[Important] Compatibility & Changes in 101.0
Moderator: Moderators
Re: [Important] Compatibility & Changes in 101.0
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.
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.
Re: [Important] Compatibility & Changes in 101.0
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 wrote:Make a unit with all available pieces, hide/show them as needed.
Re: [Important] Compatibility & Changes in 101.0
I don't see it as a hack, but the 32 weapons limit can be annoying indeed.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.
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
Re: [Important] Compatibility & Changes in 101.0
I guess it comes down to personal preference, I don't see composites as a hack.
(Ok not generally but maybe in this case)
(Ok not generally but maybe in this case)
- bobthedinosaur
- Blood & Steel Developer
- Posts: 2700
- Joined: 25 Aug 2004, 13:31
Re: [Important] Compatibility & Changes in 101.0
interesting... would definitely like to see some kind of inventory thing or transport restrictions gadgets come from this.
Re: [Important] Compatibility & Changes in 101.0
Inventories? Transports? Composite units? Pfft.
BRING FORTH THE TERRA-TRON
BRING FORTH THE TERRA-TRON
Re: [Important] Compatibility & Changes in 101.0
So its gone for good? Is anyone going to write a generic replacement gadget?hokomoko wrote: ...
Airbase Removal
...
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?
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?...
New Transporting
...
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?
Re: [Important] Compatibility & Changes in 101.0
Yes.code_man wrote: So its gone for good? Is anyone going to write a generic replacement gadget?
Set max speed, max reverse speed and max acceleration to 0.Also how does one prevent a unit from moving?
Support for the Legacy Transports isn't planned for removal or deprecation.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?
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.
No.Will anything break for the old transports? In particularly the firebase stuff.
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)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.
I'll check this.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.
This can be easily implemented in lua, even in _post.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?
Re: [Important] Compatibility & Changes in 101.0
Thanks for quick reply, good to know.
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.
That is rather not good to hear. :/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)
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.
Re: [Important] Compatibility & Changes in 101.0
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
- Posts: 589
- Joined: 03 Jun 2010, 01:28
Re: [Important] Compatibility & Changes in 101.0
I somehow missed this post, big thank you hoko moko (+any other hidden dev behind this).
Re: [Important] Compatibility & Changes in 101.0
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.
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.
Re: [Important] Compatibility & Changes in 101.0
the previous way seems better.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.
-
- Posts: 823
- Joined: 21 Oct 2008, 02:54
Re: [Important] Compatibility & Changes in 101.0
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.8611z wrote:the previous way seems better.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.
Re: [Important] Compatibility & Changes in 101.0
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'
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
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: [Important] Compatibility & Changes in 101.0
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".
Et tu, I see no reason to have one.I see no reason why they shouldn't enforce a domain constraint in the function
Re: [Important] Compatibility & Changes in 101.0
Not 100% what you mean by "domain constraint."Super Mario wrote: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.8611z wrote:the previous way seems better.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.
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.
Re: [Important] Compatibility & Changes in 101.0
That's one interpretation.I think the purpose of Spring.ValidUnitID() is this: To check if a value describes a valid unitID.
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