Spring RTS Engine

Setting a finished unit to build < 1 does not turn it into a nano frame. I think this is an engine bug.

For now just remove the unit and replace it with a nanoframe.

Tobi wrote:For now just remove the unit and replace it with a nanoframe.

How? Spring.CreateUnit creates fully built units.

I found out about the secret 5th param that makes nanoframes. When was the wiki last updated?

Wiki wrote:Spring.CreateUnit note: offmap positions are clamped! (you still can use MoveCtrl todo so)

( string "defName" | number unitDefID,
number x, number y, number z,
(number facing | string "facing"),
number teamID ) -> number unitID

Still, < 1 build progress is a bit of a bug. The 5th param shouldn't be needed.

Just added it to wiki

You can see in the history when it was last updated.

And yeah, it is a bug, and yeah, it isn't really easy to solve. (Need to make sure all the state transitions that happen when unit finished building are put together, and make new code that can do the reverse transition.)

Tobi wrote:And yeah, it is a bug, and yeah, it isn't really easy to solve. (Need to make sure all the state transitions that happen when unit finished building are put together, and make new code that can do the reverse transition.)

Doesn't that already exist with gradual reclaim?

Tobi wrote:And yeah, it is a bug, and yeah, it isn't really easy to solve. (Need to make sure all the state transitions that happen when unit finished building are put together, and make new code that can do the reverse transition.)

Btw: It is useful to have a Callin for that. Basically the reverse of UnitFinished.

And what if nanoframes are turned off? Current method is probably better.

FLOZi wrote:And what if nanoframes are turned off?

Why do you care about a feature that you won't use? Why do you set build percentage when you disabled nanoframes?

Because you may still want to put the building in 'being built' state?

(Which is the only thing that is being done here; the nanoframe is just a side effect.)

Tobi wrote:Because you may still want to put the building in 'being built' state?

(Which is the only thing that is being done here; the nanoframe is just a side effect.)

Exactly.

Nanoframes should be moved to lua anyway, its a TA specific mechanism thats sitting in a general RTS engine.

Doing so would also make it easier to do things like showing the reverse of the build animation on features being reclaimed

How does that make anything easier?

AF wrote:Nanoframes should be moved to lua anyway, its a TA specific mechanism thats sitting in a general RTS engine.

Doing so would also make it easier to do things like showing the reverse of the build animation on features being reclaimed

Maybe you haven't noticed but spring is mainly used by TA mods (over 90% of all game-time), meaning removing TA-specific features (without providing a 100% functional replacement beforehand) is a completely retarded idea.

Especially when the removal won't actually provide anything useful.

Regret wrote:[ meaning removing TA-specific features (without providing a 100% functional replacement beforehand) is a completely retarded idea.

moving it to lua isn't removal it adds flexibility.

smoth wrote:moving it to lua isn't removal it adds flexibility.

No it does not.

how so?

smoth wrote:how so?

Because it wouldn't add anything that isn't already possible with Lua, it would just remove a feature.

Why have it as part of the core engine? Seems needless.

smoth wrote:Why have it as part of the core engine? Seems needless.

Because nobody made a fully working replacement for it and it is non-sense to remove such a fundamental part of the engine that is used so vastly.

Countless mods/games use the feature. Even if it was remade it would be ridiculous to remove engine support of it as it would most surely cause a damn heck of a lot of new problems causing needless chaos and patching for all involved projects.

Unless you have a replacement ready there is no use even arguing it's removal.