IRC logs for #openttd on OFTC at 2011-01-22
⏴ go to previous day
00:20:34 *** lightekk is now known as AFK|lightekk
00:21:01 <__ln__> AFK|lightekk: no public aways, please
00:24:22 *** Razmir is now known as Guest1122
00:26:27 *** Guest1122 has left #openttd
00:44:01 <DJNekkid> ('finished' nutracks)
00:44:15 <DJNekkid> ./</shameless self-add>
00:48:00 <FauxFaux> NutRacks sounds like a very painful torture device.
00:48:20 <Pulec> any videos to explain to super stupid?
00:49:04 <Pulec> forget it i dont wanna know :D
01:12:46 *** roboboy has joined #openttd
01:33:46 *** roboboy has joined #openttd
02:18:50 *** roboboy has joined #openttd
03:05:20 *** tokai|mdlx has joined #openttd
05:41:13 *** Eddi|zuHause2 has joined #openttd
05:56:18 *** Eddi|zuHause2 has joined #openttd
06:33:54 *** Wizzleby has joined #openttd
06:35:11 *** Wizzleby is now known as Guest1154
06:35:19 *** Guest1154 has left #openttd
06:47:49 *** andythenorth has joined #openttd
06:55:26 *** roboboy has joined #openttd
07:01:23 *** andythenorth has joined #openttd
07:10:09 *** DayDreamer has joined #openttd
08:02:59 *** HerzogDeXtEr has joined #openttd
08:10:33 *** andythenorth has joined #openttd
08:28:32 * andythenorth wonders how planes choose different sprites for take off / level flight
08:29:05 <andythenorth> can't see any special action 3 handling in the spec
08:36:33 <dihedral> you could check how its done in av8
08:38:14 <andythenorth> I'll just invent something - this is for ships anyway :)
08:38:35 <dihedral> i did not know they fly
08:42:24 <andythenorth> dihedral: hydrofoils ;)
08:42:37 <andythenorth> I guess it is actually flying of a sort
08:45:13 <andythenorth> hydrofoils should 'taxi' as they get close to a dock :P
08:45:17 <andythenorth> state machine...
08:48:36 <andythenorth> someone should have cookies for design of standard action 1 / 2 /3
08:50:34 <dihedral> either that - or you define them as planes which need special airports / runways :-)
08:51:02 <andythenorth> they might fly a bit high...
08:52:13 <dihedral> yes and they could then fly over land too :-P
08:52:33 <andythenorth> maybe hovercraft should be planes :P
08:52:53 <andythenorth> but with a new cb to specify altitude
08:53:02 * andythenorth ponders reading plane code
08:53:26 <dihedral> nah - making them planes is not correct ;-)
08:53:44 <dihedral> you'd lave at seeing a hydrofoil passing over houses :-P
08:59:23 *** Alberth has joined #openttd
08:59:23 *** ChanServ sets mode: +o Alberth
08:59:25 <andythenorth> B4 W Current speed (note, units different for each vehicle type)
08:59:39 <andythenorth> how the units are different is not explained :D
09:07:32 <andythenorth> ships need realistic acceleration option :P
09:20:33 *** andythenorth has joined #openttd
09:49:33 *** fonsinchen has joined #openttd
09:53:38 *** AFK|lightekk is now known as lightekk
09:53:44 <CIA-2> OpenTTD: rubidium * r21886 /trunk/src/ (33 files in 6 dirs): -Codechange: move documentation towards the code to make it more likely to be updated [n].
10:03:28 *** frosch123 has joined #openttd
10:04:50 *** tycoondemon has joined #openttd
10:11:06 <CIA-2> OpenTTD: rubidium * r21887 /trunk/src/ (network/core/tcp_admin.h newgrf_industrytiles.h road_gui.h): -Fix-ish: some headers weren't including the headers they depend on
10:15:36 *** HerzogDeXtEr has joined #openttd
10:33:30 <CIA-2> OpenTTD: rubidium * r21888 /trunk/src/ai/ (64 files in 2 dirs): -Codechange: remove some unneeded (for the AI header) headers from some AI headers, reducing the include tree
10:35:07 *** andythenorth has joined #openttd
10:46:05 *** tycoondemon has joined #openttd
10:54:07 *** Adambean has joined #openttd
11:07:35 *** TheDirtyOne has joined #openttd
11:10:49 *** Xaroth_ has joined #openttd
11:16:05 *** Eddi|zuHause2 has joined #openttd
11:16:27 <TheDirtyOne> why does OTTD look for the config and content at my documents?
11:16:34 *** einKarl has joined #openttd
11:18:20 <TheDirtyOne> so for valid installation I do this: Unpack OTTD to the folder in my documents tat it wants to use, unpack the opengfx to data.
11:18:59 *** Progman has joined #openttd
11:20:39 <Terkhen> it looks at another places too, check the readme
11:21:13 <Terkhen> and OpenTTD can be unpacked anywhere, it does not need to be at that folder
11:25:52 <TheDirtyOne> it checks at its install place, but prioritizes my documents and creates the config there
11:27:07 <Alberth> it has to create the config someplace
11:27:28 <TheDirtyOne> so why does it create it into documents, not into itself?
11:27:40 <Alberth> but read the readme, it has detailed explanations on what it all does
11:28:17 <Alberth> I guess becauses of shared installs
11:28:26 <TheDirtyOne> and there's one more weirdness - sound/music
11:29:21 <TheDirtyOne> ottd with legacy pack (full with sfx) takes the same space as openttd with opengfx alone
11:37:00 <Terkhen> TheDirtyOne: the installer is not intended for creating portable installations
11:37:06 *** andythenorth has joined #openttd
11:37:33 <Terkhen> download the zip archive and use its own data folder if you want to have everything in the same folder
11:38:06 <Terkhen> but IMO having them in the My documents folders is more useful, then you don't lose your data and savegames if you reinstall
11:42:04 <TheDirtyOne> Terkhen: zip tries that too.
11:42:32 <Terkhen> you need an openttd.cfg file there too
11:43:00 <Terkhen> as I said, check the readme
11:43:01 *** KenjiE20 has joined #openttd
11:43:38 <TheDirtyOne> zip just lacks the cfg
11:44:00 <TheDirtyOne> just one empty file with .cfg extension.
11:44:11 <Alberth> no, otherwise it would overwrite an existing cfg
11:44:17 <Alberth> and it gets created anyway
11:44:43 <TheDirtyOne> it gets created in documents automatically
11:45:34 <TheDirtyOne> is there a switch to make it into exe's folder?
11:45:50 <Terkhen> believe me, it's all explained in the readme
11:47:14 <TheDirtyOne> oh, 1.05 got rid of this - files get found even with an outside cfg
11:50:24 <Alberth> way way before that version already, actually, afaik
11:53:25 <TheDirtyOne> and why are there 2 music files in content system?
11:53:29 *** roboboy has joined #openttd
11:53:44 <TheDirtyOne> openmsx and anthology-something
11:54:26 <TheDirtyOne> is OTTD compatible with patched MIDIs?
11:55:18 <planetmaker> depends upon what you call a 'patched midi'
11:55:32 <TheDirtyOne> FeelSound patching
12:03:05 <TheDirtyOne> fixing might be needed for MIDIs with bad instrument codes, and so on...
12:03:42 <planetmaker> Should work to just modify an existing midi
12:03:46 <Alberth> I have no clue at all what that means
12:05:12 <TheDirtyOne> planetmaker: PSMPlayer makes fixing/feelsound patching easy
12:05:44 <planetmaker> I've not heart of any of those tools, sorry
12:06:02 <TheDirtyOne> I managed, over chat, to guide one person to fixing the MIDI file that was causing MIDI library misinterpreting instruments.
12:06:18 <TheDirtyOne> Just get PSMPlayer - it's very small.
12:08:14 <Alberth> we have had enough commercials now, thank you
12:10:06 <planetmaker> oh no. definitely not. and not for my OS
12:10:39 <TheDirtyOne> it's not advertising. It's a win32 app to work with MIDIs.
12:12:07 <planetmaker> see. the point. Nothing which is remotely usable for me
12:12:11 <Alberth> whatever, nobody is interested
12:12:46 * TheDirtyOne is a sick, mindless fatty that plays random games and is always full of weird//stupid questions...
12:13:04 *** TheDirtyOne has left #openttd
12:14:00 <Terkhen> explodes == never will come back?
12:14:44 <Alberth> don't get your hopes up too much :)
12:19:48 <andythenorth> anyone playing FIRS?
12:19:55 <andythenorth> I am wondering what to work on
12:22:55 <Alberth> so many projects, and still out of ideas :)
12:22:58 <Terkhen> I have not played FIRS in a long time
12:23:19 <andythenorth> Alberth: you're out of ideas or me?
12:23:33 <Alberth> hmm, perhaps it is time to try playing FIRS again
12:23:39 <Alberth> andythenorth: I meant you
12:23:55 <andythenorth> what I don't have is an easy way to prioritise :)
12:24:04 <andythenorth> I did have DanMacK sending me sprites for a bit
12:24:10 <andythenorth> that set a direction for FISH
12:24:24 <andythenorth> but he's not here today ;)
12:25:52 *** Markavian has joined #openttd
12:32:20 *** ZirconiumX has joined #openttd
12:32:42 *** JOHN-SHEPARD_ has joined #openttd
13:07:28 *** Chris_Booth has joined #openttd
13:18:28 <ZirconiumX> I think BR had a maglev prototype - around 1970
13:23:26 <frosch123> yeah, ottd should also have an option to waste lots of money into researching prototypes which will never become available
13:23:53 <ZirconiumX> "I had a million - but now I don't..."
13:24:52 <ZirconiumX> "I spent it on ill-fated prototypes - and now everyone hates me for spending their money..."
13:36:28 *** andythenorth has joined #openttd
13:37:38 <andythenorth> wallyweb has got a bit excited about electricity :o
13:38:06 <andythenorth> a power circuit is just a lot of little men passing buckets of charge to each other yes / no?
13:38:12 <andythenorth> that's what we drew in school anyway :P
13:42:15 <__ln__> i don't think such a fundamental phenomenon of physics could have changed since you were in school. (whenever that was)
13:43:34 <Alberth> except it are actually 'holes' that move from+ to - :)
13:43:59 <Alberth> (or electrons that move from - to +)
13:44:57 <andythenorth> adding an actual electrical grid seems somewhat overkill
13:46:16 <andythenorth> however....if the map could handle storing point values of arbitrary properties like charge....
13:46:34 <andythenorth> ...then a 'proper' spot price economy would also be possible
13:47:45 <Alberth> I fail to see the point of it all, play simcity instead would be much easier
13:48:05 <andythenorth> everyone has their pet project :D
13:48:12 <andythenorth> mine is roadtypes :P
13:49:26 <andythenorth> and also rv-wagons
14:00:44 <devilsadvocate> you could model it as something that satisfies poisson's equation
14:01:30 <devilsadvocate> put in sources at power plants, sinks at usage points, and then charge people based on 'availability' at that specific point
14:02:00 <devilsadvocate> of course, that way, you can end up 'using' more than you produce
14:02:37 <devilsadvocate> but solving actual power flow equations would be a big more ugly
14:09:57 <Terkhen> andythenorth: how do you enable CB1D?
14:11:22 <Rubidium> Alberth: we already had the idea to have a cargo "electrons", so you ship 1 ton of electrons per train or something ;)
14:12:45 *** Brianetta has joined #openttd
14:15:36 <andythenorth> Terkhen: I was going to say extend prop 17
14:15:45 <andythenorth> but if it's a byte, it's full :P
14:15:53 <Alberth> in fact, we are already shipping electrons in toyland batteries
14:16:38 <andythenorth> or a new action 0 prop is needed
14:16:55 <frosch123> if trains have no flag for 1d, rv should not have one either
14:17:02 <Terkhen> using 17 would be the most desirable option, yes
14:17:14 <andythenorth> frosch123: that presents an interesting conundrum
14:17:31 <Terkhen> yes, as it makes sense that the default behaviour is identical to what we have now
14:17:31 <andythenorth> that means either all RVs become attachable, or none
14:18:21 <andythenorth> so every single vehicle that is attachable has to explicitly handle cb 1D?
14:18:41 <frosch123> just as every train vehicle which is not attachable, right?
14:18:49 <Terkhen> but wouldn't that make handling of the CB different between trains and road vehicles?
14:19:07 <andythenorth> frosch123: train vehicles are attachable by default though?
14:19:15 <andythenorth> so the inverse :)
14:19:30 <frosch123> Terkhen: usually "failed callback" is defines as "default behaviour as if the cb was not enabled"
14:19:35 * andythenorth wonders what fraction of road vehicles *should* be attachable
14:19:44 <frosch123> so, it is perfectly fine, if failed cb means different things for trains and rv
14:19:52 <andythenorth> buses generally probably aren't attachable
14:19:54 <Terkhen> yes, that's what I meant
14:20:00 <andythenorth> trucks don't attach to each other
14:20:10 <Terkhen> I guess they would only differ on the handling of "failed cb"
14:20:12 <andythenorth> so basically trailers would need to handle CB1D to become trailers
14:20:18 <Terkhen> andythenorth: none by default
14:20:25 <frosch123> in fact, it would be uncommon if failing cb 1d for rv would allow attaching
14:20:44 <andythenorth> do it the other way - explicitly enable attaching
14:21:19 <frosch123> andythenorth: actually i see no point in generally allowing any attaching
14:21:28 <frosch123> that would allow attaching a bus to a truck engine
14:22:18 <frosch123> just take a look at the tons of complains, that trains allow attaching wagons from other grfs
14:22:28 <Terkhen> my preference for adding a callback flag was for not handling the CB1D differently, but I don't really mind if it is only the failed cb result
14:22:45 <frosch123> if rv engines allow attaching busses from other sets, that will certainly cause a lot of trouble
14:22:46 <andythenorth> frosch123 there are probably as many complaints the other way? :P
14:22:49 <andythenorth> anyway, I'm convinced
14:22:53 <andythenorth> by your argument
14:23:16 <andythenorth> so I should change the spec - default is to fail with the default message
14:24:18 *** ZirconiumX has joined #openttd
14:24:26 <frosch123> not sure. i guess there is some difference between attaching rvs and trains
14:25:01 <frosch123> while you can attach most rv wagons to any rv which can accept some wagon, you usually cannot attach multiple rv engines
14:25:24 <andythenorth> I think that would have to be handled by the newgrf author
14:25:31 <frosch123> just because your truck can pull any trailer, it cannot pull every engine
14:26:12 <frosch123> so, maybe multiheaded-compatible could be a misc flag for rv
14:26:27 <frosch123> i.e. most engines can only be put at the front, not as secondary engines
14:26:34 <andythenorth> I can think of edge cases where multi-headed RVs are desirable
14:26:40 <andythenorth> but they are definitely non-standard
14:27:03 <Terkhen> IIRC for starters we were going to disallow all multiheaded
14:27:13 <Terkhen> introducing a flag latter for those special cases would make sense
14:28:45 <andythenorth> really we could live without them
14:29:16 <andythenorth> Terkhen: don't we need to disallow them under the current RV acceleration model?
14:29:22 <andythenorth> RVs can't have powered trailing vehicles yes / no?
14:29:51 <Terkhen> I don't remember how is that handled, but since the code between trains and road vehicles is unified the change required should be minimal
14:30:11 <frosch123> andythenorth: articulated parts are never powered for consistency
14:30:20 <frosch123> that does not hold for separately attached things
14:30:45 <andythenorth> but would there be any harm in the spec saying "'Engines' cannot be attached as trailing vehicles. "
14:31:34 <devilsadvocate> in RV, you mean?
14:31:36 <frosch123> am i right, that multiheaded rv usually consist of the same type of engine, i.e. are more like multiple-unit trains?
14:31:36 <andythenorth> means I can't add multiple bulldozers to a consist :P
14:31:55 <frosch123> and train MUs are not done via attaching multiple engines these days
14:32:04 <andythenorth> frosch123: multi-headed RVs are basically some form of heavy-haulage unit
14:32:19 <andythenorth> it would be 'nice' to be able to attach them, but not necessary
14:33:42 <andythenorth> frosch123: Terkhen i.e. I would like to include these in HEQS, which could be done as articulated RV, but much better creating a consist with attaching:
14:37:07 <Terkhen> what about the trams? :)
14:37:34 *** Biolunar has joined #openttd
14:37:45 <andythenorth> multi-headed trams - good point
14:38:17 <andythenorth> and also there might be a case for creating consists of PAX trams
14:38:36 <andythenorth> so if there's no implementation problem, engines should be attachable (if allowed)
14:38:49 <andythenorth> does that need a flag on the lead vehicle, the one being attached, or both?
14:39:10 *** EyeMWing has joined #openttd
14:39:10 *** FauxFaux has joined #openttd
14:39:10 *** Rubidium has joined #openttd
14:39:10 *** weber.oftc.net sets mode: +ov Rubidium Rubidium
14:40:10 *** mikegrb has joined #openttd
14:40:34 *** Eddi|zuHause2 has joined #openttd
14:40:34 *** lasershock has joined #openttd
14:40:34 *** Belugas has joined #openttd
14:40:34 *** glevans2 has joined #openttd
14:40:34 *** oxygen.oftc.net sets mode: +ov Belugas Belugas
14:40:34 *** Markavian has joined #openttd
14:40:34 *** Born_Acorn has joined #openttd
14:44:26 <frosch123> andythenorth: i guess a flag for the second engine, and the usual cb for the front
14:46:04 <frosch123> wrt. trams: you do not need to attach multiple engines. isn't it more plausible than someone introduced a passenger wagon with livery override just as for trains?
14:46:34 <andythenorth> I don't understand livery over-rides
14:46:57 <frosch123> take a look at the train sets
14:47:04 <andythenorth> how would I combine two articulated trams?
14:47:16 <frosch123> they have a mu wagon which you can attach to other mu-engines
14:47:35 <andythenorth> is the mu wagon powered?
14:47:56 <andythenorth> so do RVs need powered wagon concept?
14:47:59 <planetmaker> there's a powered wagon CB
14:48:10 <planetmaker> rv don't need that imho
14:49:27 <frosch123> afaik the wagons are not powered usually, but the engine reports different power via cb36 depending on the number of attached wagons
14:49:44 <andythenorth> I can't think of a case where it would be needed for RVs
14:50:09 <andythenorth> do PAX trams need powered wagons?
14:51:43 <frosch123> you talked about attaching multiple trams
14:51:56 <frosch123> that can be done by attaching engines, or by attaching wagons
14:51:58 <andythenorth> I think that's cleaner
14:51:59 <CIA-2> OpenTTD: rubidium * r21889 /trunk/src/main_gui.cpp: -Fix [FS#4434]: crash when scrolling outside of the main window (with some video backends)
14:52:13 <andythenorth> I can't see a case for powered RV wagons using CB
14:52:17 <frosch123> andythenorth: might be, but it is not the way it is done for trains usually :)
14:52:31 <frosch123> at least in the train sets i used
14:52:35 <CIA-2> OpenTTD: rubidium * r21890 /trunk/src/ (95 files in 10 dirs): -Cleanup: remove some unneeded includes
14:52:38 *** tokai|mdlx has joined #openttd
14:52:38 *** Maedhros has joined #openttd
14:52:42 <frosch123> maybe planetmaker knows better
14:52:44 <andythenorth> but trams != trains...
14:52:57 <frosch123> but, ottd player == ottd player
14:53:30 <planetmaker> frosch123, I doubt that I know more about newgrfs than you ;-)
14:54:05 <frosch123> i am sure you played with more, and know whether you attach wagons or engines to mus
14:54:19 <andythenorth> frosch123: I am confused :) do you make case for or against having powered wagon cb?
14:54:22 <planetmaker> wagons are attached to mus
14:54:24 <frosch123> esp. as i dislike pax transporation and usually only do cargo
14:54:52 <frosch123> andythenorth: i am agains attaching multiple tram engines to make trams longer
14:54:53 <planetmaker> and they can have a powered wagon CB and thus provide power.
14:55:37 <andythenorth> I think it would be weird to have a 'tram' and then a 'fake tram'
14:56:01 <frosch123> andythenorth: how do you control the length of the tram?
14:56:13 <frosch123> do you attach multiple engines of each 3 articulated parts
14:56:33 <frosch123> or do you build one front, and then attach 5 wagons, which are partially powered
14:56:50 *** ZirconiumX has joined #openttd
14:56:55 <andythenorth> articulated trams seem like fixed units to me
14:57:17 <frosch123> the latter is done by most train sets, the former is done by e.g. the csd train set
14:57:28 <frosch123> take a look at it, i consider it crappy gameplay :)
14:57:52 <andythenorth> so powered wagon cb is needed?
14:58:00 <frosch123> you want to control the length of trams with single wagons, not in bunches of 3 parts
14:58:16 <planetmaker> callback <whatever> defines "can wagon be attached"
14:58:18 <frosch123> andythenorth: not necessarily, there are multiple ways to code that
14:58:31 <planetmaker> that'd be what trains do
14:58:39 <frosch123> planetmaker: that part is easy, it is more about, "this engine can be attached to some other"
14:58:52 <planetmaker> it's the same callback, though
14:58:59 * andythenorth is condused: how to add powered wagons without powered wagon cb ?
14:59:01 <planetmaker> it goes by ID - IIRC
14:59:06 <frosch123> just because you have a truck which can pull every trailer, it does not mean you can attach another truck to it
14:59:12 * Terkhen is confused by the same reason :)
14:59:19 <frosch123> planetmaker: but it is only from the pov of the front, not of the wagon
14:59:44 * andythenorth supposes consist length could be checked and hp adjusted accordingly?
14:59:47 <planetmaker> frosch123, true. But IIRC that works by ID, and you return the CB for 'can attach' true for those vehIDs which you like
14:59:57 <planetmaker> yes, from the engine, indeed
15:00:52 <frosch123> planetmaker: sure, but again: you do not ask the engine which is going to be attached
15:01:11 <frosch123> and that problem is bigger for rv than for trains
15:01:37 <frosch123> for trains it is mostly only about mixing grfs
15:02:15 <planetmaker> frosch123, maybe I did something wrong. But "MU" is an engine property with a CB where I add the singe wagon IDs which I want to allow
15:02:33 <planetmaker> It's quite limited, doesn't allow cross-grf-talk, but... well. It's ok
15:03:03 <andythenorth> I thought the wagon being attached would check for IDs in the rest of the consist.
15:03:09 <frosch123> planetmaker: that part is fine. but now think about the reverse
15:03:21 <andythenorth> if all of those IDs are allowed, allow attaching
15:03:36 <planetmaker> uhm, yes? You mean a wagon which asks whether it wants to be able to be attached?
15:03:39 <planetmaker> Not possible afaik.
15:03:46 <frosch123> planetmaker: exactly
15:03:54 <frosch123> and i think that is important for rv
15:04:06 <frosch123> but it might also be of use for trains
15:04:17 <planetmaker> yes, if for both, please ;-)
15:04:51 * andythenorth had misunderstood cb1D
15:04:56 <planetmaker> indeed, thinking of it, you're right. It just need both: can be attached and wants to be attached
15:05:24 <planetmaker> or better: can tow / can be towed
15:06:20 <andythenorth> some kind of friend / foes list :P
15:06:23 <maddy_> seems gui windows are of type "struct" in current version, but my patch uses "class", will that be a prob?
15:06:58 <frosch123> some compilers complain about deriving struct from class and vice versa
15:07:19 <planetmaker> andythenorth, nah, not explicitly. Just a callback to the (already existing) consist with "can I tow (more)" and another to the new vehicle which reads "can i be towed"
15:08:27 <andythenorth> planetmaker: if checking other vehicle IDs...it will come to a friends / foes list, but in a varaction 2 :D
15:09:21 <fonsinchen> hrm ... refactor smallmap to split out linkgraph overlay in a clean == produce a huge pile of trivial diff
15:09:32 <fonsinchen> not split out linkgraph overlay == ugly
15:10:20 <planetmaker> trivial diffs are more or less easy to review ;-)
15:10:44 <Terkhen> I'm a bit confused about this callback talk, I should try to code something with it before wondering how to make it work
15:10:58 <andythenorth> Terkhen: a train thing?
15:11:00 <fonsinchen> And it's a lot of boring work to produce them.
15:12:58 <fonsinchen> well ... time to create some new branches
15:14:57 <andythenorth> frosch123: so if there was a new cb like 1D, but for the vehicle being attached...
15:15:09 <andythenorth> ....a special flag for 'allow multiple engines per consist' is not needed
15:19:45 <andythenorth> is it a new cb, or a modification of 1D?
15:20:05 <andythenorth> I guess a new cb
15:28:23 <andythenorth> Terkhen: do you need to code a newgrf to get your head around it?
15:32:26 <andythenorth> Terkhen: a good test for rv-wagons might be HEQS 2
15:32:41 * andythenorth is puzzled how version numbers work
15:33:00 <andythenorth> HEQS 1.0 will go into maintenance....so probably there will be HEQS 1.1, 1.2 etc
15:33:08 <andythenorth> probably a branch
15:33:15 <andythenorth> meanwhile HEQS 2 is a redevelopment
15:33:29 <andythenorth> so I guess I just have to use nightly build numbers :o
15:44:10 <Terkhen> andythenorth: I think so, it helped with the rest of callbacks
15:52:29 *** ABCRic is now known as Guest1210
15:53:07 *** Chruker has joined #openttd
16:13:55 *** DayDreamer has joined #openttd
16:16:58 *** andythenorth_ has joined #openttd
16:21:34 <andythenorth_> Terkhen: HEQS wouldn't be a bad place to hack
16:21:41 <andythenorth_> it has both rvs and rail vehicles...
16:21:52 <andythenorth_> and I have a case for new wagons using cb 1D
16:22:05 <Terkhen> I'll have a hard enough time trying to learn how to do it in NML :)
16:29:08 <andythenorth_> nfo puts it into your head with more...force :P
16:30:07 *** Eddi|zuHause2 has joined #openttd
16:30:58 <andythenorth_> cb1D isn't what I need
16:31:14 <andythenorth_> I need the new, unimplemented 'check for this wagon' cb
16:31:34 <Terkhen> andythenorth_: I agree, but NFO also gives you stronger headaches
16:31:50 <andythenorth_> that is the sign of the brain learning :
16:32:08 <andythenorth_> frosch123: what would be a good ID for the new cb?
16:37:26 <frosch123> yup, next free one :p
17:02:38 *** DanMacK has joined #openttd
17:04:42 *** tokai|mdlx has joined #openttd
17:04:42 *** Maedhros has joined #openttd
17:08:06 *** MtlGuard has joined #openttd
17:08:26 *** MtlGuard has joined #openttd
17:11:28 *** MtlGuard has joined #openttd
17:15:30 <andythenorth_> cb 15C looks to be occupied
17:20:27 <__ln__> wouldn't a window seat be nicer
17:20:28 *** SmatZ sets mode: +b *!*@114.243.64.28
17:33:19 *** einKarl has joined #openttd
17:38:23 <andythenorth_> cb1D looks to be train specific at the moment
17:38:40 <andythenorth_> at least, it's defined in train_cmd.cpp
17:38:50 <planetmaker> nice when finally theory and experiment somewhat agree... and two ways to solve one problem give the same result :-)
17:38:55 <andythenorth_> would it be better to unify train / rv stuff before or after adding a cb?
17:39:06 <planetmaker> I earned my dinner today ;-)
17:39:43 <Terkhen> andythenorth_: in which part of train code is it being called?
17:40:06 <andythenorth_> Terkhen: CheckTrainAttachment
17:40:38 <andythenorth_> maybe that calls another function already?
17:40:40 <andythenorth_> that isn't train specific?
17:41:31 <Terkhen> at first glance that function does not have many train specific code
17:41:58 <Terkhen> it would get unified up to ground_vehicle at some point in rv-wagons
17:42:29 *** Kurimus has joined #openttd
17:43:18 <andythenorth_> I should read it more :P
17:43:27 <andythenorth_> (baby bath time right now)
17:55:04 *** ABCRic is now known as Guest1221
18:01:10 * andythenorth_ just fell down the stairs
18:01:10 <andythenorth_> and isn't even drunk :P
18:06:18 <andythenorth_> no damage to my laptop though :P
18:06:24 <andythenorth_> no code was lost :P
18:08:18 <andythenorth_> I don't understand how GetVehicleCallbackParent is handling wagon attachment
18:08:39 <andythenorth_> it seems to offload the check somewhere else, but I can't see where
18:10:25 <andythenorth_> I'm in newgrf_engine.cpp
18:10:26 <peter1138> parent = head of chain
18:11:55 <Rubidium> looks like that callback is "special" in the way that it passes the parent instead of getting the parent from the vehicle
18:12:18 <Rubidium> which makes sense as it's not yet connected, although NewGRFs assume it to be connected for the test
18:12:22 <andythenorth_> and the actual logic for 'allowed / not allowed' -> return value is all in nfo?
18:12:31 <andythenorth_> and the cb just gets back a value from a varaction 2 ?
18:12:59 * andythenorth_ was looking for some 'if' code that won't exist :P
18:13:01 <Rubidium> a few lines later callback is evaluated
18:13:15 <Rubidium> s/callback/callback result/
18:22:07 *** ABCRic_ has joined #openttd
18:22:07 *** ABCRic is now known as Guest1224
18:22:08 *** ABCRic_ is now known as ABCRic
18:45:27 <__ln__> is there a term for the sensation of surprisedness that a frenchman (or a belgian) experiences when he realises the person he's speaking to does not understand french?
18:49:21 <__ln__> 'vousneparlezpasfrançais!?' is a bit long for a term
18:50:20 *** JOHN-SHEPARD has joined #openttd
18:50:34 <__ln__> such an observation usually doesn't stop them from continuing to talk in french
18:51:49 <ABCRic> je ne parle pas français?
18:52:01 *** lightekk is now known as PUB|lightekk
18:52:24 *** fjb is now known as Guest1227
18:54:54 <andythenorth_> frosch123: adding a new attach cb...
18:55:11 <andythenorth_> would that need to be checked after current attach cb check?
18:55:58 <frosch123> i guess it needs calling at the same point in the code. but i guess it does not matter which one first
18:56:25 <andythenorth_> so l982-991 in train_cmd.cpp would basically need repeating?
18:56:27 <Terkhen> will this cause another mayhem such as CB15/CB36? :P
18:56:36 <andythenorth_> and something like this adding:
18:56:37 <andythenorth_> uint16 callback = GetVehicleCallback(CBID_WAGON_ALLOW_ATTACH_TO_CONSIST, 0, 0, head->engine_type, t, head);
18:57:54 <frosch123> you want to call it for the wagon, not for the head
18:59:00 <andythenorth_> vehicle->engine_type?
18:59:12 <CIA-2> OpenTTD: translators * r21891 /trunk/src/lang/ (5 files):
18:59:12 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
18:59:12 <CIA-2> OpenTTD: danish - 1 changes by nurriz
18:59:12 <CIA-2> OpenTTD: japanese - 12 changes by kokubunzi
18:59:12 <CIA-2> OpenTTD: slovenian - 1 changes by ntadej
18:59:13 <CIA-2> OpenTTD: turkish - 107 changes by niw3
18:59:13 <CIA-2> OpenTTD: ukrainian - 60 changes by Fixer
18:59:48 <frosch123> i guess GetVehicleCallback(CBID_WAGON_ALLOW_ATTACH_TO_CONSIST, 0, 0, t->engine_type, t)
19:00:40 * andythenorth_ isn't sure about the invalidate cache stuff
19:00:49 <andythenorth_> does that need repeating if two cbs are handled?
19:01:14 <frosch123> that is only for moving the vehicle
19:01:33 <frosch123> i.e. the function attached the wagon, then calls the callbacks, and detaches the wagon again
19:03:46 *** Cybertinus has joined #openttd
19:04:05 <frosch123> there the wagon is already partly detached again
19:04:23 <frosch123> call the callback immediatelly after the other, and assign the result to callback2 or whateer :)
19:06:37 <frosch123> looks a bit duplicated, but should work
19:07:05 <andythenorth_> so I need to add the cb to newgrf_callbacks.h
19:07:12 <andythenorth_> is it that simple :o
19:07:53 <frosch123> likely also to table/newgrf_debug_data.h
19:16:52 <andythenorth_> frosch123: no cb mask in this case?
19:16:58 <andythenorth_> i.e. I can set CBM_NO_BIT
19:17:27 <frosch123> andythenorth_: i guess it would be better if you change the cb results to < 0x3FF for custom text, 0x400 = allowed, 0x401...
19:17:44 <frosch123> cb1d has no mask either
19:20:22 <frosch123> aren't they sorted by id?
19:23:30 *** JOHN-SHEPARD_ has joined #openttd
19:25:47 <andythenorth_> tabs vs. spaces?
19:26:32 <andythenorth_> silly old xcode
19:27:22 * andythenorth_ should write newgrf to test this :P
19:41:08 <DanMacK> Use a dozer and a trailer to test :P
19:44:51 <Alberth> andythenorth_: Gmund Mog is not very useful is it? 2t fruit & vegetables
19:45:10 <andythenorth_> haul ENSP + FMSP with it
19:45:16 <andythenorth_> or....help with rv-wagons :P
19:45:21 <Terkhen> isn't it is a bit slow for that?
19:46:22 <Alberth> 51km/h is not bad compared to the alternatives No 6 or 8 crawler, at 16/17 km/h :)
19:48:57 * andythenorth_ broke the compile
19:49:07 <Terkhen> I usually use HEQS along with another road vehicle set
19:51:22 * andythenorth_ fixes the compile
19:53:19 <andythenorth_> now to make a newgrf
19:58:18 *** Eddi|zuHause2 has joined #openttd
20:00:41 <Terkhen> hmm... stupid templates
20:12:29 <__ln__> what's the fail part of the photo, everyone seems to have a seat
20:12:55 <Wolf01> they could have used a larger train, see the tracks
20:17:32 <andythenorth_> how do I handle a cb ID that doesn't fit in a byte?
20:17:50 <andythenorth_> do I just go word sized, or do I add 80?
20:27:24 <frosch123> you _always_ have to use words for checking callback ids
20:38:29 <frosch123> that makes use of some downwards-compatibility thing
20:38:48 <frosch123> imagine there would be a callback 0x123
20:38:58 <frosch123> you would put it in the 0x23 case
20:39:32 <frosch123> that's the reason why cb numbering jumped from 3d to 140 :)
20:40:12 <frosch123> everyone was only testing the byte, so when cb 00 to ff would have been assigned, you would be screwed when adding 100
20:43:32 <andythenorth_> not as pretty :|
20:45:04 <andythenorth_> planetmaker: how do I stop make bailing out on a renum error?
20:45:15 <andythenorth_> there's a switch?
20:47:15 <planetmaker> make NFO_WARN_LEVEL=10
20:47:21 <frosch123> btw... is brainfuck highlighting suitable for nfo?
20:47:49 <andythenorth_> it seems to be my saved selection at pastebin :)
20:47:54 <andythenorth_> my new cb doesn't
20:57:16 <andythenorth_> maybe there's more to do to create this cb
21:00:13 <andythenorth_> frosch123: in context of CheckTrainAttachment, what is variable t?
21:00:18 <andythenorth_> the vehicle, or the train it's being attached to?
21:02:49 * andythenorth_ sees some problems
21:03:13 <andythenorth_> callback and callback2 are silly variable names :P
21:03:34 <andythenorth_> and I'm silly for not updating references to callback
21:04:39 <andythenorth_> this might just work :)
21:07:51 <frosch123> on rereading. i guess you need to use GetVehicleCallbackParent() instead of GetVehicleCallback() for this callback as well. looks like the wagon is not attached while calling the callback
21:08:04 <frosch123> but that should not hurt your testgrf
21:09:18 <andythenorth_> frosch123: I had missed something stupid
21:09:24 <andythenorth_> it currently seems to work
21:09:39 <andythenorth_> there is an odd edge case I just found with a savegame
21:09:47 <andythenorth_> so I have enabled 15E for a rail vehicle
21:10:00 <andythenorth_> and return FD to prevent attach
21:10:10 <andythenorth_> but in my savegame these vehicles are already in a consist
21:10:23 <andythenorth_> I can't take vehicles out of the consist to an empty line in depot
21:10:45 <andythenorth_> but might be problematic?
21:11:12 *** Progman_ has joined #openttd
21:12:47 <andythenorth_> I'll screenshot
21:13:15 <frosch123> buy a new wagon to a separate line, then ctrl+drag the whole consist behind it
21:13:23 <frosch123> you should always be allowed to do that
21:15:24 <andythenorth_> you're right about the new wagon method
21:15:31 <andythenorth_> the other behaviour is correct
21:15:41 <andythenorth_> and should only occur in the case of save games
21:16:30 *** Progman_ is now known as Progman
21:17:29 <andythenorth_> frosch123: what else needs to be done for this?
21:17:41 <andythenorth_> you suggested changing the cb return values?
21:19:07 <andythenorth_> the defines (constants?) names should be cleaned up
21:19:39 <frosch123> andythenorth_: you seem to need GetVehicleCallbackParent(), so the parent scope is set up correctly
21:20:05 <andythenorth_> CBID_TRAIN_ALLOW_WAGON_ATTACH is too train specific
21:20:05 <andythenorth_> CBID_WAGON_ALLOW_ATTACH_TO_CONSIST implies specific to wagons
21:20:37 <frosch123> grf version 8 will change all those 0xfd, fe, ff special results, and replace them with >= 400, so you can use all D4xx text itds
21:21:01 <andythenorth_> what's the issue? Some varacts will fail if they reference (e.g. 82)?
21:21:13 <frosch123> i am not sure whether it is better to do that in advance for new callbacks, or whether it is better to make cb 1d and 15e consistent
21:21:46 <frosch123> andythenorth_: the cb is called while the wagon is not attached, so parent scope will refer to the wagon as well
21:21:55 <frosch123> so you cannot access the head
21:22:12 <andythenorth_> do I need to use head->engine_type in params?
21:22:19 <andythenorth_> instead of t->engine_type
21:24:58 <andythenorth_> but I do need to add head to params?
21:24:58 <frosch123> you need to append head as the additional parameter to the other function
21:25:02 <andythenorth_> or it doesn't compile :)
21:25:16 <andythenorth_> uint16 callback2 = GetVehicleCallbackParent(CBID_WAGON_ALLOW_ATTACH_TO_CONSIST, 0, 0, t->engine_type, t, head);
21:25:30 <andythenorth_> callback2 looks like a silly name to me
21:26:07 <frosch123> i guess keep the cb results as they are
21:26:29 <andythenorth_> so should I clean up the var names callback and callback2?
21:26:38 <andythenorth_> I don't really know the ruling style :P
21:26:44 <frosch123> if you can come up with good ones :) i cannot :p
21:26:54 <andythenorth_> callback1 and callback2 :P
21:27:19 <andythenorth_> cb_result_1, cb_result_2
21:27:38 <frosch123> then i prefer wagon_callback and engine_callback
21:28:37 <andythenorth_> my code always has very long var names, which seems to bother other people :)
21:30:18 <andythenorth_> CBID_TRAIN_ALLOW_WAGON_ATTACH <- is that define or a constan?
21:31:13 <andythenorth_> i.e. what is correctly known as when discussing?
21:39:33 <andythenorth_> when asking questions, I don't know how to refer to the things in src that look to me like CPP defines
21:39:50 <frosch123> CBID_TRAIN_ALLOW_WAGON_ATTACH is an enumeration value
21:41:04 <andythenorth_> I've changed it to CBID_ENGINE_ALLOW_WAGON_ATTACH
21:41:25 * andythenorth_ wonders if cb1D is only applied to lead vehicle, or all engines in consist?
21:41:31 <andythenorth_> looks like lead vehicle only
21:42:44 <frosch123> yeah, we do not call 16384 callbacks for trains of 128 wagons :p
21:43:01 <andythenorth_> I think I've done it
21:43:03 *** JOHN-SHEPARD has joined #openttd
21:43:39 <frosch123> i doubt anyone on the forums can make use of it :)
21:46:41 *** Phoenix_the_II has joined #openttd
21:50:11 <frosch123> please add the testgrf as well :)
21:56:37 <andythenorth_> frosch123: it's uploading....ridiculously slowly :o
21:56:50 <andythenorth_> it may time out :o
21:58:29 <andythenorth_> frosch123: I was just thinking about rv-wagon attachment
21:58:56 <andythenorth_> if there were several truck sets, it might worth providing a way for trailers in one to be compatible with trailers in another...
21:59:14 <andythenorth_> i.e. a system of labels + a translation table
22:00:21 <andythenorth_> for articulated (fifth wheel trucks) it would need the graphics to be highly standardised
22:00:34 <andythenorth_> for drawbar (conventional) trailers it would work quite easily
22:01:24 <andythenorth_> Terkhen: I now understand attachment a little better :)
22:03:01 <Terkhen> I'm not sure that's good news if that understanding leads to scary stuff like labels :P
22:03:14 <andythenorth_> forget them for now :)
22:04:14 * andythenorth_ wonders why it wasn't suggested before by anyone
22:04:37 <andythenorth_> it would be a way to provide cross-grf attachment rules without having to check grfids
22:05:56 <Terkhen> how many labels would that need?
22:06:20 <andythenorth_> cargo labels have (mostly) worked because mb is very anal about them
22:06:20 <andythenorth_> which is useful
22:06:41 <andythenorth_> rail type labels are...unproven wrt to how useful they are + whether they will degrade
22:06:51 <andythenorth_> for rvs...let me think
22:07:21 <Terkhen> the issue I'm seeing is that you can have many more engines than cargo types, so you would need much more labels
22:07:44 <frosch123> andythenorth_: currently every fool defines his own rail labels, though you cannot necessarily tell the difference
22:08:40 <andythenorth_> for trucks it would really only be 'articulated' and 'drawbar'
22:09:29 <andythenorth_> anything relating to cargos for example should be handled by varaction 2 in cb 15E, not by esoteric labels
22:09:46 <andythenorth_> trams shouldn't need labels
22:10:03 <andythenorth_> farm tractors and other odd vehicles would need a bit of thought
22:11:13 <andythenorth_> it would need to check the vehicle being attached to, not the lead vehicle
22:11:25 <andythenorth_> it would also need to then check the following vehicle to
22:12:20 <andythenorth_> it's basically to do with how vehicles are physically coupled together
22:13:55 <andythenorth_> a smart newgrf author might be able to handle it all with graphics....
22:14:27 <andythenorth_> but the graphics would need to depend on the preceeding vehicle
22:17:17 <Terkhen> I think this is quite subjective
22:17:35 <Terkhen> unless there is some kind of unified view everybody will do whatever he wants with the labels
22:17:36 <andythenorth_> I think it's down to newgrf authors to handle
22:17:58 <Terkhen> also, engines are not as standarized as cargos or railtypes
22:18:24 <andythenorth_> it will produce the interesting result that truck sets will be incompatible with each other
22:18:39 <andythenorth_> i.e. truck in set A can't haul trailers from set B
22:18:59 <andythenorth_> but that's better than no rv-wagons at all
22:21:57 * andythenorth_ can't see a varact 2 for getting ID of preceeding / following vehicle in a chain
22:22:05 <andythenorth_> I don't want to check their props, just ID
22:23:59 <andythenorth_> like var C6, but with offsets of +1 or -1 in the consist from current vehicle
22:29:17 *** andythenorth_ has left #openttd
22:29:35 *** fonsinchen has joined #openttd
22:39:05 *** Chris_Booth_ has joined #openttd
22:42:32 *** Chris_Booth_ is now known as Chris_Booth
22:43:47 *** ABCRic is now known as Guest1250
22:55:03 *** roboboy has joined #openttd
23:08:23 <CIA-2> OpenTTD: rubidium * r21892 /trunk/src/ (lang/english.txt network/network_gui.cpp): -Fix [FS#4421]: only some scenarios from the main scenario folder and no heightmaps could be started in the "start server" window
23:08:45 <CIA-2> OpenTTD: rubidium * r21893 /trunk/src/lang/ (49 files in 2 dirs): -Update (r21892): remove the strings from the other language files as well
23:09:12 <CIA-2> OpenTTD: rubidium * r21894 /trunk/src/ (openttd.cpp openttd.h): -Cleanup: get rid of the unused SM_START_SCENARIO
23:09:13 <CIA-2> OpenTTD: rubidium * r21895 /trunk/src/ (fios.cpp fios.h fios_gui.cpp): -Cleanup: get rid of the unused SLD_NEW_GAME
23:13:52 <CIA-2> OpenTTD: rubidium * r21896 /trunk/src/openttd.cpp: -Cleanup: remove the unused StartScenario
23:18:46 <SmatZ> Ammler: the suse build system should expect that
23:19:02 <SmatZ> like, compile with -D__TIME__=1234 ... or sth like that :)
23:19:27 <SmatZ> also, makedepend (or other tools) tell you what headers are needed for rebuild
23:19:31 <SmatZ> including system libraries
23:19:42 <SmatZ> so if those changes, then the package should be rebuilt
23:19:52 <SmatZ> (unless you are using static linking)
23:20:36 <SmatZ> Ammler: just replace __DATE__/__TIME__ by "built by OpenSuSE", or whatever you feel nice :)
23:20:49 <Ammler> well, for openttd it isn't that bad as it is a "end binary"
23:21:39 <Ammler> but it would be bad, if e.g. grfcodec would use it
23:22:21 <Rubidium> Ammler: ask him how we should be able to detect which build of the OBS system is creating the crash
23:22:51 <Rubidium> as apparantly we are not allowed to store "rebuild" information into the binary
23:23:17 <Ammler> Rubidium: how does debian handle that?
23:23:17 <Rubidium> i.e. you're not allowed to change the version number either as that would give a different binary and rebuild stuff as well
23:23:27 <Rubidium> it just rebuilds the binary
23:23:54 <Rubidium> if it's a library and the ABI changes all packages depending on the ABI are rebuilt
23:24:17 <Rubidium> otherwise it doesn't rebuild stuff
23:24:34 <Rubidium> as that'd be insane for each time core utils or gcc is updated
23:24:42 <Ammler> yes, but what if the rebuild time is the only thing, which changed?
23:25:00 <Rubidium> Ammler: that's not happening with Debian
23:25:15 <Rubidium> there's always a reasonable reason to rebuild
23:25:37 <Ammler> so if grfcodec changes, openttd would not rebuild?
23:25:49 <Rubidium> yes, it's not needed is it?
23:26:03 <Ammler> and how does the buildsystem know that?
23:26:36 <Rubidium> the binary package doesn't depend on grfcodec
23:26:41 *** ABCRic is now known as Guest1262
23:26:43 <Rubidium> only the source package does
23:27:05 <Rubidium> even then, SuSE rebuilds the WHOLE repository each time gcc is updated?
23:28:41 <Rubidium> I know that occasionally a huge farm is used to rebuild the whole of Debian's repository to find broken builds, but that's only testing one architecture
23:28:49 <Ammler> hmm, maybe not, I need to ask
23:28:58 <Rubidium> and not the dozen or so architectures Debian supports
23:29:54 <Ammler> well, usual persons can only use i586 and x86_64 on suse, the rest needs some privilegs
23:30:31 <Ammler> there are 200 build hosts running for those 2
23:32:57 <Rubidium> Debian has only a hand full of builders for those platforms
23:35:29 <Rubidium> handfull = 5 for i386 and amd64 combined
23:36:47 <Rubidium> which is more than enough as those boxes are idling quite a lot
23:37:04 <Rubidium> really makes a difference whether gcc compiles in 4 or 24 hours
23:37:56 <guru3> Right. Got to 1st on the Company League Table in this online game. Now I can go to bed.
23:38:00 <Ammler> since everyone can make his own repos and quite easy branch packages and add his own patches, the suse hosts are quite busy, mostly >1000 packages in the queue
23:39:16 <Rubidium> (or 3 vs 31 hours for openoffice)
23:39:27 *** Eddi|zuHause2 is now known as Eddi|zuHause
23:40:36 <Ammler> a lot people have their custom kernels
23:44:37 <Ammler> Rubidium: I asked anc got confirmed, changed gcc does also rebuild openttd :-)
23:45:23 <Rubidium> that does more harm w.r.t. rebuilds than our debugging stuff
23:45:30 <Ammler> that is why __DATE__ and __TIME__ is bad on obs :-)
23:45:58 <Rubidium> Ammler: but updating gcc more or less implies that the binaries will be different anyhow
23:46:19 <Ammler> well, they said, I could also just ignore the warning which I do for openttd, as it is end product
23:47:01 <Ammler> Rubidium: yes, in our case, it would harm if grfcodec would have such a thing
23:47:43 <Rubidium> as it'd basically only be rebuilt when there's a new gcc, and then OpenTTD would be rebuilt in any case
23:47:57 <Rubidium> likewise for libpng (as OpenTTD depends on that as well)
23:48:44 <Ammler> maybe you are right :-) (and lucky)
23:48:51 <Rubidium> even though it's completely unneeded for OpenTTD to be recompiled when libpng gets updated, except when the API/ABI changes in such a way it's not binary compatible anymore
23:49:00 <Ammler> but you see, that the warning about it is legal?
23:49:39 <Rubidium> Ammler: but... my point is: how would you know which of the many rebuilds you have, and as such what library/compiler/whatnot it's compiled with
23:49:41 <Ammler> Rubidium: it is good to know, if openttd does still build with newer libpng
23:50:15 <Rubidium> Ammler: in 99% of the cases newer is just some additions or internal library changes
23:50:58 <Rubidium> they better spend a few days in analysing the library, than to spend a load of time into making packages not use some arbitrary defines
23:51:44 <Rubidium> for what it's worth, we list the gcc and library versions as well in the crash log
23:52:19 <Rubidium> so if *any* of those are updated the data in the crash log will change
23:52:30 <Ammler> those are legal changes
23:53:00 <Ammler> Rubidium: just imagine, we would use build date and time for the newgrfs
23:53:30 *** supermop has joined #openttd
23:53:38 <Rubidium> Ammler: to counter that, then we'd be storing the version of grfcodec in the NewGRF as well
23:54:02 *** PUB|lightekk is now known as lightekk
23:54:39 <Ammler> yes, we know, why you don't :-)
23:55:07 <Rubidium> Ammler: but if they don't like __DATE__ and such, we could just rebuild rev.cpp each time and inject the date into there so their system doesn't notice it
23:55:50 <Ammler> nah, that would just hide the error
23:56:00 <Ammler> as said, I can ignore it, no issue
23:56:41 <Ammler> I was just wondering, why the newest rpmlint does warn about and got the answer
23:57:07 *** lightekk is now known as DRUNK|lightekk
23:57:22 <Rubidium> openttd.i586: W: no-manual-page-for-binary openttd
23:57:50 <Ammler> that is because I splitted the package for dedicated binary
23:57:58 <Ammler> so the man page is in data
23:59:43 <Ammler> that is something I could bugreport
continue to next day ⏵
