RP and RepeatPan's mods

I forgot this earlier but just opt out of the beta builds to get R27 back if you want it.

2 Likes

Nice, that works. Thanks.

It seems that thread was added in this version - might explain a few things. Interesting could be

if not decoda_break_on_error then
  decoda_break_on_error = false
end
if not decoda_output then
  decoda_output = false
end

so probably we should try set that to true once and see what happens. I’ll update RP and the mods for now to r3499.

Sucks that, that happened.

Well looky what we have here!

function ResourceCallHandler:_harvest_node(resource_node, component_name, task_name, task_args)

It looks like it’s quite useless though, as the component itself isn’t used anywhere at all. I guess I can patch that though to something that makes a little more sense.


function ResourceCallHandler:shear_sheep(session, response, sheep)
  asset(false, "shear_sheep was broken, so i deleted it =)  -tony")
end

I don’t know what you’ve expected when trying to shear a sheep with an axe, Tony. Good to see the sheep insanity coming to an end, however.


The unit control handler that they’ve added is a bit weird. But then again it’s not used anywhere.


The new AI seems to be somewhat context based. If I see this correctly-ish, the commands are still chained, with newer commands being able to access results of later ones. I haven’t really looked into it though, but references to ā€œTOPā€, ā€œPREVā€ and ā€œBACK(1)ā€ seem to go in that direction.


A few name changes regarding commands, basically tooltip => description.


More hardcoding to civ as faction, sadly.


Something about items injecting (and un-injecting) AIs into an object. Interesting I guess?


huh, there was a destroy entity command the whole time and I didn’t notice it. Probably should take a list of commands at some point.


Attributes and their ranges are defined as component now, with some pretty weird way for derived attributes to work.


Some dead zone behaviour for mouse control. I’m not too sure if I’m going to honour that in rp_hotfix.


The game starts an hour later, at 8.


Really weird embark images. If I had to take a guess, this is part of some blueprint/city planning thing. The images seem to be side-encoded. Are they trying to mimic DF?


Other than that, there don’t seem to be many changes that I would need to take care off. RP’s patches can very likely be re-added easily, although I’ll have to change a few things.


19:12:

Events can return radiant.events.UNLISTEN to force the event listener to remove the event. Pretty nice for fire-and-forget events or execute-one things that might are built using an anonymous function.


Porting the mods isn’t difficult, the changes in the world generation took some time to read and adjust to though. I think I’m almost done and can likely release all updated mods (at least those that aren’t deprecated) in an hour or so. This isn’t going to use any of the new features, such as mixintos, or a new API, but r3499 is going to contain the first ā€œworkingā€ versions I believe. After that’s done, I can start moving on to prettier APIs and re-design RP’s internal flow. Switching from certain hacks to more appropriate versions, using real loggers (at least partially) and last but not least a file API.


stonehearth:is_harvestable is quite a weird event name to indicate that something is harvestable again… It sounds like a query.


19:27: I’m not sure if it was already the case, I think not - lua files are now preferred over luac. Bad news is that stonehearth/components/scaffolding_fabricator/scaffolding_fabricator_component.luac is also unusable in the decompiled version (attempt to subtract boolean from number - :empty() sounds like a boolean thingy).

Two files affected, I wonder how many more there are - and what is causing unluac to fail all of a sudden.


#r3399

It ain’t pretty but it sure works. You can get the three RP mods here and the zip containing all my mods here. Alternatively, as always, GitHub is up-to-date.

