P.U.R.E. 0.8 RC3

[Argh]

@KDR: I'm using MoveCtrl to get it done, duh. It's the only other way to make Units float in space.

@Lurker: I don't want any of that stuff to be mandatory for everybody or anything, it's just that in this specific case, I need:

1. Transports where Units aren't stunned, so that I can send them directions and have them animate, and where they will engage targets as normal. If I'm going to make them "walk", the easiest way by far is to do it by dragging them around with Pieces of the Transport and sending their BOS a signal to start walking animations.

2. Transports where Units keep their LOS, so that buildings by themselves don't need it. It's a performance issue.

What happens when you turn off holdsteady? It looks like units will stay at their original direction forever.

Nothing I did, including messing with that, seemed to allow me to actually change the orientation of the Units attached to a Piece. HoldSteady didn't seem to have any effect (think it's just there for orientation control for air transports). I could change their position, but without orientation control, I might as well just stick with MoveCtrl.

As it is, it all works, so I can hardly complain. Making them move around is just visual icing anyhow.

[FLOZi]

holdsteady sets whether the transportee maintains the heading it had when loaded or takes on the heading of the transporter (but not of the piece of the transporter it is attached to)

[Argh]

Right. What I need, if I'm going to make them work as classic transports, is something that allows them to follow the orientation of the Piece their attached to at all times, basically. Then I could use BOS on the transport's end, send a signal to the attached Units via BOS-->Lua-->BOS to start their walk animations, and voila, the illusion is created that they're "patrolling the rooftops", or whatever. That's what I'd have preferred- transport loading / unloading behavior just requires minor tweaks at that point that I can do with Lua.

As it is, though... doing it with MoveCtrl would require setting up custom bounds, checking on their positions all the time, sending them signals, and would be very CPU-heavy, without creating any real benefits, other than looking a little prettier imo.

[lurker]

Wouldn't want what to be mandatory?
1. READ MY POST YOU CAN ALREADY DO THIS ARE YOU HIGH
2. Is nothing more than a bugfix.

[Argh]

Yay, the perils of internet communications.

I'm saying that:

1. If you use isAirBase, Units do not behave correctly, when attached to a Building that's acting as a Transport. They don't engage targets most of the time. I think this is because of the no-LOS issue, but idk.

And since they don't behave correctly, nor can they be re-oriented, etc., no, it's not what I'm smoking that's the issue

Trust me, I wouldn't blow a day and a half of dev time on this, if transports worked. I tried all of that first, thinking it would be a really easy thing to add to my pile o' content, and unlike my current solution, it wouldn't require specific tags for Units that can use it, complex filtering, etc.

2. Is not a bugfix- not all Units should have LOS while transported. It's wasteful with a Transport that isn't using isAirBase.

Ideally, the "transport" FBI would have tags something like this:

isFireBase=0;
isAirBase=1;
followPieces=1;
keepLos=1;

...to generate the correct behaviors, I think. Everything past that would be some simple signals to StartMoving()/StopMoving() started by a teeny Lua-->COB-->Lua sequence, which would be nice and cheap.

[lurker]

If you use isAirBase, Units do not behave correctly, when attached to a Building that's acting as a Transport.

I never meant to say it worked well, just that they aren't paralyzed

Is not a bugfix- not all Units should have LOS while transported. It's wasteful with a Transport that isn't using isAirBase.

Sensible behavior is that isAirBase transported units have LOS. I could add tags for it, but to just simply add keeping LOS for airbase is a bugfix.

[Argh]

I never said it worked well, just that they aren't paralyzed

Ah. Yes, you're right, they aren't paralyzed. Sorry, I was dreadfully unclear there.

Sensible behavior is that isAirBase transported units have LOS. I could add tags for it, but to just simply add keeping LOS for airbase is a bugfix.

Fair enough, that would cure it the vast majority of the time, and I suspect it would correct their behavior. Then it'd just be about getting them to follow their Piece orientations, and voila, they can be transports.

[lurker]

I doubt it would correct it (unless you did those tests when the buildings had no LOS). Individual LOS is barely used for anything.

[KDR_11k]

Eh, why would using Lua to move the units be wasteful, especially compared to COB with COB->Lua->COB bridges?

[Pressure Line]

Sensible behavior is that isAirBase transported units have LOS.

umm... im sure you meant to write "isfireplatform" because that is the correct tag.

[Argh]

Eh, why would using Lua to move the units be wasteful, especially compared to COB with COB->Lua->COB bridges?

Because I'd use the Transport's Pieces to actually move the Units around and turn them, and merely tell the Units that they're "moving" and trigger their walk cycles. It'd only be passing that stuff when I want to trigger a "movement period", however long that is- maybe they patrol endlessly, unless the building's taking damage, maybe they only move a little bit every few seconds, to keep up the illusion that they're alive.

