make a transportation better

[manolo_]

hi,

here the link:
http://xta.darkstars.co.uk/forums/viewt ... p=479#p479

sum: transportation via hovertransporter is strange, could u fix it, so that the unit is really inside of the trans nstead of 100meter under the gorund?

[Kloot]

It is not the engine's decision where to draw units that are being transported, "u" have to fix the transporter's BOS script to position units properly (ex. at dummy model pieces). For transports with closed bays, just tell their transportees not to draw themselves at all.

[AF]

Incorrect.

This has always been the case with spring. I had bgu reports showing EE land transports where I had selected using a rectangle with the mouse and I could see the selection squares of the loaded units underneath far below the map.

On one map I even loaded a commander into a sea transport and selected it using this trick and proceeded to reclaim the transport destroying my commander. Thus a fix was given that prevented commands being given to these units but the units are still there.

They're not being hidden, they're just being moved somewhere way below the map. It has always been this way, and it is true of all transports that do not show the unit being transported.

[Kloot]

Perhaps you should read the code responsible before correcting people:

Code: Select all

void CTransportUnit::Update() {
	CUnit::Update();
	std::list<TransportedUnit>::iterator ti;
	for (ti = transported.begin(); ti != transported.end(); ++ti) {
		float3 relPos;
		if (ti->piece >= 0) {
			relPos = localmodel->GetPiecePos(std::max(0, ti->piece));
		} else {
			relPos = float3(0.0f, -1000.0f, 0.0f);
		}
		float3 pos = this->pos + (frontdir * relPos.z) +
					(updir    * relPos.y) +
					(rightdir * relPos.x);

		ti->unit->pos = pos;
		ti->unit->UpdateMidPos();
		...
	}
}

Where ti->piece is provided by the ATTACH opcode for ticking threads:

Code: Select all

	case ATTACH:
		r2 = POP();
		r1 = POP();
		owner->AttachUnit(r2, r1);
		break;

"owner" being a COB instance in this context:

Code: Select all

void CCobInstance::AttachUnit(int piece, int u)
	// -1 is valid, indicates that the unit should be hidden
	if ((piece >= 0) && (!unit->localmodel->PieceExists(piece))) {
		GCobEngine.ShowScriptError("Invalid piecenumber for attach");
		return;
	}

	CTransportUnit* tu = dynamic_cast<CTransportUnit*>(unit);

	if (tu && uh->units[u]) {
		// logOutput.Print("attach");
		tu->AttachUnit(uh->units[u], piece);
	}
}

Which calls:

Code: Select all

CTransportUnit::AttachUnit(CUnit* unit, int piece) {
	...
	TransportedUnit tu;
	tu.unit = unit;
	tu.piece = piece;
	...
	transported.push_back(tu);
	...
}

And just to wrap this up, a sample execution trace for XTA's Arm Bear hover-transport loading the Commander (note the -1 appearing on the second tick as the loader boom retracts, since this is an original Cavedog script any transport units in other mods that use it will also be affected):

Code: Select all

	CTransportCAI::ExecuteLoadUnits()

	// grappler picks up the comm
	CCobThread::Tick(), ATTACH opcode, unit number = 3969, piece = 18
	CCobInstance::AttachUnit(int piece = 18, int unit = 3969)
	CTransportUnit::AttachUnit(CUnit* 0x8e2f140, int piece 18)

	// grappler gets stowed away
	CCobThread::Tick(), ATTACH opcode, unit number = 3969, piece = -1
	CCobInstance::AttachUnit(int piece = -1, int unit = 3969)
	CTransportUnit::AttachUnit(CUnit* 0x8e2f140, int piece -1)

Next time, kindly do your research instead of wasting everyone's time.

PS. you might also be interested to know for future reference that things work differently where aerial transports are concerned:

Code: Select all

CTransportCAI::ExecuteLoadUnits() {
	...
	if (CTAAirMoveType* am = dynamic_cast<CTAAirMoveType*>(owner->moveType)) {
		args.push_back((int)(unit->model->height * 65536));
		owner->cob->Call("BeginTransport", args);

		args2.push_back(0);
		args2.push_back((int)(unit->model->height * 65536));
		owner->cob->Call("QueryTransport", args2); // get the link piece

		((CTransportUnit*) owner)->AttachUnit(unit, args2[0]);
	} else {
		std::vector<int> args;
		args.push_back(unit->id);
		owner->cob->Call("TransportPickup", args, ScriptCallback, this, 0);
	}
	...
}

Thus a fix was given that prevented commands being given to these units but the units are still there.

I know, I wrote it.

[AF]

Im sorry but you've obviously overlooked the very piece of code which causes this bug right in front of you!

What your describing is one way transportation works but it is not the only way! There were 2 methods used in TA. One for aircraft and one for land/sea/hover, the difference being in aircraft the unit was attached to a piece and visible, and in hover/sea/land the unit was attached to a piece and then 'hidden'.

So while you accurately described the process inc ob of moving a transported unit, you did not see the 'hidden' state at all.

Lets take a closer look:

Perhaps you should read the code responsible before correcting people:

Code: Select all

