News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

James Petts, please pull my partial merge from standard to experimental

Started by neroden, December 05, 2011, 12:21:31 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

neroden

For pak128.Britain, I have successfully merged standard into experimental up to mid-day on October 30 or so.  It was a very tedious process but it fixed a few minor bugs, improved the Makefile, and added a couple of nice objects.  Please merge my ncn-devel (a3258d2ab777aa8223dce414e42640791f6f7857) branch for pak128.Britain to get the results.

Due to rampant conflicts, I'm merging standard one commit at a time.  The next commit to merge is a pain because it involves massive changes in the translations file.  It would probably be best to make sure everything was in the Simutranslator and that en.tab for Experimental could be auto-generated but I'm unsure whether that's possible.  I probably won't get to merging that for some time, but I figured the partial merge would be valuable anyway.

jamespetts

Nathaneal,

thank you very much for this. I wonder whether it might be an idea at some point to re-branch from Abruch's automatic builds so that we don't have to keep doing this every once in a while - the issue, though, is how to go about it...

(I accidentally posted this reply in the wrong thread previously - apologies).
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

neroden

The problem is that every single .dat file in pak128.Britain.Experimental has changes from standard -- the deletion of "gear", the addition of loading times, station prices, "overcrowded_capacity", "comfort", etc.  This means that text conflicts are common and will remain so even if we rebranch.

The best way to eliminate these difficulties is to get features from experimental pushed into standard.  If the physics models are synchronized, gear can be deleted from standard and that eliminates a lot of the differences.  Loading times are another one which would eliminate a lot of differences.

The second-best way is to get standard to happily ignore things from experimental which it doesn't understand; so then we could simply have overcrowded_capacity, comfort, min_loading_time, etc. settings in the files for standard (those won't change often), which would eliminate a lot of other differences.

We can usually get the image files to sync up, but even there there are issues, mainly due to the fact that experimental supports multiple liveries on one "vehicle" and standard doesn't.  Again, each feature which goes into standard is a difference in the pak which can be eliminated.

jamespetts

Makeobj already does ignore parameters (such as overcrowded capacity in Standard) which it does not support. The problems are not so much with Experimental only parameters, which are easy to accomodate in this way, but things that must be different for Experimental - the liveries, the absence of gear, the different power settings, the different prices, etc.. I doubt that Standard will be modified sufficiently, e.g., to incorporate Experimental's physics model (the Standard developers might permit ignoring of liveries, for example, if I were to write the patch, but this would not deal with the presence/absence of "gear"). There is no problem in principle with having text conflicts: once the conflicts are registered on Git and Git knows which one of the two versions to prefer, it will deal with it intelligently until the remote repository wants to change one of the conflicted parts. It is often the case, however, that there are changes to non-conflicted parts of .dat files, and it would be useful to be able to merge these automatically.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

prissi

The physics model of experimental is certainly never ever to be considered for standard, as it was already discussed a lot. But as james said, makeobj ignores most of the stuff it does not know.

The en.tab file contains several changes and is even with an extra break, so half of the translations are not working and with lots of typos. The only way to rebuild it, was sevral uploads to simutranslator and downloading it again, and merging all pieces. THe standard pak128.britain en.tab is 98% percent from simutranslator. The different stop names in there are added then by hand. This shoudl work without problem for experimental too, as it only translate the names of the pakfile; as long as experimental do not have similar names for other objects of course.

neroden

Quote from: jamespetts on December 06, 2011, 09:18:55 AM
Makeobj already does ignore parameters (such as overcrowded capacity in Standard) which it does not support. The problems are not so much with Experimental only parameters, which are easy to accomodate in this way, but things that must be different for Experimental - the liveries, the absence of gear, the different power settings, the different prices, etc.. I doubt that Standard will be modified sufficiently, e.g., to incorporate Experimental's physics model (the Standard developers might permit ignoring of liveries, for example, if I were to write the patch, but this would not deal with the presence/absence of "gear"). There is no problem in principle with having text conflicts: once the conflicts are registered on Git and Git knows which one of the two versions to prefer, it will deal with it intelligently until the remote repository wants to change one of the conflicted parts. It is often the case, however, that there are changes to non-conflicted parts of .dat files, and it would be useful to be able to merge these automatically.

