[Important] Compatibility & Changes in 101.0

[hokomoko]

tl;dr Airbases and fuel engine implementations were removed. New Transporting (TM) was added.
Example gadget: viewtopic.php?f=23&t=34417

Glossary:
Legacy Transports - Any unit with transportCapacity > 0 and transportMass > 0 (unit.isTransport in lua)


Airbase Removal

The airbase code in the engine was a bad case of highly specific & buggy code and its maintenance wasn't worth keeping it.
Fuel code was slightly better, but still highly specific and not worth keeping.

Removed Tags:

• minAirBasePower
• maxFuel
• refuelTime

SetUnitFuel, GetUnitFuel and COB setters/getters were deprecated

Since isAirbase is used with some AIs it was kept for now, it doesn't affect anything and it is only useful for marking a unit's role.


New Transporting

In order to make a lua reimplementation possible, the transport system was made more generic and new lua callouts were added.
The behaviour of Legacy Transports should stay the same, other than the fact that now every mobile unit can be a Legacy Transport (including builders).

The main change in New Transporting is that now every unit can have units attached (or detached) to it (form it) by using:

• Spring.UnitAttach(transporterID, passengerID, pieceNum) - When used on Legacy Transports this will be equivalent to the script AttachUnit.
• Spring.UnitDetach(passengerID), Spring.UnitDetachFromAir(passengerID)
• Spring.SetUnitLoadingTransport(passengerID, transportID) - Turns off collisions between these two.

When units are attached/detached, the regular UnitLoaded and UnitUnloaded callins are called.

Units that were attached are still selectable and can still fire. You can make them unselectable/stun them as necessary.

A Legacy Transport isn't usable for New Transporting.

Air Units Landing

Another required capabilty was to force air units to land in a specific point. This is still being tweaked, but a new lua callout was added:
Spring.SetUnitLandGoal(unitID, x, y, z [, radius]) which tells the unit to land (even if it is in fly mode) in the supplied point (doesn't have to be on ground).
This callout can be called every frame to update the landing position if it needs to be changed (i.e. when landing on a carrier).

Example:




All the above changes are already live in the latest dev version (100.0.1-150-g7bf559f)

[PicassoCT]

Fueling is now handled by lua? Part of Spring base content?

Is it handled at all?

[hokomoko]

Not handled at all.

[Jools]

The main change in New Transporting is that now every unit can have units attached (or detached) to it (form it) by using:

• Spring.UnitAttach(transporterID, transporteeID, piece) - When used on Legacy Transports this will be equivalent to the script AttachUnit.
• Spring.UnitDetach(transporteeID), Spring.UnitDetachFromAir(transporteeID)

Is script AttachUnit still present or is it removed?

[hokomoko]

The script AttachUnit still exists and will only work with Legacy Transports (as was before).

[Silentwings]

What is it that distinguishes a legacy transport from a new transport? A unitdef tag?

[hokomoko]

There is no "New Transport" as any unit can have other units attached to it by synced lua.

Legacy Transports - Any unit with transportCapacity > 0 and transportMass > 0 (unit.isTransport in lua)

[FLOZi]

now every unit can have units attached (or detached) to it (form it) by using:

• Spring.UnitAttach(transporterID, transporteeID, piece)

I think I love you.


I also hate you for doing this now, when I have no time to do anything with it.

[Jools]

Thanks for notifying, I'm sure the change will be for the better.

The only reason I was concerned with the internal script way was because I spent a lot of time calibrating it for the morph gadget, and it has such a mess of a code that I'd rather not touch it again :)

[gajop]

I think it would be reasonable to have the synced read equivalent of SetUnitLandPos, e.g. GetUnitLandPos and some way of knowing if the unit is currently trying to land -> does SetUnitLandPos cause a command to be issued?
Is this also the first time a synced ctrl callout would be used to issue unit orders? I don't think that incosistency is great if so. Should we be making custom commands that would be calling SetUnitLandPos?

[Super Mario]

That's great! What are you working on next?

[hokomoko]

I think it would be reasonable to have the synced read equivalent of SetUnitLandPos, e.g. GetUnitLandPos and some way of knowing if the unit is currently trying to land -> does SetUnitLandPos cause a command to be issued?

SetUnitLandPos is a slightly improved SetUnitMoveGoal and doesn't issue a command, it should be used by custom commands which require the unit to land.

I'll put example code in the near future.

That's great! What are you working on next?

It's not done yet.

[FLOZi]

Men of War style equipment inventories.

[hokomoko]

A slight change:
SetUnitLandPos(unitID, px, py, pz) => SetUnitLandGoal(unitID, px, py, pz [, radius])

[Jools]

What does the optional radius argument do? Specify the radius of the acceptable circle where it is allowed to land? It wills till try to land at the specified point?

[hokomoko]

Yup

[FLOZi]

I also think this will make 'restricted' transports easier / cleaner to implement:

For example, a jeep that can carry exactly 4 soldiers and 1 anti tank weapon, and nothing else:

[hokomoko]

Correct.

[Super Mario]

Would be cool if you could "equip" weapons by picking them up from the ground. That way a clone of army men would be possible and I would play the ever lasting shit out of it.

[FLOZi]

Would be cool if you could "equip" weapons by picking them up from the ground. That way a clone of army men would be possible and I would play the ever lasting shit out of it.

That is what I meant with

Men of War style equipment inventories.