Log for #openttd on 8th November 2011:
Times are UTC Toggle Colours

00:00:21  <Eddi|zuHause> (or a grid, one for each value. then you get both horizontal and vertical resizing "for free")
00:02:25  *** Progman [~progman@p57A1CD7B.dip.t-dialin.net] has quit [Remote host closed the connection]
00:35:45  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÌß]
00:45:05  *** z-MaTRiX [~matrix@index.linuxsecured.net] has joined #openttd
00:47:22  *** mahmoud [~KEM@ALyon-158-1-77-77.w90-29.abo.wanadoo.fr] has quit [Read error: Connection reset by peer]
00:52:39  <z-MaTRiX> hi
01:51:28  *** blotek_ [~blotek@abro203.neoplus.adsl.tpnet.pl] has joined #openttd
01:58:27  *** blotek [~blotek@aeih229.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 480 seconds]
02:12:12  *** George [~George@212.113.107.39] has joined #openttd
02:18:42  *** George|2 [~George@212.113.107.39] has quit [Ping timeout: 480 seconds]
03:24:33  *** rhaeder1 [~quix0r@dslb-094-221-205-021.pools.arcor-ip.net] has joined #openttd
03:30:31  *** rhaeder [~quix0r@dslb-094-221-149-164.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
04:03:42  *** glx [glx@2a01:e35:2f59:c7c0:e10b:2972:428a:9030] has quit [Quit: bye]
04:21:47  *** blotek_ [~blotek@abro203.neoplus.adsl.tpnet.pl] has quit [Remote host closed the connection]
04:45:32  *** supermop_ [~daniel_er@cpe-67-243-25-39.nyc.res.rr.com] has quit [Quit: supermop_]
05:03:10  *** Eddi|zuHause [~johekr@p54B73A0D.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
06:18:44  *** Eddi|zuHause [~johekr@p54B73A26.dip.t-dialin.net] has joined #openttd
06:36:10  *** Prof_Frink [~proffrink@5e0a9627.bb.sky.com] has quit [Ping timeout: 480 seconds]
06:43:07  *** JVassie [~James@2.27.86.104] has joined #openttd
07:11:23  *** Celestar [~dax@89.204.137.80] has joined #openttd
07:16:26  <Celestar> morning \o
07:19:15  *** pugi [~pugi@dyndsl-095-033-153-132.ewe-ip-backbone.de] has joined #openttd
07:20:09  <Terkhen> good morning
07:24:30  *** JVassie [~James@2.27.86.104] has quit [Ping timeout: 480 seconds]
07:33:32  *** sla_ro|master [~slaco@95.76.27.160] has joined #openttd
07:52:14  <peter1138> Celestar, fixed it yet? :D
07:56:19  *** Elukka [~Elukka@89-166-103-135.bb.dnainternet.fi] has joined #openttd
07:56:41  <Celestar> fixed what? the morning? :P
08:00:41  <Celestar> and I'm trying to understand git :P
08:02:08  <planetmaker> use hg-git ;-)
08:02:24  <planetmaker> moin also :-)
08:04:39  *** Neon [~Neon@dslb-094-219-013-186.pools.arcor-ip.net] has joined #openttd
08:04:46  *** HerzogDeXtEr1 [~Flex@i59F6ACB6.versanet.de] has quit [Read error: Connection reset by peer]
08:06:16  *** Progman [~progman@p57A1B050.dip.t-dialin.net] has joined #openttd
08:12:47  <Celestar> ok I cloned michi_cc's git repo. suppose I wanna do some own development there, what's the recommended procedure? Make an own branch and then merge from Master if he does changes?
08:14:23  <peter1138> something like that
08:50:52  *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd
08:52:46  *** pugi [~pugi@dyndsl-095-033-153-132.ewe-ip-backbone.de] has quit [Quit: I reject your reality and substitute my own]
08:53:27  <Celestar> peter1138: heh. k
08:53:38  <Celestar> erm ....
08:53:57  <Celestar> define debug_message (message) { return; }
08:55:14  <Eddi|zuHause> that souds... useful...
08:57:03  <Eddi|zuHause> mÀh... i still have no way how smartd does not wake up sleeping drives
08:59:11  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
09:16:19  *** MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has quit [Ping timeout: 480 seconds]
09:33:49  <peter1138> hm
09:33:51  *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has joined #openttd
09:34:08  <andythenorth> morninks
09:35:43  <andythenorth> in some respects we should remove the class information from the table of cargo *labels*
09:36:02  <andythenorth> why?
09:36:24  <Eddi|zuHause> what?
09:36:39  <andythenorth> so in the list of known cargos we display their classes
09:36:43  <andythenorth> in the wiki
09:36:47  <andythenorth> who is that information useful to?
09:37:03  <Eddi|zuHause> everybody
09:37:21  <andythenorth> es
09:37:22  <andythenorth> yes
09:37:30  <andythenorth> but some of that utility is for all the wrong reasons
09:37:35  *** TWerkhoven [~Turbulent@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd
09:37:42  <andythenorth> for cargo set authors trying to maintain parity, it's useful
09:37:53  <Eddi|zuHause> a cargo set author must know that to keep his set compatible with others, and a vehicle set author must know that to define exceptions for the refitability
09:37:59  <andythenorth> Eddi|zuHause: no
09:38:02  <Eddi|zuHause> yes
09:38:05  <andythenorth> well yes
09:38:07  <andythenorth> currently
09:38:13  <Eddi|zuHause> deja vu :)
09:38:16  <andythenorth> because of the stupid XOR mask
09:38:23  <andythenorth> which is a fact on the ground
09:38:37  <andythenorth> but the cargos with labels are *known* cargos yes/no?
09:41:09  <andythenorth> linking the labels and the classes so tightly encourages vehicle authors to provision support for specific cargos based on classes, not labels
09:41:17  <andythenorth> they have no choice currently
09:41:21  *** DDR_ [~chatzilla@142.179.78.88] has quit [Ping timeout: 480 seconds]
09:42:14  <Eddi|zuHause> andythenorth: there's still the 32 cargos barrier
09:42:22  <andythenorth> yup
09:42:34  <andythenorth> this is all hot air wrt what's currently implemented
09:42:45  <andythenorth> but worth unpicking imho
09:42:46  <Eddi|zuHause> so you MUST rely on cargo classes
09:43:29  <andythenorth> yup
09:43:35  <andythenorth> but not in cb-land
09:43:48  <andythenorth> with the cb, problem solved
09:44:05  <andythenorth> and as older sets stuck on the refit masks are not maintained, they don't need the information
09:44:14  <Eddi|zuHause> don't treat some hypothetical callback as holy grail
09:44:35  <andythenorth> it doesn't solve the 'how best to define classes'
09:44:46  <andythenorth> it just sweeps away the mess of XOR
09:44:59  <Eddi|zuHause> primarily, a callback would be much more complicated to code than a simple bitmask
09:45:08  <planetmaker> which would leave the existing classes sufficient, though, andythenorth
09:45:15  <andythenorth> planetmaker: yes
09:45:35  <andythenorth> currently MB appears to be amenable to *removing* certain classes, which might be wise, then just keep current scheme
09:45:38  <planetmaker> and as eddi pointed out correctly: it'd not pose a big issue to sanitize the classes of existing cargos
09:46:18  <planetmaker> I'm not too thrilled by what he suggests. It basically is to do the same thing as now. Just differently named
09:46:22  <planetmaker> and backwards
09:46:37  <andythenorth> he considers both current scheme + a new scheme
09:46:41  <andythenorth> both are worth looking at
09:47:51  <andythenorth> Eddi|zuHause: I still think you're wrong about beer btw :D
09:48:00  <andythenorth> not because you're wrong, but because it's a slippery slope
09:48:23  <andythenorth> by your evidence-based method, milk *is* piece goods - because it used to travel in churns for hundreds of years
09:49:36  <andythenorth> where I grew up, coal was delivered in sacks
09:49:42  <Eddi|zuHause> you could implement churns as vehicles-in-vehicles, then the whole issue would disappear :)
09:50:01  <andythenorth> it would indeed
09:50:07  <andythenorth> separation of container + cargo
09:51:12  <andythenorth> my point isn't to argue about beer - I just don't think looking at specific RL examples is very helpful for deciding classes
09:51:21  <andythenorth> it just leads to 'war via google image search'
09:53:04  *** pjpe [ae5b514a@ircip2.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
09:54:49  <planetmaker> :-P
09:54:56  * planetmaker googles a few images to gather fuel ;-)
09:56:10  <andythenorth> Eddi|zuHause: I'm going to duck the issue :P
09:56:27  <Eddi|zuHause> and i have to go out...
09:56:40  <andythenorth> *if* vehicle authors don't do the dumb thing and exclude piece/bulk/liquid, there isn't really a problem
09:57:13  <Eddi|zuHause> there are lots of problems... :)
09:58:52  <andythenorth> in that case we should move on to those :P
09:59:14  <andythenorth> the classes set by cargo sets shouldn't be a holy war :)
09:59:24  <andythenorth> the exclusions used by vehicle set authors might be :P
10:04:06  <Eddi|zuHause> prop 29 should be switched "AND" instead of "AND NOT"
10:04:22  <Eddi|zuHause> and the XOR issue resolved
10:04:27  <planetmaker> eh?
10:04:35  <planetmaker> and? How would that be helpful?
10:04:56  <planetmaker> you mean like piece or liquid) AND (refrigerate)?
10:04:57  <planetmaker> hm, yes
10:05:01  <Eddi|zuHause> then it would be "monotonous"
10:05:01  <Eddi|zuHause> which means adding classes to cargos is unproblematic
10:05:19  <planetmaker> That's true
10:05:24  <planetmaker> That'd make it easy
10:07:48  <andythenorth> so vans would set 'covered' in prop 29?
10:08:00  <andythenorth> rather than open wagons having to set 'covered' in prop 29
10:08:08  <andythenorth> as per current AND NOT case
10:09:01  <Eddi|zuHause> yes
10:09:27  <andythenorth> it's not a change we could make though, is it?
10:09:51  <andythenorth> or is it?
10:10:25  *** Devroush [~dennis@ip-213-49-111-51.dsl.scarlet.be] has joined #openttd
10:11:30  <andythenorth> hmm...does that idea help?
10:11:30  <Eddi|zuHause> it would have to be part of GRFv8
10:11:45  <andythenorth> now we get no cargo travelling by covered van unless the covered class is set
10:11:48  <Eddi|zuHause> it would be 50% of my proposal
10:11:49  <andythenorth> seems sub-optimal
10:12:02  <Eddi|zuHause> the other 50% would be rearranging the cargo classes
10:12:26  <andythenorth> Eddi|zuHause: what *doesn't* the cb route solve for you?
10:13:19  <andythenorth> hmm
10:13:27  <andythenorth> ANDing with covered would be stupid anyway
10:13:43  <andythenorth> it would be better to put covered in prop 28
10:14:34  <andythenorth> if you had two classes in prop 29 do you have to match both in the AND
10:14:42  <andythenorth> i.e. AND (AND) or AND (OR)
10:17:30  <peter1138> # funny how love is, everywhere just look and see
10:26:34  *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has left #openttd []
10:56:20  <planetmaker> Eddi|zuHause, the 11 November date became void ;-)
11:03:51  *** sla_ro|master [~slaco@95.76.27.160] has quit []
11:39:20  *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has quit [Quit: Leaving.]
11:41:24  *** hanf [~Klaus@host-89-242-66-98.as13285.net] has joined #openttd
11:42:26  *** mahmoud [~KEM@ALyon-158-1-77-77.w90-29.abo.wanadoo.fr] has joined #openttd
11:45:55  *** blotek [~blotek@abro203.neoplus.adsl.tpnet.pl] has joined #openttd
11:46:12  *** TGYoshi [~TGYoshi@86.81.146.146] has joined #openttd
12:15:35  <CIA-6> OpenTTD: yexo * r23130 /trunk/src/misc_gui.cpp: -Change [FS#4825]: open the query string window centered as it (almost) always requires your attention
12:19:49  *** andythenorth [~Andy@78-86-194-127.zone2.bethere.co.uk] has joined #openttd
12:31:00  <andythenorth> wallyweb misses that the additional classes are to add information
12:31:04  <michi_cc> Celestar: I'm using rebasing instead of merging in that repository, which unfortunately isn't very friendly for people to use as a development base (i.e. I treat it more like a patch queue). Nevertheless, coping with it isn't too difficult.
12:31:26  <andythenorth> merging everything 'odd' into one class destroys the information content
12:31:56  <andythenorth> *but* this suggests that using classes to store information which is not 1:1 related to refitting is unwise
12:33:07  <michi_cc> Celestar: Most of the time, using 'git pull --rebase' to update should work. In case it doesn't, ask me :)
12:34:22  <Celestar> $ git pull --rebase
12:34:23  <Celestar> Current branch master is up to date.
12:34:26  <Celestar> so something like that?
12:35:21  <michi_cc> Yes, and you can also execute 'git config --add branch.master.rebase true' to make --rebase the default.
12:35:32  <michi_cc> (for the branch master, that is)
12:36:05  <andythenorth> planetmaker: new prop 'cleaning factor' - byte
12:36:13  <andythenorth> multiplier on refit cost
12:36:17  <Noldo> what's the workflow for using git in patchqueue way?
12:36:23  <andythenorth> when refitting *from* that cargo
12:36:47  <planetmaker> no. Not a factor. Just a flag
12:36:53  <andythenorth> meh
12:36:58  <andythenorth> multipliers are more fun :)
12:37:04  <michi_cc> Rebasing can fail or produce unwanted effects, but as I don't update there often, you'll probably be fine. Should there be a problem you can just ask me.
12:37:05  <planetmaker> otherwise you're duplicating the callback
12:37:09  <Celestar> michi_cc: so in that case, how would you add a "patch queue" on top of that?
12:37:27  <Celestar> make a own branch and use "rebase" for updating?
12:37:38  <andythenorth> planetmaker: so just set a bit?
12:38:01  <andythenorth> and let the vehicle author decide costs?
12:38:36  <michi_cc> That's exactly what pull --rebase does. I.e. it saves which commits are on your master branch but not in origin, updates origin and then rebases only your changes onto the new remote changes.
12:38:51  <Celestar> ah
12:38:55  <Celestar> sounds good
12:38:57  *** MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has joined #openttd
12:40:15  <michi_cc> It's possible to do that manually as well, but generally git pull --rebase Just Works™
12:41:26  <michi_cc> It won't save you from conflicts, but merging wouldn't either.
12:41:37  <Celestar> nah.
12:41:44  <Celestar> I'm not afraid of conflicts :>
12:42:36  <planetmaker> andythenorth, of course
12:42:44  <andythenorth> ok
12:42:46  <andythenorth> works for me
12:42:50  *** TWerkhoven [~Turbulent@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Remote host closed the connection]
12:43:03  <planetmaker> frosch suggested using one of the misc flags
12:43:07  <Celestar> michi_cc: anyway, what's your plan with that patch queue anyway?
12:43:12  <planetmaker> which probably is a good idea, if it's not a cargo class
12:43:14  <andythenorth> planetmaker: is it more properly a 'refit at station or refit at depot' flag?  Rather than a 'refit cost' flag?
12:43:38  <planetmaker> I think he suggested a flag for "foodish"
12:43:49  <planetmaker> with basically the same meaning as the cargo class
12:43:58  <andythenorth> seems overly specific somehow...
12:44:03  <planetmaker> (or that's how I'd treat it. Like "needs clean car"
12:44:06  <planetmaker> no
12:44:15  <andythenorth> 'needs clean car' is ok
12:44:40  <planetmaker> foodish was your wording ;-P
12:44:53  <andythenorth> how often am I wrong?
12:44:58  <andythenorth> ~50% of the time?
12:45:40  <planetmaker> foodish is not wrong. It's just a sub-category of 'clean' ;-)
12:45:50  <Celestar> hm.
12:46:06  <michi_cc> Celestar: Completing my half-split of MP_STATION and then thinking about MP_TUNNELBRIDGE.
12:46:27  <Celestar> If, in facebook, people are more and more accepting friend requests. How long until everyone has everyone else friended? :P
12:46:30  <Celestar> michi_cc: halfsplit?
12:47:05  <michi_cc> "openttd - 56 Fehler, 0 Warnung(en)" or something like that :)
12:47:25  <Celestar> rofl
12:49:25  <Celestar> michi_cc: and the MP_TUNNELBRIDGE idea was then MP_CLEAR + MP_BRIDGE + MP_RAILWAY or something?
12:50:08  *** TWerkhoven [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd
12:50:59  <Celestar> hm.
12:51:00  <michi_cc> I'm not exacty sure on that yet, but definitely not MP_CLEAR + MP_BRIDGE for the same height level. Probably a MP_CLEAR for the terrain under the bridge at a different height level and MP_TUNNELBRIDGE as a base for the other heightlevels.
12:51:27  <Celestar> MP_CLEAR + MP_RAILWAY + MP_BRIDGE + MP_RAILWAY + MP_BRIDGE + MP_RAILWAY
12:51:45  <Celestar> (crossing railway bridges over railway?)
12:52:01  <Celestar> michi_cc: how about a MP_BRIDGEHEAD ?
12:52:29  <planetmaker> andythenorth, cargo has no means to provide refit cost hints
12:52:35  <planetmaker> it's intrinsically impossible
12:52:42  <planetmaker> as it depends 100% on what was there before
12:52:50  <planetmaker> and how the vehicle is equipped
12:52:51  <michi_cc> That would just be a "subtype" of MP_TUNNELBRIDGE
12:53:06  <Celestar> or that.
12:54:26  <andythenorth> planetmaker: you could make the blanket assumption that *anything* specifying clean requires the vehicle to be cleaned
12:54:54  <Celestar> michi_cc: did you give MP_FOUNDATION a thought?
12:55:01  <andythenorth> I think we agree, it's just not written down in spec form?
12:55:15  <planetmaker> andythenorth, it's a bad idea. It mixes again two features more than is good for them
12:55:25  <planetmaker> For no real benefit
12:55:37  <michi_cc> That's one of the areas I'm not sure yet what the best solution is.
12:55:45  <andythenorth> a hint specific to the cost?  I think that's a bad idea.  You convinced me it's just a bool
12:55:55  <andythenorth> the vehicle sets the cost
12:56:48  <andythenorth> the flag would be used by the vehicle during the refit cb
12:56:57  <planetmaker> yes
12:57:13  <andythenorth> what the vehicle set author does is up to them
12:57:22  <planetmaker> i.e. the cost hint is pointless when considering milk. A refit of the box car would cost nothing. The tanker needs cleaning
12:57:22  <andythenorth> they could check the new cargo, or both previous and new cargos
12:57:47  <planetmaker> yes. That's what the callback does. What OpenGFX+Trains does
12:58:07  <planetmaker> (if you are in need of an example ;-) )
12:58:12  <andythenorth> nah, I get it
12:58:19  <andythenorth> it's a bool
12:58:50  <andythenorth> making it mean 'foodstuff' is too specific.  'Clean' is a bit vague.  Just needs a name
12:59:16  <Celestar> michi_cc: I'll wreck my brain a bit, maybe I have some epiphany
13:01:02  <andythenorth> planetmaker: any other useful bool props you can think of? :P :D
13:01:20  <andythenorth> these aren't conventions, they're patches on ottd?
13:01:33  <andythenorth> so they won't fragment in quite the same way
13:01:36  <andythenorth> and will get more sane review
13:01:51  <planetmaker> yes
13:02:41  <planetmaker> more so, they require patches to nforenum and nml
13:03:09  <Celestar> michi_cc: or maybe write some prototype :P
13:07:17  <Eddi|zuHause> i'm not having a sensible idea how to revamp the cargo class system while keeping compatibility with the old system...
13:11:00  <Celestar> have two systems?
13:11:26  <Eddi|zuHause> http://xkcd.com/927/ ?
13:13:55  *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd
13:18:13  <z-MaTRiX> hey-ho
13:19:49  *** Biolunar [mahdi@blfd-4db190a7.pool.mediaWays.net] has joined #openttd
13:28:17  <andythenorth> Eddi|zuHause: keep the current system?
13:30:27  <andythenorth> it's really not very broken
13:30:32  <lugo> "It's cheaper to keep her"
13:30:33  <andythenorth> just a bit confusing
13:30:40  <andythenorth> and a bit degraded by random classes
13:31:16  <andythenorth> and cargo sets need to forget trying to provide reverse-support via classes to vehicle sets that do odd things
13:48:37  <Eddi|zuHause> the problem is the conversion of old cargos to a sensible system
13:49:12  <andythenorth> that's not a problem if we don't change...?
13:49:51  <Eddi|zuHause> yes, it is
13:49:59  <Eddi|zuHause> because it completely does not make any sense
13:51:30  *** glx [glx@2a01:e35:2f59:c7c0:91d7:24c2:f473:6f05] has joined #openttd
13:51:33  *** mode/#openttd [+v glx] by ChanServ
13:54:20  <andythenorth> Eddi|zuHause: break old sets?
13:54:27  <andythenorth> it's about time lots of them got broken
13:55:31  <planetmaker> to unconditionally break them is not really a way
13:57:39  <andythenorth> Eddi|zuHause: only classes trouble you?  Not labels?
13:58:19  <Eddi|zuHause> andythenorth: i don't really care about labels. that's solely a matter for industry set authors
13:58:22  <andythenorth> ok
13:58:26  <andythenorth> so one proposal
13:58:59  * andythenorth thinks
13:59:35  <Eddi|zuHause> andythenorth: the "FMSP is both fertilizer and harvesters" is kinda troublesome
13:59:54  <andythenorth> Eddi|zuHause: shrug :)
14:00:00  <andythenorth> let vehicle set authors decide
14:00:23  <Eddi|zuHause> andythenorth: but it totally destroys the class system :)
14:00:34  <Eddi|zuHause> andythenorth: you should either split it, or remove one of them
14:01:15  <Eddi|zuHause> andythenorth: combine FMSP and ENSP into "machines", and add FERT
14:01:32  * Eddi|zuHause is opening a can of worms)
14:01:55  <andythenorth> Eddi|zuHause: feel free to open the can :)
14:02:19  <andythenorth> but then we start confusing the cargo with the industry chain gameplay
14:02:51  <andythenorth> it really should be of no issue that FMSP is n things in the gameplay
14:02:56  <planetmaker> we should only use only two cargo classes: "dorks" and "stuff"
14:03:01  <andythenorth> the cargo set should be a black box to the vehicle set
14:03:15  <andythenorth> labels can cross the black box
14:03:26  <Eddi|zuHause> yesandno
14:03:32  <andythenorth> standard answer :P
14:03:46  <planetmaker> it's no issue that a vehicle set doesn't support all possible representation of a cargo
14:04:10  <andythenorth> the duty of the vehicle set is to provide vehicles matching certain classes
14:04:14  <planetmaker> and honestly... your latest table, Eddi|zuHause , reads like "no change needed"
14:04:30  <andythenorth> the duty of the vehicle set is not to support the cargo set author's vision of what a cargo is
14:04:43  <Eddi|zuHause> planetmaker: "not pourable" is a change
14:04:52  <andythenorth> the cargo set author determines where the cargo goes
14:04:56  <andythenorth> and certain intrinsic properties
14:04:57  <Eddi|zuHause> planetmaker: and still the current cargos are totally wrong
14:05:10  <peter1138> i agree with wallyweb ;)
14:05:32  *** frosch123 [~frosch@frnk-590fe7e9.pool.mediaWays.net] has joined #openttd
14:05:35  <Eddi|zuHause> planetmaker: current GOOD is not "piece/countable", current WOOD and STEL is not "oversized"
14:05:59  <planetmaker> don't mix the cargo classes of labels in the cargo classes discussion
14:06:07  <planetmaker> it's IMHO two things
14:06:19  <Eddi|zuHause> planetmaker: but it is actually the biggest problem
14:06:24  <planetmaker> yes, that it is
14:06:36  <Eddi|zuHause> planetmaker: it makes no sense fixing cargo classes, when the cargo labels stay utterly wrong
14:06:51  <planetmaker> But it doesn't require new classes at all. Just new labels. Or re-definition of labels. Or moving the labels from the xor to a new property
14:07:03  <planetmaker> I'm not arguing that, Eddi|zuHause
14:07:06  <Eddi|zuHause> planetmaker: currently we're at two new classes
14:07:13  <planetmaker> I'm arguing: "only fix the classes attached to existing labels"
14:07:22  <Eddi|zuHause> planetmaker: "lightweight" and "not pourable"
14:07:25  <andythenorth> I would place money on ending this with fewer classes than we currently have in the wiki
14:07:28  <planetmaker> and the two "new" classes I think we agreed are not needed
14:07:40  <andythenorth> 'requires pressure discharge' should go away too
14:07:58  <Eddi|zuHause> planetmaker: who is "we" and what is your value of "agree"?
14:08:08  <planetmaker> who's your "we"?
14:09:05  <planetmaker> and where do you derive any concensus about those classes from? Or their need?
14:09:23  <andythenorth> hazardous + covered/sheltered should be removed
14:09:29  <Eddi|zuHause> i didn't... i explicitly stated that is _my_ view
14:09:34  <andythenorth> oversized + neo-bulk should be consolidated
14:09:38  <andythenorth> clean is a failed idea
14:09:43  <andythenorth> special should be removed if possible
14:09:46  <planetmaker> <Eddi|zuHause> planetmaker: currently we're at two new classes
14:09:50  <andythenorth> pressure discharge should not be added
14:10:02  <Eddi|zuHause> planetmaker: that's a pluralis majestis :p
14:10:12  <andythenorth> labels should be disconnected entirely from classes
14:10:20  <andythenorth> and vehicle sets should provide for maintainability
14:10:31  <andythenorth> this all stems from *idiots not using the GPL*
14:10:37  <planetmaker> disconnecting labels from classes in refit would solve basically all issues
14:10:43  <andythenorth> ^^ all / some /s
14:10:47  <planetmaker> :-)
14:10:48  <planetmaker> most
14:11:00  <planetmaker> we could remove hazardous indeed
14:11:10  *** hanf [~Klaus@host-89-242-66-98.as13285.net] has quit [Quit: Leaving]
14:11:20  <andythenorth> http://www.dwheeler.com/essays/gpl-compatible.html
14:11:35  *** hanf [~Klaus@host-89-242-66-98.as13285.net] has joined #openttd
14:12:02  <Eddi|zuHause>  <planetmaker> disconnecting labels from classes in refit would solve basically all issues <-- problem with that thought is that it only solves _future_ issues, not compatibility with existing sets
14:12:04  <andythenorth> the most common objection from players is "wail, my favourite set won't work"
14:12:19  <andythenorth> then we dick around trying to reverse engineer sets that improperly implemented an incomplete and flawed spec
14:12:42  <planetmaker> Eddi|zuHause, we can't change current set's assumptions
14:12:48  <andythenorth> current sets should be maintained if they want accurate support
14:12:59  <andythenorth> otherwise we should slim down the number of classes, and use them in a brute-force way
14:13:01  <Eddi|zuHause> planetmaker: then we should change the default cargo's labels
14:13:20  <planetmaker> that's an interesting idea
14:13:49  <andythenorth> we have on the one hand a clear proposition that 'classes never aim to provide accurate support to vehicle types, only that some vehicle will be able to carry them' (I paraphrase)
14:14:07  <andythenorth> then we get tied up in knots trying to do ever-more-perfect support for a future unknown, and a broken past
14:14:34  <andythenorth> set bulk and/or liquid and/or piece and the cargo will *always* be transported
14:15:04  <jonty-comp> i swear you've been arguing about cargo classes for the last week
14:15:08  <andythenorth> yup
14:15:43  <andythenorth> Eddi|zuHause: GDS2
14:15:45  <Eddi|zuHause> planetmaker: yes, it is a very intriguing idea. _very_ old sets (like DBSetXL 0.8) use only cargo slots, so don't care about labels at all, and newer sets should have cargo class based refits
14:15:47  <andythenorth> instead of FOOD
14:16:04  <andythenorth> the <32 cargo limit will be eliminated
14:16:11  <andythenorth> wrt CTT
14:16:49  <andythenorth> hmm
14:16:55  <andythenorth> when I typed FOOD I meant GOOD :P
14:16:57  <andythenorth> sorry
14:16:58  <Eddi|zuHause> <andythenorth> the <32 cargo limit will be eliminated <-- compare the time between computers providing >1MB memory, and the 640k barrier being "eliminated"?
14:17:16  <Eddi|zuHause> andythenorth: "GODS" :)
14:17:30  <andythenorth> Eddi|zuHause: it can go as soon as frosch figures out and commits the two year old cb idea?
14:17:36  <andythenorth> Eddi|zuHause: OGOD
14:17:52  <andythenorth> or do an obiwan letter shift
14:17:57  <andythenorth> HPPE
14:19:41  <andythenorth> or do an imperfect obiwan
14:19:42  <andythenorth> HOPE
14:20:27  <andythenorth> planetmaker: dare we only set bulk, piece, liquid for FIRS? :o
14:20:39  <planetmaker> as classes?
14:20:44  <planetmaker> No. We also set refrigerate
14:20:53  <andythenorth> I was worrying about that
14:20:57  <planetmaker> And covered IMHO makes sense for some, too
14:20:59  <andythenorth> but it's an odd class before 1900
14:21:09  <planetmaker> that's up to the vehicle set
14:21:11  <andythenorth> planetmaker: anything can be covered.  Use a tarpaulin, or shrink wrap
14:21:19  <planetmaker> a vehicle set can always choose to ignore it
14:21:21  <andythenorth> planetmaker: he
14:21:23  <andythenorth> exactly
14:21:25  <andythenorth> so why set it?
14:21:28  <andythenorth> let the vehicle set decide?
14:21:35  <andythenorth> based on...labels
14:21:35  <planetmaker> as it helps to provide special support in 1970
14:21:47  <andythenorth> classes are for unknown cargos
14:22:02  <planetmaker> the refrigerate class is sufficient (as positive definition) to ship all those cargos
14:22:05  <planetmaker> I just tested yesterday
14:22:10  <andythenorth> slippery slope....
14:22:14  <planetmaker> w/o bulk/piece/liquid consideration at all
14:22:40  <andythenorth> is refrigerate a core class then?
14:23:27  <planetmaker> no
14:24:11  <andythenorth> hmm
14:24:11  <planetmaker> if you want to use it as inclusion criterion one would have to create a class "non-refrigerate"
14:24:21  <andythenorth> well removing the 'extra' classes was an appealing idea :P
14:28:50  <Belugas> hello
14:31:31  <planetmaker> andythenorth, I guess we can remove 'hazard'
14:31:49  <planetmaker> and join neo-bulk / over-sized. And remove clean
14:31:56  <planetmaker> then it's quite clean again ;-)
14:36:27  <z-MaTRiX> hi
14:36:27  <z-MaTRiX> :)
14:45:04  <andythenorth> planetmaker: I am suspicious about covered
14:45:24  <andythenorth> if I was coding a train set, I would set covered on vans, flat cars and open wagons
14:45:32  <andythenorth> thereby negating it
14:45:32  <andythenorth> :P
14:46:04  *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd
14:46:40  <planetmaker> it has the same issue as refrigerated.
14:47:03  <planetmaker> it'd be more useful if it was either used as 'and'
14:47:42  <andythenorth> if I have ice to hand, I can refrigerate anything?
14:47:43  <andythenorth> :P
14:53:25  *** Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has joined #openttd
15:00:12  <CIA-6> OpenTTD: yexo * r23131 /trunk/src/ai/api/ai_order.cpp: -Fix (r16165): AIOrder::IsCurrentOrderPartOfOrderList return false for valid vehicles and crashed for invalid ones
15:01:04  <frosch123> "covered" is meant for the EXCLUDE-mask
15:02:07  <frosch123> bulk, piecegoods and liquid are basically INCLUDE-only, everything starting from refridgerated is EXCLUDE-only
15:02:12  <andythenorth> I know
15:02:18  <andythenorth> but let's get rid of some :P
15:02:24  <frosch123> the first four can be used in both INCLUDE and EXCLUDE
15:02:37  <planetmaker> mail? :-P
15:02:37  <andythenorth> if they're used in EXCLUDE the world ends
15:03:13  <frosch123> planetmaker: ttd mail is a special ttd cargo, not related to any rl cargo
15:05:14  <planetmaker> sadly. yes
15:05:27  <andythenorth> I don't understand why covered is ok, but neo-bulk adds inumerable, intolerable complexity :P
15:06:00  <planetmaker> you really don't know?
15:06:50  <Terkhen> it feels duplicated :P
15:07:35  <andythenorth> for the purpose I intend it, is neo-bulk simply the inverse of covered?
15:07:45  <andythenorth> no
15:07:50  <planetmaker> no
15:07:52  <andythenorth> the inverse of covered is not covered :P
15:07:59  <planetmaker> it's about the similar to over-sized
15:08:23  <planetmaker> neo-bulk just means it's not-palettizable piece cargo
15:08:35  <planetmaker> possibly with unhandy dimensions
15:08:40  <andythenorth> yup
15:08:45  <planetmaker> (though in my understanding not necessarily unhandy)
15:08:59  <planetmaker> mail bags iirc are also neo-bulk ;-)
15:09:09  <planetmaker> but I might have mis-understood that
15:09:12  <andythenorth> maybe
15:09:18  <andythenorth> the term seems to be loosely defined
15:09:31  <andythenorth> a better term might be "doesn't fit through doors nicely"
15:09:58  <CIA-6> OpenTTD: yexo * r23132 /trunk/src/osk_gui.cpp: -Fix: when any keys on te on-screen keyboard were pressed the text cursor disappeared
15:10:29  <andythenorth> planetmaker: as far as I am concerned, we could consolidate neo-bulk and oversized to one class....then remove it :P
15:10:49  <andythenorth> the help I am trying to provide to vehicle sets is better forgotten about
15:10:52  <andythenorth> use labels
15:11:49  <planetmaker> I wonder whether I should update the NewGRF wiki ;-)
15:12:10  * andythenorth has an idea
15:12:14  <planetmaker> probably I should leave this to you :-P
15:12:14  <andythenorth> make prop 28 a byte
15:12:41  <andythenorth> or maybe a word
15:12:45  <andythenorth> \o/
15:12:48  <planetmaker> it is a word...
15:12:52  <planetmaker> or which?
15:12:56  <planetmaker> feature
15:12:59  <andythenorth> train prop 28?
15:13:04  <andythenorth> sorry
15:13:55  <andythenorth> is it word sized right now?
15:14:16  <andythenorth> anyway, make it a byte :D
15:14:30  <andythenorth> everything above 'refrigerated' gets deprecated
15:14:36  <andythenorth> remove prop 29
15:14:45  <andythenorth> everyone wins
15:14:46  *** TWerkhoven2 [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd
15:15:47  <frosch123> hmm, so "express" means stuff that shall be transported with high-speed trains
15:16:03  <frosch123> so, it would be an INCLUDE-mask thingie
15:17:21  <planetmaker> it'd be 'exclude' with the same reasoning
15:17:26  <Yexo> but a wagon doesn't decide whether or not it can be attached to a high-speed engine
15:17:43  <planetmaker> but it has a speed limit (sometimes)
15:17:55  <frosch123> the engine decides about attaching anyway
15:17:57  <planetmaker> except for all those which play without :-)
15:18:02  <frosch123> and start/stop
15:18:05  <Yexo> that means a wagon with high speed limit would include express, but you could still attach it to a slow engine
15:18:23  <planetmaker> snail express :-)
15:18:27  <frosch123> Yexo: i was refering to the german discussion of patchman and mb from 2005
15:18:47  <frosch123> where patchman says, express it the stuff that is transportable using maglev
15:19:00  <Yexo> aha
15:19:08  <Yexo> well, imo express makes no sense in that was as cargoclass
15:19:16  <Eddi|zuHause> "express" is a flawed concept
15:19:20  <andythenorth> it makes no sense
15:19:27  <andythenorth> it has the benefit of usefulness though
15:19:41  <andythenorth> sense might be orthogonal to utility
15:19:46  <Eddi|zuHause> add those cargos to "mail" isntead
15:20:39  <andythenorth> the downside of removing express is that it works
15:20:49  <andythenorth> it's conceptually all wrong
15:21:01  <andythenorth> but if you want milk on fast passenger trains it provides that easily
15:21:32  <andythenorth> is there another way that could be achieved?
15:21:38  *** TWerkhoven [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Ping timeout: 480 seconds]
15:21:52  <andythenorth> ...labels?
15:22:15  *** MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has quit [Remote host closed the connection]
15:24:16  <andythenorth> what's the point of armoured?
15:24:19  <Eddi|zuHause> how is "Wood Products" "bulk"?
15:24:26  <andythenorth> wood chips
15:24:38  <Eddi|zuHause> andythenorth: that makes no sense...
15:24:39  <andythenorth> I have a long pm discussion with MB about it if you would like a copy
15:24:48  <andythenorth> it makes complete sense
15:24:50  <andythenorth> wood chips are bulk
15:25:04  <andythenorth> and he can send you pictures of them being transported as such if that helps
15:25:18  <andythenorth> why doesn't it make sense? :)
15:25:29  <andythenorth> it certainly makes FIRS lumber a bit...odd
15:25:29  <Eddi|zuHause> it doesn't make sense as an ingame cargo...
15:25:42  <planetmaker> why not?
15:25:53  <andythenorth> I actually convinced myself it works
15:26:19  <andythenorth> Eddi|zuHause: what's troubling about it?
15:26:25  <andythenorth> wood products can be bulk
15:26:31  * andythenorth is asking genuinely
15:26:34  <andythenorth> not for argument
15:26:42  <andythenorth> sawdust can be poured
15:26:45  <andythenorth> wood chips can be poured
15:27:51  <Eddi|zuHause> andythenorth: but it has nothing to do with "Lumber"
15:28:18  <frosch123> andythenorth: "armoured" are those classical western wagons with soldiers on them
15:28:40  <frosch123> i.e. they are closed wagons with whatever in them
15:29:05  <frosch123> a flat bed wagon in front and behind with one machine gun each
15:29:13  <frosch123> and a flat bed wagon at the end with a cannon
15:29:14  <andythenorth> Eddi|zuHause: again that's due to a mistake when coding FIRS
15:29:23  <Eddi|zuHause> andythenorth: basically it's something related to the discussion on why "FMSP" shouldn't be both "fertilizer" and "machines"
15:29:29  <andythenorth> (a) lumber is a highly confusing term, it varies depending which continent you're on
15:29:40  <andythenorth> (b) we made the mistake of trying to reuse an existing ECS class
15:30:01  <andythenorth> class / label /s
15:30:28  <andythenorth> trying to reuse labels with no attention to wether they mean similar things in game is unhelpful
15:30:36  <andythenorth> it's a bad pattern
15:30:58  <andythenorth> it nominally gains cargo sprite support faster, except that support could well be wrong
15:31:30  <andythenorth> it looks like it gains vehicle refit support faster, but that's a fallacy, and shows a fatal misunderstanding of what classes are for
15:31:41  <andythenorth> so basically we messed up
15:32:29  <andythenorth> and yes, the conceptual cargo Wood Products (WDPR) has nothing to do with FIRS intention of Lumber, which is basically treated dimensional lumber for making things from
15:35:35  <andythenorth> frosch123: if I add 'soldiers' cargo, can they go in 'armoured' ?
15:35:57  <andythenorth> I guess armoured has to stay, but it's *so* niche...
15:36:21  <frosch123> andythenorth: i think most sets transport mail and armored in the same vans
15:36:58  *** Devroush [~dennis@ip-213-49-111-51.dsl.scarlet.be] has quit [Ping timeout: 480 seconds]
15:37:09  <andythenorth> but if I want to add a future cargo which needs armoured wagons, I should be able to?
15:37:16  <andythenorth> uranium?
15:37:20  <andythenorth> banknotes?
15:37:26  <andythenorth> prisoners?
15:37:30  <andythenorth> meh
15:37:44  <andythenorth> seems like a waste of a bit, but we're stuck eating hysterical raisins
15:38:03  <andythenorth> why does Mail get a class?
15:38:38  * andythenorth considers a new industry set: '1st class mail' '2nd class mail' 'parcels' 'airmail'
15:38:45  <andythenorth> main industry: post office
15:39:37  <planetmaker> called ecs houses?
15:39:42  <frosch123> passengers and special are built-in cargoclasses with speic
15:39:49  <frosch123> speical implementations
15:39:59  <frosch123> Eddi|zuHause: as such "special" cannot be deprecated
15:40:12  <frosch123> cargos with class "special" are hidden from the gui in certain parts
15:40:18  <Eddi|zuHause> hm, ok
15:40:37  <andythenorth> frosch123: can a vehicle ever refit to special?
15:40:40  <andythenorth> I guess
15:40:42  <andythenorth> regearing
15:40:52  <z-MaTRiX> ahaha
15:40:53  <z-MaTRiX> http://www.raspberrypi.org/
15:41:05  <z-MaTRiX> These boards use an Atmel ATmega644 microcontroller clocked at 22.1MHz, and a 512K SRAM for data and framebuffer storage.
15:41:08  <andythenorth> a better question would be, is 'special' valid for a prop 28 or 29 refit mask
15:41:11  *** Devroush [~dennis@ip-213-49-91-174.dsl.scarlet.be] has joined #openttd
15:41:36  <andythenorth> I know that pikka thinks regearing was not his finest idea anyway
15:42:00  <frosch123> CC_MAIL is also special, as in passenger and mail are always the first cargos in a list
15:42:29  <Eddi|zuHause> frosch123: so what happens if multiple cargos are in CC_MAIL?
15:42:31  <planetmaker> have to be?
15:42:51  <CIA-6> OpenTTD: yexo * r23133 /trunk/src/ai/api/ai_order.cpp: -Fix [FS#4823]: AIOrder didn't handle implicit orders correctly in all cases
15:42:53  <planetmaker> what is, if there's no passengers?
15:42:53  *** Celestar [~dax@89.204.137.80] has quit [Ping timeout: 480 seconds]
15:42:56  <frosch123> Eddi|zuHause: they are sorted by name
15:42:58  <frosch123> like the rest
15:43:04  <planetmaker> k :-)
15:43:12  * planetmaker thinks of a Cylon economy
15:43:12  <frosch123> planetmaker: there are no busses :p
15:43:24  <z-MaTRiX> it does 3d video at 22MHZ
15:43:56  * andythenorth wants to kill all the classes :D
15:44:05  <andythenorth> this however gains not much
15:44:06  <frosch123> oh, crap
15:44:10  <CIA-6> OpenTTD: yexo * r23134 /trunk/src/ai/ (5 files in 2 dirs): -Add [FS#3799]: [NoAI] AICargoList_StationAccepting
15:44:22  <planetmaker> hm, frosch123 ?
15:44:31  <frosch123> industries producing CC_MAIL are excluded for naming nearby stations "mine"
15:44:41  <andythenorth> how esoteric
15:45:00  <planetmaker> err... *that is peculiar*
15:45:02  <andythenorth> are they allowed to name it "yours"
15:45:29  <frosch123> i guess i should add a list of "coded usages" of the classes to the thread
15:45:38  <andythenorth> yes
15:45:40  <andythenorth> that would help
15:45:55  <andythenorth> especially if it turns out someone can devise a new better alternative to classes
15:46:01  <andythenorth> then we see what legacy crap exists
15:46:10  <andythenorth> although /me prefers to refine classes
15:46:23  <andythenorth> refine => remove, clarify
15:46:45  <andythenorth> frosch123: the 'clean is a special flag' route might be appealing
15:49:23  <peter1138> CC_MAIL or CT_MAIL?
15:50:36  <frosch123> CC_MAIL
15:50:52  <frosch123> i am grepping for \<CC_
15:51:01  <frosch123> and try to ignore console colors :p
15:51:15  <peter1138> yeah i spotted that earlier, hehe
15:51:23  <peter1138> SCC too
15:52:49  <CIA-6> OpenTTD: yexo * r23135 /trunk/src/ai/api/ai_order.cpp: -Fix (r23133): always compile before commit
15:54:37  <Eddi|zuHause> did the forum just die or is that me?
15:55:27  <peter1138> it's you
15:56:19  <Eddi|zuHause> http://www.tt-forums.net/viewtopic.php?p=979268#p979268 <-- lengthy proposal
15:57:25  <planetmaker> can't you just keep it in sensible words than illegible UIC letters?
15:57:47  <Eddi|zuHause> planetmaker: i defined all abbreviations...
15:58:00  <Eddi|zuHause> planetmaker: or shall i go mad during copy-pasting lengthy words?
15:58:34  <planetmaker> yes
15:58:41  <planetmaker> the letters don't add to anything
15:58:58  <planetmaker> and make it totally unreadable, if one doesn't either know them or wants to memorize every letter.
15:59:03  <planetmaker> Which do not even follow a pattern
15:59:13  <planetmaker> (except being cryptic UIC letters)
15:59:50  <planetmaker> i.e. using the letters is IMHO quite the wrong thing to do
15:59:53  <Eddi|zuHause> G - GÃŒterwagen, Z - Zisternenwagen
16:00:33  <Eddi|zuHause> the older DB/DRG classification may have more "sensible" abbreviations
16:00:45  <Eddi|zuHause> e.g. "O" instead of "E"
16:00:47  <planetmaker> if you want to explain: don't use abbreviations
16:01:05  <Eddi|zuHause> but i'm really not understanding your criticism
16:02:16  <planetmaker> you're introducing a chain of abbreviations which do not relate at all to what they abbreviate
16:03:57  <Eddi|zuHause> it's a set of abbreviations that has been used in that same thread very often...
16:04:03  <planetmaker> and re-defining classes without really much need. The only new thing is the "pourable"
16:04:15  <planetmaker> by one person. Or two
16:05:05  <planetmaker> anyway, independent of that: that system is only slightly different from what we have for classes
16:05:16  <planetmaker> That doesn't warrant a change there
16:05:25  <Eddi|zuHause> yes, that was the point, keep as much of the current system as possible
16:05:50  <planetmaker> Keep the complete class system as is. Maybe remove hazard and replace by pour
16:06:06  <planetmaker> then everything is safe wrt past newgrfs
16:06:35  <planetmaker> the only thing which really makes sense to redefine in that context is the assignment of classes to labels
16:07:00  <Eddi|zuHause> "deprecating the express and armored class" is more of a suggestion for new GRFs
16:07:16  <planetmaker> which - as we saw - is possibly done better by inventing new labels
16:07:58  *** hanf [~Klaus@host-89-242-66-98.as13285.net] has quit [Read error: Connection reset by peer]
16:08:22  <andythenorth> Eddi|zuHause: you think FMSP should be split for transport reasons? :)
16:08:34  <Eddi|zuHause> andythenorth: yes
16:08:52  <andythenorth> feel free to rework the chains to suit ;)
16:09:09  <andythenorth> and explain to users which cargos are needed at farms, and in which combinations
16:09:22  <andythenorth> ENSP should also be split
16:09:25  * peter1138 bops andythenorth over the head with fleetwood mac
16:10:12  <Eddi|zuHause> andythenorth: add MCHN cargo, transport FERT and MCHN to farms, transport BDMT and MCHN to mines?
16:10:30  <planetmaker> that's then two cargos for mines...
16:11:35  <Eddi|zuHause> need someone capable of operative decisions: remove those unused URAN etc. cargos that "someone" added, and nobody actually knows who that was
16:13:24  <TGYoshi> This talk sounds complicated.
16:13:50  <andythenorth> Eddi|zuHause: combine FERT and FUEL to make EXPL
16:13:56  <andythenorth> transport those to mines too
16:14:15  <Eddi|zuHause> that sounds overcomplicated
16:14:24  <Eddi|zuHause> make refinery produce BDMT?
16:14:35  <andythenorth> if you're transporting machines you also need to transport PETR or FUEL
16:14:43  <andythenorth> and PART
16:14:45  <andythenorth> and TYRE
16:15:18  <Eddi|zuHause> refinery: BDMT (explosives), lumber yard: BDMT (lumber), cement plant: BDMT (cement), glass works: BDMT (glass)
16:15:57  <Eddi|zuHause> brick works: BDMT (bricks)
16:16:14  <andythenorth> BDMT should properly be split
16:16:26  <Eddi|zuHause> you have a 32 cargo limits
16:16:28  <andythenorth> powered cement is a bulk cargo needing moisture protection
16:18:33  <peter1138> so
16:18:48  <peter1138> either forget about that
16:19:01  <peter1138> or give it no classes and make a special vehicle set :p
16:19:59  <andythenorth> raise the cargo limit :P
16:21:49  <andythenorth> 256 should be enough
16:21:57  <andythenorth> and industry sets should provide vehicles
16:22:07  * andythenorth needs a prefix for '/me is now trolling'
16:22:08  <Eddi|zuHause> FIRS has already very many cargos. should actually try to reduce it
16:22:26  <michi_cc> Eddi|zuHause: s/uint32/uint64/ in the proper places takes care of that :)
16:22:33  <andythenorth> Eddi|zuHause: I think that's reduced as far as it can go
16:22:39  <andythenorth> I've had that discussion enough times now
16:23:02  <andythenorth> if I start it again, planetmaker will abandon contributing, then I'll be left on my own, unable to read/write nml
16:23:08  <andythenorth> ;)
16:23:29  <andythenorth> also - the bunfight about FMSP is nothing to do with classes, so maybe we park it for now?
16:23:34  <andythenorth> I was trolling a bit :P
16:23:59  <Eddi|zuHause> yes
16:24:36  <andythenorth> FIRS economies are the proper solution to 'fewer cargos please'
16:27:06  <planetmaker> so... CARB (carbon bricks), DURA (depleted uranium), MATE (materials), WATT (electricity), UORE (uranium ore), URAN (uranium), SILI (silicate), RCKT (rockets), OXYG (oxygen) can all go, I guess. I've seen them nowhere nor is their origin clear.
16:28:57  *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has joined #openttd
16:29:07  <Eddi|zuHause> maybe it's from that SirXavius guy with the OTTD
16:29:14  <Eddi|zuHause> OTTD+500 project?
16:30:37  <planetmaker> anyway. Removed. History still has them, if needed
16:31:37  <Eddi|zuHause> TWOD was another cargo that didn't have any information which set includes it
16:32:20  <planetmaker> iirc it once was ECS?
16:32:31  <Eddi|zuHause> possibly
16:35:16  <peter1138> george thought TWOD was a default one
16:35:25  <peter1138> or something like that?
16:37:22  <TrueBrain> pff, video website are lying to me! It started with: This ad will run for 30 seconds. Then I clicked a button. It doesn't run for 30 seconds. It stopped. There and then.
16:37:26  <planetmaker> something like that is what I recall, too
16:37:28  * TrueBrain blacklists another video website ...
16:43:17  *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has quit [Remote host closed the connection]
16:44:08  <frosch123> TWOD was listed as default cargo for several years
16:44:34  <frosch123> and various people were surprised that it did not appear in TTDP or OTTD
16:44:34  <Eddi|zuHause> i presume COPR as well?
16:44:58  <frosch123> CORE is default afaik
16:45:24  <frosch123> COPR was in some set somewhen, maybe FIRS?
16:45:27  <Eddi|zuHause> yes, but COPR is listed further down
16:45:49  <planetmaker> tropical climate is CORE. I don't know about COPR. iirc pikka had something with it?
16:46:27  <frosch123> i remember pikka argueing with someone, why he did not use CORE, but added COPR. But the other guy meant it as not copper ore, but (pure) copper
16:47:03  <planetmaker> that was my understanding of COPR, too. But I don't really know where (or whether) it's used
16:47:04  <frosch123> http://www.tt-forums.net/viewtopic.php?p=979274#p979274 <- anyway, your list
16:50:02  *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has joined #openttd
16:55:44  <andythenorth> planetmaker: lots of those space cargos are awaiting Pikka's April 1st set
16:55:49  <andythenorth> I think
16:55:58  <andythenorth> maybe not though, he was keeping it secret
16:56:01  <andythenorth> maybe they're easter eggs
16:56:13  <andythenorth> twod is tropical wood yes / no?
16:56:19  <andythenorth> stupid label :P
16:56:19  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Remote host closed the connection]
16:56:35  <andythenorth> it has a different weight per unit or such I think? I read the code for it once
16:57:00  <andythenorth> or I was smoking crack
16:57:07  <frosch123> twod is armoured, so it does get stolen :p
16:57:26  <andythenorth> nice list
16:58:28  <frosch123> (/me played a rpg once, where a friend thought that a heavy oak door would be very valueable, and that his character shall carry it out of the dungeon to sell it :p )
16:58:33  *** Eddi|zuHause [~johekr@p54B73A26.dip.t-dialin.net] has quit [Remote host closed the connection]
16:58:48  *** Eddi|zuHause [~johekr@p54B73A26.dip.t-dialin.net] has joined #openttd
16:59:02  <planetmaker> yes, TWOD is. But those labels are there in the webpage since r0
16:59:06  <planetmaker> So... not sure :-)
16:59:24  <andythenorth> I support it in FISH and HEQS
16:59:25  <andythenorth> :P
16:59:34  <andythenorth> I think
16:59:40  <planetmaker> If I removed a cargo which is going to be used... Well. Wikis luckily have history
16:59:57  <frosch123> planetmaker: i guess it was indeed proposed as default cargo, but somehow did not make it into the ttdp code
17:00:04  <planetmaker> I also added a note to state where that cargo label is to be used ;-)
17:00:12  <planetmaker> frosch123, TWOD?
17:00:13  <frosch123> anyway, why do you want to remove labels from the wiki?
17:00:18  <frosch123> i see no use in that
17:00:36  <planetmaker> long list of pointless labels?
17:00:36  * andythenorth wants to remove *classes* from the list of labels on the wiki
17:00:50  <andythenorth> the classes of a cargo are of *no* concern to vehicle authors
17:01:05  *** Prof_Frink [~proffrink@5e0a9627.bb.sky.com] has joined #openttd
17:01:05  <frosch123> except for the xor mask
17:01:13  <andythenorth> bloody mask :P
17:01:19  <Belugas> 12:00h!  LUNCH HOUR!!!!!
17:01:21  <frosch123> and also the refit cb
17:01:27  <TrueBrain> I am having dinner ...
17:01:32  <Belugas> andythenorth, Halloween is over , remove that mask...
17:01:34  <frosch123> since you likely do not want to use all labels always
17:01:38  <andythenorth> frosch123: not in the refit cb
17:01:45  <planetmaker> andythenorth, sure
17:01:49  <andythenorth> if you want to support specific cargos, use a label
17:01:50  <planetmaker> classes are available there
17:01:50  <Belugas> enjoy TrueBrain :)
17:01:55  * andythenorth is being black and white
17:01:56  <frosch123> planetmaker: labels are never pointless
17:02:14  <andythenorth> if you want to use classes to support a specific cargo You Are Doing It Wrong
17:02:42  <andythenorth> very wrong
17:02:49  <planetmaker> frosch123, but they should state where they are used / come from
17:03:02  <frosch123> andythenorth: so you want to check every vehicle in game with every industry set, to see if you need to add some other cargo manually? :p
17:03:13  <andythenorth> no
17:03:23  <andythenorth> you just set the classes on your vehicles correctly
17:03:26  <andythenorth> that's it
17:03:30  <andythenorth> that's what classes are for
17:03:35  * andythenorth is being black and white :P
17:03:43  *** HerzogDeXtEr [~Flex@i59F6ACB6.versanet.de] has joined #openttd
17:04:05  <andythenorth> if you care which vehicles coal, or pigs, or string go in, use their labels
17:04:08  <andythenorth> otherwise don't care
17:04:19  <andythenorth> this is the mistake we haz been making at some points
17:05:07  <andythenorth> classes make no guarantee of appropriate vehicles, just that there's a chance the player will be able to transport unknown cargos
17:06:08  * andythenorth doubts this will ever actually be the case
17:06:28  *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
17:06:29  <andythenorth> real world, we'll continue using classes as a shortcut
17:06:43  <andythenorth> why set coal, iore, core, etc
17:06:45  <andythenorth> just set bulk :P
17:06:53  <planetmaker> frosch123, while I agree in principle with "labels are never pointless", those which I removed have never nor are being used in any NewGRF I saw. And they've been there for ages
17:07:14  <frosch123> so, you checked all vehicle grfs?
17:07:34  <planetmaker> No, I didn't. But the cargos have to be supplied by something
17:07:45  <andythenorth> let's just remove some at random occasionally :)
17:08:02  <planetmaker> And those is much easier to check :-)
17:09:37  <frosch123> andythenorth: also the list of classes is to supply examples
17:09:47  <andythenorth> yes
17:09:54  <andythenorth> it helps cargo set authors
17:09:56  <andythenorth> I accept that
17:10:11  <andythenorth> and it guides vehicle set authors as to actual use of classes - in general
17:10:21  <andythenorth> I just think it's part of the problme
17:10:29  <andythenorth> porblem?
17:10:32  <andythenorth> problem
17:11:39  <Eddi|zuHause> next step would be to split the table into "these cargos are currently in use" and "there cargos have been deprecated because of <reason>"
17:11:51  <andythenorth> not a bad move
17:11:58  <planetmaker> go for it :-)
17:12:27  <planetmaker> andythenorth, the classes of a cargo always have to be part of that table.
17:12:32  <andythenorth> I know :(
17:12:41  <planetmaker> Even when they were used totally independent in refit algorithm
17:13:07  <planetmaker> as it's pointless to specifically support a cargo when you already have it catered for via classes. And when you transport containers only anyway
17:13:10  <andythenorth> but you see that they don't help the decoupling?
17:13:42  <andythenorth> 'when you have already catered for it via classes' <- but then classes may not be changed later as it 'breaks' sets
17:13:46  <planetmaker> it does neither. couple nor de-couple. It's simply specs for that particular cargo
17:13:52  <andythenorth> specs can change
17:14:12  <andythenorth> the sets don't "break", but the perception is they do
17:14:15  <planetmaker> "specs can change" is something usually not done with newgrfs ;-)
17:14:16  <Yexo> specs can't change without breaking backwards compatiblity
17:14:26  <planetmaker> "specs can be extended" - yes. That's different though
17:16:13  <andythenorth> I accept that XOR means classes can't change
17:16:31  <andythenorth> if that didn't exist
17:16:35  <andythenorth> specs should be able to change
17:16:51  <andythenorth> a set that is 'broken' due to a change of class on a cargo is not in fact 'broken'
17:16:55  <andythenorth> it's working perfectly as intended
17:17:15  <andythenorth> (assuming no XOR sadness)
17:17:32  <Yexo> I think you're right. Unfortunately we do have that "XOR adness" and we can't simply remove that
17:17:36  <andythenorth> yup
17:17:40  <andythenorth> it's just hot air in that respect
17:17:48  <andythenorth> so the correct answer is to change labels, not classes
17:18:01  <andythenorth> thereby *really* annoying authors who have added label based support
17:18:15  <planetmaker> we could add two new properties, though... "transport-by-label" and "never-transport-by-label". Or similar
17:18:29  *** sla_ro|master [~slaco@95.76.27.160] has joined #openttd
17:18:34  <frosch123> speaking of mess... does firs now use SCRP or SCMT ?
17:18:40  <andythenorth> SCMT
17:18:45  <frosch123> and are the classes acutally correct on the wiki?
17:18:46  <planetmaker> I still would advocate to revert to SCRP
17:18:54  <planetmaker> and just change the class :-P
17:18:54  <andythenorth> the classes are currently correct
17:18:56  <andythenorth> they were incorrect
17:19:05  <andythenorth> SCRP was described as bulk, but was piece
17:19:06  *** pugi [~pugi@host-091-097-041-253.ewe-ip-backbone.de] has joined #openttd
17:20:02  <andythenorth> planetmaker: can we or can't we change classes?  I am a small amount confused :O
17:20:39  <andythenorth> FIRS labels + classes should never have been in that wiki  :x
17:20:55  <andythenorth> I explicitly put them on my site with a big health warning
17:21:07  <andythenorth> and said that the code was the only canonical place during development
17:21:17  <andythenorth> then they were added to the wiki not by me
17:21:19  <andythenorth> :|
17:21:21  <Yexo> andythenorth: putting it on your site instead of in the specs doesn't change a thing
17:21:30  <frosch123> discussion will be interupted for while
17:21:35  <Yexo> it probably only means even less support from vehicle set authors
17:21:39  <CIA-6> OpenTTD: frosch * r23136 /trunk/src/ (newgrf.cpp newgrf_spritegroup.cpp newgrf_spritegroup.h): -Change: [NewGRF v8] Deprecate old-style callback results 0xFF??.
17:21:54  <andythenorth> Yexo: that's not a bad thing when it is < 1.0
17:21:59  *** Celestar [~dax@82.113.99.44] has joined #openttd
17:22:06  <CIA-6> OpenTTD: frosch * r23137 /trunk/src/ (articulated_vehicles.cpp newgrf_callbacks.h): -Change: [NewGRF v8] New result format for callback 16.
17:22:15  <andythenorth> right now I get 10 kinds of trouble every time that gameplay shows a cargo needs adjusting
17:22:22  <Yexo> andythenorth: given the amount of users you ahve you can hardly call your current releases "development versions"
17:22:45  <andythenorth> we don't know how many users there are :)
17:22:47  <CIA-6> OpenTTD: frosch * r23138 /trunk/src/ (18 files): -Feature: [NewGRF] Allow passing 32bit parameters to 60+x variables (using var 7B). Currently most useful for vehicle var 60.
17:22:50  <andythenorth> there could be lots of downloads and no users
17:23:18  <CIA-6> OpenTTD: frosch * r23139 /trunk/src/newgrf.cpp: -Change: [NewGRF v8] Do no longer apply base cost fallbacks.
17:23:34  <CIA-6> OpenTTD: frosch * r23140 /trunk/src/ (4 files in 2 dirs): -Add: ErrorUnknownCallbackResult()
17:23:48  <CIA-6> OpenTTD: frosch * r23141 /trunk/src/ (newgrf_station.cpp object_cmd.cpp): -Change: [NewGRF v8] Invert result bit 10 of callbacks 149 and 157 to make them consistent with other slope check callbacks. (michi_cc)
17:24:00  <CIA-6> OpenTTD: frosch * r23142 /trunk/src/ (9 files): -Change: [NewGRF v8] Unify the return values of callbacks returning D0xx texts.
17:24:53  <CIA-6> OpenTTD: frosch * r23143 /trunk/src/newgrf_engine.cpp: -Change: [NewGRF v8] Return the translated cargobit in vehicle var 42.
17:25:01  <CIA-6> OpenTTD: frosch * r23144 /trunk/src/newgrf.cpp: -Change: [NewGRF v8] Consider the 'default cargotype' properties as indices into the cargo translation table.
17:25:17  <CIA-6> OpenTTD: frosch * r23145 /trunk/src/newgrf.cpp: -Change: [NewGRF v8] Determine the 'first' refittable cargo of vehicles using the cargo ordering from the cargo translation table.
17:25:29  <CIA-6> OpenTTD: frosch * r23146 /trunk/src/ (7 files in 3 dirs): -Change: [NewGRF v8] Make callback 22 return a probability to use instead of property 18.
17:26:07  <CIA-6> OpenTTD: frosch * r23147 /trunk/src/ (11 files): -Change: [NewGRF v8] Unify the return values of boolean callbacks, and check the results for validity.
17:26:31  <CIA-6> OpenTTD: frosch * r23148 /trunk/src/ (8 files): -Change: [NewGRF] Check the results of various callbacks for validness.
17:27:06  <CIA-6> OpenTTD: frosch * r23149 /trunk/src/ (engine_type.h newgrf.cpp roadveh_cmd.cpp table/engines.h): -Add: [NewGRF] Road vehicle property 23 to shorten vehicles without callback usage.
17:27:12  <CIA-6> OpenTTD: frosch * r23150 /trunk/src/ (newgrf.cpp newgrf_properties.h roadveh_cmd.cpp train_cmd.cpp): -Change: [NewGRF v8] Deprecate callback 11, and use callback 36 instead.
17:27:22  <CIA-6> OpenTTD: frosch * r23151 /trunk/src/ (economy.cpp newgrf.cpp newgrf_properties.h): -Change: [NewGRF v8] Deprecate callback 12, and use callback 36 instead.
17:27:59  <CIA-6> OpenTTD: frosch * r23152 /trunk/src/newgrf.cpp: -Change: [NewGRF v8] Snow line height table uses values between 0x00 and 0xFF independent of number of height levels.
17:28:08  <CIA-6> OpenTTD: frosch * r23153 /trunk/src/ (newgrf.cpp newgrf.h newgrf_spritegroup.cpp): -Change: [NewGRF v8] Use heightlevel units in variable 20/A0.
17:28:18  <CIA-6> OpenTTD: frosch * r23154 /trunk/src/ (9 files): -Change: [NewGRF v8] Use heightlevel units in nearby tile info variables. (rubidium)
17:28:28  <CIA-6> OpenTTD: frosch * r23155 /trunk/src/newgrf_industries.cpp: -Change: [NewGRF v8] Use heightlevel units in var 8A of callback 28.
17:28:38  <CIA-6> OpenTTD: frosch * r23156 /trunk/src/newgrf_engine.cpp: -Change: [NewGRF] Clamp height in aircraft variable 44.
17:28:49  <CIA-6> OpenTTD: frosch * r23157 /trunk/src/newgrf_generic.cpp: -Change: [NewGRF v8] Format of extra callback info for callback 144. (michi_cc)
17:28:57  <CIA-6> OpenTTD: frosch * r23158 /trunk/src/newgrf.cpp: -Feature: [NewGRF] Patch/setting variable 14. (rubidium)
17:29:35  <CIA-6> OpenTTD: frosch * r23159 /trunk/src/newgrf.cpp: -Feature: Support for NewGRF version 8.
17:29:46  <frosch123> discussion can continue :p
17:29:54  *** Celestar [~dax@82.113.99.44] has quit [Read error: Connection reset by peer]
17:33:26  <Eddi|zuHause> frosch123: any chance of slipping in a commit that splits the refit mask into two? (removing the weird XOR behaviour)
17:34:00  <Eddi|zuHause> (probably unnecessary, though)
17:34:05  <frosch123> No, the next thing will be a callback
17:36:49  <CIA-6> OpenTTD: yexo * r23160 /trunk/src/ (10 files): -Fix: wrong comments in a lot of TileTypeProcs definitions
17:40:05  <CIA-6> OpenTTD: yexo * r23161 /trunk/src/newgrf_airporttiles.cpp: -Fix (r23154): don't convert pointer to bool but actually check the grf_version variable
17:40:46  <Eddi|zuHause> http://newgrf-specs.tt-wiki.net/wiki/CargoTypes#Cargo_Labels <-- i hereby officially deprecated the "GEAR" cargo :)
17:41:51  <CIA-6> OpenTTD: frosch * r23162 /trunk/src/ai/api/ai_order.cpp: -Fix (r23133): Silence gcc warning.
17:43:19  <frosch123> sorry, but what's all this deprecated fuzz about if noone sayd till now how to keep compatibility?
17:43:48  <frosch123> GEAR is used in several sets of pikka
17:43:48  <Eddi|zuHause> frosch123: i mean that as "these cargos are not used in any industry set"
17:44:46  <Eddi|zuHause> frosch123: sure, but a wiki like this should reflect the "state of the art" technology, not some previous failed attempts
17:45:18  <frosch123> GEAR is state of the art
17:46:06  <andythenorth> how will Pikka provide regearing without a cargo to store the value in?
17:46:09  <frosch123> imo a list of "deprecated" label is nonsense
17:46:12  <andythenorth> it's not deprecated by Pikka
17:46:25  <frosch123> labels are not used exclusively by a single set
17:46:34  <andythenorth> it can only be deprecated in the context of a specific set, not everywhere
17:46:39  <frosch123> they are defined forever
17:46:58  <andythenorth> that's why I left SCRP in, but marked is as deprecated in FIRS :D
17:47:04  <Eddi|zuHause> frosch123: i think of that list like "do not use these labels in a new set unless you have a good reason. these are listed only for backwards compatibility"
17:47:18  <andythenorth> Might be a better header for it
17:47:26  <frosch123> "do not use these labels in a new set" is nonsense
17:47:28  <andythenorth> I have no objection to splitting the list in principle
17:47:39  <frosch123> why should an industry set only use defined cargos?
17:47:54  <frosch123> if a industry set wants special tropic wood, why not?
17:48:22  <andythenorth> it's fun that such a simple system can cause all of us so much headache :)
17:48:35  *** pjpe [ae5b514a@ircip1.mibbit.com] has joined #openttd
17:50:45  <CIA-6> OpenTTD: yexo * r23163 /trunk/src/rail_cmd.cpp: -Fix [FS#4627]: don't display railway fences between track and waypoints (Krille)
17:50:56  <frosch123> maybe we should protect the cargo page from edits for one month :p
17:51:14  *** |Jeroen| [~jeroen@d5152B25B.access.telenet.be] has joined #openttd
17:51:27  <andythenorth> it's always best to have a wiki war to refine a spec no?
17:51:28  <andythenorth> :P
17:51:40  <Eddi|zuHause> Yexo: breaking my fences patch?
17:52:04  <Yexo> could be
17:52:13  <andythenorth> so
17:52:23  <Eddi|zuHause> frosch123: i have not changed any actual information. just reordered the table.
17:52:35  <andythenorth> in the wiki table of cargo labels - even if we have the classes, do we need the actual mask there?
17:53:15  <andythenorth> you don't think "I want to add coal so I need to set the refit mask to *coal's classes*"
17:54:06  <andythenorth> you should think "is my vehicle for bulk cargos"
17:55:07  <Eddi|zuHause> andythenorth: it's redundant, but i don't see any harm...
17:55:13  <andythenorth> encourages wrong thinking
18:01:14  <Eddi|zuHause> frosch123: http://newgrf-specs.tt-wiki.net/wiki/CargoTypes#Cargo_Labels <-- better?
18:02:03  * frosch123 hugs eddi :)
18:03:14  <planetmaker> nice
18:03:27  <andythenorth> yup
18:09:49  <andythenorth> can we summarise proposed class changes yet?
18:10:15  <andythenorth> remove all > bit 8 is not going to work?
18:12:14  <Eddi|zuHause> andythenorth: my current list has: combine armored and mail (disputed, see frosch's reply), change "express" into "lightweight", remove hazardous, neo-bulk and clean, add non-pourable, clarify "oversized" to mean "piece goods, but needs flatbed or stake wagon"
18:12:55  <Eddi|zuHause> oh, and clarify "covered" to "pulverized, needs strict moist protection"
18:13:19  <Eddi|zuHause> (i.e. "doesn't suffice to cover with a simple tarpaulin")
18:14:13  <andythenorth> Eddi|zuHause: for the purposes of a vehicle set author, does 'pulverised' sufficiently overlap with 'needs pressure discharge'?
18:14:21  <andythenorth> they'll be highly similar vehicles I would think
18:14:27  <Eddi|zuHause> yes
18:14:31  <frosch123> Eddi|zuHause: there are lots of cargos on the wiki which need to be covered but are not pulverised
18:14:46  <andythenorth> covered is invalid :P
18:14:50  <frosch123> basically every foodish stuff
18:14:51  <Eddi|zuHause> frosch123: yes, my proposal removes that flag from those cargos
18:15:07  <frosch123> i don't think that is useful
18:15:16  <frosch123> that's what pourable is for, isn't it?
18:15:36  <andythenorth> so what's known / uncontentious?
18:15:40  <andythenorth> remove hazardous
18:15:42  <andythenorth> \o/
18:15:46  <andythenorth> + / - 1?
18:16:04  <Eddi|zuHause> frosch123: "piece goods" and "covered" is nonsense, "piece goods" already implies "goes in closed wagons"
18:16:09  <andythenorth> no
18:16:15  <andythenorth> piece goods implies break-bulk cargo
18:16:31  <andythenorth> covered is nonsense because anything can be covered easily
18:16:34  <Eddi|zuHause> at least if we follow MB's UIC-class-system
18:17:23  <Eddi|zuHause> frosch123: the difference between "pourable" and "pulverized" is that "pourable" goes into hopper wagons, and "pulverized" goes into silo wagons
18:18:04  <Eddi|zuHause> frosch123: when pulver gets wet, it cannot be unloaded anymore. aside of potential chemical reactions
18:18:25  <Eddi|zuHause> frosch123: when pourable cargo gets wet, it just is wet
18:18:40  <andythenorth> Eddi|zuHause: you mean powder?
18:18:51  <Eddi|zuHause> yes
18:19:13  <andythenorth> the typical transport term for the vehicles would be 'powder wagon'
18:20:07  <Eddi|zuHause> http://farm5.static.flickr.com/4020/4626174473_4f51325d55.jpg <-- from the second post of the thread
18:20:34  <andythenorth> real world examples :P
18:20:59  <Eddi|zuHause> http://www.tt-ms.de/forum/attachment.php?aid=4443
18:21:13  <CIA-6> OpenTTD: frosch * r23164 /trunk/src/roadveh_cmd.cpp: -Fix (r23149): Default roadvehicles became somewhat short.
18:21:34  <Eddi|zuHause> (from today's DBSet teaser)
18:22:17  <frosch123> [19:17] <andythenorth> covered is nonsense because anything can be covered easily <- it is about "must be covered", not "can be covered" :p
18:22:47  <andythenorth> but my vehicle can provision a cover if it must be covered :)
18:22:50  <andythenorth> it is not a problem
18:23:08  <andythenorth> it makes more sense in the way that eddi is implying - the cargo needs moisture protection etc
18:23:14  <frosch123> so, it should go along "clean" ?
18:23:28  <frosch123> in a separate property "cargo misc flags"
18:23:39  <andythenorth> do that and you open a can of worms
18:23:56  <andythenorth> actually in my mind it's clearly not a flag
18:24:03  <andythenorth> it's about the vehicle not the cargo
18:24:17  <andythenorth> the 'clean' flag is a flag because it's about the cargo needing the vehicle to be clean
18:24:24  <frosch123> well, but the vehicle should know whether it shall draw the cargo covered
18:24:28  <peter1138> it's about the cargo needing the vehicle to be covered
18:24:37  <andythenorth> clean is a refitting *cost* issue not a refitting issue
18:25:03  <Eddi|zuHause> a tarpaulin for covering also costs :)
18:25:05  <andythenorth> 'clean' is a mutable property of the vehicle
18:25:20  <andythenorth> so is covered I guess :P
18:25:25  <andythenorth> but not quite the same way
18:26:25  <Eddi|zuHause> anyway, it's obvious that there's still lots of room for discussions
18:27:34  <Elukka> huh. dbset has development again?
18:28:32  <andythenorth> looks nice
18:30:02  <andythenorth> Eddi|zuHause: frosch123 planetmaker http://www.tt-forums.net/viewtopic.php?f=68&t=53654&p=979294#p979294
18:30:35  *** Wolf01 [~wolf01@host48-239-dynamic.16-79-r.retail.telecomitalia.it] has joined #openttd
18:31:08  <frosch123> Elukka: release of dbset 0.9 was scheduled for 11-11-11, i.e. in 3 days. but has now been postponed again
18:31:14  <frosch123> due to new features
18:31:16  <Elukka> i see
18:31:18  <Wolf01> evening
18:31:55  *** MeSaber [~MeSaber@h-43-13.a166.priv.bahnhof.se] has joined #openttd
18:32:21  *** MeSaber [~MeSaber@h-43-13.a166.priv.bahnhof.se] has left #openttd []
18:35:38  *** TWerkhoven[l] [~turbulent@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd
18:38:20  <andythenorth> biab
18:38:21  *** andythenorth [~Andy@78-86-194-127.zone2.bethere.co.uk] has quit [Quit: andythenorth]
18:41:05  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
18:41:46  <planetmaker> bbl
18:42:21  *** TGYoshi_ [~TGYoshi@86.81.146.146] has joined #openttd
18:45:23  <CIA-6> OpenTTD: translators * r23165 /trunk/src/lang/ (7 files): (log message trimmed)
18:45:23  <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:23  <CIA-6> OpenTTD: dutch - 14 changes by habell
18:45:23  <CIA-6> OpenTTD: english_US - 27 changes by Rubidium
18:45:23  <CIA-6> OpenTTD: finnish - 28 changes by jpx_
18:45:25  <CIA-6> OpenTTD: german - 4 changes by planetmaker
18:45:25  <CIA-6> OpenTTD: italian - 27 changes by lorenzodv
18:45:35  *** HerzogDeXtEr [~Flex@i59F6ACB6.versanet.de] has quit [Read error: Connection reset by peer]
18:45:38  *** HerzogDeXtEr [~Flex@i59F6ACB6.versanet.de] has joined #openttd
18:46:53  *** TheMask96 [~martijn@pride.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
18:49:12  *** TGYoshi [~TGYoshi@86.81.146.146] has quit [Ping timeout: 480 seconds]
18:52:17  *** TheMask96 [~martijn@wrath.vhost.ne2000.nl] has joined #openttd
18:53:15  *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
18:53:19  *** mode/#openttd [+o Alberth] by ChanServ
18:54:52  *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has quit [Quit: supermop]
18:59:10  *** rhaeder1 [~quix0r@dslb-094-221-205-021.pools.arcor-ip.net] has quit [Quit: Leaving.]
19:04:33  <Eddi|zuHause> http://newgrf-specs.tt-wiki.net/wiki/CargoTypes#Cargo_Labels <-- moved FUEL to deprecated as well (if i understand the comment right)
19:05:24  <Eddi|zuHause> now only COPR has no indication on which set actually uses it
19:06:15  *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has joined #openttd
19:07:19  <frosch123> ask pikka
19:07:24  *** pjpe [ae5b514a@ircip1.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
19:07:30  <frosch123> pbi had fuel or petr or whatever
19:07:37  <frosch123> ukrsi maybe as well
19:08:41  *** JVassie [~James@2.27.86.104] has joined #openttd
19:09:09  <__ln___> oh no! berlusconi will resign.
19:09:34  <andythenorth> so
19:10:12  <andythenorth> 'covered' might be better as 'sensitive to weathering'
19:10:25  <andythenorth> covered confuses
19:10:32  <andythenorth> is it for including or excluding?
19:10:41  <andythenorth> should I set covered on all vans?
19:10:48  <Eddi|zuHause> no
19:10:49  <andythenorth> should I exclude covered on all open vehicles?
19:11:12  <andythenorth> 'sensitive to weather' gets closer to how most authors will want to use it - for covered hoppers, silos
19:11:45  <Eddi|zuHause> the old "covered" means something like "must have roof or tarpaulin over it", while the new/proposed one is way stricter
19:11:56  <andythenorth> the old covered seems of minimal use
19:12:07  <Eddi|zuHause> exactly, hence my proposed change
19:12:21  <Eddi|zuHause> the new covered makes only sense for bulk/"uncountable" cargo
19:12:45  <andythenorth> agreed - but there's no need to try and force that :)
19:13:09  <andythenorth> on the old covered, with OR classes, as cargo set author I might as well set it
19:13:14  <Eddi|zuHause> well, yes, the rules must be stated as clearly as possible
19:13:22  <andythenorth> because everything can be covered - and "where's the harm?"
19:13:27  <andythenorth> which makes it useless
19:13:52  <Eddi|zuHause> exactly that should be prevented...
19:14:09  <Eddi|zuHause> you're already interpreting things differently than i am
19:14:50  <andythenorth> 'sensitive to weather' or similar is open to similar interpretation?
19:15:09  <andythenorth> if I set that for coal cargo, does it look right or wrong?
19:17:24  <Eddi|zuHause> maybe "covered" is completely wrong, and it should really be named "powderized"
19:17:50  <andythenorth> that might work
19:18:12  <andythenorth> all cargos are sensitive to weather to some extent, but it's only significant for a small number
19:18:34  <andythenorth> would that sweep up 'requires pressure' as well?
19:18:56  <peter1138> and the date... is 2023-11-08 19:20
19:18:59  <andythenorth> most powder tankers are either gravity or pressure discharge, but at TTD scale they'll look the same
19:18:59  <Eddi|zuHause> that's imho fairly irrelevant at TTD-scale
19:19:13  <peter1138> the ongoing cargo class discussion was never resolved, and still continues...
19:19:16  <andythenorth> and you can carry grain in a pressure discharge vehicle
19:19:30  <andythenorth> peter1138: you could run a book on how many classes we add
19:19:32  <andythenorth> ...or remove
19:19:56  <peter1138> remember
19:20:01  <peter1138> classes are meant to be ... general
19:20:11  <andythenorth> therefore....fewer
19:20:13  <peter1138> they're for the fallback case
19:20:14  <andythenorth> imho
19:20:22  <andythenorth> labels = specific case
19:20:34  <Eddi|zuHause> andythenorth: if you take my example wagons, then adding "powderized" for grain will disallow grain in hopper wagons
19:20:45  <andythenorth> don't conflate the fallback with "I'm too lazy to add known labels and want to just use classes"
19:20:51  <Eddi|zuHause> andythenorth: which feels somewhat wrong, as there were specialized hopper wagons for grain
19:21:07  <andythenorth> Eddi|zuHause: why will it do that?  Grain is a known cargo
19:21:46  <Eddi|zuHause> andythenorth: have as few exceptions as possible. having a 32 cargo limit or not is irrelevant for that rule
19:22:19  <andythenorth> Eddi|zuHause: remove the 'pressure discharge' requirement?  I don't care about it
19:22:25  <andythenorth> it was your request MB answered :P
19:22:51  <andythenorth> Eddi|zuHause: actually I see your point
19:23:03  <andythenorth> there's no fricking answer to the grain problem :D
19:23:13  <CIA-6> OpenTTD: michi_cc * r23166 /trunk/src/newgrf.cpp: -Change: [NewGRF v8] Don't override rail type prop 1B with prop 09.
19:23:17  <andythenorth> either you want to set 'foo' on grain to make it weather sensitive, or you don't
19:23:25  <andythenorth> you can't have both routes with classes
19:23:45  <andythenorth> grain is appropriate for weather protection so I'd set the class
19:23:57  <andythenorth> what the vehicle author does with that is up to them
19:24:16  <andythenorth> or the class needs to get dropped
19:24:35  <Eddi|zuHause> there's an important difference between "weather sensitive" (prevent rain from falling on it) and "moist sensitive" (shield it from any kind of water)
19:25:27  <andythenorth> what known cargos are moisture sensitive?
19:25:45  <andythenorth> I suspect it's a useless class and should be removed
19:25:47  <Eddi|zuHause> in my list it's LIME, SULP and FERT
19:26:33  <andythenorth> honestly? :)
19:26:35  <Eddi|zuHause> but not GRAI/WHEA/MAIZ/CERE or CLAY
19:26:41  <andythenorth> seems like another case of 'author has own views' :)
19:27:02  <andythenorth> I can find n pictures of limestone in open wagons or hoppers
19:27:17  <andythenorth> Fertiliser is also piece goods and also travels in open wagons
19:27:21  <Eddi|zuHause> andythenorth: well, the approach was different. my thought was "what goes in that kind of wagon?"
19:29:38  <Eddi|zuHause> http://www.hs-merseburg.de/~nosske/EpocheII/fg/e2f_g127.gif <-- this wagon is listed as: "Kalk, Kalkmergel, gemahlenem Kalkstein,
19:29:39  <Eddi|zuHause> staubfeine Soda, staubfeines Steinsalz, und Gesteinstaub;
19:29:41  <Eddi|zuHause> auf Antrag und mit Zustimmung des WagenbÃŒros auch fÃŒr andere geeignete GÃŒter."
19:29:42  <andythenorth> if you're describing a new scheme, fine :)
19:30:20  <andythenorth> I just think it's not going to work to try and set classes by referring to "I want to refit to existing known cargos using classes only"
19:30:38  <andythenorth> the fallback case provided by classes explicitly rules out the kind of support you're after
19:31:07  <andythenorth> the only concern is to try and ensure *some* vehicles provide transport
19:31:13  *** |Jeroen| [~jeroen@d5152B25B.access.telenet.be] has quit [Quit: oO]
19:31:30  <andythenorth> therefore we should drop as many classes as possible, because more classes increases the likelihood of XORs preventing new cargos being carried
19:31:40  <andythenorth> see BEER and eGRVTS for example
19:32:00  <Eddi|zuHause> what's the problem there?
19:32:01  *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has quit [Read error: Connection reset by peer]
19:32:06  *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has joined #openttd
19:32:07  <andythenorth> stupid wifi
19:32:19  <Eddi|zuHause> what's the problem in eGRVTS?
19:32:57  <andythenorth> doesn't support BEER
19:33:02  <andythenorth> we set too many classes
19:33:05  <andythenorth> they get XORed
19:33:10  <Eddi|zuHause> i meant WHY?
19:33:10  <andythenorth> FIRS broke classes
19:33:16  <andythenorth> :D
19:33:21  <Eddi|zuHause> what exactly is wrong?
19:33:35  <andythenorth> there are no vehicles to carry BEER in eGRVTS
19:33:43  <Eddi|zuHause> *slap*
19:33:49  *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing]
19:33:52  <andythenorth> I don't know what's wrong :)
19:33:53  <Eddi|zuHause> WHAT EXACT CONDITION MAKES IT EXCLUDE BEER
19:33:57  <andythenorth> I have no idea
19:34:06  <andythenorth> zeph probably knows
19:34:15  <andythenorth> we could find out - we have the code in the repo I think
19:34:33  <Eddi|zuHause> if people would stick to the rules i put up in my proposal, such things shouldn't happen anymore
19:34:56  <andythenorth> I sort of don't want to look - because I want to prove the point that I should *stop* adjusting fricking FIRS classes to try and get support from person x's favourite vehicle set
19:34:56  <Eddi|zuHause> maybe the rules should be more clear
19:35:26  <Eddi|zuHause> the problem is not the classes
19:35:28  <andythenorth> nearly all of FIRS class changes are to try and retrospectively support a specific vehicle set
19:35:39  <Eddi|zuHause> the problem is that everybody has a slightly different opinion of what they mean
19:35:44  <andythenorth> yes that
19:35:50  <andythenorth> and also maybe Zeph set them wrong
19:36:02  <Eddi|zuHause> quite likely
19:36:49  <Eddi|zuHause> likely something like excluding Express in the Liquid wagon, and excluding Liquid in the Express wagon
19:37:13  <andythenorth> as the code is undocumented nfo with almost no formatting, I have desire to look
19:38:38  <Eddi|zuHause> the first one is a collision with the rule "express is only valid for piece goods", and the second is a collision with the rule "do not exclude the basic (OR) classes"
19:38:48  *** brundlefly [none@50-44-67-1.bltn.il.frontiernet.net] has joined #openttd
19:39:08  <andythenorth> express is only valid for piece goods?
19:40:55  *** George|2 [~George@212.113.107.39] has joined #openttd
19:40:55  *** George is now known as Guest16305
19:40:55  *** George|2 is now known as George
19:41:57  *** KritiK [~Maxim@95-28-19-103.broadband.corbina.ru] has joined #openttd
19:42:05  <andythenorth> Eddi|zuHause: would you set 'foo' (moisture whatever) for grain?
19:42:07  <Eddi|zuHause> it's something i noticed when thinking about classes. bad things happen when the "exclude" categories overlap: for wagons: "only list 'express' in the AND NOT mask, if you have 'piece goods' in the OR mask". for cargos: "only set 'express' if you also set 'piece goods'"
19:42:20  <Eddi|zuHause> andythenorth: i wouldn't
19:43:14  <Eddi|zuHause> i should write a lengthy article over my reasonings...
19:44:04  <CIA-6> OpenTTD: rubidium * r23167 /trunk/src/ (tunnel_map.cpp tunnel_map.h): -Codechange [FS#4818]: make IsTunnelInWay z parameters signed as well (hackalittlebit)
19:44:13  <andythenorth> Eddi|zuHause: I wouldn't either
19:45:05  <andythenorth> if you really want silo support, I would restrict it to 'this is specifically a powder, it needs to be fluidised for loading / unloading, and it needs to be kept dry'
19:46:28  <andythenorth> but if you did add it to grain, grain would still travel by open hopper
19:46:36  <andythenorth> because you're xor on that class would be wrong
19:46:43  <andythenorth> your / you're /s
19:47:04  <andythenorth> the 'powder' is a 'may' not a 'must'
19:47:19  <Eddi|zuHause> that's a design decision. if we want to have grain in that category, the categories must be rearranged
19:47:27  *** Guest16305 [~George@212.113.107.39] has quit [Ping timeout: 480 seconds]
19:48:04  <CIA-6> OpenTTD: yexo * r23168 /trunk/ (9 files in 4 dirs): -Feature [FS#1824]: always draw fences around field tiles
19:48:14  *** pjpe [ade6a119@ircip1.mibbit.com] has joined #openttd
19:48:53  <andythenorth> is it clear though?  If we keep the current scheme, you don't exclude 'foo' (powders) from open hoppers
19:48:58  <andythenorth> you exclude bulk from silos
19:49:06  <andythenorth> and rely on 'foo' to get those cargos into silos
19:49:16  <andythenorth> or rather, you don't include bulk for silos
19:49:23  *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd
19:49:45  <Eddi|zuHause> yes, because my assumption is that any cargo that sets "silo" also sets "bulk"
19:49:45  <andythenorth> (stupid implicit / explicit excludes)  :\
19:49:53  <Eddi|zuHause> so checking for that is redundant
19:50:17  <andythenorth> it's just redundant because it's redundant
19:50:22  <andythenorth> the classes are OR
19:50:41  <peter1138> multistop docks!
19:50:46  <peter1138> vehicles in vehicles!
19:51:05  <Eddi|zuHause> it's made redundant by some additional requirements on set design that i put up
19:51:13  <andythenorth> peter1138: roadtypes
19:51:16  <Eddi|zuHause> that currently do not hold for the existing cargos
19:51:19  <andythenorth> and also: mornington crescent
19:51:50  * andythenorth would like to claim £5
19:51:57  <Eddi|zuHause> that won't work if set designers do not follow these rules
19:52:13  <andythenorth> does that matter?
19:52:18  <andythenorth> if they do it wrong, they're wrong
19:52:40  <andythenorth> or they have their own ideas on cargo transport
19:52:46  <Eddi|zuHause> it must first be explained/clarified in a way that makes certain they are wrong
19:52:52  <andythenorth> good point
19:53:06  <andythenorth> as long as we're clear that wrong is possible, and the class scheme can do nothing about that :P
19:53:32  <Eddi|zuHause> eGRVTS cannot be "wrong" on the BEER matter, because it was not specified properly
19:53:37  <andythenorth> I would not file "cargo set designer does not like your vehicle choices" under wrong
19:53:59  <andythenorth> I would file "you failed to provide adequate fallbacks due to xyz" as wrong
19:54:38  <andythenorth> I would file "trying to support specific cargos by classes" as wrong
19:55:35  <andythenorth> I would file "I can't be bothered to setup label based support, please change your set classes" as wrong
19:56:34  <andythenorth> I want to file "dear cargo set author: I have a google image search that shows your cargo classes are definitely wrong for country x at date xyz" as wrong
19:57:29  <andythenorth> and I want to stop everyone jumping on me for changing FIRS cargo *classes* when it's supposed to be a fricking *abstraction* system
19:57:29  <andythenorth> :D
20:02:48  <andythenorth> I would also file "trying to reuse existing labels in your cargo set, but you have different intentions" as wrong
20:08:26  <Eddi|zuHause> yes. "if in doubt, add new label"
20:08:59  <Eddi|zuHause> but the "environment" was different back then
20:09:17  <andythenorth> the case when we started FIRS was 'reuse labels to get a better chance of cargo support'
20:09:28  <andythenorth> which just implied classes were being used wrong
20:09:37  * andythenorth wishes he had known that
20:11:22  <andythenorth> it's a shame that refittability can't be simply determined by the action chain for cargo label support
20:12:19  <andythenorth> i.e. action 3 - action 2 graphics chain
20:14:06  <andythenorth> i.e. if the label is known in the action 3 (via CTT), refit to it
20:14:16  <andythenorth> otherwise fallback to classes
20:21:31  *** supermop [~daniel_er@rrcs-72-43-171-87.nyc.biz.rr.com] has joined #openttd
20:23:58  <Qantourisc> How hard is it to make an gprs file ?
20:26:14  *** Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has joined #openttd
20:26:26  <Rubidium> what is a gprs file?
20:26:40  <Eddi|zuHause> andythenorth: there's probably some hysterical raisin for that
20:26:44  <andythenorth> general packet radio scheme?
20:27:02  <andythenorth> Eddi|zuHause: it was a dumb suggestion, but I've just convinced myself it's smart
20:27:24  <Qantourisc> I mean NewGRF
20:27:52  <Yexo> Read www.tt-wiki.net/wiki/NMLTutorial and decide for yourself
20:28:04  <Eddi|zuHause> Qantourisc: somewhere between 3 lines and 27000 lines
20:28:16  <V453000> :D
20:28:23  <appe> im bored with ottd.
20:28:42  *** Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has quit []
20:28:44  <Zuu> write a patch
20:28:55  <Yexo> or an AI, or a NewGRF ;)
20:29:48  <Zuu> Or improve TutorialAI by writing a new chapter :-)
20:29:49  <Qantourisc> I was wondering, why you don't get fined for slow deliveries :)
20:29:56  <Yexo> Zuu: I wanted to commit FS#4700 earlier today, only it didn't apply at all
20:30:11  <Rubidium> Qantourisc: you get fined
20:30:14  * Zuu goes and looks what FS#4700 is
20:30:20  <Yexo> New AIConfig flag: AICONFIG_AI_DEVELOPER - hides setting unless user have gui.ai_developer_tools = 1
20:30:30  <andythenorth> grf v8: decide refittability by looking first at labels in action 3
20:30:30  <Eddi|zuHause> @fs 4700
20:30:30  <DorpsGek> Eddi|zuHause: http://bugs.openttd.org/task/4700
20:30:36  <Qantourisc> Rubidium: ow ? didn't notise yet, but i mean fined as: getting -$$$ for your delivery
20:30:52  <Rubidium> Qantourisc: you get way less than when you transport it much quicker
20:30:52  <Zuu> Yexo: Oh, so you also liked my idea :-)
20:30:59  <Eddi|zuHause> andythenorth: how do you exclude specific cargos then?
20:31:08  <appe> got tips on any simple but interesting grf i can try?
20:31:12  <Rubidium> and at a certain point the payment dropoff gets steeper
20:31:16  <Yexo> Zuu: yes, just never got around to it before
20:31:25  <Yexo> and now I did, it completely fails to apply
20:31:26  <Rubidium> it's just not that visible
20:31:30  <andythenorth> Eddi|zuHause: what's the case for that (I am trying to think, you may be faster)
20:31:41  <andythenorth> I see the case
20:31:41  <Qantourisc> Rubidium: I mean going below zero for a delivery :p
20:32:13  <Zuu> Yexo: I'll take a look at it.
20:32:13  <Rubidium> Qantourisc: income - running cost being less than zero is a "fine" enough to me
20:32:13  <Yexo> Qantourisc: in which case it would be better not to deliver the cargo at all, which is stupid
20:32:28  <andythenorth> Eddi|zuHause: reuse the existing refit mask, interpret it only as 'not'
20:32:41  <andythenorth> or better, use a cb, remove the <32 limit
20:33:22  <Qantourisc> Yexo: no, in that case it's best to reroute the dam thing, or sell straight away, to prevent further losses
20:33:31  <Qantourisc> I was wondering how to make things harder in later gameplay
20:33:54  *** rhaeder [~quix0r@dslb-094-221-205-021.pools.arcor-ip.net] has joined #openttd
20:34:36  <Qantourisc> A fine for late deliveries would help, as it gets worse when your network grows
20:34:59  <Qantourisc> "Altered costs and prices" might already cut it though didn't try yet
20:35:21  <andythenorth> did I miss the grf v8 shipping window?
20:38:54  <Eddi|zuHause> andythenorth: there's a window until december-ish
20:40:57  <andythenorth> would my action 3 - labels proposal actually work?
20:41:01  <andythenorth> or am I smoking crack?
20:41:32  <appe> i just found the wedish trainset
20:41:33  <appe> +s
20:41:34  <andythenorth> they're not really returned as results are they from action 3
20:41:38  <appe> that's fantastic
20:41:49  <andythenorth> they're just branches
20:43:22  * andythenorth tries to guess how things work that he has absolutely no idea about
20:48:30  *** Andel [~andel@owenrudge.net] has quit [Remote host closed the connection]
20:51:24  <Eddi|zuHause> andythenorth: i'm sure that it's programmatically possible to do, but that doesn't mean it's sensible
20:56:39  <Zuu> Yexo: I started to merge the patch, but started to wonder what the differences where. So I made a new clone of my plain trunk and ran the patch through dos2unix and now it applied without any problems.
20:57:13  <andythenorth> Eddi|zuHause: nice forum post.  I 100% disagree with your premise for (1), 100% agree with (2), and (3) I find plausible, but really, a big bunfight waiting to happen
20:57:15  <Yexo> Zuu: of course
20:57:24  <Yexo> sorry, I should have realized that myself
20:57:45  <Zuu> Only Hunk #2 in table/settings.ini applies with a offset (38 lines) all other changes applies exactly.
20:58:54  <Yexo> right now I'm looking at the crash savegame from the forum, after that I'll compile/test/commit your patch
20:59:21  <Zuu> Good. That crash save game is kind of interesting.
20:59:33  <Zuu> At least it is for me non-obvious what the problem is.
21:00:32  <Zuu> With that savegame I have now ran into a type offset problem. Not sure exactly what visual studio mean by that.
21:00:57  <Zuu> Sorry, not type offset. But "Datatype misaligment"
21:01:35  <Yexo> I got a gpf on a local (stack-based) variable, that should also never happen except when overflowing the stack
21:02:15  <Zuu> Indede, my call stack is probably also overflown as it is constantly calling itself (_qsort)
21:03:10  <Yexo> that wasn't what I got
21:03:22  <Yexo> it wasn't in _qsort, at least I don't think so
21:03:31  <Yexo> running it again now in a debug build, this is going to take a while
21:03:49  <Zuu> I'm in "bool SQVM::StartCall(SQClosure *closure,SQInteger target,SQInteger args,SQInteger stackbase,bool tailcall)" when the datatype misaligment happened.
21:04:04  <Zuu> However, it has been stuck in _qsort for long time and my call stack is filled with it.
21:04:07  <Yexo> could be the same them, I clicked it away
21:04:51  <Yexo> about 40minutes before it'll reach november
21:10:00  <frosch123> [21:41] <andythenorth> would my action 3 - labels proposal actually work? <- peter suggested that two years ago in the same topic where also the cb is :p
21:10:11  *** DDR_ [~chatzilla@142.179.78.88] has joined #openttd
21:10:15  <andythenorth> well maybe he was right :D
21:12:58  <Zuu> Yexo: Is _current_company updated to be the AI company that is currently being executed?
21:13:07  <Zuu> It has value 7 according to my debugger.
21:13:26  <Yexo> yes, that should be correct
21:15:47  <Zuu> Counting the tabs in the AI debug window from left to right (with the first, greyed out, benig 0) I find that company 7 is BorkAI.
21:16:51  <andythenorth> frosch123: I looked in the topic I think you're referring to... http://www.tt-forums.net/viewtopic.php?f=26&t=44248&start=20
21:17:01  <andythenorth> that must be the wrong thread
21:17:13  <andythenorth> :)
21:17:19  *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd []
21:33:46  *** sla_ro|master [~slaco@95.76.27.160] has quit []
21:34:47  <Wolf01> 'night
21:34:50  *** Wolf01 [~wolf01@host48-239-dynamic.16-79-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.]
21:35:29  <andythenorth> frosch123: found it :)
21:39:32  *** sla_ro|master [~slaco@95.76.27.160] has joined #openttd
21:42:33  <Yexo> Zuu: the new savegame you posted is still running on November 10th
21:43:24  <Zuu> Hmm, mine crashed at the date I wrote (with farm binary r23126)
21:46:05  <Zuu> Tested again, but actually, I ended up using the one the original one as I've figured out at which value the _date variable should be at the time when it crashes.
21:46:22  <Zuu> That is. _date == 734808
21:46:33  <TGYoshi_> So.. any way to reduce train ÂŽbreakdownsÂŽ? There are so many :/
21:46:59  <Zuu> To be able to run the AI step by step, still the vm is quite hard to read what it is doing :-)
21:47:04  <Eddi|zuHause> TGYoshi_: difficulty settings => breakdowns "reduced" or "off"
21:47:16  <CIA-6> OpenTTD: yexo * r23169 /trunk/src/ (6 files in 4 dirs): -Feature: [NoAI] AICONFIG_AI_DEVELOPER flags to hide AI settings unless gui.ai_developer_tools is enabled (Zuu)
21:47:56  <TGYoshi_> Thanks, they were on ÂŽReducedÂŽ already tho, still breaking multiply times on a rail..
21:48:23  <andythenorth> ho
21:48:26  <andythenorth> http://www.tt-forums.net/viewtopic.php?f=26&t=40452&p=979345#p979345
21:48:42  <Eddi|zuHause> TGYoshi_: maybe you didn't service your vehicle often enough, or it's already very old
21:49:13  *** sla_ro|master [~slaco@95.76.27.160] has quit []
21:49:32  <Zuu> Yexo: Thanks, though if one start to use it by now, the AI will not load at all by a stable OpenTTD. But after april 2012 it can start to get used. :-)
21:49:35  <TGYoshi_> It even happens with a new train on a new game :P
21:49:51  <Yexo> you can use it now already by defining the constant in info.nut
21:50:06  <Zuu> Oh. Good point.
21:50:08  <TGYoshi_> And for some reason the pathfinding of the trains is really mutated
21:51:08  *** Progman [~progman@p57A1B050.dip.t-dialin.net] has quit [Remote host closed the connection]
21:51:09  <CIA-6> OpenTTD: yexo * r23170 /trunk/src/ai/api/ai_changelog.hpp: -Doc (r23169): add he new value to the AI changelog
21:52:52  *** sla_ro|master [~slaco@95.76.27.160] has joined #openttd
22:04:31  *** aglenday [~Impatient@59.167.161.74] has joined #openttd
22:11:13  *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
22:11:52  <Eddi|zuHause> "south korea switches email from port 25 to 587 - to block spammers"
22:14:16  <andythenorth> Eddi|zuHause: "#openttd blocks mention of cargo classes"  :D
22:16:02  *** valhallasw [~valhallas@vpn91.ext.espci.fr] has joined #openttd
22:20:17  <Zuu> Yexo: Good spot.
22:20:43  <Zuu> So on a slow computer, it is a freeze, and if you got a quick one, the freeze is quick enough that some people report it as a crash instead :-)
22:21:07  <Yexo> it actually is a stack overflow in most cases
22:21:15  <Yexo> depends on how the initial array is sorted
22:22:16  <Zuu> So those 9 minutes that the thread OP is talking about can not be explained by he using a slow computer that don't reach the stack overflow?
22:22:22  <Yexo> unless you have 80GB stack space :p
22:22:48  <Zuu> Is that what is requried for this problem? :-)
22:22:51  <Yexo> I think those 9 minutes were from the start until he reached the crash date
22:22:57  <Yexo> at which time it takes a while to actually crash
22:23:18  <Zuu> Oh, 9 minutes on non-fast-forward :-)
22:23:29  <Yexo> well, sorting an already sorted array of 50000 items will result in 50000**2 recursive calls
22:23:47  <Yexo> say each of those takes 32 bytes of stack space (and that is very conservative) you need 80GB
22:24:21  <Yexo> not to mention a lot of patience
22:24:46  <Zuu> and a 64bit build
22:26:01  <Eddi|zuHause> use heapsort
22:26:27  <Yexo> I'm very tempted to disable the sort() function and reimplement it in squirrel
22:26:31  <Eddi|zuHause> has better worst case than qsort, and better space usage than mergesort
22:27:15  <Zuu> Yexo, when you use AIList.Sort, is it also using _qsort?
22:27:21  <Yexo> no
22:27:25  <Eddi|zuHause> so... and who tried to tell me that AIs cannot cause this?
22:27:36  <Zuu> Kogut
22:27:43  <Yexo> someone without knowledge
22:28:06  *** valhalla1w [~valhallas@193.52.24.37] has joined #openttd
22:29:08  <Yexo> AIList has a custom sort algorithm
22:29:38  *** valhalla2w [~valhallas@vpn91.ext.espci.fr] has joined #openttd
22:29:45  <Yexo> haven't looked at it in detail for a long time, it's some variant of bucketsort I believe
22:30:02  <Zuu> Perhaps it is a good idea to make those comparable in performance?
22:30:08  <Eddi|zuHause> we've had several cases already where somehow some AIs managed to get around the opcode restrictions
22:30:34  <Zuu> It is quite easy as there are some states an AI can be when it can't be suspended.
22:30:49  <Zuu> Eg. when squrrel calls one of your functions.
22:31:09  <Zuu> Eg. when you call .Valuate or using sort with a comparator.
22:31:54  <Zuu> So in a such function you can make an infinity loop, and then OpenTTD can't do anything against that.
22:32:01  <Yexo> Zuu: AIList.Sort() doesn't call any squirrel functions
22:32:09  <Yexo> only .Valuate does, but you could implement that one in squirrel
22:32:35  <Zuu> Indeed. The problem is not if you want to make something that works.
22:32:46  <Yexo> so if we remove AIList.Valuate and provide an implementation in squirrel, and do the same for sort() and other functions that call squirrel functions, we should be able to get around this
22:33:10  *** TGYoshi_ [~TGYoshi@86.81.146.146] has quit [Quit: Poof]
22:34:43  <Zuu> Sounds like a good solution. I wonder how many more functions there are in addition to sort().
22:35:32  *** valhallasw [~valhallas@vpn91.ext.espci.fr] has quit [Ping timeout: 480 seconds]
22:36:12  *** valhalla1w [~valhallas@193.52.24.37] has quit [Ping timeout: 480 seconds]
22:37:48  <Yexo> most problematic will be the other meta-functions like _get and _set
22:38:04  <Yexo> I don't see a way to implement support for those completely in squirrel
22:39:26  <Yexo> we could make those functions very expensive (=eat all opcodes for current tick) so as to make nobody use them and remove them maybe in 1.3
22:40:07  *** valhalla2w [~valhallas@vpn91.ext.espci.fr] has quit [Ping timeout: 480 seconds]
22:40:39  <Zuu> Hmm, I don't think I've used _get or _set, so I didn't knew they were calling your own functions.
22:40:54  <Yexo> the pathfinder libraries use them
22:41:31  <Yexo> see http://dev.openttdcoop.org/projects/lib-pathfinderrail/repository/entry/main.nut#L76
22:42:01  <Yexo> if you did "local costobj = Rail.Cost(); costobj.something = 3;" the _set function would be called with idx == "something"
22:42:08  <Zuu> Oh, I see. you implement _get and _set in your class, and then those functions are called when you try to get/set a missing member.
22:43:05  *** HerzogDeXtEr1 [~Flex@i59F6B04F.versanet.de] has joined #openttd
22:43:37  <Zuu> So before making those very expansive the path finder would need a re-design.
22:43:42  <Yexo> instead of disallowing those functions we could try to find a way to set a hard-limit on opcodes for them and if you go over those, instead of suspending just kill the AI
22:44:02  <Yexo> well, for the pathfinder it's not so important
22:44:20  <Yexo> it's only for setting the costs, which is usually done only once per pathfinding action
22:44:29  <Yexo> ie a few ticks more or less won't be noticed
22:45:40  <Zuu> It depends, why you want to block them. If it is to stop a possible security issue that somone evil can write an AI that freezes/crashes OpenTTD. Or is it just to discourage AI writers to use them?
22:45:58  <Yexo> f it is to stop a possible security issue that somone evil can write an AI that freezes/crashes OpenTTD <- that
22:46:48  <Zuu> Then, you would need to completely forbid them I think, as a clever attacker could exploint the hole in just one go.
22:47:48  <Yexo> I'm not sure much afraid of an evil person that exploits this (that's easy, simply not use those AIs), but more that it's a pitfall were good-willing AI writers can actually hang OpenTTD
22:47:57  <Yexo> much like the problem we just found on the forum
22:48:18  *** andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has left #openttd []
22:48:45  <Zuu> Okay, in that case, the idea of counting expansive calls and giving feedback (by haning or providing stats) is a possible route.
22:49:08  *** HerzogDeXtEr [~Flex@i59F6ACB6.versanet.de] has quit [Ping timeout: 480 seconds]
22:56:11  <Zuu> Have you been able to confirm that it is BorkAI? I'm questioning myself because I can't find any line in the code that looks like it sorts 50000 elements.
22:59:12  <Yexo> I haven't yet tried to
23:01:01  <Zuu> I though I would report it in the BorkAI thread, but I don't want to until I have cleared out my doubts.
23:01:18  <Zuu> The AI before in execution order is IdleAI, and the one after BorkAI is SimpleAI.
23:01:58  <Yexo> I have confirmed earlier it was company 7, and that is BorkAI
23:02:07  <Zuu> Okay
23:02:49  *** Biolunar [mahdi@blfd-4db190a7.pool.mediaWays.net] has quit [Quit: All your IRC are belong to us!]
23:02:52  *** Elukka [~Elukka@89-166-103-135.bb.dnainternet.fi] has quit []
23:03:52  <Eddi|zuHause> Yexo: to me it sounds like you need a better method to suspend an AI if the VM runs too long, instead of patching out every builtin function
23:04:43  <Yexo> even if we could suspend the vm while it was in native code, that wouldn't have helped us in this case
23:04:55  <Yexo> since all the runtime is within a single c++ function
23:05:34  <Zuu> would a separate thread/process work that could be killed forcefully if the AI takes way too long?
23:05:46  *** Neon [~Neon@dslb-094-219-013-186.pools.arcor-ip.net] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
23:05:59  <Zuu> It would still run the AIs in sequence, but just have the separate thread to be able to kill it.
23:06:07  <Yexo> a separate thread is very tricky, since if you kill it from outside you can easily leak memory
23:06:14  <Zuu> But I guess that would complicate things a lot.
23:06:15  <Eddi|zuHause> not killed. suspended/resumed by time slice
23:06:31  <Yexo> Eddi|zuHause: suspending at the wrong moment might cause a lot of trouble
23:06:41  <Yexo> I'm not sure how safe all the API functions are
23:07:16  <Yexo> Eddi|zuHause: and you always need a way to kill such a thread forcefully if you want to end the game
23:07:55  *** TWerkhoven[l] [~turbulent@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Remote host closed the connection]
23:11:01  *** TWerkhoven2 [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Quit: He who can look into the future, has a brighter future to look into]
23:11:42  *** JVassie [~James@2.27.86.104] has quit [Ping timeout: 480 seconds]
23:14:00  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÌß]
23:16:47  <Yexo> Zuu: main.nut:871
23:16:58  <Yexo> the code befores makes a lst of all possible routes
23:17:21  <Yexo> which is done by matching for each cargo every industry that produces it to every industry that accepts that cargo
23:18:11  <Zuu> Okay, feel free to post that to the BorkAI thread to get all your clever points :-)
23:18:50  <Zuu> .. not that it would be my role to say anything against you doing that ...
23:19:43  <Yexo> I didn't see your post there yet
23:20:08  <Zuu> I though it would be a good idea to infrom the AI author.
23:21:17  *** mahmoud [~KEM@ALyon-158-1-77-77.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
23:30:38  <Eddi|zuHause> what do you do when you find a bag with two cans with a radioactive sign and writings "Uranium" and "Sulphur-Zinc" on them? of course you open them without any protection before the firefighters arrive
23:31:14  <Eddi|zuHause> http://www.derwesten-recherche.org/2011/11/radioaktiver-fund-gibt-raetsel-auf/
23:33:05  *** Yexo is now known as Guest16325
23:33:53  *** Guest16325 is now known as Yexo
23:38:43  *** MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has joined #openttd
23:42:36  *** sla_ro|master [~slaco@95.76.27.160] has quit []
23:44:12  <frosch123> i bet grandma threw aways grandpa's toys
23:51:19  <__ln___> dear magicians, is the line (0,2,1)+t(3,1,0) a subspace of R^3? not?
23:53:41  <planetmaker> good night