I guess it would be useful to share the current state of the little tool and the tables, no matter how messy and incomplete the whole thing still is (the translation table started as a quick setup to be able to evaluate the whole approach, therefore needs to be restructured). WARNING: RUN THIS ONLY ON A COPY OF THE FILES! They are expected in .\trunk-copy (I advise to use "clean"ed source code, the IDE, if any, must not keep the files open). The script needs Perl >=5.8, for Windows e.g. the free "Community Edition" from ActiveState: http://www.activestate.com/activeperl -
The file tr.cmd is a frontend to save typing on Windows, the actual file translate.pl should run on any platform (EDIT: but the file names will be shown with \'s). You might need to adapt the paths in it and then call: tr phase1 check tr phase1 sim tr phase1 translate tr phase2 check tr phase2 sim tr phase2 translate The sim and check calls are optional and do not change the files. But if "check" shows warnings, sim/translate will fail. EDIT: A lot of output is printed on the screen - you better minimize the cmd.exe window or switch off debug output in order to achieve acceptable performance. If additional translations have been entered in the text tables, a delta update can be run with the same commands, but a check is not possible after translation, and phase 1 must not run after phase 2 changes have happened.
I do not have access to a (commercial) refactoring tool, which could do the whole job or at least help a lot. For parsing C++ (in Perl), I did not find much (as opposed to plain C), but if I use GCC's dump function, it would still be much easier (and probably faster at runtime) than writing a C++ p****r and dependency tracker on my own. But this kind of understanding of the code would only save the unnecessary phase1 changes (due to false conflicts) and allow for better texts in some cases.
EDIT: the current version translates single words in comments, but not in strings of any kind.
Aside: Maybe intro and retire dates could be collapsed into one line, too?
Thats makes sense, but it needs abbreviated month names, e.g. "Available: Apr 1965 - Oct. 1978", and special case treatment when either date does no apply.
Oops... Yes, for the second dialog, I had used a slightly older revision (because it was the newest on the other computer that I use). So please forget about the second bug, except that those parameters are not in the climate dialog yet - but I guess that this is quite redundant to the settings dialog. About the parameters themselves - one needs to read additional documentation, because they are really not as simple as the proposed % value. As there is a preview for the map geometry, a preview for the tree distribution would help with changing the settings to useful values.
I can? (Checking again...) No, I can't, that dialog has the same settings controls as the climate dialog, including the "no trees" checkbox (although this one does not have the mentioned bug), but no forest_* parameters. These appear in simutrans/config/simuconf.tab (I installed the whole core package of this revision, plus r294 of pak64). Maybe the settings do not appear because of other simuconf.tab files that are also evaluated? Anyways, their non-appearance would be another buglet.
The checkbox "no trees" can be checked, but not unchecked. Restarting ST solves this.
But instead of fixing this glitch, I would prefer to be able to set the tree density (in % of the available space, i.e. not considering water/rivers, buildings etc.), because now there is only the choice between around 80% coverage (new map in Pak128) and a totally sterile map.
Just another thought: What about adding a penalty to overcrowded stations in the route search? Maybe equivalent to 1 or 2 more interchanges.
You have linked to the other thread where this had been brought up. From my little experience (small maps only) with no_routing_over_overcrowded=1, I can say that overcrowding stops (regarding p****enger+mail) are regulated rather strictly with this setting. Using the level may ease this a lot, especially if there are no alternative routes. But the overflowing stops are only a symptom of lacking transport capacity - a non-overflowing next transfer stop can also mean that the capacity to it (from the current stop) may be too low. From the other posts, I see ideas on how to move the focus to vehicle capacity (but the aggregate capacity of all vehicles+lines between two stops has to be considered).
[blue]{ This posted edited by Isaac Eiland-Hall to remove certain off-topic parts. If you require more information, contact me. -Isaac }[/blue]
I did not suggest to change routes when the pax are on board; I said, check and change route where necessary at the transfer when the pax are about to be loaded onto the convoy.
I think that, even with re-routing only at transfers, oscillating routes (causing p****engers to move back and forward) will happen in nontrivial networks. That's the reason why I made the suggestion above (maybe this wasn't clear). How are you going to stabilize that without storing any information about the original routing decision, no matter how that is calculated? OTOH, how about just implementing alternative routing (load-balancing) within the current routing system, leaving its activation and evaluation of the effects to the user? Maybe it is already sufficient for most cases. It may be necessary to differentiate between pax+mail (many small packets, which however aggregate at transfer stations) and goods (mostly huge chunks with one destination from generation onwards).
Regarding merging of packets: for my suggestion, this would be possible to some extent: merge packets where the following transfer stop has the same state, according to the referenced snapshots.
Regarding oscillating/unstable routing: if there was a method to stabilize this, a modification to the routing algorithm (choosable with no_routing_over_overcrowded = 2?), which allows alternative routes, might become within reach. Some ideas (some may have been mentioned before): 1) re-test the overcrowding state of a station only with low frequency 2) instead of the overcrowding flag, take the level of crowdedness as a routing malus 3) choose a random route from the possible ones combining 2) and 3): take this malus into account for probability; combine with 1) to make this stable
Another approach: snapshot pointer/counter Let's store the network state in each goods packet, so the original routing decision (at p****enger generation/goods release) is retained. Totally crazy idea? The idea is to store only an identifier (perhaps an 8 bit number) into the goods packet *or* the containing convoy, pointing to a 'snapshot', i.e. the overflowing state of transfer stops at a certain point of time in the past. For this, the stops have to have a kind of history (obviously, a method to identify real transfer stations is useful to keep space requirements low). The larger the network is (in terms of travel time), the longer the time between two snapshots will have to be (variable time resolution). By this, the original routing decision can be repeated, I hope.
More details: What happens when the counter has to change to a value already in use? Either keep them as they are, or else all packets/convoys will be checked for packets with that value, and those packets should expire: set the counter to a reserved value, e.g. 0, to mark them as obsolete - discard them at their chosen transfer stop or any next stop - *or* revert to standard routing (do not check for overcrowded state). Regarding the "black hole" argument against discarding: these packets will have used a lot of capacity x time, blocking other customers from being served, perhaps generating no revenue in the meantime (depending on pay_for_total_distance setting). If the counter is attached to the convoy, the re-routing decision at the next transfer stop would still be influenced by the olf value (however, we need to synchronize the convoy at each stop, at least each real transfer stop), so we have at least stabilizing effect for the time between two stops. If the counter is attached to the goods packet, it could also serve a purpose in a different revenue calculation scheme (using overall travel time), but then variable time resolution cannot be used.
1) power, gear and ... final power : display next to the gear value, the final power (power * gear).
This is also needed in the convoy details window.
Quote
2) When a convoy is in the depot, its max speed is displayed, why not show the total power (counted with gear), weight, (why not power/weight ? for empty and full convoy), capacity.
There is only finite space, and the depot window is not supposed to be larger, to keep it usable on smaller screens. A sub-dialogue may be set up to contain more information, e.g. showing a list of the values for the different possible goods (which cause different weights of the convoy when it is loaded).
Hmm, if it was a hole in SMF, then I would expect the following actions to target SMF functions as well. With such a generic payload, I suspect a problem with PHP, MySQL or the underlying software.
How can we be sure that there isn't a backdoor? Comparing the RTE to a backup works to a limited extent.
As discussed elsewhere, Frank may not be able to do something about it, because not only his server is involved in the HTTP request (according to my understanding, err, guessing of the technical setup). The aforementioned advertisement in the error message might be from Frank's provider's webserver, same for the error message itself. @the people to whom the problem occurs: could you please post a screenshot and also the source code (put it in a
(posting conflict with Prissi...) (I can't test with Linux, but I guess that I found the reason:)
menu.WindowSkin.pak is part of the core distribution (in simutrans/skin), not the pak-set. Same goes for translations and maybe some other files. Compiling ST alone will not provide you with these files. Please take those files from an official core distribution (or a complete archive from the nightly builds).
Please, this request separate into new topic and locate it where it will fit best:
If you know that a new topic is needed, why don't you open it yourself?
Quote
To station extension: what level (how much p****engers and post) to set?
This is the creator's choice. Take one that matches the visible size and intended use. Of course, if they are meant as a replacement for other objects, they should match them in their parameters, too.
Quote
I need to know how to create source *.png file(s) for *.dat file for rotated building when I have more than one original pictures.
Have you looked into the Wiki? That page doesn't say much about rotation, but the necessary parameters seem to be covered there.
I have noticed that croatian translation (Hrvatski) is totaly unfinished. It is mixed with croatian and hungarian words ?!!!!! In game texts also show half croatian and half hungarian. 102.2. has wrong translation, even 102.2.2 is totaly wrong. Maybe somebody started to translate (obviously from hungarian as the base) and never finished?
After viewing a diff of the .tab files (base and pak64 texts from 102.2.2), I reckon that the reason for the mix-up is an erroneous fill-up import of HU translation into HR, because there are many regions with exactly the same translation texts. So, there is no work going to be lost when you or anyone else overwrites the incorrect translations. Also, the language exports for HR and HU show no authors beside Frank (administrator). Does this mean that there aren't any active translators for these languages?
A separate category means more menue clutter, more objects to paint (stations, track - what about bridges, tunnel entries?), more support cases... And the player should still be able to use them as overground trains (because metro lines appear above ground in reality where available space allows), just as a separate, incompatible system (it would not allow level crossings, for example). This is less player-friendly than the alternatives, I think.
In the svnlog, you can see the files that have been changed (if you expand a log entry), but not the changes in the files. The most recent changes just don't refer to game objects, so they don't matter to the user. The last change happened on 10th of February, so it's not really "old".
But why does the dirt road have a limit of 80t, whereas the better ones have 8t, 15t and 60t, respectively? Also, the program could show "weight limit <foo> tonnes" in the tooltips instead of just the value, which can be overlooked or misunderstood easily.
With ST-exp 7.1 and Pak128.Britain-exp. V0.4, I was able to reproduce the mentioned problem with the given savegame. I could get the busses to move again by building a complete new road to their next stop. (It's not possible to replace the city road by building over it, which caused a little trouble for my tests).
The problem is most probably caused by the motorway between Inverness, Sheffield and Westminster. Maybe there is some invisible roadsign (one-way, minimum speed), or it may have been saved with invalid weight limits or ribis (although the city cars seem to like it), or some other bug specific to ST-experimental. Therefore, I move this topic to the board for the experimental branch.
@rainer: You need the experimental Pak128.Britain, loading with the standard one results in this error.
EDIT: If there is a weight limit problem, the busses may be able to p**** the route empty, but fail to find a route if filled to some extent.
EDIT^2: OK, I found the reason: the "tarmac" road, that is in use here, has a weight limit of 15 tonnes, which does not allow busses of this size. I overlooked this, because it looks exactly the same as the motorway. The Pak set should provide different images.
I can confirm this for the same setup and versions as Isaac wrote (102.2.1 with Pak.German, Win-GDI without debugging). The option in the players dialog works, however. If it is intended, then the Wiki and other documentation need to be updated.
Do you use ST-experimental, or the main branch with "Pak128 Britian experimental" (don't know whether that combination works)? In the first case, the problem may happen only in ST-experimental, so this thread would fit better in the board for that.
To continue older savegames with Pak128 version 1.4.5 or nightly builds of Pak128, it may be necessary to copy certain .pak files from the compatibility pack 1.4.4 into the Pak128 sub-folder (see Missing factories in Pak128 compatibility pack). This file collection hasn't been included in this official release (unlike version 1.4.4), and it's not part of the Pak128 nightly builds either.
If .pak files are missing when loading a savegame, then Simutrans will abort with a message like:
Quote
FATAL ERROR: fabrik_t::rdwr() no besch for grain_farm PRESS ANY KEY
(Sorry for the late addendum to the announcement. I still keep stumbling over this problem.)
The form had been much more useful in the past (on the previous server, Tomas's one), when it provided the (IMO) best method of searching in the DB. Therefore, I used it a lot. The current "Object Guide" is a replacement for this kind of use, but it doesn't have all the fields the original form had (I forget which ones).
Even more so now. I've just uploaded my SVE but no link was given and the file is not currently on display. This is the fourth time I've uploaded this file and at 15.6mb I can't keep doing it.
I have tested uploading twice with a file of similar size (15.1 MB) when logged in, and the file doesn't appear in the download list either, nor did I get an error message. However, uploading a file of 7.5 MB worked at the first try. Maybe there is a bug. (I have SDSL here, so uploading is as fast as downloading, but a timeout can still happen. Furthermore, I am behind a proxy, but that allows uploads of 33 MB.)
Quote
Maybe Prissi will kindly let me upload it direct to him?
Maybe as an e-mail attachment? (His mail address is in his profile, Idon't know if anyone is supposed to send big files to that address.) But the other developers cannot test with the file in that case.
Can you tell me why I can't get to the links page on File Sharing? I log on but all I get is the upload page. I uploaded my SVE but it didn't put up a link.
****uming that you mean http://simutrans-germany.com/files/index.php?lang=en: The download section is at the bottom of the same page as the upload section. But the browser window has to be large enough (by height) to show both sections, otherwise you can't even scroll to the lower one.
