News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

James Petts: I'm 'rebranching' the experimental pak -- help needed!

Started by neroden, May 10, 2010, 05:42:01 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

neroden

You might not want to mess with the experimental pak until I'm done.  When I'm done, I should have a "proper" branch off of the git for standard, which looks pretty much like your current HEAD for experimental, and you can clone that, check it out, and start working on it.

I'm running into a few oddities, so I'm going to document them here and possibly get answers:
(1) I discovered that I'd saved the wrong version of menuconf.tab in the last cleanup; this is fixed.
(2) I'd dropped electricity.tab on the floor in the last cleanup; it's back.
(3) Standard has more interesting settings for "city road" and "intercity road" in simuconf.tab.  I ported them over, but they can be reverted easily if needed.
(4) In order to minimize alterations I tried to keep line layout within .dat files as close to standard as possible, which means some changes from you existing experimental pak.
(5) There are some name changes: Knight-Monument to Knight_Monument and a couple more.  Are these necessary or desirable?
(6) There's vast masses of extra city lists in experimental.  This is a design decision: would we like to say "This is pak128.britain, we will have only English city lists", or do we want the masses of city lists (probably from pak128)?
(7) There are some weird divergences in en.tab which I'm still trying to decipher.
(8) There are two bizarre .zip files floating around in the experimental repo (stations/stations.zip and gui128/gui128.zip), which appear to contain variant .png files with different brightness (or something).  Can I get rid of these?

There will probably be more oddities to sort out as I continue this.

(EDIT)
(9) There are all kinds of variances in the vehicle definitions, beyond the ones I expected (addition of experimental-specific values).  The boats all have increased power, which I assumed was intentional; the bus changes, however, are more extensive, ranging from changes in weight to changes in capacity to changes (!) in loading time.  I am highly suspicious that at least some of them are accidental or incorrect.  I'm going to try to queue them up as individual commits so that they can be examined and possibly reverted individually.  EDIT: First question: a number of vehicles have loading times in both standard and experimental, usually longer in experimental.  Which is right?  EDIT: Second question: some capacities vary quite dramatically, notably the stagecoach (4 in experimental vs. 8 in standard).  Who's right, and should standard be changed if experimental is right?

(EDIT)
Note that the loading times for (for example) the foden-compound.dat were different *on introduction into version control* so I can't figure out which is "newer".

(10) Are the changes to forestrules.dat (extensive changes to forests) in experimental intentional?

(EDIT)
(11) Is there any reason to add back the citybuildings/sidewalk.dat file, which contains nothing but comments?
(12) Are the following changes in one city building worth applying, or obsoleted by standard?  (I already renamed the city building to match standard)

diff --git a/citybuildings/res-1900.dat b/citybuildings/res-1900.dat
index 89daf23..884bc96 100644
--- a/citybuildings/res-1900.dat
+++ b/citybuildings/res-1900.dat
@@ -1,11 +1,13 @@
Obj=building
Name=RES_A_1900_00_08
copyright=Archon
type=RES
chance=100
Level=8
-intro_year=1900
-retire_year=1920
+intro_year=1895
+intro_month=11
+retire_year=1921
+retire_month=4
needs_ground=1
dims=1,1,4


(EDIT)
(13) (yeah yeah, this is a lot) There's something funny going on with 1909-elec-substation.png.  In standard there is an image used for an "ordinary building"; in experimental there's a *slightly different* image, more brightly lit, used in 'ways/' for an actual substation.  Neither appears to have the full complement of rotations (where's the back view?).  (On a vaguely related note I'm amused to note that cars move around in the parking lot whenever you rotate the map).

jamespetts

Neroden - thank you for your hard work on this: it is much appreciated. I shall answer your issues by number, as necessary. Please note, however, that I do not think that I have committed the latest changes that I have made to Pak128.Britain - I was planning on waiting until the line endings issue had been resolved, then pulling your changes, then committing/pushing. It seems as if this might be somewhat of an error.

