## News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

## More variation in inner-city stop names

Started by archchancellor, September 01, 2011, 05:38:13 PM

0 Members and 1 Guest are viewing this topic.

#### archchancellor

Hi,

I've been a happy experimental player for some time now, but the lack of variation in stop names in cities is something that has bothered me for some time. I've now finally found some time and hacked up a small addition to the way these names are generated.

What the change does is add support for a roadlist_LANG.txt file in the texts directory of the pak (I've attached a sample). Just as with the citylist files, each line is a single name, which is used when generating the name of a stop to create a bit more variety. The additional road names are only used within the city, not outside (so no "London High Street Station" in the middle of nowhere. Factory and monument names are tried (and used) first and only if there aren't any or they have already been used will the roadlist be consulted. If no roadlist file is available, then the system falls back to the current naming scheme. You can give it a try here:

https://github.com/scmmmh/simutrans-experimental/tree/streetnames

All feedback much appreciated. This is my first excursion into simutrans programming and I also haven't done any c++ work for some time.

I was thinking it might be worth having a more complex and capable system, which might distinguish names for inner-city, suburbs, country-side or something similar. However I'm not entirely sure it would be worth it. Any thoughts?

Happy routing,
Mark

#### Carl

This sounds like a great idea!

#### Dwachs

Very nice first post!

I would like to see this ported back to simutrans standard, too. No restriction to simutrans-experimental needed.

I commented on github, too.
Quote
I was thinking it might be worth having a more complex and capable system, which might distinguish names for inner-city, suburbs, country-side or something similar. However I'm not entirely sure it would be worth it. Any thoughts?
This would be necessary, as well, as stops at the outside of the city already receive those "Xsuburb" names. For your patch, this would mean to maintain three lists, like road_names_center, road_names_suburb, road_names_extern. In the txt-file these names could be seperated by a line consisting of minus signs like

main street
more center names
---
suburb west
more suburb names
---
out and away
more extern names

Parsley, sage, rosemary, and maggikraut.

#### archchancellor

Quote from: Dwachs on September 01, 2011, 06:11:41 PM
I would like to see this ported back to simutrans standard, too. No restriction to simutrans-experimental needed.

That sounds sensible. I'll get it into a shape that everybody is happy with for sim-exp and then we can look into porting it back?

Quote from: Dwachs on September 01, 2011, 06:11:41 PM
I commented on github, too.This would be necessary, as well, as stops at the outside of the city already receive those "Xsuburb" names. For your patch, this would mean to maintain three lists, like road_names_center, road_names_suburb, road_names_extern. In the txt-file these names could be seperated by a line consisting of minus signs like

main street
more center names
---
suburb west
more suburb names
---
out and away
more extern names

That looks good. I'll have a bash at that either this evening or tomorrow.

Regarding the git-hub comment, the file parsing code will need to be updated anyway and I'll take the pointless block of code out then.

Mark

#### The Hood

This is a great idea - hope it gets included.

#### archchancellor

Hi,

I've updated the code at https://github.com/scmmmh/simutrans-experimental/tree/streetnames and it now supports urban/suburban/rural halt-names. I've attached an updated sample roadlist_en.txt.

All suggestions as to how to improve this code are welcome.

Happy building,
Mark

#### jamespetts

Mark,

welcome to the forums! Apologies for not having replied earlier on this topic: I am afraid that I have been somewhat busy with non-Simutrans matters of late. This is a rather splendid idea, I have to say: I had taken to naming my stops manually, which could become rather tedious after a while. I had rather wanted for something like this to be included for some time, but had not had the time to code it, given other priorities.

When I get the time, I shall look into and test this. Thank you again for your work!

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### archchancellor

Hi,

I've updated the code and changed the naming from _road_ to _location_. This should hopefully make it clearer that the names generated by the functions (from what is now called locationlist_LANG.txt) are names for the location and are not linked to any road being there. I've also done some code-cleanup based on feedback from Dwachs.

I'm working with Dwachs on getting the code to a state where it could be included in the standard simutrans code-base and simutrans-experimental can then inherit the feature.

Happy coding,
Mark

#### prissi

#8
This can be easily achieved within the current system. The string "0center" just needs to be replaced by "%s Pcadilly Str. %s". You can add a translation file like this called en-streenames and the content like

0center
1center
%s High Str. S5
...

This overwrites all previous entries of 0center and so on. The translation file name must just start with the two letter of the language code. It either goes into pakxyz/text/ in the main pak or in the pakxyz/text/ folder in your simutrans directoy. (In the latter it is of course only activated, when you load extensions on startup. THis is the highly recommended location anyway, if you want to do onlyine games and people should not be confused about your different stop names ... )

This works of course also for standard.

#### archchancellor

Right. Groovy. I hadn't fully grasped the power of that part of the name generation.

Prissi, do you think it would be worth changing the numbering scheme to "centerXX" to allow for more names (and of course to "suburbXX" and "externXX")? As far as I can see the current system limits to 36 distinct names, which in a big city can easily be reached. With the "centerXX" scheme the naming could be limited by a pak-specific setting (say 99 or 999). As far as I can see it would only require a small change in the code, which I would be more than happy to have a go at.

Mark

#### prissi

Currently almost no language uses the possible 36 entries. But it would be very easy to change it to something else, like center000-center999, and only if those are not present it would fall back to 0center. That way the old way would be used, whenever there are not enough place names specified.

The center000 would have preference, and would be reserved for custom strings and would not be imported into translator.

This is a very good suggestion. It would also enable games to switch this on by using "load with extensions" ...

#### The Hood

The one advantage I see with the proposed system over the current is that the current system goes through the list one by one, whereas the new system has a random element.  It would be nice to have the random element for more variety in station names.

#### archchancellor

I'm new to the simutrans code-base, so please excuse me for being a bit slow in understanding.

Why would the center000 entries not be imported into translator?
How does the "load with extensions" functionality work?
Would it be possible for the code in simhalt.cc to find out how many centerXXX entries there are to enable a random selection? (the randomness is nice because it gives each town a distinctive flair)

Mark

#### VS

As a somewhat tangential suggestion, would it be possible to generate names with Markov chains instead? That could introduce some high quality randomness without relying on hard constraints on numbers of entries, their combinations etc.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

#### archchancellor

@VS: I'm not quite sure what the advantage is there. In either case you would have to spend some time collecting real-world examples, but in the case of the Markov model you would then also have to train the model (unless I've misunderstood something). While you would get more variation, you would probably also get some names that don't work in reality. It's a tradeoff of course, but I'm just not quite sure I see the advantage over randomly selecting an existing street/square/area/... name from a list.

