Translation limits and a bad idea

A private forum for those folks working on patches for RRT3.
milo
Engineer
Posts: 512
Joined: Sat Nov 11, 2006 5:36 pm
Location: End of the line

Translation limits and a bad idea Unread post

Issue: A lot of the RT3 objects use a translation table embedded in RT3.exe to map their names to RT3.lng text. A typical entry maps "FarmCorn" to 3255, which RT3.lng translates to "Corn Farm", permitting a corn farm to have different names in each language. This table has a limited number of entries; because of other structures adjacent to it, I can't add more than 19 new entries to it. The new cargos alone will fill those. Furthermore, I don't plan to release a new patch to RT3.exe every time we add new objects.

If an object does not have an entry, its internal name is used. The new engine "ICE (Class 401)" works just fine in English scenarios. However, it also shows up as "ICE (Class 401)" in German scenarios, when it should probably be something like "ICE (Baureihe 401)" instead.

One alternative would be to reserve a message range in RT3.lng for new objects, and then give the new objects names like "_4355 ICE (Class 401)", where 4355 is the RT3.lng message number. With that naming scheme, we could skip the translation table altogether, though we would have to patch the RT3.lng on each pack release. I think I can set things up such that the object would show up as "ICE (Class 401)" if there's no entry for it in RT3.lng.

Downsides:
  • We'd have to keep careful track of how message numbers are allocated, because a duplicate would cause problems.
  • New naming system is a bit cumbersome.
  • We should probably rebuild a lot of the Loco Pack.
Anyone have a better idea? The only other one I can come up with involves adding a new message number field to every object, which would probably cause all sorts of backwards-compatibility problems.

If we don't address the problem at all, we gradually lose the ability to trade new scenarios with Molse's board.
User avatar
bombardiere
Dispatcher
Posts: 425
Joined: Tue Nov 14, 2006 9:07 am
Location: Turku, Finland

Unread post

Hhhhhmmm, I guess this applies me mostly. If you ask me, Hell with the translations. Everyone just should learn speak English.
:twisted:
Ok, on more serious note, I can live with it. Only issue is co-ordination. I can rename the engines to what ever that is needed. But how about possible future additions? It would be difficult to release a new .ing file everytime I cook up a new loco.

I guess the best thing would be to add this feature to the “unofficial loco pack” and leave individual engines out of it. It means that the Patch and Loco pack would be really integrated. (and possible future industries)

P.S. If we go this road, could you please reserve about 30 slots for me? My personal goal is to release unofficial British Rail expansion pack. (perhaps 15-20 Brit engines and a scenario)
milo
Engineer
Posts: 512
Joined: Sat Nov 11, 2006 5:36 pm
Location: End of the line

Unread post

Woohoo! Slightly modified, this proposal solves the problems we're having with old savefiles! It boils down to essentially the same hack PopTop used in CtC, but with far less code involved.

Objects are loaded in case-insensitive lexicographic order. In other words, Concrete loads after Coffee and before Corn. If we rename the object, we can change its load order and hence the place where it appears in internal structures. Unfortunately _####Name moves all of the new cargos to the *beginning* of the list, which doesn't help the savefile problem a bit. However, replacing the underscore with a tilde (~) now forces all of the new objects to the ends of their respective lists.

So the new proposed object naming standard is ~####Name, where #### corresponds to an index in the RT3.LNG file. Use this tilde form for .CTY, .BCA, .LCO, .IMB, and probably .CAR files. I don't think it's necessary for .BTY, .DDS, .3DP, or .TGA files, as these either point to or are pointed from the other files.

Example:
~4451Concrete.cty
~4451Concrete.imb
concrete.dds

Downsides:
  • Naming inconvenience
  • New objects show up at the end of any list rather than where one would expect to find them
  • We probably can't install more than one Pack at once, unless we split a given space into "pack type A" and "pack type B".
Upsides:
  • Existing savefiles work in 1.06!
  • You get to control the display order for anything in a given pack now.
There are a couple of ways to handle index ranges. We could either allocate very large ranges for each type of object (locomotives, buildings, cargos), or we could swap out the relevant sections of RT3.LNG depending on which packs are currently installed. I'm leaning toward the latter to save memory - even if we don't use a thousand message slots between 5000 and 6000, the game would still have to allocate space for all of those slots if there are messages using indices above 6000.

Proposed index ranges:
4355-4424 Locomotives
4425-4449 Buildings
4450-4460 Cargos
4461-4499 Cargo skins

These assume that we don't plan to swap *out* any of the original RT3 or CtC objects. If Bombardiere wants to, say, replace all of the existing American engines with British ones for a long-playing scenario, then we should probably allocate much larger index ranges.
User avatar
pure al
Dispatcher
Posts: 306
Joined: Sat Dec 23, 2006 11:38 am
Location: British Rail Class 450

Unread post

Cool! Well that's complicated, but probably worth it. I made some cargos a few months back, and found it was the cargo IDs that were forcing other cargos to loose their positions. Could we get away with just using blank spaces before the names?
milo
Engineer
Posts: 512
Joined: Sat Nov 11, 2006 5:36 pm
Location: End of the line

Unread post

Unfortunately blank spaces sort before letters. I thought underscores would at least come after the capitals, but apparently something in the game does a _tolower during load. The tildes cause the command shell to do some frightening things here and there (hint: do NOT try DEL ~*), but they're at least accepted by the system and seem to fix some of the game save problems we've been seeing.

The numbers are necessary for translations to work without requiring difficult changes to the hardcoded table inside RT3.exe every time we add a new locomotive, building, or cargo.

Of course, because I ripped out the CtC ordering hack, we're still probably going to have the occasional issue with locomotive availability flags. *sigh*
User avatar
pure al
Dispatcher
Posts: 306
Joined: Sat Dec 23, 2006 11:38 am
Location: British Rail Class 450

Unread post

You're doing a brilliant job Milo, and you have nothing to sigh about :D
User avatar
bombardiere
Dispatcher
Posts: 425
Joined: Tue Nov 14, 2006 9:07 am
Location: Turku, Finland

Unread post

I can live with this. I could start with loco pack engines, and leave rest for later. (and rethink and replan) But HEY, how on earth 75 loco spots are going to be enough for me….. :roll: Ok, I have plenty of plans, but luckily not enough free time to do all those. At the moment it is going to be 19 loco pack engines and possibly about 15 BR engines.

However, one BUT. I may have problems to rename these locos. I have a Scandinavian keyboard, and sometimes it doesn’t function well with English ones. These odd little funny sings such as ^~Öä. Earlier I made an engine which had / in its name. It worked fine in my computer, but crashes the game for anyone using English keyboard. (standard)
Post Reply