IRC logs for #openttd on OFTC at 2022-04-18
⏴ go to previous day
00:54:36 *** WormnestAndroid has joined #openttd
01:40:42 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
01:54:56 *** Wormnest has quit IRC (Quit: Leaving)
01:55:00 *** _aD has quit IRC (Quit: leaving)
02:23:10 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:28:24 *** Cthulhux has quit IRC (Quit: Cthulhux)
05:10:34 *** sla_ro|master has joined #openttd
05:49:45 *** HerzogDeXtEr has joined #openttd
05:52:56 *** snail_UES_ has quit IRC (Quit: snail_UES_)
06:21:03 *** sla_ro|master has quit IRC ()
07:41:04 *** gelignite has joined #openttd
08:03:00 *** andythenorth has joined #openttd
08:16:33 *** wybpip[m] has joined #openttd
08:16:33 *** wybpip[m] has left #openttd
08:26:37 *** Gustavo6046 has quit IRC (Quit: Goodbye! Leave messages at my XMPP @ gustavo6046@anonym.im or my Discord Gustavo6046#9009 or possibly my Mastodon gustavo6046@fosstodon.org – I don't ch)
08:29:45 <andythenorth> there's an entire system of codes for e.g. 'bullhead rail', and the material etc
08:29:53 * andythenorth thinks this might be unexploited
09:15:53 <TrueBrain> hmm .. currently I send to the TrueGRF compiler something like "weight = 16", which means 1000kg
09:16:08 <TrueBrain> in other words, it uses the internal OpenTTD values
09:16:26 <TrueBrain> but as those files are now in YAML, I wonder .. should I make that "weight = 1000", and let the compiler do the conversion
09:17:03 <TrueBrain> the main issue I have with that, is that "weight = 999" has no meaning
09:30:55 *** sla_ro|master has joined #openttd
10:00:47 *** andythenorth has quit IRC (Quit: andythenorth)
10:46:08 *** gelignite has quit IRC (Read error: Connection reset by peer)
11:05:26 *** frosch123 has joined #openttd
11:19:33 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:22:18 *** WormnestAndroid has joined #openttd
12:07:22 <FLHerne> Yeah, but then you get the same hell as NML rounding
12:07:58 <NGC3982> is nml still used for something ttd related?
12:08:12 <FLHerne> where you have to be really careful to make sure every input value and every combination of values rounds *back* to whatever it was input as
12:08:43 <FLHerne> NGC3982: the majority of recent newgrfs?
12:09:03 <FLHerne> also, you couldn't really use it for anything non-TTD-related
12:09:10 <NGC3982> i always thought nml was some ancient moon thing you guys did way back when
12:09:18 <TrueBrain> FLHerne: I have that issue anyway .. was just wondering if I should put that in the compiler or in the editor .. still not sure :D
12:10:02 <FLHerne> NGC3982: NML is still the latest thing, at least until TrueGRF works
12:10:09 <FLHerne> maybe you're thinking of NFO
12:10:15 <TrueBrain> TrueGRF will never replace NML :)
12:10:22 <FLHerne> of course NML pretty much compiles to NFO anyway
12:10:35 <NGC3982> sorry, i was thinkinh about nfo
12:10:36 <FLHerne> TrueBrain: maybe, but then NML doesn't allow implementing everything NFO did
12:11:01 <FLHerne> and for the most part no-one cares, unless they're doing stations, except glx fixed that
12:17:21 <frosch123> TrueBrain: unit conversion in nml fails for two reasons: (1) nml can only do unit conversions in properties, it can't do it in callbacks because it does not know to which callback a switch belongs. but this may not apply to truegrf. (2) some things have no intuitive unit. nml uses a self-invented unit for cargo payment, but it only adds to the confusion
12:17:48 <TrueBrain> ha, yeah, that doesn't help
12:17:56 <TrueBrain> yeah, weight is one of the more clear examples
12:18:01 <TrueBrain> in the UI, you insert kg
12:18:06 <TrueBrain> but you can only do it in steps of 62.5kg
12:18:14 <TrueBrain> which, by no accident, maps to the OpenTTD unit perfectly
12:18:27 <TrueBrain> but that still leaves the question .. should the in-between YAML file contain the kg, or the internal value
12:18:36 <TrueBrain> I find it tricky .. really depends on how you look at it
12:19:04 <glx> yaml is not supposed to be edited by human I guess
12:19:16 <TrueBrain> it is meant to be human readable for sure
12:19:54 <frosch123> currently your yaml only has integers, with units you would need floats
12:20:03 <TrueBrain> YAML supports both, yes
12:20:16 <TrueBrain> (in fact, I believe everything is a double, if I am not mistaken the specs)
12:20:49 <FLHerne> frosch123: does it still use the weird cargo-payment unit? I thought there was a PR to delete that stupid idea
12:21:13 <frosch123> FLHerne: different thing :)
12:21:30 <FLHerne> TrueBrain: internal value then
12:21:42 <frosch123> nml uses a custom unit in the property. the PR was about nml applying a unit to a scalar value without unit
12:21:43 <FLHerne> if the UI won't ever let you set it to something that doesn't map to one
12:21:50 <TrueBrain> yeah, there is no black&white answer here :)
12:22:04 <FLHerne> otherwise someone can naïvely edit the yaml to something the UI wouldn't allow
12:22:23 <glx> and they'll complain the value is not right in openttd
12:22:41 <TrueBrain> people will complain no matter what :P
12:22:49 <TrueBrain> but I could always refuse invalid values
12:22:52 <TrueBrain> I mean .. that is not that hard
12:22:58 <frosch123> TrueBrain: it's probably a lot easier to keep the units in the gui, and put internal values into the yaml
12:23:11 <frosch123> supporting units in the compilers is really hard
12:23:15 <TrueBrain> easier is relative .. I am now doing this crap in Javascript
12:23:18 <TrueBrain> not sure what I prefer :P
12:23:22 <frosch123> speeds have like 5 different units in different places
12:23:30 <frosch123> which are not easy to detect
12:23:36 <TrueBrain> I have to deal with it anyway :)
12:24:07 <TrueBrain> guess the question is more, do I see another future for the YAML files besides TrueGRF UI on top of it
12:25:28 *** andythenorth has joined #openttd
12:25:44 <glx> storing internal value will be easier, and whatever you chose you'll still have to convert from user unit (km/h, mph, m/s, ...) to something else
12:25:46 <TrueBrain> that is so much more readable than 1/16th of a 1000kg :P
12:26:05 <TrueBrain> I think you strongly misestimate the "easier" part :P
12:26:11 <TrueBrain> it really really doesn't matter where the conversion is done :)
12:26:40 <TrueBrain> similar, I was wondering if I should set classes by name
12:26:45 <TrueBrain> or by this weird bitfield-ish-like thingy
12:26:56 <TrueBrain> now it reads: "classes: 128"
12:27:04 <TrueBrain> which is a bit meaningless
12:28:01 <andythenorth> hmm I want to use a bitfield in my railtype label scheme
12:28:10 <andythenorth> but I've never implemented one in python :P
12:28:17 <andythenorth> probably 1 << n or something
12:29:45 <andythenorth> never used a byte-sized bitfield either
12:31:23 <andythenorth> yeah, nfo industry action 0 flags are bytesized
12:34:28 <TrueBrain> meh; I just don't know. Conflicting goals :)
12:39:42 <andythenorth> what's the better user experience?
12:39:58 <andythenorth> the reality of what shows up in game is dictated by internal representation
12:40:11 <TrueBrain> it is more about: who is the user of the YAML :)
12:40:12 <andythenorth> so WYSIWYG suggest the UI should represent that to end user
12:40:23 <andythenorth> oh the YAML user, it's an intermediate, doesn't mater
12:40:36 <andythenorth> where you do it same shit, different day
12:40:44 <TrueBrain> no, that is in fact the question .. is it really intermediate? :D
12:40:57 <andythenorth> I think it's intermediate
12:41:02 <TrueBrain> mainly I am rather annoyed how difficult Javascript is to handle simple stuff
12:41:05 <andythenorth> I am frequently wrong so eh
12:41:10 <TrueBrain> so much hooks and shit ...
12:41:12 <glx> it's a choice between convert on compile and convert on edit
12:41:15 <andythenorth> Life is Better If You Avoid Javascript
12:41:28 <TrueBrain> as when I do it in Javascript, I need to convert twice
12:41:32 <TrueBrain> (once for read, once for write)
12:41:40 <TrueBrain> if I do it in the compiler I only have to do it once
12:41:42 <andythenorth> so avoid the javascript, it's just a disgusting programming language
12:41:46 <andythenorth> for reasons I cannot explain
12:41:54 <andythenorth> but I have a 22 year dislike of it
12:42:13 <andythenorth> I think that's long enough to have given it fair chance
12:42:16 <glx> you'll still have to convert for read and write whatever unit you chose to store
12:42:37 <frosch123> TrueBrain: but the gui has to parse the unit from the yaml
12:42:44 <frosch123> in whatever way that is written
12:42:48 <TrueBrain> I can pick the unit in the YAML :)
12:42:54 <TrueBrain> currently it is dictated by what OpenTTD uses internally
12:42:58 <andythenorth> if I want to write YAML directly from a compile, it would suit me to not have to convert that to internal OpenTTD representation
12:42:58 <TrueBrain> take weight .. which is in a 1/16th unit
12:43:01 <TrueBrain> when I would make it kg
12:43:06 <TrueBrain> the UI doesn't need to do any conversion
12:43:23 <glx> but if user wants to use pounds ?
12:43:31 <TrueBrain> but I guess cargo classes is even easier to show what I mean
12:43:39 <TrueBrain> now I need to convert a number and bitfield in one back to strings
12:43:50 <TrueBrain> if I make it two fields: cargoclass and cargoclassoptions, or what-ever
12:43:58 <TrueBrain> the UI would become so much simpler to deal with
12:44:11 <andythenorth> for an audience of one (me) I'd rather your compile accepted values with real-world units, not internal representation :P
12:44:26 <TrueBrain> andythenorth: that is in summary what I am debating, yes
12:44:45 <TrueBrain> similar with cargo penalty rate .. this 2.5 days unit is just .. ugh, annoying :P
12:45:06 <andythenorth> you can't escape doing the work somewhere
12:45:29 <andythenorth> if you do it once in the compile, no other clients writing / reading the YAML have to deal with it
12:45:43 <andythenorth> but sometimes values will drift
12:45:50 <TrueBrain> I just wish OpenTTD pick somewhat less complicated units :P
12:46:17 <TrueBrain> can we update the NFO version and fix them all?! :P :P
12:46:42 <frosch123> TrueBrain: not sure the cargo aging becomes better with a different unit :) maybe consider a slider without numbers and just two labels "decays fast", "decays slow" :p
12:47:01 * andythenorth might leave if we're talking about cargo aging
12:47:19 <andythenorth> I have railtype label scheme to invent :P
12:48:24 <frosch123> andythenorth: i wrote 17kb of blog, i am still not finished with cargo classes. i don't think i will get to railtypes :p
12:48:37 <andythenorth> I did wonder this morning
12:48:48 <andythenorth> could we optionally mask the railtype label?
12:48:58 <andythenorth> so we could say 'first byte is broad compatibility'
12:49:25 <andythenorth> anyway, I think I've 'solved' it, with my own label schema
12:49:41 <andythenorth> I considered versioning that schema in advance, but nah, yolo
12:55:38 <TrueBrain> owh, and I forgot the shit called "price" :D haha
12:55:44 <TrueBrain> ugh .. the case is growing strong ..
12:55:52 <TrueBrain> item.price = Math.round((price * (1 << 21)) / 10 / 20 / 255);
12:55:58 <TrueBrain> to convert from pounds to what-ever OpenTTD does
12:56:11 *** snail_UES_ has joined #openttd
12:58:26 <andythenorth> snail_UES_ o/ does FR trains use axle load?
13:05:32 *** snail_UES_ has quit IRC (Quit: snail_UES_)
13:07:24 <michi_cc> TrueBrain: You do realize that you can't set a price pound anyway unless you also forcefully set all base costs in the GRF, right?
13:07:54 <TrueBrain> I have no clue what you are aiming at
13:08:01 <TrueBrain> all I know, is that a cargo price was not in pounds
13:09:38 <michi_cc> Interesting, cargo seems to be the one exception that does not use base costs, it seems.
13:10:46 <michi_cc> But e.g. industry construction cost is dependent on the base cost for industries, so the pound to internal units factor can be changed by another NewGRF.
13:11:13 <TrueBrain> yeah, I called it "fund cost multiplier"
13:16:14 <TrueBrain> @calc 255 * 2.5 * 2
13:17:46 <frosch123> costs could use % as unit. 0% - cheap, 100% - expensive
13:18:12 <frosch123> with inflation and currencies, costs have about no unit at all
13:21:24 <TrueBrain> right .. 2 more things to port from the old TrueGRF ... cargo colour and cargo icon ..
13:21:36 <TrueBrain> but otherwise it seems things are getting there :)
13:22:34 <TrueBrain> just now a really boring looking list of information to fill in .. pretty sure I can style that a bit nicer
13:22:38 <TrueBrain> but what-ever, not now :D
13:26:29 *** tokai|noir has joined #openttd
13:26:29 *** ChanServ sets mode: +v tokai|noir
13:33:25 *** tokai has quit IRC (Ping timeout: 480 seconds)
13:44:47 *** Cthulhux has joined #openttd
13:52:05 <andythenorth> nielsm I've basically stolen this, and adapted (also simplified) it to express 'requirements' via the label :P https://0x0.st/ocxA.txt
14:12:21 <nielsm> does that mean you can't read them any longer?
14:13:22 <andythenorth> well, my scheme is relatively simple
14:13:38 <andythenorth> labels in the form IHA_ for vanilla rail vehicle
14:13:47 <andythenorth> IHB_ for vanilla electrified rail vehicle :P
14:14:05 <andythenorth> last byte is used for stupid modifiers, and only rarely
14:14:32 <andythenorth> e.g. IHAA for 'allowed to use dedicated high speed lines'
14:15:17 <andythenorth> I think the missing link is that prop 05 should be expressing vehicle capabilities / requirements, which your spec showed me :)
14:15:43 <andythenorth> the entire current scheme seems ass backwards to me because of that one tiny detail
14:16:05 <andythenorth> but it's completely solvable without changing newgrf spec
14:16:19 <nielsm> yeah vehicle being able to run on a track is really a combination of all those factors that need to align
14:16:42 <andythenorth> afaict, the purpose of the entirety of railtypes is to hand lots of control to railtype author
14:17:20 <andythenorth> but if the vehicle set author tries to pre-empt that and specify railtype explicitly
14:18:16 <andythenorth> my route requires actively maintained grfs but eh
14:18:34 <andythenorth> I was told n times to reuse existing cargo labels 'because nobody will maintain the vehicle sets'
14:18:59 <andythenorth> anyway, I will implement, and we will find out why I am wrong :P
14:46:41 * andythenorth about to change railtype labels in a running game :P
14:46:45 <andythenorth> see how that goes
14:54:11 <andythenorth> hmm one stuck train, had to crash another one into it
14:56:25 <andythenorth> oh and a path reservation that wouldn't clear from a tile
14:57:27 <andythenorth> lol this did not go well
15:04:09 <andythenorth> haha tile_powers_railtype() trips up my railtype labels plan :)
15:04:19 <andythenorth> there is really no sensible way to not have 'ELRL' there
15:04:33 <andythenorth> but ELRL wasn't in my railtypetable, it's a fallback :P
15:09:24 <andythenorth> is there any cost or downside to having railtypes in the vehicle grf railtypetable?
15:09:30 <andythenorth> it's just a bunch of labels to index into?
15:13:33 <frosch123> the cost is that you can only have 255 in your grf :)
15:13:49 <frosch123> you won't be able to list all 4 billion labels
15:15:51 <andythenorth> 'this is terrible, how will I cope?'
15:16:48 <andythenorth> let's see if I broke anything yet
15:18:08 <andythenorth> seems not, must try harder
15:23:34 <andythenorth> hmm no way to see value of train prop 05 in game?
15:26:37 <andythenorth> if have a vehicle with prop 05 "FOO_", which falls back to "ELRL" using the nml magic
15:27:34 <andythenorth> and I define the "ELRL" railtype so that it provides an alternate for "FOO_"
15:27:41 <andythenorth> what will the vehicle prop 05 value be? :P
15:28:03 <andythenorth> we have vehicle based alternates, and railtype based alternates, and I don't know who wins :P
15:29:41 <michi_cc> prop 05 will always the numerical index of the position into your RTT.
15:30:15 <andythenorth> I am assuming nml remaps using the value of prop 05 on the vehicle using conditionals around some action 0s
15:30:30 <andythenorth> I don't fancy trying to read the nfo :)
15:31:13 * andythenorth tries reading the nfo
15:36:06 *** NGC3982 has quit IRC (Quit: leaving)
15:36:24 *** NGC3982 has joined #openttd
15:48:35 <andythenorth> ok far as I can tell, if "ELRL" is an alternate for "FOO_", it all works
15:48:45 <andythenorth> not 100% sure my tests are valid, but eh
16:32:14 <andythenorth> lol railtype spec is awesome :P
16:32:18 <andythenorth> such potential for madness
16:33:09 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
16:34:16 *** WormnestAndroid has joined #openttd
16:41:17 *** Eddi|zuHause has quit IRC (Read error: Connection reset by peer)
16:42:14 *** Eddi|zuHause has joined #openttd
16:57:51 <andythenorth> so can I change vehicle speed by railtype?
16:57:57 <andythenorth> or does that desync? :D
17:04:12 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
17:27:53 *** Gustavo6046 has joined #openttd
17:50:33 <andythenorth> oh what's more useful for railtype authors?
17:50:44 <andythenorth> indicate 'light' standard gauge vehicles, or 'heavy'?
17:51:21 <andythenorth> a national rail system tends to have a default standard for mainlines, and older / slower / less maintained track is marked up accordingly with route limits
17:56:31 *** supermop_work has joined #openttd
18:11:36 * andythenorth does funny things
18:15:26 <andythenorth> ok dare I say it, I think understand railtypes :P
18:15:31 <andythenorth> thanks all who helped
18:16:12 <frosch123> ok, i started a stop watch
18:16:51 <frosch123> how long until "delete everything"?
18:19:03 <andythenorth> frosch123 by 11pm I think
18:19:19 <andythenorth> do we have a global var for 'railtype is available'?
18:20:41 * andythenorth was in wiki search, many results :)
18:20:43 <frosch123> oh, good point... railtype_available is passed a railtype label, not a index into the rtt
18:20:57 <frosch123> so you can use it to test all 4 billion types
18:21:06 <frosch123> and then compose the rtt dynamically
18:22:38 <andythenorth> this might be needed
18:24:19 * andythenorth tests some things
18:27:17 <andythenorth> so I define vehicle prop 05 in terms of what the vehicle wants / can do
18:27:43 <andythenorth> then railtype authors can do what they like with that, via alternative_railtype_list
18:28:00 <andythenorth> the number of railtype grfs being actively maintained suggests this might never be used but eh
18:31:51 <andythenorth> maybe I should add a mapping in action 14 of IHXY types to standardised types
18:32:09 <andythenorth> 'sounds like fun'
18:33:28 <andythenorth> "before setting up a game, I would like to assign railtype labels, yes please"
18:34:15 <supermop_work> andythenorth: making rails?
18:52:59 <DorpsGek> - Update: Translations from eints (by translators)
19:10:01 <supermop_work> hmm news mispelled my name
19:21:28 <andythenorth> supermop_work so are you now homeless?
19:34:17 <TrueBrain> Hope you get sorted soon ...
19:44:50 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
20:00:17 *** Wormnest has joined #openttd
20:18:42 <supermop_work> going to look for apartments to sublet this week
20:30:10 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
20:31:10 *** geli has quit IRC (Quit: Stay safe!)
20:32:43 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:53:20 *** sla_ro|master has quit IRC ()
21:21:09 *** andythenorth has quit IRC (Quit: andythenorth)
21:22:52 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:57:46 *** Wormnest has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** supermop_work has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** WormnestAndroid has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** felix has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** MaverickFischer has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** dwfreed has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** nnyby has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** Vadtec has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** mikegrb has quit IRC (synthon.oftc.net reflection.oftc.net)
21:57:46 *** Gustavo6046 has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** esselfe has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** Nemoder has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** greeter has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** gregdek has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** colde has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** mindlesstux has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** Extrems has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** twpol has quit IRC (synthon.oftc.net larich.oftc.net)
21:57:46 *** dale has quit IRC (synthon.oftc.net weber.oftc.net)
21:57:46 *** rightnut has quit IRC (synthon.oftc.net weber.oftc.net)
21:57:46 *** ST2 has quit IRC (synthon.oftc.net weber.oftc.net)
21:57:46 *** reldred has quit IRC (synthon.oftc.net weber.oftc.net)
21:57:46 *** murr4y has quit IRC (synthon.oftc.net weber.oftc.net)
21:57:46 *** Ttech has quit IRC (synthon.oftc.net weber.oftc.net)
21:58:58 *** rightnut has joined #openttd
21:58:58 *** reldred has joined #openttd
21:59:03 *** Wormnest has joined #openttd
21:59:03 *** supermop_work has joined #openttd
21:59:03 *** WormnestAndroid has joined #openttd
21:59:03 *** MaverickFischer has joined #openttd
21:59:03 *** dwfreed has joined #openttd
21:59:03 *** mikegrb has joined #openttd
21:59:10 *** Gustavo6046 has joined #openttd
21:59:10 *** esselfe has joined #openttd
21:59:10 *** Nemoder has joined #openttd
21:59:10 *** greeter has joined #openttd
21:59:10 *** Extrems has joined #openttd
21:59:10 *** mindlesstux has joined #openttd
21:59:10 *** gregdek has joined #openttd
23:04:12 *** virtualrandomnumber has joined #openttd
23:04:42 *** virtualrandomnumber has quit IRC ()
continue to next day ⏵