After the stream tonight I might tackle several design flaws in RP and my mods, including but not limited to:

  • Using mixintos to get rid of rp:entity_created (and more). Let’s see what mixintos are capable of.
  • Re-designing the logging system; properly use several loggers so people can tune what they want in their stonehearth.log (and what not). If I’m feeling extra fancy I might add tracer listener support too - the console could profit greatly from that.
  • Introduce a file API to RP (that currently will just wrap io's files)
  • Export timers into rp.timers and add a few more functions. And so many aliases.
  • Re-work the event system; introduce a lua object which allows to capture events for objects, or entities, without being subscribed to them (for example, subscribe to every faction’s event without subscribing to each faction individually).
  • Think about implementing the deadzone stuff for rp_hotfix.
1 Like

to summarize, this is RP working for R34 right?

Yes, it is. It hasn’t been tested much, but from what I can see it works.

ok I will test it then I guess :smile:

Release 41 Update News

  • radiant.events.trigger(entity, "stonehearth:entity_created", {entity = entity}). Err. It’s triggering the entity_created event on the entity? Question time!
  • Terrain.get_entities_in_block and Terrain.get_height. If those two functions are working and doing what they’re called, we could now have fancy stuff like ā€œdrag and drop to chop down stuffā€.
  • NewGameCallHandler was modified quite a lot for the plans.
  • tiny maps are now 2x2 instead of 1x1 it seems.
  • A change in the personality logs to make for easier mixinto (I assume)
  • client_cast_aoe and server_cast_aoe.
  • The landscaper was quite a bit redesigned it seems. Just as I was done patching that one. A few adjustments need to be done but it seems like my system would be compatible - although the code was heavily changed. We’ll see.

I will see if I update RP to R41. Technically, I want to ā€œkillā€ RP. I have already prepared its successor - dubbed Jelly - which tries to move away from an essential modding framework to a library.

Jelly currently just has the possibility to completely override the tree spawning by using json files that describe where trees should be spawned - but I have a few more things planned.

I might release a quickly fixed r4099, but that would likely be the last version of RP. I’m not even sure what currently breaks.

Edit: rp_test_world, rp_developers_dreams and rp_time_is_money seem to be broken. The fact that one girl here is called ā€œZenia Fosshopā€ determined that those mods still work.

So I guess it was just broken decompiled files again.

Edit 2: It’s just rp_time_is_money that seems to be ā€œbrokenā€. rp_developer_dreams seems to work… somewhat. The preview is of course totally wrong, but that’s as good of a fixing as I will offer with RP.

1 Like

yes, it seems there was an issue with how the personality service was handling array values…

Well, the problem was that the mixinto didn’t ā€œmergeā€ the arrays - the same thing that makes merging recipes impossible. It’s doable in lua to fix that… but this way it’s much nicer :wink:

Edit: I’ve pushed the last update I believe. rp_test_world, rp_developers_dreams and rp_time_is_money now work as they should.

To be honest, I’m quite amazed. A lot of the mods are still going with very little update required - rp_lucky_worker had merely 9 commits, of which 4 were merely manifest updates. The others were API changes that were kind of necessary (to make the mod prettier and compatible to rp_alternate_naming and friends).

Stay tuned for Jelly. I think I might be able to release the first developer preview today. First feature: Moddable landscape generator. Override trees, mixinto your own trees, and more.

3 Likes

thanks for updating your ā€œmod packā€, as they may be the only way I can get the new client to run…

looking forward to said Jelly!!

2 Likes

I see that this is part of the ā€œMore Treesā€ Mod. Is there any way to prevent the landscape generator stopping the generation of bushes?

It’s not part of the mod, that’s actually a developer preview of my Jelly (that was not really intended to be public, but eh).

The current Jelly is unstable at best (experimental?) and therefore, the missing bushes are a bug that I didn’t catch (nor really paid attention to - focus was on the tree algorithm).

I won’t release Jelly officially before I’ve finished my kitchen project, however. It would make updates so much easier for both me and you, so that’s something to look forward to. That being said, there might be a smaller bugfix release which addresses this issue before the official release, but I am not guaranteeing anything.

You need testers, no? :wink:

That’s true, I’m not a big fan of releasing clearly unfinished things though. The fact that Jelly seems to kill every other landscape feature is something grave enough to not warrant a release in my eyes.

I guess. Although I managed to at least get food in my mod… so it’s all right for me.

Problem with windows? Reinstall windows.

Stonehearth equivalent:

Problem with adding custom entities? Make them from wood. :wink:
@chimeforest

Why didn’t you follow the rule @Alfie ? :laughing:

2 Likes

Disregard safety measures, monkey patch everything.

I am @Avairian and I approve this message.

5 Likes

I kinda did… you have to chop a ā€˜Berry Tree’ to get food… :wink: