Getting TLL to work

[colorblind]

In light of recent discussion of a third race, I thought it a good idea to get The Lost Legacy working with Spring. Because why would you develop a third race when you've already got one lying around?

I haven't played with TLL before so I don't know if it's any good. But just from the unit stats it looks very promising. Honestly, when you have a sight tower (giving you more LOS) called 'Hasselhof' you're on the right track.

Of course, if it is to be played with online the whole thing would have to be balanced to match the XTA flavour. But that shouldn't be too hard.

So I've downloaded the files, extracted and merged with the XTA content and set the side parameter in the script.txt file to "side=ttl" and gave it a go. Didn't work.

Can anyone tell me how it could work? I did change the \\GAMEDATA files etc, but the TLL commander just wouldn't appear. Any help is appreciated.

[Min3mat]

UGH xta flavour makes me SICK ;P

[Torrasque]

Min3mat : I think everybody on this forum know you don't like XTA, please stop.

colorblind : I can't help you. I can just say that the tll is really a good 3rd pary race. It don't look odd compared to core and arm, have similarity in the build tree, but have it's own feeling. It's really a fun race.

[AF]

The arm and core are bhardcoded into the commanders script.
To access a 3rd race you need to change the race side in the script that you feed into TASpring so that you're not arm or core.

Also, there's a limited nubmer of textures in spring which was pointed out by buggi when he tried to load TLL into spring. I'm sure there's a thread on this by him somewhere in this forum.

[colorblind]

I can't find the thread you're talking about. Could you point it out to me?

And for the hardcoding: you're wrong Alantai. The CommanderScript.cpp loops through every side in GAMEDATA\\SIDEDATA.TDF and compares it to the one in the script.txt file ... so it should work in principle.
Although I'm not so sure how line 42

Code: Select all

string sideName=p.SGetValueDef("arm",string(sideText)+"\\name");

and line 45

Code: Select all

string cmdType=p.SGetValueDef("armcom",string(sideText)+"\\commander");

exactly work. The "arm" parts are a bit misleading ...

But the texturelimit could be why the TTL commander didn't appear. No textures, nothing to render. Or am I being too naive? Should Spring have crashed with an error instead?

[Gnomre]

Take a look in a sidedata file, color:

Code: Select all

[SIDE0]
	{
	name=Arm;
	commander=ARMCOM;
	}
[SIDE1]
	{
	name=Core;
	commander=CORCOM;
	}
[CANBUILD]
	{
	}

The source you quoted there just pulls out the name and commander strings there. So for TLL, you would need a sidedata that looks something like this:

Code: Select all

[SIDE0]
	{
	name=Arm;
	commander=ARMCOM;
	}
[SIDE1]
	{
	name=Core;
	commander=CORCOM;
	}
[SIDE2]
	{
	name=TLL;
	commander=TLLCOM;
	}
[CANBUILD]
	{
	}

Obviously change the name of the TLL commander if necessary, since I'm not familiar with their naming scheme.

[colorblind]

Perhaps I wasn't all too clear in my first my: I did that already. Didn't work. But thanks for pointing it out anyway.

[AF]

It might ahve changed since I last saw it then.

Try changing the order, the commanders script onyl has 2 players, pawned AI and you. Unless thats changed too. So you'll be whatever the first race def is int he file and the enemy the second aka arm then core.

[Buggi]

You'll never ever get all of the textures to load. Some of them are massive ( > 300 pixels).

Even when I did get all the textures small enough the game still crashed because I don't think it could handle the textures.

Ideally there should be a texture "plane" for each "side" but that would take a considerable amount of work.

-Buggi

[Dragon45]

The side's name is TLL, not TTL... maybe that's a part of the problem?

[colorblind]

Oops . Damn those typos ...

Buggi's right, it's really a texture problem. I did some digging and found that all of the TLL textures fit on 9494433 squared pixels. That's approximately 3081*3081 pixels, way bigger than the textureplane Spring currently supports (i.e. 2048*2048).

The textures are being handled in TextureHandler.cpp, so I naively changed lines 81-94 from

Code: Select all

	if(totalSize<1024*1024){
		bigTexX=1024;
		bigTexY=1024;
	} else if(totalSize<1024*2048){
		bigTexX=1024;
		bigTexY=2048;
	} else if(totalSize<2048*2048){
		bigTexX=2048;
		bigTexY=2048;
	} else {
		bigTexX=2048;
		bigTexY=2048;
		MessageBox(0,"To many/large unit textures to fit in 2048*2048","Error",0);
	}

to

Code: Select all

	if(totalSize<1024*1024){
		bigTexX=1024;
		bigTexY=1024;
	} else if(totalSize<1024*2048){
		bigTexX=1024;
		bigTexY=2048;
	} else if(totalSize<2048*2048){
		bigTexX=2048;
		bigTexY=2048;
	} else if(totalSize<3072*2048){
		bigTexX=3072;
		bigTexY=2048;
	} else if(totalSize<3072*3072){
		bigTexX=3072;
		bigTexY=3072;
	} else if(totalSize<3072*4096){
		bigTexX=3072;
		bigTexY=4096;
	} else if(totalSize<4096*4096){
		bigTexX=4096;
		bigTexY=4096;
	} else {
		bigTexX=4096;
		bigTexY=4096;
		MessageBox(0,"To many/large unit textures to fit in 4096*4096","Error",0);
	}

With this change Spring seems to be able to handle all the textures, but it nevertheless crashes the moment you enter the game. It gives "no such cursor: cursorreclamate" and "couldn't find armtag" as error msgs in the infobox (see the image below).
So it could be very well that my approach is a bit to simplistic. Or it could be that the TLL files arent yet fully in a format that Spring understands.

[Gnomre]

I may very well be talking out of my ass here, but I think there's probably a very good reason for 2048 squared which makes it very hard to increase the limit... I think (but don't take my word on it) most graphics cards only support up to a 2048 pixel texture sheet, so any more and the card can't handle it. The only way to solve this that I can think of would be to create multiple sheets in the game, but that's probably both difficult to code and to manage in game.

I may be totally wrong though. *Prepares to be lectured*