(3) This is probably an issue related to what is discussed above. The road settings that I have in my local version are:


################################ Road Settings ###################################

# (=1) drive on the left side of the road
drive_left = 1

# The below sections deal with the types of roads built automatically by the game,
# both when the map starts and during the game (in the case of city roads). Different
# kinds of roads are available at different times. The types of roads specified must
# be available in a .pak file. If a specified type is unavailable, Simutrans will
# guess which road it should be using.

# City roads timeline. Format examples:
# city_road[0]=name,1900,1920
# city_road[1]=name2,1921,1950

city_road[0]=city_road,1905,2050
city_road[1]=cobblestone_road,1781,1904
city_road[2]=dirt_road,1700,1780

# Intercity roads timeline. Format examples:
# city_road[0]=name,1900,1920
# city_road[1]=name2,1921,1950

intercity_road[0]=dirt_road,1700,1860
intercity_road[1]=cobblestone_road,1861,1902
intercity_road[3]=tarmac_road,1903,1932
intercity_road[4]=asphalt_road,1933,2050

# Max. length of intitial intercity road connections
# If you want to speed up map creation, lower this value
# If you want more initial intercity roads, raise this value

intercity_road_length = 320


(4) That is probably sensible - I'd be interested to see what sorts of line layouts that you had in mind.

(5) These changes are necessary, and are probably desirable in Standard, too: the monuments will not appear if there is a "-" in the name.

(6) That is an interesting thought. I tend to prefer fictionalised city names, and have been working on adding a very large number of name beginnings and endings to en.tab of the base (rather than the pakset specific) text sets, which will generate a very large number of realistic sounding British style city names. Some people, however, prefer lists of real names. The problem is, though, that if people use a language other than English, and there is no city list for that language, then the naming will revert to using the automatic syllable mixing naming system from the base en.tab, rather than using the English city lists.

(8) These can be killed.

(9) Wherever there are differences, it is likely because I have found the values from Standard to be incorrect or otherwise undesirable and changed them: please therefore adopt the values from the Experimental branch over the Standard branch wherever there is a conflict. The loading times, which are not used in Standard, are outdated values that I have changed after testing to more appropriate values. As for the stage coach, the correct position is that it should have a capacity of 4 and an overcrowded capacity of 4, bringing it to a total capacity of 8: in reality, four people could sit inside, and a further four could sit on the roof. The overcrowded capacities of vehicles have not yet been set fully in Experimental.

(10) Yes - too much tree cover substantially impairs the performance. Britain in the 18th century  and later did/does not have such extensive forests in any event - most land is pastoral.

(11) No - this was only removed from Standard recently. I kept the file commented rather than deleting it as, if I deleted it, SVN would always put it back.

(12) I'd prefer to keep the slightly longer life span of this building, and dislike in any case the unfortunate trend in the Standard version to use rounded numbers for introduction/retirement dates.
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

Quote from: jamespetts on May 10, 2010, 07:27:14 PM
(3) This is probably an issue related to what is discussed above. The road settings that I have in my local version are:
I'll just grab these, thanks very much!
Quote
(4) That is probably sensible - I'd be interested to see what sorts of line layouts that you had in mind.
There's some funny churn regarding the location of "starting_year" in files, even when the starting year doesn't actually change.  That's mostly what I was fixing.

Quote
(5) These changes are necessary, and are probably desirable in Standard, too: the monuments will not appear if there is a "-" in the name.
Excellent.  I think I may have to make a queue of patches which belong in standard.

Quote
(6) That is an interesting thought. I tend to prefer fictionalised city names, and have been working on adding a very large number of name beginnings and endings to en.tab of the base (rather than the pakset specific) text sets, which will generate a very large number of realistic sounding British style city names. Some people, however, prefer lists of real names. The problem is, though, that if people use a language other than English, and there is no city list for that language, then the naming will revert to using the automatic syllable mixing naming system from the base en.tab, rather than using the English city lists.
OK, have to think about this.

Regarding #8-12, I will do as you have advised.  Thank you very much!

EDIT:
Quote from: jamespetts on May 10, 2010, 07:27:14 PM
Neroden - thank you for your hard work on this: it is much appreciated. I shall answer your issues by number, as necessary. Please note, however, that I do not think that I have committed the latest changes that I have made to Pak128.Britain - I was planning on waiting until the line endings issue had been resolved, then pulling your changes, then committing/pushing. It seems as if this might be somewhat of an error.
OK, here's what I recommend doing now.  Make a 'diff' ('git diff' if you can) of your local changes versus the most recent version on github.  If it's small enough, upload it for me and I'll integrate it while I'm rebranching.  If it's larger, save it off to the side and then apply it after checking out the 'new' version.

The purpose of rebranching is to get history from standard working properly; at the moment git thinks there is no common history between standard and experimental, making merges not work right.  If we rebranch, I have to do it all by hand *once* (i.e. now) but never again.

Oh, there's a 13 up above, BTW.  :-)

EDIT 2:
OK, I changed my mind.   ;)  Just push your current changes back to git, and I can merge them from there.  If you've done major merges from standard this will make it easier for me; if you haven't, this won't be any more difficult than working with a 'diff'.

EDIT:
(14) Binary files a/gui/gui128/ls-cursors.png and b/gui/gui128/ls-cursors.png differ
Do I want the version from standard or the version from experimental (or some third version)?
(15) I found and fixed the problem I was having with 'buy house' vanishing.

EDIT:
(16) I am very curious about this change:

-BackImage[0][0][0][0][0]=sheep-farm-house-all.0
-BackImage[3][0][0][0][0]=sheep-farm-house-all.1
-BackImage[2][0][0][0][0]=sheep-farm-house-all.2
-BackImage[1][0][0][0][0]=sheep-farm-house-all.3
-fields=SheepField
+BackImage[0][0][0][0][0][0]=sheep-farm-house-all.0.0
+BackImage[3][0][0][0][0][0]=sheep-farm-house-all.0.1
+BackImage[2][0][0][0][0][0]=sheep-farm-house-all.0.2
+BackImage[1][0][0][0][0][0]=sheep-farm-house-all.0.3
+fields[0]=SheepField

I understand that fields has to change from plain to [ 0 ] everywhere.  But I'm mystified bythe extra column of  [ 0 ] on BackImage -- what changed to change it from 5 to 6 layers?  Also, the definition of SheepField jumped around from one part of the file to another.

jamespetts

Neroden,

have pushed as you've suggested. Do let me know when I should start pulling. As to the remaining queries:

(13) In Standard, the substation is a city building. This does not make sense in Experimental, as it is possible to connect a city to the electricity grid using a substation  (in Standard, one can only do this with industries). It would be confusing for a substation to be a city building. So, I have taken the substation graphic, and used it for the end-consumer substation - in Standard, there is only the one graphic used for both types (the power station's substation and the end user's substations).I'm not sure why the graphic is brighter in one version than another - I thought that I just copied it accross. I think that it was only after I did this that (very recently) Standard was updated to allow snow images for substations, which update was then included in Experimental. It might be possible simply to use the original graphic for the substation, including the snow images now - I have not looked into it.

(14) They both appear to be the same to me, so I am not sure why they show as not binary equivalent.

(16) This is not something that I have programmed myself - I suspect that this is a fix from somewhere that I pasted in. If the sheep farm now works in Standard, best to use the .dat file from there.
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

EDIT: Renumbering because I'm brainless. :P

(17) I understand that intro & retirement dates etc. are more accurate in experimental, but this surprised me:


diff --git a/london-underground/met-dreadnought-third.dat b/london-underground/met-dreadnought-third.dat
index aad23f1..f1f455a 100644
--- a/london-underground/met-dreadnought-third.dat
+++ b/london-underground/met-dreadnought-third.dat
@@ -15,9 +15,11 @@ cost=850000
runningcost=26
sound=-1