void CTransportUnit::Update() {
	CUnit::Update();
	std::list<TransportedUnit>::iterator ti;
	for (ti = transported.begin(); ti != transported.end(); ++ti) {
		float3 relPos;
		if (ti->piece >= 0) {
			relPos = localmodel->GetPiecePos(std::max(0, ti->piece));
		} else {
			relPos = float3(0.0f, -1000.0f, 0.0f);
		}
		float3 pos = this->pos + (frontdir * relPos.z) +
					(updir    * relPos.y) +
					(rightdir * relPos.x);

		ti->unit->pos = pos;
		ti->unit->UpdateMidPos();
		...
	}
}

Where ti->piece is provided by the ATTACH opcode for ticking threads:

and again

Code: Select all

		if (ti->piece >= 0) {
			relPos = localmodel->GetPiecePos(std::max(0, ti->piece));
		} else {
			relPos = float3(0.0f, -1000.0f, 0.0f);
		}

See here? you totally missed the bit of code that generates the issue I described! In fact we now know that the unit is exactly 1000 points below the transporting unit!

I can now theorize from this that if a land or hover transport was picked up by an air transport with a cruise altitude of greater than 1000 then we would see the transported unit hover over the map!

This is basic common knowledge of BOS scripting that has been exploited at length by zwzsg and others who would know far more and he may even know the reasoning behind the -1k value which could be because OTA used the same mechanism and that mechanism was exploited by cob scripts? I remember this vaguely from the TAU stargate unit threads..

[Kloot]

I have not missed anything, otherwise I wouldn't have stated "the code responsible" (ie., responsible for drawing transported units below the map). The entire point is that the transporter's script has the final say in the drawing location by specifying a piece >= 0 even if it is a ground transport, as mentioned in my first post:

It is not the engine's decision where to draw units that are being transported

Incorrect.

Now, why the choice was made for offsetting pos by (0, -1000.0, 0) instead of simply not drawing the unit when the piece < 0, you'll have to ask whoever wrote that piece of code (Yeha?), but I don't consider it a bug (more like an aesthetic wart that may have historical reasons like other engine details).

One for aircraft and one for land/sea/hover, the difference being in aircraft the unit was attached to a piece and visible, and in hover/sea/land the unit was attached to a piece and then 'hidden'

Spring replicates both as you can tell, but gives you more freedom with the hover/sea/land case (except the OTA scripts borrowed by most *TA mods obviously don't exploit it).

[Argh]

Ok... without getting into the various controversial things... my main complaint with this is that attach-unit to piece -1 doesn't result in the unit being sent somewhere where it can't be seen at all.

I'd send them to 1000000, 1000000, 1000000 - one million units LEFT, UP, BACK. Well off the map, for even the largest maps. So high that nobody will ever see them, period.

Sending it to -1000 is bad, because it results in visual problems of various sorts with Widget displays, etc.

Could this be addressed?

[REVENGE]

Couldn't the code be modified to not render the unit being transported?

[Pxtl]

Ok... without getting into the various controversial things... my main complaint with this is that attach-unit to piece -1 doesn't result in the unit being sent somewhere where it can't be seen at all.

I'd send them to 1000000, 1000000, 1000000 - one million units LEFT, UP, BACK. Well off the map, for even the largest maps. So high that nobody will ever see them, period.

Sending it to -1000 is bad, because it results in visual problems of various sorts with Widget displays, etc.

Could this be addressed?

if you took the unit away from the transport's horizontal coords, I'd worry about units that may be pursuing it changing course and running off to middle-of-nowhere, or similar bugs occurring. Sure, they shouldn't do that - they probably notice that the unit is being transported... but somewhere in the code or the Lua, there's a script that misses that check and would get horribly confused by things existing out there.

If they're attached to -1, they shouldn't exist in the game world. End of story.

[lurker]

The entire point is that the transporter's script has the final say in the drawing location by specifying a piece >= 0 even if it is a ground transport, as mentioned in my first post

...

more freedom with the hover/sea/land case (except the OTA scripts borrowed by most *TA mods obviously don't exploit it).

That's technically true that you can tell spring what position to render, but you can't make get it to not be rendered with a number >=0 either; you just get a cob error.

[Kloot]

set ALPHA_THRESHOLD 255;

Or as people are so fond of saying, "use Lua".

[Argh]

Setting the ALPHA_THRESHHOLD will not deal with the fact that the engine still sees a Unit at 0,-1000,0, and therefore things like Widgets will continue to draw status, etc.

Meh, I'll just move the piecenum used for attachment to some ridiculous distance, then move it back to home during Killed() so that it won't bork, hopefully... it just irritates me that we can't just declare a Unit is "off the board" entirely.

[Kloot]

Of course it won't, AT is a trick just as the -1000 translation is.

and therefore things like Widgets will continue to draw status, etc.

Then use SetUnitNoDraw.

t just irritates me that we can't just declare a Unit is "off the board" entirely.

Because units _aren't_ off the board when transported, the engine
still has to track them for all sorts of purposes (hence they cannot
NOT exist in the game world, you can get them out of sight but not
out of mind).

[AF]

They're at -1k for a reason and changing that may break the more exotic scripts like the stargate units.

One other issue is that they're still selectable. Either way this is a bug. The expected behavior is hidden but it is not. You suggested we fix this via a kludge and go back through all the scripts and modify them accordingly.

Has anybody tested my theoretical test with the airtransport? This could even cause other issues such as pushing other units out of the way underneath it, but tests need to be done.