There doesn’t appear to be a corresponding data relationship for the vehicle transforming back into a predefined item (unless I missed something in the save jsons). I assume that’s so a folded vehicle can be placed as either a loot item or as a vehicle in the world, and then the procedural folding code takes over from there. That all makes sense. What I can’t figure out is what the use of the “moves” parameter would be then, since it would only affect the first time the vehicle is ever unfolded. Maybe to avoid having to iterate through the elements of the resulting vehicle and calculate the time required?
I’m specifically interested in how folding/unfolding times can be controlled. I’m happy to poke around in the source and make a pull request to do something like add an optional folding-time parameter to parts, but I’d like to know what the intent of the main developers is before getting started.
How do you see it being meant to work?
Iirc that one is in fact vestigial, it dates from when there were only specific foldable vehicles, and those are subsequently handled by the more generic fold/unfold code.
I’d support either a per-part fold/unfold cost or setting/adjusting move cost based on propagating the move cost or adjustment to the vehicle itself.
That’s almost exactly what I was thinking - an optional per-part parameter that would just allow tuning of the existing algorithm for specific cases. I haven’t looked at the algo so I don’t know exactly how that would look, but I’m envisioning something very simple like a straight turn cost that gets summed in or a scaling factor.
I’d like to start contributing so I figured I’d pick some small whimsical ideas that I wouldn’t get too ambitious about or attached to. This one would allow, for instance, viable skateboards. And hopefully open the door to some creative uses we can’t see from here.
I think I also recall hearing some noise about the vehicle code being a mess and due for a refactor as part of the move to 3-d - is there anything I’d have to consider in order to not lump on legacy debt? And is this the appropriate place for that discussion or should it be on git?
Three other things come to mind -
1 - Allowing building/scenario designers to place pre-folded vehicles may still be useful, or allowing strange things to fold to/from vehicles (e.g. worn parachutes). So it may still make sense to have an analogue to the use-action. Maybe as a subset of the more generic item-transform functionality so as to reduce the namespace footprint since it’s kind of a niche use? That’s not something I intend to tackle this early but just food for thought.
2 - Would you see any use in being able to control (from json, directly or derived) the properties of the item that a vehicle folds into? I know that gets tricky due to combinatorial complexity, given that vehicles can be customized. But I think there are a few different approaches that could limit the scope of what can be changed. Concrete examples would be the clothing layering properties of a parachute, or inscription on a folding bike so that an NPC companion will automatically pick it up (or at least preserving existing parameters across transformations).
3 - Documentation. Naturally I’ll update it as part of the PR. Should I go looking for other things to update about the use-actions? I’m guessing you’d have an intuitive sense for how complete/up-to-date it is. If you think it needs attention, point me in the right direction and I’ll take care of the details.
Sorry, I think I replied to the thread itself and not to you. Still getting used to discourse.