[Important] Compatibility & Changes in 101.0

[hokomoko]

Picking up weapons has nothing to with this thread, and already possible.
Make a unit with all available pieces, hide/show them as needed.
Implement weapons on the ground as features or neutral unit.
Make a custom command for picking up.

[FLOZi]

Make a unit with all available pieces, hide/show them as needed.

Hack, and implies a limit of 32 available weapons to pick up. This will potentially allow cleaner implementations. I say potentially because getting the unit AI right wrt targeting will be problematic.

[hokomoko]

Hack, and implies a limit of 32 available weapons to pick up. This will potentially allow cleaner implementations. I say potentially because getting the unit AI right wrt targeting will be problematic.

I don't see it as a hack, but the 32 weapons limit can be annoying indeed.
Replacing the unit with another is an option (which is more of a hack) that solves these issues.
Can even make a smart script to take care of pose etc.

EDIT: Not to mention composite units is x100 times hackier

[FLOZi]

I guess it comes down to personal preference, I don't see composites as a hack.

(Ok not generally but maybe in this case)

[bobthedinosaur]

interesting... would definitely like to see some kind of inventory thing or transport restrictions gadgets come from this.

[Anarchid]

Inventories? Transports? Composite units? Pfft.

BRING FORTH THE TERRA-TRON

[code_man]

...
Airbase Removal
...

So its gone for good? Is anyone going to write a generic replacement gadget?

Also how does one prevent a unit from moving? Not just an air unit, but ground/naval unit, to simulate a fuel system.
I was told i can set gravitiy on a unit to prevent it from moving at all but it would seem a bit hacky to me, i was wondering if there are better ways.

Nearly forgot, might be a bit offtopic, but can you make jet style aircraft that dont land vertically?

...
New Transporting
...

So does that mean the old transportaion can be considered deprecated in future and game developers will be expected to write/steal their own transportation gadget?
Will anything break for the old transports? In particularly the firebase stuff.

Sorry if i go out of scope here but i would need to know how this will be handled in the future.
I tried making a firebase but i still do not understand how i can make multiple units be not seen but still be able to fire from inside a transport, like a bunker for instance.
Also i need them to fire from specific points depending on in which direction the target is.
I have tried this, but the units weapons when fired from inside the transport collide with the carrier and blow it up and themselfs with it.
If you could tell me how this will be handeled in 101, i would much appreciate.

Also i bitched alot in the past about the (un)load command being neigh unusable, has/will this be improved? I swear unit loading has caused me dearly in more than a few games.

Id also like to point out this https://springrts.com/mantis/view.php?id=4745, which is still in 100.

Last but not least, what do you think of a tag linking transportCapacity with harvestStorage so that a unit like a truck can either carry materials or units?

[hokomoko]

So its gone for good? Is anyone going to write a generic replacement gadget?

Yes.

Also how does one prevent a unit from moving?

Set max speed, max reverse speed and max acceleration to 0.

So does that mean the old transportaion can be considered deprecated in future and game developers will be expected to write/steal their own transportation gadget?

Support for the Legacy Transports isn't planned for removal or deprecation.
However, if your game has new transporting mechanics, they won't play well with Legacy transports, so a gadget may be needed to simulate these.

Will anything break for the old transports? In particularly the firebase stuff.

No.

Sorry if i go out of scope here but i would need to know how this will be handled in the future.
I tried making a firebase but i still do not understand how i can make multiple units be not seen but still be able to fire from inside a transport, like a bunker for instance.

Units in a fire platform still have a position in the world and aim just like every other unit. So a SC-style bunker can be hard to implement (it may be better to just give that unit the possible weapons and enable/disable them based on loaded units)

Also i bitched alot in the past about the (un)load command being neigh unusable, has/will this be improved? I swear unit loading has caused me dearly in more than a few games.
Id also like to point out this https://springrts.com/mantis/view.php?id=4745, which is still in 100.

I'll check this.

Last but not least, what do you think of a tag linking transportCapacity with harvestStorage so that a unit like a truck can either carry materials or units?

This can be easily implemented in lua, even in _post.

[code_man]

Thanks for quick reply, good to know.

Units in a fire platform still have a position in the world and aim just like every other unit. So a SC-style bunker can be hard to implement (it may be better to just give that unit the possible weapons and enable/disable them based on loaded units)

That is rather not good to hear. :/
My game makes rather heavy use of firebase/ivf mechanics by design and i was hoping the engine could support me there.
Dont want this to float too offtopic but if you have anymore specific information, it might help me.

[Jools]

Would it be possible to rename 'transporteeID' to 'passengerID', just in the wiki? It makes it easier to fast grasp which field is which. transporter and transportee are too similar...

[PepeAmpere]

I somehow missed this post, big thank you hoko moko (+any other hidden dev behind this).

[FLOZi]

Seen as it isn't mentioned elsewhere:

Spring.isValidUnit(unitID)

will now complain if the passed argument is anything other than a number, previously you could pass it nil and it would behave nicely.

[8611z]

Spring.isValidUnit(unitID) will now complain if the passed argument is anything other than a number, previously you could pass it nil and it would behave nicely.

the previous way seems better.

[Super Mario]

Spring.isValidUnit(unitID) will now complain if the passed argument is anything other than a number, previously you could pass it nil and it would behave nicely.

the previous way seems better.

If you going to depute this, then you going to have to put more meat into your argument, as I see no reason why they shouldn't enforce a domain constraint in the function that he is describing.

[FLOZi]

I actually agree with knorke, but I'm sure he'll now find a way to disagree.


AFAIAA The argument in favour of this lies along the lines of 'it can help you realise when you did something dumb in lua'

[Silentwings]

I would also argue in favour of Spring.IsValidUnitID(nil) returning false without erroring, because in cases where the engine may pass you either (1) a valid unitID or (2) a nil, and it saves you the trouble of writing "if unitID and Spring.IsValidUnitID(unitID) then".

I see no reason why they shouldn't enforce a domain constraint in the function

Et tu, I see no reason to have one.

[8611z]

Spring.isValidUnit(unitID) will now complain if the passed argument is anything other than a number, previously you could pass it nil and it would behave nicely.

the previous way seems better.

If you going to depute this, then you going to have to put more meat into your argument, as I see no reason why they shouldn't enforce a domain constraint in the function that he is describing.

Not 100% what you mean by "domain constraint."
I think the purpose of Spring.ValidUnitID() is this: To check if a value describes a valid unitID.
I do not see a situation where the question can not be clearly answered with returning either true or false.
If the value is describes a currently valid unitID then the answer is: No.
If the value is a negative number then the answer is: No.
If the value is not an integer then the answer is: No.
If the value is a string then the answer is: No.
If the value is a table then the answer is: No.
If the value is nil then the answer is: No.
And so on.
That the value happens to be nil is imo a valid situation. (I wonder how many ValidUnitID() checks are added especially to catch that situation.)
If the question can always be answered with 100% certainty then no question should cause an error.

[hokomoko]

I think the purpose of Spring.ValidUnitID() is this: To check if a value describes a valid unitID.

That's one interpretation.
I prefer to think of: To check if a UnitID is valid.
Any non-number argument is not a UnitID that we can check, so we have an error.

anyway https://github.com/spring/spring/commit ... 3a51e7b494
so discussion is irrelevant