Recent posts

#1

Patches & Projects / Re: [Patch] Contextual constru...

Last post by prissi - Yesterday at 08:11:55 PM

One could add one special construction tool, and there select all three components (way, bridge, tunnel). Maybe even in the main menubar, with tabs for the separate waytypes. That could clear up a lot of screen estate for paksets with compact menu bars and keep the screen clear of tools bars (only one window needed). Not relying on hidden modifier keys.

#2

Patches & Projects / Re: [Project] Native Language ...

Last post by prissi - Yesterday at 08:03:48 PM

This is true for German, French, and Japanese too and any language with UTF8 characters. Maybe Korean as well. No idea of chinese ordering.
A and Ä or é and è and ê in French, and 赤池 before 赤坂 and  朝日 ...

#3

Patches & Projects / Re: [Project] Native Language ...

Last post by victor_18993 - Yesterday at 06:29:43 PM

To native language support, I am not sure if it is possible, but ... I wish I would see if towns were sorted by name correctly.

Currently, in Czech, towns with name beginning by some characters are given to the end of list - even if they should not be. From currently played game, Úlíkov is given to thew end of list - even if it should be between Tršice and Vatěkov.

In Czech language correct order of characters is (even if few characters don't appear in the beginning of names):

A, Á, B, C, Č, D, Ď, E, É, Ě, F, G, H, CH, I, Í, J, K, L, M, N, Ň, O, Ó, P, Q, R, Ř, S, Š, T, Ť, U, Ú, Ů, V, W, X, Y, Ý, Z, Ž.

In game, towns beginning by characters like Á, Č, Ď, É, Í, or Ú and so on are given to the end of list.

Thanks, Václav. I was able to reproduce this exactly.
The town list is currently sorted using a byte-wise

Code Select Expand

strcmp() on UTF-8 text, which is why names beginning with Czech accented characters are pushed after the ASCII letters.
I have prepared and tested a locale-aware collation prototype specifically using Czech as the first real case. Your example now sorts correctly:

Code Select Expand

Tršice < Úlíkov < VatěkovI also checked the Czech-specific ordering rules more carefully.

Code Select Expand

Č, Ř, Š, Ž and

Code Select Expand

CH need primary ordering treatment, while characters such as

Code Select Expand

Ď, Ě, Ň, Ť and accented vowels are handled as secondary differences rather than independent alphabet positions.
The implementation is currently local and being prepared for review by prissi before any integration. Thanks for reporting this — it uncovered a real limitation in the current sorting code.

#4

Patches & Projects / Re: [Patch] Contextual constru...

Last post by makie - Yesterday at 05:51:16 PM

The second-click idea is interesting too. If clicking an already selected construction tool does not currently have an important meaning, using the second click/tap to open the advanced construction dialog could provide a common mouse/touch-accessible solution without introducing an Android-specific workflow.

The second click deselects the tool—effectively selecting the magnifying glass instead. You can disable this behavior in the settings.

I like the solution where the second click opens the settings.

I often accidentally deselect a tool by clicking on it a second time—usually because I forget to press Ctrl.

[left-hand-drive graphics]

#5

Extension Requests / Re: Wish: Diagonal graphics fo...

Last post by makie - Yesterday at 05:34:17 PM

One clarification before integrating the patch:
When dedicated left-hand-drive graphics are provided for a roadsign, should those graphics automatically take precedence over

Code Select Expand

offset_left, so that the horizontal shift is not applied?
The tests show that using both mechanisms at the same time causes a double correction: the dedicated LHT graphics already place the sign correctly, and applying

Code Select Expand

offset_left afterwards moves it off the road.
If dedicated LHT graphics are intended to override

Code Select Expand

offset_left, the remaining change in the candidate is very small.

No,
it can be set to zero by the pak designer, so there is a solution for this,
and who knows—perhaps "offset_left" is useful in some cases after all.

I assume that pak designers test their graphics and position them correctly in one or another way.

Thank you for your efforts.

I am happy with the current solution, and should I encounter an insurmountable problem, I will get in touch again.

#6

Pak192.Comic / Re: Missing streetlist_en.txt?

Last post by Flemmbrav - Yesterday at 09:46:27 AM

This makes me wonder if the streetlist should even be translated, or rather, if we'd just use the streetlist_de.txt for every language? Would be authentic, no?

#7

Patches & Projects / Re: [Project] Native Language ...

Last post by Václav - Yesterday at 08:40:39 AM

To native language support, I am not sure if it is possible, but ... I wish I would see if towns were sorted by name correctly.

Currently, in Czech, towns with name beginning by some characters are given to the end of list - even if they should not be. From currently played game, Úlíkov is given to thew end of list - even if it should be between Tršice and Vatěkov.

In Czech language correct order of characters is (even if few characters don't appear in the beginning of names):

A, Á, B, C, Č, D, Ď, E, É, Ě, F, G, H, CH, I, Í, J, K, L, M, N, Ň, O, Ó, P, Q, R, Ř, S, Š, T, Ť, U, Ú, Ů, V, W, X, Y, Ý, Z, Ž.

In game, towns beginning by characters like Á, Č, Ď, É, Í, or Ú and so on are given to the end of list.

#8

Patches & Projects / Re: [Patch] Contextual constru...

Last post by victor_18993 - Yesterday at 08:14:10 AM

Thanks, Roboron. 

I agree that detecting the presence of a physical keyboard would be preferable to making the decision based on the operating system. Screen size also sounds like a better fallback than an OS-specific rule.

The second-click idea is interesting too. If clicking an already selected construction tool does not currently have an important meaning, using the second click/tap to open the advanced construction dialog could provide a common mouse/touch-accessible solution without introducing an Android-specific workflow.

I'll look into whether that interaction can be implemented cleanly and how it could be reflected in the toolbar state.

[left-hand-drive graphics]

#9

Extension Requests / Re: Wish: Diagonal graphics fo...

Last post by victor_18993 - Yesterday at 08:04:55 AM

One clarification before integrating the patch:
When dedicated left-hand-drive graphics are provided for a roadsign, should those graphics automatically take precedence over

Code Select Expand

offset_left, so that the horizontal shift is not applied?
The tests show that using both mechanisms at the same time causes a double correction: the dedicated LHT graphics already place the sign correctly, and applying

Code Select Expand

offset_left afterwards moves it off the road.
If dedicated LHT graphics are intended to override

Code Select Expand

offset_left, the remaining change in the candidate is very small.

[SimuTranslator]

#10

Patches & Projects / Re: [Project] Native Language ...

Last post by victor_18993 - Yesterday at 07:57:02 AM

Small update on the NLS work:

The new translations have now been uploaded to SimuTranslator for Bulgarian, Russian and Turkish.

• Russian: 100% coverage of the Simutrans interface and the texts for pak64, pak128, pak128.Britain and pak128.German.
• Bulgarian: 100% coverage of the Simutrans interface and the texts for pak64, pak128, pak128.Britain and pak128.German.
• Turkish: the entire Simutrans interface has now been translated.

This significantly improves the language coverage of the project, especially for Russian and Bulgarian, where users now have complete coverage not only of the game interface but also of several of the main paksets.

The translations are already available in SimuTranslator for review and future inclusion.
Thanks to everyone involved in the translation and review work.