Unit limit

[tow_dragon]

Small reqest: function in GlobalAI interface that returns unit limit. It is quite important for NanoBlobs support in new TSI. Supposing that it is 500 isn't good.

[Kloot]

That would indeed be useful, although a small patch to CAICallback::GetValue() might perhaps be better than a new function.

Edit: ok, done.

[AF]

No need.

Open the file script.txt via the AI callback, load it into a TdfParser or CSunParser class and read the value for yourself.

[AF]

Despite kloots recent patch to add AIVAL_UNIT_LIMIT callback to the AI interface, it is indeed totally unnecessary unless your running via spring.exe(a small percentage of users). To get the same results right here and now without waiting for spring 0.75/74b4, you can use the follow snippet.

Code: Select all

int GetMaxUnits(){
	TdfParser p;
	p.LoadFile("script.txt");
	int n;
	p.GetDef(n,"500","GAME\\MaxUnits");
	return n;
}

If you dont have or want to sue TdfParser, the old CSunParser veylon ported will work, just repalce TdfParser p; with CSunParser p;

[Kloot]

That is a rather hackish detour to make just for getting a gamestate variable.

[AF]

It works, and it has worked for many many spring versions already gone by, and doesnt depend on an everchanging interface, nor does it require me to wait for the next release of spring.

Infact this sort of technique was used to read starting positions by me veylon and krogothe in KAI NTai and OTAI to great effect.

Code: Select all

	TdfParser cq(G);
	cq.LoadFile("script.txt");
	int nt;
	cq.GetDef(nt,"1","GAME\\NumTeams");

	TdfParser MP(G);
	MP.LoadFile(string("maps\\")+string(G->cb->GetMapName()).substr(0,string(G->cb->GetMapName()).find('.'))+".smd");
	vector<string> sections = MP.GetSectionList("MAP\\");
	for(int n=0; n<nt; n++){
		float3 pos= UpVector;
    	MP.GetDef(pos.x, "-1", string("MAP\\TEAM") + to_string(n) + "\\StartPosX");
    	MP.GetDef(pos.z, "-1", string("MAP\\TEAM") + to_string(n) + "\\StartPosZ");
		if(G->Map->CheckFloat3(pos)){
			start_pos.push_back(pos);
			G->Actions->AddPoint(pos);
		}
    }

[Kloot]

You could simpy have submitted an interface patch yourself to (optionally) directly read that data, it's not like it would have required you to rewrite all of NTAI.

[AF]

No but it would have required me to spend an hour re-organising my setup to accomodate 2 installs, and then ontop of that force me to wait possibly months for the spring devs to release a version of spring with the patch.

Whereas I can get immediate results and share them without lugging around a custom VS2003 build of spring.exe.

[Kloot]

All such a patch would mean for you in terms of "reorganizing" your setup would be:

1) removing/deactivating some old code upon a new release of Spring
2) inserting/activating some new code upon a new release of Spring

Which would:

1) take at most 5 minutes to achieve
2) be entirely optional due to the nature of the patch

I don't see what the big deal is, basically.

[AF]

Thats not what I meant. I was referring to writting a patch not using your addition to the interface.

I'd have to set up 2 NTai setups and 2 SVN setups, one each for /trunk and one for modified trunk to write the patch in, so thats 2 Spring svns, 1 NTai, and 1 NTai to test the patch with. Considering my existing setup is messy at best...

[Kloot]

It's really not that much effort to prevent messy situations from developing in the first place. Here's what I did to create this patch, for instance:

1) updated my local trunk copy to the latest revision
2) wrote the patch
3) moved KAI from my local tag copy to the trunk copy
4) added a few lines of code to KAI to use the new callback
5) tested the patch with KAI with a few different unit limits
6) submitted it
7) moved KAI back to my tag copy and undid the code additions

All in all, I spent maybe half an hour on it, tops. And only the last step would be fundamentally different for you, as you could simply comment out the new code and re-enable it at the next release of Spring. The bottom line is that you only ever need NTAI setup to write one, whether it's a mess or not.

[AF]

If I were to add stuff to the interface, it wouldnt be stuff to prevent work arounds, stuff which would end up as a core component. Such as directory listings in the VFS and the systems that would depend on it, enemy unit creation in LOS, deaths of features etc, that any system depending on them would falter when they where removed.

This is a problem as testing things usually means implementing the system and that usually requires architectural changes. My siuation doesnt make it easy, and I havent much experience doing anything other than updating or commiting via svn or looking at websvn.