-Constraint[Next][0]=Metropolitan-Dreadnought-Third
-Constraint[Next][1]=Metropolitan-Bogie-Third
-Constraint[Next][2]=none


Standard has constraints on assembling the Metropolitan "Dreadnought" and experimental doesn't.  Is this intentional?

EDIT:
(18) From your most recent changes.  There are a bunch of plausible power, weight, etc. changes and then there's this:

diff --git a/bus/leyland-leopard.dat b/bus/leyland-leopard.dat
index 4f6db19..9743158 100644
--- a/bus/leyland-leopard.dat
+++ b/bus/leyland-leopard.dat
@@ -8,7 +8,7 @@ engine_type=diesel
freight=Passagiere
payload=48
speed=85
-power=130
+power=13093
#gear=110
weight=13
length=6

Um, 13093?  Is this just an error?

EDIT:
(19) In your most recent commit you appear to have deleted trains/gwt-churchward-star.dat -- is this an error?  (I'm assuming it is.)

EDIT:
(20) In experimental the oldest passenger and goods quay have no intro date, vs. 1750 intro date in standard.  I assumed this was intentional but added a comment to the file to this effect.

EDIT:
(21) There appear to be trains which are in experimental and not standard, and trains which are in standard and not experimental.  Ow.  In particular the gwr-hall is present in standard but not experimental; a complex collection of br-mk1 variants are present in experimental but not standard.  What to do?

EDIT: A more complete documentation of the problem:
Images in experimental and not standard:
trains/images/br-mk1-rb-cc.png <-- EDIT: This is the -rbr-cc from standard
trains/images/br-mk1-rb-m.png <-- EDIT: This is the -rbr-m from standard

Images in standard and not experimental:
trains/images/gwr-hall.png
trains/images/gwr-modified-hall.png
trains/images/lms-fowler-3p.png

Images in both, but different in each:
trains/images/br-mk1-rbr-cc.png
trains/images/br-mk1-rbr-m.png
trains/images/l&yr-emu.png <-- EDIT: This one is a symmetry flip-flop, same images in a different order
trains/images/msj&a-emu-driving.png <-- EDIT: these appear identical to the naked eye
All the .dat issues seem to be related closely enough to the images that I could probably figure them out if I knew what was going on with the images.

EDIT: I included the changes to the br-mk1-rb* files, kept the files from standard for the hall, modified hall and fowler 3p, and used the standard version for the l&yr and msj&a EMUs.

(22)  Is this citybuilding change correct?  It's the only difference in 'level' for any citybuilding.  That's one nice big building in experimental.

diff --git a/citybuildings/res-70.dat b/citybuildings/res-70.dat
index 4ac3248..891baf7 100644
--- a/citybuildings/res-70.dat
+++ b/citybuildings/res-70.dat
@@ -63,7 +63,7 @@ Name=RES_JH_1970_03_04
copyright=James
type=res
chance=15
-Level=4
+Level=12
intro_year=1970
retire_year=1990
needs_ground=1


EDIT:
Quote from: jamespetts on May 10, 2010, 09:47:06 PM
(13) In Standard, the substation is a city building. This does not make sense in Experimental, as it is possible to connect a city to the electricity grid using a substation  (in Standard, one can only do this with industries). It would be confusing for a substation to be a city building. So, I have taken the substation graphic, and used it for the end-consumer substation - in Standard, there is only the one graphic used for both types (the power station's substation and the end user's substations).I'm not sure why the graphic is brighter in one version than another - I thought that I just copied it accross. I think that it was only after I did this that (very recently) Standard was updated to allow snow images for substations, which update was then included in Experimental. It might be possible simply to use the original graphic for the substation, including the snow images now - I have not looked into it.
I tried simply copying over the graphic from standard for the substation, that's what's in the new branch I'm building; we'll dig out the older copy from experimental if we have to.

(24) Is the deletion of the BrickViaduct200/225/320 types (and the complete non-use of the BrickViaduct200 graphic) intentional? I'm going to assume so.

(25) Are spaces really allowed in "name"s for objects?  Merchant Navy and Merchant Navy Rebuilt have them.

And now -- the result.  :D
It's ready, although some improvements may be possible with the answers to the caveats above.  However, do not attempt to merge your old tree with it. :police:  You need to rebranch.

You want this git repository:  git://github.com/neroden/simutrans-pak128.britain.git and you want the "new-experimental" branch.  Create a new branch off of that, check it out and use that for all future development.  (If you prefer, branch off of aburch's 'standard' repo, then merge from mine, then continue.  Either way, do not attempt to merge with the old tree.  You can do a "diff" against the old tree, but you can't merge.  If you're really picky about the names of your branches, you can use 'git branch -f' to forcibly point an old branch at the new line of development.)

This should make future merges from standard much, much easier and less trouble-prone.   Since this is a new branch from standard, no merges will be needed until the next time standard changes, of course.

When you finish getting "rebranched", please take a look at the commits to my "ncn-devel" branch; one makes small rivers navigable; the others are part of a pack fixing up problems with the wooden road bridges.  I would particularly like to see the road fixes go in, or at least the critical first one.

jamespetts

Neroden,

thank you for the work. I'll answer your latest queries, if I'm not too late. I don't know whether my answers change anything.

(17) I don't think that it's intentional. We should follow Standard here, I think.

(18) That looks as though I've tried to replace 130 with 93 and failed.

(19) This file was correctly deleted, as it was a mis-spelled version of gwr-churchward-star.dat. It was the Great Western Railway, not the Great Western Trainway... ;-)

