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