Back to Home / #openttd / 2011 / 01 / Prev Day | Next Day
#openttd IRC Logs for 2011-01-22

---Logopened Sat Jan 22 00:00:38 2011
00:38-!-Eddi|zuHause [] has quit [Read error: Connection reset by peer]
00:41-!-Eddi|zuHause2 [] has joined #openttd
00:46-!-xb [~ggnn@] has joined #openttd
00:48-!-xb [~ggnn@] has quit []
00:56-!-Eddi|zuHause2 [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause2 [] has joined #openttd
01:13-!-xiong [] has joined #openttd
01:33-!-Guest178 [] has quit [Remote host closed the connection]
01:33-!-Wizzleby [] has joined #openttd
01:35-!-Wizzleby is now known as Guest1154
01:35-!-Guest1154 [] has left #openttd []
01:47-!-andythenorth [] has joined #openttd
01:55-!-roboboy [] has joined #openttd
01:56-!-andythenorth [] has quit [Quit: andythenorth]
02:01-!-andythenorth [] has joined #openttd
02:08-!-andythenorth [] has quit [Quit: andythenorth]
02:10-!-DayDreamer [~DayDreame@] has joined #openttd
02:18-!-roboboy [] has quit [Ping timeout: 480 seconds]
02:22-!-DDR [] has quit [Quit: In democracy it's your vote that counts; In feudalism it's your count that votes. - Mogens Jallberg]
02:33<dihedral> <- lol
02:33<dihedral>good morning
03:01-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
03:02-!-HerzogDeXtEr [] has joined #openttd
03:05-!-perk11 [~perk11@] has joined #openttd
03:09<@Terkhen>good morning
03:10-!-andythenorth [] has joined #openttd
03:28*andythenorth wonders how planes choose different sprites for take off / level flight
03:29<andythenorth>can't see any special action 3 handling in the spec
03:32-!-perk11 [~perk11@] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
03:36<dihedral>you could check how its done in av8
03:38<andythenorth>I'll just invent something - this is for ships anyway :)
03:38<dihedral>i did not know they fly
03:42-!-pugi [] has joined #openttd
03:42<andythenorth>dihedral: hydrofoils ;)
03:42<andythenorth>I guess it is actually flying of a sort
03:45<andythenorth>hydrofoils should 'taxi' as they get close to a dock :P
03:45<andythenorth>state machine...
03:48<andythenorth>someone should have cookies for design of standard action 1 / 2 /3
03:50<dihedral>either that - or you define them as planes which need special airports / runways :-)
03:50<andythenorth>water planes?
03:50<andythenorth>could work
03:51<andythenorth>they might fly a bit high...
03:52<dihedral>yes and they could then fly over land too :-P
03:52<andythenorth>maybe hovercraft should be planes :P
03:52<andythenorth>but with a new cb to specify altitude
03:53*andythenorth ponders reading plane code
03:53<dihedral>nah - making them planes is not correct ;-)
03:53<dihedral>you'd lave at seeing a hydrofoil passing over houses :-P
03:59-!-Alberth [] has joined #openttd
03:59-!-mode/#openttd [+o Alberth] by ChanServ
03:59<andythenorth>B4 W Current speed (note, units different for each vehicle type)
03:59<andythenorth>how the units are different is not explained :D
04:00-!-Chrill [] has joined #openttd
04:01<andythenorth>hi Alberth
04:07<andythenorth>ships need realistic acceleration option :P
04:07<andythenorth>Terkhen: :D ^
04:18-!-andythenorth [] has quit [Quit: andythenorth]
04:20-!-andythenorth [] has joined #openttd
04:28-!-andythenorth [] has quit [Quit: andythenorth]
04:33-!-Razmir [] has joined #openttd
04:35-!-Lakie [~Lakie@] has joined #openttd
04:36-!-Wolf01 [] has joined #openttd
04:45-!-tycoondemon [] has quit []
04:49-!-fonsinchen [] has joined #openttd
04:53-!-AFK|lightekk is now known as lightekk
04:53<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].
05:03-!-frosch123 [] has joined #openttd
05:04-!-tycoondemon [] has joined #openttd
05:11<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
05:14-!-DayDreamer [~DayDreame@] has quit [Quit: Leaving.]
05:14-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
05:15-!-HerzogDeXtEr [] has joined #openttd
05:21-!-tycoondemon [] has quit [Ping timeout: 480 seconds]
05:33<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
05:35-!-andythenorth [] has joined #openttd
05:36-!-andythenorth [] has quit []
05:44<@planetmaker>good day
05:45<@Terkhen>hello planetmaker
05:46-!-tycoondemon [] has joined #openttd
05:54-!-Adambean [] has joined #openttd
05:58-!-Xaroth [~Xaroth@] has joined #openttd
06:04-!-Xaroth_ [~Xaroth@] has quit [Ping timeout: 480 seconds]
06:07-!-TheDirtyOne [~chatzilla@] has joined #openttd
06:10-!-Xaroth_ [~Xaroth@] has joined #openttd
06:15-!-Eddi|zuHause2 [] has quit [Remote host closed the connection]
06:15-!-Xaroth [~Xaroth@] has quit [Ping timeout: 480 seconds]
06:16-!-Eddi|zuHause2 [] has joined #openttd
06:16<TheDirtyOne>why does OTTD look for the config and content at my documents?
06:16-!-einKarl [] has joined #openttd
06:17-!-Fast2 [] has joined #openttd
06:18<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.
06:18-!-Progman [] has joined #openttd
06:20<@Terkhen>it looks at another places too, check the readme
06:21-!-ecke [~ecke@] has joined #openttd
06:21<@Terkhen>and OpenTTD can be unpacked anywhere, it does not need to be at that folder
06:25<TheDirtyOne>it checks at its install place, but prioritizes my documents and creates the config there
06:27<@Alberth>it has to create the config someplace
06:27<TheDirtyOne>so why does it create it into documents, not into itself?
06:27<@Alberth>but read the readme, it has detailed explanations on what it all does
06:28<@Alberth>I guess becauses of shared installs
06:28<TheDirtyOne>and there's one more weirdness - sound/music
06:29<TheDirtyOne>ottd with legacy pack (full with sfx) takes the same space as openttd with opengfx alone
06:36-!-einKarl [] has quit [Remote host closed the connection]
06:37<@Terkhen>TheDirtyOne: the installer is not intended for creating portable installations
06:37-!-andythenorth [] has joined #openttd
06:37<@Terkhen>download the zip archive and use its own data folder if you want to have everything in the same folder
06:38<@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
06:42<TheDirtyOne>Terkhen: zip tries that too.
06:42<@Terkhen>you need an openttd.cfg file there too
06:43<@Terkhen>as I said, check the readme
06:43-!-KenjiE20 [~KenjiE20@] has joined #openttd
06:43<TheDirtyOne>zip just lacks the cfg
06:44<TheDirtyOne>just one empty file with .cfg extension.
06:44<@Alberth>no, otherwise it would overwrite an existing cfg
06:44<@Alberth>and it gets created anyway
06:44<TheDirtyOne>it gets created in documents automatically
06:45<TheDirtyOne>is there a switch to make it into exe's folder?
06:45<@Terkhen>believe me, it's all explained in the readme
06:47<TheDirtyOne>oh, 1.05 got rid of this - files get found even with an outside cfg
06:50<@Alberth>way way before that version already, actually, afaik
06:53<TheDirtyOne>and why are there 2 music files in content system?
06:53-!-roboboy [] has joined #openttd
06:53<TheDirtyOne>openmsx and anthology-something
06:53<@Alberth>so you have a choice
06:54<TheDirtyOne>is OTTD compatible with patched MIDIs?
06:55<@planetmaker>depends upon what you call a 'patched midi'
06:55<TheDirtyOne>FeelSound patching
07:00<TheDirtyOne>MIDIs fixed by instrument swapping and patched with FeelSound using PSMPlayer -
07:02-!-Chrill [] has quit []
07:03<TheDirtyOne>fixing might be needed for MIDIs with bad instrument codes, and so on...
07:03<@planetmaker>Should work to just modify an existing midi
07:03<@Alberth>I have no clue at all what that means
07:05<TheDirtyOne>planetmaker: PSMPlayer makes fixing/feelsound patching easy
07:05<@planetmaker>I've not heart of any of those tools, sorry
07:06<TheDirtyOne>I managed, over chat, to guide one person to fixing the MIDI file that was causing MIDI library misinterpreting instruments.
07:06<TheDirtyOne>Just get PSMPlayer - it's very small.
07:08<@Alberth>we have had enough commercials now, thank you
07:10<@planetmaker>oh no. definitely not. and not for my OS
07:10<TheDirtyOne>it's not advertising. It's a win32 app to work with MIDIs.
07:12<@planetmaker>see. the point. Nothing which is remotely usable for me
07:12<@Alberth>whatever, nobody is interested
07:12*TheDirtyOne is a sick, mindless fatty that plays random games and is always full of weird//stupid questions...
07:13*TheDirtyOne explodes
07:13-!-TheDirtyOne [~chatzilla@] has left #openttd []
07:14<@Terkhen>explodes == never will come back?
07:14<@Alberth>don't get your hopes up too much :)
07:19<andythenorth>anyone playing FIRS?
07:19<andythenorth>I am wondering what to work on
07:22<@Alberth>so many projects, and still out of ideas :)
07:22<@Terkhen>I have not played FIRS in a long time
07:23<andythenorth>Alberth: you're out of ideas or me?
07:23<@Alberth>hmm, perhaps it is time to try playing FIRS again
07:23<@Alberth>andythenorth: I meant you
07:23<andythenorth>I have ideas
07:23<andythenorth>what I don't have is an easy way to prioritise :)
07:24<andythenorth>I did have DanMacK sending me sprites for a bit
07:24<andythenorth>that set a direction for FISH
07:24<andythenorth>but he's not here today ;)
07:25-!-Markavian [] has joined #openttd
07:32-!-ZirconiumX [] has joined #openttd
07:32-!-JOHN-SHEPARD_ [] has joined #openttd
07:36-!-JOHN-SHEPARD [] has quit [Ping timeout: 480 seconds]
07:36<Razmir>just for your interest, monorails should be available since year 1909 :)
07:41-!-Pulec [] has joined #openttd
07:49-!-andythenorth [] has quit [Quit: andythenorth]
08:07-!-nicfer [~nicfer@] has joined #openttd
08:07-!-Chris_Booth [] has joined #openttd
08:18<ZirconiumX>I think BR had a maglev prototype - around 1970
08:23<frosch123>yeah, ottd should also have an option to waste lots of money into researching prototypes which will never become available
08:23<ZirconiumX>"I had a million - but now I don't..."
08:24<ZirconiumX>"I spent it on ill-fated prototypes - and now everyone hates me for spending their money..."
08:25-!-ZirconiumX [] has quit [Quit: ajax IRC Client]
08:33-!-glx [glx@2a01:e35:2f59:c7c0:cd1a:12ba:4bc8:af7f] has joined #openttd
08:33-!-mode/#openttd [+v glx] by ChanServ
08:36-!-andythenorth [] has joined #openttd
08:37<andythenorth>wallyweb has got a bit excited about electricity :o
08:38<andythenorth>a power circuit is just a lot of little men passing buckets of charge to each other yes / no?
08:38<andythenorth>that's what we drew in school anyway :P
08:42<__ln__>i don't think such a fundamental phenomenon of physics could have changed since you were in school. (whenever that was)
08:43<@Alberth>except it are actually 'holes' that move from+ to - :)
08:43<@Alberth>(or electrons that move from - to +)
08:44-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
08:44<andythenorth>adding an actual electrical grid seems somewhat overkill
08:46<andythenorth>however....if the map could handle storing point values of arbitrary properties like charge....
08:46<andythenorth>...then a 'proper' spot price economy would also be possible
08:47<@Alberth>I fail to see the point of it all, play simcity instead would be much easier
08:48<andythenorth>everyone has their pet project :D
08:48<andythenorth>mine is roadtypes :P
08:49<andythenorth>and also rv-wagons
09:00<devilsadvocate>you could model it as something that satisfies poisson's equation
09:01<devilsadvocate>put in sources at power plants, sinks at usage points, and then charge people based on 'availability' at that specific point
09:02<devilsadvocate>of course, that way, you can end up 'using' more than you produce
09:02<devilsadvocate>but solving actual power flow equations would be a big more ugly
09:09<@Terkhen>andythenorth: how do you enable CB1D?
09:11<@Rubidium>Alberth: we already had the idea to have a cargo "electrons", so you ship 1 ton of electrons per train or something ;)
09:11-!-roboboy [] has quit [Ping timeout: 480 seconds]
09:12-!-Brianetta [] has joined #openttd
09:15-!-Razmir [] has left #openttd []
09:15<andythenorth>Terkhen: I was going to say extend prop 17
09:15<andythenorth>but if it's a byte, it's full :P
09:15<@Alberth>in fact, we are already shipping electrons in toyland batteries
09:16<andythenorth>Terkhen: we could abuse prop
09:16<andythenorth>or a new action 0 prop is needed
09:16<frosch123>if trains have no flag for 1d, rv should not have one either
09:17<@Terkhen>using 17 would be the most desirable option, yes
09:17<andythenorth>frosch123: that presents an interesting conundrum
09:17<@Terkhen>yes, as it makes sense that the default behaviour is identical to what we have now
09:17<andythenorth>that means either all RVs become attachable, or none
09:17<frosch123>"none" of course?
09:18<andythenorth>so every single vehicle that is attachable has to explicitly handle cb 1D?
09:18<frosch123>just as every train vehicle which is not attachable, right?
09:18<@Terkhen>but wouldn't that make handling of the CB different between trains and road vehicles?
09:19<andythenorth>frosch123: train vehicles are attachable by default though?
09:19<andythenorth>so the inverse :)
09:19<frosch123>Terkhen: usually "failed callback" is defines as "default behaviour as if the cb was not enabled"
09:19*andythenorth wonders what fraction of road vehicles *should* be attachable
09:19<frosch123>so, it is perfectly fine, if failed cb means different things for trains and rv
09:19<andythenorth>buses generally probably aren't attachable
09:19<@Terkhen>yes, that's what I meant
09:20<andythenorth>trucks don't attach to each other
09:20<@Terkhen>I guess they would only differ on the handling of "failed cb"
09:20<andythenorth>so basically trailers would need to handle CB1D to become trailers
09:20<@Terkhen>andythenorth: none by default
09:20<frosch123>in fact, it would be uncommon if failing cb 1d for rv would allow attaching
09:20<andythenorth>do it the other way - explicitly enable attaching
09:20<andythenorth>fail by default
09:21<frosch123>andythenorth: actually i see no point in generally allowing any attaching
09:21<frosch123>that would allow attaching a bus to a truck engine
09:22<frosch123>just take a look at the tons of complains, that trains allow attaching wagons from other grfs
09:22<@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
09:22<frosch123>if rv engines allow attaching busses from other sets, that will certainly cause a lot of trouble
09:22<andythenorth>frosch123 there are probably as many complaints the other way? :P
09:22<andythenorth>anyway, I'm convinced
09:22<andythenorth>by your argument
09:23<andythenorth>so I should change the spec - default is to fail with the default message
09:24-!-ZirconiumX [] has joined #openttd
09:24<frosch123>not sure. i guess there is some difference between attaching rvs and trains
09:25<frosch123>while you can attach most rv wagons to any rv which can accept some wagon, you usually cannot attach multiple rv engines
09:25<andythenorth>I think that would have to be handled by the newgrf author
09:25<frosch123>just because your truck can pull any trailer, it cannot pull every engine
09:26<frosch123>so, maybe multiheaded-compatible could be a misc flag for rv
09:26<frosch123>i.e. most engines can only be put at the front, not as secondary engines
09:26<andythenorth>I can think of edge cases where multi-headed RVs are desirable
09:26<andythenorth>but they are definitely non-standard
09:27<@Terkhen>IIRC for starters we were going to disallow all multiheaded
09:27-!-ZirconiumX [] has quit []
09:27<@Terkhen>introducing a flag latter for those special cases would make sense
09:28<andythenorth>really we could live without them
09:29<andythenorth>Terkhen: don't we need to disallow them under the current RV acceleration model?
09:29<andythenorth>RVs can't have powered trailing vehicles yes / no?
09:29<@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
09:36-!-Netsplit <-> quits: Zuu, SpComb, glevans2, Eddi|zuHause2, @planetmaker, Priski, Sionide, Prof_Frink, z-MaTRiX_nonidentified, @DorpsGek, (+109 more, use /NETSPLIT to show all of them)
09:40-!-Netsplit over, joins: Rubidium, FauxFaux, Andel, verm__, EyeMWing, xiong
09:40-!-Biolunar [] has joined #openttd
09:40-!-Fuco [] has joined #openttd
09:40-!-Netsplit over, joins: Brianetta, andythenorth, +glx, Chris_Booth, Pulec, JOHN-SHEPARD_, KenjiE20, ecke, Progman, Xaroth_ (+8 more)
09:40-!-ServerMode/#openttd [+ovvo Rubidium Rubidium glx Alberth] by
09:40-!-Netsplit over, joins: SpComb, APTX, ^Spike^, SpComb^, Markk, Vadtec, @SmatZ, hoax_, russell_h, SirSquidness (+66 more)
09:40-!-Netsplit over, joins: Eddi|zuHause2, lasershock, @Belugas, glevans2, CIA-2
09:40-!-Netsplit over, joins: murr4y, PeterT, nicfer, Markavian, ar3k, lugo, a1270, Born_Acorn
09:44<frosch123>andythenorth: i guess a flag for the second engine, and the usual cb for the front
09:46<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?
09:46<andythenorth>I don't know
09:46<andythenorth>I don't understand livery over-rides
09:46<frosch123>take a look at the train sets
09:47<frosch123>e.g. 2cc
09:47<andythenorth>how would I combine two articulated trams?
09:47-!-maddy_ [] has joined #openttd
09:47<frosch123>they have a mu wagon which you can attach to other mu-engines
09:47<maddy_>hi folks
09:47<andythenorth>is the mu wagon powered?
09:47<@planetmaker>can be
09:47<andythenorth>so do RVs need powered wagon concept?
09:47<@planetmaker>there's a powered wagon CB
09:48<@planetmaker>rv don't need that imho
09:49<frosch123>afaik the wagons are not powered usually, but the engine reports different power via cb36 depending on the number of attached wagons
09:49<andythenorth>I can't think of a case where it would be needed for RVs
09:50<andythenorth>do PAX trams need powered wagons?
09:51<frosch123>you talked about attaching multiple trams
09:51<frosch123>that can be done by attaching engines, or by attaching wagons
09:51<andythenorth>I think that's cleaner
09:51<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)
09:52<andythenorth>I can't see a case for powered RV wagons using CB
09:52<frosch123>andythenorth: might be, but it is not the way it is done for trains usually :)
09:52<frosch123>at least in the train sets i used
09:52<CIA-2>OpenTTD: rubidium * r21890 /trunk/src/ (95 files in 10 dirs): -Cleanup: remove some unneeded includes
09:52-!-tokai|mdlx [] has joined #openttd
09:52-!-KouDy [~KouDy@] has joined #openttd
09:52-!-Maedhros [] has joined #openttd
09:52-!-Mikael [~Mikael@] has joined #openttd
09:52-!-Noldo [] has joined #openttd
09:52<frosch123>maybe planetmaker knows better
09:52<andythenorth>but trams != trains...
09:52<frosch123>but, ottd player == ottd player
09:53<@planetmaker>frosch123, I doubt that I know more about newgrfs than you ;-)
09:54<frosch123>i am sure you played with more, and know whether you attach wagons or engines to mus
09:54<andythenorth>frosch123: I am confused :) do you make case for or against having powered wagon cb?
09:54<@planetmaker>wagons are attached to mus
09:54<frosch123>esp. as i dislike pax transporation and usually only do cargo
09:54<frosch123>andythenorth: i am agains attaching multiple tram engines to make trams longer
09:54<@planetmaker>and they can have a powered wagon CB and thus provide power.
09:55<andythenorth>I think it would be weird to have a 'tram' and then a 'fake tram'
09:56<frosch123>andythenorth: how do you control the length of the tram?
09:56<frosch123>do you attach multiple engines of each 3 articulated parts
09:56<frosch123>or do you build one front, and then attach 5 wagons, which are partially powered
09:56-!-ZirconiumX [] has joined #openttd
09:56<andythenorth>articulated trams seem like fixed units to me
09:57<frosch123>the latter is done by most train sets, the former is done by e.g. the csd train set
09:57<frosch123>take a look at it, i consider it crappy gameplay :)
09:57<andythenorth>so powered wagon cb is needed?
09:58<frosch123>you want to control the length of trams with single wagons, not in bunches of 3 parts
09:58<@planetmaker>callback <whatever> defines "can wagon be attached"
09:58<frosch123>andythenorth: not necessarily, there are multiple ways to code that
09:58<@planetmaker>that'd be what trains do
09:58<frosch123>planetmaker: that part is easy, it is more about, "this engine can be attached to some other"
09:58<frosch123>i.e. the reverse
09:58<@planetmaker>it's the same callback, though
09:58*andythenorth is condused: how to add powered wagons without powered wagon cb ?
09:59<@planetmaker>it goes by ID - IIRC
09:59<frosch123>just because you have a truck which can pull every trailer, it does not mean you can attach another truck to it
09:59*Terkhen is confused by the same reason :)
09:59<frosch123>planetmaker: but it is only from the pov of the front, not of the wagon
09:59*andythenorth supposes consist length could be checked and hp adjusted accordingly?
09:59<@planetmaker>frosch123, true. But IIRC that works by ID, and you return the CB for 'can attach' true for those vehIDs which you like
09:59<@planetmaker>yes, from the engine, indeed
10:00<frosch123>planetmaker: sure, but again: you do not ask the engine which is going to be attached
10:01<frosch123>and that problem is bigger for rv than for trains
10:01<frosch123>for trains it is mostly only about mixing grfs
10:02<@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
10:02<@planetmaker>It's quite limited, doesn't allow cross-grf-talk, but... well. It's ok
10:03<andythenorth>I thought the wagon being attached would check for IDs in the rest of the consist.
10:03<frosch123>planetmaker: that part is fine. but now think about the reverse
10:03<andythenorth>if all of those IDs are allowed, allow attaching
10:03<@planetmaker>uhm, yes? You mean a wagon which asks whether it wants to be able to be attached?
10:03<@planetmaker>Not possible afaik.
10:03<frosch123>planetmaker: exactly
10:03<frosch123>and i think that is important for rv
10:04<@planetmaker>uhm... is it?
10:04<frosch123>but it might also be of use for trains
10:04<@planetmaker>yes, if for both, please ;-)
10:04*andythenorth had misunderstood cb1D
10:04<@planetmaker>indeed, thinking of it, you're right. It just need both: can be attached and wants to be attached
10:05-!-KritiK [] has joined #openttd
10:05<@planetmaker>or better: can tow / can be towed
10:06<andythenorth>some kind of friend / foes list :P
10:06<maddy_>seems gui windows are of type "struct" in current version, but my patch uses "class", will that be a prob?
10:06<frosch123>some compilers complain about deriving struct from class and vice versa
10:07<@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"
10:08<andythenorth>planetmaker: if checking other vehicle will come to a friends / foes list, but in a varaction 2 :D
10:09<fonsinchen>hrm ... refactor smallmap to split out linkgraph overlay in a clean == produce a huge pile of trivial diff
10:09<fonsinchen>not split out linkgraph overlay == ugly
10:10<@planetmaker>trivial diffs are more or less easy to review ;-)
10:10<@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
10:10<andythenorth>Terkhen: a train thing?
10:11<fonsinchen>And it's a lot of boring work to produce them.
10:11<andythenorth>or an RV thing?
10:12<fonsinchen>well ... time to create some new branches
10:14<andythenorth>frosch123: so if there was a new cb like 1D, but for the vehicle being attached...
10:15<andythenorth>....a special flag for 'allow multiple engines per consist' is not needed
10:19<andythenorth>is it a new cb, or a modification of 1D?
10:20<andythenorth>I guess a new cb
10:21<@Terkhen>andythenorth: yes
10:26-!-ABCRic [] has joined #openttd
10:27-!-KritiK [] has quit [Quit: Leaving]
10:28<andythenorth>Terkhen: do you need to code a newgrf to get your head around it?
10:29<@planetmaker>opengfx+RV ;-)
10:32<andythenorth>Terkhen: a good test for rv-wagons might be HEQS 2
10:32*andythenorth is puzzled how version numbers work
10:33<andythenorth>HEQS 1.0 will go into probably there will be HEQS 1.1, 1.2 etc
10:33<andythenorth>probably a branch
10:33<andythenorth>meanwhile HEQS 2 is a redevelopment
10:33-!-ZirconiumX [] has quit [Quit: ajax IRC Client]
10:33<andythenorth>so I guess I just have to use nightly build numbers :o
10:33-!-KritiK [] has joined #openttd
10:36-!-nicfer [~nicfer@] has quit [Read error: Connection reset by peer]
10:39-!-KritiK [] has quit [Quit: Leaving]
10:43<@planetmaker>why do you?
10:44<@Terkhen>andythenorth: I think so, it helped with the rest of callbacks
10:52-!-ABCRic is now known as Guest1210
10:52-!-ABCRic [] has joined #openttd
10:53-!-Chruker [] has joined #openttd
10:56-!-Guest1210 [] has quit [Ping timeout: 480 seconds]
11:04-!-Fuco [] has quit [Quit: Quit]
11:06-!-fonsinchen [] has quit [Remote host closed the connection]
11:07-!-nicfer [~nicfer@] has joined #openttd
11:09-!-Fuco [] has joined #openttd
11:13-!-DayDreamer [~DayDreame@] has joined #openttd
11:16-!-andythenorth_ [] has joined #openttd
11:21<andythenorth_>Terkhen: HEQS wouldn't be a bad place to hack
11:21<andythenorth_>it has both rvs and rail vehicles...
11:21<andythenorth_>and I have a case for new wagons using cb 1D
11:22<@Terkhen>I'll have a hard enough time trying to learn how to do it in NML :)
11:22-!-andythenorth [] has quit [Ping timeout: 480 seconds]
11:29<andythenorth_>nfo puts it into your head with more...force :P
11:29-!-Eddi|zuHause2 [] has quit [Remote host closed the connection]
11:30-!-Eddi|zuHause2 [] has joined #openttd
11:30<andythenorth_>cb1D isn't what I need
11:31<andythenorth_>I need the new, unimplemented 'check for this wagon' cb
11:31<@Terkhen>andythenorth_: I agree, but NFO also gives you stronger headaches
11:31<andythenorth_>that is the sign of the brain learning :
11:32<andythenorth_>frosch123: what would be a good ID for the new cb?
11:33<+glx>next free ID maybe
11:34<andythenorth_>looks like 15C
11:37<frosch123>yup, next free one :p
11:43-!-KritiK [] has joined #openttd
11:45-!-maddy_ [] has quit [Quit: leaving]
12:02-!-DanMacK [~DanMacK@] has joined #openttd
12:02<DanMacK>Hey all
12:03-!-Netsplit <-> quits: Maedhros, tokai|mdlx, Mikael, Noldo, KouDy
12:04-!-Netsplit over, joins: tokai|mdlx, KouDy, Maedhros, Mikael, Noldo
12:07<@Terkhen>hi DanMacK
12:08-!-MtlGuard [~jk26@] has joined #openttd
12:08-!-MtlGuard [~jk26@] has left #openttd []
12:08-!-MtlGuard [~jk26@] has joined #openttd
12:08-!-MtlGuard [~jk26@] has left #openttd []
12:11-!-MtlGuard [~jk26@] has joined #openttd
12:11-!-MtlGuard [~jk26@] has left #openttd []
12:15<andythenorth_>cb 15C looks to be occupied
12:15<andythenorth_>15E then
12:20<__ln__>wouldn't a window seat be nicer
12:20-!-mode/#openttd [+b *!*@] by SmatZ
12:33-!-einKarl [] has joined #openttd
12:38<andythenorth_>cb1D looks to be train specific at the moment
12:38<andythenorth_>at least, it's defined in train_cmd.cpp
12:38<@planetmaker>nice when finally theory and experiment somewhat agree... and two ways to solve one problem give the same result :-)
12:38<andythenorth_>would it be better to unify train / rv stuff before or after adding a cb?
12:39<@planetmaker>I earned my dinner today ;-)
12:39<@Terkhen>andythenorth_: in which part of train code is it being called?
12:40<andythenorth_>Terkhen: CheckTrainAttachment
12:40<andythenorth_>maybe that calls another function already?
12:40<andythenorth_>that isn't train specific?
12:41<@Terkhen>at first glance that function does not have many train specific code
12:41<@Terkhen>it would get unified up to ground_vehicle at some point in rv-wagons
12:42-!-Kurimus [] has joined #openttd
12:43<andythenorth_>I should read it more :P
12:43<andythenorth_>(baby bath time right now)
12:47-!-dfox [] has joined #openttd
12:47-!-Pulec [] has quit [Ping timeout: 480 seconds]
12:49-!-Pulec [] has joined #openttd
12:55-!-ABCRic is now known as Guest1221
12:55-!-ABCRic [] has joined #openttd
12:58-!-Guest1221 [] has quit [Ping timeout: 480 seconds]
12:59-!-Lakie [~Lakie@] has quit [Remote host closed the connection]
12:59-!-Lakie [~Lakie@] has joined #openttd
13:01*andythenorth_ just fell down the stairs
13:01<andythenorth_>and isn't even drunk :P
13:06<andythenorth_>no damage to my laptop though :P
13:06<andythenorth_>no code was lost :P
13:08<andythenorth_>I don't understand how GetVehicleCallbackParent is handling wagon attachment
13:08<andythenorth_>it seems to offload the check somewhere else, but I can't see where
13:10<andythenorth_>I'm in newgrf_engine.cpp
13:10<@peter1138>parent = head of chain
13:11<@Rubidium>looks like that callback is "special" in the way that it passes the parent instead of getting the parent from the vehicle
13:12<@Rubidium>which makes sense as it's not yet connected, although NewGRFs assume it to be connected for the test
13:12<andythenorth_>and the actual logic for 'allowed / not allowed' -> return value is all in nfo?
13:12<andythenorth_>and the cb just gets back a value from a varaction 2 ?
13:12*andythenorth_ was looking for some 'if' code that won't exist :P
13:13<@Rubidium>a few lines later callback is evaluated
13:13<@Rubidium>s/callback/callback result/
13:22-!-ABCRic_ [] has joined #openttd
13:22-!-ABCRic is now known as Guest1224
13:22-!-ABCRic_ is now known as ABCRic
13:26-!-Guest1224 [] has quit [Ping timeout: 480 seconds]
13:39-!-nicfer [~nicfer@] has quit [Read error: Connection reset by peer]
13:45<__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?
13:49<__ln__>'vousneparlezpasfrançais!?' is a bit long for a term
13:50-!-JOHN-SHEPARD [] has joined #openttd
13:50<__ln__>such an observation usually doesn't stop them from continuing to talk in french
13:51<ABCRic>je ne parle pas français?
13:52-!-lightekk is now known as PUB|lightekk
13:52-!-fjb is now known as Guest1227
13:52-!-fjb [] has joined #openttd
13:54-!-xiong [] has quit [Ping timeout: 480 seconds]
13:54-!-JOHN-SHEPARD_ [] has quit [Ping timeout: 480 seconds]
13:54<andythenorth_>frosch123: adding a new attach cb...
13:55<andythenorth_>would that need to be checked after current attach cb check?
13:55<frosch123>i guess it needs calling at the same point in the code. but i guess it does not matter which one first
13:56<andythenorth_>so l982-991 in train_cmd.cpp would basically need repeating?
13:56<@Terkhen>will this cause another mayhem such as CB15/CB36? :P
13:56<andythenorth_>and something like this adding:
13:56<andythenorth_> uint16 callback = GetVehicleCallback(CBID_WAGON_ALLOW_ATTACH_TO_CONSIST, 0, 0, head->engine_type, t, head);
13:57<frosch123>not 'head'
13:57<frosch123>you want to call it for the wagon, not for the head
13:59<CIA-2>OpenTTD: translators * r21891 /trunk/src/lang/ (5 files):
13:59<CIA-2>OpenTTD: -Update from WebTranslator v3.0:
13:59<CIA-2>OpenTTD: danish - 1 changes by nurriz
13:59<CIA-2>OpenTTD: japanese - 12 changes by kokubunzi
13:59<CIA-2>OpenTTD: slovenian - 1 changes by ntadej
13:59<CIA-2>OpenTTD: turkish - 107 changes by niw3
13:59<CIA-2>OpenTTD: ukrainian - 60 changes by Fixer
13:59-!-Guest1227 [] has quit [Ping timeout: 480 seconds]
13:59<frosch123>i guess GetVehicleCallback(CBID_WAGON_ALLOW_ATTACH_TO_CONSIST, 0, 0, t->engine_type, t)
14:00*andythenorth_ isn't sure about the invalidate cache stuff
14:00-!-Kurimus [] has quit []
14:00<andythenorth_>does that need repeating if two cbs are handled?
14:01<frosch123>that is only for moving the vehicle
14:01<frosch123>i.e. the function attached the wagon, then calls the callbacks, and detaches the wagon again
14:03-!-Cybertinus [] has joined #openttd
14:04<frosch123>there the wagon is already partly detached again
14:04<frosch123>call the callback immediatelly after the other, and assign the result to callback2 or whateer :)
14:06<frosch123>looks a bit duplicated, but should work
14:07<andythenorth_>so I need to add the cb to newgrf_callbacks.h
14:07<andythenorth_>is it that simple :o
14:07<frosch123>likely also to table/newgrf_debug_data.h
14:16<andythenorth_>frosch123: no cb mask in this case?
14:16<andythenorth_>i.e. I can set CBM_NO_BIT
14:17<frosch123>andythenorth_: i guess it would be better if you change the cb results to < 0x3FF for custom text, 0x400 = allowed, 0x401...
14:17<frosch123>cb1d has no mask either
14:20<frosch123>aren't they sorted by id?
14:21-!-Chruker [] has quit []
14:21-!-pugi [] has joined #openttd
14:23<frosch123>s/ /\t/
14:23-!-JOHN-SHEPARD_ [] has joined #openttd
14:24-!-JOHN-SHEPARD [] has quit [Ping timeout: 480 seconds]
14:25<andythenorth_>tabs vs. spaces?
14:26<frosch123>yeah :)
14:26<andythenorth_>silly old xcode
14:27*andythenorth_ should write newgrf to test this :P
14:40<DanMacK>Go for it :D
14:41<DanMacK>Use a dozer and a trailer to test :P
14:44<@Alberth>andythenorth_: Gmund Mog is not very useful is it? 2t fruit & vegetables
14:44-!-JOHN-SHEPARD_ [] has quit [Ping timeout: 480 seconds]
14:45<andythenorth_>haul ENSP + FMSP with it
14:45<andythenorth_> with rv-wagons :P
14:45<@Terkhen>isn't it is a bit slow for that?
14:46<@Alberth>51km/h is not bad compared to the alternatives No 6 or 8 crawler, at 16/17 km/h :)
14:48*andythenorth_ broke the compile
14:49<@Terkhen>I usually use HEQS along with another road vehicle set
14:51*andythenorth_ fixes the compile
14:53<andythenorth_>here's my diff :)
14:53<andythenorth_>now to make a newgrf
14:58-!-Eddi|zuHause2 [] has quit [Remote host closed the connection]
14:58-!-Eddi|zuHause2 [] has joined #openttd
15:00<@Terkhen>hmm... stupid templates
15:10-!-DDR [] has joined #openttd
15:11<Wolf01> they noticed the pre r21863 cargo bug too :P
15:12<__ln__>what's the fail part of the photo, everyone seems to have a seat
15:12<Wolf01>they could have used a larger train, see the tracks
15:17*andythenorth_ forgets
15:17<andythenorth_>how do I handle a cb ID that doesn't fit in a byte?
15:17<andythenorth_>do I just go word sized, or do I add 80?
15:27<frosch123>you _always_ have to use words for checking callback ids
15:27-!-Alberth [] has left #openttd []
15:36<andythenorth_>frosch123: this shouldn't work then?
15:38<frosch123>that makes use of some downwards-compatibility thing
15:38<frosch123>imagine there would be a callback 0x123
15:38<andythenorth_>I'll amend
15:38<frosch123>you would put it in the 0x23 case
15:39<frosch123>that's the reason why cb numbering jumped from 3d to 140 :)
15:40<frosch123>everyone was only testing the byte, so when cb 00 to ff would have been assigned, you would be screwed when adding 100
15:42<andythenorth_>15E is 01 5E
15:42<andythenorth_>or 15 E0?
15:43<@planetmaker>escapes rule ;-)
15:43<andythenorth_>not as pretty :|
15:43<andythenorth_>less rhythmic
15:45<andythenorth_>planetmaker: how do I stop make bailing out on a renum error?
15:45<andythenorth_>there's a switch?
15:45<frosch123>make -ik
15:47<@planetmaker>make NFO_WARN_LEVEL=10
15:47<frosch123>btw... is brainfuck highlighting suitable for nfo?
15:47<andythenorth_>it seems to be my saved selection at pastebin :)
15:47<andythenorth_>my new cb doesn't
15:55<andythenorth_>frosch123: this is my nfo
15:55<andythenorth_>and this is my ottd diff:
15:56<frosch123>both look fine :)
15:57<andythenorth_>maybe there's more to do to create this cb
15:58-!-George [~George@] has quit [Read error: Connection reset by peer]
16:00<andythenorth_>frosch123: in context of CheckTrainAttachment, what is variable t?
16:00<andythenorth_>the vehicle, or the train it's being attached to?
16:01-!-George [~George@] has joined #openttd
16:02*andythenorth_ sees some problems
16:03<frosch123>t is the wagon
16:03<andythenorth_>callback and callback2 are silly variable names :P
16:03<andythenorth_>and I'm silly for not updating references to callback
16:03<@planetmaker>that depends
16:04<andythenorth_>this might just work :)
16:07<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
16:08<frosch123>but that should not hurt your testgrf
16:09<andythenorth_>frosch123: I had missed something stupid
16:09<andythenorth_>it currently seems to work
16:09<andythenorth_>more or less
16:09<andythenorth_>there is an odd edge case I just found with a savegame
16:09<andythenorth_>so I have enabled 15E for a rail vehicle
16:10<andythenorth_>and return FD to prevent attach
16:10<andythenorth_>but in my savegame these vehicles are already in a consist
16:10<andythenorth_>I can't take vehicles out of the consist to an empty line in depot
16:10<andythenorth_>it's correct
16:10<andythenorth_>but might be problematic?
16:10<frosch123>move all at once
16:11-!-Progman_ [] has joined #openttd
16:12<andythenorth_>I'll screenshot
16:13<frosch123>buy a new wagon to a separate line, then ctrl+drag the whole consist behind it
16:13<frosch123>you should always be allowed to do that
16:15<andythenorth_>you're right about the new wagon method
16:15<andythenorth_>the other behaviour is correct
16:15<andythenorth_>and should only occur in the case of save games
16:16-!-Progman [] has quit [Ping timeout: 480 seconds]
16:16-!-Progman_ is now known as Progman
16:17<andythenorth_>frosch123: what else needs to be done for this?
16:17<andythenorth_>you suggested changing the cb return values?
16:17-!-DayDreamer [~DayDreame@] has quit [Quit: Leaving.]
16:18-!-DDR [] has quit [Ping timeout: 480 seconds]
16:19<andythenorth_>the defines (constants?) names should be cleaned up
16:19<frosch123>andythenorth_: you seem to need GetVehicleCallbackParent(), so the parent scope is set up correctly
16:20<andythenorth_>CBID_TRAIN_ALLOW_WAGON_ATTACH is too train specific
16:20<andythenorth_>CBID_WAGON_ALLOW_ATTACH_TO_CONSIST implies specific to wagons
16:20<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
16:21<andythenorth_>what's the issue? Some varacts will fail if they reference (e.g. 82)?
16:21<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
16:21<frosch123>andythenorth_: the cb is called while the wagon is not attached, so parent scope will refer to the wagon as well
16:21<frosch123>so you cannot access the head
16:22<andythenorth_>do I need to use head->engine_type in params?
16:22<andythenorth_>instead of t->engine_type
16:24<andythenorth_>but I do need to add head to params?
16:24<frosch123>you need to append head as the additional parameter to the other function
16:25<andythenorth_>or it doesn't compile :)
16:25<andythenorth_> uint16 callback2 = GetVehicleCallbackParent(CBID_WAGON_ALLOW_ATTACH_TO_CONSIST, 0, 0, t->engine_type, t, head);
16:25<andythenorth_>seems to work
16:25<andythenorth_>callback2 looks like a silly name to me
16:26<frosch123>i guess keep the cb results as they are
16:26<andythenorth_>so should I clean up the var names callback and callback2?
16:26<andythenorth_>I don't really know the ruling style :P
16:26<frosch123>if you can come up with good ones :) i cannot :p
16:26<andythenorth_>callback1 and callback2 :P
16:27<andythenorth_>cb_result_1, cb_result_2
16:27<frosch123>then i prefer wagon_callback and engine_callback
16:28<andythenorth_>fine by me
16:28<andythenorth_>my code always has very long var names, which seems to bother other people :)
16:30<andythenorth_>CBID_TRAIN_ALLOW_WAGON_ATTACH <- is that define or a constan?
16:31<andythenorth_>i.e. what is correctly known as when discussing?
16:39<andythenorth_>when asking questions, I don't know how to refer to the things in src that look to me like CPP defines
16:39<frosch123>CBID_TRAIN_ALLOW_WAGON_ATTACH is an enumeration value
16:41<andythenorth_>I've changed it to CBID_ENGINE_ALLOW_WAGON_ATTACH
16:41*andythenorth_ wonders if cb1D is only applied to lead vehicle, or all engines in consist?
16:41<andythenorth_>looks like lead vehicle only
16:42<frosch123>yeah, we do not call 16384 callbacks for trains of 128 wagons :p
16:42<frosch123>hmm, 8192 only
16:43<andythenorth_>I think I've done it
16:43-!-JOHN-SHEPARD [] has joined #openttd
16:43<andythenorth_>post to fs?
16:43<frosch123>where else?
16:43<frosch123>i doubt anyone on the forums can make use of it :)
16:46-!-Phoenix_the_II [] has joined #openttd
16:46-!-PhoenixII [] has quit [Read error: Connection reset by peer]
16:50<frosch123>please add the testgrf as well :)
16:56<andythenorth_>frosch123: it's uploading....ridiculously slowly :o
16:56<andythenorth_>it may time out :o
16:58<andythenorth_>frosch123: I was just thinking about rv-wagon attachment
16:58<andythenorth_>if there were several truck sets, it might worth providing a way for trailers in one to be compatible with trailers in another...
16:59<andythenorth_>i.e. a system of labels + a translation table
16:59<@Terkhen>that sounds scary
17:00<andythenorth_>for articulated (fifth wheel trucks) it would need the graphics to be highly standardised
17:00<andythenorth_>for drawbar (conventional) trailers it would work quite easily
17:00<andythenorth_>frosch123: fs updated
17:01<andythenorth_>Terkhen: I now understand attachment a little better :)
17:03<@Terkhen>I'm not sure that's good news if that understanding leads to scary stuff like labels :P
17:03<andythenorth_>forget them for now :)
17:03<@Terkhen>ok :)
17:04*andythenorth_ wonders why it wasn't suggested before by anyone
17:04<andythenorth_>it would be a way to provide cross-grf attachment rules without having to check grfids
17:05<@Terkhen>how many labels would that need?
17:06<andythenorth_>I'm not sure
17:06<andythenorth_>cargo labels have (mostly) worked because mb is very anal about them
17:06<andythenorth_>which is useful
17:06<andythenorth_>rail type labels are...unproven wrt to how useful they are + whether they will degrade
17:06<andythenorth_>for rvs...let me think
17:07<@Terkhen>the issue I'm seeing is that you can have many more engines than cargo types, so you would need much more labels
17:07<frosch123>andythenorth_: currently every fool defines his own rail labels, though you cannot necessarily tell the difference
17:08<andythenorth_>for trucks it would really only be 'articulated' and 'drawbar'
17:09<andythenorth_>anything relating to cargos for example should be handled by varaction 2 in cb 15E, not by esoteric labels
17:09<andythenorth_>trams shouldn't need labels
17:10<andythenorth_>farm tractors and other odd vehicles would need a bit of thought
17:11<andythenorth_>it would need to check the vehicle being attached to, not the lead vehicle
17:11<andythenorth_>it would also need to then check the following vehicle to
17:12<andythenorth_>it's basically to do with how vehicles are physically coupled together
17:13<andythenorth_>a smart newgrf author might be able to handle it all with graphics....
17:14<andythenorth_>but the graphics would need to depend on the preceeding vehicle
17:17<@Terkhen>I think this is quite subjective
17:17<@Terkhen>unless there is some kind of unified view everybody will do whatever he wants with the labels
17:17<andythenorth_>I think it's down to newgrf authors to handle
17:17<andythenorth_>no labels
17:17<@Terkhen>also, engines are not as standarized as cargos or railtypes
17:18<andythenorth_>it will produce the interesting result that truck sets will be incompatible with each other
17:18<andythenorth_>i.e. truck in set A can't haul trailers from set B
17:18<andythenorth_>but that's better than no rv-wagons at all
17:21-!-einKarl [] has quit [Remote host closed the connection]
17:21*andythenorth_ can't see a varact 2 for getting ID of preceeding / following vehicle in a chain
17:22<andythenorth_>I don't want to check their props, just ID
17:23-!-DDR [] has joined #openttd
17:23<andythenorth_>like var C6, but with offsets of +1 or -1 in the consist from current vehicle
17:28*andythenorth_ bed time
17:28-!-a1270 [] has quit [Remote host closed the connection]
17:29-!-andythenorth_ [] has left #openttd []
17:29-!-fonsinchen [] has joined #openttd
17:30<@Terkhen>good night
17:35-!-a1270 [] has joined #openttd
17:39-!-Chris_Booth_ [] has joined #openttd
17:42-!-Chris_Booth [] has quit [Ping timeout: 480 seconds]
17:42-!-Chris_Booth_ is now known as Chris_Booth
17:43-!-ABCRic is now known as Guest1250
17:43-!-ABCRic [] has joined #openttd
17:48-!-Guest1250 [] has quit [Ping timeout: 480 seconds]
17:50-!-lugo [lugo@] has quit [Ping timeout: 480 seconds]
17:55-!-roboboy [] has joined #openttd
17:58-!-lugo [lugo@] has joined #openttd
17:59-!-X-2 [] has quit [Remote host closed the connection]
18:00-!-DanMacK [~DanMacK@] has quit [Quit: Bye for now!]
18:07-!-roboboy [] has quit [Ping timeout: 480 seconds]
18:08<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
18:08<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
18:09<CIA-2>OpenTTD: rubidium * r21894 /trunk/src/ (openttd.cpp openttd.h): -Cleanup: get rid of the unused SM_START_SCENARIO
18:09<CIA-2>OpenTTD: rubidium * r21895 /trunk/src/ (fios.cpp fios.h fios_gui.cpp): -Cleanup: get rid of the unused SLD_NEW_GAME
18:13<CIA-2>OpenTTD: rubidium * r21896 /trunk/src/openttd.cpp: -Cleanup: remove the unused StartScenario
18:18<@SmatZ>Ammler: the suse build system should expect that
18:19<@SmatZ>like, compile with -D__TIME__=1234 ... or sth like that :)
18:19<@SmatZ>also, makedepend (or other tools) tell you what headers are needed for rebuild
18:19<@SmatZ>including system libraries
18:19<@SmatZ>so if those changes, then the package should be rebuilt
18:19<@SmatZ>(unless you are using static linking)
18:20<@SmatZ>Ammler: just replace __DATE__/__TIME__ by "built by OpenSuSE", or whatever you feel nice :)
18:20<Ammler>well, for openttd it isn't that bad as it is a "end binary"
18:21-!-Progman [] has quit [Remote host closed the connection]
18:21<Ammler>but it would be bad, if e.g. grfcodec would use it
18:22<@Rubidium>Ammler: ask him how we should be able to detect which build of the OBS system is creating the crash
18:22-!-frosch123 [] has quit [Remote host closed the connection]
18:22<@Rubidium>as apparantly we are not allowed to store "rebuild" information into the binary
18:23<Ammler>Rubidium: how does debian handle that?
18:23<@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
18:23<@Rubidium>it just rebuilds the binary
18:23<@Rubidium>if it's a library and the ABI changes all packages depending on the ABI are rebuilt
18:24<@Rubidium>otherwise it doesn't rebuild stuff
18:24<@Rubidium>as that'd be insane for each time core utils or gcc is updated
18:24<Ammler>yes, but what if the rebuild time is the only thing, which changed?
18:25<@Rubidium>Ammler: that's not happening with Debian
18:25<@Rubidium>there's always a reasonable reason to rebuild
18:25<Ammler>so if grfcodec changes, openttd would not rebuild?
18:25<@Rubidium>yes, it's not needed is it?
18:26<Ammler>and how does the buildsystem know that?
18:26<@Rubidium>the binary package doesn't depend on grfcodec
18:26-!-ABCRic is now known as Guest1262
18:26-!-ABCRic [] has joined #openttd
18:26<@Rubidium>only the source package does
18:27<@Rubidium>even then, SuSE rebuilds the WHOLE repository each time gcc is updated?
18:27<Ammler>I think so, yes
18:28<@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
18:28<Ammler>hmm, maybe not, I need to ask
18:28<@Rubidium>and not the dozen or so architectures Debian supports
18:29<Ammler>well, usual persons can only use i586 and x86_64 on suse, the rest needs some privilegs
18:30-!-DDR [] has quit [Ping timeout: 480 seconds]
18:30-!-Guest1262 [] has quit [Ping timeout: 480 seconds]
18:30<Ammler>there are 200 build hosts running for those 2
18:32<@Rubidium>Debian has only a hand full of builders for those platforms
18:34-!-ABCRic [] has quit [Quit: The bad thing about quit messages is that you never know how people react to them.]
18:35<@Rubidium>handfull = 5 for i386 and amd64 combined
18:35-!-perk11 [~perk11@] has joined #openttd
18:36<@Rubidium>which is more than enough as those boxes are idling quite a lot
18:37<@Rubidium>really makes a difference whether gcc compiles in 4 or 24 hours
18:37-!-fonsinchen [] has quit [Remote host closed the connection]
18:37<guru3>Right. Got to 1st on the Company League Table in this online game. Now I can go to bed.
18:38<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
18:39<@Rubidium>(or 3 vs 31 hours for openoffice)
18:39-!-Eddi|zuHause2 is now known as Eddi|zuHause
18:39<guru3>Good night.
18:40<Ammler>a lot people have their custom kernels
18:44<Ammler>Rubidium: I asked anc got confirmed, changed gcc does also rebuild openttd :-)
18:45<@Rubidium>that does more harm w.r.t. rebuilds than our debugging stuff
18:45<Ammler>that is why __DATE__ and __TIME__ is bad on obs :-)
18:45<@Rubidium>Ammler: but updating gcc more or less implies that the binaries will be different anyhow
18:46<Ammler>well, they said, I could also just ignore the warning which I do for openttd, as it is end product
18:47<Ammler>Rubidium: yes, in our case, it would harm if grfcodec would have such a thing
18:47<@Rubidium>not really
18:47<@Rubidium>as it'd basically only be rebuilt when there's a new gcc, and then OpenTTD would be rebuilt in any case
18:47-!-Wolf01 [] has quit [Read error: Connection reset by peer]
18:47<@Rubidium>likewise for libpng (as OpenTTD depends on that as well)
18:48<Ammler>maybe you are right :-) (and lucky)
18:48<@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
18:49<Ammler>but you see, that the warning about it is legal?
18:49<@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
18:49<Ammler>Rubidium: it is good to know, if openttd does still build with newer libpng
18:50<@Rubidium>Ammler: in 99% of the cases newer is just some additions or internal library changes
18:50<@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
18:51<@Rubidium>for what it's worth, we list the gcc and library versions as well in the crash log
18:52<@Rubidium>so if *any* of those are updated the data in the crash log will change
18:52<Ammler>those are legal changes
18:53<Ammler>Rubidium: just imagine, we would use build date and time for the newgrfs
18:53-!-supermop [] has joined #openttd
18:53<@Rubidium>Ammler: to counter that, then we'd be storing the version of grfcodec in the NewGRF as well
18:54-!-PUB|lightekk is now known as lightekk
18:54<Ammler>yes, we know, why you don't :-)
18:54-!-perk11 [~perk11@] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
18:55<@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
18:55<Ammler>nah, that would just hide the error
18:56<Ammler>as said, I can ignore it, no issue
18:56<Ammler>I was just wondering, why the newest rpmlint does warn about and got the answer
18:57-!-lightekk is now known as DRUNK|lightekk
18:57<@Rubidium>openttd.i586: W: no-manual-page-for-binary openttd
18:57<Ammler>that is because I splitted the package for dedicated binary
18:57<Ammler>so the man page is in data
18:59<__ln__>*split, split, split
18:59<Ammler>that is something I could bugreport
19:00<@SmatZ>*split splat splut
19:05-!-Biolunar [] has quit [Remote host closed the connection]
19:06<Ammler>he, another suggestion is to make a rpmlintrc to filter out those warnings :-P
19:09-!-Zuu [] has quit [Ping timeout: 480 seconds]
19:10<@Rubidium>Ammler: it doesn't have an option to silence warnings?
19:11<CIA-2>OpenTTD: rubidium * r21897 /trunk/src/ (console_gui.cpp gfx_type.h): -Fix (21707): Kenobi visited IsValidConsoleColour shortly
19:14-!-Adambean [] has quit [Quit: Gone fishing]
19:15<Ammler>Rubidium: rpmlintrc is for that
19:17-!-Chrill [] has joined #openttd
19:22-!-Lakie [~Lakie@] has quit [Quit: Sleep.]
19:34-!-Cybertinus [] has quit [Remote host closed the connection]
19:34-!-DRUNK|lightekk is now known as HNGVR|lightekk
19:42-!-DDR [] has joined #openttd
19:44-!-roboboy [] has joined #openttd
19:57-!-supermop [] has quit [Quit: supermop]
20:06-!-Chrill [] has quit []
20:07-!-roboboy [] has quit [Ping timeout: 480 seconds]
20:08-!-CaptObvious [] has joined #openttd
20:08<CaptObvious>I've set up a dedicated server and when my clients are trying to join it's giving them "Could not load savegame"
20:09<CaptObvious>and the log on the server says "*** CaptObvious has left the game (could not load map)"
20:09<CaptObvious>any ideas what could be wrong?
20:09<+glx>all compression libs linked for clients and server ?
20:09<+glx>xz, zlib, lzo
20:10<CaptObvious>well I get no errors on server start
20:10<CaptObvious>but I'll try grabbing the libs
20:11<+glx>compile time link ;)
20:11<CaptObvious>I downloaded the binaries from
20:12<CaptObvious>emerge isn't finding "xz" - any ideas which package it would be in?
20:14<CaptObvious>aha, xz-utils
20:15<CaptObvious>okay, I grabbed those 3 libraries and it's still doing the same
20:17<CaptObvious>any other ideas?
20:20-!-KenjiE20 [~KenjiE20@] has quit [Quit: WeeChat 0.3.4]
20:23-!-KritiK [] has quit [Quit: Leaving]
20:24<+glx>clients should get an error box
20:24<CaptObvious>they do, "could not load savegame"
20:24<CaptObvious>after downloading the map
20:27<+glx>hmm "openttd -d sl1" maybe
20:27<+glx>server log doesn't help
20:28<CaptObvious>openttd -d sl1 complains about video drivers
20:28<CaptObvious>tried -D sl1 and I get "dbg: [net] getaddrinfo for hostname "sl1", port 3979, address family either IPv4 or IPv6 and socket type tcp failed: Name or service not known"
20:28<+glx>-d is not -D :)
20:29<CaptObvious>I know, as I stated
20:29<CaptObvious>I tried -d
20:29<CaptObvious>"Error: Couldn't find any suitable video driver"
20:29<+glx>oh of course for dedicated server it's -d sl1 -D
20:30<+glx>but try -d sl1 on the client
20:31<CaptObvious>trying that now
20:31<CaptObvious>takes a while to download the map, I'm on a mobile data connection =/
20:32<+glx>maybe it takes too long
20:32<CaptObvious>"Broken save game - invalid chunk size"
20:33<+glx>incomplete file
20:33<CaptObvious>why would the server be giving out an incomplete map? O.o
20:41<CaptObvious>I tried a smaller map
20:41<CaptObvious>same error
21:01<+glx>I don't know, wait for people with more knowledge
21:11-!-grig_58 [~Velin@] has joined #openttd
21:11-!-grig_58 [~Velin@] has left #openttd []
21:17-!-glx [glx@2a01:e35:2f59:c7c0:cd1a:12ba:4bc8:af7f] has quit [Quit: bye]
21:22-!-nicfer [~nicfer@] has joined #openttd
21:26<CaptObvious>heh, I downloaded the svn version and compiled it and now all 3 versions on the site (nightly, beta and stable) give version mismatch
21:28-!-Ttech [] has joined #openttd
21:28-!-dfox [] has quit [Read error: Operation timed out]
21:30<CaptObvious>finally! the beta version works.
21:32<Markk>Wow, 1.1.0 Beta?
21:33<Markk>The time just fly by.
21:49-!-roboboy [] has joined #openttd
21:58-!-roboboy [] has quit [Ping timeout: 480 seconds]
22:03-!-CaptObvious [] has quit []
22:05-!-tokai|noir [] has joined #openttd
22:11-!-tokai|mdlx [] has quit [Ping timeout: 480 seconds]
22:14-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
22:16-!-Chris_Booth [] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]]
22:36-!-Fuco [] has quit [Ping timeout: 480 seconds]
23:25-!-DDR [] has quit [Ping timeout: 480 seconds]
23:45-!-Pulec [] has quit []
23:51-!-xiong [] has joined #openttd
23:51-!-Pulec [] has joined #openttd
---Logclosed Sun Jan 23 00:00:38 2011