News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

[patch] Renaming stops with cities

Started by VS, October 21, 2009, 07:38:47 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

VS

Hello,
following the discussion here, I tried to get it to work. What it currently handles well are stop names that start with city name. And that's all.

It indeed works (somewhat) but it's really ugly. This is the first time I got to work hands-on with C strings and... uh.

I am not sure how to get past the limitations enforced by how Simutrans works:

Quote from: VS on October 21, 2009, 05:02:10 PM
I have not even started looking at the "real stuff" that needs to be done there, but even now I can show you something extraordinarily funny. For some reason textboxes in Simutrans always act in "real time", so the name changes literally as you type, with each keystroke.

Take a station like "Appington Apache settlement". You want to rename the city, so you delete the name and... whoops! As you remove the letters, the name changes to App, then Ap, and the next deletion makes it just A and replaces Ap with A, where the trouble start. You get "A Aache settlement". Last keystroke makes it an empty string, so even both capital As are dropped and you get " ache settlement". Now you start typing a new name. Exactly what should the program do when the last name it remembers is nothing?

Obviously it can be done - everything can - but not the obvious way :-(

EDIT: of course just the first occurrence should be replaced, so at least some of the worries should not hold true... we'll see.

The natural way to change text is to remove it and type something new, but that does not work here that well... is there some reason to make the windows sync names all the time?

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!

skreyola

My suggestion would be to change the behavior of just the city window to not update/change anything outside the text field until it loses focus... or else add a button "Rename City with Stops" or similar, that would give a new text field. That way, the S&R could be done in one fell swoop.
Again, I'd like to recommend that if this does get added, it only affect stops within that city's city limits, in case two cities somehow got named the same thing.
--Skreyola
You can also help translate for your language with SimuTranslator.

VS

Only in city limits - that's exactly how it works.

I don't know if it is desirable to make the renaming behave differently than the other windows.

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!

prissi

That is part of the simutrans philosophy, i.e. no confirmation buttons etc. but a completely non-modal UI. But in priciple a change would jsut require to change gui_textinput_t to update the text only on WIN_CLOSE events.

I would also suggest to collect all stops in laden_abschliessen() and every time a new name is created, i.e. each town has a list with stops with its name. Then it could be even shown in the window (Stops: 40 within 20 outside city limits) and would update all of them quite easily.

Another cahnge would be that the stops itself take care of the town name. But this seems the most difficult change, imho.

skreyola

Quote from: prissi on October 22, 2009, 09:09:34 AM
Another cahnge would be that the stops itself take care of the town name. But this seems the most difficult change, imho.
I'm not sure I understand correctly.
Are you suggesting that changing the town name part of the station name would rename the town? That would cause problems if players want to name stops by some universal means (Stop 24AF6, Stop 230,100)...
Are you saying the stop should just store a %town macro? That would make good sense.
--Skreyola
You can also help translate for your language with SimuTranslator.

VS

Updated version. Now stations register to nearby cities, which maintain their list.

  • still no counters in city info window
  • removing does not work yet
  • the gui paradigm issues not touched yet
  • this might not be 1:1 persistent after "breaking session" (save+load) - the position of station is determined from first tile saved in init_pos and nearest city with welt->suche_naechste_stadt(); are these guaranteed to stay the same...? Is this an issue?

A "proper" solution, guaranteed to always rename everything, might be to save (forever) parent city with stops when they are created, but that requires altering savegames and adds yet more coupling... any opinions?

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!

z9999+

As someone mentioned before, this must be triggered by closing window or some kind of button clicking.
This should only replace old city name by new city name.
This should not add new city name to all stops.

VS


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!

VS

Forget all that was here so far, strstr over get_alle_haltestellen() does the job without any speed hits. I'll try to play a bit with some other ideas I have there; for now, here it is.

http://vs.simutrans.com/misc_files/rename-stops-with-cities-2902.diff

edit: Final version concerning renaming stops (new file).

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!

z9999+

This version is not good. It should limit the city area like as old version.

In our language, city name is very short and many similar character (Kanji) is used.
So, changing same name of whole world causes too many problems for us.

VS

So - if you have a Japanese name of town, it is often a substring of other normal texts?

Maybe this could be configured in simuconf - off / only in city area / whole world? Default being only this town...

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!

yoshi

That's problematic in other languages as well, as I can easily imagine city names which might be used in other strings in the game.

e.g. Zug, Essen, Baden


And also, if you replace Ulm with Augsburg, Neu Ulm would be Neu Augsburg as well. This would be annoying. There should be geographical limit in which the replacement is carried out, if it's possible.

z9999+

Option might be good, but problem will still happen.

I suggested before that "this must be triggered by closing window or some kind of button clicking.".
But your system is triggered by hitting return key.

What will happen if player delete city name and hitting return key accidentaly ?
When player input new city name, all stop name will add new city name.

So, I still suggest that it must be triggered by closing window or some kind of button clicking.

VS

Closing window is bad as confirmation, because how else does one "cancel" ? (And what if player accidentally hits escape during writing?)

I will add a button for renaming visible when name is different.

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!

prissi

Given those remarks, I think I move this back to Patches

VS

#15
...and like an annoying zombie, this crawls back from the gutter yet once more ;D

I finally managed to understand how some parts of gui work. This version shows rename/cancel buttons when name is changed. They hide again once used. Is that good or should they stay permanently visible? My motivation to make them only temporary was mainly that ok/cancel would look weird on a city information window. And these buttons should be near the textbox so that it is clear they belong to it, whil ok/cancel is typically in the bottom...

Apart from this I plan to add some detection of false positives so that "New Amsterdam" is not renamed with "Amsterdam", and then let's see... Anyway, how would this eventually interact with network mode?

edit: done.

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!

Dwachs

#16
Did a quick test. Some comments: It would be much more logical if the buttons are displayed as soon as the inputfield has the cursor focus. That said, after clicking one of the buttons the inputfield should release the focus. I would also like the old behavior to stay: i.e. pressing enter renames the city.

gui_textinput_t calls its listeners when enter is pressed, so you can catch this event in action_triggered.

Edit: patch of stadt_info.cc attached, all other changes of your patch I did not touch.
Parsley, sage, rosemary, and maggikraut.

Dwachs

#17
As to networkmode: the synchronization has to be realized in stadt_t::set_name(). So your patch is one step in the right direction, since the dialog does not manipulate the name directly as before. edit: this has already changed. But the change now happens after clicking a button and not somewhere else.
Parsley, sage, rosemary, and maggikraut.

VS

Ah, thanks. I'm still struggling to understand the gui... With your changes it looks to me finished.

Regarding enter, z9999+ argued that it is a bad idea and you that it is good. So how do I choose? ???

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!

Dwachs

Quote from: VS on January 15, 2010, 04:32:35 PM
Regarding enter, z9999+ argued that it is a bad idea and you that it is good. So how do I choose? ???
Now you have both methods: enter and button.

Upon reading those old posts: There should be some check whether the string is empty: I.e. only accept non-empty names.
Parsley, sage, rosemary, and maggikraut.

VS

Oops... safety added.

Since you reread the thread - if you wonder about those mentioned counters. The patch in its recent form does not include places where one could get counting for free, so that would be another project, if ever done. In the beginning it seemed that this will be done very differently.

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!

prissi

Well I am not to keen on the button idea, since it break the simutrans UI, as there are nearly no modal dialoges using cancel. In this case the renaming could be simply done when processing the win_close message.

But better would be cities keeping track of their stations via a list, and then any renaming is possible without conflict or doubling. Empty name would just means front then.

Dwachs

But how should one cancel/undo wrong inputs? Since any action (escape/ enter/ close win) applies the wrong name.
Parsley, sage, rosemary, and maggikraut.

prissi

Just enter the correct name. Or change it again, when cities keep track of "their" stations that is easily possible.

Also now the name is changed. That is part of the simutrans UI philosophy, that there are nearly nothing modal; if you do something, you get immediate result. (Studies have show that such UI are most intuitively usderstood, as try and error give immediate results. Also modal dialogues force a workflow, while modal free allows real freedom. (For the same reason, simutrans have no pull down menu bars.)

VS

#24
The problems that made me decide linking stations and cities is too much:
a) you must save this and change format,
b) no compatibility, affects only new games,
c) can't re-link a station once it is built
...or you re-bind them after each load, which means it is not reliable.

I have done that earlier, so it isn't impossible, either... just not the direction I like.

offtopic: since I can't type any of ěščřž then the "always forward" paradigm is to me a flaw, not help.

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!

prissi

#25
Not being able to input special characters like "ěščřž" is a bug nobody did report. So I cannot fix, if I do not know about it.

And most new features affect only new games. It would be like: is gameversion high enough? Yes, then loading : No, then built from information that is there. All new stuff is like this.

What do you mean with rebuilt?

EDIT: for your letter you need just a translator entry.

VS

By "rebuild" I meant creating the links again. If saving the links is not a problem, let's do it then!

Gui is obviously another part. What concerns me there is, can the whole system handle renames with each key press? (Obviously only one way to find out, eh ;) )

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!