That could be to added as an optional parameter:
Code: Select all
Spring.CreateUnit( string "defName" | number unitDefID, number x, number y, number z, (number facing | string "facing"), number teamID [, boolean isbeeingbuild] ) -> number unitID
Moderator: Moderators
Code: Select all
Spring.CreateUnit( string "defName" | number unitDefID, number x, number y, number z, (number facing | string "facing"), number teamID [, boolean isbeeingbuild] ) -> number unitID
Read. the. post.Pxtl wrote:I realize that it's too late to change it, but why would anything else occur? How the hell does it make any sense that ordering the creation of a unit in partial completion state results in a fully functional but incomplete unit instead of a unit under construction?
You can't order it like that, you can only create a finished unit and then reduce its build completion. Apparently some things happen when the unit is finished that aren't reverted by reducing the completion.Pxtl wrote:I realize that it's too late to change it, but why would anything else occur? How the hell does it make any sense that ordering the creation of a unit in partial completion state results in a fully functional but incomplete unit instead of a unit under construction?
Internally CreateUnit calls LoadUnit:zwzsg wrote:Instead of boolean isbeeingbuild, why not a number buildProgress, and a UnitID beingBuiltBy?
Code: Select all
CUnitLoader::LoadUnit(const UnitDef* ud, float3 pos, int team,
bool build, int facing, const CUnit* builder)
Code: Select all
Spring.CreateUnit( string "defName" | number unitDefID, number x, number y, number z, (number facing | string "facing"), number teamID [, boolean isbeeingbuild[, number builderUnitID]] ) -> number unitID
Didn't add builder because it is barely used inside Spring: it is only used to get the initial firestate and movestate, and to pass the builderID parameter back to Lua's UnitCreated callin.lua: added 'build' parameter (boolean, default false) to Spring.CreateUnit
Give the con/factory a guard (assist) order on the build? May not work if you have canAssist=0 though.zwzsg wrote:But I still need a BuiltBy argument, or some other way to tell the factory or the cons to resume nanolathing it.
Code: Select all
SetUnitHealth(unitID, {"health"=..., "buildProgress"=...})
but wouldn't it fire the UnitCreated event with a proper builder argument? the rest can be handled there.Tobi wrote:In either case, as far as I've seen a builder argument to CreateUnit would currently not have the effect that the builder continues construction. That would require substantial more changes (normally the builder initiates the construction, not the buildee.)
Yeah, I tested, it works, but only if I set canAssist to 1.Tobi wrote:Give the con/factory a guard (assist) order on the build? May not work if you have canAssist=0 though.
Does not work if the ground is occupied by the unbuilt building.Alternative solution that should always work I think, is to issue the order to the con/factory again
You mean, do not spawn the under construction unit, issue the build order, and once build order is issued, change the buildprogress of the newly made under construction unit? Should work.issue the order to the con/factory again and once it started the build issue:Code: Select all
SetUnitHealth(unitID, {"health"=..., "buildProgress"=...})