IRC logs for #openttd on OFTC at 2010-10-07
⏴ go to previous day
00:01:16 *** Eddi|zuHause has joined #openttd
00:03:16 *** ProfFrink has joined #openttd
00:08:46 *** Eddi|zuHause has joined #openttd
00:09:13 *** ProfFrink is now known as Prof_Frink
00:23:43 *** roboboy has joined #openttd
01:21:55 *** Eddi|zuHause2 has joined #openttd
01:22:37 *** fjb is now known as Guest1984
01:37:40 *** Eddi|zuHause2 is now known as Eddi|zuHause3
01:37:41 *** Eddi|zuHause3 is now known as Eddi|zuHause
01:37:56 *** Eddi|zuHause is now known as Eddi|zuHause2
01:38:16 *** Eddi|zuHause2 is now known as Eddi|zuHause
02:06:43 *** glevans2 has joined #openttd
02:28:27 *** valhallasw has joined #openttd
02:39:35 *** De_Ghosty has joined #openttd
03:02:57 <TruePikachu> Hmmm...why must train 31 be so stupid?
03:03:46 <TruePikachu> It's a 24 tile long goods train trying to get into a 4 tile long PAX station
03:04:07 <TruePikachu> I have waypoints set up in addition...
03:04:20 <TruePikachu> But it keeps turning the wrong way
03:11:19 <TruePikachu> I've checked everything!
03:11:36 <TruePikachu> There should be absolutly NO PROBLEM!!!
03:27:21 <TruePikachu> :P selected the wrong waypoint
03:44:59 <TruePikachu> :( I hate how much this (not the uber) station jams
03:45:58 <TruePikachu> This station so close and jams so hard that even the Uberstation feels pain (at least the Uber will fix it's jams automatically)
03:50:35 <TruePikachu> Stupid station jammed AGAIN!!!
03:51:05 <TruePikachu> It is actually funny how much it jams compared to how simple it is; it is so simple that it shouldn't jam
03:51:22 <TruePikachu> Yet it jams due to dedicated platforms
04:56:51 *** Eddi|zuHause2 has joined #openttd
05:42:28 *** roboboy has joined #openttd
06:05:21 *** Cybertinus has joined #openttd
06:07:07 *** valhallasw has joined #openttd
06:08:04 *** Singaporekid has joined #openttd
06:10:09 *** Kurimus has joined #openttd
06:24:02 *** JVassie has joined #openttd
06:37:16 *** ^Spike^ has joined #openttd
06:54:47 <dihedral> TruePikachu, there is a penalty for too short trains
06:55:03 <dihedral> and 24 vs 4 is quite a substantial difference
06:55:49 <dihedral> and while i am at it: "might eventually have a patch." does not make a feature request a patch ticket in bugs
06:56:14 <dihedral> next to that, openttd is not performance calculator
06:58:32 <dihedral> <dihedral> TruePikachu, there is a penalty for too short trains <- s/trains/stations/
07:23:36 *** TomyLobo has joined #openttd
07:32:13 *** Br33z4hSlut5 has joined #openttd
07:35:11 *** Progman has joined #openttd
07:50:33 *** Cybertinus has joined #openttd
07:52:34 *** andythenorth_ has joined #openttd
07:52:53 <andythenorth_> what does "Flat area around industries" do in advanced settings?
07:52:58 <andythenorth_> (not in ottd wiki)
07:54:29 <planetmaker> andythenorth_: it's your pony ;-)
07:55:42 <planetmaker> don't tell us you forgot about it already ;-)
07:55:45 <andythenorth_> I've tested what I thought it did.
07:56:04 <planetmaker> it doesn't do that?!
07:56:33 *** JVassie_ has joined #openttd
08:00:24 <planetmaker> indeed it does not what I thought it does
08:00:29 <andythenorth_> I can't find where that setting is having an effect
08:00:46 <andythenorth_> I assumed it was a variable in CheckIfCanLevelIndustryPlatform
08:11:30 <planetmaker> src/industry_cmd.cpp: uint size_x = max_x + 2 + 2 * _settings_game.construction.industry_platform;
08:11:32 <planetmaker> src/industry_cmd.cpp: uint size_y = max_y + 2 + 2 * _settings_game.construction.industry_platform;
08:12:59 <andythenorth_> so this setting checks for flat land n tiles around an industry
08:15:31 <planetmaker> well... sometimes
08:17:08 <andythenorth_> doesn't apply if industry can build on slopes
08:17:18 <andythenorth_> what if industry can be terraformed under?
08:18:50 *** roboboy has joined #openttd
08:19:03 *** Biolunar has joined #openttd
08:19:33 *** Biolunar is now known as Guest2006
08:47:52 *** KenjiE20 has joined #openttd
08:53:00 *** JVassie has joined #openttd
08:57:13 *** Biolunar_ has joined #openttd
09:15:43 *** Skiddles has joined #openttd
09:25:54 *** Adambean has joined #openttd
09:46:53 *** Chris_Booth has joined #openttd
09:52:55 *** Chris_Booth has joined #openttd
09:55:23 *** Chris_Booth has joined #openttd
10:00:21 *** Chris_Booth has joined #openttd
10:15:03 *** Adambean` has joined #openttd
11:50:21 *** Chruker has joined #openttd
12:45:37 *** norbert79 has joined #openttd
12:53:35 *** Lurimax has joined #openttd
12:55:48 *** SpComb^ has joined #openttd
13:03:07 *** Phoenix_the_II has quit IRC
13:06:49 *** HerzogDeXtEr has joined #openttd
13:06:49 *** jonty-comp has joined #openttd
13:06:49 *** peter1138 has joined #openttd
13:06:49 *** Phoenix_the_II has joined #openttd
13:06:49 *** planetmaker has joined #openttd
13:06:49 *** V453000 has joined #openttd
13:06:49 *** Terkhen has joined #openttd
13:06:49 *** Hirundo has joined #openttd
13:06:49 *** XeryusTC has joined #openttd
13:06:49 *** rhaeder has joined #openttd
13:06:49 *** bartavelle has joined #openttd
13:06:49 *** solenoid.oftc.net sets mode: +o peter1138
13:06:53 *** ChanServ sets mode: +v peter1138
13:08:07 *** andythenorth_ has joined #openttd
13:23:33 *** Lakie` is now known as Lakie
13:40:16 *** andythenorth__ has joined #openttd
13:43:39 *** Adambean has joined #openttd
14:03:19 *** andythenorth__ has quit IRC
14:08:50 <Rubidium> IIRC the zero-ing isn't even needed
14:09:31 <planetmaker> hm, probably true :-)
14:12:53 *** Devroush has joined #openttd
14:16:04 <skfin> Hi, I'm packaging openttd, what should I add as author
14:16:29 <planetmaker> The people mentioned in the credits?
14:17:33 <skfin> Ok, but what for copyright? Is it same as mentioned at openttd.org, "OpenTTD Team"
14:18:42 <skfin> Lastest stable for my ppa
14:19:17 <peter1138> Just use the existing Debian package info?
14:19:24 <Rubidium> what's wrong with the .debs on our download page?
14:19:32 <norbert79> Yeah, wanted to ask it as well
14:19:51 <skfin> You dont have package archive for them
14:20:01 <skfin> They dont update automatically to lastest ones
14:20:04 <Rubidium> norbert79: yeah, we don't compile s390 binaries
14:20:20 <norbert79> Rubidium: Or to ARM :)
14:20:25 <glx> but all the "scripts" are in the tar IIRC
14:20:39 <peter1138> Debian has OpenTTD 1.0.4...
14:20:42 <Rubidium> true, just ln -s os/debian debian
14:20:55 <norbert79> skfin: You're right on the update side
14:20:59 <Rubidium> Ubuntu has 1.0.4 as well
14:21:13 <peter1138> So both these OSes already have the current stable.
14:21:14 <norbert79> yet apt-get update won't bring it up unless it's in a repo
14:22:05 <skfin> Rubidium: It's coming for Maverick
14:22:17 <skfin> But its half year until next version
14:22:18 <Rubidium> even then, there're 2 PPAs for 1.0.4
14:22:35 <norbert79> Rubidium: ...which are? :)
14:22:38 <peter1138> Either way, the packaging information is there already. You can just build it and plonk it onto your PPA.
14:23:33 <norbert79> Rubidium: If the addon bot on this channel would contain the repo information for some distriobutions, that would be a great help
14:24:50 <Rubidium> norbert79: repo information such as: just do apt-get install openttd (no need to add a special repository)
14:25:29 <norbert79> Rubidium: No, repo information like which PPA source... plain apt-get install openttd will give you openttd 1.0.0 in lucid from multiverse
14:25:34 *** ChanServ sets mode: +v tokai
14:26:20 <Rubidium> we don't support those PPAs
14:26:21 <norbert79> Rubidium: At least in Ubuntu... Debian has even older versions of OpenTTD available in stable
14:26:42 <peter1138> An old release of an OS has an old version available. Shocking!
14:27:09 <norbert79> peter1138: Lucid is LTS, and just 6 months old... Windows XP is 2001... Which ojne is older?
14:27:17 <norbert79> Rubidium: You could still list them as Unoffical, partner supported links, for example
14:27:32 <peter1138> Windows Updates never provided any version of OpenTTD.
14:27:40 <norbert79> peter1138: Or take Windows 95.. And it still older
14:27:52 <Rubidium> oh... and DOS is even older :)
14:28:11 <norbert79> Rubidium: You don't support DOS though :) peter1138: Windows has no packaging system neither
14:28:44 <norbert79> it's kinda narrow-minded though, in my opinion, some links to outside sources marking "Unspoorted" would not hurt anyone... But whatever
14:29:22 <norbert79> and launchpad does not compute atm
14:29:43 <peter1138> I'm not really sure what you're talking about.
14:30:07 <peter1138> All the packaging information is there for this guy to build current OpenTTD and provide a PPA.
14:30:25 <Rubidium> there are even two flavours of packaging
14:31:24 <norbert79> peter1138: No, I mean like this page: http://www.openttd.org/en/download-stable - Adding one more line into selection with: outside sources, or unsupported or whatever... That would be a great help for those, who cannot use any binary of pre-packaged options, like for MacOS
14:32:07 <norbert79> peter1138: Just an idea, no offense, I just think that would help lot of users
14:32:15 <peter1138> Then you have to keep an eye on it forever more... the maintainer might stop, or may make malicious modifications, or whatever...
14:33:02 <Rubidium> yeah, show me one reliable Mac OS X packager
14:33:02 <norbert79> peter1138: Why not letting the maintainers let those links being updated, and remove those where you cannot see any updates for 6 months, for e.g.
14:33:13 <peter1138> We could just make a proper repo...
14:33:32 <norbert79> peter1138: Also an option, right
14:34:39 <norbert79> peter1138: And if it works well, then you could move to more repository solutions, and make an official for every each
14:34:54 <norbert79> but that's something for long term
14:35:39 <norbert79> Yet I prefer having OpenTTD in one directory, like back in old DOS times :)
14:35:49 <norbert79> one directory, everything in one place
14:36:14 <Rubidium> with or without subdirectories?
14:36:22 <norbert79> nah, data/scenarios/etc exists
14:36:38 <norbert79> just without having it seperate from $HOME
14:36:51 <Rubidium> that's can be easily done
14:36:57 <norbert79> Yeah, this is how I use it
14:37:24 <norbert79> and I have the game on a pendrive too, with all available binaries so I can play from everywhere :D
14:40:25 <Rubidium> where's the s390 one?
14:40:56 <norbert79> Don't have it, is there somewhere I could download it from?
14:42:28 <norbert79> Pity, that I don't have any access to a real zSystem, I only use them through 3270 emulation :(
14:46:06 <glx> <norbert79> Rubidium: You don't support DOS though :) peter1138: Windows has no packaging system neither <-- maybe there will be one, one day (www.coapp.org)
14:46:48 <norbert79> glx: Let me check that, if yes, that would be just perfect :)
14:47:44 <glx> but it's far from finish :)
14:47:52 <norbert79> glx: So it's aptitude/yum like kinda approach as I assume... Nice, nice... I guess it will come with GUI too
14:47:58 <norbert79> yeah, kinda guessed :))
14:50:17 *** norbert79 has joined #openttd
14:52:20 <norbert79> glx: Yet I guess that would also require of some software's repcakaging, yet Installshield supports updating functions, it would be still necessary being able updating installed programs right
14:52:27 <norbert79> like Pidgin can be updated with ease
14:53:45 <Dagda> I have a problem of knowedge surely ... but i cant upgrade rails -> electric rails
14:54:30 <Dagda> erreur "rails are not suitable" or something like that
14:55:26 <planetmaker> then you need to convert not a railtype to itself. Or something like that
14:55:35 <Dagda> My electric central is working (i think)
14:55:40 <planetmaker> i.e. first select electric rails
14:56:29 <Dagda> where ? i saw "conversion" button only
14:57:22 <glx> conversion button is "convert to current type" current being the toolbar type
14:57:24 <planetmaker> try to click and hold the rail toolbar button
14:57:38 <planetmaker> then select the railtype you want
14:58:30 <Dagda> no submenu when i hold the "upgrade rails" button
14:58:36 <norbert79> No, before doing that
14:58:38 <planetmaker> not upgrade rails
14:58:51 <planetmaker> which opens that toolbar
14:58:59 <norbert79> (Hold down LMB for more railtypes)
14:59:16 <norbert79> same goes for many menus, almost every each of them
14:59:36 <norbert79> one menu button will bring up more submenus when having LMB pressed and hold down
15:18:24 *** andythenorth_ has joined #openttd
15:18:39 *** waldtroll has joined #openttd
15:22:51 *** Brianetta has joined #openttd
15:41:23 *** norbert79 has left #openttd
15:46:01 *** |Jeroen| has joined #openttd
15:47:33 *** Brianetta is now known as Brianetta-moving
15:48:20 *** Brianetta has joined #openttd
15:48:51 *** Brianetta-moving has quit IRC
15:52:10 *** lobstah has joined #openttd
15:54:20 <Belugas> plus, i only have one boy ;)
15:54:43 <andythenorth_> one is enough for me right now :P
15:55:47 <planetmaker> assuming we allow newgrfs to define a minimum version which they're compatible to and newgrf_show_old_versions=off - should it only show the latest version, even if there are incompatible, older ones?
15:57:28 <planetmaker> (I'd prefer the answer 'yes' ;-) )
15:57:58 <Belugas> let me try to even digest the question :S
15:58:24 <Belugas> ho... speaking of digesting...
16:00:46 <planetmaker> Belugas: background is such: currently, if a newgrf is not backward compatible, one has to define a new grfID. But as we have versions now, it makes sense to actually mark incompatibility with earlier versions by a new piece of information: the minimum version of itself the newgrf is compatible to.
16:01:41 <planetmaker> Now, current trunk only shows the newest version of a newgrf, if versions are set. But current trunk also assumes that a grf with the same grfID is always compatible...
16:01:49 <Rubidium> planetmaker: I still wouldn't show it
16:03:17 <planetmaker> also makes the patch smaller :-)
16:05:51 <Belugas> problem not showing why it's not compatible is that the user won't be able to correct. but on the other hand, the said user would never be able to figure it out why
16:08:20 <planetmaker> Belugas: there's still the option "newgrf_show_old_versions"
16:08:22 <Belugas> andythenorth_, note that i would not buy those copy sets
16:08:24 <planetmaker> Set that and you have all
16:08:38 <andythenorth_> Belugas: me neither :)
16:08:41 <planetmaker> but it's cfg / console only :-)
16:08:52 <andythenorth_> dunno if it's loyalty, or concerns about quality :o
16:09:02 * andythenorth_ is writing a scary migration script
16:09:12 <planetmaker> migration script?
16:09:16 <andythenorth_> 4 years worth of timesheet data, all stored in python objections
16:09:28 <Belugas> planetmaker : thus, the user needs tobe a bit brainy (read not a chemist, but a rocker scientist ;)
16:09:33 <andythenorth_> if I get this wrong I (a) screw all our data (b) lockup a production webserver in a boring way
16:09:38 <Belugas> andythenorth_ : quality
16:09:45 * Belugas rest his case and open hi guitar case
16:09:48 <andythenorth_> there are of course no unit tests in this app of mine :P
16:10:13 <planetmaker> Belugas: he must not be a noob ;-)
16:10:27 <planetmaker> noobs only play with new NewGRFs when they create new games ;-)
16:11:11 * andythenorth_ wonders if BROS could convert bitch-slapping effort into pixels
16:11:15 <andythenorth_> would be quite productive
16:11:25 <planetmaker> andythenorth_: write a conversion script :-P
16:11:49 <andythenorth_> make it a feature in nml
16:11:54 <andythenorth_> they might get something done that way
16:12:19 <planetmaker> I proposed them to use NML (all needed is there) and I offered to get them going
16:12:24 <planetmaker> welshdragon declined
16:13:22 <planetmaker> Instead he posts 'news' in the DevZone about the forums of that set. I wonder how useful that 'news' is...
16:14:01 <andythenorth_> planetmaker: do you see any connection here with why German manufacturing industry is insanely effective, whilst British equivalent is in ongoing decline?
16:14:41 <planetmaker> I tend to not connect personal contacts to macro-economic facts
16:14:52 <planetmaker> or sometims even 'facts'
16:15:17 <planetmaker> they usually don't make for good prejudice ;-)
16:17:03 <andythenorth_> I guess I see a lot of British traits in how the BROS set is being done
16:17:21 <andythenorth_> it's remarkably ineffective result for something that has had so much work on it
16:17:32 <andythenorth_> this data won't migrate on its own :o
16:17:40 <andythenorth_> at, least, not until I press go :)
16:27:50 *** frosch123 has joined #openttd
16:28:29 <planetmaker> frosch123: I'd like to ask for a pony :-)
16:28:49 <frosch123> talk about pressure :p
16:29:09 <planetmaker> I provide food and stables :-)
16:29:57 <planetmaker> actually... I brought a pony... I just need the 'branding' ;-)
16:30:17 <planetmaker> (sounds strange, but my dictionary tells me...)
16:39:00 <planetmaker> but... sorry :-) I don't mean to put pressure on you. Just you're one of newgrf specialists ;-) Bad timing on my part though :-P
16:40:29 *** Adambean has joined #openttd
16:40:52 <andythenorth_> planetmaker: put your ponies in a queue behind my ponies
16:40:59 <frosch123> it could be worse, other guys seem to need a "patch announcement" category on fs
16:41:14 <planetmaker> andythenorth_: I grew this pony ;-)
16:41:33 <planetmaker> and it's about to become mature ;-)
16:41:52 <frosch123> there is no developer "claudia", so what do you need a grown horse for?
16:41:54 <planetmaker> actually... also a pony for you ;-)
16:42:53 <planetmaker> that's the true-hatschie-guy, right?
16:51:02 <frosch123> when loading a game with a compatible grf and then saving it again. does it keep the old version, or does it update the version?
16:51:11 *** HerzogDeXtEr1 has joined #openttd
16:51:38 <Rubidium> I'd say, the new one
16:52:08 <frosch123> also think so, as it updates the md5sum as well
16:52:09 <Rubidium> primarily because forward compatability isn't quite guaranteed
16:52:55 <planetmaker> it should use the new one
16:53:11 <frosch123> hmm, right, was happens if there are only older versions of the grf
16:53:32 <Rubidium> and the game wouldn't be loadable
16:53:33 <frosch123> [18:52] <planetmaker> it should use the new one <- are you sure that the patch does that?
16:53:48 <planetmaker> frosch123: I'm not really sure about that
16:54:15 <frosch123> i would expect some change in IsGoodGRFConfigList
16:56:20 <planetmaker> basically the change is in FindGRFConfig
16:56:39 <planetmaker> which checks also already for the compatibility
16:56:52 <frosch123> yeah, but what about the stuff at line 487
16:57:00 <frosch123> c->version = f->version; <- around that line
16:57:37 <planetmaker> that basically copies the data from the found grf to the currently used one
16:57:42 <planetmaker> for compatible ones
16:57:46 <planetmaker> but incompatible ones never go there
16:58:31 <planetmaker> and as I have the version of the (now) used grf, it will be saved. Do I err there?
16:59:26 <frosch123> you do not copy min_loadable_version there
16:59:31 <frosch123> so what is displayed in the gui?
16:59:35 *** Lurimax has joined #openttd
16:59:40 <frosch123> the old one? and is that intentional?
16:59:53 <planetmaker> Hm... I don't copy the min_loadable_version. Possibly I should copy that there...
17:00:09 <planetmaker> Probably the old one. let's check
17:00:22 <frosch123> well, what is more useful in the gui?
17:00:51 <planetmaker> well. the current min_loadable_version. But usually that's not needed at all...
17:01:01 <frosch123> you also see that stuff before loading the game in the preview
17:02:41 <planetmaker> it definitely makes sense to copy everything :-)
17:03:29 <planetmaker> though... the savegame actually will then not load with the min_loadable_version but only with version henceforth
17:04:14 <planetmaker> But then: it's a newgrf property. Not a savegame one
17:06:37 *** fjb is now known as Guest2039
17:16:32 <planetmaker> ok, line added (locally). The current newgrf version is definitely saved in the savegame, so an older one than currently used will not be accepted
17:17:52 *** Biolunar has joined #openttd
17:18:27 *** Biolunar is now known as Guest2042
17:18:30 <planetmaker> do you need test grfs?
17:21:12 <planetmaker> ok... what question. Added, too
17:22:42 <frosch123> hmm, what to eat next..
17:26:27 <planetmaker> hm... my previous scenario developer patch is now completely independent of this a14 thing :-)
17:38:14 *** Guest2042 is now known as Biolunar
17:45:35 <CIA-2> OpenTTD: translators * r20905 /trunk/src/lang/ (hungarian.txt slovenian.txt):
17:45:35 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:36 <CIA-2> OpenTTD: hungarian - 2 changes by IPG
17:45:36 <CIA-2> OpenTTD: slovenian - 2 changes by ntadej
17:47:39 *** |Jeroen| has joined #openttd
17:50:13 *** Alberth has joined #openttd
17:54:47 *** Chris[A] is now known as Pikel
18:01:28 *** fonsinchen has joined #openttd
18:06:30 *** ajmiles has joined #openttd
18:17:07 *** lobster has joined #openttd
18:34:42 <frosch123> does it need a stupidity test for min_version <= version?
18:35:18 * andythenorth_ runs a migration script and hopes for best :P
18:35:55 *** last_evolution has joined #openttd
18:40:21 <planetmaker> uhm... where, frosch123 ?
18:40:35 <frosch123> somewhere where the author notices it :p
18:40:46 <frosch123> e.g. make the grf unavailable or so
18:41:12 <planetmaker> it will always match if md5sum matches
18:41:32 <frosch123> yes, but won't it cause some havoc later on?
18:41:38 <planetmaker> Though I didn't test that, that's *I think* what will happen
18:41:55 <frosch123> yes, you test firsr for md5sum, then for version :)
18:42:18 <frosch123> though maybe nforenum should learn to check such stuff
18:42:32 <planetmaker> well, still OpenTTD needs to check it, too
18:43:02 <planetmaker> let's see, should not be difficult to add. Just forcing min_loadable_version to be <= version
18:46:39 <planetmaker> is there somewhere a routine for grf sanity check after it has been read?
18:47:05 <planetmaker> static void InitNewGRFFile(const GRFConfig *config, int sprite_offset) ?
18:47:54 <frosch123> there is a check for duplicate grfs, and i would also expect .html files to fail to get added to the list :p
18:51:58 <planetmaker> I think the best place to rectify that is when the files are read
18:53:09 <planetmaker> maybe in bool GRFFileScanner::AddFile(const char *filename, size_t basepath_length) ?
18:53:58 *** trebuchet has joined #openttd
18:56:42 <planetmaker> it might be easy to add at the MINV itself. But then I don't know whether a version will be defined later.
18:59:54 <planetmaker> hm... or better in GetGRFConfig?
19:02:06 <frosch123> + if (c->version < minversion) continue; <- as someone pointed out, shouldn't that be "if (c->version < minversion || c->min_loadable_version > minversion)"
19:02:30 <frosch123> i.e. you do not pass "min.required version" to "FindGRFConfig", but "requested version"
19:03:14 <frosch123> "c->version < minversion" only denies downgrades
19:03:54 <V453000> original acceleration still is as default in a clear new config file?
19:05:09 <planetmaker> frosch123: but if I require a certain version, I only want to make sure that the current newgrf can provide the required version
19:05:21 <planetmaker> and min_loadable_version <= version
19:05:41 <frosch123> well, yes, but currently you are not using min_loadable_version at all :p
19:05:44 <planetmaker> otherwise min_loadable_version would double as a kind of 2nd version
19:06:07 <frosch123> you only display it in the gui
19:06:30 <planetmaker> I use it when loading savegames
19:06:42 <planetmaker> when determining compatibility.
19:07:00 <planetmaker> if I have min_loadable_version=20. And the game was played with 19, I don't load
19:07:40 <frosch123> where? grepping shows no usage
19:08:09 <frosch123> you compare only the version of the available grfs with the version stored in the save
19:08:27 <frosch123> you want to compare the version from the save with both the version and min_version from the available ones
19:09:13 <Rubidium> a14.min_loadable_version <= valid versions for the NewGRF <= a14.version
19:12:27 *** Brianetta has joined #openttd
19:14:55 <Rubidium> oh, was it said that the default min_loadable_version should equal version?
19:15:28 <planetmaker> Personally I'd argue for, if not set, set to 0
19:15:46 <Rubidium> no, that makes NewGRF developers ignore the setting
19:16:15 <Rubidium> if you set the version, then you care and should set the min_loadable_version as well
19:16:23 <planetmaker> frosch123: you're right, it must be if (c->min_loadable_version < minversion) continue;
19:16:53 <frosch123> and you should not call it "minversion"
19:17:08 <Rubidium> IMO it's better to fail during development/testing than when it's actually being used
19:17:18 <planetmaker> requireversion, frosch123 ?
19:17:24 <planetmaker> Rubidium: convinced :-)
19:17:34 <frosch123> something like that, but with some "_" between parts
19:17:41 <frosch123> desired_version or so
19:18:18 <frosch123> and while you change that diff, also change // -> /* */ :)
19:18:50 <planetmaker> yes, I just noticed that I left the comments. Shall I leave them (in the changed form)?
19:19:21 <Rubidium> and desired_version == c->version is the "holy grail", i.e. it's better than the highest version version that can load it (at least for compatible NewGRFs)
19:19:43 <Rubidium> (except when desired_version == 0)
19:19:47 <planetmaker> well. Holy grail is md5sum ;-)
19:20:01 <Rubidium> yeah, but that's already passed when you're starting to check versions
19:20:30 *** fonsinchen has joined #openttd
19:22:29 <Rubidium> oh... no, some licenses don't allow doing that
19:23:51 <planetmaker> hm... that requires me to check for whether the thing was set or not. Thus the simple, if not set=0 (as for a14, version) does not work
19:24:18 <planetmaker> or I cannot allow explicitly setting min_loadable_version=0
19:24:24 <planetmaker> which is bollocks
19:24:43 <Rubidium> just "require" VRSN is set before MINV in the documentation
19:25:00 <frosch123> or default min_version to UINT32_MAX
19:25:04 <Rubidium> then VRSN sets min_version to $VRSN and MINV overrides it
19:25:38 <frosch123> sounds better than my suggestion
19:25:46 <planetmaker> ok, that's it. Easy :-)
19:26:01 <planetmaker> Any way in OpenTTD to enforce, or ensure it?
19:26:07 <planetmaker> Or just assuming that?
19:26:17 <frosch123> hmm, did somewhen read the pillar topic completely? why does he distinguish the bridge types?
19:26:26 <Rubidium> fail for MINV if $VRSN == 0?
19:26:57 <frosch123> planetmaker: "fail if MINV is set befor VRSN"
19:27:20 <planetmaker> oh, you mean... no version=0, then I should issue an error if MINV is set?
19:27:25 <planetmaker> well... yes. why nto
19:27:58 <frosch123> same if MINV > VRSN
19:28:03 <planetmaker> frosch123: bridge pillars: I think he didn't quite understand how they were drawn, where the sprites came from. Maybe he did now, but I'm not quite sure
19:28:19 <planetmaker> yes. So all that check in the MINV check in a14. Quite fine and easy :-)
19:39:20 *** blathijs has joined #openttd
19:41:20 <andythenorth_> what work to do
19:52:22 <frosch123> hmm, let's see whether 0.5 compiles
19:52:57 <frosch123> it does, and how fast ...
19:54:24 <planetmaker> why the heck do you need 0.5?
19:54:44 <andythenorth_> maybe it's FIRS 0.5 :P
19:54:47 <frosch123> i want to know how bridgepillars looked pre r4430
19:54:55 <andythenorth_> maybe frosch123 finished FIRS while I wasn't looking?
19:56:23 <frosch123> "can't build bridge here... level land or water required under bridge" :o
19:56:59 <planetmaker> dang. compiled wrong stuff. Used qpop instead of qpush :-P
20:02:08 <frosch123> hmm, did i pick the wrong revision...
20:03:23 <planetmaker> what's the suggested grf debug level for complaining about wrong MINV or MINV before VRSN? 0?
20:08:09 <frosch123> last occurence of SPR_PILLARS_BASE was removed in r8129, though the commit message does not suggest that
20:08:23 <frosch123> maybe it was already not used at that point
20:09:13 *** Progman has joined #openttd
20:11:35 <frosch123> ok, 0.4 draw pillars slightly different
20:13:42 <frosch123> so, seems like there is a lot of unsed sprites in openttd.grf since r4430 resp 0.5 :o
20:15:16 <planetmaker> in extra there are no pillars used
20:15:22 <frosch123> looks like the pillar length is actually more correct in 0.4
20:15:27 <planetmaker> only default ones
20:15:55 <frosch123> so i guess ottd did some "better" solution back then, which was later trashed for newgrf compatibility
20:16:07 <DorpsGek> frosch123: Commit by Darkvater :: r4430 /trunk (table/bridge_land.h tunnelbridge_cmd.c) (2006-04-15 16:07:00 UTC)
20:16:08 <DorpsGek> frosch123: - NewGRF: Use the bridge's sprite layout for drawing high pillars. This fixes newgrf's high-bridge pillars drawing. Also remove the now obsolete _bridge_poles_table which was already integrated into the bridge sprite tables
20:17:37 *** Fixed was kicked by DorpsGek (Wrong channel. Retry in #openttdcoop.)
20:19:00 <frosch123> that actually explains why ottd distinguished in such a weird way between drawing pillars for high bridges and low bridges
20:19:13 <frosch123> they used completely different sprites in 0.4 :o
20:23:15 *** lobstar has joined #openttd
20:28:00 <frosch123> but yes, now i remember that i somewhen wondered about bridges having less pillars when higher
20:29:05 *** scott1429 has joined #openttd
20:29:49 <frosch123> oh, and the bridges have a pillar at the south and none at the north
20:31:13 <scott1429> hi can i get new buses for locomotion
20:31:42 <planetmaker> also... a14 MINV queue updated
20:31:57 <planetmaker> scott1429: ask in a locomotion channel. This is OpenTTD
20:37:08 <planetmaker> dihedral: I'm quite sure that it's a valid bug report
20:37:44 *** Brianetta has joined #openttd
20:37:54 <planetmaker> g'night andythenorth_
20:44:02 <dihedral> planetmaker, it does look rather odd - i just could not imagine a silly report coming from that person either :-P
20:44:29 <dihedral> however - why, if it's a valid bug report, make it from a not so valid situation
20:44:58 <dihedral> or, is the bug only noticeable with his additions, and why would it then be a bug
20:45:23 <dihedral> and i totally do not get what he is on about :-D
20:45:51 <planetmaker> he just made desasters like a common thing happening constantly. For testing purposes
20:46:12 <planetmaker> heightlevels was what he tested
20:46:31 <planetmaker> see that thread and you understand where he comes from :-)
20:47:07 <dihedral> it's just not mentioned in his bug report
20:49:27 <frosch123> if (best == NULL || c->version > best->version) best = c; <- lacks the "matching version is best" case
20:51:53 <planetmaker> It doesn't need to. Because the best one is the one with the highest version
20:52:23 <frosch123> i thought we said, the bestone is the one with the same version?
20:52:26 <planetmaker> Only point would be to stop the recursion
20:53:44 <planetmaker> If we look for desired_version. and skip all where version > desired_version...
20:54:07 <planetmaker> ...we're left with taking the current version, if ithe existing best is lower
20:54:19 <planetmaker> thus current can at most (and best) be desired_version
20:54:50 <frosch123> so you need to revert the test in that line
20:55:06 <frosch123> pick the lowest version which passes the c->version < desired_version test
20:55:22 <frosch123> unless desired_version is 0
20:56:16 <frosch123> oh "(set 0 0 if not relevant" fails at the min_loadable_version > desired_version
20:57:49 <planetmaker> I somehow still don't follow you. Seems I'm slow
20:58:35 <planetmaker> we have current best->version with best->min_loadable_version and look for desired_version
20:59:15 <frosch123> if desired_version is 0, we do not want to test min_loadable_version at all, and just pick the highest version
20:59:35 <frosch123> if desired_version is not 0, we wand to pick the lowest version which passes the c->version < desired_version || c->min_loadable_version > desired_version test
21:01:12 <frosch123> hmm, though if a save has a grf with no version information, it would pick the newest one
21:01:26 <frosch123> does not sound right either
21:01:43 <planetmaker> desired=0 should not need special treatment
21:01:52 <Rubidium> but only if the md5sum doesn't match, right?
21:02:12 <planetmaker> md5sum + grfid the same overrules everything
21:02:35 <frosch123> + if (c->version < desired_version || c->min_loadable_version > desired_version) continue; <- in any case: that line contradicts "(set to 0 if not relevant)"
21:04:18 <planetmaker> The default value is 0...
21:04:43 <planetmaker> Actually it's only used when the md5sum is NOT set.
21:04:49 <planetmaker> So only the comment is wrong
21:04:58 <frosch123> const GRFConfig *best = FindGRFConfig(c->ident.grfid, NULL); <- that call from BuildAvailables() in newgrf_gui.cpp needs the return the newest version. loading savegames without version information resp. with grfs without version information should not necessarily pick the highest version
21:04:59 <planetmaker> But it needs a default value in order to compile
21:05:44 <frosch123> planetmaker: but, it seems the default value is wrong, as different behaviours are needed at different places currently using the default
21:07:22 <frosch123> hmm, i guess PrintGrfFilename in gamelog.cpp seems to print the wrong filename in some cases
21:07:31 <frosch123> (sorry off-topic :p )
21:11:40 <planetmaker> hm... desired_version=UINT32_MAX when looking for compatible newgrfs with version=0?
21:16:26 <planetmaker> going through possibilities:
21:16:52 <planetmaker> assuming we have a savegame with desired_version=0. Then we do find the highest version one as best is highest version
21:17:49 <planetmaker> assuming we have a savegame with desired_version=5. Then we skip all version0 ones
21:19:06 <frosch123> yeah, the "pick same version" condition is kind of tricky with "no version"
21:19:26 <planetmaker> hm... but then indeed we want the lowest version
21:19:44 <planetmaker> why not the highest one which loads our game just fine?
21:19:57 <planetmaker> Would make more sense
21:20:46 <frosch123> i do not know exaclty what ais do, but they changed it several times
21:20:46 <planetmaker> I mean... It's like when I have an old savegame to say that I should better play it with OpenTTD 0.5.3 than current trunk - as 0.5.3 is more similar to what was used back then
21:21:14 <planetmaker> well... highest compatible, if not an exact match, I say
21:21:59 <planetmaker> otherwise it makes no sense to provide update newgrfs
21:22:06 <planetmaker> which is what this setting shall allow
21:24:02 <frosch123> yeah, looks like ais do the same
21:24:10 <planetmaker> and... if I don't have a mental knot in my mind, it'll always pick the newest one (within the limits of min_loadable_version <= desired_version <= version)
21:24:25 <frosch123> though ais test the version instead of md5sum
21:24:45 <planetmaker> well. yes. But we shouldn't skip md5sum. We must not
21:25:10 <frosch123> so, remains the question whether ottd should pick a grf with the exact same version but different md5sum over a newer version
21:25:39 <planetmaker> I don't think really.
21:25:58 <planetmaker> If it's the same, then md5sums should match
21:26:13 <planetmaker> If they don't match it's fishy and anyway only compatible. Then we can also pick the newer one
21:27:23 <planetmaker> otherwise one could add a if c->version = desired_version return c
21:28:37 <frosch123> ok, remains the issue with "just pick the newest, do not test any min version"
21:28:55 <planetmaker> when do you need that, frosch123 ?
21:28:56 <frosch123> that needs some special value for desired_version
21:29:04 <frosch123> planetmaker: for the gui
21:29:15 <frosch123> else it will not show grfs with min_version > 0
21:29:24 <frosch123> that is newgame-gui
21:29:54 <frosch123> take a look at BuildAvailables
21:30:16 <frosch123> const GRFConfig *best = FindGRFConfig(c->ident.grfid, NULL); <- that line should get the newest one
21:30:23 <frosch123> not the newest one being able to load version 0
21:31:41 <frosch123> otoh, a savegame using an old grf without version (i.e. version 0) should indeed pick the newest one being able to load version 0 :)
21:31:49 <frosch123> so "0" is no good default value
21:32:11 <frosch123> it needs some special value, either some extra bool parameter, or maybe UINT32_MAX will do
21:32:13 <planetmaker> but... it does show the newest here
21:32:21 <planetmaker> with a min_loadable_version=50
21:33:50 <frosch123> did you maybe enable newgrf_show_old_versions?
21:35:11 <planetmaker> I've both: the 0-compatible one and the 50-compatible one
21:35:18 <frosch123> or is the newest version being able to load version 0 in face one with version 0?
21:37:16 <planetmaker> can you rephrase?
21:38:25 <frosch123> there is a test at the bottom, when grfs are added to the list
21:38:37 <frosch123> if "best" is not the newest grf, that will fail
21:38:50 <frosch123> and "best" is currently only the newest grf being able to load version 0
21:42:13 <planetmaker> but it reads const GRFConfig *best = FindGRFConfig(c->ident.grfid, NULL, c->version);
21:42:38 <planetmaker> So we find... currently several
21:42:58 <planetmaker> I guess we would find FIRS 0.3 and 0.4 - if it had this feature
21:43:44 <planetmaker> So we use the best one compatible with the current version.
21:44:04 <frosch123> actually makes sense :)
21:44:42 *** Progman has joined #openttd
21:44:49 <planetmaker> I guess it returns anyway more than I initially intended
21:45:21 <planetmaker> if newgrf_show_old_versions = 0 it should only return the newest.
21:46:36 *** last_evolution has quit IRC
21:46:58 <frosch123> i guess i would trash the default parameters for FindGRFConfig, and check every occurence for the correct ones
21:47:06 <frosch123> but, now i need some sleep :)
21:47:45 *** valhallasw has joined #openttd
21:55:21 *** Prof_Frink has joined #openttd
21:56:07 *** glx is now known as Guest2075
22:14:31 <Zulm> hello is openttd compatible with transport tyccon (not delux ) ?
22:15:11 *** ProfFrink has joined #openttd
22:16:54 <Rubidium> it can load its savegames if that's wat you mean
22:16:58 *** ProfFrink is now known as Prof_Frink
22:18:03 *** ajmiles has joined #openttd
22:21:56 *** roboboy has joined #openttd
22:38:14 *** ChanServ sets mode: +v tokai
23:03:31 *** Chris_Booth has joined #openttd
23:33:49 <Dagda> SOmething strange, I cant buy any copters (empty list), they are all old, and no new model ...
23:34:23 <Dagda> I msu wait more (time game), or no more, and i can delete copter buildings ?
23:34:57 <TruePikachu> Under the advanced options, enable "vehicles never expire",
23:35:22 <Dagda> Defaults ? I dont know, I downloaded some langage citu name, the soud pack, and some cards/scripts, but i play with "nex gme"
23:35:29 <TruePikachu> and then, in console (`; key to the left of 1/!), type "resetengines"
23:35:51 <TruePikachu> I'm meaning the default vehicles; no vehical NewGRF loaded
23:36:12 <TruePikachu> Either way, the procedure will give you all vehicles which have been availible
23:36:13 <Dagda> Ok for the "tips", but is it normal ?
23:36:23 <TruePikachu> Ye; see the Wiki page for the airports
23:36:38 <TruePikachu> Helicopters become unavailible somewhere between 2030 and 2050
23:36:54 <Dagda> ok, it's normal, in 2045 no copter in the sky ;)
23:37:31 <TruePikachu> Well, after disabling expiration and resetting the pool, you should have them back
23:38:07 <Dagda> no, if it's normal, i will play with this
23:38:37 <Dagda> i note the tips, if my idea change :p
23:39:17 <TruePikachu> Also, you _might_ want to look into PikkaBird's Av8tors NewGRF
23:39:52 <TruePikachu> There are some helis that never expire there, and lots of aircraft that can carry all types of cargo (not just the express cargo)
23:40:39 <Dagda> ok, this pack is in my text file, thx again !
23:40:56 <Dagda> many thing to try with this game
23:41:32 <Dagda> Ho, do you know another game, like this ... the name is not far "trans simu"
23:44:40 *** roboboy has joined #openttd
23:53:27 <Dagda> some graphics are good, but the full 3D univers is very strange (youtube videos)
23:54:01 <Dagda> there is some packs for upgrading the openttd original V1 game ?
continue to next day ⏵
