[Important] Compatibility & Changes in 101.0 - Page 2

[Important] Compatibility & Changes in 101.0

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

hokomoko
Spring Developer
Posts: 592
Joined: 02 Jun 2014, 00:46

Re: [Important] Compatibility & Changes in 101.0

Post by 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.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6235
Joined: 29 Apr 2005, 01:14

Re: [Important] Compatibility & Changes in 101.0

Post by FLOZi »

hokomoko wrote: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
Spring Developer
Posts: 592
Joined: 02 Jun 2014, 00:46

Re: [Important] Compatibility & Changes in 101.0

Post by hokomoko »

FLOZi wrote: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
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6235
Joined: 29 Apr 2005, 01:14

Re: [Important] Compatibility & Changes in 101.0

Post by 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)
User avatar
bobthedinosaur
Blood & Steel Developer
Posts: 2699
Joined: 25 Aug 2004, 13:31

Re: [Important] Compatibility & Changes in 101.0

Post by bobthedinosaur »

interesting... would definitely like to see some kind of inventory thing or transport restrictions gadgets come from this.
User avatar
Anarchid
Posts: 1383
Joined: 30 Nov 2008, 04:31

Re: [Important] Compatibility & Changes in 101.0

Post by Anarchid »

Inventories? Transports? Composite units? Pfft.

BRING FORTH THE TERRA-TRON
User avatar
code_man
Posts: 260
Joined: 19 Jan 2014, 13:10

Re: [Important] Compatibility & Changes in 101.0

Post by code_man »

hokomoko wrote: ...
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
Spring Developer
Posts: 592
Joined: 02 Jun 2014, 00:46

Re: [Important] Compatibility & Changes in 101.0

Post by hokomoko »

code_man wrote: 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.
User avatar
code_man
Posts: 260
Joined: 19 Jan 2014, 13:10

Re: [Important] Compatibility & Changes in 101.0

Post by code_man »

Thanks for quick reply, good to know.
hokomoko wrote: 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.
User avatar
Jools
XTA Developer
Posts: 2814
Joined: 23 Feb 2009, 16:29

Re: [Important] Compatibility & Changes in 101.0

Post by 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...
User avatar
PepeAmpere
Posts: 589
Joined: 03 Jun 2010, 01:28

Re: [Important] Compatibility & Changes in 101.0

Post by PepeAmpere »

I somehow missed this post, big thank you hoko moko (+any other hidden dev behind this). :!:
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6235
Joined: 29 Apr 2005, 01:14

Re: [Important] Compatibility & Changes in 101.0

Post by 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
Posts: 169
Joined: 08 Jul 2015, 20:20

Re: [Important] Compatibility & Changes in 101.0

Post by 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
Posts: 820
Joined: 21 Oct 2008, 02:54

Re: [Important] Compatibility & Changes in 101.0

Post by Super Mario »

8611z wrote:
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.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6235
Joined: 29 Apr 2005, 01:14

Re: [Important] Compatibility & Changes in 101.0

Post by 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'
User avatar
Silentwings
Moderator
Posts: 3686
Joined: 25 Oct 2008, 00:23

Re: [Important] Compatibility & Changes in 101.0

Post by 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
Posts: 169
Joined: 08 Jul 2015, 20:20

Re: [Important] Compatibility & Changes in 101.0

Post by 8611z »

Super Mario wrote:
8611z wrote:
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
Spring Developer
Posts: 592
Joined: 02 Jun 2014, 00:46

Re: [Important] Compatibility & Changes in 101.0

Post by 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
Post Reply

Return to “Engine”

cron