Air transport fix.

AF · Post by AF » 29 Jun 2006, 21:10

You are totally nto gettign what i am saying.

Your fix fixes the problem and opens up a new type of unit to modders.

But it doesnt fix it for old units unless their FBI's changed.

Thus I am not replacing your patch I am ADDING to it. I am not saying that what you did is wrong, I am adding to it so that it doesnt require modder to change the tags as they are already....

btw I've never used teamspeak, I already have enough cotnact details as ti is (msn, yahoo, gtalk,gmail,this forum,darkstars, lobby, aol/aim take your pick)

Rafal99 · Post by **Rafal99** » 29 Jun 2006, 21:19

AF wrote:if (UnitDef->builder == true){
// ITS A REPAIR PAD
}else{
//IT'S A TRANSPORT!!!!
}

It doesn't seem like a good idea. What with unit which is a transport but can also build things? It doesn't mean it is a repair pad.
I think Smoth's solution is much better.

AF · Post by AF » 29 Jun 2006, 21:33

the problem si your seeing them as 2 different solutions, they're nto seperate solutions.

Mine is meant to go alongside smoth's replacement, it isnt meant to replace it.

All ti does is prevent existing untis from having to change their TDF's to fix the issue.

It doesnt rpevent you from using smoths tag or changing how smoths tag works.

If smoths tag is not defined and isairbase==1 then it assumes this units TDF was made before the patch smoth made was posted here. So it dynamically assigns smoths tag.

there is nothign stopping you deining both tags and getting transports that have air repair pads, or having any combination e.g.
isAirBase=1;
isfireplatform=1;

or

isAirBase=0;
isfireplatform=1;

or
isAirBase=1;
isfireplatform=0;

What I'm sayign is that if you just define
isAirBase=1;
by itself without the isfireplatform then it assumes the TDF was written before the isfireplatform tag was added, and attempts to fix the problem dynamically.

My change does not affect units that use smoths new tag at all

smoth · Post by **smoth** » 29 Jun 2006, 21:46

AF, you don't need the //$$ that is just my hottag method so I know what I changed... my initials are ss.

Rafal99 · Post by **Rafal99** » 30 Jun 2006, 00:12

Ok, now i understand what you (AF) meant. I have modified Smoth's patch so it adds isFirePlatform tag but keeps compatibility with isAirBase tag. It also fixes, so planes won't try to land on transports with isAirBase=1 tag anymore.

Code: Select all

edit: Patch code was posted here, but version posted 3 posts below is better. :)

What do think about it now?

Caydr · Post by **Caydr** » 30 Jun 2006, 00:21

There are less than 10 units in any mod to date that would need changing, AF. Don't be so dramatic.

AF · Post by AF » 30 Jun 2006, 00:26

If something can go wrong it will go wrong.

smoth · Post by **smoth** » 30 Jun 2006, 00:34

How about I don't make any patchs and you people can do it. Obviously I am not freakin needed.

Rafal99 · Post by **Rafal99** » 30 Jun 2006, 00:36

Ok, i have found a way to do the same effect with smaller amount of changes.

Updated patch:

Code: Select all

Index: D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitDef.h
===================================================================
--- D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitDef.h	(revision 1552)
+++ D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitDef.h	(working copy)
@@ -172,7 +172,8 @@
 	float loadingRadius;	//for transports
 	int transportCapacity;
 	int transportSize;
-	bool isAirBase;// should the carried units still be able to shoot?
+	bool isAirBase;
+	bool isFirePlatform; // should the carried units still be able to shoot? 
 	float transportMass;
 
 	bool canCloak;							//if the unit can cloak
Index: D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitDefHandler.cpp
===================================================================
--- D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitDefHandler.cpp	(revision 1552)
+++ D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitDefHandler.cpp	(working copy)
@@ -292,6 +292,12 @@
 	tdfparser.GetDef(ud.transportSize, "0", "UNITINFO\\transportsize");
 	tdfparser.GetDef(ud.transportCapacity, "0", "UNITINFO\\transportcapacity");
 	ud.isAirBase=!!atoi(tdfparser.SGetValueDef("0", "UNITINFO\\isAirBase").c_str());
+	ud.isFirePlatform=!!atoi(tdfparser.SGetValueDef("0", "UNITINFO\\isfireplatform").c_str());
+	if (ud.isAirBase && !ud.builder) {
+		ud.isAirBase = false;
+		ud.isFirePlatform = true;
+	}
+
 	ud.loadingRadius=220;
 	tdfparser.GetDef(ud.transportMass, "100000", "UNITINFO\\TransportMass");
 
Index: D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitTypes/TransportUnit.cpp
===================================================================
--- D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitTypes/TransportUnit.cpp	(revision 1552)
+++ D:/xxxxx/TA Spring Source/trunk Source/rts/Sim/Units/UnitTypes/TransportUnit.cpp	(working copy)
@@ -94,7 +94,7 @@
 	unit->AddDeathDependence (this);
     unit->transporter = this;
 	unit->toBeTransported=false;
