That’s sadly one of my weak points. I aim to please, which means that I would rather not do something than do it poorly. The only reason I would do a sloppy job is because I didn’t realise earlier that it would be that difficult/impossible and I tried about every way I could imagine.
As for the move part… I might have a solution. So:
18:49: Idea which I am not too fond of. Basically, it’s a copy of PlaceableItemProxyComponent
, where the line that adds the placed_item
component to entity has been removed.
19:13: A simple copy of the PlaceableItemProxyComponent proved to be non-working. I’m quite desperate at this point; I don’t want to re-invent the wheel.
19:33: And back we are after a very short intermezzo where @SteveAdamo threatened me… I hope the function head in his bed makes clear that there is no messing around with the family.
19:45: Well, this seems to work. By adding a new field to stonehearth:placeable_item_proxy
I’ve managed to create “unmovable” objects. This is likely something that will be in RP 2703 and newer, but since I don’t want people to use dev versions unless they really have to, I’ll keep it in as a version-limited hack (just like click_and_gone that I need to update too at some point…)
Next step: Growth effects. Oh, and growing trees should probably be not be sprouted, as that “resets” their model. I’ll have to check for a solution for that, too.
19:53: And there we go, growing effects implemented. I had a glorious choice between a bunch of sound effects and the fire pit. Guess which critter is burning in its final stage now. Kind of. fursplosion looks like it isn’t implemented yet, sadly.
19:58: I’ve defined a table which defines which components are copied over from each stage; so far this is stonehearth:resource_node and unit_info. This means that description and name can be changed with each growth stage, too. Perhaps I should move those into a sub-key of the growth stage, but then again…
Harvesting shoots is disabled for these trees; let’s see if I can bring them back.
20:03: Hm. The model change to depleted is right in the middle of RenewableResourceNodeComponent:spawn_resource
… I can’t really prevent that. If I carried over stonehearth:renewable_resource_spawned
from rp_click_and_gone to RP I might…
I’m afraid I’ll have to do just that. So let’s move on to r2703 and carry over the new hooks; then re-write rp_cag and after that we’re back to trees.
20:30: Added the resource events in RP and updated rp_click_and_gone to use them. Officially less hackish now.
I’ve changed the order too, so we don’t need timers for now.
Next thing: Moving the unmovable part into RP, too.
20:45: Moved the unmovable part to RP and fixed where I accidentally a whole location.
I think at this stage I’m pretty much done. One last thing to do is to add the possibility to call functions when growth happens - that seems like a reasonable thing to do.
20:59: _radiant.call
does not like entities. At least not if they are passed “plain”, i.e. not boxed in a table. So I guess the on_start
command that we fire will have to expect to be used like an event rather than a normal command/call, sadly.
21:08: rp_diy_trees:enable_shooting might be a slightly confusing name. I love it.
21:14: That should do the trick. Now I just have to close the 11 SciTE windows I had opened. Start fresh before I overwrite changes…
21:15: ["ntit"] = "(Entity 5976 Little Tree)";
I would like to solve: “Untitled”! buzzer
21:18: I really think that Radiant’s json parser is seriously broken. It concats strings ([ "Hello", "World" ]
to one element, Hello""World
) and { foobar : "bar" }
does not throw an exception but rather yields { ooba = "bar" }
as lua object… Errr…
21:22: Who had the idea to call a command “enable_command” which takes two parameters: the command name and whether it’s enabled or not. Really! I would expect enable_command("foo")
to enable foo, not to disable it (because nil evaluates to false).
Right, so the saplings are yielding no sprouts until they reach a certain height (by using the “on_start” call in the json). Next I have to disable the “depleted” thing. I’m not really satisfied with calling the event just on the component; I think it should be on the entity too. Subscribing to a component’s event doesn’t sound very modular. Yeah, let’s change that.
21:32: In other news, I’m not a big fan of this system as a whole. Subscribing to every entity created just to subscribe to a few (or even one) events seems like a very unnecessary process. I might deal some magic with RP to have these entities fire on a special manager too. That would be nice. But we’ll do that after the next update. Perhaps I’m missing something.
I also completely forgot why I wanted to move that event. Uhhh… Ah right, setting the model wasn’t it.
21:37: Alright, done. The model now properly stays the same it was before, nice.
Right. Let’s see if I can nicely identify trees. I guess searching the entity uri for ‘oak_tree’ will do the trick for now. Renaming a few things to make this work.
21:49: dumdidum.
21:54: Being unable to disable commands before they are created is a pain. It would be much cleaner if they stored command changes (i.e. calls to enable_command) in a table for commands that have not been added yet. Then, when the command is added, it simply inherits that state (to work for default-disabled commands too).
22:01: commands:disable_command("chop_tree", true)
- see? SEE? Just what I’ve talked about. I’ve typed up to “true” before realising what I was doing.
22:11: Added automagical chop detection. That means that trees can turn on/of whether they can be lumbered or not during growth. For example, you could have a tree that isn’t choppable (sapling), then is (tree), then turns into a flower and thirteen moons later becomes Yggsdrasil and satisfies all your wood needs for… like ever.
I’m quite satisfied with the current version and while it is far from done, I think it’s a neat tech demo. Refactoring stuff to make it easier to use.
22:25: Alright, here we go. Took me a day and it isn’t as pretty as I would like it to but I think it’s quite an achievement given the tools we have to work with.
To use it, RP r2701 is the base; however the WIP r2703 rp.smod is required because of the new events that I’m using. The mod itself is available here. So if you’re curious, have the latest WIP video here (including @SteveAdamo beloved pouff).
The mod currently only contains a sapling for oak trees, but copying and adapting it should be really easy. I’m curious what @Miturion can do with it - in theory, it could be used for all growing things - wheat, flowers, you name it. However, it’s currently a bit hard coded to chopping.
If you have any questions, requests or something let me know. Known issues:
- The size cannot be changed once the sapling has been spawned. That’s an issue Radiant has to fix (!summon whoever-is-responsible). If we could, we could simply adapt the size in each growth stage or introduce new growth stages this way - would be really amazing.
- It’s kind of hard-coded for trees right now; that is it will check the
stonehearth:resource_node
for a durability > 0 and then enable the ‘chop’ command. I might change this in the future to allow/change this behaviour. In theory, you can use whatever you want using theon_start
callback in every growth stage. I’m not sure what to do here, because it really screams for an observer instead of this built-in functionality. Plus there would be on_start, but hm. - The icon is too cute and might cause allergic reactions, I know. Sorry!
duration
currently uses gameloop ticks (5/second) instead of a calendar entry. This would be another excellent use of timers, as the usual code for this kind of thing is a copy-paste and does not allow minutes. I might add something like timers to RP; we’ll see.
So right, that’s it. That was about how I develop mods, including all the nasty side-effects that occur. The final product usually looks so much easier but it’s all a matter of getting used to it. RP’s API actually proves to be quite useful for certain things. Now it’s time for Rick and Morty.