It's simple and effective fakery, basically.

I have no interest in building a virtual movement system that would have to be tailored to the geometry of each building. If it's do that, or just have them stand there, that's a no-brainer. My time for blue-sky tech projects like that is pretty much exhausted. Doing it by piece manipulation, on the other hand, would be an easy, one-afternoon thing... if it all worked right. Which it doesn't.

umm... im sure you meant to write "isfireplatform" because that is the correct tag.

There are two tags: isAirBase (determines whether they can still shoot) and isFirePlatform (determines if user can select them).

I do not want players to be able to select the units once they're in a building- I tried that, and it would not be a good thing for players, it's too confusing and unintuitive.

[Pressure Line]

umm... im sure you meant to write "isfireplatform" because that is the correct tag.

There are two tags: isAirBase (determines whether they can still shoot) and isFirePlatform (determines if user can select them).

I do not want players to be able to select the units once they're in a building- I tried that, and it would not be a good thing for players, it's too confusing and unintuitive.

isAirBase determines whether planes can land on it and be repaired/refueled iirc. Ask smoth, he wrote the patch

[Argh]

Well, the Changelog, which we all know is the sole source of all truth, says, "-Added tag "isAirBase" to unit FBI file, sets if the units that are being transported will be stunned or not, defaults to 0."

When set, Units aren't stunned, so I assume it's doing what it says on the tin.

[Pressure Line]

http://spring.clan-sy.com/phpbb/viewtop ... =12&t=5704

Ok, as we know we need isairbase to have unit fire from a transport. This causes a problem because airbases also repair aircraft. So transports would get occupied by aircraft seeking repair.

So I sepperated the tags.

Isairbase will no longer be needed for transports to have units firing from them.

Instead they can use a tag:
isfireplatform

for that purpose purpose of denoting a transport is a platform a unit can fire weapons or it's nano-gun from.

u needs moar research.

EDIT and isairbase was added in 0.63b1. isfireplatform was added much later (OMG THE CODE GOT CHANGED!) lern to changelog.

[Argh]

You're right, but this is all still entirely irrelevant. Transport code, as it currently exists, doesn't work correctly for the intended purpose, because of all the other problems I've described. If it gets fixed, great, they can be transports, otherwise ooh, people will have to add a couple of customParams tags to their infantry in their games, if they want their infantry to be able to interact with the buildings.

Oh, and I sat down and rebuilt the test map. Took about 45 minutes to build all of this:

[Pressure Line]

You're right, but this is all still entirely irrelevant.

only if you consider aircraft landing on top of the building and being unable to get off because they refuse to if they haven't been repaired/refueled 'irrelevant.'

and yes, transported units should follow the rotation of the piece they are attached to, not just the rotation of the entire transport unit.

[Argh]

only if you consider aircraft landing on top of the building and being unable to get off because they refuse to if they haven't been repaired/refueled 'irrelevant.'

Yes, I do, because the buildings are no longer using any Spring transport code. It's all Lua, no Spring native code is being used.

As for future changes, yes, you're right, it'd be something like this:

isFireBase=1;
transportUnitsSelectable=0;
followPieces=1;

Are we done now? All I wanted to do was unveil a new feature of the gameplay, not have some silly debate about why it's not entirely perfect in every possible way.

Most commercial games just stick units in buildings onto static spots, or hide them and treat them as virtual representations (i.e., DoW's system with Imperial Guard, where the units occupying a building had nothing to do with what weapons fired from it). Any improvement on that would be welcome, but I'm not willing to develop an all-Lua technology to do that, as it would eat into time that would be better-spent elsewhere... so it's up to Lurker et al, if anybody wants to see guys running around on rooftops. I don't care a lot, either way, as it's basically just a visual effect, not really relevant to gameplay, and I should have just ignored Lurker's question, apparently

[Pressure Line]

I vaguely remember from testing last year that if a unit is set to be a repair pad, but doesnt have the pad piece defined in the script planes will just try to land on the base piece of the model (often with hilarious looking results)

the point im getting at is "if your unit is defined as a repair pad, planes will try to land on them whether or not that is the intended behaviour."

*edit* and from memory units in a transport with the isfireplatform tag active keep their los (but im not 100% on this one)

[Argh]

and from memory units in a transport with the isfireplatform tag active keep their los

Yes they do, but they're selectable as well, which is not a desired outcome.

[Pressure Line]

units do sometimes need help (ie micro) selecting targets... because a targets value in a given situation is not always directly related to its metal cost (which iirc is what Spring uses to determine targetting priority)

but heh, its your game :)