-	if (!unitDef->isAirBase)
+	if (!unitDef->isFirePlatform)
 		unit->stunned=true;	//make sure unit doesnt fire etc in transport
 	unit->UnBlock();
 	loshandler->FreeInstance(unit->los);
@@ -126,7 +126,7 @@
 			unit->transporter=0;
 			if(CTAAirMoveType* am=dynamic_cast<CTAAirMoveType*>(moveType))
 				unit->moveType->useHeading=true;
-			unit->stunned=false; // de-stun in case it isairbase=0
+			unit->stunned=false; // de-stun in case it isfireplatform=0
 			unit->Block();
 			loshandler->MoveUnit(unit,false);
 			unit->moveType->LeaveTransport();

AF · Post by AF » 30 Jun 2006, 00:36

Us two wouldnt be aware of it if you handt posted the first patch, I wouldnt have even known where to look to solve it.

smoth · Post by **smoth** » 30 Jun 2006, 00:38

why did it get this reaction...? no other patch was treated this way. what is it.. DID I sound arrogant or something?

AF · Post by AF » 30 Jun 2006, 00:44

because of the reaction you all gave to my addition.

React liek that and you'll get a similar reaction back.

smoth · Post by **smoth** » 30 Jun 2006, 00:46

AF wrote:because of the reaction you all gave to my addition.

React liek that and you'll get a similar reaction back.

what addition?

What reaction, I have NO IDEA what you are talking about.

AF · Post by AF » 30 Jun 2006, 00:49

I added to it, yet you all ahd a go at me for replacing your code when infact i was adding to it.

Remember? The bit that dynamically set the value fo your tag if the user didnt define it based on wether it was a buidler or not?

Denying something happened wont make ti go away, it just paints a picture fo you being ignorant.

PS :: Teamspeak.org gives me timedout delayed response emssages

j5mello · Post by **j5mello** » 30 Jun 2006, 00:54

AF wrote:because of the reaction you all gave to my addition.

React liek that and you'll get a similar reaction back.

eye for an eye we have all heard that before.

the point is (like caydr said) only like 10 units (in all of spring, i think) need to be changed its not that big of a problem. XTA can be updated with new spring version, i think from his response that Caydr is willing to change his units, uhh, who else... TLL maybe, 1944 isn't out, E&E doesn't use it, im sure there are a few others but really its not going to be that hard.

smoth · Post by **smoth** » 30 Jun 2006, 00:55

AF wrote:I added to it, yet you all ahd a go at me for replacing your code when infact i was adding to it.

Remember? The bit that dynamically set the value fo your tag if the user didnt define it based on wether it was a buidler or not?

AF wrote:Denying something happened wont make ti go away, it just paints a picture fo you being ignorant.

You can call me names or whatever but that doesn't make you right.

By keeping the old unit functionality we still have aircraft landing on transports. Which is bad because the unit will be broken still. We have to change the old code to correct those old units. That was the whole point of the patch.

AF wrote:PS :: Teamspeak.org gives me timedout delayed response emssages

weird

AF · Post by AF » 30 Jun 2006, 00:56

I was replying to smoth nto caydr, and I'm aware of that.

However you're not going to suggest we scrap the patch and carry on as we are currently?

Rafal99 · Post by **Rafal99** » 30 Jun 2006, 01:00

smoth wrote:By keeping the old unit functionality we still have aircraft landing on transports.

Rafal99 wrote: I have modified Smoth's patch so it adds isFirePlatform tag but keeps compatibility with isAirBase tag. It also fixes, so planes won't try to land on transports with isAirBase=1 tag anymore.

Noone reads what i wrote.

smoth · Post by **smoth** » 30 Jun 2006, 01:30

Rafal99 wrote:
Rafal99 wrote: It also fixes, so planes won't try to land on transports with isAirBase=1 tag anymore.
Noone reads what i wrote.

isairbase=1 is for planes to land on the platform.

Rafal99 · Post by **Rafal99** » 30 Jun 2006, 01:44

smoth wrote:isairbase=1 is for planes to land on the platform.

Yes, i know, but

Rafal99 wrote:+ if (ud.isAirBase && !ud.builder) {
+ ud.isAirBase = false;
+ ud.isFirePlatform = true;
+ }

This part of code means that unit with isAirBase=1 but without Builder=1 won't be treated as air repair pad. All current air repair pads have Builder=1 tag, and all transports don't have this tag, so it will all work well.
Although if you want to make a transport with builder abilities, which isn't air pad, then you can only use IsFirePlatform=1, not isAirBase=1.

Spring RTS Engine

Air transport fix.