Back to Home / #openttd / 2011 / 11 / Prev Day | Next Day
#openttd IRC Logs for 2011-11-09

---Logopened Wed Nov 09 00:00:03 2011
00:10-!-ImpatientSpoon [~Impatient@] has joined #openttd
00:14-!-Devroush [] has quit []
00:17-!-aglenday [~Impatient@] has quit [Ping timeout: 480 seconds]
00:18-!-ImpatientSpoon [~Impatient@] has quit [Ping timeout: 480 seconds]
00:27-!-mahmoud [] has joined #openttd
00:56-!-Eddi|zuHause2 [] has joined #openttd
01:04-!-Eddi|zuHause [] has quit [Ping timeout: 480 seconds]
01:29-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
01:37-!-JVassie [~James@] has joined #openttd
01:50-!-DayDreamer [] has joined #openttd
01:59-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
02:07-!-Celestar [] has joined #openttd
02:33-!-sla_ro|master [~slaco@] has joined #openttd
02:43*Celestar resumes playing with the map.
02:50-!-andythenorth [] has joined #openttd
03:02<Celestar>heya pm
03:03<@planetmaker>hi Celestar :-)
03:05<Terkhen>good morning
03:05-!-Brianetta [] has joined #openttd
03:06<Celestar>the Slope of a tile can only change if the height of itself and the three adjacent tiles with increased indices change in height, right?
03:14<@peter1138>or rather, *or*
03:24<@planetmaker>hi Terkhen
03:26<@planetmaker>moin andythenorth
03:27*andythenorth wonders if Eddi|zuHause2 is awake yet
03:27-!-Eddi|zuHause2 is now known as Eddi|zuHause
03:27<andythenorth>me neither
03:27<andythenorth>Eddi|zuHause: I 'done a reply innit'
03:28-!-Brianetta [] has quit [Quit: Tschüß]
03:29<Celestar>peter1138: yeah :P
03:31<andythenorth>peter1138: label based refit using action 3 cargos NOT all other labels in CTT?
03:31<andythenorth>fallback to classes, no XOR madness
03:35<@planetmaker>andythenorth: no not
03:35<@planetmaker> not in CTT hm..
03:36<@planetmaker>makes it a bit hard to craft vehicles without mentioning each cargo separately
03:36<andythenorth>planetmaker: that's one of the costs
03:36<andythenorth>but tbh I think crafting vehicles based on classes is wrong-headed
03:36<andythenorth>I know it's easier
03:37<@planetmaker>and it disables a way to decide on the cargo display somewhere further down the decision tree (i.e. in the default branch)
03:38<@planetmaker>something which for example all my newgrfs do ;-)
03:38<andythenorth>did I miss something? :o
03:38<andythenorth>what causes that unwanted side effect?
03:38<andythenorth>the action 3 would be unchanged, this would just establish refits
03:38<andythenorth>you'd still have a graphics branch of n varact 2s
03:39<@planetmaker>now the graphics branch can go like "first decide build year", then decide company, then only check for actual cargo type in vehicle and then branch
03:39<@planetmaker>to the appropriate graphics
03:40<@planetmaker>and not mention the cargo label in the action3
03:40<andythenorth>oh I see
03:40<@planetmaker>(or rather entry into the CTT which can be mentioned in action3)
03:40<andythenorth>the requirement to be explicit breaks that
03:41<Eddi|zuHause>planetmaker: well, all action 3 entries may still point to the same action 2
03:41<andythenorth>or does it? :)
03:41<@planetmaker>True, Eddi|zuHause
03:41<@planetmaker>and I actually still like this idea... it doesn't break the properties
03:41<andythenorth>Eddi|zuHause: I've no idea if my solution to classes can be implemented - but it seems to meet your case
03:41<@planetmaker>does it need grf v8? I guess
03:42<@planetmaker>as it changes something in a not-backward compatible way
03:43<Eddi|zuHause>where are we on semantics? "if in Action3=>allow, else if in CTT => disallow, else ask classes"?
03:43<andythenorth>two very clean sets: 'known' and 'unknown'
03:44<Eddi|zuHause>so you leave out all cargos from CTT which you do not bother for specific graphics
03:44<andythenorth>you could yes
03:44<andythenorth>moving to action 3 check would remove the <32 limit?
03:45<andythenorth>in fact that's the case already isn't it?
03:45<andythenorth>I use that in HEQS
03:48<andythenorth>maintaining a CTT isn't too much work :)
03:49<andythenorth>and sensible people might template their action 2/3 chains anyway...
03:50<Celestar>michi_cc: how do I obtain a TileIndex from an iterator?
03:51<Celestar>-> ?
03:52<@peter1138>andythenorth, you are a grave digger
03:52<@peter1138>i don't even remember writing that stuff :p
03:53<Eddi|zuHause>peter1138: it's actually frosch's fault for pointing out that this proposal exists :p
03:53<@peter1138>it doesn't help with the problems that cargo classes tries to solve
03:53<@peter1138>that is, unknown cargo types
03:54<@peter1138>but imho supporting cargo classes should be pretty generic, not specialised
03:54<andythenorth>it's not supposed to solve classes :)
03:54<andythenorth>but it helps a lot - by disconnecting them from labels entirely
03:55<Eddi|zuHause>"supporting cargo classes" is a matter of everybody agreeing what cargo classes mean
03:55<Celestar>where is the damn opening game ffs :P
03:55<Eddi|zuHause>Celestar: data/opntitle.dat
03:55<andythenorth>using the action 3 also restores some sanity
03:56<andythenorth>no more train prop 1D :)
03:56<andythenorth>no more XOR
03:57<andythenorth>Eddi|zuHause: (for example only, let's not get stuck on reality) - so for classes, you might have fertiliser, which is bulk and piece. In bulk form you want the moisture protect category. But for piece goods that category simply doesn't exist - we assume that piece goods are always packaged appropriately.
03:58<andythenorth>this is approximately your scheme?
03:58<andythenorth>we should test it against current classes
03:58<andythenorth>or did you already?
03:59<andythenorth>looks like you did
03:59<Eddi|zuHause>it's in the list of my post
03:59<andythenorth>so does my proposal to split the bytes make sense (in the thread)?
04:01<Eddi|zuHause>it disregards the fact that we have to deal with an existing spec, which can only have incremental changes
04:01<Celestar>michi_cc: you around?
04:02<andythenorth>Eddi|zuHause: can that be worked around? :P
04:03<andythenorth>if there's extensive breakage that might be the cost we have to pay
04:03<andythenorth>depending who backs it, it might simply not matter
04:03<andythenorth>MB might agree
04:03<andythenorth>coop might agree
04:03<andythenorth>pikka _might_ agree
04:04<andythenorth>george looks fed up with current system
04:04<andythenorth>oops, sorry for highlight
04:04<Eddi|zuHause>andythenorth: if you as a cargo set author can live with setting properties for both "old style" classes and "new style" classes
04:05<andythenorth>I could yes
04:06<andythenorth>the 'old' properties would be set pretty bluntly, using primarily just a few core classes
04:06<andythenorth>to avoid breakage on the exclude problem
04:07<andythenorth>he's fast
04:07<andythenorth>the fastest in the west
04:07<Eddi|zuHause>it's only half the proposal, though :)
04:08<@planetmaker>it misses the doxygen for the variable ;-)
04:08<andythenorth>we could at least test it for him :P
04:08*andythenorth can't, 10am actual meeting, with actual work to do
04:08<andythenorth>but probably later
04:09<Eddi|zuHause>peter1138: the point was that action3 can have _more_ than 32 entries
04:09<Eddi|zuHause>so an uint32 is defeating the point
04:11<Eddi|zuHause>or is that cargo slots at that point already?
04:15-!-Neon [] has joined #openttd
04:15<Celestar>stupid optimizer ...
04:17<Celestar>(gdb) p _m[t]
04:17<Celestar>Segmentation fault
04:17<Celestar>ouch :P
04:19<Celestar>and why does this hang? (gdb) p MapSizeX()
04:19<Celestar>oh it doesn't O_o, it only takes 20 seconds to complete
04:20<@planetmaker>on big maps with many rivers and industries it may take a bit :-)
04:21<Celestar>what does MapSizeX have to do with rivers? :P
04:22-!-Brianetta [] has joined #openttd
04:23<@planetmaker>river generation takes longer on large maps
04:23<@planetmaker>as they employ path finding
04:23-!-TWerkhoven [] has joined #openttd
04:24<@peter1138>Eddi|zuHause, it's after the translation
04:26<Celestar>planetmaker: _!
04:26<Celestar>planetmaker: ~...extern uint _map_size_x;
04:26<Celestar>~...return _map_size_x
04:26<Celestar>that's the whole function :P
04:28-!-andythenorth [] has quit [Quit: andythenorth]
04:28<@peter1138>i think planetmaker is misinterpreting you :)
04:28<@planetmaker>probably :-)
04:28<@peter1138>MapSizeX() isn't a lot to do with rivers
04:28<Celestar>p MapSizeX()
04:28<Celestar>in gdb takes 20 seconds to complete
04:30-!-andythenorth [] has joined #openttd
04:30<Celestar>m1 = 0 '\000', m2 = 0, m3 = 0 '\000', m4 = 3 '\003', m5 = 5 '\005', m6 = 0 '\000', m7 = 0 '\000',
04:30<Celestar>that does look weird :P
04:30<@peter1138>i think you broke it
04:38-!-DayDreamer [] has quit [Quit: Leaving.]
04:59<@peter1138>Eddi|zuHause, so does it work? :p
05:00<Eddi|zuHause>no idea :)
05:02*andythenorth will test it later
05:03<andythenorth>so if I set the refit mask and class props to 00, and get refits matching my action 3 cargo types, it works?
05:03<andythenorth>for some value of 'works'?
05:04-!-pjpe [] has quit [Quit: ajax IRC Client]
05:08<Celestar>peter1138: yeah I broke quite some shit :P
05:09<@peter1138>andythenorth, take out all the refit properties
05:10<Celestar>but at least I only broke saveload :D
05:10<@peter1138>nothing important :D
05:11<@peter1138>andythenorth, of course, then it's incompatible with older ottd ;)
05:12<@peter1138>i don't treat not as in action 3 as exclude
05:12*Celestar curses at AfterLoadGame
05:12<@peter1138>that would definitely require grfv8
05:15<@planetmaker>Explicit refit via CTT and action3 is nice. I'm not entirely sure about the "not in action3 but in CTT", whether that should mean "not refittable to"
05:17<@peter1138>i guess the thinking is it's a known cargo, and you didn't include it, therefore you must not want it
05:17<@peter1138>also it's more complex to write :p
05:17-!-andythenorth_ [] has joined #openttd
05:17-!-andythenorth is now known as Guest16382
05:17-!-andythenorth_ is now known as andythenorth
05:18<@planetmaker>the thinking is clear, sure
05:18-!-Guest16382 [] has quit [Read error: Connection reset by peer]
05:19<@planetmaker>it's definitely more work, though
05:19<@planetmaker>as I then always need the cargos I want to refit to and the default
05:19<@planetmaker>while now for containers the default suffices ;-)
05:19<@planetmaker>But it's still a good solution, I think
05:20<@planetmaker>with the added benefit that we don't need to topple cargo classes as they are
05:20<@planetmaker>i.e. it's quite backward compatible
05:20<@planetmaker>without adding many new properties and many new class defintions
05:21<@planetmaker>which would make newgrfs incompatible with old(er) versions of openttd
05:21<@Yexo>what was the idea exactly? For all cargos in CTT: in action3 => refitable, otherwise => not refitable. For all cargos not in CTT: use cargoclasses?
05:22<@Yexo>that would be something for grfv8
05:22<@planetmaker>also yes :-)
05:23<@planetmaker>but I prefer that much over a complete class re-design
05:23<@Yexo>might require a lot of work as you need to explicitely state every known cargo every time, but it would cover all cases I think
05:23<@planetmaker>it'd make it easy. And you know explicitly which cargos you support
05:24<@planetmaker>(you don't quote those which the wagon doesn't transport)
05:25<Celestar>I need to give AfterLoadGame some thought. this is a monster :P
05:26<andythenorth>Yexo: it would also de-conflate the current situation, which (looks to me) like misusing classes to try and ensure detailed support
05:27<@planetmaker>and of course one can still rely on the cargo classes
05:27<@Yexo>planetmaker: only if you never need to know the cargo
05:27<@planetmaker>for specilized graphics you need to quote the label anyway
05:27<@planetmaker>if not - then you can use the class instead. Which would be better
05:27<@Yexo>you don't quite the label, you quote the index in your CTT
05:28<@Yexo>which implies the cargo is in your CTT, so you can't rely on cargoclasses
05:28<@planetmaker>yes, true. but in NML you do ;-)
05:28<@Yexo>that's an abstraction in nml :)
05:28<@planetmaker>yes. A good one
05:31<@planetmaker>still, there's no problem with that as the CTT can be longer than 32 entries
05:32<@planetmaker>and relying on classes for cargo w/o special graphics probably is good.
05:32<@planetmaker>If you don't want to do that: only then you have to quote the label explicitly
05:33<@planetmaker>thus: use a short CTT :-P
05:35<@peter1138>i remember someone was using different CTTs depending on which cargo set was loaded
05:35<@peter1138>completely missing the point of them
05:36-!-DDR_ [~chatzilla@] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20111008085652]]
05:36<@peter1138>anyway, my patch doesn't check for grfv8 because i didn't implement the exclude rule
05:36<@peter1138>and tbh i don't fancy implementing it :p
05:38<@peter1138>although it just requires a loop through the CTT for each vehicle during the final refit stuff
05:39<@Yexo>you just need to loop once through the CTT to create a mask against the currently valid cargos
05:39<@Yexo>than you can use that mask
05:39<@peter1138>hmm, yeah
05:39<@peter1138>quite minor after all :p
05:40<@peter1138>is it wanted?
05:41<@peter1138>Yexo, once per grf
05:41<@Yexo>yes, ofc
05:41-!-DOUK [] has joined #openttd
05:42<@planetmaker>we should ask frosch about his thoughts on that implementation
05:42<@planetmaker>But ... sounds good to me
05:42<@Yexo>more in general just post it to the discussion topic on the forums
05:42-!-sla_ro|vista [~slaco@] has joined #openttd
05:43-!-Borgso [] has joined #openttd
05:43-!-Vettel [] has joined #openttd
05:44-!-bb10X [] has joined #openttd
05:44-!-yorick [] has joined #openttd
05:44-!-Eitsew [] has joined #openttd
05:44-!-xORR [] has joined #openttd
05:44<@planetmaker>yes, probably better
05:45-!-TheMask96- [] has joined #openttd
05:45-!-Hinrik_ [] has joined #openttd
05:46-!-panna [] has joined #openttd
05:46-!-snorre_ [] has joined #openttd
05:46-!-SpBot [] has joined #openttd
05:46-!-blathijs_ [] has joined #openttd
05:46-!-Netsplit <-> quits: bb10, +michi_cc, sla_ro|master, ashb, mahmoud, XeryusTC, Osai, xQR, Zeknurn, dotwaffle, (+15 more, use /NETSPLIT to show all of them)
05:46-!-Vettel is now known as Zeknurn
05:46-!-xORR is now known as xQR
05:46-!-Netsplit over, joins: ashb
05:49-!-dfox [] has joined #openttd
05:49-!-Mazur [] has joined #openttd
05:49-!-SmatZ [] has joined #openttd
05:50-!-michi_cc [] has joined #openttd
05:50-!-mode/#openttd [+v michi_cc] by ChanServ
05:50-!-Terkhen [] has joined #openttd
05:50-!-Osai [] has joined #openttd
05:50-!-XeryusTC [] has joined #openttd
05:50-!-mode/#openttd [+o Terkhen] by ChanServ
05:50<andythenorth>peter1138: it was OzTrans using different CTTs
05:50<andythenorth>and he has gone off and taken his toys home
05:51<Celestar>can't gprof profile a single function *sigh*
05:52<Eddi|zuHause>why do the default cargos need 3 separate lables for grain/wheat/maize?
05:53<andythenorth>Eddi|zuHause: hysterical raisins?
05:54<@peter1138>cos they're different things?
05:54<Eddi|zuHause>real question: if we change default labels to accompany with new cargo classes, can we safely unify these three?
05:55<andythenorth>only to something fuzzy like 'cereals'
05:55<andythenorth>or 'grains'
05:55<Eddi|zuHause>i mean only by label. they would still show different names in each climate
05:56<@peter1138>what would merging the labels achieve?
05:56<andythenorth>Eddi|zuHause: from FIRS experience same label, different names is a bad pattern
05:56<andythenorth>it's just an arse
05:57-!-dotwaffle [] has joined #openttd
05:57<Eddi|zuHause>peter1138: if we want to change cargo classes of default cargos, we must introduce new labels. the difference is introducing one new label or 3
05:57<@peter1138>who wants to change the default cargo classes
05:57<Eddi|zuHause>i do
05:57<@peter1138>and why does that require need cargo labels?
05:57<Eddi|zuHause>because without new label, existing refit masks break
05:58<@peter1138>Eddi|zuHause, you are crazy
05:58<@peter1138>with a new label, existing refit masks break
05:58<Eddi|zuHause>no, with a new label, cargo class based refits trigger
05:58<@peter1138>i propose not changing with the default classes and definitely not the labels
05:59<@peter1138>a lot of stuff has a refit mask without cargo classes
05:59-!-rhaeder [] has joined #openttd
05:59<@peter1138>well, ok, i'm assuming :p
06:00<Eddi|zuHause>i would assume everything that has a CTT also has cargo classes
06:00<Eddi|zuHause>without CTT, the label is irrelevant, the refits don't change at all, since the slots don't change
06:00-!-sla_ro|vista [~slaco@] has quit []
06:04-!-blotek_ [] has joined #openttd
06:21<appe>a recommendation; the "South Sweden" scenario combined with a girlfriend who works with the swedish train systems office.
06:21<appe>"nono, you are supposed to always make the x2k break down just before Linköping. you said you wanted it to be realistic, right?"
06:23<appe>x2k (x2000), swedish passanger train.
06:23<MNIM>hahaha, appe
06:24<appe>the x2k is infamous for being two things in sweden
06:24<Mazur>I wondered, because here in the Netherlands nothing (important) actually experienced a Y2k problem, at the time.
06:24<appe>the fastest train we have, and the slowest, since it always breaks down before it can get to it's destination.
06:24<appe>Mazur: harr.
06:24<Mazur>I hear you.
06:26-!-MNIM [] has quit [Remote host closed the connection]
06:26<appe>actually, the best trains in sweden are the smaller and slower x61/14
06:27<andythenorth>Eddi|zuHause: why do you need to change the classes on existing labels?
06:27<andythenorth>I miss the point
06:27<Eddi|zuHause>andythenorth: because their classes are wrong
06:27<andythenorth>so it's a 'correctness' issue
06:27<Eddi|zuHause>andythenorth: it causes exceptions where they don't need to be
06:28<andythenorth>not an 'I want to control refits on known labels using classes' fallacy
06:28<Eddi|zuHause>andythenorth: which again will cause confusion with everybody who starts a set and starts out with class based refits
06:30<andythenorth>and then they'll start dicking around with classes in a wrong fashion :P
06:30<andythenorth>but that's ok, because they're doing it wrong anyway using class based refits
06:32<andythenorth>Eddi|zuHause: write a forum post about it :)
06:33<TrueBrain>Eddi|zuHause: I cannot deny nor admit any of that (slow reply, I know)
06:33<appe>im having the best month of my life.
06:33<appe>i just fucked up orders for a quarter of a million swedish kronor.
06:34<Eddi|zuHause>appe: better than misaccounting 55.5 billion €
06:35<Celestar>Eddi|zuHause: comon, that's only sub-percentage error :P
06:36<Eddi|zuHause>Celestar: i think it was something around 2.5%
06:36<Celestar>Eddi|zuHause: little enough for the average bean counter to not give a damn..
06:37<Celestar>yes. I do hate them with a passion
06:37<appe>Eddi|zuHause: 55.5 billion euro?
06:38<@planetmaker>luckily they just "found" them. Not "found them missing"
06:38<Celestar>I'd like to "find" 55 billion EUR too
06:39<Celestar>or even 55 million for that matter
06:41<@planetmaker>I'd even content for 5.5 million or 0.55 million ;-)
06:44<CIA-6>OpenTTD: yexo * r23172 /trunk/src/order_gui.cpp: -Fix (r23088) [FS#4831]: crash when looking at orders from a vehicle that's not in your company
06:44<@peter1138>can i have a force dynamics 401cr?
06:44<@planetmaker>hm. yexo was faster
06:45<Celestar>planetmaker: yeah, would not mind either of the options :P
06:48-!-frosch123 [] has joined #openttd
06:48<Eddi|zuHause>hm... is paper "lightweight"?
06:48<Celestar>not at all.
06:48<Celestar>the density of paper is very high.
06:49<Celestar>Eddi|zuHause: it's ROUGHLY between half and twice the density of water. which is heavy enough.
06:50<Celestar>planetmaker: but just one cannot help but wonder whether those "sesselpfurzer" have any idea about the numbers they're dealing with.
06:50<@planetmaker>they clearly don't
06:50<frosch123>everyday i join, there is the same topic going on :s
06:51<Celestar>frosch123: paper density?!
06:51<frosch123>no, the intention behind eddi's question
06:52<Celestar>rofl. ok.
06:52<@peter1138>and somebody dug up something i posted nearly 3 years ago ;p
06:52<Eddi|zuHause>frosch123: well, if we don't resolve this soon, nothing changes, and we have the same discussion next year all over again
06:52<frosch123>hmm, is it a good sign that now girls also go amok?
06:53<Celestar>frosch123: where?
06:53<@peter1138>equal opportunities?
06:53<frosch123>Celestar:,1518,796732,00.html (german)
06:53<Eddi|zuHause>frosch123: the technical term is "go postal" :p
06:53<@planetmaker>equal opportunities killer?
06:55<Eddi|zuHause>frosch123: it's never an "ali" or "mahmud" though...
06:55<Celestar>Eddi|zuHause: nah. those use bombs.
06:55<Eddi|zuHause>Celestar: that never happens either...
06:56<Celestar>13 year old girl.
06:57<Celestar>that's some extreme version of BDSM isn't it?
06:57<@peter1138>no, it's german
06:57<Celestar>peter1138: what is?
06:58<Eddi|zuHause>i should probably not have googled for "BDSM"
06:59<Celestar>don't google for "manpages" either :P
06:59<andythenorth>Eddi|zuHause: paper lightweight?
06:59<andythenorth>how do you want it to be transported? :P
07:00<andythenorth>Eddi|zuHause: try asking it as "how does paper travel" ??
07:00<Eddi|zuHause>andythenorth: if paper is not lightweight, what is MNSP then?
07:01<andythenorth>that is indeed a good question
07:01<Eddi|zuHause>(one has "express" set, the other doesn't)
07:01<andythenorth>"MNSP a cargo that is delivered to industries"
07:01*andythenorth has other tautologies available
07:02<andythenorth>MNSP is express so that it goes in Pikka's vehicles that allow refitting to express
07:02<Mazur>Paper lightweight? You've never had to unload a paper delivery at an office, then?
07:02<Eddi|zuHause>andythenorth: if i understand "MNSP" as "packaging materials"
07:02<@peter1138>what's MNSP?
07:02<andythenorth>manufacturing supplies in FIRS
07:02<andythenorth>the current use of express might be considered not wholly valid - see reasoning above :P
07:03<andythenorth>it's the kind of reverse-compatibility crap that I want to cut out
07:03<andythenorth>mnsp is piece goods
07:04<Eddi|zuHause>which is why i want to reinterpret "express" as "lightweight"
07:04<andythenorth>it's not even a valid 'priority' cargo in gameplay
07:05<Eddi|zuHause>meaning "goes in closed wagons with larger packaging area, to make full use of the allowed weight"
07:05<andythenorth>what about "suitable for air transport"? And "can be shipped by higher-speed transport, such as mail and PAX trains" ?
07:05<andythenorth>and other such?
07:06<andythenorth>I don't have the issue with express that some of you do, it makes no sense, but works
07:07<Eddi|zuHause> <-- this is a normal cargo wagon with 15t capacity for "piece and express goods, animals, bodies, baggage, mail, and cargos that need to be covered"
07:07-!-KenjiE20 [] has joined #openttd
07:08<Eddi|zuHause> <-- this is a larger carggo wagon with 15t capacity, for "cargos with special permit, elephants, camels, giraffes, airplane parts, <long list with special exceptions>"
07:09<Eddi|zuHause>andythenorth: that's what it says in the table:
07:10<@peter1138>andythenorth, so did it work? :0
07:10*andythenorth will test now
07:10<@peter1138>wrong shift order, that should've been a ;)
07:10<Eddi|zuHause>andythenorth: so basically, it should be something between "piece goods" and "oversized"
07:11<andythenorth>'special' :P
07:11<andythenorth>bodies are probably express
07:12<andythenorth>as are cammels
07:12<andythenorth>you don't want them waiting around :P
07:14*andythenorth thinks "compile faster"
07:14<@planetmaker>camels are vehicles. Not cargo
07:14<andythenorth>vehicles in vehicles
07:14<Eddi|zuHause>damn, too slow :p
07:14<andythenorth>I have a macro for it :P
07:14<andythenorth>how do I compile faster? Get a faster OS?
07:15<@planetmaker>make -j3
07:15<@planetmaker>or -j7
07:15<andythenorth>I used -j6
07:15<andythenorth>for laughs
07:15<Celestar>make -j :D
07:15-!-hanf [] has joined #openttd
07:15<Eddi|zuHause>question: do we want a cargo class that decides between "piece goods, can be in an open or closed wagon" and "piece goods, must be in a closed wagon"?
07:15<@planetmaker>how long does it take you then?
07:16<Eddi|zuHause>i always use make -j12
07:16<@peter1138>you want classes that let you transport goods even if you don't know about them, in a mostly transparent and generic way
07:16<andythenorth>planetmaker: about 3 minutes
07:17<@planetmaker>that's not too bad
07:17<andythenorth>Eddi|zuHause: no
07:17<andythenorth>it's not an appropriate choice
07:19<andythenorth>Eddi|zuHause: you mean an extra class? or a new core class instead of express?
07:19<andythenorth>I missed the context sorry
07:19<andythenorth>maybe I meant yesno
07:19<Eddi|zuHause>an extra class
07:20<andythenorth>so like existing 'covered' ?
07:20<Celestar>make -j takes 2:56 here
07:22<Eddi|zuHause>andythenorth: yes, but for piece goods only
07:22<andythenorth>why is it valid?
07:23<andythenorth>or to put it another way, if you only had 4 bits to spend on extra classes for piece, would this be one of them?
07:23<andythenorth>one of those bits is almost certainly 'livestock'
07:23<Celestar>make -j4 takes 2:27
07:23<andythenorth>and another is probably 'outsized or awkward'
07:24<andythenorth>I don't think we should allow 8 exclude classes, it's an arse
07:24<Eddi|zuHause>"make clean && time make -j12": real 0m38.841s user 2m7.435s sys 0m16.435s
07:25<Eddi|zuHause>CETS is unfortunately not that fast...
07:25<Celestar>Eddi|zuHause: bigass box :P
07:25<Eddi|zuHause>Celestar: it's already a year old
07:25<Eddi|zuHause>Celestar: and i took the slowest back then
07:26<Celestar>mine is a 3-year laptop :P
07:26<Celestar>make -j3 is 2:20
07:26<Celestar>Eddi|zuHause: what CPU isthat?
07:26<Eddi|zuHause>same as above, with caching effects: real 0m30.882s user 2m6.625s sys 0m15.797s
07:27<Eddi|zuHause>AMD Phenom II X6 1055T 6x2.8GHz / 9MB / 125W
07:28<Celestar>why -j12?
07:28<andythenorth>real 2m7.098s user 7m6.068s sys 0m33.103s
07:28<Eddi|zuHause>because it's 2*6?
07:28<andythenorth>no idea if -j12 works best for my CPU
07:28<Eddi|zuHause>they say with n cores you should use -j(2n+1)
07:28<andythenorth>I have 2 cores, 2 threads per core
07:28<Eddi|zuHause>so technically that would be -j13
07:28<Celestar>Eddi|zuHause: somehow for me -j4 is slower than -j3
07:28<__ln___>uh oh, bad times for the Red Arrows
07:30<Celestar>but I guess I'm bottlenecked by the damn notebook disk :P
07:30<Eddi|zuHause>above -j(n) is probably only relevant if you have lots of uncached I/O
07:30*Celestar plans to get an SSD soon
07:30<Celestar>just not sure which.
07:30<Eddi|zuHause>so a "test series" is likely to give skewed results
07:31<Eddi|zuHause>because after reading the whole source once, it's in the cache
07:31<Celestar>Eddi|zuHause: I'm running each test twice :P
07:31<Celestar>-j2 2:19
07:32<Eddi|zuHause>Celestar: is that real or user?
07:35<andythenorth>peter1138: the action 3 patch appears to work
07:35<andythenorth>I haven't tested yet for cargos > 32
07:35<Celestar>-j1 3:40
07:35<andythenorth>buy menu cargo doesn't freak it out
07:36<Eddi|zuHause>-j1: real 2m4.609s user 1m47.602s sys 0m16.254s
07:36<andythenorth>the refit and class masks are all 0
07:36<Eddi|zuHause>with the caching effects, there is no benefit beyond -j6
07:37<andythenorth>Eddi|zuHause: the question about 'covered' piece - is that a specific detail, or a general concern about the scheme?
07:37<Eddi|zuHause>andythenorth: the question is, which cargos benefit from it?
07:37<andythenorth>from existing known cargos?
07:37<andythenorth>none :P
07:37<andythenorth>to be strict
07:37<andythenorth>but for example purposes, maybe some
07:38*andythenorth -> newgrf wiki
07:38<Eddi|zuHause>other question: make paper "oversized" (so it goes on stake wagons)?
07:39<@planetmaker>that sounds stupid
07:39<@planetmaker>paper is a cargo which is excellently palettized
07:39<Eddi|zuHause>planetmaker: that's how they are transported in the default set
07:40<@planetmaker>yes, but anything not oversized excluded from a stake wagon is stupid ;-)
07:40<Eddi|zuHause>so you'd like stake wagons for every piece goods?
07:42<Eddi|zuHause>planetmaker: so what'd be the benefit of using a closed wagon then?
07:43*andythenorth is puzzled
07:43<Eddi|zuHause>planetmaker: but "dry" has no gameplay effect
07:44<andythenorth>I don't get it
07:44<andythenorth>paper goes on stake wagons because they support the label 'PAPR'
07:44<andythenorth>unless we're trying to do some backwards compatibility
07:45<Eddi|zuHause>andythenorth: no set ought to use explicit labels, unless they want to display specific graphics
07:45<andythenorth>so you think the action 3 patch is an incorrect approach?
07:46<Eddi|zuHause>andythenorth: no, this is completely separate
07:46<andythenorth>a separate approach? Or separate part of the same puzzle?
07:47<Eddi|zuHause>the latter
07:47*andythenorth is still confused :D
07:47<andythenorth>you're working to establish class-based refits which can be precise?
07:48<Eddi|zuHause>andythenorth: a vehicle set author shall have the opportunity to override the classification by adding specific labels. but class based refit should be the default
07:48<andythenorth>'default' as in 'first considered' or default as in 'fallback' ?
07:48<Eddi|zuHause>the former
07:49<Eddi|zuHause>the "standard approach that is taught to newbies"
07:49<andythenorth>so you propose that classes are not an abstraction mechanism?
07:49<andythenorth>their goal needs to be expanded beyond 'provides a fallback'
07:49<Eddi|zuHause>classes ARE an abstraction scheme
07:50<andythenorth>not if they're intended to convey detailed information about specific cargos reliably
07:51<andythenorth>I don't think you're wrong, but imho you're rewriting the spec for classes
07:51<andythenorth>maybe that's your intention :D
07:51<Eddi|zuHause>at least in my mind, it works like this: there's a "canonical set of abstract wagons" noted in the wiki. a cargo set author distributes his cargos among these wagons so at least one wagon loads the cargo. a vehicle set author implements either each of these wagons, or combines some wagons, or provides special wagons that don't fit into this scheme
07:51<andythenorth>I think you're writing a promise we can't keep, e..g
07:52<andythenorth>promising 'classes are only a fallback' is a promise we can keep
07:52<andythenorth>promising 'classes are the best way to ensure correct vehicle support' is going to fail
07:52<andythenorth>because 'correct' is undefinable
07:53<Eddi|zuHause>maybe not "correct", but "complete" and "consistent"
07:53<andythenorth>I would doubt that we can provide 'consistent'
07:53*peter1138 ponders committing this action 3 thing
07:53<andythenorth>'complete' works
07:53<@peter1138>"well tested" ;p
07:54<andythenorth>peter1138: bound to succeed
07:54<Eddi|zuHause>peter1138: sorry, not testing anything right now... i'm in an "abstract" mood...
07:54<@Yexo>peter1138: very bad timing while the discussion about cargoclasses on the forums is still going
07:55<@Yexo>better propose your solution there first
07:55*planetmaker wonders what frosch123 thinks about grfv8: cargo label in action3: allow refit unconditionally. cargo label not in action3 but in CTT: disallow refit unconditionally. cargo label neither in action3 nor in CTT: use cargo classes as now
07:55<@peter1138>why? it doesn't affect classes at all
07:55<andythenorth>it does affect the XOR
07:55<andythenorth>but other than that it's complete win
07:55<@peter1138>and all this talk about changing existing classes, and even changing the original cargo labels... urgh
07:56<@planetmaker>peter1138: it's a change which directly relates to this discussion
07:56<andythenorth>it's not connected to the classes issue
07:56<andythenorth>it's nicely decoupled apart from the XOR
07:56<@peter1138>andythenorth, it doesn't affect the XOR
07:56<frosch123>planetmaker: i wonder whether actually *any* modern vehicle newgrf uses cargos in action3 besided 0xFF
07:56<frosch123>i would expect every newgrf, which uses callback to branch later
07:56<andythenorth>peter1138: what happens if I set a refit mask in train prop 1D (refittable cargos)
07:57<andythenorth>I didn't test that :)
07:57<Eddi|zuHause>it makes the XOR useless
07:57<@Yexo>frosch123: every NML-created grf does
07:57<@planetmaker>Yexo: I didn't ;-)
07:57<frosch123>Yexo: what? branch later? or branch in action3 ?
07:57<Eddi|zuHause>andythenorth: any bit set in prop 1D is overridden
07:57<@Yexo>branch in action3, at least if you provide the cargo label in the graphics block
07:57<@planetmaker>but I guess that support was added to NML when I had the cargo_in_veh_type switch already
07:57<@planetmaker>as such: hysterical raisins ;-)
07:58<@Yexo>planetmaker: I doubt that, that was one of the first nml features :p
07:58<@planetmaker>well :-P
07:58<Eddi|zuHause>andythenorth: unless your CTT is shorter than 32. then behaviour is probably undefined
07:58<andythenorth>recoding HEQS trams for this action 3 route will make for a witty time for moi
07:59<@peter1138>andythenorth, basically, the refit mask is set up as before, and then all the cargos from the action 3 are overlaid over that
07:59<Eddi|zuHause>andythenorth: aren't HEQS trams refittable to everything?
07:59<@peter1138>if you're saying grfs are not even using the cargo type feature in favour of manually checking (wtf? why would you do that?) then i see no point in this
07:59<@planetmaker>the action3 approach would deprecate the cargo-lable-xor-property
07:59*andythenorth uses the action 3 approach
07:59<andythenorth>its explicit and easy
08:00<frosch123>well, if action3 is commonly used for branching... we could add a flag to some misc property which disables usage of the xor thingie and enable the action3/ctt thingie instead
08:00<@Yexo>peter1138: if you use the cargo type feature in action3 you have to branch callbacks for every cargotype
08:00<andythenorth>a few cases uses varact 2, but there's no particular gain
08:00<frosch123>i would not change it by default in grfv8
08:00<@Yexo>otherwise you can handle callbacks first and than fall back to a varaction2 that chose the correct graphics
08:00<Eddi|zuHause>frosch123: misc flag sounds like a sensible idea
08:01<andythenorth>I'd go with this
08:01<andythenorth>it's one big bit of arse removed
08:01<Eddi|zuHause>frosch123: or a per-vehicle-flag
08:01<andythenorth>deprecating some dumb classes is another bit sorted
08:02<@peter1138>ok, fine
08:02<@peter1138>so it's pointless
08:02<andythenorth>then it's "just" a case of seeing if Eddi|zuHause is smoking crack about classes
08:02<frosch123>Eddi|zuHause: i mean a "misc" vehicle property
08:02<Eddi|zuHause>frosch123: not sure what that is
08:02<andythenorth>special flags?
08:02<frosch123>Eddi|zuHause: train property 27
08:02<frosch123>and simliar for all vehicles
08:03<frosch123>they all have such a property
08:03<frosch123>they even use the same bit configuration
08:03<andythenorth>would this need tool updates? grfcodec et al
08:03<@peter1138>change the refit parameter for grfv8 :)
08:03<andythenorth>default = action 3 in v8?
08:03<andythenorth>default = current in v7?
08:03<@peter1138>make it a list of indices into the CTT instead of a bitmask
08:04<@peter1138>(you're stuck with the XOR problem then, though)
08:04<frosch123>peter1138: you do the update of nforenum and the other tools
08:04<frosch123>changing the size of act0 props is a no-go
08:04<@Yexo>peter1138: that was explicitely decided against since it chagnes the size of an existing property
08:04<andythenorth>action 3 route \o/ :)
08:04<@Yexo>what would be possible is adding two new properties, an include list of cargo-indicies and an exlucde-list
08:04<@peter1138>andythenorth, it's not useful, yexo already stated that
08:04<@Yexo>instead of the current xor-mask
08:05<Eddi|zuHause>new properties: refittable cargo list, and unrefittable cargo list
08:05<frosch123>anyway, what makes the action3 route different from a callback?
08:05<@peter1138>you were against a callback
08:05<frosch123>the action3 route feels weird for me, esp. since i would usually branch callback first, later cargotype
08:05<Eddi|zuHause>callbacks can do too many evil things
08:05<andythenorth>the action 3 route is incapable of evil
08:05<Celestar>cliffs are going to buf ....
08:06<andythenorth>refittable to x before 1900, to y after 1900
08:06<Celestar>be fun*
08:06<@planetmaker>frosch123: in NML it doesn't matter... you put CB there in the graphics block, too
08:06<frosch123>the callback would also allow checking cargo classes in more detail, instead of only OR, and NOT AND
08:06<@peter1138>andythenorth, yea but nobody uses cargo types in action 3 any more
08:06<andythenorth>and the action 3 is pretty easy to understand when first starting coding
08:06<andythenorth>peter1138: for some definition of 'nobody'
08:06<Eddi|zuHause>maybe action 3 needs a special "callback-cargo", like 0xFF for purchase list
08:06<frosch123>peter1138: who was against the callback?
08:07<frosch123>Eddi|zuHause: why make it more complicated?
08:07-!-Fuco [] has quit [Ping timeout: 480 seconds]
08:07<@Yexo><andythenorth> refittable to x before 1900, to y after 1900 <- that won't work even with the callback. You'd need to save your game and reload it after 1900 to make it work, and even than it'd fail in MP
08:07<andythenorth>Yexo: won't work? What about newly built vehicles?
08:08<@Yexo>the refit cb would be called on the vehicle type when the game starts, not when a vehicle is built
08:08<frosch123>the callback is not called for every vehicle
08:08<@peter1138>frosch123, you
08:08<V453000>o_O wagons changing refittability with time? why
08:08<andythenorth>oh ok
08:08<frosch123>that will cause too many trouble with autorenew/replace
08:08<frosch123>calling it yearly might be possible
08:08<andythenorth>possible != wise :P
08:09<Eddi|zuHause>that may horribly break autorefit-cargodest-networks :p
08:09<frosch123>peter1138: yes, that is "callback when vehicle is built"
08:09<frosch123> <- that is "callback on gamestart"
08:09<andythenorth>I liked the action 3 because it puts refittability and cargo graphics in one place. That's a win for me. Guess not for others :(
08:09<@peter1138>Eddi|zuHause, 0xFF is default rather than purchase list, and tbh i thought it was used for callbacks, but no, cargo specific chains are used for callbacks too
08:10<frosch123>andythenorth: do you really add n cases to branch callbacks?
08:10<@peter1138>callback on gamestart?
08:10<@peter1138>that's... unorthadox
08:10<andythenorth>frosch123: let me check...
08:10<+michi_cc>Add a special cargo 0xFE for callbacks use if the Act3 has it, otherwise do the callbacks as before.
08:11<frosch123>stations already have special FE
08:11<+michi_cc>Then FD or whatever :)
08:11<@peter1138>separate features, won't conflict afaik
08:12<frosch123>andythenorth: fish does not do that
08:12<frosch123>and you will have a lot of fun doing so.
08:12<@peter1138>Eddi|zuHause, hmm, 0xFF is listed as CT_PURCHASE, never mind :)
08:12<Eddi|zuHause>peter1138: but "FD for stations, FE for all others" is not quite sensible either
08:12<@peter1138>Eddi|zuHause, can you refit stations?
08:12<@peter1138>no but there are callbacks
08:13<Eddi|zuHause>peter1138: stations have callbacks as well
08:13<andythenorth>frosch123: fish is a bad case, it only uses class based refits iirc
08:13<frosch123>so, which chain shall rerandomisation pick?
08:13<frosch123>the callback chain or the graphics chain? :p
08:13<andythenorth>most of my cases are bad :P
08:13<@peter1138>i don't think it should be done
08:14<+michi_cc>I'd have said callback unless rerandomisation somehow depends on the cargo type.
08:14<@peter1138>i'd rather just we just added 2 new properties
08:14<@peter1138>variable length, a list of indices into the CTT
08:14<Eddi|zuHause>a list of labels
08:14<@peter1138>or that
08:14<+michi_cc>peter1138: The callback cargo type makes sense regardless of any refit stuff to remove the explicit branching for callbacks.
08:14<@peter1138>to be applied after the existing refit stuff is done
08:15<@Yexo>list of indices in CTT is more consistent than a list of labels
08:15<frosch123>michi_cc: it would break a lot
08:15<frosch123>e.g. rerandomisation in callbakcs
08:15<frosch123>and likely some callback are also cargotype specific
08:15<@Yexo>personally I'm in favor of a cb, since not only can it easily implement to explicit include/exclude lists but it has also more freedom what to do with the cargoclasses for unknown cargoes
08:15<andythenorth>even if run once, a cb could do insane crap like 'disable refit if grf x exists'
08:15<+michi_cc>I never really understood randomisation ;)
08:16<@Yexo>andythenorth: you can do that even without a callback
08:16<andythenorth>are classes & labels being put back together again? :(
08:16<andythenorth>labels need to be yes/no imho, not conditional on 'how this author was feeling about it'
08:16<frosch123>so, we can add a two properties with a list of ctt indices or labels; we can add a callback; or we can do both
08:17<frosch123>the action3 thingie does sound useful at all to me
08:17<andythenorth>labels also need to explicitly exclude known cargos from a vehicle
08:17<andythenorth>what are the advantages of a cb that returns *labels* ?
08:17<andythenorth>(classes might justify a cb)
08:18<@Yexo>andythenorth: the callback won't return labels
08:18<andythenorth>it will return yes/ no...
08:18<@Yexo>the cb gets a index in the CTT (or FF if it isn't in there) and the classes (mostly useful when index is FF) and return yes or no
08:18<@peter1138>frosch123, missing not?
08:18*andythenorth does ponder
08:18<frosch123>the cb would be asked for every existing cargo, and can then decide on label, classes, specific weight or whatever whether the vehicle would be reifttable
08:18<frosch123>peter1138: yeah :s
08:19<andythenorth>so it could include FIRS milk, but exclude ECS milk
08:19<andythenorth>oh joy :(
08:19<@Yexo>andythenorth: again, you could already do that
08:19<andythenorth>yup true
08:19<andythenorth>we have proof of that - except it never shipped :P
08:20<andythenorth>the cb is going to be the best route isn't it - we always end up on a cb
08:21<frosch123>we can also go for the list of labels/ctt indices in two act0 props
08:21<andythenorth>what's the second prop for?
08:21<@Yexo>one for explicit include, one list for explicit exclude
08:21<frosch123>rest via classes
08:21<andythenorth>what fails about exclude anything that's not in the CTT?
08:21<@Yexo>just apply after the current properties
08:21<andythenorth>that was nonsense
08:22<andythenorth>what fails about excluding cargos that are in the CTT, but not in the list of included labels?
08:22<frosch123>you mean exclude everything in ctt, whcih is not in the prop?
08:22<frosch123>then we would have to go for "indices" instead of "labels"
08:22<andythenorth>two props allows for lazy authoring
08:23<@Yexo>whatever the strategy (props or cb) I'd be in favor of using indices over labels anyway
08:23<andythenorth>which is an advantage to many
08:23<andythenorth>indices makes complete sense
08:23<andythenorth>it's way more upgradeable for starters
08:23<andythenorth>if some idiot changes SCRP to SCMT, it's one change :P
08:23<@Yexo>actually no, it'd be an addition of a new label to support both the old and the new label
08:23<frosch123>using a single prop + ctt might be more robust; then you cannot skip cargos from the ctt, which you think are fine due to their classes
08:24<@planetmaker>Yexo: ctt indices?
08:24<@planetmaker>that'd be more than uint32
08:24<@Yexo>index in cargo translation table
08:24<@Yexo>planetmaker: we're talking about a new property that is a list of those indices
08:24<andythenorth>frosch123: I think the 'lazy' class-based route for exclusions is bad
08:24<andythenorth>can't explain why
08:24<@Yexo>it would be a byte <len> followed by <len> bytes that are indices
08:25<@Yexo>or something similar to that
08:25<andythenorth>labels are either explicit or not, excluding cargos you know about should be on the basis of labels, not implicit
08:25<@planetmaker>ah, so one byte per CTT entry?
08:25<Celestar>why is HP UX such a total and utter piece of crap?!
08:25<@planetmaker>sounds good
08:25<andythenorth>this makes complete sense
08:25<@peter1138>you could make it a big bitmask
08:25<andythenorth>although /me might do something evil with CPP :P
08:25<frosch123>Celestar: every non-free *nix is
08:26<@peter1138>how big can the CTT be?
08:26<andythenorth>if you don't make it a bitmask, I can do evil things with CPP :P
08:26<@planetmaker>peter1138: not really. You don't know the size of the CTT
08:26<@planetmaker>and it can be arbitrarily long
08:26<frosch123>a list of indicies is easier, since it fits the current usage of #define
08:26<andythenorth>#define COAL = 01, which will produce "COAL" :P
08:26<andythenorth>bitmask doesn't allow that ^
08:26<@Yexo>it can be arbitrary long, but a CTT with a length over 253 items might lead to problems
08:26<Celestar>frosch123: but this is especially stupid
08:27<frosch123>Celestar: rule of thumb: prefix every command with a "g"
08:27<Celestar>frosch123: you cannot read a timestamp with strftime() that you have just created with strptime() using the same format string.
08:27<frosch123>Celestar: sed -> gsed, grep -> ggrep, awk -> gawk, ...
08:27<@peter1138>probably not useful as a bitmask anyway
08:28<@Yexo>a bitmask is possible, that's what george asked for in one of those topics
08:28<andythenorth>with defines, when some idiot changes "SCRP" to "SCRM" I just do f+r on my defines, or use a mapping :P
08:28<@Yexo>however it's very hard to read / write
08:28<Eddi|zuHause>i find indices unweildy... but maybe nml can shield that from me...
08:28<andythenorth>nml could ship as a favour constants for all known cargos :P
08:28<andythenorth>cargo_COAL etc
08:28<@Yexo>Eddi|zuHause: every label in a CTT is from then on defined as a named with as value the index in the CTT
08:29<@peter1138>andythenorth, why bother when the constant its representing is "COAL" ?
08:29<andythenorth>peter1138: because I'm not a very good programmer?
08:29<Celestar>frosch123: well I have compiled binaries for almost everything :P
08:29<Eddi|zuHause>Yexo: hm, ok, then indices might make implementation in nml easier
08:29<Celestar>frosch123: awk, grep, sed, gcc, vim, find ...
08:29<Celestar>frosch123: because out of the box, HPUX is totally unusable
08:30<Celestar>frosch123: and ksh just sucks donkey balls and then some
08:30<@Yexo>when you're writing nml code it doesn't matter, Either you write COAL (=cargotype("COAL")) or you write "COAL"
08:30<Eddi|zuHause>andythenorth: in nml, all CTT entries automatically become constants
08:30<andythenorth>this route has much in its favour
08:31<andythenorth>I'd better remove the action 3 patch :P
08:31<@planetmaker>so two new properties?
08:32<andythenorth>depends on whether you think lazily relying on classes is wise or not
08:32<@Yexo>or one, with everything not in the first means exclude automatically
08:32*andythenorth prefers one
08:32<andythenorth>otherwise we make it possible to keep doing the 'class-label' shuffle
08:32<@peter1138>just one is fine
08:33<frosch123>Celestar: imagine you are on solaris, and the admin thinks "csh" is a better default than "tcsh"
08:33<Celestar>frosch123: been there, done that. thanks :P
08:33<@peter1138>users can't choose a shell?
08:33<Celestar>frosch123: at least I managed to get a working bash 4 on HPUX :P
08:33*andythenorth can write a define for 'BULK_cargos = COAL IORE BAUX' etc
08:33<Celestar>peter1138: sometimes "chsh" isn't working :P
08:34<andythenorth>then set the prop to 'BULK_cargos' ...
08:34<Celestar>peter1138: and some idiots ONLY install the default shell :P
08:34<frosch123>peter1138: yes, but you have to it on every machine, since they are decoupled from each other with no network home dir, for security reasons
08:34<Celestar>frosch123: oh yeah.
08:34<TrueBrain>Celestar: just copy a shell yourself ;)
08:34<Celestar>frosch123: and I had a nice bug in the HPUX LDAP client last week.
08:35<Celestar>frosch123: it gave me root rights for some reason :P
08:35<@planetmaker>one property might be nicer, if "not in there but in ctt means exclusion"
08:35<@planetmaker>o_O @ Celestar
08:35<frosch123>planetmaker: one property is better since it is not possible to say "i do not need to add this cargo to the property, as the cargoclasses will already add it"
08:35-!-Kurimus [] has joined #openttd
08:35<@peter1138>yeah, working on the assumption that if it's in the CTT then the author knows about it, and didn't explicitly chose it
08:35<andythenorth>planetmaker: I like that it keeps a clean set of 'known'
08:36<@peter1138>also means you can't do silly things like including and excluding the same thing :p
08:37<@peter1138>so basically it's the action 3 thing but done with an explicit property
08:37<andythenorth>if we don't do it this way, we just keep the XOR problem
08:37<andythenorth>two props just maintains the XOR problem against classes
08:37<andythenorth>"I want bulk but not foo"
08:37<andythenorth>so instead of putting all bulk cargos into 'include' I rely on bulk, then use the exclude for some known cargos
08:38<andythenorth>then if a class ever needs to change, the world ends
08:38<@planetmaker>That property has the adv. it also works in grf v7
08:38<andythenorth>and it's like the last 5 days didn't happen :(
08:38<andythenorth>so one prop :)
08:38<@planetmaker>and overrides the existing 3 properties
08:38<@planetmaker>hm. or rather the xor part
08:38<@planetmaker>or maybe not even that
08:40<@planetmaker>frosch123: I like your suggestion wrt introduction dates
08:41<Eddi|zuHause>i'm fairly sure DaleStan is breaking some rule about backseat-moderation
08:41<frosch123>planetmaker: setting the new property disables the xor property. the class properties remain unaffected
08:43<Eddi|zuHause>peter1138: shouting "this is off topic" instead of clicking on the report button and requesting to split things
08:43<@peter1138>well, he always wanted to be a moderator, heh
08:43<andythenorth>bring back dalestan!
08:44<andythenorth>a dalebot would be nice
08:44<andythenorth>he taught me a good amount of nfo
08:46*andythenorth volunteers to test any patch :)
08:46<andythenorth>relating to a new refit prop
08:50<@peter1138>of course, it means duplicating it
08:50<@peter1138>cos it needs to be done for all vehicle types :(
08:51<Eddi|zuHause>someone thought it useful to have same properties with different IDs for each vehicle type
08:51<Eddi|zuHause>unifying is for pussies
08:52<@Yexo>we could add it as prop 2C for all vehicle types
08:52<andythenorth>it's fun to visit the wiki first every time I have a question
08:52<andythenorth>we can't just reliably refer to prop IDs
08:53<andythenorth>maybe that's the point :P
08:53<andythenorth>enforces wiki visiting
08:53<@Yexo>you can refer to a prop ID as long as you meantion for which feature
08:53<andythenorth>all that wear on tear on the keys for (trains) (RVs) (ships) :P
08:54<andythenorth>on / and /s
08:54<andythenorth>Eddi|zuHause: so...which extra classes do you want for piece goods? :P
08:54<andythenorth>totally unrelated to labels :)
08:55<Eddi|zuHause>i'm currently getting unsure about "lightweight" (formerly "express")
08:55<andythenorth>refrigerated, armoured, oversized ?
08:55<andythenorth>leave it as express
08:55<@peter1138>i could add it to CommonVehicleChangeInfo :p
08:56<@peter1138>now, how long can the list me?
08:56<Eddi|zuHause>up to 256?
08:57<andythenorth>Eddi|zuHause: assuming we did something like two props for classes (or some other whatever imeplentation) - so core_class AND requires_classes
08:57<andythenorth>are the requires_classes AND or OR ?
08:57<frosch123>peter1138: extended byte?
08:57<Eddi|zuHause>andythenorth: currently the extended classes are AND NOT
08:57<andythenorth>exclude is a bit insane tbh
08:57<andythenorth>for classes
08:58<Eddi|zuHause>andythenorth: that's unlikely to change, however
08:58<andythenorth>how do you exclude classes you don't know about yet?
08:58<@peter1138>frosch123, why not just a word? eb was for backwards compatibility
08:58<frosch123>the advance of all newer classes being "AND NOT" is, that they keep compatibility with old vehicle sets
08:58<Eddi|zuHause>andythenorth: you don't exclude the unknown classes
08:58<andythenorth>Eddi|zuHause: how do you do backwards compatibility whilst enforcing that 'powders' are only valid for 'bulk' ?
08:59<andythenorth>you need to be branching boolean logic according to core classe
08:59<frosch123>peter1138: to obfuscate the obvious question "will we get more than 256 entries per ctt" :p
08:59<Eddi|zuHause>andythenorth: i don't hence introducing new labels for existing cargos. old cargo sets will produce "strange" results.
08:59<frosch123>but, word is also fnie
08:59<@peter1138>frosch123, not possible
08:59<@peter1138>CTT indices are 8 bit only
09:00<andythenorth>Eddi|zuHause: I quite like your proposal for core + extra classes specific to the core cargo. But only if it's enforced
09:00<frosch123>well, then you do not need a word, and a byte is sufficient
09:00<andythenorth>if that can't be done, we maybe just declare classes messy, remove some, celebrate the removal of XOR and do something else :P
09:01<frosch123>it can become an extended byte in grf v10, when we extent ctt to 65536 labels :p
09:01<andythenorth>Eddi|zuHause: how about cb, rely on the author to do the right thing, add a special flag for using the cb instead of props 28/29 (trains)
09:02<Eddi|zuHause>4294967296 entries per CTT!!
09:02<andythenorth>Eddi|zuHause then rework classes on existing labels, with 6 months of crap about it on the forums
09:02<@peter1138>Eddi|zuHause, that wouldn't need a CTT ;)
09:03<andythenorth>with a cb, you could branch on bulk class or whatever, providing the class specific support you're advocating
09:03<Eddi|zuHause>andythenorth: we don't need flags for CBs. if a CB is not used, it will fail, and automatically fall back to the old system
09:04<andythenorth>detail :)
09:04<andythenorth>does it solve your problem
09:04<Eddi|zuHause>andythenorth: no. a cb does not solve anything regarding to classes
09:04<andythenorth>because you want to rework classes on current labels?
09:05<@peter1138>the flags for CBs is because it's quicker to test a flag than to call a CB and find it fails
09:05<Eddi|zuHause>andythenorth: we'll forever have to pass "old style classes" and "new style classes" to each "cargo type/class" variable
09:05<andythenorth>Eddi|zuHause: so classes aren't solvable ;)
09:05<andythenorth>so delete some, move on?
09:06<Eddi|zuHause>andythenorth: classes can't be deleted
09:06<frosch123>can we delete neo-.bulk and clean for now?
09:06<frosch123>it might simplify the discussion
09:06<andythenorth>and hazardous seems to be safer
09:06<@peter1138>delete the ones added the other day, certainly
09:06<andythenorth>nobody has defended hazardous, and enough useful people have posted in the thread
09:06<Eddi|zuHause>frosch123: i think so, yes. and hazardous is fairly unanimous to remove as well
09:06<frosch123>it is used by existing vehicle grfs
09:07<Eddi|zuHause>eGRVTS is broken anyway
09:07<andythenorth>can we delete it if we ask Zeph?
09:07<Eddi|zuHause>misinterprets the "express" cargo
09:08<andythenorth>can we mark it as 'deprecated but used'
09:08<Eddi|zuHause>sure, but it will forever block a bit in the bitmask
09:09<@peter1138>are 9 & 10 used?
09:09<andythenorth>10 is apparently 'requires pressure discharge'
09:10<Eddi|zuHause>10 is disputed, and 9 is fairly useless in the current state
09:10<andythenorth>sorry 11 is pressure discharge
09:10-!-Progman [] has joined #openttd
09:10<andythenorth>according to MB
09:10<@peter1138>but as it's OR not AND...
09:11<andythenorth>10 is stupid
09:11<andythenorth>but that's not a reason to remove it without a better consensus I guess
09:11<andythenorth>hazardous should be deprecated
09:11<andythenorth>it's meaningless
09:12-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
09:12<frosch123>it will be handy for new disasters
09:12<andythenorth>add it to your misc flag along with clean :P
09:12<andythenorth>it's not a refit class
09:13<andythenorth>so I add a nuclear materials carrier, setting hazardous for it
09:13<andythenorth>then someone adds a TNT cargo
09:13<andythenorth>or fire cargo
09:13<andythenorth>fire is hazardous :P
09:13*andythenorth ponders adding 'fire' to FIRS :P
09:16<andythenorth>Class Translation Table? :P
09:17<@peter1138>cargo class labels...
09:18<andythenorth>labels composing classes ?
09:18<andythenorth>DRYBULK = Bulk AND Sheltered
09:21<@peter1138>you are
09:23<andythenorth>Eddi|zuHause: wrt to your table here:
09:24<andythenorth>can we rewrite as a simple list of {core class: [extra class, extra class] }
09:24<Eddi|zuHause>yes, but it won't be sorted by bits then
09:24<andythenorth>backwards compatibility is a headache anyway
09:24<andythenorth>I just want to see how it works
09:25<andythenorth>could we dump current pax / mail / express class into one?
09:25<andythenorth>for this purpose?
09:25<Eddi|zuHause>pax is special
09:25<Eddi|zuHause>mail is special
09:25<Eddi|zuHause>express is weird
09:26<andythenorth>is express a core class? historically yes
09:26<andythenorth>probably shouldn't be
09:26<andythenorth>{ bulk : [sheltered, pourable, ?? ] }
09:28<Eddi|zuHause>short version: there are 5 basic classes: [pax, mail, countable (piece), uncountable (bulk), liquid]
09:30<Eddi|zuHause>countable has these specific flags: "lightweight" (probably should go), "refrigerated" and "oversized" (needs flat/stake wagon or roof access)
09:31<Eddi|zuHause>uncountable has these specific flags: "not pourable" and "powderized"
09:34<Eddi|zuHause>pax, mail and liquid have no specific flags
09:34<andythenorth>actually -1
09:34<andythenorth>why 'not pourable' ?
09:34<andythenorth>but powderised
09:34<andythenorth>AND NOT or AND?
09:35<Eddi|zuHause>possibly redefine as "not powderized"
09:35<Eddi|zuHause>but that needs adding this flag to all existing bulk cargos
09:35<Eddi|zuHause>which is probably a bad idea
09:36<andythenorth>treat this as clean sheet to see if it's valid
09:36<andythenorth>in an idealised system, it's much easier to say what a vehicle supports than what it doesn't
09:36<andythenorth>what does liquid get?
09:37<Eddi|zuHause>assume refrigeration is part of the refitting process for liquid cargos...
09:37<Eddi|zuHause>i have never heard of refrigerated tank wagons
09:38<andythenorth>concept empiricism :P
09:38<Eddi|zuHause>andythenorth: to say a wagon loads powderized bulk cargo, you add "powderized" to the OR mask, and leave the AND NOT mask empty
09:39<andythenorth>and then your open hoppers set powderised
09:39<andythenorth>for the AND NOT mask
09:39<Eddi|zuHause>yes. hoppers set "bulk" in the OR mask, and "powderized" in the AND NOT mask
09:40<andythenorth>this is the idealised way? or the 'has a chance of backwards compatibility' way?
09:40<Eddi|zuHause>hoppers also set "not pourable" in the AND NOT mask
09:41<Eddi|zuHause>that system works either way. just when we don't change the existing cargos, lots of exceptions have to be made, and the next person writing a vehicle set will get it wrong again
09:42-!-Adambean [] has joined #openttd
09:42<andythenorth>and this system can't prevent exclusion collisions when many classes are set
09:43<andythenorth>and it's still valid within the spec to set piece goods and powderised
09:43<andythenorth>whereas you'd prefer having to set both bulk and powderised
09:43<Eddi|zuHause>yes. it requires some discipline when coding a cargo set
09:44<Eddi|zuHause>but at least the specs would be clear enough to point fingers "this is wrong"
09:44<Eddi|zuHause>it's not open for interpretation anymore
09:45<andythenorth>Eddi|zuHause: if there was a way to implement this?
09:45<andythenorth>new props?
09:46<andythenorth>one prop
09:46<andythenorth>dword sized
09:47<andythenorth>e.g. first byte is bulk, set first nibble for 'enable bulk' second nibble as mask for the extra classes
09:47<andythenorth>other nibbles for liquid, passengers, mail
09:47<andythenorth>one byte for piece goods
09:48-!-SpBot_ [] has joined #openttd
09:48<Eddi|zuHause>i don't think that is a good route to take
09:48<andythenorth>one nibble free (assuming I can count)
09:48<andythenorth>probably not :)
09:48-!-SpBot [] has quit [Read error: Connection reset by peer]
09:50<Eddi|zuHause>which cargos are measured in "crates" currently?
09:51<andythenorth>I'd have to look :|
09:51<andythenorth>in FIRS code
09:51<andythenorth>what's your idea?
09:51<Eddi|zuHause>if we take "abstract" wagons: one closed wagon, and one long closed wagon
09:52<Eddi|zuHause>we could define the closed wagon as "1 crate for each 1t capacity", and the long closed wagon as "n crates for each 1t capacity", where n is defined by the weight of one crate
09:52<Eddi|zuHause>to handle volume vs weight
09:53<Eddi|zuHause>i.e. with 2 crates = 1t, and 15t capacity, the normal closed wagon has 15 crates capacity, and the long closed wagon 30 crates
09:53<Eddi|zuHause>but if refit to a cargo measured in t, both have 15t capacity
09:53<andythenorth>isn't that just a cb 36 thing?
09:54<Eddi|zuHause>the question is, whether we need a special class for that
09:54<andythenorth>I had the idea that countable always = crates, uncountable = t, liquid = l
09:54<andythenorth>tying unit to core class fails when more than one core class is valid
09:54<Eddi|zuHause>andythenorth: yes "crate" = "volume units"
09:55<Eddi|zuHause>no, "express/lightweight" is a specific flag
09:55<Eddi|zuHause>the core class is piece goods
09:56<Eddi|zuHause>but we could use weight per unit property for that stuff
09:56<Eddi|zuHause>so it doesn't necessarily need a cargo class
09:56<andythenorth>Eddi|zuHause: move 'express' to a misc flag?
09:57<andythenorth>it's not an intrinsic property, it's a hint to certain kinds of vehicles
09:57<Eddi|zuHause>i'm inclined to remove "express" completely
09:57<andythenorth>you don't author planesets :P
09:57<Eddi|zuHause>or redefine it to "airfreight"
09:58*andythenorth -> going out
09:58<Eddi|zuHause>then it should become a core class
09:58<andythenorth>I think express remains as a core class
09:58<Eddi|zuHause>i should do that as well
09:58<andythenorth>it's been poked at from every angle, it won't die
09:58<Eddi|zuHause>but it's pure milk outside
09:58-!-andythenorth [] has quit [Quit: andythenorth]
10:04-!-TGYoshi [~TGYoshi@] has joined #openttd
10:14-!-DayDreamer [] has joined #openttd
10:17-!-Celestar [] has quit [Ping timeout: 480 seconds]
11:00<@peter1138>neobulk & clean are still there ;p
11:00-!-Brianetta [] has quit [Quit: Tschüß]
11:01<frosch123>are they?
11:04<@peter1138>in the specs, heh
11:04<@peter1138>also, i started writing a long time ago
11:04<@peter1138>(no, never tested, no, it most likely doesn't work right)
11:05<frosch123>it will likely desync on autoreplace/renew
11:05<@peter1138>i'm sure i never put it anywhere cos it's totally unfinished and won't work
11:05<@peter1138>but it was long ago
11:05<frosch123>@calc 65536*16*4
11:05<@DorpsGek>frosch123: 4194304
11:06<frosch123>who cares :p
11:06<frosch123>though 64k is no longer the vehicle limit
11:06<frosch123>hmm, i think psa gained id lately
11:06<@peter1138>i can't remember what it was for. i think pikka wanted it
11:08<@peter1138>i was looking at a history of the specs :p
11:15-!-Biolunar [] has joined #openttd
11:24-!-glx [glx@2a01:e35:2f59:c7c0:8d3e:d0f1:5421:870a] has joined #openttd
11:24-!-mode/#openttd [+v glx] by ChanServ
11:30-!-supermop [] has joined #openttd
11:38<CIA-6>OpenTTD: frosch * r23173 /trunk/src/ (9 files): -Codechange: Rename GetVehicleCapacity() to Engine::DetermineCapacity().
11:39<CIA-6>OpenTTD: frosch * r23174 /trunk/src/ (engine.cpp newgrf_engine.cpp newgrf_engine.h): -Codechange: Deduplicate code between GetEngineProperty() and GetVehicleProperty().
11:40<CIA-6>OpenTTD: frosch * r23175 /trunk/src/engine.cpp: -Codechange: Refactor Engine::DetermineCapacity().
11:41<CIA-6>OpenTTD: frosch * r23176 /trunk/src/ (engine.cpp engine_base.h): -Codechange: Deduplicate code between Engine::DetermineCapacity() and Engine::GetDisplayDefaultCapacity().
11:50-!-supermop [] has quit [Quit: supermop]
11:53-!-Prof_Frink [] has joined #openttd
12:11-!-Brianetta [] has joined #openttd
12:11-!-HerzogDeXtEr [] has joined #openttd
12:14-!-sla_ro|master [~slaco@] has joined #openttd
12:18-!-Neon [] has joined #openttd
12:22-!-andythenorth [] has joined #openttd
12:25-!-Zuu [] has joined #openttd
12:32<andythenorth>Eddi|zuHause: name a class explicitly in the spec? Bulk-sheltered ?
12:32<andythenorth>wiki only, but it's a cluestick
12:34-!-mahmoud [] has joined #openttd
12:36-!-Fuco [] has joined #openttd
12:40-!-DOUK [] has quit [Ping timeout: 480 seconds]
12:43-!-valhallasw [~valhallas@] has joined #openttd
12:52-!-KOPOBA [~xren@] has joined #openttd
12:54<KOPOBA>is there any way to get know why server drops me when i want to connect to it? i see dowloading of map bar and then suddenly all close and i see main menu?
12:55<KOPOBA>i try to connect serveral times 3-5 and finnaly connect
13:08<@planetmaker>too slow connection?
13:11<KOPOBA>it takes 2-4 seconds to download 1 megabite map
13:11<Eddi|zuHause>andythenorth: what do you mean?
13:11<@Terkhen>unstable connection
13:12<KOPOBA>there is no any logs or somthing?
13:12<KOPOBA>to be sure why it happens
13:14<andythenorth>Eddi|zuHause: when describing the class, don't call it "Sheltered" or whatever, call it "Bulk-sheltered"
13:14<andythenorth>it's a sticking plaster, not a fix
13:20<andythenorth>did we figure out if any sets are using oversized?
13:20<andythenorth>and if it's ok to deprecate hazardous (despite eGRVTS use)
13:21<Eddi|zuHause>ECS defines GLAS and VEHI as oversized
13:21<Eddi|zuHause>and i'd really like if WOOD and STEL were oversized as well
13:21<frosch123>is that only written on the wiki, or does george set them?
13:22<Eddi|zuHause>don't know
13:22<andythenorth>Eddi|zuHause: you don't mind that STEL might stop getting transported by van?
13:22<Eddi|zuHause>who the hell transports STEL by van?
13:23-!-LordAro [] has joined #openttd
13:23<frosch123>anyway, it is likely not ok to deprecate any class, including hazardous
13:23<frosch123>covered and oversized can be likely slightly redefined to mean similar things
13:24<andythenorth>those sound fine, but hazardous should go, it's a dumb idea :P
13:24<frosch123>express is also bad, but both have been there for years, and are used everywhere
13:24<andythenorth>Eddi|zuHause: what about when steel needs covering IRL? Same rule as all piece goods - assume the vehicle or the packaging can provide the cover
13:24<andythenorth>frosch123: I think we keep express
13:25<andythenorth>it's widely used and removing it just makes life hard for plane set authors
13:25<andythenorth>(mostly Pikka probably)
13:25<Eddi|zuHause>andythenorth: steel doesn't really need covering
13:25<frosch123>and with "express" meaning "can be transported in ttd-style maglev" it actually makes sense, just that noone knew that definition, and thus it is not used as such
13:25<andythenorth>Eddi|zuHause: coil gondolas :)
13:25<andythenorth>but yes
13:25<andythenorth>+1 to steel does not need covering
13:25<KOPOBA>what values i can use for debug_level?
13:26<Eddi|zuHause>frosch123: i propose renaming "express" to "air freight"
13:26<frosch123>0 to 9
13:26<Eddi|zuHause>frosch123: with a suggestion that wagons should never exclude it
13:27<andythenorth>priority freight?
13:27<Eddi|zuHause>no, that's as ambiguous as "freight"
13:29<andythenorth>one purpose of hazmat might have been to exclude from planes?
13:30<andythenorth>express appears to be a RL freight catgeory
13:31<andythenorth>strictly a category of cargo; freight is another category of cargo
13:32-!-Elukka [] has joined #openttd
13:35<andythenorth>express doesn't trouble me
13:35<andythenorth>can we leave it be?
13:35<andythenorth>maybe expand the description?
13:35-!-Wolf01 [] has joined #openttd
13:37<__ln___>Wolf01: congratulations
13:39-!-|Jeroen| [] has joined #openttd
13:40<LordAro>__ln___: huh?
13:43<andythenorth>Eddi|zuHause: how would you feel about a column for classes indicating 'usual units' ?
13:43<andythenorth>overkill? or useful?
13:43<andythenorth>when coding FIRS I didn't think about it enough - some errors in that respect got fixed recently
13:43<Eddi|zuHause>andythenorth: the units may vary between industry sets
13:43<andythenorth>hence 'usual'
13:43<Eddi|zuHause>andythenorth: keep that in mind for later
13:44-!-pjpe [] has joined #openttd
13:44<andythenorth>I'm wrong actually. For a cargo with two core classes, there's no 'correct' unit anyway
13:44<andythenorth>although the usual unit is a nice guide to what the classes might be
13:45<andythenorth>if you usually measure it in litres, it's probably first and foremost liquid
13:45<CIA-6>OpenTTD: translators * r23177 /trunk/src/lang/ (8 files in 2 dirs): (log message trimmed)
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: belarusian - 21 changes by Wowanxm
13:45<CIA-6>OpenTTD: dutch - 14 changes by habell
13:45<CIA-6>OpenTTD: english_US - 2 changes by Rubidium
13:45<CIA-6>OpenTTD: italian - 2 changes by lorenzodv
13:45<CIA-6>OpenTTD: romanian - 6 changes by kkmic
13:45<andythenorth>if it's tonnes, it's likely uncountable and therefore bulk
13:45<andythenorth>if it's countable units, choose piece
13:47-!-Brianetta [] has quit [Quit: Tschüß]
13:48<andythenorth>Eddi|zuHause: do you like drawing flow charts? :)
13:48*andythenorth ponders drawing a flow chart using OTTD
13:49<@Belugas>i hate flow charts
13:49<@Belugas>i dream of flow charts
13:50<@Belugas>i'd rather be watching cash flow
13:50*andythenorth watches cash flow
13:56<z-MaTRiX>PolyTetraFluoroEthylene rulz :)
13:59-!-|Jeroen| [] has quit [Quit: oO]
14:00-!-pugi [] has joined #openttd
14:09<andythenorth>Eddi|zuHause: frosch123 what's best description of 'oversized' so far? Something like needs flat vehicle, stake vehicle, open vehicle, or vehicle with very large doors or opening roof?
14:09<andythenorth>for countable cargo only
14:10<Eddi|zuHause>i have put "stake/flatbed wagon" now
14:11-!-JVassie [~James@] has joined #openttd
14:11<andythenorth>where? :) I am writing a forum post
14:17-!-ctibor [~ctibor@] has joined #openttd
14:18<__ln___>i was at least partially right, WolframAlpha doesn't want to understand Mathematica syntax when the variable names are not appropriate:
14:20-!-George [~George@] has quit [Read error: Connection reset by peer]
14:21<ctibor>I think I have found a bug in OpenTTD. Suppose you have engine A. Define engine B as a replacement. A goes to the depot, but financial limit is not available. After that engine B becomes unavailable. You define engine C as a replacement for A. A goes to the depot and tries to replace itself with B (there is message that replacement engine is not available). So Openttd somehow remembers what the engine tried to replace itself with and this doesn't change even
14:21<ctibor>after redifining the replacement list. Is it a bug or feature? Should I file it to the bugzilla?
14:26<Eddi|zuHause>andythenorth: in my WIP spec proposal
14:27<frosch123>ctibor: are you sure the news item was recent
14:27<frosch123>or was it maybe that old that it was from before you switched the replacement from B to C
14:27-!-George [~George@] has joined #openttd
14:28<Eddi|zuHause>hm... now FISH is marked as "air freight", that's clearly not intended :)
14:29<frosch123>why not?
14:30<ctibor>frosch123: I have only few trains, I can even see that train coming from depot
14:31<frosch123>maybe you have different replacement rules for groups and all trains
14:34<appe>can anyone make me a bus grf with jeremy clarksons head popping out of the window?
14:35<ctibor>I don't have any groups defined
14:35<ctibor>frosch123 ^
14:35<Prof_Frink>Never mind that, make a Train GTi grf.
14:37<ctibor>frosch123: I have even seen a train, that was replaced with the engine, I have defined previously and the changed it to another one, while the other conditions I describe happened.
14:38<frosch123>well, seems like a case "without savegame we cannot say anything"
14:40<Eddi|zuHause>ctibor: even without groups, you have the "ungrouped" and "all" groups
14:40-!-TheMask96- [] has quit [Ping timeout: 480 seconds]
14:41<ctibor>Eddi|zuHause: ah, you have i point, i checked and it is definitely the case
14:41<ctibor>sorry for waisting your ticks on this :-)
14:42<andythenorth>Eddi|zuHause: what's non-pourable bulk for now?
14:42<andythenorth>stuff like scrap metal that can't be hopper discharged?
14:42<Eddi|zuHause>i'm thinking scrap metal, clay, sugar beet
14:43<Eddi|zuHause>oil seeds, and possibly waste
14:44<Eddi|zuHause>and fibre crops
14:44<Rubidium>mamgnets ;)
14:44<frosch123>cotton candy
14:44-!-andythenorth is now known as Guest16500
14:44-!-andythenorth [] has joined #openttd
14:45-!-TheMask96 [] has joined #openttd
14:45-!-Guest16500 [] has quit [Read error: Connection reset by peer]
14:45<andythenorth>sugar cane
14:46-!-KritiK [] has joined #openttd
14:46<Rubidium>dry ice?
14:49<andythenorth>how odd
14:49<andythenorth>I just posted a forum post that seemed to remove at least one post by george or MB
14:50<andythenorth>I see what happened
14:50<@Terkhen>you can delete your post as long as it is the last one IIRC
14:50<@Terkhen>so it was probably removed just before you posted
14:52<andythenorth>it was just a double post by me when connection dropped, I misread it
14:55<KOPOBA>is there any way to remove city from main screen?
14:56<Eddi|zuHause>no, cities cannot be removed
14:56<Eddi|zuHause>(not sure i understand the question)
14:56<KOPOBA>when i start openttd i see menu and city on background
14:57<Wolf01>just save a game where you want and rename the save to title.dat
14:58<Wolf01>you'll see the place where you saved, but don't use a big game or OTTD will take ages to open
14:58<Wolf01>*big map
14:59<KOPOBA>openttd will work properly if i save empty file and name it title.dat?
14:59<Wolf01>yes, title.dat is just a savegame
15:00<Wolf01>you can generate a flat land in scenario editor and use that one
15:01<Rubidium>just remove the file ;)
15:01-!-rhaeder [] has quit [Quit: Leaving.]
15:01<Eddi|zuHause>just delete opntitle.dat
15:02<Wolf01>doesn't it generates the sea?
15:03<KOPOBA>says cant open file
15:03<KOPOBA>but this is ok
15:04-!-rhaeder [] has joined #openttd
15:05-!-TWerkhoven[l] [] has joined #openttd
15:06<frosch123>except it does not fit the thread :p
15:07-!-rhaeder [] has quit []
15:10<Eddi|zuHause>i'm against implicit exclusion
15:12<Eddi|zuHause>have an explicit list of inclusions, and an explicit list of exclusions. all other cargos will be judged by their class
15:12<andythenorth>it's explicit exclusion
15:12<andythenorth>frosch123: yes it should be moved :)
15:13<frosch123>Eddi|zuHause: two lists are bad. then vehicle authors skip adding cargos to the list, because they think the classes will do
15:13<andythenorth>Eddi|zuHause: you explicitly chose not to refit to it - by not including it in the list
15:13-!-rhaeder [] has joined #openttd
15:13<Eddi|zuHause>frosch123: but classes should do.
15:13<andythenorth>they don't and won;t
15:13<andythenorth>won't :P
15:13<frosch123>Eddi|zuHause: you get the same result as today
15:14<frosch123>you do not know whether a cargo is in a class or not
15:14<Eddi|zuHause>frosch123: no.
15:14<andythenorth>all we do with two props is ask everyone to upgrade grfs for same result
15:14<frosch123>Eddi|zuHause: if you have no special needs for cargo, just do not include it in the ctt
15:15<Eddi|zuHause>frosch123: imagine a cargo that needs specific graphics on one wagon, and generic graphics on the other wagons. then i need to include it in CTT to decide the wagons, and i have to add it to _every_ wagon's refit list
15:16<Eddi|zuHause>that's stupid. a hassle. tedious. senseless work.
15:16<Eddi|zuHause>unneeded redundancy.
15:18<andythenorth>maybe /me is immune to that
15:18-!-blotek___ [] has joined #openttd
15:18<andythenorth>when you code industry tiles, industry layouts, industry action 2s for graphics, redundancy becomes a way of life
15:18<Eddi|zuHause>it must be three state logic: "include", "exclude", "don't care"
15:19-!-Brianetta [] has joined #openttd
15:19<Eddi|zuHause>andythenorth: when i face redundancy, i write a generator script...
15:19<Eddi|zuHause>but this is a case where it's easily avoided
15:21<@planetmaker>don't care is not in ctt
15:21<Eddi|zuHause>planetmaker: the CTT is global to the grf
15:21<@planetmaker>and for the vehicles you have, you should care whether they transport a given cargo. Not?
15:22<Eddi|zuHause>imagine i have one wagon that has special livery for TOUR
15:22<andythenorth>Eddi|zuHause: when you face redundancy you write a generator script -> is the write answer
15:22<andythenorth>right /s :P
15:22<Eddi|zuHause>now i have to go through 50 differen passenger wagons and add TOUR to their refit list
15:22<andythenorth>you use whatever templating language you like to set that up as a define
15:23<Eddi|zuHause>or: i need TOUR only in the refit capacity callback
15:23<andythenorth>you effectively create your own private classes internal to your set
15:24<Eddi|zuHause>andythenorth: that's not the path of least resistance in this case
15:24<andythenorth>what is?
15:25-!-blotek_ [] has quit [Ping timeout: 480 seconds]
15:25<Eddi|zuHause>andythenorth: passenger wagons are currently working perfectly fine, if i just set them to CC_PASSENGERS
15:25<Eddi|zuHause>andythenorth: with the proposed change, i have to touch every already finished wagon
15:25<Eddi|zuHause>andythenorth: just because i use the TOUR label in capacity callback
15:26<@peter1138>only if you used the ctt refit list property with that vehicle
15:27<andythenorth>the proposal is not to remove current refit mask prop
15:27<Eddi|zuHause>that's not the point
15:28<andythenorth>well I am puzzled
15:29<andythenorth>I don't see a way to have 'classes and labels are coupled', 'classes and labels aren't coupled'
15:29<andythenorth>I can't figure out an ontology for that
15:29<andythenorth>is something wrong in the requirements?
15:30<Eddi|zuHause> <-- anyway, thoughts?
15:31-!-Cybertinus [] has joined #openttd
15:31*andythenorth has an idea
15:31<andythenorth>classes are provided not by cargo set, but by vehicle set
15:32<andythenorth>there is a label -> class mapping table
15:32<andythenorth>each vehicle set decides what classes it wants to define for each cargo, and then uses those with the current class props
15:33<andythenorth>ideally, this would be in a varaction 2 chain
15:33*Eddi|zuHause doesn't see how that ever is going to work
15:33<andythenorth>this would solve the problem for vehicle authors
15:34<andythenorth>they get to keep class based refitting, with precise control over which labels use which classes
15:34<andythenorth>thereby making it a black box between cargo set and vehicle set
15:34<andythenorth>whilst allowing vehicle authors the control they require
15:34<andythenorth>making it a varact 2 is convenient, because it could be redefined arbitrarily within the same grf, which is probably desirable
15:35<andythenorth>multiple vehicles could chain to the same varact
15:35<andythenorth>it's quite an easy one - just read the label (index in the CTT) and return a bit mask of classes
15:35<andythenorth>then use those to determine refittability
15:36<andythenorth>the goal is precise control without using labels?
15:36<frosch123>Eddi|zuHause: "never exclude" sounds wrong for passengers
15:37<frosch123>imo "passengers" should always be present, either as include or as exclude
15:37<frosch123>take TOUR as example
15:37<andythenorth>Eddi|zuHause: what happens if I want to transport ice? :)
15:37<andythenorth>liquid + refrigerated?
15:38<andythenorth>or LPG?
15:38<frosch123>ice is not liquid
15:38<b_jonas>transporting snow is funnier
15:38<andythenorth>it is if you freeze it in the tanker
15:38<frosch123>it is either oversized piece goods, or non-pouring bulk
15:38*andythenorth is fooling
15:38<andythenorth>looks pretty good otherwise
15:39<andythenorth>'no set defines this yet' <- true for hazardous? eGRVTS implements it, but doesn't define it?
15:39<b_jonas>isn't transporting ice the same as transporting raw meat products?
15:39<b_jonas>no wait
15:39<b_jonas>I guess it isn't
15:44<Eddi|zuHause>andythenorth: refrigerated is forbidden for liquids
15:44<Eddi|zuHause>andythenorth: that's in the industry column
15:45<Eddi|zuHause>andythenorth: meaning no industry set defines that yet
15:45<andythenorth>assumed so, thought I'd check
15:45<andythenorth>really really, is there a use for 'covered' for countable cargo?
15:45-!-DOUK [] has joined #openttd
15:46*frosch123 wonders what breaks more sets... changing cargo classes of default cargos, or changing labels of default cargos
15:46<Rubidium>doing both ;)
15:47*andythenorth would place money on Rubidium's answer
15:47<andythenorth>if it was OR then changing classes
15:47<andythenorth>is my guess
15:48<frosch123>changing labels breaks all sets supplying specific graphics
15:48<andythenorth>or varact 2 checks of translated cargos
15:48<Eddi|zuHause>frosch123: i really don't see how changing labels is breaking any sets. old sets refit on slots, and new sets (should) refit on classes
15:48<andythenorth>frosch123: also....station sets :P :o
15:49<andythenorth>what do house sets do about cargo?
15:49<Eddi|zuHause>same as industries
15:50-!-Kurimus [] has quit []
15:50<andythenorth>Eddi|zuHause: steel can't go by boxcar? :P
15:51-!-mahmoud [] has quit [Ping timeout: 480 seconds]
15:51<andythenorth>for every case, a counter case :) Death by image search
15:52<andythenorth>(I didn't search for that one, it was coincidental browsing ;) )
15:53<frosch123>well, i'll leave you alone with this :p
15:54<frosch123>i'll be gone from tomorrow to next week :)
15:54<andythenorth>enjoy :)
15:54<frosch123>a few days without cargo classes
15:55*andythenorth wonders if eddi is right about exclude
15:55<andythenorth>for labels
15:55-!-Brianetta [] has quit [Quit: Tschüß]
15:55<andythenorth>the 'include only' route is highly elegant, but the usability might suck
16:00<Eddi|zuHause>andythenorth: i'll write a guide to designing wagons accompanying that
16:01<andythenorth>Eddi|zuHause: for the case of a prop to exclude labels - so I add a new label to my CTT for one vehicle. Now I have to go and update exclude properties on n vehicles to exclude that :(
16:01<andythenorth>sucks just as much
16:02<Eddi|zuHause>andythenorth: why? adding a cargo to CTT doesn't change its behaviour
16:03<Eddi|zuHause>andythenorth: refitability is defined by classes
16:03<Eddi|zuHause>in both cases
16:03<andythenorth>I want to prevent refitting of some new cargo
16:03<Eddi|zuHause>you never want to prevent refitting to _all_ wagons
16:03<andythenorth>it has classes on it I don't like
16:05<andythenorth>I disagree with the cargo author
16:05-!-Celestar [] has joined #openttd
16:06<Eddi|zuHause>yes, but then you want specific exceptions, so it's warranted that you apply this specific exception to every place that needs it
16:08<andythenorth>and we need to stick to the rule that a cargo author may never vary classes once a cargo is first defined
16:08<andythenorth>or we break sets
16:08<andythenorth>so no industry set should publish classes until a 'final' release
16:10<+michi_cc>Eddi|zuHause: I'd have set GOODS as Countable + Air freight
16:11<Eddi|zuHause>yes. that's what the table says, actually
16:12<Eddi|zuHause>michi_cc: removing cargo classes is stated explicitly. the current classes are to be kept otherwise
16:12<+michi_cc>I understood "proposed change" as use these classes instead. Rename the column to "additional classes"?
16:14<frosch123>it also has a "remove" :p
16:14<andythenorth>Eddi|zuHause: MB contributed some more thoughts in the thread
16:16<andythenorth>clay is pourable btw (albeit sticky)
16:17<andythenorth>if we could figure this out I could next start figuring out what to do with auto-refit :)
16:17<Rubidium>andythenorth: then it hasn't been long enough in the hopper ;)
16:18<andythenorth>in tropic, if you travel for too long, your cargo decays 100%
16:18<andythenorth>and your wagon capacity is set to 0
16:20-!-TWerkhoven2 [] has joined #openttd
16:21-!-Celestar [] has quit [Ping timeout: 480 seconds]
16:22<andythenorth>Eddi|zuHause: ENSP might imply liquid, due to the FIRS chain including petrol -> ENSP ?
16:23<andythenorth>I don't care either way
16:23<andythenorth>it's a highly generic cargo
16:23<Eddi|zuHause>you did read MB's last sentence, right? :o
16:24<andythenorth>I tend to apply a rosy-pink filter to everything he says
16:24<+michi_cc>andythenorth: Ideal auto-refit cargo :)
16:24<+michi_cc>Can go into any wagon you'd want so you can always take it in the return trip.
16:24<andythenorth>ideal for backloading
16:25<andythenorth>I will need to rework the supplies mechanic though :P
16:25<andythenorth>as more will get delivered
16:27<andythenorth>Eddi|zuHause: sugar beet not pourable?
16:27-!-TWerkhoven [] has quit [Ping timeout: 480 seconds]
16:27<Eddi|zuHause>andythenorth: i don't see it fitting well into an ore/coal hopper, anyway :p
16:28-!-DayDreamer [] has left #openttd []
16:28<Eddi|zuHause>maybe that should be changed. i'm not too strong on this
16:29<andythenorth>that one's probably pourable
16:29<andythenorth>which FICR are bulk? Cotton or such?
16:29<frosch123>so, will there be an addition misc cargo flags property for "clear" and other refit-cost/autorefit-specific stuff?
16:30<andythenorth>frosch123: probably
16:30<Eddi|zuHause>"covered" should also be turned into a misc flag, rather than a class.
16:30<andythenorth>frosch123 that doesn't need a grf version bump?
16:31<frosch123>cb 15e does not use var18 yet
16:31<andythenorth>Eddi|zuHause: I think MB would like to use covered for providing cargo support, so probably valid as a class
16:31<frosch123>you can either add a new property, or extent the "freight" property
16:31<andythenorth>he wants to use it to provide detailed graphics
16:31<Eddi|zuHause>andythenorth: the way i see it, "covered" does not change refitability at all
16:32<andythenorth>do you distinguish it from powderised?
16:32<andythenorth>you do
16:32<Eddi|zuHause>andythenorth: yes, but misc flags should provide that graphics decisions, not classes
16:32<frosch123>"freight" currently only uses 1 bit, but both ottd and ttdp actually only check for == 0 or != 0. so, unless grfs check the version number, old ottd/ttdp would consider everything as "freight" when adding mor flags
16:32<frosch123>(but i do not think that is a concern; since adding a new property would disable usage completely)
16:32<andythenorth>Eddi|zuHause: I find covered entirely pointless, on the basis that you've moved 'powderised' to a specific bit of its own
16:33<Eddi|zuHause>andythenorth: yep
16:33<andythenorth>I don't get how covered helps anybody
16:33<frosch123>food-stuff is covered
16:33<frosch123>grain, maize and such
16:33<andythenorth>if its piece goods, you presume that the wagon provides that
16:33<andythenorth>anyway, in game it's more fun to see the cargo in the wagon :P
16:33<frosch123>both are bulk and pourable
16:34<Eddi|zuHause>andythenorth: i left covered untouched, because removing classes is not going to work anyway
16:34<andythenorth>maybe we forget about it
16:34<andythenorth>what will be will be in that case
16:36-!-Cybertinus [] has quit [Remote host closed the connection]
16:37<andythenorth>oh ffs
16:38*andythenorth just discovered that for long periods, most uk grain moved as piece goods
16:38<andythenorth>did I mention classes are stupid if based on real life?
16:39<andythenorth>we should just base them on what's going to be fun
16:40-!-frosch123 [] has quit [Remote host closed the connection]
16:59-!-LordAro [] has quit [Quit: ajax IRC Client]
17:01<andythenorth>Eddi|zuHause: rename WOOD to LOGS :D
17:02<andythenorth>Eddi|zuHause: if not FOO_ how about HAM_ or EGGS ?
17:02<andythenorth>python jokes :P
17:07-!-andythenorth [] has quit [Quit: andythenorth]
17:16-!-Brianetta [] has joined #openttd
17:19-!-TGYoshi [~TGYoshi@] has quit [Quit: Poof]
17:26-!-pugi [] has quit [Read error: Connection reset by peer]
17:27-!-pugi [] has joined #openttd
17:35-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
17:40-!-KritiK [] has quit [Ping timeout: 480 seconds]
17:43-!-HerzogDeXtEr1 [] has joined #openttd
17:50-!-HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
17:52<@Terkhen>good night
18:02-!-valhallasw [~valhallas@] has quit [Quit: zzzzzz]
18:04-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
18:05-!-pjpe [] has quit [Quit: ajax IRC Client]
18:07-!-TWerkhoven[l] [] has quit [Remote host closed the connection]
18:15-!-Zuu [] has quit [Ping timeout: 480 seconds]
18:15-!-TWerkhoven2 [] has quit [Quit: He who can look into the future, has a brighter future to look into]
18:19-!-Progman [] has quit [Remote host closed the connection]
18:40-!-MNIM [] has joined #openttd
18:54<ctibor>I have a farm that produces only 6 livestock / month. I have two trains servicing it and the station has rating for around 72%. I have smooth economy enabled. The farm increases its production sometimes to 12 livestock per month, even to 18, but never goes above that value. I service that farm for around 50 years and it is still that low. Why doesn't it increase more?
19:03-!-hanf [] has quit [Quit: Leaving]
19:03-!-sla_ro|master [~slaco@] has quit []
19:05-!-pjpe [] has joined #openttd
19:05-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
19:25-!-Tomazim [] has joined #openttd
19:27<Tomazim>I am beyond pleased that there is still an OpenTTD community
19:34<@planetmaker>many parts of it are sleeping right now, though ;-)
19:37<Tomazim>I am playing some single player hardmode now
19:37<Tomazim>It's so slow :(
19:38<Tomazim>The beginning is slow
19:38<Tomazim>i.e hard to make money with a 100k loan
19:38<@planetmaker>grant yourself more loan ;-)
19:39<Tomazim>They like me enough for 300k now, so it's picking up
19:45-!-DDR_ [~chatzilla@] has joined #openttd
20:15<z-MaTRiX>in original ttd it was lol to make profit from shares of companies, just needed to buy shares before the company requests loan, then when the company has money, just sell the share, and loan will not be shared <;
20:17-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
20:19-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
20:29-!-Pikka [] has joined #openttd
20:31-!-Brianetta [] has quit [Quit: Tschüß]
20:32-!-Pikka [] has quit []
20:37-!-Elukka [] has quit []
20:42-!-Strid_ [] has quit [Ping timeout: 480 seconds]
20:43-!-KenjiE20 [] has quit [Ping timeout: 480 seconds]
20:49-!-blotek___ [] has quit [Ping timeout: 480 seconds]
21:00-!-Zuu [] has joined #openttd
21:13-!-Strid_ [] has joined #openttd
21:15-!-Zuu [] has quit [Read error: Connection reset by peer]
21:18-!-enr1x_ [] has joined #openttd
21:19-!-enr1x [] has quit [Ping timeout: 480 seconds]
21:40-!-Adambean [] has quit [Quit: Gone fishing]
22:26-!-rhaeder1 [] has joined #openttd
22:31-!-rhaeder [] has quit [Ping timeout: 480 seconds]
23:00-!-glx [glx@2a01:e35:2f59:c7c0:8d3e:d0f1:5421:870a] has quit [Quit: bye]
23:07-!-HerzogDeXtEr1 [] has quit [Read error: Connection reset by peer]
23:21-!-Kurimus [] has joined #openttd
23:24-!-Tomazim [] has quit [Ping timeout: 480 seconds]
---Logclosed Thu Nov 10 00:00:09 2011