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

---Logopened Tue Nov 08 00:01:01 2011
00:03-!-Eddi|zuHause [] has quit [Ping timeout: 480 seconds]
01:19-!-Eddi|zuHause [] has joined #openttd
01:36-!-Prof_Frink [] has quit [Ping timeout: 480 seconds]
01:43-!-JVassie [~James@] has joined #openttd
02:12-!-Celestar [~dax@] has joined #openttd
02:17<Celestar>morning \o
02:19-!-pugi [] has joined #openttd
02:20<Terkhen>good morning
02:25-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
02:34-!-sla_ro|master [~slaco@] has joined #openttd
02:52<@peter1138>Celestar, fixed it yet? :D
02:57-!-Elukka [] has joined #openttd
02:57<Celestar>fixed what? the morning? :P
03:01<Celestar>and I'm trying to understand git :P
03:02<@planetmaker>use hg-git ;-)
03:03<@planetmaker>moin also :-)
03:05-!-Neon [] has joined #openttd
03:05-!-HerzogDeXtEr1 [] has quit [Read error: Connection reset by peer]
03:06-!-Progman [] has joined #openttd
03:13<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?
03:15<@peter1138>something like that
03:51-!-DayDreamer [] has joined #openttd
03:53-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
03:54<Celestar>peter1138: heh. k
03:54<Celestar>erm ....
03:54<Celestar>define debug_message (message) { return; }
03:55<Eddi|zuHause>that souds... useful...
03:57<Eddi|zuHause>mäh... i still have no way how smartd does not wake up sleeping drives
03:59-!-Brianetta [] has joined #openttd
04:17-!-MNIM [] has quit [Ping timeout: 480 seconds]
04:34-!-andythenorth [] has joined #openttd
04:36<andythenorth>in some respects we should remove the class information from the table of cargo *labels*
04:37<andythenorth>so in the list of known cargos we display their classes
04:37<andythenorth>in the wiki
04:37<andythenorth>who is that information useful to?
04:38<andythenorth>but some of that utility is for all the wrong reasons
04:38-!-TWerkhoven [] has joined #openttd
04:38<andythenorth>for cargo set authors trying to maintain parity, it's useful
04:38<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
04:38<andythenorth>Eddi|zuHause: no
04:38<andythenorth>well yes
04:38<Eddi|zuHause>deja vu :)
04:38<andythenorth>because of the stupid XOR mask
04:39<andythenorth>which is a fact on the ground
04:39<andythenorth>but the cargos with labels are *known* cargos yes/no?
04:41<andythenorth>linking the labels and the classes so tightly encourages vehicle authors to provision support for specific cargos based on classes, not labels
04:42<andythenorth>they have no choice currently
04:42-!-DDR_ [~chatzilla@] has quit [Ping timeout: 480 seconds]
04:42<Eddi|zuHause>andythenorth: there's still the 32 cargos barrier
04:43<andythenorth>this is all hot air wrt what's currently implemented
04:43<andythenorth>but worth unpicking imho
04:43<Eddi|zuHause>so you MUST rely on cargo classes
04:44<andythenorth>but not in cb-land
04:44<andythenorth>with the cb, problem solved
04:44<andythenorth>and as older sets stuck on the refit masks are not maintained, they don't need the information
04:44<Eddi|zuHause>don't treat some hypothetical callback as holy grail
04:45<andythenorth>it doesn't solve the 'how best to define classes'
04:45<andythenorth>it just sweeps away the mess of XOR
04:45<Eddi|zuHause>primarily, a callback would be much more complicated to code than a simple bitmask
04:45<@planetmaker>which would leave the existing classes sufficient, though, andythenorth
04:45<andythenorth>planetmaker: yes
04:46<andythenorth>currently MB appears to be amenable to *removing* certain classes, which might be wise, then just keep current scheme
04:46<@planetmaker>and as eddi pointed out correctly: it'd not pose a big issue to sanitize the classes of existing cargos
04:47<@planetmaker>I'm not too thrilled by what he suggests. It basically is to do the same thing as now. Just differently named
04:47<@planetmaker>and backwards
04:47<andythenorth>he considers both current scheme + a new scheme
04:47<andythenorth>both are worth looking at
04:48<andythenorth>Eddi|zuHause: I still think you're wrong about beer btw :D
04:48<andythenorth>not because you're wrong, but because it's a slippery slope
04:49<andythenorth>by your evidence-based method, milk *is* piece goods - because it used to travel in churns for hundreds of years
04:50<andythenorth>where I grew up, coal was delivered in sacks
04:50<Eddi|zuHause>you could implement churns as vehicles-in-vehicles, then the whole issue would disappear :)
04:50<andythenorth>it would indeed
04:50<andythenorth>separation of container + cargo
04:51<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
04:52<andythenorth>it just leads to 'war via google image search'
04:53-!-pjpe [] has quit [Quit: ajax IRC Client]
04:55*planetmaker googles a few images to gather fuel ;-)
04:56<andythenorth>Eddi|zuHause: I'm going to duck the issue :P
04:57<Eddi|zuHause>and i have to go out...
04:57<andythenorth>*if* vehicle authors don't do the dumb thing and exclude piece/bulk/liquid, there isn't really a problem
04:57<Eddi|zuHause>there are lots of problems... :)
04:59<andythenorth>in that case we should move on to those :P
04:59<andythenorth>the classes set by cargo sets shouldn't be a holy war :)
05:00<andythenorth>the exclusions used by vehicle set authors might be :P
05:04<Eddi|zuHause>prop 29 should be switched "AND" instead of "AND NOT"
05:05<Eddi|zuHause>and the XOR issue resolved
05:05<@planetmaker>and? How would that be helpful?
05:05<@planetmaker>you mean like piece or liquid) AND (refrigerate)?
05:05<@planetmaker>hm, yes
05:05<Eddi|zuHause>then it would be "monotonous"
05:05<Eddi|zuHause>which means adding classes to cargos is unproblematic
05:06<@planetmaker>That's true
05:06<@planetmaker>That'd make it easy
05:08<andythenorth>so vans would set 'covered' in prop 29?
05:08<andythenorth>rather than open wagons having to set 'covered' in prop 29
05:08<andythenorth>as per current AND NOT case
05:10<andythenorth>it's not a change we could make though, is it?
05:10<andythenorth>or is it?
05:11-!-Devroush [] has joined #openttd
05:12<andythenorth>hmm...does that idea help?
05:12<Eddi|zuHause>it would have to be part of GRFv8
05:12<andythenorth>now we get no cargo travelling by covered van unless the covered class is set
05:12<Eddi|zuHause>it would be 50% of my proposal
05:12<andythenorth>seems sub-optimal
05:12<Eddi|zuHause>the other 50% would be rearranging the cargo classes
05:13<andythenorth>Eddi|zuHause: what *doesn't* the cb route solve for you?
05:14<andythenorth>ANDing with covered would be stupid anyway
05:14<andythenorth>it would be better to put covered in prop 28
05:15<andythenorth>if you had two classes in prop 29 do you have to match both in the AND
05:15<andythenorth>i.e. AND (AND) or AND (OR)
05:18<@peter1138># funny how love is, everywhere just look and see
05:27-!-andythenorth [] has left #openttd []
05:57<@planetmaker>Eddi|zuHause, the 11 November date became void ;-)
06:04-!-sla_ro|master [~slaco@] has quit []
06:40-!-DayDreamer [] has quit [Quit: Leaving.]
06:42-!-hanf [] has joined #openttd
06:43-!-mahmoud [] has joined #openttd
06:46-!-blotek [] has joined #openttd
06:46-!-TGYoshi [~TGYoshi@] has joined #openttd
07:16<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
07:20-!-andythenorth [] has joined #openttd
07:31<andythenorth>wallyweb misses that the additional classes are to add information
07:31<+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.
07:32<andythenorth>merging everything 'odd' into one class destroys the information content
07:32<andythenorth>*but* this suggests that using classes to store information which is not 1:1 related to refitting is unwise
07:33<+michi_cc>Celestar: Most of the time, using 'git pull --rebase' to update should work. In case it doesn't, ask me :)
07:35<Celestar>$ git pull --rebase
07:35<Celestar>Current branch master is up to date.
07:35<Celestar>so something like that?
07:36<+michi_cc>Yes, and you can also execute 'git config --add branch.master.rebase true' to make --rebase the default.
07:36<+michi_cc>(for the branch master, that is)
07:36<andythenorth>planetmaker: new prop 'cleaning factor' - byte
07:36<andythenorth>multiplier on refit cost
07:37<Noldo>what's the workflow for using git in patchqueue way?
07:37<andythenorth>when refitting *from* that cargo
07:37<@planetmaker>no. Not a factor. Just a flag
07:37<andythenorth>multipliers are more fun :)
07:37<+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.
07:37<@planetmaker>otherwise you're duplicating the callback
07:37<Celestar>michi_cc: so in that case, how would you add a "patch queue" on top of that?
07:38<Celestar>make a own branch and use "rebase" for updating?
07:38<andythenorth>planetmaker: so just set a bit?
07:38<andythenorth>and let the vehicle author decide costs?
07:39<+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.
07:39<Celestar>sounds good
07:39-!-MNIM [] has joined #openttd
07:40<+michi_cc>It's possible to do that manually as well, but generally git pull --rebase Just Works™
07:42<+michi_cc>It won't save you from conflicts, but merging wouldn't either.
07:42<Celestar>I'm not afraid of conflicts :>
07:43<@planetmaker>andythenorth, of course
07:43<andythenorth>works for me
07:43-!-TWerkhoven [] has quit [Remote host closed the connection]
07:43<@planetmaker>frosch suggested using one of the misc flags
07:43<Celestar>michi_cc: anyway, what's your plan with that patch queue anyway?
07:43<@planetmaker>which probably is a good idea, if it's not a cargo class
07:43<andythenorth>planetmaker: is it more properly a 'refit at station or refit at depot' flag? Rather than a 'refit cost' flag?
07:44<@planetmaker>I think he suggested a flag for "foodish"
07:44<@planetmaker>with basically the same meaning as the cargo class
07:44<andythenorth>seems overly specific somehow...
07:44<@planetmaker>(or that's how I'd treat it. Like "needs clean car"
07:44<andythenorth>'needs clean car' is ok
07:45<@planetmaker>foodish was your wording ;-P
07:45<andythenorth>how often am I wrong?
07:45<andythenorth>~50% of the time?
07:46<@planetmaker>foodish is not wrong. It's just a sub-category of 'clean' ;-)
07:46<+michi_cc>Celestar: Completing my half-split of MP_STATION and then thinking about MP_TUNNELBRIDGE.
07:47<Celestar>If, in facebook, people are more and more accepting friend requests. How long until everyone has everyone else friended? :P
07:47<Celestar>michi_cc: halfsplit?
07:47<+michi_cc>"openttd - 56 Fehler, 0 Warnung(en)" or something like that :)
07:50<Celestar>michi_cc: and the MP_TUNNELBRIDGE idea was then MP_CLEAR + MP_BRIDGE + MP_RAILWAY or something?
07:50-!-TWerkhoven [] has joined #openttd
07:51<+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.
07:52<Celestar>(crossing railway bridges over railway?)
07:52<Celestar>michi_cc: how about a MP_BRIDGEHEAD ?
07:53<@planetmaker>andythenorth, cargo has no means to provide refit cost hints
07:53<@planetmaker>it's intrinsically impossible
07:53<@planetmaker>as it depends 100% on what was there before
07:53<@planetmaker>and how the vehicle is equipped
07:53<+michi_cc>That would just be a "subtype" of MP_TUNNELBRIDGE
07:53<Celestar>or that.
07:55<andythenorth>planetmaker: you could make the blanket assumption that *anything* specifying clean requires the vehicle to be cleaned
07:55<Celestar>michi_cc: did you give MP_FOUNDATION a thought?
07:55<andythenorth>I think we agree, it's just not written down in spec form?
07:55<@planetmaker>andythenorth, it's a bad idea. It mixes again two features more than is good for them
07:56<@planetmaker>For no real benefit
07:56<+michi_cc>That's one of the areas I'm not sure yet what the best solution is.
07:56<andythenorth>a hint specific to the cost? I think that's a bad idea. You convinced me it's just a bool
07:56<andythenorth>the vehicle sets the cost
07:57<andythenorth>the flag would be used by the vehicle during the refit cb
07:57<andythenorth>what the vehicle set author does is up to them
07:58<@planetmaker>i.e. the cost hint is pointless when considering milk. A refit of the box car would cost nothing. The tanker needs cleaning
07:58<andythenorth>they could check the new cargo, or both previous and new cargos
07:58<@planetmaker>yes. That's what the callback does. What OpenGFX+Trains does
07:58<@planetmaker>(if you are in need of an example ;-) )
07:58<andythenorth>nah, I get it
07:59<andythenorth>it's a bool
07:59<andythenorth>making it mean 'foodstuff' is too specific. 'Clean' is a bit vague. Just needs a name
08:00<Celestar>michi_cc: I'll wreck my brain a bit, maybe I have some epiphany
08:01<andythenorth>planetmaker: any other useful bool props you can think of? :P :D
08:02<andythenorth>these aren't conventions, they're patches on ottd?
08:02<andythenorth>so they won't fragment in quite the same way
08:02<andythenorth>and will get more sane review
08:03<@planetmaker>more so, they require patches to nforenum and nml
08:03<Celestar>michi_cc: or maybe write some prototype :P
08:08<Eddi|zuHause>i'm not having a sensible idea how to revamp the cargo class system while keeping compatibility with the old system...
08:11<Celestar>have two systems?
08:12<Eddi|zuHause> ?
08:14-!-DayDreamer [] has joined #openttd
08:20-!-Biolunar [] has joined #openttd
08:29<andythenorth>Eddi|zuHause: keep the current system?
08:31<andythenorth>it's really not very broken
08:31<lugo>"It's cheaper to keep her"
08:31<andythenorth>just a bit confusing
08:31<andythenorth>and a bit degraded by random classes
08:32<andythenorth>and cargo sets need to forget trying to provide reverse-support via classes to vehicle sets that do odd things
08:49<Eddi|zuHause>the problem is the conversion of old cargos to a sensible system
08:49<andythenorth>that's not a problem if we don't change...?
08:50<Eddi|zuHause>yes, it is
08:50<Eddi|zuHause>because it completely does not make any sense
08:52-!-glx [glx@2a01:e35:2f59:c7c0:91d7:24c2:f473:6f05] has joined #openttd
08:52-!-mode/#openttd [+v glx] by ChanServ
08:55<andythenorth>Eddi|zuHause: break old sets?
08:55<andythenorth>it's about time lots of them got broken
08:56<@planetmaker>to unconditionally break them is not really a way
08:58<andythenorth>Eddi|zuHause: only classes trouble you? Not labels?
08:59<Eddi|zuHause>andythenorth: i don't really care about labels. that's solely a matter for industry set authors
08:59<andythenorth>so one proposal
08:59*andythenorth thinks
09:00<Eddi|zuHause>andythenorth: the "FMSP is both fertilizer and harvesters" is kinda troublesome
09:00<andythenorth>Eddi|zuHause: shrug :)
09:00<andythenorth>let vehicle set authors decide
09:01<Eddi|zuHause>andythenorth: but it totally destroys the class system :)
09:01<Eddi|zuHause>andythenorth: you should either split it, or remove one of them
09:01<Eddi|zuHause>andythenorth: combine FMSP and ENSP into "machines", and add FERT
09:02*Eddi|zuHause is opening a can of worms)
09:02<andythenorth>Eddi|zuHause: feel free to open the can :)
09:03<andythenorth>but then we start confusing the cargo with the industry chain gameplay
09:03<andythenorth>it really should be of no issue that FMSP is n things in the gameplay
09:03<@planetmaker>we should only use only two cargo classes: "dorks" and "stuff"
09:03<andythenorth>the cargo set should be a black box to the vehicle set
09:04<andythenorth>labels can cross the black box
09:04<andythenorth>standard answer :P
09:04<@planetmaker>it's no issue that a vehicle set doesn't support all possible representation of a cargo
09:04<andythenorth>the duty of the vehicle set is to provide vehicles matching certain classes
09:04<@planetmaker>and honestly... your latest table, Eddi|zuHause , reads like "no change needed"
09:05<andythenorth>the duty of the vehicle set is not to support the cargo set author's vision of what a cargo is
09:05<Eddi|zuHause>planetmaker: "not pourable" is a change
09:05<andythenorth>the cargo set author determines where the cargo goes
09:05<andythenorth>and certain intrinsic properties
09:05<Eddi|zuHause>planetmaker: and still the current cargos are totally wrong
09:05<@peter1138>i agree with wallyweb ;)
09:06-!-frosch123 [] has joined #openttd
09:06<Eddi|zuHause>planetmaker: current GOOD is not "piece/countable", current WOOD and STEL is not "oversized"
09:06<@planetmaker>don't mix the cargo classes of labels in the cargo classes discussion
09:06<@planetmaker>it's IMHO two things
09:07<Eddi|zuHause>planetmaker: but it is actually the biggest problem
09:07<@planetmaker>yes, that it is
09:07<Eddi|zuHause>planetmaker: it makes no sense fixing cargo classes, when the cargo labels stay utterly wrong
09:07<@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
09:07<@planetmaker>I'm not arguing that, Eddi|zuHause
09:07<Eddi|zuHause>planetmaker: currently we're at two new classes
09:07<@planetmaker>I'm arguing: "only fix the classes attached to existing labels"
09:08<Eddi|zuHause>planetmaker: "lightweight" and "not pourable"
09:08<andythenorth>I would place money on ending this with fewer classes than we currently have in the wiki
09:08<@planetmaker>and the two "new" classes I think we agreed are not needed
09:08<andythenorth>'requires pressure discharge' should go away too
09:08<Eddi|zuHause>planetmaker: who is "we" and what is your value of "agree"?
09:08<@planetmaker>who's your "we"?
09:09<@planetmaker>and where do you derive any concensus about those classes from? Or their need?
09:10<andythenorth>hazardous + covered/sheltered should be removed
09:10<Eddi|zuHause>i didn't... i explicitly stated that is _my_ view
09:10<andythenorth>oversized + neo-bulk should be consolidated
09:10<andythenorth>clean is a failed idea
09:10<andythenorth>special should be removed if possible
09:10<@planetmaker><Eddi|zuHause> planetmaker: currently we're at two new classes
09:10<andythenorth>pressure discharge should not be added
09:10<Eddi|zuHause>planetmaker: that's a pluralis majestis :p
09:10<andythenorth>labels should be disconnected entirely from classes
09:11<andythenorth>and vehicle sets should provide for maintainability
09:11<andythenorth>this all stems from *idiots not using the GPL*
09:11<@planetmaker>disconnecting labels from classes in refit would solve basically all issues
09:11<andythenorth>^^ all / some /s
09:11<@planetmaker>we could remove hazardous indeed
09:11-!-hanf [] has quit [Quit: Leaving]
09:12-!-hanf [] has joined #openttd
09:12<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
09:12<andythenorth>the most common objection from players is "wail, my favourite set won't work"
09:13<andythenorth>then we dick around trying to reverse engineer sets that improperly implemented an incomplete and flawed spec
09:13<@planetmaker>Eddi|zuHause, we can't change current set's assumptions
09:13<andythenorth>current sets should be maintained if they want accurate support
09:13<andythenorth>otherwise we should slim down the number of classes, and use them in a brute-force way
09:13<Eddi|zuHause>planetmaker: then we should change the default cargo's labels
09:14<@planetmaker>that's an interesting idea
09:14<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)
09:14<andythenorth>then we get tied up in knots trying to do ever-more-perfect support for a future unknown, and a broken past
09:15<andythenorth>set bulk and/or liquid and/or piece and the cargo will *always* be transported
09:15<jonty-comp>i swear you've been arguing about cargo classes for the last week
09:16<andythenorth>Eddi|zuHause: GDS2
09:16<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
09:16<andythenorth>instead of FOOD
09:16<andythenorth>the <32 cargo limit will be eliminated
09:16<andythenorth>wrt CTT
09:17<andythenorth>when I typed FOOD I meant GOOD :P
09:17<Eddi|zuHause><andythenorth> the <32 cargo limit will be eliminated <-- compare the time between computers providing >1MB memory, and the 640k barrier being "eliminated"?
09:18<Eddi|zuHause>andythenorth: "GODS" :)
09:18<andythenorth>Eddi|zuHause: it can go as soon as frosch figures out and commits the two year old cb idea?
09:18<andythenorth>Eddi|zuHause: OGOD
09:18<andythenorth>or do an obiwan letter shift
09:20<andythenorth>or do an imperfect obiwan
09:21<andythenorth>planetmaker: dare we only set bulk, piece, liquid for FIRS? :o
09:21<@planetmaker>as classes?
09:21<@planetmaker>No. We also set refrigerate
09:21<andythenorth>I was worrying about that
09:21<@planetmaker>And covered IMHO makes sense for some, too
09:21<andythenorth>but it's an odd class before 1900
09:21<@planetmaker>that's up to the vehicle set
09:21<andythenorth>planetmaker: anything can be covered. Use a tarpaulin, or shrink wrap
09:22<@planetmaker>a vehicle set can always choose to ignore it
09:22<andythenorth>planetmaker: he
09:22<andythenorth>so why set it?
09:22<andythenorth>let the vehicle set decide?
09:22<andythenorth>based on...labels
09:22<@planetmaker>as it helps to provide special support in 1970
09:22<andythenorth>classes are for unknown cargos
09:22<@planetmaker>the refrigerate class is sufficient (as positive definition) to ship all those cargos
09:22<@planetmaker>I just tested yesterday
09:22<andythenorth>slippery slope....
09:22<@planetmaker>w/o bulk/piece/liquid consideration at all
09:23<andythenorth>is refrigerate a core class then?
09:24<@planetmaker>if you want to use it as inclusion criterion one would have to create a class "non-refrigerate"
09:25<andythenorth>well removing the 'extra' classes was an appealing idea :P
09:32<@planetmaker>andythenorth, I guess we can remove 'hazard'
09:32<@planetmaker>and join neo-bulk / over-sized. And remove clean
09:32<@planetmaker>then it's quite clean again ;-)
09:45<andythenorth>planetmaker: I am suspicious about covered
09:46<andythenorth>if I was coding a train set, I would set covered on vans, flat cars and open wagons
09:46<andythenorth>thereby negating it
09:46-!-Adambean [] has joined #openttd
09:47<@planetmaker>it has the same issue as refrigerated.
09:47<@planetmaker>it'd be more useful if it was either used as 'and'
09:48<andythenorth>if I have ice to hand, I can refrigerate anything?
09:54-!-Kurimus [] has joined #openttd
10:00<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
10:01<frosch123>"covered" is meant for the EXCLUDE-mask
10:02<frosch123>bulk, piecegoods and liquid are basically INCLUDE-only, everything starting from refridgerated is EXCLUDE-only
10:02<andythenorth>I know
10:03<andythenorth>but let's get rid of some :P
10:03<frosch123>the first four can be used in both INCLUDE and EXCLUDE
10:03<andythenorth>if they're used in EXCLUDE the world ends
10:03<@planetmaker>mail? :-P
10:03<frosch123>planetmaker: ttd mail is a special ttd cargo, not related to any rl cargo
10:05<@planetmaker>sadly. yes
10:06<andythenorth>I don't understand why covered is ok, but neo-bulk adds inumerable, intolerable complexity :P
10:06<@planetmaker>you really don't know?
10:07<Terkhen>it feels duplicated :P
10:08<andythenorth>for the purpose I intend it, is neo-bulk simply the inverse of covered?
10:08<andythenorth>the inverse of covered is not covered :P
10:08<@planetmaker>it's about the similar to over-sized
10:09<@planetmaker>neo-bulk just means it's not-palettizable piece cargo
10:09<@planetmaker>possibly with unhandy dimensions
10:09<@planetmaker>(though in my understanding not necessarily unhandy)
10:09<@planetmaker>mail bags iirc are also neo-bulk ;-)
10:09<@planetmaker>but I might have mis-understood that
10:10<andythenorth>the term seems to be loosely defined
10:10<andythenorth>a better term might be "doesn't fit through doors nicely"
10:10<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
10:11<andythenorth>planetmaker: as far as I am concerned, we could consolidate neo-bulk and oversized to one class....then remove it :P
10:11<andythenorth>the help I am trying to provide to vehicle sets is better forgotten about
10:11<andythenorth>use labels
10:12<@planetmaker>I wonder whether I should update the NewGRF wiki ;-)
10:12*andythenorth has an idea
10:12<@planetmaker>probably I should leave this to you :-P
10:12<andythenorth>make prop 28 a byte
10:13<andythenorth>or maybe a word
10:13<@planetmaker>it is a word...
10:13<@planetmaker>or which?
10:13<andythenorth>train prop 28?
10:14<andythenorth>is it word sized right now?
10:15<andythenorth>anyway, make it a byte :D
10:15<andythenorth>everything above 'refrigerated' gets deprecated
10:15<andythenorth>remove prop 29
10:15<andythenorth>everyone wins
10:15-!-TWerkhoven2 [] has joined #openttd
10:16<frosch123>hmm, so "express" means stuff that shall be transported with high-speed trains
10:16<frosch123>so, it would be an INCLUDE-mask thingie
10:18<@planetmaker>it'd be 'exclude' with the same reasoning
10:18<@Yexo>but a wagon doesn't decide whether or not it can be attached to a high-speed engine
10:18<@planetmaker>but it has a speed limit (sometimes)
10:18<frosch123>the engine decides about attaching anyway
10:18<@planetmaker>except for all those which play without :-)
10:18<frosch123>and start/stop
10:18<@Yexo>that means a wagon with high speed limit would include express, but you could still attach it to a slow engine
10:19<@planetmaker>snail express :-)
10:19<frosch123>Yexo: i was refering to the german discussion of patchman and mb from 2005
10:19<frosch123>where patchman says, express it the stuff that is transportable using maglev
10:19<@Yexo>well, imo express makes no sense in that was as cargoclass
10:20<Eddi|zuHause>"express" is a flawed concept
10:20<andythenorth>it makes no sense
10:20<andythenorth>it has the benefit of usefulness though
10:20<andythenorth>sense might be orthogonal to utility
10:20<Eddi|zuHause>add those cargos to "mail" isntead
10:21<andythenorth>the downside of removing express is that it works
10:21<andythenorth>it's conceptually all wrong
10:21<andythenorth>but if you want milk on fast passenger trains it provides that easily
10:22<andythenorth>is there another way that could be achieved?
10:22-!-TWerkhoven [] has quit [Ping timeout: 480 seconds]
10:23-!-MNIM [] has quit [Remote host closed the connection]
10:25<andythenorth>what's the point of armoured?
10:25<Eddi|zuHause>how is "Wood Products" "bulk"?
10:25<andythenorth>wood chips
10:25<Eddi|zuHause>andythenorth: that makes no sense...
10:25<andythenorth>I have a long pm discussion with MB about it if you would like a copy
10:25<andythenorth>it makes complete sense
10:25<andythenorth>wood chips are bulk
10:25<andythenorth>and he can send you pictures of them being transported as such if that helps
10:26<andythenorth>why doesn't it make sense? :)
10:26<andythenorth>it certainly makes FIRS lumber a bit...odd
10:26<Eddi|zuHause>it doesn't make sense as an ingame cargo...
10:26<@planetmaker>why not?
10:26<andythenorth>I actually convinced myself it works
10:27<andythenorth>Eddi|zuHause: what's troubling about it?
10:27<andythenorth>wood products can be bulk
10:27*andythenorth is asking genuinely
10:27<andythenorth>not for argument
10:27<andythenorth>sawdust can be poured
10:27<andythenorth>wood chips can be poured
10:28<Eddi|zuHause>andythenorth: but it has nothing to do with "Lumber"
10:29<frosch123>andythenorth: "armoured" are those classical western wagons with soldiers on them
10:29<frosch123>i.e. they are closed wagons with whatever in them
10:29<frosch123>a flat bed wagon in front and behind with one machine gun each
10:29<frosch123>and a flat bed wagon at the end with a cannon
10:29<andythenorth>Eddi|zuHause: again that's due to a mistake when coding FIRS
10:30<Eddi|zuHause>andythenorth: basically it's something related to the discussion on why "FMSP" shouldn't be both "fertilizer" and "machines"
10:30<andythenorth>(a) lumber is a highly confusing term, it varies depending which continent you're on
10:30<andythenorth>(b) we made the mistake of trying to reuse an existing ECS class
10:30<andythenorth>class / label /s
10:31<andythenorth>trying to reuse labels with no attention to wether they mean similar things in game is unhelpful
10:31<andythenorth>it's a bad pattern
10:31<andythenorth>it nominally gains cargo sprite support faster, except that support could well be wrong
10:32<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
10:32<andythenorth>so basically we messed up
10:33<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
10:36<andythenorth>frosch123: if I add 'soldiers' cargo, can they go in 'armoured' ?
10:36<andythenorth>I guess armoured has to stay, but it's *so* niche...
10:37<frosch123>andythenorth: i think most sets transport mail and armored in the same vans
10:37-!-Devroush [] has quit [Ping timeout: 480 seconds]
10:37<andythenorth>but if I want to add a future cargo which needs armoured wagons, I should be able to?
10:38<andythenorth>seems like a waste of a bit, but we're stuck eating hysterical raisins
10:38<andythenorth>why does Mail get a class?
10:39*andythenorth considers a new industry set: '1st class mail' '2nd class mail' 'parcels' 'airmail'
10:39<andythenorth>main industry: post office
10:40<@planetmaker>called ecs houses?
10:40<frosch123>passengers and special are built-in cargoclasses with speic
10:40<frosch123>speical implementations
10:40<frosch123>Eddi|zuHause: as such "special" cannot be deprecated
10:40<frosch123>cargos with class "special" are hidden from the gui in certain parts
10:41<Eddi|zuHause>hm, ok
10:41<andythenorth>frosch123: can a vehicle ever refit to special?
10:41<andythenorth>I guess
10:41<z-MaTRiX>These boards use an Atmel ATmega644 microcontroller clocked at 22.1MHz, and a 512K SRAM for data and framebuffer storage.
10:41<andythenorth>a better question would be, is 'special' valid for a prop 28 or 29 refit mask
10:41-!-Devroush [] has joined #openttd
10:42<andythenorth>I know that pikka thinks regearing was not his finest idea anyway
10:42<frosch123>CC_MAIL is also special, as in passenger and mail are always the first cargos in a list
10:43<Eddi|zuHause>frosch123: so what happens if multiple cargos are in CC_MAIL?
10:43<@planetmaker>have to be?
10:43<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
10:43<@planetmaker>what is, if there's no passengers?
10:43-!-Celestar [~dax@] has quit [Ping timeout: 480 seconds]
10:43<frosch123>Eddi|zuHause: they are sorted by name
10:43<frosch123>like the rest
10:43<@planetmaker>k :-)
10:43*planetmaker thinks of a Cylon economy
10:43<frosch123>planetmaker: there are no busses :p
10:44<z-MaTRiX>it does 3d video at 22MHZ
10:44*andythenorth wants to kill all the classes :D
10:44<andythenorth>this however gains not much
10:44<frosch123>oh, crap
10:44<CIA-6>OpenTTD: yexo * r23134 /trunk/src/ai/ (5 files in 2 dirs): -Add [FS#3799]: [NoAI] AICargoList_StationAccepting
10:45<@planetmaker>hm, frosch123 ?
10:45<frosch123>industries producing CC_MAIL are excluded for naming nearby stations "mine"
10:45<andythenorth>how esoteric
10:45<@planetmaker>err... *that is peculiar*
10:45<andythenorth>are they allowed to name it "yours"
10:46<frosch123>i guess i should add a list of "coded usages" of the classes to the thread
10:46<andythenorth>that would help
10:46<andythenorth>especially if it turns out someone can devise a new better alternative to classes
10:46<andythenorth>then we see what legacy crap exists
10:46<andythenorth>although /me prefers to refine classes
10:47<andythenorth>refine => remove, clarify
10:47<andythenorth>frosch123: the 'clean is a special flag' route might be appealing
10:50<@peter1138>CC_MAIL or CT_MAIL?
10:51<frosch123>i am grepping for \<CC_
10:51<frosch123>and try to ignore console colors :p
10:52<@peter1138>yeah i spotted that earlier, hehe
10:52<@peter1138>SCC too
10:53<CIA-6>OpenTTD: yexo * r23135 /trunk/src/ai/api/ai_order.cpp: -Fix (r23133): always compile before commit
10:55<Eddi|zuHause>did the forum just die or is that me?
10:56<@peter1138>it's you
10:57<Eddi|zuHause> <-- lengthy proposal
10:58<@planetmaker>can't you just keep it in sensible words than illegible UIC letters?
10:58<Eddi|zuHause>planetmaker: i defined all abbreviations...
10:58<Eddi|zuHause>planetmaker: or shall i go mad during copy-pasting lengthy words?
10:59<@planetmaker>the letters don't add to anything
10:59<@planetmaker>and make it totally unreadable, if one doesn't either know them or wants to memorize every letter.
10:59<@planetmaker>Which do not even follow a pattern
10:59<@planetmaker>(except being cryptic UIC letters)
11:00<@planetmaker>i.e. using the letters is IMHO quite the wrong thing to do
11:00<Eddi|zuHause>G - Güterwagen, Z - Zisternenwagen
11:01<Eddi|zuHause>the older DB/DRG classification may have more "sensible" abbreviations
11:01<Eddi|zuHause>e.g. "O" instead of "E"
11:01<@planetmaker>if you want to explain: don't use abbreviations
11:01<Eddi|zuHause>but i'm really not understanding your criticism
11:03<@planetmaker>you're introducing a chain of abbreviations which do not relate at all to what they abbreviate
11:04<Eddi|zuHause>it's a set of abbreviations that has been used in that same thread very often...
11:04<@planetmaker>and re-defining classes without really much need. The only new thing is the "pourable"
11:05<@planetmaker>by one person. Or two
11:05<@planetmaker>anyway, independent of that: that system is only slightly different from what we have for classes
11:06<@planetmaker>That doesn't warrant a change there
11:06<Eddi|zuHause>yes, that was the point, keep as much of the current system as possible
11:06<@planetmaker>Keep the complete class system as is. Maybe remove hazard and replace by pour
11:06<@planetmaker>then everything is safe wrt past newgrfs
11:07<@planetmaker>the only thing which really makes sense to redefine in that context is the assignment of classes to labels
11:07<Eddi|zuHause>"deprecating the express and armored class" is more of a suggestion for new GRFs
11:08<@planetmaker>which - as we saw - is possibly done better by inventing new labels
11:08-!-hanf [] has quit [Read error: Connection reset by peer]
11:09<andythenorth>Eddi|zuHause: you think FMSP should be split for transport reasons? :)
11:09<Eddi|zuHause>andythenorth: yes
11:09<andythenorth>feel free to rework the chains to suit ;)
11:09<andythenorth>and explain to users which cargos are needed at farms, and in which combinations
11:10<andythenorth>ENSP should also be split
11:10*peter1138 bops andythenorth over the head with fleetwood mac
11:10<Eddi|zuHause>andythenorth: add MCHN cargo, transport FERT and MCHN to farms, transport BDMT and MCHN to mines?
11:11<@planetmaker>that's then two cargos for mines...
11:12<Eddi|zuHause>need someone capable of operative decisions: remove those unused URAN etc. cargos that "someone" added, and nobody actually knows who that was
11:14<TGYoshi>This talk sounds complicated.
11:14<andythenorth>Eddi|zuHause: combine FERT and FUEL to make EXPL
11:14<andythenorth>transport those to mines too
11:14<Eddi|zuHause>that sounds overcomplicated
11:15<Eddi|zuHause>make refinery produce BDMT?
11:15<andythenorth>if you're transporting machines you also need to transport PETR or FUEL
11:15<andythenorth>and PART
11:15<andythenorth>and TYRE
11:16<Eddi|zuHause>refinery: BDMT (explosives), lumber yard: BDMT (lumber), cement plant: BDMT (cement), glass works: BDMT (glass)
11:16<Eddi|zuHause>brick works: BDMT (bricks)
11:16<andythenorth>BDMT should properly be split
11:17<Eddi|zuHause>you have a 32 cargo limits
11:17<andythenorth>powered cement is a bulk cargo needing moisture protection
11:19<@peter1138>either forget about that
11:19<@peter1138>or give it no classes and make a special vehicle set :p
11:20<andythenorth>raise the cargo limit :P
11:22<andythenorth>256 should be enough
11:22<andythenorth>and industry sets should provide vehicles
11:22*andythenorth needs a prefix for '/me is now trolling'
11:22<Eddi|zuHause>FIRS has already very many cargos. should actually try to reduce it
11:23<+michi_cc>Eddi|zuHause: s/uint32/uint64/ in the proper places takes care of that :)
11:23<andythenorth>Eddi|zuHause: I think that's reduced as far as it can go
11:23<andythenorth>I've had that discussion enough times now
11:23<andythenorth>if I start it again, planetmaker will abandon contributing, then I'll be left on my own, unable to read/write nml
11:24<andythenorth>also - the bunfight about FMSP is nothing to do with classes, so maybe we park it for now?
11:24<andythenorth>I was trolling a bit :P
11:25<andythenorth>FIRS economies are the proper solution to 'fewer cargos please'
11:27<@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.
11:29-!-supermop [] has joined #openttd
11:29<Eddi|zuHause>maybe it's from that SirXavius guy with the OTTD
11:29<Eddi|zuHause>OTTD+500 project?
11:31<@planetmaker>anyway. Removed. History still has them, if needed
11:32<Eddi|zuHause>TWOD was another cargo that didn't have any information which set includes it
11:33<@planetmaker>iirc it once was ECS?
11:36<@peter1138>george thought TWOD was a default one
11:36<@peter1138>or something like that?
11:38<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.
11:38<@planetmaker>something like that is what I recall, too
11:38*TrueBrain blacklists another video website ...
11:44-!-supermop [] has quit [Remote host closed the connection]
11:44<frosch123>TWOD was listed as default cargo for several years
11:45<frosch123>and various people were surprised that it did not appear in TTDP or OTTD
11:45<Eddi|zuHause>i presume COPR as well?
11:45<frosch123>CORE is default afaik
11:46<frosch123>COPR was in some set somewhen, maybe FIRS?
11:46<Eddi|zuHause>yes, but COPR is listed further down
11:46<@planetmaker>tropical climate is CORE. I don't know about COPR. iirc pikka had something with it?
11:47<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
11:47<@planetmaker>that was my understanding of COPR, too. But I don't really know where (or whether) it's used
11:47<frosch123> <- anyway, your list
11:50-!-supermop [] has joined #openttd
11:56<andythenorth>planetmaker: lots of those space cargos are awaiting Pikka's April 1st set
11:56<andythenorth>I think
11:56<andythenorth>maybe not though, he was keeping it secret
11:56<andythenorth>maybe they're easter eggs
11:56<andythenorth>twod is tropical wood yes / no?
11:57<andythenorth>stupid label :P
11:57-!-Brianetta [] has quit [Remote host closed the connection]
11:57<andythenorth>it has a different weight per unit or such I think? I read the code for it once
11:57<andythenorth>or I was smoking crack
11:57<frosch123>twod is armoured, so it does get stolen :p
11:58<andythenorth>nice list
11:59<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 )
11:59-!-Eddi|zuHause [] has quit [Remote host closed the connection]
11:59-!-Eddi|zuHause [] has joined #openttd
11:59<@planetmaker>yes, TWOD is. But those labels are there in the webpage since r0
11:59<@planetmaker>So... not sure :-)
12:00<andythenorth>I support it in FISH and HEQS
12:00<andythenorth>I think
12:00<@planetmaker>If I removed a cargo which is going to be used... Well. Wikis luckily have history
12:00<frosch123>planetmaker: i guess it was indeed proposed as default cargo, but somehow did not make it into the ttdp code
12:00<@planetmaker>I also added a note to state where that cargo label is to be used ;-)
12:00<@planetmaker>frosch123, TWOD?
12:00<frosch123>anyway, why do you want to remove labels from the wiki?
12:01<frosch123>i see no use in that
12:01*andythenorth wants to remove *classes* from the list of labels on the wiki
12:01<@planetmaker>long list of pointless labels?
12:01<andythenorth>the classes of a cargo are of *no* concern to vehicle authors
12:01-!-Prof_Frink [] has joined #openttd
12:01<frosch123>except for the xor mask
12:01<andythenorth>bloody mask :P
12:02<@Belugas>12:00h! LUNCH HOUR!!!!!
12:02<frosch123>and also the refit cb
12:02<TrueBrain>I am having dinner ...
12:02<@Belugas>andythenorth, Halloween is over , remove that mask...
12:02<frosch123>since you likely do not want to use all labels always
12:02<andythenorth>frosch123: not in the refit cb
12:02<@planetmaker>andythenorth, sure
12:02<andythenorth>if you want to support specific cargos, use a label
12:02<@planetmaker>classes are available there
12:02<@Belugas>enjoy TrueBrain :)
12:02*andythenorth is being black and white
12:02<frosch123>planetmaker: labels are never pointless
12:02<andythenorth>if you want to use classes to support a specific cargo You Are Doing It Wrong
12:03<andythenorth>very wrong
12:03<@planetmaker>frosch123, but they should state where they are used / come from
12:03<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
12:04<andythenorth>you just set the classes on your vehicles correctly
12:04<andythenorth>that's it
12:04<andythenorth>that's what classes are for
12:04*andythenorth is being black and white :P
12:04-!-HerzogDeXtEr [] has joined #openttd
12:04<andythenorth>if you care which vehicles coal, or pigs, or string go in, use their labels
12:04<andythenorth>otherwise don't care
12:05<andythenorth>this is the mistake we haz been making at some points
12:05<andythenorth>classes make no guarantee of appropriate vehicles, just that there's a chance the player will be able to transport unknown cargos
12:06*andythenorth doubts this will ever actually be the case
12:07-!-DayDreamer [] has quit [Read error: Connection reset by peer]
12:07<andythenorth>real world, we'll continue using classes as a shortcut
12:07<andythenorth>why set coal, iore, core, etc
12:07<andythenorth>just set bulk :P
12:07<@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
12:07<frosch123>so, you checked all vehicle grfs?
12:08<@planetmaker>No, I didn't. But the cargos have to be supplied by something
12:08<andythenorth>let's just remove some at random occasionally :)
12:08<@planetmaker>And those is much easier to check :-)
12:10<frosch123>andythenorth: also the list of classes is to supply examples
12:10<andythenorth>it helps cargo set authors
12:10<andythenorth>I accept that
12:10<andythenorth>and it guides vehicle set authors as to actual use of classes - in general
12:11<andythenorth>I just think it's part of the problme
12:12<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>"
12:12<andythenorth>not a bad move
12:12<@planetmaker>go for it :-)
12:13<@planetmaker>andythenorth, the classes of a cargo always have to be part of that table.
12:13<andythenorth>I know :(
12:13<@planetmaker>Even when they were used totally independent in refit algorithm
12:13<@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
12:13<andythenorth>but you see that they don't help the decoupling?
12:14<andythenorth>'when you have already catered for it via classes' <- but then classes may not be changed later as it 'breaks' sets
12:14<@planetmaker>it does neither. couple nor de-couple. It's simply specs for that particular cargo
12:14<andythenorth>specs can change
12:14<andythenorth>the sets don't "break", but the perception is they do
12:15<@planetmaker>"specs can change" is something usually not done with newgrfs ;-)
12:15<@Yexo>specs can't change without breaking backwards compatiblity
12:15<@planetmaker>"specs can be extended" - yes. That's different though
12:16<andythenorth>I accept that XOR means classes can't change
12:17<andythenorth>if that didn't exist
12:17<andythenorth>specs should be able to change
12:17<andythenorth>a set that is 'broken' due to a change of class on a cargo is not in fact 'broken'
12:17<andythenorth>it's working perfectly as intended
12:18<andythenorth>(assuming no XOR sadness)
12:18<@Yexo>I think you're right. Unfortunately we do have that "XOR adness" and we can't simply remove that
12:18<andythenorth>it's just hot air in that respect
12:18<andythenorth>so the correct answer is to change labels, not classes
12:18<andythenorth>thereby *really* annoying authors who have added label based support
12:19<@planetmaker>we could add two new properties, though... "transport-by-label" and "never-transport-by-label". Or similar
12:19-!-sla_ro|master [~slaco@] has joined #openttd
12:19<frosch123>speaking of mess... does firs now use SCRP or SCMT ?
12:19<frosch123>and are the classes acutally correct on the wiki?
12:19<@planetmaker>I still would advocate to revert to SCRP
12:19<@planetmaker>and just change the class :-P
12:19<andythenorth>the classes are currently correct
12:19<andythenorth>they were incorrect
12:19<andythenorth>SCRP was described as bulk, but was piece
12:19-!-pugi [] has joined #openttd
12:20<andythenorth>planetmaker: can we or can't we change classes? I am a small amount confused :O
12:21<andythenorth>FIRS labels + classes should never have been in that wiki :x
12:21<andythenorth>I explicitly put them on my site with a big health warning
12:21<andythenorth>and said that the code was the only canonical place during development
12:22<andythenorth>then they were added to the wiki not by me
12:22<@Yexo>andythenorth: putting it on your site instead of in the specs doesn't change a thing
12:22<frosch123>discussion will be interupted for while
12:22<@Yexo>it probably only means even less support from vehicle set authors
12:22<CIA-6>OpenTTD: frosch * r23136 /trunk/src/ (newgrf.cpp newgrf_spritegroup.cpp newgrf_spritegroup.h): -Change: [NewGRF v8] Deprecate old-style callback results 0xFF??.
12:22<andythenorth>Yexo: that's not a bad thing when it is < 1.0
12:22-!-Celestar [~dax@] has joined #openttd
12:22<CIA-6>OpenTTD: frosch * r23137 /trunk/src/ (articulated_vehicles.cpp newgrf_callbacks.h): -Change: [NewGRF v8] New result format for callback 16.
12:23<andythenorth>right now I get 10 kinds of trouble every time that gameplay shows a cargo needs adjusting
12:23<@Yexo>andythenorth: given the amount of users you ahve you can hardly call your current releases "development versions"
12:23<andythenorth>we don't know how many users there are :)
12:23<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.
12:23<andythenorth>there could be lots of downloads and no users
12:24<CIA-6>OpenTTD: frosch * r23139 /trunk/src/newgrf.cpp: -Change: [NewGRF v8] Do no longer apply base cost fallbacks.
12:24<CIA-6>OpenTTD: frosch * r23140 /trunk/src/ (4 files in 2 dirs): -Add: ErrorUnknownCallbackResult()
12:24<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)
12:24<CIA-6>OpenTTD: frosch * r23142 /trunk/src/ (9 files): -Change: [NewGRF v8] Unify the return values of callbacks returning D0xx texts.
12:25<CIA-6>OpenTTD: frosch * r23143 /trunk/src/newgrf_engine.cpp: -Change: [NewGRF v8] Return the translated cargobit in vehicle var 42.
12:25<CIA-6>OpenTTD: frosch * r23144 /trunk/src/newgrf.cpp: -Change: [NewGRF v8] Consider the 'default cargotype' properties as indices into the cargo translation table.
12:26<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.
12:26<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.
12:26<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.
12:27<CIA-6>OpenTTD: frosch * r23148 /trunk/src/ (8 files): -Change: [NewGRF] Check the results of various callbacks for validness.
12:27<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.
12:27<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.
12:28<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.
12:28<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.
12:28<CIA-6>OpenTTD: frosch * r23153 /trunk/src/ (newgrf.cpp newgrf.h newgrf_spritegroup.cpp): -Change: [NewGRF v8] Use heightlevel units in variable 20/A0.
12:29<CIA-6>OpenTTD: frosch * r23154 /trunk/src/ (9 files): -Change: [NewGRF v8] Use heightlevel units in nearby tile info variables. (rubidium)
12:29<CIA-6>OpenTTD: frosch * r23155 /trunk/src/newgrf_industries.cpp: -Change: [NewGRF v8] Use heightlevel units in var 8A of callback 28.
12:29<CIA-6>OpenTTD: frosch * r23156 /trunk/src/newgrf_engine.cpp: -Change: [NewGRF] Clamp height in aircraft variable 44.
12:29<CIA-6>OpenTTD: frosch * r23157 /trunk/src/newgrf_generic.cpp: -Change: [NewGRF v8] Format of extra callback info for callback 144. (michi_cc)
12:29<CIA-6>OpenTTD: frosch * r23158 /trunk/src/newgrf.cpp: -Feature: [NewGRF] Patch/setting variable 14. (rubidium)
12:30<CIA-6>OpenTTD: frosch * r23159 /trunk/src/newgrf.cpp: -Feature: Support for NewGRF version 8.
12:30<frosch123>discussion can continue :p
12:30-!-Celestar [~dax@] has quit [Read error: Connection reset by peer]
12:34<Eddi|zuHause>frosch123: any chance of slipping in a commit that splits the refit mask into two? (removing the weird XOR behaviour)
12:34<Eddi|zuHause>(probably unnecessary, though)
12:34<frosch123>No, the next thing will be a callback
12:37<CIA-6>OpenTTD: yexo * r23160 /trunk/src/ (10 files): -Fix: wrong comments in a lot of TileTypeProcs definitions
12:40<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
12:41<Eddi|zuHause> <-- i hereby officially deprecated the "GEAR" cargo :)
12:42<CIA-6>OpenTTD: frosch * r23162 /trunk/src/ai/api/ai_order.cpp: -Fix (r23133): Silence gcc warning.
12:44<frosch123>sorry, but what's all this deprecated fuzz about if noone sayd till now how to keep compatibility?
12:44<frosch123>GEAR is used in several sets of pikka
12:44<Eddi|zuHause>frosch123: i mean that as "these cargos are not used in any industry set"
12:45<Eddi|zuHause>frosch123: sure, but a wiki like this should reflect the "state of the art" technology, not some previous failed attempts
12:46<frosch123>GEAR is state of the art
12:46<andythenorth>how will Pikka provide regearing without a cargo to store the value in?
12:46<frosch123>imo a list of "deprecated" label is nonsense
12:46<andythenorth>it's not deprecated by Pikka
12:47<frosch123>labels are not used exclusively by a single set
12:47<andythenorth>it can only be deprecated in the context of a specific set, not everywhere
12:47<frosch123>they are defined forever
12:47<andythenorth>that's why I left SCRP in, but marked is as deprecated in FIRS :D
12:47<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"
12:48<andythenorth>Might be a better header for it
12:48<frosch123>"do not use these labels in a new set" is nonsense
12:48<andythenorth>I have no objection to splitting the list in principle
12:48<frosch123>why should an industry set only use defined cargos?
12:48<frosch123>if a industry set wants special tropic wood, why not?
12:49<andythenorth>it's fun that such a simple system can cause all of us so much headache :)
12:49-!-pjpe [] has joined #openttd
12:51<CIA-6>OpenTTD: yexo * r23163 /trunk/src/rail_cmd.cpp: -Fix [FS#4627]: don't display railway fences between track and waypoints (Krille)
12:51<frosch123>maybe we should protect the cargo page from edits for one month :p
12:51-!-|Jeroen| [] has joined #openttd
12:52<andythenorth>it's always best to have a wiki war to refine a spec no?
12:52<Eddi|zuHause>Yexo: breaking my fences patch?
12:52<@Yexo>could be
12:53<Eddi|zuHause>frosch123: i have not changed any actual information. just reordered the table.
12:53<andythenorth>in the wiki table of cargo labels - even if we have the classes, do we need the actual mask there?
12:53<andythenorth>you don't think "I want to add coal so I need to set the refit mask to *coal's classes*"
12:54<andythenorth>you should think "is my vehicle for bulk cargos"
12:55<Eddi|zuHause>andythenorth: it's redundant, but i don't see any harm...
12:55<andythenorth>encourages wrong thinking
13:01<Eddi|zuHause>frosch123: <-- better?
13:02*frosch123 hugs eddi :)
13:10<andythenorth>can we summarise proposed class changes yet?
13:11<andythenorth>remove all > bit 8 is not going to work?
13:12<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"
13:13<Eddi|zuHause>oh, and clarify "covered" to "pulverized, needs strict moist protection"
13:14<Eddi|zuHause>(i.e. "doesn't suffice to cover with a simple tarpaulin")
13:14<andythenorth>Eddi|zuHause: for the purposes of a vehicle set author, does 'pulverised' sufficiently overlap with 'needs pressure discharge'?
13:15<andythenorth>they'll be highly similar vehicles I would think
13:15<frosch123>Eddi|zuHause: there are lots of cargos on the wiki which need to be covered but are not pulverised
13:15<andythenorth>covered is invalid :P
13:15<Eddi|zuHause>frosch123: yes, my proposal removes that flag from those cargos
13:15<frosch123>basically every foodish stuff
13:15<frosch123>i don't think that is useful
13:16<frosch123>that's what pourable is for, isn't it?
13:16<andythenorth>so what's known / uncontentious?
13:16<andythenorth>remove hazardous
13:16<andythenorth>+ / - 1?
13:16<Eddi|zuHause>frosch123: "piece goods" and "covered" is nonsense, "piece goods" already implies "goes in closed wagons"
13:17<andythenorth>piece goods implies break-bulk cargo
13:17<andythenorth>covered is nonsense because anything can be covered easily
13:17<Eddi|zuHause>at least if we follow MB's UIC-class-system
13:18<Eddi|zuHause>frosch123: the difference between "pourable" and "pulverized" is that "pourable" goes into hopper wagons, and "pulverized" goes into silo wagons
13:18<Eddi|zuHause>frosch123: when pulver gets wet, it cannot be unloaded anymore. aside of potential chemical reactions
13:19<Eddi|zuHause>frosch123: when pourable cargo gets wet, it just is wet
13:19<andythenorth>Eddi|zuHause: you mean powder?
13:19<andythenorth>the typical transport term for the vehicles would be 'powder wagon'
13:20<Eddi|zuHause> <-- from the second post of the thread
13:21<andythenorth>real world examples :P
13:21<CIA-6>OpenTTD: frosch * r23164 /trunk/src/roadveh_cmd.cpp: -Fix (r23149): Default roadvehicles became somewhat short.
13:22<Eddi|zuHause>(from today's DBSet teaser)
13:23<frosch123>[19:17] <andythenorth> covered is nonsense because anything can be covered easily <- it is about "must be covered", not "can be covered" :p
13:23<andythenorth>but my vehicle can provision a cover if it must be covered :)
13:23<andythenorth>it is not a problem
13:23<andythenorth>it makes more sense in the way that eddi is implying - the cargo needs moisture protection etc
13:24<frosch123>so, it should go along "clean" ?
13:24<frosch123>in a separate property "cargo misc flags"
13:24<andythenorth>do that and you open a can of worms
13:24<andythenorth>actually in my mind it's clearly not a flag
13:24<andythenorth>it's about the vehicle not the cargo
13:25<andythenorth>the 'clean' flag is a flag because it's about the cargo needing the vehicle to be clean
13:25<frosch123>well, but the vehicle should know whether it shall draw the cargo covered
13:25<@peter1138>it's about the cargo needing the vehicle to be covered
13:25<andythenorth>clean is a refitting *cost* issue not a refitting issue
13:25<Eddi|zuHause>a tarpaulin for covering also costs :)
13:25<andythenorth>'clean' is a mutable property of the vehicle
13:26<andythenorth>so is covered I guess :P
13:26<andythenorth>but not quite the same way
13:27<Eddi|zuHause>anyway, it's obvious that there's still lots of room for discussions
13:28<Elukka>huh. dbset has development again?
13:29<andythenorth>looks nice
13:30<andythenorth>Eddi|zuHause: frosch123 planetmaker
13:31-!-Wolf01 [] has joined #openttd
13:31<frosch123>Elukka: release of dbset 0.9 was scheduled for 11-11-11, i.e. in 3 days. but has now been postponed again
13:32<frosch123>due to new features
13:32<Elukka>i see
13:32-!-MeSaber [] has joined #openttd
13:33-!-MeSaber [] has left #openttd []
13:36-!-TWerkhoven[l] [] has joined #openttd
13:39-!-andythenorth [] has quit [Quit: andythenorth]
13:41-!-Brianetta [] has joined #openttd
13:43-!-TGYoshi_ [~TGYoshi@] has joined #openttd
13:46<CIA-6>OpenTTD: translators * r23165 /trunk/src/lang/ (7 files): (log message trimmed)
13:46<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:46<CIA-6>OpenTTD: dutch - 14 changes by habell
13:46<CIA-6>OpenTTD: english_US - 27 changes by Rubidium
13:46<CIA-6>OpenTTD: finnish - 28 changes by jpx_
13:46<CIA-6>OpenTTD: german - 4 changes by planetmaker
13:46<CIA-6>OpenTTD: italian - 27 changes by lorenzodv
13:46-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
13:46-!-HerzogDeXtEr [] has joined #openttd
13:47-!-TheMask96 [] has quit [Ping timeout: 480 seconds]
13:49-!-TGYoshi [~TGYoshi@] has quit [Ping timeout: 480 seconds]
13:53-!-TheMask96 [] has joined #openttd
13:54-!-Alberth [] has joined #openttd
13:54-!-mode/#openttd [+o Alberth] by ChanServ
13:55-!-supermop [] has quit [Quit: supermop]
13:59-!-rhaeder1 [] has quit [Quit: Leaving.]
14:05<Eddi|zuHause> <-- moved FUEL to deprecated as well (if i understand the comment right)
14:06<Eddi|zuHause>now only COPR has no indication on which set actually uses it
14:07-!-andythenorth [] has joined #openttd
14:08<frosch123>ask pikka
14:08-!-pjpe [] has quit [Quit: ajax IRC Client]
14:08<frosch123>pbi had fuel or petr or whatever
14:08<frosch123>ukrsi maybe as well
14:09-!-JVassie [~James@] has joined #openttd
14:09<__ln___>oh no! berlusconi will resign.
14:10<andythenorth>'covered' might be better as 'sensitive to weathering'
14:11<andythenorth>covered confuses
14:11<andythenorth>is it for including or excluding?
14:11<andythenorth>should I set covered on all vans?
14:11<andythenorth>should I exclude covered on all open vehicles?
14:11<andythenorth>'sensitive to weather' gets closer to how most authors will want to use it - for covered hoppers, silos
14:12<Eddi|zuHause>the old "covered" means something like "must have roof or tarpaulin over it", while the new/proposed one is way stricter
14:12<andythenorth>the old covered seems of minimal use
14:12<Eddi|zuHause>exactly, hence my proposed change
14:13<Eddi|zuHause>the new covered makes only sense for bulk/"uncountable" cargo
14:13<andythenorth>agreed - but there's no need to try and force that :)
14:13<andythenorth>on the old covered, with OR classes, as cargo set author I might as well set it
14:13<Eddi|zuHause>well, yes, the rules must be stated as clearly as possible
14:14<andythenorth>because everything can be covered - and "where's the harm?"
14:14<andythenorth>which makes it useless
14:14<Eddi|zuHause>exactly that should be prevented...
14:14<Eddi|zuHause>you're already interpreting things differently than i am
14:15<andythenorth>'sensitive to weather' or similar is open to similar interpretation?
14:15<andythenorth>if I set that for coal cargo, does it look right or wrong?
14:18<Eddi|zuHause>maybe "covered" is completely wrong, and it should really be named "powderized"
14:18<andythenorth>that might work
14:18<andythenorth>all cargos are sensitive to weather to some extent, but it's only significant for a small number
14:19<andythenorth>would that sweep up 'requires pressure' as well?
14:19<@peter1138>and the date... is 2023-11-08 19:20
14:19<andythenorth>most powder tankers are either gravity or pressure discharge, but at TTD scale they'll look the same
14:19<Eddi|zuHause>that's imho fairly irrelevant at TTD-scale
14:19<@peter1138>the ongoing cargo class discussion was never resolved, and still continues...
14:20<andythenorth>and you can carry grain in a pressure discharge vehicle
14:20<andythenorth>peter1138: you could run a book on how many classes we add
14:20<andythenorth>...or remove
14:20<@peter1138>classes are meant to be ... general
14:20<@peter1138>they're for the fallback case
14:21<andythenorth>labels = specific case
14:21<Eddi|zuHause>andythenorth: if you take my example wagons, then adding "powderized" for grain will disallow grain in hopper wagons
14:21<andythenorth>don't conflate the fallback with "I'm too lazy to add known labels and want to just use classes"
14:21<Eddi|zuHause>andythenorth: which feels somewhat wrong, as there were specialized hopper wagons for grain
14:21<andythenorth>Eddi|zuHause: why will it do that? Grain is a known cargo
14:22<Eddi|zuHause>andythenorth: have as few exceptions as possible. having a 32 cargo limit or not is irrelevant for that rule
14:23<andythenorth>Eddi|zuHause: remove the 'pressure discharge' requirement? I don't care about it
14:23<andythenorth>it was your request MB answered :P
14:23<andythenorth>Eddi|zuHause: actually I see your point
14:23<andythenorth>there's no fricking answer to the grain problem :D
14:23<CIA-6>OpenTTD: michi_cc * r23166 /trunk/src/newgrf.cpp: -Change: [NewGRF v8] Don't override rail type prop 1B with prop 09.
14:24<andythenorth>either you want to set 'foo' on grain to make it weather sensitive, or you don't
14:24<andythenorth>you can't have both routes with classes
14:24<andythenorth>grain is appropriate for weather protection so I'd set the class
14:24<andythenorth>what the vehicle author does with that is up to them
14:25<andythenorth>or the class needs to get dropped
14:25<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)
14:26<andythenorth>what known cargos are moisture sensitive?
14:26<andythenorth>I suspect it's a useless class and should be removed
14:26<Eddi|zuHause>in my list it's LIME, SULP and FERT
14:27<andythenorth>honestly? :)
14:27<Eddi|zuHause>but not GRAI/WHEA/MAIZ/CERE or CLAY
14:27<andythenorth>seems like another case of 'author has own views' :)
14:27<andythenorth>I can find n pictures of limestone in open wagons or hoppers
14:28<andythenorth>Fertiliser is also piece goods and also travels in open wagons
14:28<Eddi|zuHause>andythenorth: well, the approach was different. my thought was "what goes in that kind of wagon?"
14:30<Eddi|zuHause> <-- this wagon is listed as: "Kalk, Kalkmergel, gemahlenem Kalkstein,
14:30<Eddi|zuHause>staubfeine Soda, staubfeines Steinsalz, und Gesteinstaub;
14:30<Eddi|zuHause>auf Antrag und mit Zustimmung des Wagenbüros auch für andere geeignete Güter."
14:30<andythenorth>if you're describing a new scheme, fine :)
14:31<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"
14:31<andythenorth>the fallback case provided by classes explicitly rules out the kind of support you're after
14:31<andythenorth>the only concern is to try and ensure *some* vehicles provide transport
14:31-!-|Jeroen| [] has quit [Quit: oO]
14:32<andythenorth>therefore we should drop as many classes as possible, because more classes increases the likelihood of XORs preventing new cargos being carried
14:32<andythenorth>see BEER and eGRVTS for example
14:32<Eddi|zuHause>what's the problem there?
14:32-!-andythenorth [] has quit [Read error: Connection reset by peer]
14:32-!-andythenorth [] has joined #openttd
14:32<andythenorth>stupid wifi
14:33<Eddi|zuHause>what's the problem in eGRVTS?
14:33<andythenorth>doesn't support BEER
14:33<andythenorth>we set too many classes
14:33<andythenorth>they get XORed
14:33<Eddi|zuHause>i meant WHY?
14:33<andythenorth>FIRS broke classes
14:34<Eddi|zuHause>what exactly is wrong?
14:34<andythenorth>there are no vehicles to carry BEER in eGRVTS
14:34-!-Adambean [] has quit [Quit: Gone fishing]
14:34<andythenorth>I don't know what's wrong :)
14:34<andythenorth>I have no idea
14:34<andythenorth>zeph probably knows
14:35<andythenorth>we could find out - we have the code in the repo I think
14:35<Eddi|zuHause>if people would stick to the rules i put up in my proposal, such things shouldn't happen anymore
14:35<Eddi|zuHause>maybe the rules should be more clear
14:35<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
14:36<Eddi|zuHause>the problem is not the classes
14:36<andythenorth>nearly all of FIRS class changes are to try and retrospectively support a specific vehicle set
14:36<Eddi|zuHause>the problem is that everybody has a slightly different opinion of what they mean
14:36<andythenorth>yes that
14:36<andythenorth>and also maybe Zeph set them wrong
14:36<Eddi|zuHause>quite likely
14:37<Eddi|zuHause>likely something like excluding Express in the Liquid wagon, and excluding Liquid in the Express wagon
14:37<andythenorth>as the code is undocumented nfo with almost no formatting, I have desire to look
14:39<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"
14:39-!-brundlefly [] has joined #openttd
14:39<andythenorth>express is only valid for piece goods?
14:41-!-George|2 [~George@] has joined #openttd
14:41-!-George is now known as Guest16305
14:41-!-George|2 is now known as George
14:42-!-KritiK [] has joined #openttd
14:42<andythenorth>Eddi|zuHause: would you set 'foo' (moisture whatever) for grain?
14:42<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'"
14:43<Eddi|zuHause>andythenorth: i wouldn't
14:44<Eddi|zuHause>i should write a lengthy article over my reasonings...
14:44<CIA-6>OpenTTD: rubidium * r23167 /trunk/src/ (tunnel_map.cpp tunnel_map.h): -Codechange [FS#4818]: make IsTunnelInWay z parameters signed as well (hackalittlebit)
14:44<andythenorth>Eddi|zuHause: I wouldn't either
14:45<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'
14:47<andythenorth>but if you did add it to grain, grain would still travel by open hopper
14:47<andythenorth>because you're xor on that class would be wrong
14:47<andythenorth>your / you're /s
14:47<andythenorth>the 'powder' is a 'may' not a 'must'
14:48<Eddi|zuHause>that's a design decision. if we want to have grain in that category, the categories must be rearranged
14:48-!-Guest16305 [~George@] has quit [Ping timeout: 480 seconds]
14:48<CIA-6>OpenTTD: yexo * r23168 /trunk/ (9 files in 4 dirs): -Feature [FS#1824]: always draw fences around field tiles
14:49-!-pjpe [] has joined #openttd
14:49<andythenorth>is it clear though? If we keep the current scheme, you don't exclude 'foo' (powders) from open hoppers
14:49<andythenorth>you exclude bulk from silos
14:49<andythenorth>and rely on 'foo' to get those cargos into silos
14:50<andythenorth>or rather, you don't include bulk for silos
14:50-!-DayDreamer [] has joined #openttd
14:50<Eddi|zuHause>yes, because my assumption is that any cargo that sets "silo" also sets "bulk"
14:50<andythenorth>(stupid implicit / explicit excludes) :\
14:50<Eddi|zuHause>so checking for that is redundant
14:51<andythenorth>it's just redundant because it's redundant
14:51<andythenorth>the classes are OR
14:51<@peter1138>multistop docks!
14:51<@peter1138>vehicles in vehicles!
14:51<Eddi|zuHause>it's made redundant by some additional requirements on set design that i put up
14:51<andythenorth>peter1138: roadtypes
14:52<Eddi|zuHause>that currently do not hold for the existing cargos
14:52<andythenorth>and also: mornington crescent
14:52*andythenorth would like to claim £5
14:52<Eddi|zuHause>that won't work if set designers do not follow these rules
14:52<andythenorth>does that matter?
14:53<andythenorth>if they do it wrong, they're wrong
14:53<andythenorth>or they have their own ideas on cargo transport
14:53<Eddi|zuHause>it must first be explained/clarified in a way that makes certain they are wrong
14:53<andythenorth>good point
14:53<andythenorth>as long as we're clear that wrong is possible, and the class scheme can do nothing about that :P
14:54<Eddi|zuHause>eGRVTS cannot be "wrong" on the BEER matter, because it was not specified properly
14:54<andythenorth>I would not file "cargo set designer does not like your vehicle choices" under wrong
14:54<andythenorth>I would file "you failed to provide adequate fallbacks due to xyz" as wrong
14:55<andythenorth>I would file "trying to support specific cargos by classes" as wrong
14:56<andythenorth>I would file "I can't be bothered to setup label based support, please change your set classes" as wrong
14:57<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
14:58<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
15:03<andythenorth>I would also file "trying to reuse existing labels in your cargo set, but you have different intentions" as wrong
15:09<Eddi|zuHause>yes. "if in doubt, add new label"
15:09<Eddi|zuHause>but the "environment" was different back then
15:10<andythenorth>the case when we started FIRS was 'reuse labels to get a better chance of cargo support'
15:10<andythenorth>which just implied classes were being used wrong
15:10*andythenorth wishes he had known that
15:12<andythenorth>it's a shame that refittability can't be simply determined by the action chain for cargo label support
15:13<andythenorth>i.e. action 3 - action 2 graphics chain
15:14<andythenorth>i.e. if the label is known in the action 3 (via CTT), refit to it
15:15<andythenorth>otherwise fallback to classes
15:22-!-supermop [] has joined #openttd
15:24<Qantourisc>How hard is it to make an gprs file ?
15:27-!-Zuu [] has joined #openttd
15:27<Rubidium>what is a gprs file?
15:27<Eddi|zuHause>andythenorth: there's probably some hysterical raisin for that
15:27<andythenorth>general packet radio scheme?
15:27<andythenorth>Eddi|zuHause: it was a dumb suggestion, but I've just convinced myself it's smart
15:28<Qantourisc>I mean NewGRF
15:28<@Yexo>Read and decide for yourself
15:28<Eddi|zuHause>Qantourisc: somewhere between 3 lines and 27000 lines
15:29<appe>im bored with ottd.
15:29-!-Kurimus [] has quit []
15:29<Zuu>write a patch
15:29<@Yexo>or an AI, or a NewGRF ;)
15:30<Zuu>Or improve TutorialAI by writing a new chapter :-)
15:30<Qantourisc>I was wondering, why you don't get fined for slow deliveries :)
15:30<@Yexo>Zuu: I wanted to commit FS#4700 earlier today, only it didn't apply at all
15:30<Rubidium>Qantourisc: you get fined
15:30*Zuu goes and looks what FS#4700 is
15:31<@Yexo>New AIConfig flag: AICONFIG_AI_DEVELOPER - hides setting unless user have gui.ai_developer_tools = 1
15:31<andythenorth>grf v8: decide refittability by looking first at labels in action 3
15:31<Eddi|zuHause>@fs 4700
15:31<Qantourisc>Rubidium: ow ? didn't notise yet, but i mean fined as: getting -$$$ for your delivery
15:31<Rubidium>Qantourisc: you get way less than when you transport it much quicker
15:31<Zuu>Yexo: Oh, so you also liked my idea :-)
15:31<Eddi|zuHause>andythenorth: how do you exclude specific cargos then?
15:31<appe>got tips on any simple but interesting grf i can try?
15:31<Rubidium>and at a certain point the payment dropoff gets steeper
15:32<@Yexo>Zuu: yes, just never got around to it before
15:32<@Yexo>and now I did, it completely fails to apply
15:32<Rubidium>it's just not that visible
15:32<andythenorth>Eddi|zuHause: what's the case for that (I am trying to think, you may be faster)
15:32<andythenorth>I see the case
15:32<Qantourisc>Rubidium: I mean going below zero for a delivery :p
15:32<Zuu>Yexo: I'll take a look at it.
15:32<Rubidium>Qantourisc: income - running cost being less than zero is a "fine" enough to me
15:32<@Yexo>Qantourisc: in which case it would be better not to deliver the cargo at all, which is stupid
15:33<andythenorth>Eddi|zuHause: reuse the existing refit mask, interpret it only as 'not'
15:33<andythenorth>or better, use a cb, remove the <32 limit
15:34<Qantourisc>Yexo: no, in that case it's best to reroute the dam thing, or sell straight away, to prevent further losses
15:34<Qantourisc>I was wondering how to make things harder in later gameplay
15:34-!-rhaeder [] has joined #openttd
15:35<Qantourisc>A fine for late deliveries would help, as it gets worse when your network grows
15:35<Qantourisc>"Altered costs and prices" might already cut it though didn't try yet
15:36<andythenorth>did I miss the grf v8 shipping window?
15:39<Eddi|zuHause>andythenorth: there's a window until december-ish
15:41<andythenorth>would my action 3 - labels proposal actually work?
15:41<andythenorth>or am I smoking crack?
15:42<appe>i just found the wedish trainset
15:42<andythenorth>they're not really returned as results are they from action 3
15:42<appe>that's fantastic
15:42<andythenorth>they're just branches
15:44*andythenorth tries to guess how things work that he has absolutely no idea about
15:49-!-Andel [] has quit [Remote host closed the connection]
15:52<Eddi|zuHause>andythenorth: i'm sure that it's programmatically possible to do, but that doesn't mean it's sensible
15:57<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.
15:57<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
15:58<@Yexo>Zuu: of course
15:58<@Yexo>sorry, I should have realized that myself
15:58<Zuu>Only Hunk #2 in table/settings.ini applies with a offset (38 lines) all other changes applies exactly.
15:59<@Yexo>right now I'm looking at the crash savegame from the forum, after that I'll compile/test/commit your patch
16:00<Zuu>Good. That crash save game is kind of interesting.
16:00<Zuu>At least it is for me non-obvious what the problem is.
16:01<Zuu>With that savegame I have now ran into a type offset problem. Not sure exactly what visual studio mean by that.
16:01<Zuu>Sorry, not type offset. But "Datatype misaligment"
16:02<@Yexo>I got a gpf on a local (stack-based) variable, that should also never happen except when overflowing the stack
16:03<Zuu>Indede, my call stack is probably also overflown as it is constantly calling itself (_qsort)
16:03<@Yexo>that wasn't what I got
16:04<@Yexo>it wasn't in _qsort, at least I don't think so
16:04<@Yexo>running it again now in a debug build, this is going to take a while
16:04<Zuu>I'm in "bool SQVM::StartCall(SQClosure *closure,SQInteger target,SQInteger args,SQInteger stackbase,bool tailcall)" when the datatype misaligment happened.
16:04<Zuu>However, it has been stuck in _qsort for long time and my call stack is filled with it.
16:04<@Yexo>could be the same them, I clicked it away
16:05<@Yexo>about 40minutes before it'll reach november
16:10<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
16:10-!-DDR_ [~chatzilla@] has joined #openttd
16:11<andythenorth>well maybe he was right :D
16:13<Zuu>Yexo: Is _current_company updated to be the AI company that is currently being executed?
16:13<Zuu>It has value 7 according to my debugger.
16:14<@Yexo>yes, that should be correct
16:16<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.
16:17<andythenorth>frosch123: I looked in the topic I think you're referring to...
16:17<andythenorth>that must be the wrong thread
16:18-!-Alberth [] has left #openttd []
16:34-!-sla_ro|master [~slaco@] has quit []
16:35-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
16:36<andythenorth>frosch123: found it :)
16:40-!-sla_ro|master [~slaco@] has joined #openttd
16:43<@Yexo>Zuu: the new savegame you posted is still running on November 10th
16:44<Zuu>Hmm, mine crashed at the date I wrote (with farm binary r23126)
16:46<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.
16:47<Zuu>That is. _date == 734808
16:47<TGYoshi_>So.. any way to reduce train ´breakdowns´? There are so many :/
16:47<Zuu>To be able to run the AI step by step, still the vm is quite hard to read what it is doing :-)
16:47<Eddi|zuHause>TGYoshi_: difficulty settings => breakdowns "reduced" or "off"
16:48<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)
16:48<TGYoshi_>Thanks, they were on ´Reduced´ already tho, still breaking multiply times on a rail..
16:49<Eddi|zuHause>TGYoshi_: maybe you didn't service your vehicle often enough, or it's already very old
16:49-!-sla_ro|master [~slaco@] has quit []
16:50<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. :-)
16:50<TGYoshi_>It even happens with a new train on a new game :P
16:50<@Yexo>you can use it now already by defining the constant in info.nut
16:50<Zuu>Oh. Good point.
16:50<TGYoshi_>And for some reason the pathfinding of the trains is really mutated
16:51-!-Progman [] has quit [Remote host closed the connection]
16:51<CIA-6>OpenTTD: yexo * r23170 /trunk/src/ai/api/ai_changelog.hpp: -Doc (r23169): add he new value to the AI changelog
16:53-!-sla_ro|master [~slaco@] has joined #openttd
17:05-!-aglenday [~Impatient@] has joined #openttd
17:11-!-DayDreamer [] has quit [Read error: Connection reset by peer]
17:12<Eddi|zuHause>"south korea switches email from port 25 to 587 - to block spammers"
17:15<andythenorth>Eddi|zuHause: "#openttd blocks mention of cargo classes" :D
17:16-!-valhallasw [] has joined #openttd
17:21<Zuu>Yexo: Good spot.
17:21<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 :-)
17:21<@Yexo>it actually is a stack overflow in most cases
17:22<@Yexo>depends on how the initial array is sorted
17:23<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?
17:23<@Yexo>unless you have 80GB stack space :p
17:23<Zuu>Is that what is requried for this problem? :-)
17:23<@Yexo>I think those 9 minutes were from the start until he reached the crash date
17:23<@Yexo>at which time it takes a while to actually crash
17:24<Zuu>Oh, 9 minutes on non-fast-forward :-)
17:24<@Yexo>well, sorting an already sorted array of 50000 items will result in 50000**2 recursive calls
17:24<@Yexo>say each of those takes 32 bytes of stack space (and that is very conservative) you need 80GB
17:25<@Yexo>not to mention a lot of patience
17:25<Zuu>and a 64bit build
17:26<Eddi|zuHause>use heapsort
17:27<@Yexo>I'm very tempted to disable the sort() function and reimplement it in squirrel
17:27<Eddi|zuHause>has better worst case than qsort, and better space usage than mergesort
17:28<Zuu>Yexo, when you use AIList.Sort, is it also using _qsort?
17:28<Eddi|zuHause>so... and who tried to tell me that AIs cannot cause this?
17:28<@Yexo>someone without knowledge
17:28-!-valhalla1w [~valhallas@] has joined #openttd
17:29<@Yexo>AIList has a custom sort algorithm
17:30-!-valhalla2w [] has joined #openttd
17:30<@Yexo>haven't looked at it in detail for a long time, it's some variant of bucketsort I believe
17:30<Zuu>Perhaps it is a good idea to make those comparable in performance?
17:30<Eddi|zuHause>we've had several cases already where somehow some AIs managed to get around the opcode restrictions
17:31<Zuu>It is quite easy as there are some states an AI can be when it can't be suspended.
17:31<Zuu>Eg. when squrrel calls one of your functions.
17:31<Zuu>Eg. when you call .Valuate or using sort with a comparator.
17:32<Zuu>So in a such function you can make an infinity loop, and then OpenTTD can't do anything against that.
17:32<@Yexo>Zuu: AIList.Sort() doesn't call any squirrel functions
17:32<@Yexo>only .Valuate does, but you could implement that one in squirrel
17:33<Zuu>Indeed. The problem is not if you want to make something that works.
17:33<@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
17:33-!-TGYoshi_ [~TGYoshi@] has quit [Quit: Poof]
17:35<Zuu>Sounds like a good solution. I wonder how many more functions there are in addition to sort().
17:36-!-valhallasw [] has quit [Ping timeout: 480 seconds]
17:36-!-valhalla1w [~valhallas@] has quit [Ping timeout: 480 seconds]
17:38<@Yexo>most problematic will be the other meta-functions like _get and _set
17:38<@Yexo>I don't see a way to implement support for those completely in squirrel
17:40<@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
17:40-!-valhalla2w [] has quit [Ping timeout: 480 seconds]
17:41<Zuu>Hmm, I don't think I've used _get or _set, so I didn't knew they were calling your own functions.
17:41<@Yexo>the pathfinder libraries use them
17:42<@Yexo>if you did "local costobj = Rail.Cost(); costobj.something = 3;" the _set function would be called with idx == "something"
17:42<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.
17:43-!-HerzogDeXtEr1 [] has joined #openttd
17:44<Zuu>So before making those very expansive the path finder would need a re-design.
17:44<@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
17:44<@Yexo>well, for the pathfinder it's not so important
17:45<@Yexo>it's only for setting the costs, which is usually done only once per pathfinding action
17:45<@Yexo>ie a few ticks more or less won't be noticed
17:46<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?
17:46<@Yexo>f it is to stop a possible security issue that somone evil can write an AI that freezes/crashes OpenTTD <- that
17:47<Zuu>Then, you would need to completely forbid them I think, as a clever attacker could exploint the hole in just one go.
17: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
17:48<@Yexo>much like the problem we just found on the forum
17:49-!-andythenorth [] has left #openttd []
17:49<Zuu>Okay, in that case, the idea of counting expansive calls and giving feedback (by haning or providing stats) is a possible route.
17:49-!-HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
17:56<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.
17:59<@Yexo>I haven't yet tried to
18: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.
18:02<Zuu>The AI before in execution order is IdleAI, and the one after BorkAI is SimpleAI.
18:02<@Yexo>I have confirmed earlier it was company 7, and that is BorkAI
18:03-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
18:03-!-Elukka [] has quit []
18:04<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
18:05<@Yexo>even if we could suspend the vm while it was in native code, that wouldn't have helped us in this case
18:05<@Yexo>since all the runtime is within a single c++ function
18:06<Zuu>would a separate thread/process work that could be killed forcefully if the AI takes way too long?
18:06-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
18:06<Zuu>It would still run the AIs in sequence, but just have the separate thread to be able to kill it.
18:06<@Yexo>a separate thread is very tricky, since if you kill it from outside you can easily leak memory
18:07<Zuu>But I guess that would complicate things a lot.
18:07<Eddi|zuHause>not killed. suspended/resumed by time slice
18:07<@Yexo>Eddi|zuHause: suspending at the wrong moment might cause a lot of trouble
18:07<@Yexo>I'm not sure how safe all the API functions are
18:08<@Yexo>Eddi|zuHause: and you always need a way to kill such a thread forcefully if you want to end the game
18:08-!-TWerkhoven[l] [] has quit [Remote host closed the connection]
18:11-!-TWerkhoven2 [] has quit [Quit: He who can look into the future, has a brighter future to look into]
18:12-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
18:14-!-Brianetta [] has quit [Quit: Tschüß]
18:17<@Yexo>Zuu: main.nut:871
18:17<@Yexo>the code befores makes a lst of all possible routes
18:18<@Yexo>which is done by matching for each cargo every industry that produces it to every industry that accepts that cargo
18:18<Zuu>Okay, feel free to post that to the BorkAI thread to get all your clever points :-)
18:19<Zuu>.. not that it would be my role to say anything against you doing that ...
18:20<@Yexo>I didn't see your post there yet
18:20<Zuu>I though it would be a good idea to infrom the AI author.
18:22-!-mahmoud [] has quit [Ping timeout: 480 seconds]
18:31<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
18:33-!-Yexo is now known as Guest16325
18:34-!-Guest16325 is now known as Yexo
18:39-!-MNIM [] has joined #openttd
18:43-!-sla_ro|master [~slaco@] has quit []
18:44<frosch123>i bet grandma threw aways grandpa's toys
18:52<__ln___>dear magicians, is the line (0,2,1)+t(3,1,0) a subspace of R^3? not?
18:54<@planetmaker>good night
19:01<Eddi|zuHause>__ln___: no
19:01-!-supermop [] has quit [Quit: supermop]
19:01<Eddi|zuHause>__ln___: subspaces must contain (0,0,0)
19:04<__ln___>that's what i was suspecting based on google
19:06<__ln___>curiously the material by our lecturer only explicitly lists two criteria for subspaces; addition and multiplication with a scalar
19:06-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
19:07<frosch123>that is enough
19:07<frosch123>try multiplication with the scalar 0
19:11-!-appe [] has quit [Read error: Connection reset by peer]
19:11-!-appe [] has joined #openttd
19:12<Eddi|zuHause>what's the point of magic if you state everything explicitly :p
19:25<Mazur>Hm, a steam train going 0 m/h in front of a green signal.
19:27<Mazur>Anyonme awake who knows what could cause that? It's on the Welcome server. (1.1.3)
19:27<Eddi|zuHause>there's a minimum speed of 1
19:27-!-tty234 [] has quit [Remote host closed the connection]
19:28<Eddi|zuHause>otherwise: upload the savegame to the bugtracker
19:28<Mazur>Yes, it simply isn;t going, but not "stopped".
19:34-!-Zuu [] has quit [Ping timeout: 480 seconds]
19:51<CIA-6>OpenTTD: frosch * r23171 /trunk/src/train_cmd.cpp: -Fix (r23142): Fix comment.
19:56<TrueBrain>yes sir
19:56<TrueBrain>wait, you are not my boss
19:56*TrueBrain hugs frosch123
19:56<Eddi|zuHause>good morning, TrueBrain :)
19:56<TrueBrain>no, good night
19:57<TrueBrain>it is evening
19:57<TrueBrain>sun is down
19:57<TrueBrain>time to sleep
19:57<TrueBrain>what are you doing up? :P
19:57<frosch123>TrueBrain: what?
19:57<Eddi|zuHause>sun is already closer to going up than going down
19:57<Mazur>Just uploaded the savegame, I think, made a bug report, not sure if I set a proper subject.
19:57<TrueBrain>frosch123: nothing :) Your commit message: "Fix comment." :P
19:57<TrueBrain>it made me want to troll .. and so I did :)
19:58<frosch123>i thought a few second whether to write "Fix" a second time
19:58<TrueBrain>it is funny :)
19:58<TrueBrain>I made the commit: Fix the fix that shoudl fix the fix for real this time
19:58<TrueBrain>a few days back
19:58<TrueBrain>with a -Fix tag, of course
19:59<TrueBrain>right, off to bed; night all :)
19:59<Mazur>Sleep well.
20:00<TrueBrain>well, thank you. You too, for when ever you go to bed :)
20:01<Eddi|zuHause>TrueBrain: were you involved in uploading "Lost Girl" then? with a "REAL", "REALLY REAL" and "FINAL PROPER" tag or something? :p
20:01<Mazur>Good question, I have no idea.
20:08<Mazur>Ah, it was trying to go the lother way, the company owner had not arranged his right of way.
20:17-!-KritiK [] has quit [Quit: Leaving]
20:31-!-frosch123 [] has quit [Remote host closed the connection]
20:52-!-blotek_ [] has joined #openttd
20:59-!-blotek [] has quit [Ping timeout: 480 seconds]
21:19-!-HerzogDeXtEr1 [] has quit [Read error: Connection reset by peer]
21:46-!-Lachie [] has quit [Ping timeout: 480 seconds]
21:57-!-Lachie [] has joined #openttd
22:10-!-blotek_ [] has quit [Ping timeout: 480 seconds]
22:24-!-rhaeder1 [] has joined #openttd
22:30-!-rhaeder [] has quit [Ping timeout: 480 seconds]
23:01-!-glx [glx@2a01:e35:2f59:c7c0:91d7:24c2:f473:6f05] has quit [Quit: bye]
23:05-!-Lachie [] has quit [Ping timeout: 480 seconds]
23:15-!-Lachie [] has joined #openttd
---Logclosed Wed Nov 09 00:00:03 2011