The actual problem is that the changes to non-conflicting portions are often textually adjacent to the changes to conflicting portions, so git throws up its hands and asks me to check them individually.  :-P  I have found this hard to avoid.  Most of the merge conflicts are essentially "fake conflicts", which an intelligent person can resolve without a moment's thought, but which git isn't quite clever enough to merge automatically.

Quote from: prissi on December 06, 2011, 11:08:34 AM
The en.tab file contains several changes and is even with an extra break, so half of the translations are not working and with lots of typos. The only way to rebuild it, was sevral uploads to simutranslator and downloading it again, and merging all pieces. THe standard pak128.britain en.tab is 98% percent from simutranslator. The different stop names in there are added then by hand. This shoudl work without problem for experimental too, as it only translate the names of the pakfile; as long as experimental do not have similar names for other objects of course.

For pak128.britain.experimental, everything in the standard en.tab should be fine, *but* experimental adds a bunch of new strings which need translations. 

This is almost all because of the liveries feature.   Where standard has BR-Mk3-TO(BlueGrey), experimental has BR-Mk3-TSO (vehicle name) and BR-Blue (livery name).  If liveries ever made it into standard, I could probably just use the en.tab from standard unchanged (occasionally experimental has a couple of extra objects, but that is easy to add).  However, since liveries aren't in standard...

...I need to figure out how to get the large collection of extra strings into Simutranslator and extract another en.tab.

EDIT 12: Previous edits consolidated for readability.

James, I have pushed a few small Makefile tweaks for pak128.britain.experimental to my ncn-devel branch.  Please merge these; these will mean that builds of pak128.britain.experimental made by Makefile checked out from git will add the git commit number to ground.Outside.pak.  This should be helpful for debugging purposes, and perhaps also for nightly builds (does pak128.britain have automatic nightly builds?...)  I also fixed broken lines in en.tab, something which came up during the attempted merge.  I also renamed the two monuments to match standard, just to avoid trouble later.

I have found what I think is a bug in standard pak128.Britain: "AEC Standard STL" has a name with spaces in it.

I have found multiple missing  texts in the simutranslator for standard: There should be a translation to change the stop name "%s factory %s %s" to just "%s %s %s".  The "%s% High Street %s%" name for a "center" stop needs to be added back to the list.  And a surprising number of objects appear to be missing from the simutranslator for standard; see below and attachment.

I have found two items which show up in simutranslator but can't be translated: Large_Football_Ground and Small_Cricket_Ground.  Bug in the pak or in simutranslator?

The above problems might be related.  Anyway, they all need to be solved for simutranslator to work properly with pak128.britain.  Question one: how does one upload a new set of objects/strings to the simutranslator (for a later pak version)?  Question two: is there a bug in the simutranslator which is preventing it from acquiring the entire list of objects in pak128.britain properly?

In order to handle translations properly for experimental, pak128.britain.experimental needs its own set entry in the simutranslator.  How does one do that and most importantly, how does one upload the objects and the "special texts" (like the city names)?  Liveries can probably be treated as special texts for now, there are only a dozen or so of them.

Train names appear to be more standardized in experimental than standard, and those names should perhaps be used in standard as well.

The bus stop with mailbox probably should have a picture of a red pillarbox.  :-)  Wish I could do graphics...

Notes to self:
- depot names are *deliberately* different in experimental because of traction dependency. 

That is all.  :-)

EDIT 11:
- I have attached a file listing the objects in pak128-britain standard which are missing from simutranslator, not including the program texts.
- Program texts apart from the missing city names already mentioned:
"battery" (a vehicle engine power type) needs to translate to "maglev"
"Remove wayobj %s" needs to translate as "Remove electrification %s"
In experimental, the waytypes are also translated (so, narrowgauge_track becmes "(narrow gauge rail)".  I'm not sure if these are objects or have to be listed specially as program texts, but either way it should be done.

jamespetts

Nathaneal,

I have eventually got around to merging this (with some small changes, such as removing double entries for some railway vehicles in en.tab and restoring graphics of some aircraft whose graphics were removed in your merge). This is most helpful - thank you. Let me know if you think that I have made any errors in the merge.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.