Handling strings

Discuss the new AI features ("NoAI") introduced into OpenTTD 0.7, allowing you to implement custom AIs, and the new Game Scripts available in OpenTTD 1.2 and higher.

Moderator: OpenTTD Developers

Post Reply
Hephi
Engineer
Engineer
Posts: 72
Joined: 25 Oct 2009 09:56
Location: Belgium

Handling strings

Post by Hephi »

Hi,

I want to compare a certain string to another with an IF statement. Normally this causes no problems
but this time the string provided by the AIEngine.GetName(eng) function starts with "?!" characters.
Making an if("?!EngineName" == AIEngine.GetName(eng)) will not return true where if we only look
at the printed output they're exactly the same.

The ?! characters are there because the GRF shows little symbols before the name in the enginelist (I think).
So if I can't compare them the 'easy' way how should I best handle this. Is there an easy way to split the string
and drop the two first characters? I've looked into it a bit but I'm not familiar with all the C coding and couldn't
find any good example.

Thanks.
--------------------------------------------------
MailAI, a casual postal service for openTTD.
--------------------------------------------------
Yexo
Tycoon
Tycoon
Posts: 3663
Joined: 20 Dec 2007 12:49

Re: Handling strings

Post by Yexo »

First of I want to warn you that comparing a name you get from any of the *GetName api functions is not reliable. Most of them can be translated and the value you'll get depends on the current language. They're only meant to be used as debug output.

As can be seen in the squirrel documentation squirrel has a slice function for strings. So try something like this:

Code: Select all

"my string".slice(2)
Hephi
Engineer
Engineer
Posts: 72
Joined: 25 Oct 2009 09:56
Location: Belgium

Re: Handling strings

Post by Hephi »

Yexo wrote:First of I want to warn you that comparing a name you get from any of the *GetName api functions is not reliable. Most of them can be translated and the value you'll get depends on the current language. They're only meant to be used as debug output.
Good point, didn't think about that... though I'm hoping that engine names like BM64 are the same for every language.

And thx for the slice(), it's not in the squirrel documentation that I use (when I searched for it, it was used in an example though: string_element.slice(val.begin,val.end))
--------------------------------------------------
MailAI, a casual postal service for openTTD.
--------------------------------------------------
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Handling strings

Post by planetmaker »

Hephi wrote:
Yexo wrote:First of I want to warn you that comparing a name you get from any of the *GetName api functions is not reliable. Most of them can be translated and the value you'll get depends on the current language. They're only meant to be used as debug output.
Good point, didn't think about that... though I'm hoping that engine names like BM64 are the same for every language.
I can assure you that it is NOT the case, at least not for all sets and all engines.

Class 4200 --> Baureihe 4200
Railbus XY --> Schienenbus XY
Whatever Tram --> Whatever Straßenbahn
Bulog coal truck -> Bulog Kohlelaster
...
etc pp

Your assumption that names of engines remain the same breakes easier than you might assume.

Don't target your AI for a specific train set, but rather query the stats of the different engines and go by that.
User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Re: Handling strings

Post by Zuu »

Assuming you are trying to identify wagons/engines with "strange" rules like requires break wagon etc. These don't exist in the NewGRF specs as constructs other than that a NewGRF returns false on a callback. Eg. "You can't start this train". And to OpenTTD it may at best send a error-string message so users understand that they need a break wagon.

What you could turn your problems into is a feature request for something like a protocol for NewGRFs to specify these errors. Eg:
  • Requires wagon type X
  • Wagon type Y is not allowed (with this engine)
  • Wrong number of wagons
That way NewGRF authors can provide AI writers with more information so that we can support more "weird" behaviour without limiting the specs too much to certain types of usages. (compared to having the specs define the break wagon concept)
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Hephi
Engineer
Engineer
Posts: 72
Joined: 25 Oct 2009 09:56
Location: Belgium

Re: Handling strings

Post by Hephi »

Ok, so when my 'normal' wagonfinder function returns something I cannot use I use the following as a fail safe mechanism.

Code: Select all

                local new_wagon = "my selected wagon from the 'main' wagon selection function"
		local source = AIVehicle.BuildVehicle(depot, new_wagon);
		local moved = false;
		if(source != null) moved = AIVehicle.MoveWagon(source,0,new_veh,0);
		if(!moved)
		{	
			AIVehicle.SellVehicle(source);
			new_wagon = null;
			foreach(wagon, _ in RoutePlanner.GetWagonList()) //this returns only useable wagons (except offcourse GRF problems)
			{
				source = BankManager.BuildVehicle(depot, wagon);
				if(source != null) moved = AIVehicle.MoveWagon(source,0,new_veh,0);
				if(moved)
				{
					new_wagon = wagon;
					break;
				} else
				{
					AIVehicle.SellVehicle(source);	
				}
			}	
		}
//after this just use new_wagon, it will either be the chosen engine from the normal code or the first one of the wagon_list that fits for this engine
--------------------------------------------------
MailAI, a casual postal service for openTTD.
--------------------------------------------------
Post Reply

Return to “OpenTTD AIs and Game Scripts”

Who is online

Users browsing this forum: No registered users and 5 guests