Fix holdsteady

[bobthedinosaur]

Would it be possible to make the holdsteady tags useful, mainly allow attached units to follow their above hierarchy's rotation, which they currently do not (as I demonstrated in http://springrts.com/phpbb/viewtopic.php?f=11&t=23329 )

Currently holdsteady set to "false" aligns the attached unit to the map, so when the transport turns (during movement not script) the attached unit remains aligned to the map and rotates inside the transport unit's hierarchy. Why this is even useful, I don't know.

Holdsteady set to "true" (which is default and might be why not too many people noticed an issue), aligns the attached unit to the transports 0 degree heading, and the attached unit will remain that way regardless of any above hierarchy pieces rotating (script wise), but it does stay with the transport alignment as the transport moves around the map. I can see some reasons this may be helpful.

What I and many other modders/ game devs would love to see is either a third option or a fix to holdsteady false, that allows for attached units to be rotated using their transports parts.

Would there be any problems with this?

[FLOZi]

you have the options mixed up there, bob.

+1 to this, again. Maybe if I weren't so lazy I'd fix it myself.

[bobthedinosaur]

you have the options mixed up there, bob.

what part?

[FLOZi]

you have the options mixed up there, bob.

what part?

Last edited by bobthedinosaur on Wed Jun 23, 2010 5:27 am, edited 2 times in total.

I c what u did thar

[FLOZi]

Can you do a quick test for me Bob, it seems to me that piece movements are already taken into account, just not rotations?

[bobthedinosaur]

Move works, just not rotation.

[Forboding Angel]

Holdsteady is so that units on a flying transport don't go all asstarded when flying over terrain. What you are asking for is something that aligns the unit to the link piece which is entirely different.

[FLOZi]

Holdsteady is so that units on a flying transport don't go all asstarded when flying over terrain. What you are asking for is something that aligns the unit to the link piece which is entirely different.

That's not entirely accurate Forb, but I'm too drunk to explain why.

[bobthedinosaur]

yes, holdsteady true is used for that forb, and that's okay, holdsteady false tells the unit to be aligned to the map (this is what it currently does not what I am asking for), but because it is not default its rarely seen. What game has a unit that actually uses false like this? If there is a reason for it to act like this, then add the third option or make another new tag. I don't care, as long as it works.

edit: To clear some things up. Look at the link to other post and the attached screen shots if you don't understand.

[Forboding Angel]

You're missing the point. Aligning to map won't have the effect you want, you need align to link.

Anyway, try deleting the tag altogether. Spring may have some funkyness that assumes if the tag exists at all it's true.

[bobthedinosaur]

Deleting the tag doesn't do any thing. And I agree I don't want it to align to the map, as I've said I don't think any one would use that. Please read more carefully.

[CarRepairer]

I see no reason why anyone would want the attached unit to always align to the transporter's direction regardless of the piece it's attached to. If someone did want that, they can attach it to an invisible piece they control to always be aligned with the direction of the unit. This has to be a bug or oversight and I too would like it to be fixed.

[bobthedinosaur]

My thoughts exactly. If they want it stuck to the unit's alignment, then don't mess with the attached pieces. Well, there are exceptions for air units and large rotating arms, but those could also be done in the script.

I still have not heard from any of the engine developers whether this issue is to be confirmed to be bug or not.

[Pxtl]

I see no reason why anyone would want the attached unit to always align to the transporter's direction regardless of the piece it's attached to. If someone did want that, they can attach it to an invisible piece they control to always be aligned with the direction of the unit. This has to be a bug or oversight and I too would like it to be fixed.

I assume there are a hojillion air-transports that would be broken by this change. Not that I'm saying the change is a bad thing, but that it probably would have to be implemented in a backwards-compatible format.

[FLOZi]

I see no reason why anyone would want the attached unit to always align to the transporter's direction regardless of the piece it's attached to. If someone did want that, they can attach it to an invisible piece they control to always be aligned with the direction of the unit. This has to be a bug or oversight and I too would like it to be fixed.

I assume there are a hojillion air-transports that would be broken by this change. Not that I'm saying the change is a bad thing, but that it probably would have to be implemented in a backwards-compatible format.

I don't see why that would be the case.

btw I would consider it an oversight rather than a bug. When the tag was first introduced it was solely for use on air trans to maintain the OTA-like behaviour. It was me that removed the check for the air movetype to allow it to be used on ground transports. Infact I think originally it was hardcoded to air transports and there was no possibility to set it in the unit def.

[zwzsg]

I assume there are a hojillion air-transports that would be broken by this change. Not that I'm saying the change is a bad thing, but that it probably would have to be implemented in a backwards-compatible format.

I doubt any air transport has a transport-piece oriented differently than the plane. So you'd see no change.

[FLOZi]

mantis report: http://springrts.com/mantis/view.php?id=1965

Includes bob's example unit

[FLOZi]

Kloot is awesome. All hail kloot.

http://github.com/spring/spring/commit/ ... dfbbbe4634

[bobthedinosaur]

Thank you very much!

[bobthedinosaur]

play testing in the latest RC I noticed that attached unit turning is working, but it is acting strange:




it looks like the parent piece goes one way and attached rotates the opposite direction?