(20) In Standard, where no introduction date is specified, the default is 1900. In Experimental, the default is 1750. It is probably better that explicit dates are added to synchronise with Standard.

(21) If there are things in Standard missing from Experimental, that is an error with Experimental - I had meant to upload all the graphics, and had evidently missed some. If there are things in Experimental that are not in Standard, they should be in Experimental. Ultimately, we need a superset of what is in Standard and Experimental. Where there are conflicts of name (rb versus rbr), the Experimental names should be preferred, as the names in Standard are incorrect: "rbr" stands for "Restaurant Buffet Refurbished", yet the name is applied in Standard even to the vehicles in their original, un-refurbished condition.

(22) I can't remember making any deliberate changes to level, but I suspect that the Experimental settings should be retained here.

(23) The substation - does this compile properly?

(24) I must confess, I cannot remember exactly, but I think that this was intentional.

(25) I suspect that it's wise to avoid names in objects - but "Merchant Navy" is a name from Standard; the Rebuilt version was done by me, but it is now in Standard, too.
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

Quote from: jamespetts on May 11, 2010, 09:09:11 PM
Neroden,

thank you for the work. I'll answer your latest queries, if I'm not too late.
It's git!  You're never too late!  :-)

Thank you for the answers.  They do change a few tiny things.  I'll put patches for them into my git, but you shouldn't wait for this in order to rebranch -- we can always merge or cherrypick afterwards.

You may want to simply start a new github repo forked from mine (or from Ansgar's mirror of the svn) as it may make the github "network" mapping tool work better.  Actually, I'd really advise doing that, if you can stand it.

By the way, thank you for introducing me to git.  I've taken to it like a duck to water once I got going -- individual feature branches come naturally to me (which is the recommended git workflow).  So thanks.

(Further edit) The Churchward Star file was *completely* deleted.  I'm guessing you intended to rename it to gwr-churchward-star.dat ?  That's what I did.  I also made all of the other changes.  :)

I haven't tested the substation compile yet.  (I went to bed after straightening out the repo, before doing compile testing.)  It's easy enough to grab the older graphic though, if something goes wrong.

neroden

And one final discovery.  The substation graphic expects its tiles to be laid out in a different order, and with a little "lightning bolt" on one of them so the one from standard (as an industrial building) does not work to replace the one from old experimental.  EDIT: It's the lack of lightning bolts which appears to be the key.  I could turn off the lightning-bolt symbol, but that seems undesirable.

