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

---Logopened Sun Nov 06 00:00:55 2011
00:40-!-glx [glx@2a01:e35:2f59:c7c0:9970:a62c:7355:30f2] has quit [Quit: bye]
01:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
01:56-!-Eddi|zuHause [] has joined #openttd
01:48-!-Kurimus [] has joined #openttd
02:16-!-sla_ro|master [slaco@] has joined #openttd
02:50-!-andythenorth [] has joined #openttd
02:56-!-Rob110178 [] has quit [Ping timeout: 480 seconds]
03:01*andythenorth ponders
03:01<Rubidium>... breakfast?
03:02-!-Rob110178 [] has joined #openttd
03:03<andythenorth>good idea
03:04<andythenorth>also - how to allow changing newgrf parameters without inserting a small bomb into various bits of openttd
03:05-!-Rob110178 [] has quit [Remote host closed the connection]
03:09<andythenorth>enable / disable vehicles in buy menu for one example
03:09<andythenorth>change running costs for another
03:10<andythenorth>specific hooks for this in openttd seems wrong
03:10<andythenorth>but verifying generic code to show it doesn't cause kaboom seems impossible
03:11<andythenorth>and changing a parameter in one grf might be safe....
03:11<andythenorth>...but another grf might decide to disable, then...kaboom!
03:12<Terkhen>good morning
03:13<andythenorth>what possible good case is there for a grf to disable itself based on *parameters* of another grf?
03:13<@peter1138>andythenorth, one way to do it is to store the complete state of everything before and after the change
03:13<@peter1138>of course, it'll be different, otherwise there wouldn't be a parameter
03:14<@peter1138>so it's unsafe :P
03:14<andythenorth>I suppose I could code a vehicle that depended on a vehicle in another set for some complex reason
03:14<andythenorth>and then I might want to disable my grf if the vehicle is not available
03:15<andythenorth>but there's maybe a better way to do that
03:15<andythenorth>or I might insist that you can't play my grf unless you also have FISH present, with running costs set to High...
03:15<andythenorth>...because you must only play the game the way I choose
03:16<andythenorth>so basically we have tens of newgrf authors writing explodey code against other people's code, which could be changed at any time.
03:16<Terkhen>yes :D
03:16<andythenorth>how many grfs are known to disable based on other grfs parameters?
03:17<@peter1138>it's not just other grfs
03:18<@peter1138>say, a parameter that causes vehicles in the set to be different
03:18<@peter1138>heh, dbsetxl does that without a parameter anyway :p
03:18<@peter1138>(wagon speed limits)
03:18<andythenorth>different how?
03:18<andythenorth>(different in ways that lead to 'kaboom')?
03:19-!-Progman [] has joined #openttd
03:19<@peter1138>why do you want parameter changing so bad?
03:19<andythenorth>I like it :)
03:20<andythenorth>why do I want anything so bad :P
03:20<@peter1138>you like changing parameters mid-game?
03:20<andythenorth>I do it quite often
03:20<@peter1138>how weird
03:20<andythenorth>mostly I like the idea that players can turn off my stupid HEQS vehicles
03:21<@peter1138>that is going to break
03:21<andythenorth>it's fine
03:21<andythenorth>just change the climate byte
03:21<andythenorth>proven tactic
03:21<Terkhen>they can also turn them off by not playing with the NewGRF
03:22<@peter1138>or they can just not use them
03:22<andythenorth>true indeed
03:22<andythenorth>the other one is running costs
03:22<Terkhen>I don't know much about the differences between different GRF versions, but would making all dates extended be possible and/or desirable?
03:22<andythenorth>'running costs' and 'buy costs' parameters are springing up like daisies
03:22<andythenorth>but they make setting up a game an exercise in accounting
03:23<andythenorth>start game, write down costs for all the grfs you want to use, test a bit
03:23<andythenorth>end game, setup new game with new combination of parameters
03:23<andythenorth>test again
03:23<@peter1138>well tell the set authors not to do silly things
03:23<andythenorth>like run cost parameters?
03:24<Terkhen>why are those silly?
03:24<andythenorth>well they are
03:24<andythenorth>they're silly because they're not actually useful
03:24<andythenorth>unless you have newgrf developer tools on
03:24<andythenorth>they're kind of pointless to most players imho
03:25<Terkhen>you can always set them up correctly before starting the game
03:25<andythenorth>what's "correct" though? Without testing?
03:25<Terkhen>you need to test, of course
03:25*andythenorth invents a 'transformation layer' which sits between grf and game, and allows player to change things which are safely mutable
03:26<andythenorth>e.g. openttd provides a 'tweak costs' gui for each and every grf that defines things base costs
03:26<@peter1138>personally i prefer to play the game
03:27*andythenorth prefers to poke at newgrf code :P
03:30-!-TWerkhoven [] has joined #openttd
03:42-!-Neon [] has joined #openttd
03:46-!-Elukka [] has joined #openttd
03:53-!-Hyronymus [] has joined #openttd
04:05-!-TWerkhoven2 [] has joined #openttd
04:10<andythenorth>changing cargo classes in a FIRS nightly...
04:10<andythenorth>is that savegame-breaking enough to require a version bump?
04:12-!-TWerkhoven [] has quit [Ping timeout: 480 seconds]
04:18<andythenorth>it's a nightly
04:21<Terkhen>what cargo classes are you changin?
04:22-!-JVassie [~James@] has joined #openttd
04:26<andythenorth>plant fibres
04:26<andythenorth>maybe lumber (not sure)
04:26-!-DayDreamer [] has joined #openttd
04:26-!-Alberth [] has joined #openttd
04:26-!-mode/#openttd [+o Alberth] by ChanServ
04:26-!-Zuu [] has joined #openttd
04:27<Terkhen>IMO the cargos that are shared with other sets should also share cargo classes, otherwise you will break many sets supporting FIRS
04:28<Terkhen>unless they are not sharing cargo classes already :P
04:29<andythenorth>I am going to unshare one or more classes
04:29<andythenorth>classes / labels /s
04:29<andythenorth>trying to reuse labels was not entirely wise
04:29<Elukka>why not keep compatibility? i mean, i don't get the fundamental importance of whether scrap is piece goods or bulk or whatever
04:30<andythenorth>Terkhen: we tried to reuse some labels for some cargos, but the cargos are not the same, which leads to lots of head-scratching about whether classes are broken :P
04:30<andythenorth>(if that makes sense)
04:30<andythenorth>the problem is mostly that FIRS has been doing it wrong
04:30<andythenorth>the class system, and all the current definitions are exactly right
04:31<Terkhen>I see, then you should not change cargo classes, you should add new cargo labels
04:31<Terkhen>but that will be confusing too :)
04:31<Terkhen>I tend to agree with Elukka
04:32<Elukka>unless there's something that really doesn't make sense, i guess
04:32-!-Devroush [] has joined #openttd
04:33<andythenorth>Terkhen: I'm going to add new labels where they are needed, and change classes where that's not going to break anything
04:34<Terkhen>why are those changes needed?
04:36<andythenorth>because they have the wrong classes ;)
04:37<Terkhen>and? it works
04:37-!-Pulec [] has joined #openttd
04:37<CIA-6>OpenTTD: rubidium * r23123 /trunk/src/openttd.cpp: -Fix [FS#4790] (r22792): variable was initialised at the wrong moment making things with the cursor go wrong
04:38<andythenorth>not really
04:38<andythenorth>it requires vehicle set authors to add FIRS specific support, which is bad behaviour by FIRS
04:38<Terkhen>in which cases is that happening?
04:39<andythenorth>scrap, plant fibres
04:39-!-Zuu [] has quit [Ping timeout: 480 seconds]
04:40<andythenorth>lumber is a different weird case that is probably not going to change
04:40<andythenorth>also wood
04:41<andythenorth>and sugar cane
04:41<Terkhen>wood is different from vanilla wood?
04:41-!-Zuu [] has joined #openttd
04:41<@peter1138>reusing labels? hmm
04:41<Terkhen>also, plant fibres is shared, in which way is it different?
04:41<andythenorth>plant fibres is bulk in ECS
04:41<andythenorth>but not bulk in FIRS
04:42<@Yexo>that is really bad
04:42<Terkhen>andythenorth: if you plan to change cargos, take your time and choose a definitive scheme
04:42<andythenorth>I did
04:43<andythenorth>you missed yesterday ;)
04:43<Terkhen>I have to say that it wasn't very difficult for me to add FIRS support to ogfx-rv
04:43<Terkhen>so I don't see many reasons for change
04:43<andythenorth>this won't break vehicle set support, it's class based
04:43<Terkhen>if it has to be changed... keep it simple :P
04:44<andythenorth>if "classes may never be changed" then classes are broken
04:44<@Yexo>why would classes ever change?
04:44<@Yexo>and yes, in principle classes should never change
04:45<Terkhen>the point is to give vehicle set authors a fixed frame for implementing cargo support :P
04:45<@Yexo>a vehicle includes and excludes some classes, than adds specific support for cargos not in those classes
04:45-!-mahmoud [] has joined #openttd
04:45<@Yexo>if one of those cargo's was sudenly in an included class the special case would suddenly disable instead the cargo (it's a xor-mask)
04:46<@Yexo>so basically whenever the cargo classes of a cargo change you tisk breaking vehicle set support
04:47<andythenorth>in that case I'm still confused :(
04:47-!-Cybertinus [] has joined #openttd
04:48<andythenorth>what is the point of classes at all?
04:48-!-mahmoud [] has quit []
04:48<andythenorth>do they do anything useful?
04:48<@Yexo>to provide some future compatibility
04:49-!-mahmoud [] has joined #openttd
04:49<@Yexo>if sets use cargo classes correctly vehicle sets can support cargos that don't exist at the time they were made
04:49<andythenorth>it just seems very broken to me :(
04:49<andythenorth>it makes no sense
04:49<@Yexo>not with special graphics, but by having at least one wagon that can transport them
04:50<andythenorth>somewhere there is something very wrong about this system
04:50<andythenorth>it's basically unusable :(
04:52*andythenorth is depressed by it
04:52<Terkhen> <--- with cargo classes I can define some "generic" containers; if a new cargo that fits any of them is created later, I don't need to implement support for it in my vehicle set
04:53<Terkhen>this assumes that cargo classes for existing cargos are fixed, and that new cargos specified correctly will appear later
04:53<Terkhen>if old cargos change their cargo classes, my set might lose support for them
04:53<andythenorth>^ that means classes are broken fundamentally
04:54<Terkhen>broken how?
04:54*andythenorth tries to explain
04:54<andythenorth>it's really clear in my head
04:54<@Yexo>why are they broken? If cargoclasses had been used correctly from the beginning there would never be a need to change them for existing cargos
04:54<andythenorth>the point of classes is to provide abstraction between vehicle sets and cargos?
04:55<@Yexo>partly, and partly to provide future compatibility with new cargos
04:55<andythenorth>so when creating a vehicle newgrf, an author has two sets of cargo to consider: 'known' and 'unknown'
04:55<andythenorth>the set of 'known' cargos are in the wiki, and have labels
04:55<andythenorth>we use classes to provide support for 'unknown' cargos
04:56<andythenorth>at this point if we have cargo A in the known set, and I code my vehicle grf all is good
04:56<andythenorth>later cargo B appears, and is in the unknown set
04:56<Terkhen>ideally, most if not all of the known cargos should also be supported via cargo classes
04:56<andythenorth>I've set classes that can support cargo B
04:56<andythenorth>now cargo A is changed, moving it into the 'unknown' set
04:56<andythenorth>and suddenly everything goes 'boom' ?
04:56<@Yexo>andythenorth: since the refit properties are limited to the first 32 cargos from the cargo translation table, quite a lot of known cargos are also supported via classes
04:57<@Yexo><andythenorth> now cargo A is changed, moving it into the 'unknown' set <- it only goes in the "unknown" set if it gets a new label
04:57<@Yexo>if you just change the classes the vehicle set still has it in the "known" set but makes wrong assumptions about it
04:57<andythenorth>so to preserve the abstraction, the label must change? sounds reasonable
04:57<@Yexo>if you chagne the label you effectively create a new cargo
04:58<andythenorth>in which case that sounds like a very valid solution
04:58<@Yexo>that means you have to specific cmopatibility in existing sets, so no special graphics etc.
04:58<@Yexo>but if the vehicle sets are than updated they can easily support both the old and the new label
04:59<andythenorth>so none of us are smoking crack it seems
05:00<andythenorth>this means I need to figure out a migration path for each of the cargos that will change
05:00<andythenorth>which is fine
05:01<andythenorth>versioned cargo labels anyone? :P
05:01*andythenorth will bbl
05:02<andythenorth>thanks for the help
05:02-!-andythenorth [] has quit [Quit: andythenorth]
05:07-!-pjpe [] has quit [Quit: ajax IRC Client]
05:09-!-DDR_ [~chatzilla@] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20111008085652]]
05:11-!-snack2 [] has joined #openttd
05:14-!-DayDreamer [] has quit [Read error: Connection reset by peer]
05:14-!-DayDreamer [] has joined #openttd
05:17-!-pugi [] has joined #openttd
05:18-!-Spl1nt [] has joined #openttd
05:19<Spl1nt> site ever lol guys lets u send 10 free texts a day anywhere in the world free and anonymous .. if u sign up u get 50 ... i just sent 50 txts to a m8 lol he shit brix
05:19-!-Spl1nt [] has left #openttd []
05:26<TrueBrain>who in this world is still interesting in that? YOU ARE OLD Spl1nt! :P
05:26*Alberth cannot even read it
05:38-!-Wolf01 [] has joined #openttd
05:38<Wolf01>lol, it's peter's hour here
05:42<TrueBrain>it is?
05:42<Elukka>huh. never ran into irc spambots before
05:43-!-KouDy [] has joined #openttd
05:45<Wolf01>TrueBrain, sure: -> [11:38:44] <Wolf01> lol, it's peter's hour here
05:48-!-Hyronymus [] has quit [Remote host closed the connection]
05:50-!-KouDy1 [] has joined #openttd
05:50-!-KouDy [] has quit [Quit: Leaving.]
05:53-!-hanf [] has joined #openttd
05:57<Wolf01>it would be possible to get the railtype with the query tool? with 8 railtypes I can't remember which one I used 6 months ago to build the line and they look enough similar to me
05:58<Wolf01>ok, maybe if I enable the visualisation of catenary I only have to choose between 4 types
05:58-!-frosch123 [] has joined #openttd
06:12<Qantourisc>Wolf01: wait 8 types ?
06:15<Qantourisc>i don't understand nutracks :/
06:15<Qantourisc>Wolf01: a workaround is trying to replace ... but that sounds bad
06:17<Wolf01>np, I found it by trying to build a diagonal piece aside of an existing diagonal piece (a crossing would have worked too)
06:20<@Alberth>Wolf01: sounds like a useful thing to have
06:23<Qantourisc>Why is the train waiting ?
06:23<Qantourisc>isn't the other path "good enough" ?
06:24<Qantourisc>or is it because the other paths are "more costly" ?
06:24<Wolf01>did you built the station with running trains?
06:25<Qantourisc>"with running trains" ?
06:25<Qantourisc>Hmmm i added road to increase the cost... and it took the other entrence now ...
06:25<Wolf01>connected/removed a piece while a track was reserved
06:25<Qantourisc>I added some road
06:25<Qantourisc>and now he picks the other one
06:26<Qantourisc>he must always pick the cheapest path then ?
06:26<Qantourisc>(when trying to pass)
06:26<Qantourisc>One for FAQ i quess ...
06:26<Wolf01>the pathfinder always looks for the cheapest path
06:26<Qantourisc>Can i upload that picture ?
06:26<Qantourisc>or is it too ugly ? :)
06:27<@Yexo>Qantourisc: have you tried also placing path signals directly after the platform?
06:28<Qantourisc>wouldn't that make the central stations even MORE cheap ?
06:28<Qantourisc>Bad design i know though :)
06:28<@Yexo>it'd make the central platform free when there is a train waiting after the station, like in your image
06:28<@Alberth>what problem are you solving?
06:29<Qantourisc>The train not taking the green path
06:29<@Yexo>as long as there is a train that platform the cost is very high because all tiles are occupied
06:29<@Alberth>why not?
06:29<@Yexo>I'm not sure if the pathfinding stops at the end of the station or if it continues to the next signal
06:29<@Yexo>if the latter, placing signals at the end of the platforms would help
06:29<Qantourisc>Yexo: aa like that ... that might actually work :)
06:30<@Alberth>Yexo, Qantourisc: path signal blocks stop at the next signal
06:30<Qantourisc>a ok good
06:30<Qantourisc>fixed :)
06:30<@Yexo>Alberth: yes, but that's not the problem
06:31-!-DOUK [] has joined #openttd
06:31<@Yexo>the question is where the pathfinder stops adding costs to the route
06:31<@Yexo>at the end of the platform or at the first signal after the platform
06:32-!-KouDy [] has joined #openttd
06:32<Qantourisc>presignal doesn't seemt to be affected by this though
06:32<Qantourisc>Yexo: when you place them close it works.
06:32<@Yexo>if you use presignals you force a train to take any exit signal that is green, regardless whether it leads to it's destination or not
06:32<@Alberth>the former sounds illogical to me tbh, but I am not even sure what problem is being solved :)
06:33<@Yexo>I agree it sounds somewhat illogical, but if placing signals close the station works that might be it
06:36-!-mahmoud [] has quit [Ping timeout: 480 seconds]
06:36*Alberth does not see what conclusion is being drawn, but that's ok :)
06:38-!-KouDy2 [] has joined #openttd
06:38-!-KouDy1 [] has quit [Ping timeout: 480 seconds]
06:40-!-KouDy2 [] has quit [Read error: Connection reset by peer]
06:40-!-KouDy [] has quit [Ping timeout: 480 seconds]
06:41-!-KouDy [] has joined #openttd
06:51-!-KouDy1 [] has joined #openttd
06:53-!-KouDy2 [] has joined #openttd
06:56-!-KouDy [] has quit [Read error: Connection timed out]
06:59-!-andythenorth [] has joined #openttd
06:59-!-KouDy1 [] has quit [Ping timeout: 480 seconds]
07:03-!-KritiK [] has joined #openttd
07:05*andythenorth wonders what label to set for 'new' scrap metal
07:05<andythenorth>SCPM perhaps?
07:09<frosch123>packaged scrap metal? :p
07:10<@Alberth>SCRAP :)
07:10<@Alberth>hmm, too long :(
07:11<@Alberth>what's wrong with 'metal' ?
07:12<andythenorth>Alberth: could use metal
07:12<andythenorth>be a bit of an odd chain...deliver metal to the steel works to get metal...
07:12<andythenorth>one solution would be to delete the scrap metal cargo
07:12<andythenorth>this would free a cargo slot and solve the class problem
07:12<@Alberth>yeah, you want to distinguish between shiny new metal and rusty old ones
07:12<andythenorth>and I could remove an industry
07:13-!-KritiK [] has quit [Quit: Leaving]
07:15<@Alberth>it'd be easy money, deliver produced metal back to the same industry :)
07:15<andythenorth>you'd only get 4t out for your 8t in :P
07:15<@Alberth>or find 2, and transport back and forth, just like passengers :)
07:16<andythenorth>another solution would be to swap the unit to 'crates' instead of 't'
07:16<andythenorth>and leave it as piece goods
07:16<andythenorth>enforcing 'piece goods = crates', 'bulk = t' might have been a fun idea
07:16<@Alberth>do you have a paper chain, that has the same problem
07:16<andythenorth>clearly 'liquid = l' already
07:17<andythenorth>Alberth: no paper chain :D
07:17-!-blotek [] has joined #openttd
07:18*Alberth proposes SCMT for scrap metal
07:18<andythenorth>I'll add it to the wiki, and deprecate SCRP
07:19<@Alberth>but it does not really matter, does it? almost any 4 letters will do
07:19<andythenorth>pretty much
07:19-!-KritiK [] has joined #openttd
07:21<andythenorth>this will be interesting
07:22<andythenorth>I'll need to update HEQS to the new cargo. Which means it will lose support for the old scrap metal cargo
07:22<andythenorth>I don't have enough CTT slots spare for backward compatibility
07:23<andythenorth>it also means we now have two cargos called "Scrap Metal" listed in the wiki
07:24*andythenorth shrug
07:26<@Yexo>if the cargo classes are now correct, you wouldn't need to have the new (or old) scrap metal in the first 32 entries of your CTT
07:27<andythenorth>I have some vehicles which explicitly support scrap metal (and not much else)
07:27<andythenorth>so they need scrap in the refit mask
07:28-!-Brianetta [] has joined #openttd
07:38<andythenorth>I've broken FIRS
07:38<andythenorth>changing the cargo label from SCRP to SCMT breaks the build
07:39<andythenorth>nmlc: "sprites/nml/industries/recycling_plant.pnml", line 128: Unrecognized identifier 'SCRP' encountered
07:39<@Yexo>if you change the label in your CTT you also have to change all places where you use it
07:40*andythenorth ...grep
07:40<@Yexo>and don't forget to change the cargo property that sets the label
07:40<andythenorth>I think I did that :)
07:40<andythenorth>that's probably *all* I did so far :P
07:41<@Yexo>nah, you changed at least the cargo translation table too, or you wouldn't get that error
07:42<andythenorth>find + replace in just one file = fail :)
07:42<andythenorth>now I need to figure out how to add new classes
07:43<andythenorth>Yexo: are cargo classes defined in FIRS code, or are they an nml macro?
07:43<@Yexo>the cargo property "cargo_classes" (it's in cargo_props.pnml)
07:44<yorick>r23115 forgot to remove a comment
07:44<@Yexo>cargo_classes: bitmask(CC_PIECE_GOODS); <- only piece goods
07:44<@Yexo>cargo_classes: bitmask(CC_PIECE_GOODS, CC_BULK); <- both piece goods and bulk
07:44<andythenorth>so if I need to define CC_NEO_BULK...?
07:44<@Yexo>list of constants:
07:44<yorick>network_admin.cpp#234 should've been removed I think
07:45<@Yexo>you'd need to either define that via cpp "#define CC_NEO_BULK 13" (to use bit 13) or change the nml code
07:45<andythenorth>I should probably just do it in FIRS for now
07:45<andythenorth>want to test it to see what might go wrong
07:46*andythenorth needs to learn to differentiate constant and macro in nml
07:46<andythenorth>are macros always callable - ie. FOO()
07:47<@Yexo>a constant is simply a number in nml
07:47<@Yexo>macros are supported by gpp, not by nml
07:47<andythenorth>so when I'm reading code - how do I distinguish one from the other?
07:47<andythenorth>otherwise I ask the wrong question
07:47<@Yexo>3 <- that's a constant
07:48<andythenorth>and #define FOO = 3 is a define which will be replaced by the constant
07:49<@Yexo>ABC <- that can either be a define that gpp handles, or it's an identifier. An identifier is handled by nml and can actually be a lot of things. There are a lot of known identifiers that nml maps to a constant
07:49<@Yexo>like CC_PASSENGERS is mapped by nml to 0
07:49<andythenorth>ok, I think that's why I find FIRS code so hard to understand
07:49<andythenorth>all my previous code only used defines and includes, not anything else
07:49<@Yexo>think of the named nml constants as "#defines"
07:50<@Yexo>nml has a lot of buildins, like "#define CC_PASSENGERS 0"
07:50<@Yexo>gpp also supports parameters for defines, and in that case you can "call" them
07:50<andythenorth>ok so that's all fine, I just need to remember to say 'constant' instead of 'define'
07:50<@Yexo>like: "#define ABC(a) (a + a)
07:51<@Yexo>if you than write "ABC(5)" later it's replaced by "(5 + 5)"
07:51<@Yexo>that's all done by the preprocessor, nml than later simplifies that 5+5 to 10
07:51<andythenorth>so that's fairly dumb string replacement?
07:51<andythenorth>nothing is calculated?
07:51<@Yexo>not by the preprocessor
07:52<@Yexo>nml does calculate whatever it can at compile-time, so there is no problem with that
07:52<@Alberth>yorick: it is an extra explanation what is happening there
07:52<@Alberth>we have more such comments
07:52<@Yexo>it doesn't matter if you write "1+1+1+1" or "4", it'll result in exactly the same nfo/grf
07:52<yorick>Alberth: except r23115 made it not happen anymore
07:53<yorick>or am I mistaken?
07:53<andythenorth>hmm compile time compilation calculation is a brave new world
07:56<@Alberth>yorick: if (ci == NULL) return NETWORK_RECV_STATUS_OKAY; is still there, and the cs->GetInfo() seems to have moved up to the caller context
07:57<@Alberth>I'd say the comment is about that 'if', not about the info getting
07:59<yorick>this->SendClientInfo(NULL, NetworkClientInfo::GetByClientID(CLIENT_ID_SERVER)); <-- it uses the info of the server
08:00*andythenorth puzzles over refit masks :0
08:00<andythenorth> 1D 10 00 // Refittable cargo classes
08:00<andythenorth> 1E EF 0B // Non-refittable cargo classes
08:00<andythenorth>I've set a class to use bit 11
08:00<@Alberth>yorick what else can you do with cs == NULL ?
08:00<andythenorth>so the mask above should give me bulk, excluding nearly everything else?
08:00<@Alberth>previously that would have crashed
08:01<yorick>Alberth: it isn't called with ci == NULL anywhere
08:01<yorick>I think the if should be changed to an assert
08:02<yorick>(or can their be NULL cis in FOR_ALL_CLIENT_SOCKETS?)
08:02<__ln__>yorick: are you still porting OpenTTD to C#?
08:02<andythenorth>Yexo: #define CC_NEO_BULK 11 would give me a class on bit 11? I don't need to escape it? Or set 800 or anything?
08:02<@Yexo>andythenorth: that gives you all cargos that are bulk but not in any other class
08:03<yorick>__ln__: I wasn't
08:03<@Yexo>andythenorth: no, that's enough
08:03<@Yexo>bitmask(a) does that for you
08:03<andythenorth>failing for me right now
08:03<yorick>__ln__: I dislike C#
08:03<@Yexo>bitmask(4) == 0x10, bitmask(5) == 0x20, bitmask(4, 5) == 0x30 etc.
08:04*andythenorth tests
08:04<@Yexo>cargo_classes: bitmask(CC_NEO_BULK); <- that should work after your define
08:05<andythenorth>and if there are two classes, they're comma separated for that prop?
08:05<andythenorth> cargo_classes: bitmask(CC_BULK, CC_NEO_BULK);
08:06<andythenorth>FIRS appears to be setting them
08:06<andythenorth>HEQS appears not to be paying attention to bit 11
08:06<andythenorth>if I set 1E to FFFFh, it still doesn't exclude SCMT
08:07<@Yexo>if you set 1E to FFFFh it shouldn't be able to carry anything
08:07<@Yexo>except for those cargos you specially allow
08:07<@Alberth>yorick: it may depend on whether you consider the admin part 'someone trying to query the server'. (which it is not, I think)
08:07*andythenorth tests a bit more
08:08<@Alberth>is it 1 ?
08:08<yorick>the comment is confusing :-)
08:08<andythenorth>let's try setting prop 16 to \wx00
08:09<@Alberth>yorick: it is english text, which is ambiguous by definition :)
08:09<andythenorth>my vehicle disappeared from the buy menu
08:09<yorick>SendClientInfo shouldn't be called with ci == NULL, but it surely shouldn't fail silently if it is
08:09<andythenorth>I guess 00000000h for prop 16 causes it to be hidden
08:09<@Yexo>if it can't carry anything (which you just accompliished) it's indeed removed from the buy menu
08:09<andythenorth>so I have to have at least one type refittable?
08:10<andythenorth>I can't just rely on classes
08:10<@Yexo>it's 0 for prop 16 in combination with FFFh for prop 1E
08:10<@Yexo>you can rely on classes
08:10<@Yexo>but you disabled every class, and than didn't enable any cargos
08:10<@Yexo>that means no cargos at all
08:10<andythenorth>this makes sense
08:10<andythenorth>this is fun :)
08:11<andythenorth>ok so if I set 1D to 1000h and 1E to EFFFh I get...
08:11<andythenorth>all the bulk cargos
08:11<andythenorth>including SCMT, which also has bit 11 set for neo-bulk
08:11<andythenorth>so the excluding isn't working :P
08:11<andythenorth>or I'm not setting neo-bulk correctly :)
08:11<@Yexo>that's actually get you all covered cargo
08:12<@Yexo>hmm, wait
08:12<@Yexo>1D to 1000h enables all neo-bulk
08:12<andythenorth>it's possible that all my words have the wrong endian order
08:12<@Yexo>most likely
08:12<andythenorth>and I might have just been lucky so far
08:12<@Yexo>how you write it in your nfo?
08:13<@Yexo>1000h = 00 10 in nfo
08:13<andythenorth> 1D 10 00 // Refittable cargo classes
08:13<@Yexo>or \wx1000
08:13<andythenorth> 1E EF FF // Non-refittable cargo classes
08:13<andythenorth>it's been like this for about 2 years :P
08:13<@Yexo>10 00 in fno is usually written as 0010h
08:13<@Yexo>but that indeed enables all bulk
08:13<@Yexo>and 1E EF FF disables everythingcept bulk
08:14<@Yexo>so you should only get cargoes that have bulk and no other classes set
08:14<andythenorth>so plausibly, bit 11 is not being set by the cargo?
08:14*andythenorth thinks how to check
08:14<@Yexo>could you send me your patch for firs?
08:17*andythenorth will be embarrassed if it's a typo :o
08:17<@Yexo>the patch looks fine
08:18<andythenorth>have you got HEQS checked out?
08:18<@Yexo>not yet, but can easily do taht
08:19<andythenorth>try editing any of the mining truck refits
08:19<andythenorth>hopefully obvious where / how :)
08:19<@Yexo>ok, will try
08:27-!-Biolunar [] has joined #openttd
08:29-!-Adambean [] has joined #openttd
08:34-!-valhallasw [~valhallas@] has joined #openttd
08:35-!-sla_ro|master [slaco@] has quit []
08:37-!-valhalla1w [] has joined #openttd
08:43-!-valhallasw [~valhallas@] has quit [Ping timeout: 480 seconds]
08:54-!-Brianetta [] has quit [Remote host closed the connection]
09:00<@Yexo>andythenorth: "1D 10 00" "1E EF FF" works fine for me
09:00-!-Rezt [] has joined #openttd
09:00<andythenorth>I must be doing something wrong :)
09:00<@Yexo>not refitable to scrap metal, but is refittable to bauxite, clay, coal, grain, iron ore, sand, stone and sugar beet
09:01<@Yexo>"16 00 00 00 00" <- I set prop 16 to zero for this test
09:01<@Yexo>that can cdhange all those cargos of course
09:02*andythenorth might need a facepalm emoticon
09:03<andythenorth>perhaps /me should try a vehicle that *isn't* articulated :P
09:04<andythenorth>sorry :o
09:04-!-snack2 [] has quit []
09:05-!-glx [glx@2a01:e35:2f59:c7c0:b91c:6cfd:c68b:ee15] has joined #openttd
09:05-!-mode/#openttd [+v glx] by ChanServ
09:15-!-Celestar [] has joined #openttd
09:19*andythenorth wonders if a set of refitting conventions should be written and stuck in the wiki
09:21<supermop_>sounds like a plan
09:22<Terkhen>as soon as you get an agreement on said conventions :P
09:23<andythenorth>if they could be baked in, then there's less headache
09:23<andythenorth>maybe nml could encapsulate them, with some constant where you specify vehicle type
09:23<andythenorth>and that's then expanded at compile time
09:24<andythenorth>and if you want more detail, learn about the magic of the three different props that control refit :)
09:24<andythenorth>there's only so many common types of road/rail vehicle
09:26<andythenorth>flat bed, stake truck / bulkhead flat, open truck, box van with doors, hopper / dump truck, tanker, covered hopper / silo
09:26<andythenorth>covered flat wagon (full width doors or curtain sides)
09:27<andythenorth>what did I miss?
09:28*andythenorth updated the wiki with new classes
09:33*andythenorth ponders rearranging HEQS cargo translation table
09:34<andythenorth>I don't refit anything to 'armoured', so I have slots wasted with VALU, GOLD, etc
09:36<Eddi|zuHause>CETS has two parts for the translation tables, first the cargos that are used in refit lists, and second part the cargos that are needed for special graphics
09:37<Eddi|zuHause>although the whole scheme may need some retouching after an actual test game
09:38-!-pugi [] has quit [Ping timeout: 480 seconds]
09:39-!-pugi [] has joined #openttd
09:40<Eddi|zuHause>looks like this:
09:44-!-Celestar [] has quit [Ping timeout: 480 seconds]
09:45<Eddi|zuHause>a closed wagon then has a refit mask of: piece,expr,-pass,-overs,-liqu,BEER,MILK,-LVST
09:47<Eddi|zuHause>not sure what "expr" is actually used for, might want to leave that out
09:51-!-Sigvatr [sig@] has joined #openttd
09:51<Sigvatr>is the nearest town to a station the local authority?
09:52<Sigvatr>i tried doing lots of advertising in the nearest town but my rating won't go up
09:52<Sigvatr>its like 30% now
09:53<TWerkhoven2>use the query tool on nearby land
09:53<TWerkhoven2>in some odd cases, it might not be the town it seems
09:54<Sigvatr>fuck that game
09:54<Sigvatr>maybe i should try and keep the stations closer to town centers
09:54<Sigvatr>how do you improve a station rating if it isn't near a town?
09:54*Alberth gives Sigvatr the 'erase from HD' tool.
09:55<Sigvatr>haha no not the whole game
09:55<@Alberth>provide good service
09:55<Sigvatr>just that one i was playing
09:55<@Alberth>always have a train collecting cargo, do fast delivery of the cargo
09:55<Zuu>Also mind that the station location is where the sign is.
10:02-!-Celestar [] has joined #openttd
10:13-!-KOPOBA [] has joined #openttd
10:13<KOPOBA>hello what font and size of font you use for ottd? cant choose =(
10:13<Zuu>You can in your openttd.cfg
10:14<KOPOBA>yes i can
10:14<KOPOBA>but cant choose
10:15<yorick>KOPOBA: helvetica? droid sans may be ideal for the size too
10:15<Zuu>I'm on Windows and us e"Tahoma" as small font. For the others, I use the default font.
10:15<KOPOBA>yep helvetica is ok i think
10:17-!-Celestar [] has quit [Remote host closed the connection]
10:17-!-Celestar [] has joined #openttd
10:17<KOPOBA>and what numbers you advice for 1024x768 ?
10:18*Alberth uses standard openttd font at 1280x1024
10:19<Zuu>KOPOBA: What is your screen size?
10:19<Zuu>17 or 19" ?
10:20<Zuu>Unless you have problem with your eye sight, the medium and large font is probably okay to use the built in font.
10:20<Zuu>For small, a good size is 10.
10:21<Zuu>If you need the custom font for russian characters, then try with the default sizes and see if they are good. If not change and try again.
10:21<KOPOBA>what deffault size ottd use?
10:22<Zuu>For small I think it is 8
10:22<Zuu>medium := 10, large := 16 IIRC
10:23<KOPOBA>ok rhanks
10:24-!-Rezt [] has quit [Quit: Computer has gone to sleep.]
10:30<Sigvatr>i verified that a farm was under a local authority of the nearby town
10:30<Sigvatr>i bought advertising again and nothing happened
10:30<Sigvatr>what the fuck is wrong with this game
10:31-!-DOUK [] has quit [Quit: Quitte]
10:31<Sigvatr>it worked in the past
10:32-!-mahmoud [] has joined #openttd
10:32<@Yexo>your station is probably not close enough to the town center
10:32<@Yexo>the only thing advertizing does it giving a temporary boost in station ratings for station close the to town
10:32<frosch123>advertising only works for stations close to the center
10:33<frosch123>so most stations near industries are not affected by any advertising
10:33<CIA-6>OpenTTD: michi_cc * r23124 /trunk/src/vehicle_cmd.cpp: -Change: [NewGRF] Interpret the result of the refit cost callback as a signed value.
10:34<frosch123>the advertising is restricted to stations with a manhattan distance <= 10 from the town center
10:34<frosch123>(distance between town and station sign)
10:34<@Yexo>doesn't that depend on advertizing size?
10:35<frosch123>oh, indeed
10:35<frosch123>10 for small, 15 for med, 20 for large
10:35<frosch123>i thought it only had an effect on the amount
10:35<andythenorth>so is it acceptable to extend classes on a default cargo, e.g. adding 'clean' to grain etc?
10:36<andythenorth>and if yes, should that be done in ottd, or just industry sets
10:36<Eddi|zuHause>the ingame description should probably be more verbose
10:37<Sigvatr>and how does a farm produce 90 cows a month
10:37<Sigvatr>they grow on cow trees
10:38<andythenorth>'clean' is on bit 12, unless anyone knows a reason it shouldn't b
10:38<Eddi|zuHause>not 90 cows. 90 tons of cow
10:38<Eddi|zuHause>when a cow weighs several tons, you get fewer cows
10:39<frosch123>Eddi|zuHause: no, 90 items of livestock
10:39<frosch123>it's a piece cargo, not builk
10:39<andythenorth>it should be neo-bulk :P
10:39<Eddi|zuHause>hm, ok
10:40<andythenorth>actually livestock are a good indicator
10:40<andythenorth>you can move cows in open wagons, or cattle trucks
10:40<andythenorth>but you don't move them in box vans
10:40<frosch123>@calc 3/16
10:40<@DorpsGek>frosch123: 0.1875
10:41<andythenorth>although in Smokey and the Bandit 2, they moved an elephant in a box trailer
10:41<frosch123>one cow actually only weights 187 kg
10:43*andythenorth does an experiment
10:43<andythenorth>wondering what happens if you set a class no vehicle sets know about
10:43<andythenorth>but you have vehicles that refit anything
10:43<andythenorth>the answer is not good :P
10:43-!-dihedral [] has quit [Ping timeout: 480 seconds]
10:44-!-dihedral [] has joined #openttd
10:45<frosch123>if the set authors were clever enough, they would have set the classes to 0x7FFF
10:45<frosch123>if they want to transport all
10:45<andythenorth>they haven't I bet :)
10:45<andythenorth>I certainly didn't, although I am not clever
10:45<andythenorth>just noisy
10:46<frosch123>i think av8 actually does that
10:46<andythenorth>you won't be transporting sugarcane by airplane :P
10:47<andythenorth>I guess the safe thing is I set piece goods and neo-bulk
10:47<frosch123>andythenorth: why not? just because it is expensive?
10:47<@Alberth>but those people in the west need sugar desperately!
10:48<andythenorth>frosch123: because if I set just neo-bulk, you won't get any refittable planes :)
10:48<andythenorth>it's a shame that we can't invent a way for grfs to subscribe to definitions of vehicle types, which are provided by ottd
10:48<andythenorth>then we abstract away from old / unmaintained / slow releasing grfs
10:48<frosch123>so, wagons which transport neo-bulk but exclude piece cargo won't be able transport it?
10:49<andythenorth>frosch123: this is the downside of adding to a well-established class scheme :P
10:49<andythenorth>a vehicle which transports neo-bulk, but excludes piece cargo is frankly made by someone who has been smoking crack
10:49<andythenorth>transporting piece, but excluding neo-bulk is sane
10:50-!-sla_ro|master [slaco@] has joined #openttd
10:51<andythenorth>or I can ship a version of FIRS with no vehicle support for some cargos ;)
10:51-!-DayDreamer [] has quit [Quit: Leaving.]
10:54<CIA-6>OpenTTD: frosch * r23125 /trunk/src/viewport.cpp: -Codechange: Replace some 8s with TILE_SIZE / 2. (adf88)
10:55-!-KOPOBA [] has quit [Read error: Connection reset by peer]
10:59-!-Celestar [] has quit [Ping timeout: 480 seconds]
11:17-!-DayDreamer [] has joined #openttd
11:22<supermop_>would it not have been easier to instead class cargoes by their means of unloading?
11:23-!-Celestar [] has joined #openttd
11:24<Sigvatr>how many wagons will fit in a 7 length station
11:27<frosch123>depends on the length of the wagons
11:28<frosch123>unless you use an outdated version of openttd, the depot gui will tell you the length of the train in number of tiles
11:33<andythenorth>supermop_: wrt cargo classes - probably not
11:35<andythenorth>classes are good, but they are part of a system that is both complex and complicated
11:35-!-Celestar [] has quit [Remote host closed the connection]
11:35-!-Celestar [] has joined #openttd
11:52<Sigvatr>the train breaking down sound is so great, everytime i hear it i just think lol
11:52<Sigvatr>especially when it happens to someone else's train
11:57-!-APTX [] has joined #openttd
11:57-!-APTX| [] has quit [Read error: Connection reset by peer]
11:58<Eddi|zuHause>you should watch out when it happens to horses :p
12:01<Sigvatr>something is wrong, i'm picking up goods from a factory with a full load, but once they arrive at a town, they don't get sold
12:01<Sigvatr>i don't hear a kaching noise or any money go up
12:01<Sigvatr>but the goods are offloaded anyway
12:01<Sigvatr>is someone robbing my train
12:02-!-DayDreamer [] has quit [Read error: Connection reset by peer]
12:02<Eddi|zuHause>do they stockpile at the station?
12:03<Eddi|zuHause>when you click on the station, does it say "200 crates of goods (from A-Town factory)"?
12:04<andythenorth>ho ho
12:04<andythenorth>no it's not christmas
12:04<Sigvatr>can i click on a train to see what it is carrying
12:04<Sigvatr>so i can be sure
12:04*andythenorth has just finished fixing the lighting on HEQS trams, and they suck less
12:04<Eddi|zuHause>click on the train, and in the train window, click on the details button
12:05<Eddi|zuHause>(small sheet of paper on the right)
12:05<Sigvatr>oh god i found out what is happening
12:05<Sigvatr>they get to the station
12:05<Sigvatr>and unload all the goods
12:05<Sigvatr>then they put them on the train again
12:05<Sigvatr>why aren't they being sold
12:05<Eddi|zuHause>probably your station does not cover enough office buildings
12:06<Eddi|zuHause>only those accept goods
12:06<Eddi|zuHause>you typically need 3 of them
12:07<Sigvatr>ok, i'll take them to a bigger town then
12:07<Sigvatr>but still
12:07<Eddi|zuHause>PS: if you use "unload all" orders, you should combine this with "no loading"
12:10<Sigvatr>well basically my idea was that the trains would carry livestock and grain to the factory, then the factory would make shit and they would load the goods in while still at the factory, then deliver it to the town where the farm is
12:10<Sigvatr>is it against the rules to build bridges over other people's railways
12:10<Sigvatr>because i just got kicked and banned i think
12:10<Sigvatr>i can't authorize to the server
12:11<Sigvatr>never mind, connection problems
12:13<Eddi|zuHause>that is certainly not against any rules...
12:14-!-Celestar [] has quit [Ping timeout: 480 seconds]
12:15<@Yexo>Sigvatr: there are no universal rulse
12:15<@Yexo>the owner of every server decides what the rules on his/her server are
12:16<Qantourisc>Sigvatr: if you want peaple on your server :)
12:20<+michi_cc>Ladies and Gentleman, please have a game: :)
12:20<+michi_cc>Now with non-linear costs, signal costs and a severe penalty for those pesky all-way rail tiles. Enable it in Advaned Settings | Economy, play a game and watch detailed costs in the company window.
12:20<+michi_cc>Tinkering with the base costs in table/pricebase.h welcome, I can't test-play every kind of game style myself.
12:21<andythenorth>michi_cc has been busy again :D
12:22<Eddi|zuHause>i can't keep up with this...
12:22<andythenorth>me neither :P
12:22<Eddi|zuHause>i am seriously considering postponing any openttd-related stuff until christmas-ish
12:24<andythenorth>I can't upgrade grfs fast enough to keep up with features :P
12:24<Sigvatr>so to sell goods to a town, they need 3 commercial buildings?
12:24<Sigvatr>how can i make them have more buildings
12:25<andythenorth>michi_cc: is there any summary for that patch, or would it be obvious if I compiled it?
12:26<Eddi|zuHause>the problem is, if i don't update CETS now, i a) forget everything, and b) i don't hit the next blocking limitation before the next feature freeze
12:32<z-MaTRiX>ahaha the mactiny
12:33*Eddi|zuHause is seriously considering the special friend list
12:37<z-MaTRiX>Eddi|zuHause<< what do you mean by that?
12:37-!-blotek_ [] has joined #openttd
12:39<andythenorth>maybe I should stop fixing newgrf lighting and write nfo
12:39<Eddi|zuHause>learn nml ;)
12:40<andythenorth>that will just slow things down even further :)
12:41<Sigvatr>is it a good idea to have a train which carries nothing, but arrives and leaves a station frequently just to keep rating up?
12:43<Eddi|zuHause>Sigvatr: a vehicle only affects rating when it actually carries that cargo type
12:44-!-blotek [] has quit [Ping timeout: 480 seconds]
12:46<frosch123>but it is a common cheat to have a small truck constantly loading and unloading again at the same station
12:47<+michi_cc>andythenorth: Very short summary: Regular maintenance costs for company owned tracks, roads and canals.
12:48-!-Elukka [] has quit []
12:49<Sigvatr>why does all midi music ever written have to be jazz or salsa music
12:51<frosch123>maybe other types of musics care about what instruments they are played with
12:54-!-Rezt [] has joined #openttd
12:58<appe>midi music might be the most horrible thing ever to haunt planet tellus.
12:58<appe>it's like justin bieber times a googolplex
13:00<Eddi|zuHause>i have seen people do crazy stuff with midi. like a "street organ orchestra". multiple organs that are synched by a midi device
13:00<andythenorth>michi_cc: is there a rebalancing aim, or is it just for fun? :)
13:01-!-Celestar [] has joined #openttd
13:01<appe>using a midi clock != midi music
13:01<appe>midi music is that horrible windows music thingy
13:01<appe>midi hardware is something fantastic
13:01<+michi_cc>andythenorth: It's for those that think making money is too easy.
13:02<Eddi|zuHause>andythenorth: it's something that was requested by MB :p
13:06<andythenorth>how interesting
13:06*andythenorth bbl
13:06-!-andythenorth [] has quit [Quit: andythenorth]
13:12-!-Mucht [] has joined #openttd
13:17<Terkhen>hi planetmaker
13:24<z-MaTRiX>how would you rasterize a circle with x=212.111,y=333.5454,radius=333.222,linewidth=0.111 ? :)
13:25<@Alberth>take an infinitely small raster, and draw a circle
13:26<z-MaTRiX>i'm currently writing the transfer function , and willing to render that
13:26<@Alberth>depending on your coordinate system, you may end up with a small dot :)
13:26<z-MaTRiX>was thinking about anti-aliasing/subpixel-rendering
13:26<frosch123>ℝ² sounds like a useable raster for that
13:27<+michi_cc>YAIM - (Yet Another) Infrastructure Maintenance Patch
13:27<@Alberth>z-MaTRiX: define it in svg, and let the backend handle it?
13:28<z-MaTRiX>that's too easy :(
13:28<z-MaTRiX>though i'm the backend
13:28<z-MaTRiX>using SDL only with a framebuffer
13:30<frosch123>michi_cc: the catenary is stolen quite often, isn't it? :p
13:31<frosch123>oh, i misread the statistics
13:32<frosch123>what's "Tramawy"? :p
13:32-!-Devroush [] has quit [Ping timeout: 480 seconds]
13:32<z-MaTRiX>Tramway ?
13:33<z-MaTRiX>(used Artificial Interpolation)
13:40-!-Celestar [] has quit [Ping timeout: 480 seconds]
13:45<CIA-6>OpenTTD: translators * r23126 /trunk/src/lang/ (6 files): (log message trimmed)
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: belarusian - 17 changes by Wowanxm
13:45<CIA-6>OpenTTD: norwegian_bokmal - 24 changes by eloekset
13:45<CIA-6>OpenTTD: polish - 17 changes by nouwak
13:45<CIA-6>OpenTTD: spanish - 17 changes by Terkhen
13:45<CIA-6>OpenTTD: vietnamese - 17 changes by nglekhoi
13:47-!-Brianetta [] has joined #openttd
13:48<z-MaTRiX>hi girl whatsup ?
13:48<+michi_cc>frosch123: A typo I guess :)
13:49<Rubidium>michi_cc: you should iterate road types the same way as rail types in YAIM ;)
13:50<Rubidium>s/rail/road/ (case insensitive but keeping the case) should do the trick
13:55<+michi_cc>frosch123: I don't see no typo anymore ;)
13:57<frosch123>♥ double negations
14:11<Rubidium>Eddi|zuHause: regarding those speed units: I wouldn't change them to something based on km/h as that will mean OpenTTD needs to internally go to km/h which means reintroducing that "bug" about vehicles not going the right speed
14:12-!-Rezt [] has quit [Quit: Textual IRC Client:]
14:13<Eddi|zuHause>Rubidium: i guess the main point is a) all vehicles should use the same speed units, from nfo/nml perspective (to decouple from internal handling), and b) it should allow fractional values for less rounding errors.
14:17<Rubidium>those fractional values don't play nice with the internal speed code
14:17<Rubidium>(at least for trains and RVs)
14:17<Eddi|zuHause>that's a secondary issue
14:17<Rubidium>now they "encode" how far the vehicle can go in sub-unit units
14:18<Rubidium>which means you need a fractional subspeed (which already is a fraction of sorts)
14:19<Eddi|zuHause>the actually usable values might have lower resolution than the values provided by the grf. but the decoupling means the OpenTTD implementation may be switched later without influencing the grf specs
14:20<Rubidium>the question is whether less than ~0.5 km/h is really useful
14:20<Rubidium>(in granularity)
14:22<Eddi|zuHause>it is, when you want to model mph without rounding oddities
14:23<Eddi|zuHause>with 1 mph ~ 1.6km/h
14:24<Rubidium>I don't see why. With ~1 km/h I can imagine, well... prove, that one in N km/h can't be modelled with km-ish/h. But with 0.5 km-ish/h you can prove you can model each km/h and each mph
14:25<Eddi|zuHause>i thought with one nibble as fixed point allows for better coding in hex values
14:26<Rubidium>the main problem NML has is that OpenTTD's internal algorithm does some round at some points in the algorithm which means you'll get a slightly different result than when you perform all mathematical operations and then round
14:27<Rubidium>but yes, a nibble might be usefull when working with hex
14:28<Rubidium>on the other hand, a single bit might work better for decimal (just multiply by 2)
14:28<@Alberth>(x >> 3) * 2 ?
14:29<Rubidium>no, if you want 74 km-ish/h, then write \w148
14:29<Eddi|zuHause>Rubidium: how is *2 easier than *16 in decimal? :)
14:30<@Alberth>@calc 74*16
14:30<@DorpsGek>Alberth: 1184
14:30<Rubidium>but... with a factor 16 it'd be \w1184 which is a multiplication I can't do as easily in my head
14:30<Rubidium>as I multiply or divide by 2
14:30<Eddi|zuHause>Rubidium: i seriously want to get rid of km/h-ish at least for all user interfaces.
14:31<Rubidium>what about hm/h-ish? ;)
14:31<Rubidium>or... 0.0625 mph
14:31<@Alberth>Rubidium: 1 bit may not be enough, the code may just start flipping the last bit, which you can still see
14:32<Eddi|zuHause>Rubidium: if you se it that way, the current granularity is 0.625 mph
14:32<Eddi|zuHause>(for trains)
14:33<Rubidium>but what's the difference between 0.0625 mph or 0.0625 km/h user interface wise?
14:33<Eddi|zuHause>Rubidium: which is neither useful to model exact km/h values, nor exact mph values
14:34<Eddi|zuHause>Rubidium: well, i'd be fine with my proposal of XXXY format with mph instead of km/h
14:35<Rubidium>although you'd be adding (unused) granularity
14:35<@planetmaker>not exactly
14:35-!-Devroush [] has joined #openttd
14:35<Eddi|zuHause>Rubidium: but that granularity may still be used at a later date
14:36<@planetmaker>it'd be feasible to add some velocity values which then could be used later
14:36<Rubidium>planetmaker: it'll definitely be unused until the whole speed code is revised
14:36<@planetmaker>yes... but future-proof the speed properties. It's somewhat a point
14:36<@planetmaker>and would make revision possibly easier
14:36<@planetmaker>when done in two years or so
14:37<Eddi|zuHause>Rubidium: you can easily halve the granularity by calling TrainController only once per internal speed unit
14:40<Eddi|zuHause>but really, the point is to allow this kind of refactoring later, without worrying about the grf specs
14:40<Rubidium>but the specs aren't the biggest problem
14:41<Rubidium>see the aircraft accel and speed
14:41<Eddi|zuHause>no. but one less problem is one less problem :)
14:41<Rubidium>internally that's in km-ish/h, but in the spec it's in 8mph
14:42<Rubidium>*and* we still need to do it for pre-grfv8 NewGRFs
14:42<Eddi|zuHause>Rubidium: that kind of rounding will be in the newgrf abstraction layer then
14:42<Rubidium>so you'd be adding two bits of spec handling that needs to be handled
14:43<Eddi|zuHause>yes, one conversion for grf<8 and one for grf>=8
14:43<Eddi|zuHause>but i don't see a better opportunity coming up
14:44<Rubidium>that's true
14:46<@planetmaker>"it's a good opportunity now" is somewhat convincing... hm
14:50<Rubidium>ah, so you're volunteering? ;)
14:53<z-MaTRiX>multiple suns are shining at mutexland, where deadlocks are your friend :)
14:54<Rubidium>7 properties, 4 variables, and one headache: subspeed
14:55<Rubidium>(which is the exposing an implementation detail of the speed calculations)
14:56<@planetmaker>why would it be exposed?
14:57<Rubidium>if you want to make use of the higher granularity in the speed, then subspeed needs to become bigger as well
14:58<Rubidium>although, there is an caveat with mph/16 as number: you need to divide by 10 when passing it into the "distance moved" calculation
14:59-!-andythenorth [] has joined #openttd
15:00<Rubidium>which, ofcourse, isn't a nice factor for computers to divide by
15:02<@planetmaker>though currently the factors are not really nicer either. Just a factor of 10 higher
15:02-!-valhallasw [~valhallas@] has joined #openttd
15:04<Rubidium>planetmaker: they are very nice; just add "speed" to subspeed. Divide by 256. The quotient is the number of units to move, the remainder is the new subspeed
15:06<Eddi|zuHause>Rubidium: there is no reason why the factor of 10 needs to be used in the internal speed units
15:07<andythenorth>where's the fun in not multiplying speeds by 3.2 or 0.8 or whichever it is of those props that actually gets used
15:07<Rubidium>so the proposal is: use 1/16 mph in the specs and immediately trash it to 10/16 mph for trains and 5/16 mph for RVs?
15:08-!-mahmoud [] has quit [Read error: Connection reset by peer]
15:08<andythenorth>does grf v8 deprecate useless props and refuse to compile if they're used?
15:09<Rubidium>it doesn't
15:09-!-valhalla1w [] has quit [Ping timeout: 480 seconds]
15:10<Eddi|zuHause>we could deprecate the short dates
15:10<Eddi|zuHause>or stuff like the split properties
15:11<frosch123>short dates are already deprecated
15:11<frosch123>you may set them for old versions, but you do not have to
15:11<Eddi|zuHause>i think it was weight which was split between low and high byte
15:12<frosch123>i see no point in changing that
15:12<frosch123>it only adds to the mess
15:12<frosch123>and you do not see it when using nml
15:13<Eddi|zuHause>different thing: what about all the "must be zero for articulated parts" properties? there's hardly ever a reason to forbid this
15:13<frosch123>[21:12] <frosch123> it only adds to the mess <- esp wrt. other tools
15:13<frosch123>Eddi|zuHause: "must be zero" is only to ensure that they can get a meaning later
15:13<frosch123>which is independent of grfv8
15:13<Eddi|zuHause>i.e. there's no reason why articulated parts shouldn't have weight
15:14<Eddi|zuHause>or price
15:14<Rubidium>they're just ignored ;)
15:14<frosch123>exactly. that's why it is "must be zero" for now. so if they get weight, grfs stay the same
15:15<frosch123>Eddi|zuHause: the specs generally do not state stuff like "unused" or "ignored"
15:15<frosch123>as then the grfs do just write random junk in it
15:15<andythenorth>mine do :P
15:15<andythenorth>I missed that bit of the spec for HEQS
15:15<andythenorth>I wrote a ticket to myself about it
15:16-!-mahmoud [] has joined #openttd
15:16<Eddi|zuHause>so... conclusion: it's not depending on grfv8, it just needs someone to actually implement it
15:16<andythenorth>any chance of extending refit mask to > 32 cargos?
15:16<Eddi|zuHause>andythenorth: unlikely...
15:17<frosch123>Eddi|zuHause: mind that it makes no sense to implement it, as long as trains sum te and power for the whole train before doing the minimum
15:17<frosch123>and that is an optimisation
15:17<frosch123>andythenorth: shall i link you to the callback again?
15:18<frosch123>i only linked it 3 times this week :p
15:18<andythenorth>sorry :|
15:18<andythenorth>so many new things I need to code / test
15:18<andythenorth>still busy *fixing the fricking lighting*
15:19<andythenorth>still have to implement decay rate
15:19<andythenorth>still have to do canal speed fraction
15:19<andythenorth>still have to do the auto-refit support
15:20<frosch123>your clones need to grow faster
15:20<frosch123>does any un convention forbid child-labour on newgrfs?
15:20<andythenorth>probably not explicitly
15:20<andythenorth>I doubt there's a clause about pixel art or nfo
15:21<andythenorth>frosch123: where's the callback?
15:21<@Alberth>not even on nfo?!?
15:24<+michi_cc>andythenorth: Do I need to be worried as each item on your list was me? :p
15:24<andythenorth>I just like having a to-do list :)
15:24<andythenorth>it's much easier to write nfo than ask people to patch the game
15:24<andythenorth>continuously asking for patches is hard work :P
15:25<@planetmaker>you just should kick your ass a bit and have a go at NML ;-)
15:25<andythenorth>michi_cc: I am reading the infrastructure patch - but can't see if it enables railtypes to specify a maintenance cost multiplier...
15:25<andythenorth>give me an excuse to start a railtypes set....
15:26<@planetmaker>and you should revert the sugar cane cargo classes... they're definitely not piece goods...
15:26<andythenorth>they're definitely not bulk either
15:26<+michi_cc>andythenorth: Citing from my forum post "NewGRF support for rail type specific cost factors." Would be prop 1B.
15:27<andythenorth>planetmaker: a bundle of sugar cane *is* piece goods according to the intention of that class
15:27<andythenorth>whereas sugar cane is *never* bulk
15:27<@planetmaker>andythenorth: look at the issue I created.
15:27<@planetmaker>It clearly is transported as bulk...
15:27<@planetmaker>neither over-sized nor bundled
15:28<andythenorth>bulk is things that flow
15:28<andythenorth>that's the mistake we keep making
15:28<andythenorth>bulk != bulky
15:28<@planetmaker>yup. Sugar cane sticks of 30cm do flow
15:28<@planetmaker>and definitely is not "piece goods"
15:28<@planetmaker>Thus you break all vehicle sets without good reason
15:28<@Alberth>planetmaker: what do you think of these tracks?
15:28<andythenorth>planetmaker: break how?
15:28<andythenorth>are classes classes, or are they labels?
15:29<@planetmaker>which is not a "break savegames" but a "break newgrfs" issue. Much worse.
15:29<andythenorth>I wish we could decide, it's getting tiresome
15:29<@Alberth>the long piece seems to have some weird pixels
15:29<andythenorth>either classes are abstractions, or they are precise cargos, in which case they are redundant because we have labels already
15:29<@planetmaker>I don't talk about classes. I talk about one cargo
15:29<@Alberth>and the top-left two pieces are very unclear to me what tracks they have
15:30<@planetmaker>Which you changed the properties of to the total opposite
15:30<@planetmaker>Which is - sorry - bullshit
15:30<andythenorth>please explain why
15:30<@planetmaker>this "today this, today that" is totally not funny in this respect :-(
15:31<@planetmaker>andythenorth: see the issue I opened. Sugar cane *is not* piece goods.
15:31<andythenorth>yes it is
15:31<@planetmaker>See the linsk
15:31<@planetmaker>look at the images
15:31<@planetmaker>It is not
15:31<andythenorth>you misunderstand the intention of the current cargo classes
15:31<@planetmaker>of course
15:31*Alberth tiptoes out of here
15:31<@planetmaker>so do I
15:32<andythenorth>sugar cane was added as an explicit label to handle this issue, differentiating it from sugar beet, which is bulk
15:34<@planetmaker>andythenorth: *did* you look at the links I provided?
15:34<@planetmaker>Did you see that? Or do you argue out of thin air?
15:34<@planetmaker>Is that piece goods as in "boxed sugar cane pieces or bundles?
15:34<@planetmaker>Or does it look like a pile of small sticks?
15:34<andythenorth>1 mins
15:35<andythenorth>planetmaker: you think it *should* be bulk, *shouldn't* be piece goods, or both?
15:36<andythenorth>I have no strong feelings about piece goods aspect
15:36<@planetmaker>it should just remain bulk as it was. Simple revert
15:36<@planetmaker>If you want, you can add the oversized
15:36<@planetmaker>But piece... doesn't seem right at all
15:37<@planetmaker>though I personally don't see the oversized by what I saw
15:37<andythenorth>I added piece because the class I think it should have is neo-bulk, which has zero cargo set support (so far)
15:37<@planetmaker>And... why don't you change the cargo label there, too?
15:37<@planetmaker>Or why did you change it for scrap metal?
15:37<andythenorth>the cargo label is new
15:37<@planetmaker>That's totally inconsequent
15:37<@planetmaker>The diff doesn't list a new cargo label
15:37<andythenorth>the cargo label can be changed
15:37-!-Ola [] has joined #openttd
15:38<@planetmaker>I'm not in favour of adding yet another new and soon-to-be-deprecated label, though
15:38<@planetmaker>We did that to way too many cargo labels already
15:38<andythenorth>do you want to add a new label for sugar cane?
15:39<andythenorth>we can use SRCN
15:39<@planetmaker>mostly I'm mad about what seems a quick-shot change for existing cargos which has not properly been thought-through
15:39<andythenorth>these are not new tickets
15:39<andythenorth>these are long standing issues
15:39<@planetmaker>as cargo changes mean to change all existing newgrfs
15:39<andythenorth>sugar cane was split from sugar beet for this precise reason
15:39<@planetmaker>and adding new labels means that specific support has to be added (again) for the new ones
15:40<@planetmaker>both is at least tedious
15:41<b_jonas>uh, can't a cargo have multiple labels?
15:41<andythenorth>planetmaker: some of the definitions are wrong. They impose extra work on set authors, that's wrong, and it needs to be fixed.
15:42<+michi_cc>It seems to me the current way of cargo support using labels and classes doesn't really work if it means once a cargo is introduced you can never ever change anything at all.
15:42-!-ABCRic [] has joined #openttd
15:42<andythenorth>basically between those of us who've set the cargo labels (mostly me), there have been misunderstandings
15:42<andythenorth>primarily because in english 'bulk' and 'bulky' sound similar
15:42<andythenorth>and also because I set some labels to suit me in HEQS, instead of doing proper cargo support
15:42<andythenorth>both are wrong
15:43<andythenorth>FIRS is not yet even 1.0, and has always carried a warning about changes
15:44-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
15:44<@planetmaker>andythenorth: if that's the case, then you must not publish the used cargo specs.
15:44<@planetmaker>As they're added to the wiki, they're official
15:44<andythenorth>that is a good point
15:45<andythenorth>michi_cc: the current cargo support is pretty good, but it seems to be surrounded by problems
15:46<andythenorth>conceptually it's really sound, but it's very easy to make mistakes that have a high penalty
15:46<@planetmaker>michi_cc: if you change the specs, you simply have to name it differently
15:46<andythenorth>I only today understood what MB intended by 'bulk'
15:46<@planetmaker>you don't really want to tell me you mixed up bulk and bulky, do you?
15:46<andythenorth>yes, for a long time
15:47<andythenorth>I raised this issue in forums some time ago
15:47<andythenorth>about 6 months ago or such
15:48<andythenorth>first post in this thread :)
15:48-!-Rezt [] has joined #openttd
15:49<@planetmaker>I guess no-one understood that you didn't understand English...
15:49<@planetmaker>(I didn't at least)
15:49<andythenorth>stupid language anyway
15:49-!-DOUK [] has joined #openttd
15:49<andythenorth>one 'y' totally changes the meaning :P
15:49<Eddi|zuHause><michi_cc> It seems to me the current way of cargo support using labels and classes doesn't really work if it means once a cargo is introduced you can never ever change anything at all. <-- i think the only problem with that is the "XOR" with the explicit cargo mask. if that was split into an "OR" and an "AND NOT" mask, most of the problems with switching cargo classes would disappear
15:51<andythenorth>planetmaker: it's not like I didn't discuss this about 10 million times here :P
15:52<andythenorth>no-one pointed out the mistake, we just got stuck on it every time
15:52<@planetmaker>It might explain why these discussions were so unproductive and annoying...
15:54<@planetmaker>Pointing out that you don't mean 'bulk' when you say 'bulk' is a bit difficult, don't you think?
15:54<andythenorth>so I tried to figure out what MB *intended* by the classes (assuming it was MB), which led me to Wikipedia...which led me to the shipping industry has had exact same problem: cargos that overlap both bulk and piece goods
15:54<andythenorth>hence neo-bulk
15:54<@planetmaker>except telling you that your argument is about... nonsense. Which was refuted
15:55<andythenorth>in the uk you can make a bulk order of logs
15:56<andythenorth>and a bulk delivery of cars
15:56<andythenorth>but you wouldn't use a bulk carrier for either
15:56<@planetmaker>which refers not to the cargo property at all
15:56<@planetmaker>thus has no place in cargo classes
15:56<andythenorth>I'm not arguing - the mistake was mine entirely :P
15:56-!-mahmoud [] has quit [Ping timeout: 480 seconds]
15:59<andythenorth>so one thing we should do is to not publish cargo labels?
16:00<andythenorth>at least until FIRS 1.0
16:00<andythenorth>should we remove them from the wiki?
16:00<Eddi|zuHause>sometimes i really wonder how you reach any of your conclusions...
16:01<@planetmaker>andythenorth: I mostly think we should not now change the cargo classes of the existing cargos. But wait. Gather the ideas. Weigh the ideas
16:01<@planetmaker>Not quick-"fix" like now. And change it again. But do that all from 0.9 to 1.0
16:01<andythenorth>because the cost of changing is too high?
16:01<@planetmaker>or so
16:01<@planetmaker>yes. Much so
16:02<andythenorth>I was trying to get all this done with only one major savegame break since 0.6 release
16:02<@planetmaker>and thinking a bit more about it than 24h on one way to change it, is too little imho
16:02<@planetmaker>lol. It was broken between each version
16:02<@planetmaker>And there'll be reasons to break it also between each future version. I'm sure
16:02<@planetmaker>firs 0.3 != 0.4 != 0.5 != 0.6 != 0.7
16:03<@planetmaker>version = major version
16:03<andythenorth>unlikely we'll do a 0.7 final release though
16:03<andythenorth>that's nitpicking
16:03-!-Sigvatr [sig@] has quit []
16:04<andythenorth>we only released the beta to the forums
16:04<andythenorth>next release will be 0.8 I think
16:04<andythenorth>probably when stable ottd has caught up
16:04<@planetmaker>err, why that?
16:04<@planetmaker>why skip a 0.7?
16:05<andythenorth>why release 0.7? Unless we backport a lot, which we could
16:05<@planetmaker>we just don't backport, but tag trunk as 0.7
16:06<@planetmaker>or tag a 0.7 in the branch and publish that with the betas
16:06<@planetmaker>backporting is not fun really
16:07<Wolf01>nighty night
16:07-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
16:07<andythenorth>well we could release 0.7
16:08<andythenorth>we had a reason for possibly skipping it, but I don't remember
16:08-!-Kurimus [] has quit []
16:09<@planetmaker>putting up 0.7 on bananas makes FIRS unavailable for stable OpenTTD
16:09<@planetmaker>via bananas
16:09<andythenorth>we did have a plan
16:09<@planetmaker>it's nor FIRS' fault, but that's how it (still) is
16:09<@planetmaker>yes, other grfID for trunk FIRS. But meh
16:09<andythenorth>there were plausible reasons to *never* release 0.7 on bananas, but go straight to 0.8
16:10<andythenorth>maybe we just got to the 0.7 beta and stopped there
16:10<andythenorth>perhaps we were waiting for translations against 0.7.x, but now they're mostly coming against tip afaik
16:13-!-DDR_ [~chatzilla@] has joined #openttd
16:16-!-DOUK [] has quit [Ping timeout: 480 seconds]
16:17<Zuu>Or just release it and encourange more people to use the OpenTTD nightlies?
16:18<@Alberth>translations are mostly ad-hoc imho, perhaps you should post and explicitly ask for updates
16:20<andythenorth>Alberth: I guess I should have put bold text in here :D
16:21<supermop_>this bottle of ginger beer has a nasdaq trading symbol on the label
16:21<@Alberth>I missed that entirely :p
16:21<Zuu>hmm, wxWidgets is sloooow. I need to throttle my commands to it or it consume 50% of a CPU core when it get constantly updated :-( - my SDL GUI barely touches the CPU usage. (or go back to SDL :-) )
16:21<andythenorth>Alberth: it wasn't bold enough ;)
16:21<@Alberth>I mean the entire post :)
16:22<supermop_>i guess they are hoping that halfway through I'll decide that it's so great that I'll run to a computer and buy a bunch of their stock...
16:22<__ln__>Zuu: what are you doing with wx exactly?
16:23<Zuu>I'm trying to port Junctioneer to it, but I start to question what I really gain by doing it.
16:24<Zuu>Though, I beleive part of my questions is because I don't know it good enough yet.
16:25<andythenorth>frosch123: did this get any better yet :D
16:25<Eddi|zuHause>sounds like you'd benefit from gathering multiple updates before you actually update everything
16:27<Eddi|zuHause>andythenorth: maybe you should release 0.7-RC1 with a notice to update translations within the next 2-4 weeks?
16:27<andythenorth>but tip is way ahead of the 0.7 branch I think
16:27<frosch123>andythenorth: i started the topic instead of starting an edit-war on the wiki
16:27<andythenorth>which means translators might be translating against dead code
16:28<frosch123>mb was adding non-sense back then :p
16:28<Eddi|zuHause>andythenorth: alternatively just release tip as 0.7-beta2
16:28*andythenorth never wanted to add the FIRS labels to the wiki :(
16:28<andythenorth>Eddi|zuHause: that could be a good idea
16:28<andythenorth>maybe not while this cargo shenanigan is happening though :)
16:29<Eddi|zuHause>agreed :)
16:30<andythenorth>all I feel like I've done for the last 2 days is piss everyone off, and that's even before MB eventually deigns to respond in the forums to my proposals
16:30<andythenorth>yet all I'm trying to do is correct mistakes
16:30<andythenorth>cargos are very expensive in heartache :P
16:30<frosch123>how about adding "hazardous" to "bubbles"-cargo?
16:31<frosch123>they are explosive after all
16:32<andythenorth>frosch123: I think I like the cb route :P
16:32-!-Alberth [] has left #openttd []
16:32<andythenorth>although it does nothing to help the 'cargos cannot be changed, but new cargos shouldn't be added' problem
16:32<Terkhen>good night
16:32<frosch123>i think i add the cb after the grfv8 queue
16:33<andythenorth>I think I update HEQS to use it
16:33<andythenorth>it might avoid a savegame break or some *really* tedious work
16:33<frosch123>i thought earlier this day, that the alternative "cargo shall define which vehicles can carry them" is nonsense, since the vehicles define the graphics to use
16:33<frosch123>and should know better what to carry
16:34<frosch123>andythenorth: note that the cb number will change :p
16:34<andythenorth>"cargo shall define which vehicles carry them" is going down the route of 'there are fixed types of vehicles'
16:34<andythenorth>which isn't how It has been done, and is not compatible with current approach
16:35<andythenorth>*all* of my cargo gripes are solved by (a) fixing my own stupid mistakes (b) introducing neo-bulk class
16:36<andythenorth>frosch123: how about a cb to change cargo classes during game :D
16:36<andythenorth>on the cargo
16:37<andythenorth>water is liquid in summer, but piece goods + oversized in winter
16:37<+michi_cc>Zuu: Obviously I don't know where you CPU time goes, but if you update several controls at once, using Freeze() + Thaw() might help a lot.
16:38-!-Brianetta [] has quit [Quit: Tschüß]
16:39<Zuu>michi_cc: Thanks, I indeed update several controls. It's the node junction window which lists all incomming and outgoing connections. They are ordered by the angle of the inputs/outputs. So when you move the node, the GUI is updated. Since the GUI was repainted almost for free before, I think it updated the GUI every time the node was moved without checking if it is needed or not.
16:40<Eddi|zuHause>frosch123: any possiblity the refitability-callback can do something like predetermine the allowed cargos for autorefit? e.g. if i have a tanker wagon, i could have two separate sets: "autorefit (food, milk, alcohol)" and "autorefit (oil, fuel, chemicals)", which would be available in the order list?
16:41<+michi_cc>Freeze applies to all Controls and not only Windows here of course.
16:41-!-Brianetta [] has joined #openttd
16:41<Zuu>Inded as in wx a control is a window :-)
16:42<frosch123>Eddi|zuHause: sounds very difficult
16:42<frosch123>and makes only sense to known cargos
16:42<frosch123>i.e. not cargoclass based
16:43<Eddi|zuHause>frosch123: well, it could make sense e.g. with the proposed "clean" cargo class.
16:44<andythenorth>should I revert my wiki update to classes btw?
16:45*andythenorth is always a bit worried about editing wiki
16:45*planetmaker is more worried about changing specs too quickly w/o time to consider stuff
16:46<@planetmaker>changing as in breaking existing definitions
16:46<frosch123>i just wanted to start a topic to discuss whether default cargos shall gain any of the new classes
16:47<andythenorth>I tried to clarify the definitions of the other classes as well
16:48<@planetmaker>that might be a good idea, frosch123
16:52<andythenorth>planetmaker: bulk, piece goods, AND neo-bulk for sugar cane? :o Perhaps not ;)
16:52<frosch123>omg, classifying toyland cargos...
16:53-!-KritiK [] has quit [Quit: Leaving]
16:53-!-enr1x [] has quit [Quit: leaving]
16:53<andythenorth>I suspect there are UIC codes somewhere for toyland :P
16:53<andythenorth>frosch123: it's easy: most are 'hazardous'
16:53<andythenorth>batteries: hazardous
16:53<andythenorth>to classify toys accurately, you need my proposed 'class changing' cb
16:54<andythenorth>and you have to check age of player
16:54<andythenorth>hazardouse for < 3 years
16:54<@planetmaker>andythenorth: perhaps yes
16:54<andythenorth>planetmaker: some chance we'll end up with no vehicle support if we put all three on :)
16:54<andythenorth>due to exclusions
16:55-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
16:55-!-enr1x [] has joined #openttd
16:55<andythenorth>this is why the cb route might be better...
16:55<andythenorth>although same could apply
16:56<andythenorth>although any truck or train set should include open wagons
16:56<andythenorth>and any vehicle author who doesn't allow piece goods and/or bulk into open wagons is doing something wrong
16:57<andythenorth>and excluding neo-bulk from open wagons would be stupid too
16:57<Eddi|zuHause>someone could do "bulk, but not piece goods" for the open wagons, and "piece goods, but not bulk" for the closed wagon
16:57<Eddi|zuHause>then your proposed cargo couldn't go in either of them
16:57-!-Adambean [] has quit [Quit: Gone fishing]
16:58<andythenorth>Eddi|zuHause: then they should add neo-bulk :)
16:59<andythenorth>why does the first cargo information table in the wiki include FIRS and ECS type B IDs?
16:59<andythenorth>that encourages use of hard-coded IDs, not labels
17:00<andythenorth>the ID chosen for each cargo in FIRS should be private information to FIRS
17:00<andythenorth>are there features that need it?
17:01<Eddi|zuHause>i once needed such information for the dbxl-cargo-addon, because the CTT of the addon-set was not respected back then
17:01<frosch123>yes, dbset 0.8 extension sets
17:01<andythenorth>but the wiki is not canonical for FIRS
17:02<andythenorth>only the repo is canonical
17:02-!-ABCRic [] has quit [Quit: Goodbye, world...]
17:02<@planetmaker>andythenorth: it should be canonical
17:02<@planetmaker>thus it should only include those info which can be guaranteed to remain fairly constant
17:03<andythenorth>it's not currently accurate :P
17:03<Eddi|zuHause>changing cargo-slots is something not-savegame-safe-y
17:04<Eddi|zuHause>but at the latest when "economies" are introduced, the information is probably useless
17:04<andythenorth>contains ~3 errors at the moment
17:09<Qantourisc>Dam .... i wanted to upgrade to monorail ...
17:09<Qantourisc>but by the time all the trains have checked in ... i can upgrade to maglev :p
17:11-!-Mucht [] has quit [Remote host closed the connection]
17:14<CIA-6>OpenTTD: michi_cc * r23127 /trunk/src/vehicle_cmd.cpp: -Fix [FS#4819] (r23086): Don't crash when refitting default vehicles.
17:17<frosch123> <- are the bigger flaws in there?
17:18<andythenorth>frosch123: I would like the intention of oversized/overweight clarified by whoever created it
17:18<andythenorth>it could be useful, but only if we know what it's meant to be
17:18<frosch123>isn't that best done by giving examples?
17:18<andythenorth>oversized / overweight are two different dimensions
17:18<andythenorth>and 'requires specialist vehicles' is of no help
17:19<andythenorth>my vehicle is a specialist car for carrying hot molten metal
17:19<andythenorth>can it carry sheets of glass?
17:19<frosch123>"specialist vehicles" are those which have no cargo classes, but only specific cargos :p
17:19<andythenorth>nice definition
17:20<andythenorth>fwiw, the cargo industry now treats livestock as neo-bulk
17:20-!-DDR_ [~chatzilla@] has quit [Ping timeout: 480 seconds]
17:21<andythenorth>gold should be express :P
17:21<frosch123>andythenorth: in the forum post i might suggest the defintion. "oversized/overweight" = "requires wagons which can be loaded with a crane, i.e. open or open-able roof
17:22<frosch123>andythenorth: the problem with livestock is that there are very different types of livestock
17:23<andythenorth>coconuts :P
17:23<andythenorth>that is the same three wheeled truck I have
17:24<frosch123>"passengers" are not "clean" btw. :p
17:25<andythenorth>nor are trains, so that's ok
17:25<andythenorth>especially not buses
17:25<andythenorth>mail might be?
17:25<andythenorth>but in game, mail is kind of covered anyway
17:26<@planetmaker>I'd be surprised if covered wasn't used...
17:26<andythenorth>word collision :)
17:26<andythenorth>in game, mail has few problems
17:26<andythenorth>I should have said
17:26*andythenorth tries to figure out a case for oversized / overweight
17:27<andythenorth>so the heavy item flat car in US set might refit to that class
17:27<@planetmaker>wind turbine parts :-)
17:27<andythenorth>I worry what happens if it's excluded
17:27<frosch123>let's check some pikka set
17:28<andythenorth>box cars should exclude oversized / overweight
17:28<andythenorth>for example
17:28<andythenorth>the exclude thing is basically a small bomb waiting to go off sometimes
17:28<andythenorth>setting fewer classes == better
17:32<frosch123>planetmaker: nars2 does not use them for a start :)
17:33<@planetmaker>hm, interesting
17:33<andythenorth>frosch123: I would avoid setting the oversized class
17:34<andythenorth>because the majority of vehicle types should exclude it
17:34<@planetmaker>flatbed typcially wouldn't. Would they?
17:35<andythenorth>depends on what it means
17:35<frosch123>egrvts seems to be too old, it uses only up to "hazardous"
17:35<andythenorth>let me recycle my previous comment :P
17:35<frosch123>(for exclusion mainly)
17:35<andythenorth>depending on how some authors choose to interpret it, lots of vehicles *might* exclude it
17:35<frosch123>oh, though egrvts has a bug, it uses "clean" :p
17:36<@planetmaker>as what exactly?
17:36<@planetmaker>there's a posting which states that silently ECS uses bit10 already. "great"
17:37<frosch123>the armoured carriage can transport "clean"
17:37<@planetmaker>as definition of powder
17:37<@planetmaker>oh he
17:37<@planetmaker>that's different then :-)
17:37-!-HerzogDeXtEr [] has joined #openttd
17:37<andythenorth>is it possible that oversized will end up merging with neo-bulk?
17:37<frosch123>i guess it shall have been "hazardious"
17:38<frosch123>andythenorth: yes :p
17:38<andythenorth>do we know who added 'oversized' ?
17:38<@planetmaker>take a guess
17:38<andythenorth>I think I can think like MB
17:38<frosch123>covered and oversized are by mb
17:38<andythenorth>I think he means specifically what US ralroads call 'high and wide'
17:39<frosch123>hazardous must be from some forum troll years ago
17:39<andythenorth>or 'dimensional loads'
17:39<andythenorth>basically things that might go out of the loading gauge, or over the route weight limit
17:39<andythenorth>notably it will be train specific :P
17:39<Eddi|zuHause>if i say "i have previously staded my thoughts on oversized on the forum", do i "think like MB"? :p
17:40<andythenorth>maybe you are MB
17:40<andythenorth>specifically, putting overweight cargo into *normal* wagons would create an axle loading that was too high, and advanced players should know this and choose the appropriate wagon type
17:41<andythenorth>I can't really mimic him, I am a poor mimic
17:41<Eddi|zuHause>basically, if "oversized" means "wind turbine parts, transformers, or CASTOR containers", then the class is useless, as no newgrf ever defines such things
17:41<@planetmaker>Eddi|zuHause: that's how I understood that class, though
17:41<andythenorth>moi aussi
17:42<andythenorth>I considered setting it for ENSP, but couldn't quite see the benefit
17:42<andythenorth>it's too likely to lead to unhelpful exclusions
17:42-!-HerzogDeXtEr2 [] has joined #openttd
17:42<andythenorth>it's highly specific
17:42<@planetmaker>and pointless class-cruft ;-)
17:43<andythenorth>adding such a specific cargo is unlikely to help gameplay
17:43<andythenorth>and if it was added, it would have poor vehicle support
17:43<andythenorth>double bad
17:43<frosch123>planetmaker: do you know some other modern vehicle set which might use those cargo classes?
17:43-!-KouDy [] has joined #openttd
17:44-!-HerzogDeXtEr1 [] has quit [Ping timeout: 480 seconds]
17:44<frosch123>(newer than egrvts)
17:44<andythenorth>do they do any harm?
17:44<@planetmaker>I don't really know. You're still talking of covered, do you?
17:44<@planetmaker>does ecs use it?
17:44<andythenorth>I believe covered is set in FIRS
17:45<andythenorth>by request of MB somewhere
17:45<frosch123>andythenorth: does heqs or fish use "covered/sheltered" or "oversized"?
17:45<@planetmaker>(yes, it's no vehicle set)
17:45<andythenorth>let me check
17:45<frosch123>planetmaker: industry sets do not matter
17:45<frosch123>only vehicle sets
17:45-!-TWerkhoven2 [] has quit [Quit: He who can look into the future, has a brighter future to look into]
17:45<andythenorth>heqs does not use either. I was going to add it for some heavy transport trucks in HEQS, but there are no useful cargos for them
17:45<andythenorth>I might as well just hard code ENSP
17:46<@planetmaker>frosch123: I use them in ogfx+
17:46<@planetmaker>hm... no, not sheltered
17:46-!-KouDy2 [] has quit [Ping timeout: 480 seconds]
17:46<@planetmaker>but oversized and hazardous. As 'not applicable' :-P
17:47<andythenorth>frosch123: I think HEQS excludes covered, hazardous and oversized on most vehicles - by accident
17:47<frosch123>fish uses them
17:47<andythenorth>I'd have to double check the mask
17:47<andythenorth>fish includes or excludes?
17:48<frosch123>fish and heqs use 0x03FF to include all cargos
17:48<frosch123>some heqs vehicles exclude 0x03EF
17:48<@planetmaker>2ccTS exludes wxFFFB by default
17:48<Eddi|zuHause>CETS uses sheltered
17:48<frosch123>(everything but bulk)
17:49<andythenorth>frosch123: it's accident not design that FISH / HEQS include oversized etc
17:49<andythenorth>arguably they also support clean and neo-bulk already :P
17:49<Eddi|zuHause>not entirely sure whether that's in the right way, though
17:49<@planetmaker>well. CETS can still change, I think
17:49-!-HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
17:50<andythenorth>Eddi|zuHause: where do you use it?
17:51<andythenorth>much as I am convinced by classes in general, the exclusions are a headache
17:51<andythenorth>if we set covered on grain...
17:51<andythenorth>none of these
17:51<andythenorth>can be used for grain
17:51<Eddi|zuHause>andythenorth: the open wagon says "include bulk, but exclude sheltered" and then there's a special covered wagon for "sheltered"
17:51-!-hanf [] has quit [Quit: Leaving]
17:52<andythenorth>there are differences between 'cargo needs' and 'cargo can' and 'wagon provides' and 'wagon can't'
17:52<Eddi|zuHause>the covered wagon is mostly for sensitive cargos like some (powderized) chemicals
17:52<Eddi|zuHause>it's thus called "Kaliwagen"
17:52-!-Rezt [] has quit [Quit: Textual IRC Client:]
17:53<@planetmaker>K&S ;-)
17:53-!-pjpe [] has joined #openttd
17:55<andythenorth>tarpaulins are covers
17:56<@planetmaker>Eddi|zuHause: and the first google hit on "Kaliwagon" is...
17:56<andythenorth>Eddi|zuHause: and in 1830 with UKRS 2?
17:56<Eddi|zuHause>andythenorth: this is a wagon ca. 1909
17:56<andythenorth>I know :)
17:57<Eddi|zuHause>andythenorth: opposed to the open wagon:
17:57<andythenorth>but if pikka does the correct thing and excludes covered from open wagons, then there is zero cargo support for grain
17:57<andythenorth>in 1830
17:57<andythenorth>it can't go in vans because they exclude bulk
17:57<andythenorth>so we create a system where it's impossible to do the right thing
17:57-!-Progman [] has quit [Remote host closed the connection]
17:58*planetmaker needs sleep now, though. Good night
17:58<andythenorth>unless you tell me I'm wrong about what the correct thing to do is
17:59<andythenorth>if an author doesn't provide alternatives, then they probably shouldn't exclude covered from open wagons
17:59<Eddi|zuHause>andythenorth: you could exclude it only from the later open wagons, not from the first versions
17:59-!-Devroush [] has quit [Ping timeout: 480 seconds]
18:00<andythenorth>or we could argue to make the covered / sheltered meaning more precise
18:00<andythenorth>currently I read it as 'must have a roof'
18:00<andythenorth>which is probably untrue
18:01<+michi_cc>Grain, maize and similar are of the type 'a roof would be nice', but unlike some chemicals they won't dissolve if they get so it's not a 'must absolutely have a roof' cargo.
18:01<Eddi|zuHause>do we need a specialized wagon for "Elefanten, Kamele und Giraffen"?
18:01<+michi_cc>s/get/get wet/
18:01<andythenorth>Eddi|zuHause: absolutely
18:01<andythenorth>there are B&B circus train sprites in US Set apparently as an easter egg
18:01<andythenorth>they require a very specific refit :P
18:02<andythenorth>there's no AND combination for classes?
18:02<andythenorth>we have to rely on exclusions?
18:02<Eddi|zuHause>no, there's only "OR" and "AND NOT"
18:02<andythenorth>the kaliwagen should be for cargos that are bulk AND covered
18:03<andythenorth>the exclusion is unhelpful
18:03<andythenorth>a cb could handle that better
18:03<andythenorth>much better
18:03<Eddi|zuHause>now where is that CB when you need it? :p
18:03<andythenorth>also - the open wagon 'covered' problem is a straw man, just fit a tarpaulin
18:04<andythenorth>(without the tarpaulin, your straw man gets wet) :P
18:05-!-Cybertinus [] has quit [Remote host closed the connection]
18:05<andythenorth>I had to make WOOL covered/sheltered - due to this
18:06-!-Ola [] has quit [Ping timeout: 480 seconds]
18:06<andythenorth>not sure why it's helpful though
18:07<frosch123>George: in case you didn't notice, there are at least 3 newer topics in the technical newgrf forum, which might interest you
18:09<andythenorth>MB replied in the classes thread
18:09<andythenorth>and I need to sleep, not argue with him :(
18:09*andythenorth has a modest proposal
18:09<andythenorth>as MB has a perfect system, he has to code all of our sets
18:10-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
18:12-!-mahmoud [] has joined #openttd
18:19*andythenorth -> bed
18:21<Zuu>In a sleeper rail car? :-)
18:22<andythenorth>what class is that?
18:22*andythenorth leaves you with this:
18:23<andythenorth>good night
18:23-!-andythenorth [] has quit [Quit: andythenorth]
18:24<Eddi|zuHause>Zuu: is that a railcar for sleepers?
18:24<Zuu>a rail car with beds for sleeping people.
18:24-!-Brianetta [] has quit [Quit: Tschüß]
18:25-!-Pixelator [] has joined #openttd
18:27-!-sla_ro|master [slaco@] has quit []
18:32-!-valhallasw [~valhallas@] has quit [Ping timeout: 480 seconds]
18:33-!-KouDy [] has quit [Quit: Leaving.]
18:34-!-Zuu [] has quit [Ping timeout: 480 seconds]
18:40-!-frosch123 [] has quit [Remote host closed the connection]
18:47-!-DDR_ [~chatzilla@] has joined #openttd
18:52-!-Pixelator was kicked from #openttd by DorpsGek [Wrong channel. Retry in #openttdcoop.]
19:12-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
20:14-!-nicfer [~nicfer@] has joined #openttd
20:14<nicfer>so many time :D
20:17<__ln__>time is uncountable
20:25-!-Pulec [] has quit []
20:27<z-MaTRiX>also, this is eternity
20:32-!-nicfer [~nicfer@] has quit [Ping timeout: 480 seconds]
20:41-!-nicfer [~nicfer@] has joined #openttd
20:51-!-blotek___ [] has joined #openttd
20:58-!-blotek_ [] has quit [Ping timeout: 480 seconds]
21:38-!-glx is now known as Guest16016
21:38-!-glx_ [glx@2a01:e35:2f59:c7c0:b91c:6cfd:c68b:ee15] has joined #openttd
21:38-!-mode/#openttd [+v glx_] by ChanServ
21:38-!-glx_ is now known as glx
21:43<nicfer>can I write a GRF with NML that adds a new vehicle using default game sprites?
21:44-!-Guest16016 [glx@2a01:e35:2f59:c7c0:b91c:6cfd:c68b:ee15] has quit [Ping timeout: 480 seconds]
21:49-!-blotek___ [] has quit [Remote host closed the connection]
22:26-!-rhaeder1 [] has joined #openttd
22:31-!-rhaeder [] has quit [Ping timeout: 480 seconds]
22:56<nicfer>I was trying to compile a test grf but I got this error:
22:56<nicfer>nmlc: "input", line 3: Syntax error, unexpected token "name"
22:57<nicfer>oh, I know why
22:57<nicfer>I forgot a semicolon
22:58<nicfer>now I got another error:
22:58<nicfer>nmlc: "input", line 35: Unrecognized identifier 'spritegroup_flatbed_truck_1_goods' encountered
23:00-!-glx [glx@2a01:e35:2f59:c7c0:b91c:6cfd:c68b:ee15] has quit [Quit: bye]
23:00<nicfer>I'm following the tutorial at and it told me that it's written so
23:33-!-nicfer [~nicfer@] has quit [Ping timeout: 480 seconds]
23:42-!-nicfer [~nicfer@] has joined #openttd
---Logclosed Mon Nov 07 00:00:59 2011