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