I'm patching the one from old experimental back in for the time being.  I hope, however, that someone has time to make a four-view, snow-laden substation graphic with lightning bolts.  :)

jamespetts

I have now got around to rebranching the Pak128.Britain-Ex repository on Github as Nathaneal has suggested: it can be found here: http://github.com/jamespetts/simutrans-pak128.britain/tree/new-experimental. I have also pushed some recent changes, including some new gas power stations (sharing graphics with the oil power station for the time being) and the GWR County class steam locomotive. If this new system works well, this should replace the existing Pak128.Britain-Ex repository, whose maintenance was complicated by the inept way in which I had tried to synchronise it with the official Pak128.Britain-Standard SVN. I'd appreciate knowing whether I've done this properly, however - Nathaneal: is this working now?

Edit: Does this also mean that it will now be easy to automate the building of Pak128.Britain-Ex?
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

Quote from: jamespetts on May 17, 2010, 09:25:42 PM
I have now got around to rebranching the Pak128.Britain-Ex repository on Github as Nathaneal has suggested: it can be found here: http://github.com/jamespetts/simutrans-pak128.britain/tree/new-experimental. I have also pushed some recent changes, including some new gas power stations (sharing graphics with the oil power station for the time being) and the GWR County class steam locomotive. If this new system works well, this should replace the existing Pak128.Britain-Ex repository, whose maintenance was complicated by the inept way in which I had tried to synchronise it with the official Pak128.Britain-Standard SVN. I'd appreciate knowing whether I've done this properly, however - Nathaneal: is this working now?
Yes, it works beautifully.

Quote
Edit: Does this also mean that it will now be easy to automate the building of Pak128.Britain-Ex?

I don't know, was it easy to automate the building of Pak128.Britain standard?....  ;)  It should now work pretty much exactly the same way, apart from requiring the experimental version of makeobj.   I've been making 'one command' builds quite succesfully.

sdog

deleted -- for being silly

jamespetts

Nathaneal,

excellent - glad that it now works! How would I set up a one command build in Windows?
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.

sdog

james,

i knew this thread, but i'm still rather confused about the structure on github.

Experimental is now in: "jamespetts / simutrans-pak128.britain"?
the commits look like the master branch is also experimental. However makeALL.mos doesn't contain the -ex suffix the released pak had.

I think i have a rough idea what you did, but not where it is.

jamespetts

Sdog,

this is the up to date Github repository for Pak128.Britain-Ex. The absence of the "-Ex" suffix in makeALL.mos is because I don't use makeALL.mos to build the pakset - I do it manually, since I do not know how one can use makeALL.mos on Windows.

I hope that this helps :-)
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.

sdog

thanks for pointing me to the right repository.

building manually must take half a century. I haven't really looked into using make in windows, but what i saw look rather complicated. (the level of complicated where it's easier to install linux is reached quickly). i'm thinking about a possible solution for you right now. if it's feasible i'll pm you.

on a side note: I always thought makeALL.mos was a windows solution? In linux there's make already.


jonasbb

Using mose script requires python. You should then have a possible to run python script.

jamespetts

Jonas - thank you for the information.  However, I've never used Python before, and am not really sure where to start...
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

Quote from: jamespetts on June 06, 2010, 05:07:28 PM
Jonas - thank you for the information.  However, I've never used Python before, and am not really sure where to start...

Well, I don't know how to install Python under Windows.  (I did 'apt-get install python2.6' in Debian GNU/Linux).  I'd guess you start here: http://www.python.org/download/

prissi

Just found now this statement:
Quote
Quote
(5) These changes are necessary, and are probably desirable in Standard, too: the monuments will not appear if there is a "-" in the name.
Excellent.  I think I may have to make a queue of patches which belong in standard.

My tests showed, that those with "-" show up quite well. The only thing to break loading is using "ä" and "ö" or many other ANSI characters from extended codepages, which are coded differently on different filesystems.