#### prissi

The advantage of having two kinds of names is simply that if I have only one kind of names the twelve first names will dominate any road even if I have less than twelve roads. The other thing is that the names from the second list can be taken randomly, while the simutrans names are optimized for importance, i.e. main station first.

#### Dwachs

Entering center148 etc into translator will be a pain. It would be much more comfortable using a single text file containing all the names. Moreover, then you do not have an upper limit on the number of names.

@archchancellor: "translator" refers to this site http://simutrans-germany.com/translator/ to translate all the ingame strings via a web interface. (In case you did not know)

I would not mind if the current naming scheme would be dropped in favor of a list-based one, keeping the current scheme as fall-back.
Parsley, sage, rosemary, and maggikraut.

#### Dwachs

This is now in trunk (thanks to prissi).

Now there must a file streetnames_xx.txt exist in order to be able to use it. However, the streetnames must include  %s characters to be replaced by city name / stop type. I would like to propose the following change:

Use the current implementation if %s is found in the streetname, otherwise try

buf.printf( translator::translate("%s streetname %s %s", city_name, streetname, stop)

The string "%s streetname %s %s" must be translated, using positional parameters changing the order of arguments.

Any thoughts?

Another question: how to incorporate that into the translator? The easiest way (without need for changes to the translators sourcecode) would be to create a help file __streetname.txt. Upon exporting move and rename the files xx/__streetname.txt to streetname_xx.txt.
Parsley, sage, rosemary, and maggikraut.

#### prissi

#18
For what purpose the addional string? Giving strings directly is more flexible, since you can use positional orders also in the streename file. THe two strings are twon and stop type.

If only one argument is given, the town will be the only string:
With two:
"Picadilly Street %$2s %$1s" -> Picadilly Street Station London

#### jamespetts

#19
Thank you very much Prissi for implementing this, and to Mark for suggesting it! Am I right in understanding that not all "street names" need actually be names of streets, but any elements to add to a naming convention? E.g., if we replace "Picadilly Street" in your above example with "Grosvenor Square", "Hyde Park" or indeed just "Picadilly", it would work just as satisfactorily, and give more variety - is that right?

Edit: Could you also perhaps load a short sample streetlist_xx.txt file to give an example of the format?

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

#### archchancellor

Hi Prissi,

Thank you for implementing this. That's a nicely elegant solution.

One question I have is whether it would be possible to extend this to be able to specify more name variety in the "extern" areas?

Happy coding,
Mark

#### archchancellor

#21
One more thing I have just noticed. I can't get the positional arguments to work. "Picadilly %s" works, "Picadilly %s %s" works, but "Picadilly %$2s %$1s" does not work. Instead of the replacement I get the currency symbol ("Picadilly ¢2s ¢1s"). What am I doing wrong?

Mark

Ignore this. I've got it.

#### archchancellor

I've run into something else. If I use the positional parameters, then I occasionally get random characters added to the end of the name.

This is the content of my streetlist_en.txt:

Picadilly %2$s, %1$s
Oxford Circus %2$s %1$s

and I have attached a screenshot of what it produces. If I just use the normal parameters, then I can't reproduce this problem.

Mark

#### prissi

That is most likely a bug of the positional parameter routine.

#### infernalmachine

#24
I tried this with a much longer list of names (james's list http://forum.simutrans.com/index.php?topic=8022.msg76278#msg76278 with corrections - I needed to swap order: '$1' to '1$', etc. to get it to work.).

What appears to be happening is that the length of the string doesn't decrease when you create a shorter-named stop after a longer one.

Ex: After creating the stop, "Gooding factory Steel mill stop" (length:31), I then created, "Gooding Grey Street stopll stop" (length:31).  But if the length was 24, the output would be fine.

I have many more examples of this, so I'm pretty sure these anomalies are incorrectly terminated strings rather than random weirdness.

Not sure how strings are handled, so this is either a string length issue or a lack of a end-of-string delimiter.

Update:  At first I didn't obtain any non-printing characters in stop names, but when I tried building stops in a different town, I was able to reproduce this problem as well.  (The streetlist_en.txt I'm using has entries in the form: "%1$s Chapel Lane %2$s", which is different from Mark's above.)

Also, it appears that when you create a City Hall stop, it works as usual but it doesn't alter the length of the string buffer (for subsequent stops you build), while a factory or attraction displays correctly but does change the string buffer length to its own length.

Also, it seems as if the buffer changes when you change towns, although the string length is kept. As the new buffer is not initialized, it contains random junk at the end if your stop name is shorter than the retained (from previous town) string length.

So it appears that string length is being correctly increased when required, but not being decreased when that is needed.

#### The Hood

I also got the following when starting a game: "Gillingham Manorgate  w map is being created.  (This may take a few  minutes for big maps.)" as well as similar bugs to the above...

One a related note, would it be possible to have the new behaviour in preference to auto-naming after local attractions?  e.g. have "Gillingham High Street" instead of "Gillingham Small Cricket Ground"?

#### infernalmachine

#26
Thanks, prissi, for the fixes.  It (positional parameters) appears to be working fine as of nightly 4813.

Two questions, though, which puzzle me:

1.  Using a streetlist_en.txt file which consists entirely of entries of the form:
%1$s street1 %2$s
%1$s street2 %2$s
...
%1$s streetX %2$s

results in city stops (which aren't townhalls, factories or attractions) having the desired format and names from my list.

However, if building a stop outside of a town, the default extern code is used (and presumably suburbs also work this way).  How does one change my example streetlist_en.txt to also specify a similar set of names for each of suburbs and extern? Or is this not possible yet?

2.  Earlier in the thread, it was mentioned that it is preferable to place this file in the add-on directory (.../Simutrans/pakxy/text) and then "load-with-extensions".

I have an add-on directory for pak128.open.r527 in the appropriate place (which works for add-ons. at least).  Within that I created a text directory in which I placed streetlist_en.txt.  But when I run the program and choose the "load with add-ons" button at the pak selection screen, I am not able to use the new street names (but I can use the .pak add-ons).  However it does work if I place the file directly in the actual pakset/text directory.

Does "load-with-extensions" only refer to a command-line approach, which has a different effect from the "load with add-ons" button? If so, what would the arguments be? simutrans -objects pak128.open.r527 -addons Is that what is meant by "load-with-extensions"? Or is it a different argument?

Thanks.

[EDIT:]
I ran the program with -log 1 and with streetlist_en.txt within the add-ons directory and used the "load with addons" button.  Here's three sections of the log (separated by "....").  First the program and working directories, then the search  for streetlist_en.txt, and finally the loading of snfos_fences.pak which can only be found in the addons directory, not the main pakset directory.
Simutrans version Nightly 110.0.2 from Sep 16 2011 r4813
Message: simmain::main(): Version: Nightly 110.0.2  Date: Sep 16 2011
Message: Debuglevel: 5
Message: program_dir: C:\Users\Patrick\Documents\SimuTrans\sim-winsdl\simutrans\
Message: home_dir: C:\Users\Patrick\Documents\Simutrans\
....

Message: translator::load_custom_list(): try to city name list 'C:\Users\Patrick\Documents\SimuTrans\sim-winsdl\simutrans\pak128.open.r527/text/citylist_en.txt'
Message: translator::load_custom_list(): try to city name list 'C:\Users\Patrick\Documents\SimuTrans\sim-winsdl\simutrans\pak128.open.r527/text/citylist_en.txt'
Message: translator::load_custom_list(): try to city name list 'C:\Users\Patrick\Documents\SimuTrans\sim-winsdl\simutrans\pak128.open.r527/text/streetlist_en.txt'
Message: translator::load_custom_list(): try to city name list 'C:\Users\Patrick\Documents\SimuTrans\sim-winsdl\simutrans\pak128.open.r527/text/streetlist_en.txt'
Message: translator::load_custom_list(): try to city name list 'C:\Users\Patrick\Documents\SimuTrans\sim-winsdl\simutrans\text/streetlist_en.txt'
Message: translator::load_custom_list(): try to city name list 'C:\Users\Patrick\Documents\SimuTrans\sim-winsdl\simutrans\text/streetlist_en.txt'
....

Message: wegbauer_t::register_besch(): brick_wall
Message: wegbauer_t::register_besch(): concrete_fence
Message: wegbauer_t::register_besch(): concrete_wall
Message: wegbauer_t::register_besch(): fence
Message: wegbauer_t::register_besch(): plexiglas_fence

It doesn't appear to ever look in the text subdirectory of the addons directory although it does happily find and load the addons.

#### prissi

#27
It looks for the file in the same place as for the citylists: