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.
Handling strings
Moderator: OpenTTD Developers
Handling strings
--------------------------------------------------
MailAI, a casual postal service for openTTD.
--------------------------------------------------
MailAI, a casual postal service for openTTD.
--------------------------------------------------
Re: Handling strings
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:
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)
Re: Handling strings
Good point, didn't think about that... though I'm hoping that engine names like BM64 are the same for every language.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.
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.
--------------------------------------------------
MailAI, a casual postal service for openTTD.
--------------------------------------------------
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: Handling strings
I can assure you that it is NOT the case, at least not for all sets and all engines.Hephi wrote:Good point, didn't think about that... though I'm hoping that engine names like BM64 are the same for every language.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.
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.
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: Handling strings
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:
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
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
Junctioneer (a traffic intersection simulator)
Re: Handling strings
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.
--------------------------------------------------
MailAI, a casual postal service for openTTD.
--------------------------------------------------
Who is online
Users browsing this forum: No registered users and 10 guests