Log for #openttd on 5th January 2022:
Times are UTC Toggle Colours
00:03:07  *** Gustavo6046 has joined #openttd
00:45:07  <DorpsGek> [OpenTTD/team] tmn opened issue #282: [nb_NO] Translator access request
00:46:20  <DorpsGek> [OpenTTD/team] tmn opened issue #283: [nn_NO] Translator access request
02:37:35  *** Wormnest has quit IRC
02:53:02  *** Gustavo6046 has quit IRC
02:53:18  *** Gustavo6046 has joined #openttd
02:54:54  *** Gustavo6046 has quit IRC
02:54:59  *** Gustavo6046 has joined #openttd
02:55:10  <Gustavo6046> Oops
03:05:00  *** iSoSyS has joined #openttd
03:20:46  *** glx has quit IRC
03:39:41  *** _aD has quit IRC
03:46:09  *** Flygon has joined #openttd
03:47:03  *** D-HUND has joined #openttd
03:50:26  *** debdog has quit IRC
05:47:11  *** supermop_Home_ has quit IRC
07:15:19  *** sla_ro|master has joined #openttd
07:52:21  *** tokai has joined #openttd
07:52:21  *** ChanServ sets mode: +v tokai
07:59:22  *** tokai|noir has quit IRC
08:05:57  *** andythenorth has joined #openttd
08:24:09  *** felix has quit IRC
08:27:49  <peter1138> Well
08:28:20  *** felix has joined #openttd
09:05:33  *** WormnestAndroid has quit IRC
09:57:32  *** Gustavo6046 has quit IRC
09:57:58  *** Gustavo6046 has joined #openttd
10:20:13  <TrueBrain> "For earlier versions of TTDPatch the variable .."
10:20:17  <TrueBrain> I love the vague reference :D
10:27:23  <TrueBrain> hmm ... are temp registers of a procedure local to the procedure, or local to the original varaction?
10:28:21  <TrueBrain> reading by the text, I assume the first ..
10:36:43  <TrueBrain> no, there is only 1 _temp_store .. okay
10:50:38  *** Gustavo6046 has quit IRC
10:53:07  <TrueBrain> what makes NML really hard to read for me, is that the keywords provided by NML is a HUGE list .. so often I am confused when reading NML: is this thing locally defined, or defined by NML
10:53:22  <TrueBrain> some namespacing would really have helped
10:58:11  <DorpsGek> [OpenTTD/OpenTTD] J0anJosep opened pull request #9780: Codechange: Make RoadScopeResolver constructor inlineable.
11:00:41  <TrueBrain> andythenorth: am I right in that "num_supplies_delivered" in FIRS primary industries is currently "write-only"? (as in, it isn't actually used anywhere?)
11:01:09  <TrueBrain> well, except for the 28th entry (num_supplies_delivered_27)
11:01:49  <TrueBrain> ah, no, nevermind
11:01:51  <andythenorth> it should be read somewhere
11:01:56  <andythenorth> it's shuffled every 256 ticks
11:01:57  <TrueBrain> yeah, found it ..
11:02:06  <TrueBrain> NML is not the friendliest to read :P
11:02:39  <TrueBrain> basically, the boost is calculated based on the last 27 deliveries
11:03:51  <andythenorth> yes
11:03:56  <TrueBrain> cool, tnx
11:05:10  <TrueBrain> I guess that makes boosting a bit more relaxed, you only have to deliver 4 times a year or so
11:05:45  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9780: Codechange: Make RoadScopeResolver constructor inlineable.
11:06:01  <TrueBrain> now approve my backport PR! :P
11:13:08  <TrueBrain> andythenorth: the tooltip of secondary industries say that you get a boost if you deliver all 3 cargoes (for example), but is this really true?
11:13:20  <andythenorth> yes
11:13:26  <TrueBrain> as in, the code reads as if the accepting cargoes are just adding to what is being produced?
11:13:27  <andythenorth> not in all cases, it's industry specific
11:13:31  <TrueBrain> ah
11:13:44  <andythenorth> amounts produced are multiplied by a fraction
11:13:54  <andythenorth> it might be e.g 2/8 if one cargo delivered
11:14:00  <andythenorth>  5/8 if 2 cargos delivered
11:14:06  <andythenorth> 8/8 if all 3 cargos delivered
11:14:10  <andythenorth> (examples)
11:14:17  <TrueBrain> ah, I see
11:14:32  <andythenorth> there's also a split on the output, which is fractional, but that's totally unrelated to the input above
11:15:04  <TrueBrain> so the current_production_ratio is additive of all inputs
11:15:12  <TrueBrain> and used as multiplier to the individual
11:15:58  <TrueBrain> so delivering only wheels to the car-maker is enough to make some cars, just slower :D
11:16:03  <TrueBrain> rEaLiSm :P
11:16:31  <TrueBrain> okay, and here too, if you delivered any in the last 3 months, it enables its fraction
11:16:32  <TrueBrain> gotcha
11:16:34  <TrueBrain> tnx :)
11:17:09  <TrueBrain> I love how you seem to be using persistent storage for temporary values :D
11:17:11  <TrueBrain> but that is fine :)
11:18:27  <TrueBrain> and I guess closure_counter is never really implemented?
12:10:33  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9779: Backport master into release/12
12:10:39  <TrueBrain> \o/
12:10:54  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9779: Backport master into release/12
12:11:15  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9772: Fix missing icon
12:11:29  <LordAro> you're quick
12:11:46  <TrueBrain> trying to design a simple RPN-based language .. so I can use the distraction :P
12:17:41  <DorpsGek> [OpenTTD/OpenTTD] LordAro requested changes for pull request #9726: Fix: Prevents crash when no industries are present
12:18:33  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9769: Doc: Fix broken links in GitHub docs
12:23:20  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9769: Doc: Fix broken links in GitHub docs
12:24:39  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9772: Fix missing icon
12:24:48  <TrueBrain> abusing admin powers, as rebasing those PRs is stupid
12:24:55  <DorpsGek> [OpenTTD/OpenTTD] LordAro requested changes for pull request #9770: Fix #9765: Incorrect Company Values
12:25:25  <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #9780: Codechange: Make RoadScopeResolver constructor inlineable.
12:36:06  <TrueBrain> $num_supplies_delivered[27] $num_supplies_delivered[27] %incoming_cargo_waiting[@i] + =
12:36:16  <TrueBrain> collect all the prefixes?
12:37:40  <LordAro> are you sure you're not writing perl?
12:37:59  <TrueBrain> lol
12:39:16  <LordAro> i think that could actually be valid perl, without the "+ =" on the end
12:39:57  <TrueBrain> sadly I need some meta-language, as I am not sure NewGRF is turing complete :P
12:42:29  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9739: Copy server invite code to the clipboard automatically
12:42:56  <LordAro> i'd be surprised if it wasn't
12:43:59  <TrueBrain> looping is a bit of the issue
12:44:11  <TrueBrain> you could do tail-recursion, I guess
12:44:15  <DorpsGek> [OpenTTD/OpenTTD] pelya commented on pull request #9739: Copy server invite code to the clipboard automatically
12:46:07  <TrueBrain> did anyone check how ^^ looks visually?
12:46:18  <TrueBrain> code-wise it reads to me that it now has a button with the text "copy to clipboard"?
12:47:01  <TrueBrain> I would expect something smaller, tbh :) Like a small icon or what-ever ;) But this text might be .. long, for the location it is at :)
12:47:21  <TrueBrain> I might be wrong, there is no visual in the PR :P
12:49:45  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9727: Feature #9059: Add buttons to toggle music in the Game Options menu.
12:54:55  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9642: Feature: Orientation of rail and road depots can be changed
12:55:13  <LordAro> TrueBrain: yeah, ideally a little icon
12:56:50  *** WormnestAndroid has joined #openttd
12:57:20  <TrueBrain> <- something like this is what a FIRS primary industry is, I think ..
12:57:29  <TrueBrain> writing RPN is hard :P
12:57:34  <TrueBrain> now the question is, can I actually parse this
12:57:49  <TrueBrain> need to fix cargo labels for sure :)
12:59:01  <LordAro> if you're not careful you'll invent nml2.0 :p
12:59:53  <TrueBrain> I really hope not :P
13:00:16  <TrueBrain> I am mostly balancing .. am I going to do something that is easy to parse
13:00:18  <TrueBrain> or easy to write
13:23:02  <TrueBrain> why is there an "again" in action2 industry cb ..
13:26:13  *** D-HUND is now known as debdog
14:28:03  *** gelignite has joined #openttd
14:40:50  *** Smedles has quit IRC
14:49:27  *** glx has joined #openttd
14:49:27  *** ChanServ sets mode: +v glx
14:57:53  <TrueBrain> adding list support while remaining an RPN is hard :P Right, tons of updates, I think this might actually work :)
14:59:21  *** supermop_Home has joined #openttd
14:59:28  <supermop_Home> yo
15:03:19  <TrueBrain> found a use-case for "again" .. to cap the stockpile. Which is funny, as there is no need, but knowing how to do it in one go in NML is .. non-trivial :)
15:03:47  <TrueBrain> @calc 4096 / 3 * 256 / 74
15:03:47  <DorpsGek> TrueBrain: 4723.315315315315
15:20:06  *** Gustavo6046 has joined #openttd
15:30:36  *** Gustavo6046 has quit IRC
15:35:11  *** Gustavo6046 has joined #openttd
15:37:53  <glx> remember "again" is from NFO time
16:27:09  *** nielsm has joined #openttd
16:36:11  *** frosch123 has joined #openttd
16:38:21  <frosch123> TrueBrain: i think andy stored some temporary values in persistent registers for debugging. the in-game inspect window shows persistent registers, so you can use them like printf-debugging
16:38:54  <TrueBrain> So the comments told me, yes. Still funny :D
16:39:05  <glx> and temp registers are valid for current run only
16:44:14  *** Wormnest has joined #openttd
16:49:25  *** WormnestAndroid has quit IRC
16:50:26  *** WormnestAndroid has joined #openttd
16:54:30  *** WormnestAndroid has quit IRC
16:55:05  *** WormnestAndroid has joined #openttd
16:55:43  *** jottyfan has joined #openttd
17:01:23  *** Flygon has quit IRC
17:17:51  <TrueBrain> meh; I can compile Javascript to an AST in Rust easily .. but there is too much things you can do in Javascript you really cannot in NewGRF :P
17:17:57  <TrueBrain> so that would be a frustrating run for developers too
17:18:20  <frosch123> yeah, not turing complete :)
17:18:52  <TrueBrain> so I guess I should try to convert my RPN-language to NewGRF .. I think this could work
17:18:59  <TrueBrain> at least it is more readable than NFO :P
17:19:24  <frosch123> not sure about that :p
17:19:49  <TrueBrain> at least you can use variable names instead of numbers ;)
17:20:08  <TrueBrain> if you have better suggestions, I would love to hear them btw :)
17:20:44  <TrueBrain> but .. it is tricky :)
17:21:11  <frosch123> i only used RPN for terms, never for assignments or even function declarations
17:21:17  <frosch123> so, no idea :)
17:21:22  <TrueBrain> it is also not really meant for it :P
17:21:41  <TrueBrain> but I just designed a stack-based language, which RPN is too
17:21:42  <frosch123> i did not quite understood what your "global" namespace is
17:21:47  <frosch123> but maybe not important :)
17:21:49  <TrueBrain> persistent registers
17:21:54  <TrueBrain> couldn't find a better name
17:22:08  <frosch123> why are they global? they are part of the industry instance
17:22:15  <TrueBrain> mostly as I hate writing the word persistent, I have to admit :)
17:22:18  <frosch123> so i would expect "industry" namespace
17:22:32  <TrueBrain> I guess
17:22:40  <TrueBrain> felt equally weird
17:22:49  <frosch123> &industry::memory 123 []
17:23:14  <frosch123> &town::memory 123 []
17:23:14  <TrueBrain> also considered calling it "static"
17:23:25  <TrueBrain> well, "memory".. the idea is that you don't need to know the slot
17:23:27  <TrueBrain> you just give it a name
17:23:33  <TrueBrain> and the backend will assign it a slot
17:23:38  <frosch123> "grf::params 12 []" are readonly though
17:23:42  <TrueBrain> that is a bit the point .. not have to deal with numbers ;)
17:24:01  <TrueBrain> so "industry:my_variable_name"
17:24:36  <TrueBrain> guess "persistent:" would match NewGRF specs more
17:25:02  <frosch123> "persistent" would be for indexed-access again, like "memory" above
17:25:12  <TrueBrain> "persistent:my_variable_name"
17:25:16  <TrueBrain> I don't see what you mean?
17:25:19  <frosch123> the important part is the scope: industry, town, grf
17:25:22  <TrueBrain> I can type it just fine :)
17:25:39  <frosch123> "industry::my_variable_name" is different from "town::my_variable_name"
17:25:44  <TrueBrain> that is true
17:25:49  <frosch123> or "grf::my_variable_name"
17:26:03  <TrueBrain> I see you write too much C++, with all those double : :P
17:26:25  <frosch123> oh, i did not even notice you used single :
17:26:33  <frosch123> already corrected that when reading
17:26:37  <TrueBrain> :D
17:27:13  <frosch123> there was some other thing that used single :, i hated it... was it xml?
17:27:28  <TrueBrain> most things I know use a single : for scoping
17:27:33  <TrueBrain> it is only C++ that was like: NAH, one isn't enough
17:27:52  <TrueBrain> still no clue why they wanted two
17:28:10  <frosch123> so it gets a different token than : in ?:
17:28:13  <glx> maybe because it's easier when use in ternary operator
17:28:33  <frosch123> old c++ cared about tokens, then they allowed closing two < < with >>
17:28:48  <TrueBrain> yeah .. I was about to make similar remarks :P
17:29:07  <TrueBrain> at least it is not Perl, where you can make choices when parsing it :P
17:29:35  <TrueBrain> but okay, in this RPN spaces define the tokens, so it becomes a bit easier .. no doubts about any of that stuff :)
17:30:09  <TrueBrain> hmm, your remark does remind me that "openttd:" is also a bad scope
17:30:12  <TrueBrain> as it can be industry or town too
17:31:57  <frosch123> "openttd:" would be for vars 00-39 ?
17:32:09  <TrueBrain> I didn't actually look at things in that much detail
17:32:13  <TrueBrain> NML doesn't prefix it at all
17:32:17  <TrueBrain> which was mostly what was frustrating me :D
17:32:24  <frosch123> there is a TODO item for nml to add prefixes :)
17:32:51  <TrueBrain> how many times I was like: this name ... who defines it? FIRS? No .. NML? No .. owh, wait, here in FIRS? No .. owh, here in NML? Ah, yes!
17:32:52  <frosch123> currently NML has this PARENT/SELF thing in every switch, which makes combining them difficult
17:33:09  <frosch123> TrueBrain: don't mistake NML with pyNML :p
17:33:14  <TrueBrain> so I mainly wanted to make that a bit more obvious :)
17:33:24  <TrueBrain> no, when I write FIRS I mean pyNML :P
17:33:59  <TrueBrain>  ${cargo[0]}: (${cargo[1]} * production_level * LOAD_PERM(${industry.perm_storage.base_prod_factor}) * LOAD_TEMP(9)) / (16 * 16 * 100);
17:34:02  <TrueBrain> best example of how unclear it becomes
17:34:17  <TrueBrain> ${} is pyNML, production_level is NML, 9 is FIRS
17:34:27  <TrueBrain> it is like .. yeah ... lets not do that plz :)
17:36:52  *** Gustavo6046 has quit IRC
17:40:08  <TrueBrain> see, ideal I think works better
17:40:13  <TrueBrain> I am just not sure I can parse it :D
17:41:50  *** Gustavo6046 has joined #openttd
17:43:28  <TrueBrain> I wonder how FIRS would look .. lets try
17:44:02  <frosch123> s/min/max :p
17:47:02  <TrueBrain> how to differentiate between "industry" variables (so "SELF") and "industry" persistent registers? Suggestions? :)
17:47:30  <frosch123> industry::storage::your_name ?
17:48:18  <frosch123> though i guess, if you also need names for temporaries... you would end up with industry:persistent:your_name again :p
17:52:42  <andythenorth> lol yes the templating breaks my brain
17:52:50  <andythenorth> I really try to avoid looking at it
17:53:46  <andythenorth> it's better than the edition which used CPP variadic macros in nfo-but-via-renum
17:53:54  <andythenorth> that was ..... oof
17:57:49  <TrueBrain> <- that is how FIRS would look in Javascript, give or take mistakes
17:58:33  <TrueBrain> just no clue if that is convertible to GRF ..
17:58:42  <TrueBrain> I know the RPN can be done, or at least, I know for 90% it can
17:59:36  <TrueBrain> main issue is that it is part templating, part pass-through ... :D
18:01:07  <TrueBrain> why btw is there no industry cb without using registers but with telling what cargo ? :)
18:01:15  <TrueBrain> at least, how I read it, I can either only do the first 3 cargoes
18:01:18  <TrueBrain> or use the register version
18:01:23  <TrueBrain> it consumes so much registers :P
18:03:24  <frosch123> the no-register version is pretty useless
18:03:40  <TrueBrain> exactly!
18:03:43  <frosch123> when you deliver 1000 input, and the no-register version consumed 5, you have to call the thing 200 times
18:03:48  <TrueBrain> well, I guess I can use the "again" to only use 1 register ..
18:04:09  <frosch123> only 256 times until ottd says "grf broken"
18:04:37  <glx> ottd says broken on 16bit overflow
18:04:57  <TrueBrain> frosch123: I don't get that one, sorry .. 1000 input ? 1000 different cargoes? Or 1000 units of cargo?
18:05:05  <glx>
18:05:07  <frosch123> 1000 units of cargo
18:05:18  <frosch123> delivering 1000 units within 256 ticks is not unreasonable
18:05:24  <TrueBrain> why does it have to call again if you only consume 5? If you set the "again" flag?
18:06:29  <frosch123> i don't understand your question. sound like "why is there a division operator, if you can just subtract the same amount until you reach zero"
18:07:13  <glx> a delivery can be of any numbers, but the callback has fixed values
18:07:15  <TrueBrain> and I don't understand what you were trying to say :P
18:07:18  <TrueBrain> so stale-mate! :)
18:07:37  <TrueBrain> you say: "you have to call the thing 200 times"
18:07:39  <TrueBrain> I don't get that part
18:07:44  <TrueBrain> that is what I was asking :P
18:07:48  <TrueBrain> a politer way of saying: huh?
18:07:49  <TrueBrain> :)
18:08:06  <glx> because you want to consume the 1000 received items
18:08:11  <frosch123> i mean: a industry-production callback always has to check the amount of cargo delivered, divide/multiply that number with something, and then return the result as output production
18:09:07  <frosch123> i.e. "output = input / 8" vs "while (input > 8) { input -= 8; output ++; }"
18:09:24  <TrueBrain> what does that have to do with the register version or not?
18:09:41  <glx> register version can dynamically adapt the values
18:09:47  <TrueBrain> (the reason I ask is because I start to wonder if I am not missing something here :D)
18:09:51  <frosch123> "output = input / 8" is the register version. the "while" is the non-register version with "again"
18:10:19  <TrueBrain> I don't follow .. I can always just look at incoming_cargo_waiting not?
18:10:25  <TrueBrain> and do input / 8 in both cases?
18:10:34  <TrueBrain> owh, no, okay, I get what you mean
18:10:42  <TrueBrain> I was thinking in a bit longer switch-statements :D
18:11:07  <glx> so instead of repeating 5 input gives 5 output, you can directly do 1000 input gives 1000 output via the registers
18:12:23  <frosch123> the non-register version is only useful for primary industries, which use prod_level
18:12:36  <frosch123> i think there is some flag somewhere to multiple the results of the cb with prod_level
18:12:41  <frosch123> (don't use it :p )
18:14:24  <TrueBrain> outputs[cargo.label] = cargo.multiplier * industry.production_level * * / 16 / 16 / 100;
18:14:32  <TrueBrain> at least it is more clear than the FIRS variant :P
18:15:02  <TrueBrain> it will be a very small subset of Javascript that can be supported .... but can it be done .. hmm
18:15:17  <TrueBrain> will it hurt me somewhere :)
18:16:08  <TrueBrain> signed vs unsigned might be tricky
18:16:35  <frosch123> yeah, NML users noticed :p
18:17:03  <glx> 15bit signed hits very hard
18:17:22  <TrueBrain> normally I would say: just use signed everywhere, but I am sure there are cases that is not optimal
18:18:46  <frosch123> as glx said. the problem is that not everything is 32bit, some things are 15bit, and when using 15bit things in 32bit computations, you have to know whether to sign-extend or not
18:19:12  <TrueBrain> yeah, and the facts that the advanced varact2 has different operators for signed vs unsigned
18:19:15  <TrueBrain> doesn't make it any easier ;)
18:19:27  <TrueBrain> when I use the Javascript approach, I have nothing to base that decision on :)
18:19:29  *** gelignite has quit IRC
18:19:56  <frosch123> ah yes, "grf has no strings" is compatible to "everything is a string" :p
18:20:03  <frosch123> *incompatible
18:20:22  <TrueBrain> the typelessness is more the issue :)
18:21:08  <glx> and procedures can work on full 32bit, but the return value is still 15bit
18:22:33  *** J0anJosep has joined #openttd
18:23:19  <TrueBrain> right ... so .. with the RPN I know I can deliver, and I know the footprint will be small
18:23:29  <TrueBrain> with Javascript .. I am not 100% sure, and I am unsure about the footprint
18:23:42  <TrueBrain> but .. Javascript would be 10000 times easier to write in for 99% of the users
18:26:05  <andythenorth> am I the 1%? :D
18:26:18  <TrueBrain> you writing RPN? That sounds like a disaster :P
18:26:19  <TrueBrain> sorry :)
18:26:26  <andythenorth> RPN looks quite appealing
18:26:34  <andythenorth> I've never done it, but it looks cool
18:26:44  <TrueBrain> it is really easy to mess up
18:27:19  <frosch123> but you can transform RPN into a graph
18:27:24  <frosch123> not so easy with JS
18:27:42  <TrueBrain> why do we want a graph?
18:28:22  <TrueBrain> mostly what I like about RPN, that I can stream it. I only need to read it once, and I have the answer at the end. With Javascript I need to build the AST, do reasoning on it, before I can output the result. Will take more CPU etc etc
18:28:29  <frosch123> i though the idea was: RPN in backend, user draws flow-diagram in frontend, or switches to advanced RPN mode
18:28:52  <TrueBrain> no, the idea is: use a templated variant, or an advanced mode
18:28:54  <TrueBrain> both use RPN :)
18:29:13  <TrueBrain> mainly as I found out that these functions are way too complex for visual languages :P
18:29:52  <TrueBrain> but I guess you are not wrong .. with an RPN it is always possible to experiment with it
18:33:17  <TrueBrain> pro for JS, syntax highlighters already exist :P
18:34:05  <frosch123> not sure you can syntax-highlight in RPN :p
18:34:15  <TrueBrain> me neither :D
18:34:22  <frosch123> but you can do something like bracket-highlight
18:34:44  <frosch123> highlight the child nodes of the operation at the cursor
18:35:29  <frosch123> preview as graph, preview as infix, ... etc
18:35:45  <TrueBrain> infix?
18:36:16  <frosch123> you enter "input 8 / &output =", preview says "output = input / 8"
18:36:52  <TrueBrain> lol, you flipped the left and right of the = operator from what I did
18:36:58  <TrueBrain> and it is one thing I kept wondering about while writing the RPN
18:37:12  <frosch123> oh, my mistake :)
18:37:14  <TrueBrain> it is a funny problem :)
18:37:18  <TrueBrain> it happens everywhere
18:37:26  <TrueBrain> similar with dict lookuips
18:37:29  <TrueBrain> dict key []
18:37:31  <TrueBrain> or key dict []
18:38:09  <TrueBrain> okay, decided to drop the &
18:38:17  <TrueBrain> it is not needed, so don't annoy the user with it
18:38:31  <frosch123> yay \o/
18:39:10  <frosch123> fewer sigils is always better
18:39:21  <TrueBrain> yeah, really trying to minimize the keywords and operators
18:39:22  <TrueBrain> too
18:39:53  <TrueBrain> the one thing that is a problem in both languages .. assigning register slots
18:40:01  <frosch123> <- extend with truegrf at the next bottom :)
18:40:07  <TrueBrain> I need to do loop unrolling I think
18:40:12  <TrueBrain> so I can do it then, I think
18:40:26  <frosch123> do you have a use-case for loops?
18:40:28  <TrueBrain> can I lookup register X, where X is in register Y?
18:40:32  <TrueBrain> (in NewGRF)
18:40:36  <TrueBrain> or do they have to be fixed?
18:41:22  <TrueBrain> FIRS is full of examples of loops
18:41:25  <frosch123> the 60+x parameter can be a register, so you can address persistent storage via register
18:41:28  <TrueBrain> but they are all static loops
18:41:30  <frosch123> but you cannot address regular variables
18:41:36  <TrueBrain> preprocessor loops?
18:41:39  <TrueBrain> give them a name :)
18:41:54  <frosch123> better use functions imo
18:41:57  <TrueBrain> okay, tnx frosch123
18:42:22  <TrueBrain> take as example
18:42:23  <frosch123> subfunction(0, cct:MAIL); subfunction(1, cct:COAL) is plausible to me
18:42:26  <TrueBrain> just no way you can do that without a loop, and without going insane :P
18:42:32  <frosch123> loops are probably work-around for other things
18:42:57  <TrueBrain> I do not really mind the loops; keeps the code somewhat readable
18:43:14  <TrueBrain> I just wonder how far to go in supporting them :P
18:43:33  <TrueBrain> I don't mind if they have to be unrollable by the preprocessor
18:43:37  <TrueBrain> that is a fine requirements for me
18:44:16  <frosch123> haha, i like how the loop is unrolled inside the comment :p
18:44:25  <frosch123> but with a typo
18:47:57  <glx> the second 27 is not a typo
18:49:12  <frosch123> not?
18:49:18  <TrueBrain> it is the length value
18:49:23  <glx> it's the length of the list
18:49:36  <TrueBrain> it is a stack-based language, so after the values of a list, is an entry to indicate the length of the list
18:49:42  <TrueBrain> otherwise you can't search the list on the stack :)
18:52:12  <frosch123> i did not even notice it was a RPN link, i thought it was firs pynml :p
18:52:29  <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
18:52:30  <DorpsGek>   - Update: Translations from eints (by translators)
18:52:39  <TrueBrain> I do not know what to think of this :P
18:54:07  <TrueBrain> <- RPN
18:54:10  <TrueBrain> <- JS
18:54:16  <TrueBrain> I am still ... in doubt :)
18:54:47  <TrueBrain> both about equal in length
18:56:15  <TrueBrain> I guess if I do a proper RPN, the def{ stuff would be like: "def{ .. } name = "
18:56:28  <TrueBrain> but ... that would make implementations rather complex :P
18:57:33  <TrueBrain> I did reduce the keywords to "def{", "loop{", switch and call
18:57:54  <TrueBrain> could change "call" into ()
18:58:21  <TrueBrain> procedure calls accept 1 parameter, not? Hmm .. do I want to allow that ..
18:58:47  <andythenorth> oh dear
18:58:56  * andythenorth now working out how to python template RPN or JS :P
18:59:15  <andythenorth> I already python templated GS :P
19:00:49  <TrueBrain> a procedure also returns a value
19:00:50  <TrueBrain> meh
19:00:56  <TrueBrain> why bother ...
19:02:08  <TrueBrain> ah, procedure variable is what procedure to execute ofc, not the parameter .. good; saves me from adding any of that :D
19:05:23  *** Gustavo6046_ has joined #openttd
19:06:04  <frosch123> since you mentioned it, i keep on thinking that "index dict []" would be easier to implement...
19:06:24  <frosch123> index can be an expression, dict never is
19:06:25  <TrueBrain> implementation wise it really doesn't matter :)
19:06:42  <TrueBrain> [] just looks at stack-1 and stack-2
19:06:43  <TrueBrain> that is it :)
19:06:57  <TrueBrain> or do you mean: easier to write?
19:07:31  <frosch123> no, i mean compiling to grf. va2 also is somewhat a RPN thingie
19:07:39  <frosch123> but you cannot store a dict-address in a grf-register
19:07:53  <frosch123> so when compiling the "dict []" part becomes a single instruction
19:07:53  <TrueBrain> no, I need my own stack anyway while parsing the RPN
19:07:58  <frosch123> while the "index" can be multiple
19:08:19  <TrueBrain> how I plan to create this, is a simple lexer that looks for spaces
19:08:23  <frosch123> anyway, i strongly favour the RPN version.
19:08:33  <TrueBrain> so it first finds, for example "dict", and stores the reference to the dict on the stack
19:08:33  <frosch123> the JS version is reinventing NML :p
19:08:46  <frosch123> it's cooler to have a RPN format, that other things can compile to
19:08:52  <TrueBrain> next it finds "index", stores reference on stack
19:08:59  <TrueBrain> next it finds "[]", which is an operator
19:09:03  <TrueBrain> it looks up stack-1 and stack-2
19:09:07  <TrueBrain> and outputs GRF based on it
19:09:18  <TrueBrain> so from a compiling point-of-view, the order is not relevant, I think
19:10:12  <TrueBrain> if "index" was instead "1 1 +", for example
19:10:15  *** Gustavo6046_ has quit IRC
19:10:22  <TrueBrain> the + would already resolve stack-1 and stack-2 into a single stack entry again
19:10:23  *** Gustavo6046_ has joined #openttd
19:10:54  <TrueBrain> hmm, and that is a valid point for the RPN .. you can make anything compile to the RPN .. it is harder to make other things compile into Javascript
19:11:22  *** Gustavo6046 has quit IRC
19:11:23  <frosch123> "industry.persistent 1 1 + []" would compile to "1 load_const 1 + load_persistent"
19:11:47  <frosch123> "1 1 + industry.persistent  []" is almost the same as "1 load_const 1 + load_persistent"
19:12:16  <TrueBrain> currently I am under the assumption "dicts" actually never go to GRF
19:13:52  <TrueBrain> hmm .. I do would like to support the NewGRF range switches, so you can quickly jump to something based on ranges .. how to call that? "switch"? "[...]" (just some random non-existing operator)? "lookup"?
19:15:08  <frosch123> i think if-cascade is easier in RPN
19:15:43  <TrueBrain> well, a loop-if-cascade in that case
19:15:45  <TrueBrain> for lists
19:15:53  <TrueBrain> as that is the actual case for me currently :D
19:16:15  <frosch123> "default result1 range-start1 range-end1 IFRANGE result2 range-start2 range-end2 IFRANGE"
19:16:51  * Gustavo6046_ double-checks his arsenal of large trouts
19:16:52  <TrueBrain> yeah, I went for something slightly different there ;)
19:17:12  *** Gustavo6046_ has quit IRC
19:17:14  *** Gustavo6046_ has joined #openttd
19:17:15  *** Gustavo6046_ is now known as Gustavo6046
19:17:17  <TrueBrain> mainly what I noticed that "end" is just "start + 1" - 1
19:17:32  <Gustavo6046> fixed nickname
19:18:01  <TrueBrain> so I went with: range1 range2 range3 3 result1 result2 result3 3 value switch
19:18:09  * Gustavo6046 looks menacingly at andythenorth, holding a large trout
19:18:12  <TrueBrain> if value is between [range1, range2), it returns result1
19:22:04  <TrueBrain> but the simple case in RPN is simple: default result1 range1 value > result2 range2 > result3 range3 >
19:24:20  <Gustavo6046> what is that weird language?
19:24:26  <Gustavo6046> it almost looks like a stack based language
19:24:41  <Gustavo6046> like Forth, kind of
19:25:39  <TrueBrain> an RPN, yes
19:26:22  <TrueBrain> right, less keywords is better, so away with "switch" .. just a bit sad frosch123 , that one of the things NewGRF does supply, I won't be using :D
19:29:12  <Gustavo6046> TrueBrain, I was about to ask what RPN stood for but I realized it's reverse Polish notation
19:29:14  <Gustavo6046> :D
19:30:58  <supermop_Home> I still have an rpn HP calculator
19:32:32  <Gustavo6046> what about un-reverse Polish notation?
19:32:37  <Gustavo6046> oh wait, that's just Lisp, isn't it
19:32:51  <TrueBrain> postfix vs prefix languages
19:32:53  <TrueBrain> both exist, yes :)
19:33:49  <Gustavo6046> yeah
19:34:03  <Gustavo6046> C has infix operators but its function calls are kind of like prefix notation
19:37:16  <TrueBrain> updated, now with a header that explain the language a bit more.
19:37:31  <TrueBrain> the only two keywords remaining are "def{" and "loop{"
19:40:14  <TrueBrain> frosch123: similar, is A B > like "A > B" or "B > A" .. depends on how you look at "stack" :D
19:40:38  <Gustavo6046> function pointers are fun to play with
19:40:46  <Gustavo6046> but iirc they get in the way of optimization, right?
19:44:21  <frosch123> TrueBrain: those are like division
19:44:27  <TrueBrain> yeah
19:44:27  <frosch123> so A > B
19:44:36  <TrueBrain> lets keep the order of operations from left to right, yes :)
19:44:53  <TrueBrain> no need to hurt us any more than needed :P
19:45:50  <supermop_Home> andythenorth how do you draw good stonework noise in a way that is reuseable?
19:46:03  <supermop_Home> or do you redo it for each sprite?
19:46:17  <andythenorth> supermop_Home I try not to do it :P
19:48:18  <andythenorth> supermop_Home I would just redraw it each time I think
19:48:33  <supermop_Home> oof
19:48:41  <supermop_Home> my walls don't look good
19:48:51  <supermop_Home> especially lava rock
19:49:07  <Gustavo6046> TrueBrain, masochism comes in degrees, sometimes we're ok hurting ourselves a little bit, but not any more than that
19:49:25  <Gustavo6046> lol
19:49:44  <TrueBrain> still in doubt about [] frosch123  :) Main reason I picked the current order, is becomes of this: "list key [] 1 =" <- if I do it reversed "key list [] 1 =", it is hard for me to see it manipulated "list".
19:49:57  <TrueBrain> but I think it will be one of those things ... lets make a parser first, and see what works and not after :D
19:51:12  <Gustavo6046> TrueBrain, ooh
19:51:23  <Gustavo6046> what if we wrote a simple compiler, that targets that RPN language
19:51:29  *** Wolf01 has joined #openttd
19:51:52  <TrueBrain> another one: true false <condition> or false true <condition> .. :D
19:52:01  <TrueBrain> I went for the first for now
19:52:07  <TrueBrain> feels more natural
19:52:24  <Gustavo6046> yeah
19:54:08  <frosch123> false true <condition> is easier to chain
19:54:14  *** gelignite has joined #openttd
19:54:28  <frosch123> result3 result2 <condition2> result1 <condition1>
19:55:01  <TrueBrain> depends on your frame of reference ;)
19:55:02  <TrueBrain> default result1 range1 value > result2 range2 > result3 range3 >
19:55:03  <frosch123> though for switches you have to keep the switch-value somewhere
19:55:07  <TrueBrain> works fine for me :)
19:58:12  <TrueBrain> hmmm, my if-chain is missing "value" a few times :P
19:58:31  <TrueBrain> but this again is, I guess, reading from left to right or from right to left :D
19:58:33  <TrueBrain> it is really funny :)
19:58:37  <TrueBrain> (to me at least :P)
19:58:44  <TrueBrain> pretty sure there is no right .. just choices :)
19:59:31  <TrueBrain> postfix notation is a bit more trivial in these regards, I guess
19:59:41  <TrueBrain> something like: / 20 10
20:00:01  <TrueBrain> or: > value range1 true false
20:04:12  <TrueBrain> s/postfix/prefix/
20:04:13  <TrueBrain> lol
20:04:28  *** Wolf01 is now known as Guest10406
20:04:30  *** Wolf01 has joined #openttd
20:06:32  *** Guest10406 has quit IRC
20:10:20  <TrueBrain> industry:storage: does have one caveat .. a new version should assign the same variable to the same slot, I guess :P
20:10:27  <TrueBrain> otherwise things might break a bit :)
20:10:58  *** virtualrandomnumber has joined #openttd
20:11:27  *** virtualrandomnumber has quit IRC
20:11:51  <andythenorth> a new grf version?
20:11:58  <andythenorth> with a compatible version bump?
20:12:21  <TrueBrain> FIRS 4.3 and 4.4, those versions, yes
20:13:03  <andythenorth> breaking compatibility with existing savegames is acceptable
20:13:23  <andythenorth> same variable same slot is nice, but variable meanings or valid value ranges etc might change
20:13:23  <frosch123> TrueBrain: the same applies to industry ids, random bits and stuff. i think those "locations" should be defnied when declaring the variable name
20:13:29  <andythenorth> and we have no migration capability
20:13:36  <frosch123> i.e. don't use implicit variable declaration
20:13:46  <andythenorth> the implicit in NML is a complete waste of time
20:13:46  <TrueBrain> you are both right, I think :)
20:13:54  <TrueBrain> I expect with TrueGRF people make a lot of small incremental releases
20:14:08  <TrueBrain> but yeah, I was thinking about explicit variable declaration
20:14:10  <TrueBrain> also for the type
20:14:14  <andythenorth> I try to make small incremental releases with grfs, and preserve compatibility wherever possible
20:14:19  <TrueBrain> that gives two options ..
20:14:22  <andythenorth> but when it's not's not possible
20:14:25  <TrueBrain> I can keep industry:storage: ..
20:14:32  <TrueBrain> or I can assign a local variable to that
20:15:17  <TrueBrain> so at the top you have to define something like: supplied_cycles_remaining_cargo industry:storage 29 list
20:15:26  <frosch123> andythenorth: there is a difference between "you decide when to break stuff", and "a compiler randomly switches things around, so you cannot even reload newgrf in-game, and always have to restart the game"
20:15:27  <TrueBrain> and: total_delivered local int
20:16:02  <andythenorth> frosch123 this is the problem with NML magical implicit IDs :)
20:16:14  <frosch123> yes, they are useless :)
20:16:24  <TrueBrain> so lets not repeat that for this language
20:16:27  <TrueBrain> what are we calling it ..
20:16:28  <TrueBrain> TrueRPN? :P
20:16:55  <frosch123> just RPN: reverse-polish-newgrf
20:17:01  <TrueBrain> :D
20:17:04  <TrueBrain> I like it ;)
20:17:10  <frosch123> the "polish" sets are known for realism, so reversing that
20:17:34  <TrueBrain> do I need u32 and u15
20:17:41  <TrueBrain> or can I just do u32, and convert where needed? :P
20:17:47  <TrueBrain> (well, i32 and i15 are more important, ofc)
20:18:49  <frosch123> u32/i32 are for storage, u15/i15 are function return values
20:19:45  <frosch123> technically you do not need the 32/15, just U and S
20:20:05  <frosch123> "def func() -> signed" "def func() -> unsigned"
20:20:11  <TrueBrain> now for a syntax to define types ... ugh
20:20:19  <TrueBrain> my functions don't return anything
20:20:20  <TrueBrain> much easier :P
20:20:21  <TrueBrain> just use a temp-register
20:20:23  <TrueBrain> is my answer :D
20:20:53  <TrueBrain> "num_supplies_delivered 27 list unsigned industry:storage type"
20:20:57  <frosch123> can you pass the register as output-reference to the function?
20:20:59  <TrueBrain> that feels a bit icky .. but I guess?
20:21:41  <andythenorth>  do we have enough registers? :P
20:22:16  <andythenorth> some are reserved
20:22:35  * andythenorth looks up the troublesome one
20:23:44  <glx> andythenorth: there are 256 useable registers (except in NML)
20:23:46  <andythenorth> 0x100 for vehicles is the one that kills me every time
20:24:07  <andythenorth> it's reused, which has ... interesting results
20:24:33  <glx> but 0x100 is a write only register from newgrf pov
20:24:49  <andythenorth> yup
20:25:18  <glx> with meaning for the caller depending on the callback
20:25:41  <andythenorth> it's dangerous when using random switch and spritelayers
20:25:48  <andythenorth> or rather...that's not possible :P
20:26:23  <andythenorth> I am still worried what happens if TB looks at Iron Horse
20:26:29  <andythenorth> FIRS is really simple
20:26:55  <frosch123> the problem with 100 is just that both you and nml use it :)
20:28:22  <andythenorth> I just stopped using random switch
20:28:27  <andythenorth> it was the easiest thing
20:29:27  <peter1138> Mmm, which path shall we follow today
20:29:45  <andythenorth> the path of righteousness
20:30:14  <peter1138> The path of refusing to believe in callback ID 1 as it's not documented...
20:34:27  <andythenorth> do newgrf docks use it? :)
20:40:48  <peter1138> Didn't get as far as triggers.
20:41:00  <peter1138> Besides it would all be done wrong.
20:42:01  <andythenorth> what isn't :P
20:46:54  <peter1138> Surfing With the Alien.
20:47:07  <peter1138> 80s guitar indulgence that I'd forgotten about somehow...
20:59:33  *** jottyfan has joined #openttd
21:18:19  *** J0anJosep has quit IRC
21:25:01  <Gustavo6046> four cities have many many busses and mail trucks going through them in a star of orders (asym cargodist), but this heavily congests the road stations
21:25:10  <Gustavo6046> what do I do? maybe replacing them with trains is the best course of action?
21:28:20  <FLHerne> Add links to make it more connected than a star?
21:28:44  <Gustavo6046> I mean, look at this
21:28:49  <Gustavo6046> FLHerne, links?
21:28:50  <Gustavo6046> Oh wait
21:28:51  <FLHerne> Trains are good, but you might need a lot of demolition to get into the centre
21:29:05  <Gustavo6046> is it even necessary to have them transport in a star with cargodist?
21:29:08  <Gustavo6046> Surely just a loop is enough, right?
21:29:14  <Gustavo6046> Maybe there are downsides
21:29:18  <FLHerne> No
21:29:25  <supermop_Home> turn off breakdowns
21:29:55  <FLHerne> For cdist, network graphs with bottlenecks are usually bad
21:30:00  <FLHerne> all-to-all is ideal
21:30:12  <FLHerne> somewhere in between is probably most practical
21:32:22  <Gustavo6046> ah
21:32:55  *** jottyfan has quit IRC
21:39:57  <Gustavo6046> those orders are something like ABCBDB
21:40:04  <Gustavo6046> supermop_Home, okay
21:43:51  <Gustavo6046> It's also that bus/truck stations tend to get clogged, especially if a vehicle is running early
21:44:02  <Gustavo6046> I would like them to spend the surplus days by going slower than the max speed or something
21:48:40  *** Webster has joined #openttd
21:50:18  *** Gustavo6046_ has joined #openttd
21:50:26  *** andythenorth has quit IRC
21:50:39  <Gustavo6046_> oops
21:50:58  *** andythenorth has joined #openttd
21:51:15  *** Gustavo6046 is now known as Guest10417
21:51:15  *** Gustavo6046_ is now known as Gustavo6046
21:51:27  <Gustavo6046> oops
21:51:31  <Gustavo6046> supermop_Home, yeah, true
21:52:34  *** gelignite has quit IRC
21:53:36  <supermop_Home>
21:53:58  <supermop_Home> generally road stops in series are not much better than a single one
21:54:23  <supermop_Home> as no vehicle can pass another in the line anyway
21:54:58  <supermop_Home> in parallel at least, a following RV can choose a different stop
21:55:42  <supermop_Home> same with a single stop that the rv could enter from either side
21:55:52  *** Guest10417 has quit IRC
21:56:05  <Gustavo6046> Is there a max length of transfering sequence in a cargodist route?
21:56:09  <Gustavo6046> Like max number of hops between stations
21:56:12  * Gustavo6046 hoppy wallaby
21:56:13  <supermop_Home> in practice, the RV pathfinder seems to cache too much of the vehicles route
21:56:27  <Gustavo6046> supermop_Home, but yeah, I did realize parallel is often better than serial
21:56:35  <Gustavo6046> take that silicon valley :P
21:56:36  <supermop_Home> so a late running vehicle hugs the on time one in front of it
21:56:44  <Gustavo6046> ah
21:56:46  <supermop_Home> and follows it into the same stop
21:56:55  <Gustavo6046> that sounds sweet! they're friends!
21:57:47  <andythenorth> I think someone tried a full mesh for cdist
21:57:52  <supermop_Home> as at the time it choses a route into the closest stop, it doesn't know it will be occupied
21:57:52  <andythenorth> might have been jgr :P
21:58:17  <supermop_Home> drive-in stops are better for this in therory
21:58:21  <supermop_Home> theory
21:58:44  <supermop_Home> as the late RV can leave before the on time one
21:58:58  <supermop_Home> but 1) you can't use articulated RVs
22:00:11  <Gustavo6046> ahh
22:00:14  <Gustavo6046> oooh right
22:00:16  <supermop_Home> and 2) the time it takes RVs to do the movement in and out of the stop is a huge bottleneck that erases most of the late vehicle's chance to catch up
22:00:23  <Gustavo6046> because in a drive-through, they have to exit in the same order they enter
22:00:25  <Gustavo6046> right?
22:00:28  <supermop_Home> yes
22:00:39  <Gustavo6046> what if it's a drive-through followed by a drive-in? o.o
22:00:43  <Gustavo6046> lol
22:01:19  <supermop_Home> the RVs stop at the drive through then pointlessly turnaround in the drive-in
22:01:49  <Gustavo6046> oh
22:01:57  <Gustavo6046> but don't they usually stop at the end, i.e. at the drive-in?
22:02:16  <supermop_Home> not if they just stopped at the drive through on the way there
22:02:21  <Gustavo6046> ahh
22:02:24  <Gustavo6046> hmm
22:03:07  <Gustavo6046> what if there was a stop type that was a weird Frankenstein, but one way only? a single through lane (you can pick the direction), because the space where the other lane would be is instead parking spots
22:03:27  <Gustavo6046> so like an expandable drive-in
22:03:31  *** WormnestAndroid has quit IRC
22:03:37  <Gustavo6046> you could link two lines of those in opposite directions, kinda like two lanes of one-way railway
22:03:37  <supermop_Home> if you have one chronically late RV that's just following the one in front with no chance to pass, its best just to manually stop the on-time RV briefly to let the other pass
22:03:47  *** WormnestAndroid has joined #openttd
22:03:57  <supermop_Home> Gustavo6046 that's been discussed and eagerly awaited for years
22:04:06  <Gustavo6046> :O
22:04:08  <Gustavo6046> I'm not the first one?
22:04:13  <Gustavo6046> (It sounds balanced because of the one-way thing)
22:04:23  <supermop_Home> as part of general new road stop and/or airport paradigm
22:04:28  <Gustavo6046> yayy I think alike to the awesome openttd folks :DDDD
22:04:33  <Gustavo6046> \o/
22:04:47  <Gustavo6046> that does sound like something that would go best in a NewGRF, though
22:05:04  <Gustavo6046> maybe that kind of thing could be API-ified so it isn't as hardcoded? idk
22:05:29  <supermop_Home> it would have to be a patch, because the statemachines for vehicle movement in those is hardcoded
22:06:18  <supermop_Home> this is also why airports that use different runway layouts than standard require a patch
22:06:56  <Gustavo6046> Ah :(
22:07:05  <Gustavo6046> how about a patch that makes them patchable by newgrfs or something
22:07:07  <Gustavo6046> patchception lol
22:07:14  <supermop_Home> the idea is to instead provide some means to make new movement patterns by other means rather than hardcoded
22:07:20  <supermop_Home> yes,
22:07:45  <supermop_Home> someone called rich did some work on it about 10 years ago
22:07:54  <supermop_Home> but it kind of petered out
22:09:22  <Gustavo6046> bitrot?
22:11:34  <Gustavo6046> petered out like in it didn't catch up with openttd development?
22:12:15  <andythenorth> there was a disagreement
22:14:35  *** nielsm has quit IRC
22:17:15  <supermop_Home> Gustavo6046 with trains you can do this at the end of the line that lets a late train pass an early one easily:
22:17:16  <supermop_Home>
22:17:33  <Gustavo6046> ah
22:17:38  <supermop_Home> especially if the there is amble lay-up time
22:18:44  <supermop_Home> i often schedule trains to wait the time between train on the schedule plus a few days at end of line
22:19:15  <supermop_Home> that way train 1 doesn't try to leave until train 2 has arrived and cleared the jenction
22:19:18  <Gustavo6046> ohhh, so if one is coming and another is leaving at the same time, they don't have to wait for one to go through the intersection between station lanes and the two-way rails each time?
22:19:19  <supermop_Home> junction
22:19:56  <Gustavo6046> my layout is often like this, basically a roundabout
22:19:57  <supermop_Home> basically this is what the subway here does at most end of line terminals
22:20:19  <Gustavo6046> hmm, what if a train wants to leave from the depot into the railway?
22:21:09  <supermop_Home> that's pretty uncommon - that depot is just for buying trains and starting them off
22:21:35  *** _aD has joined #openttd
22:22:02  <supermop_Home> if i wanted to use it for servicing or replacing trains i'd probably design it differently
22:22:30  <Gustavo6046> oh okay
22:22:33  <Gustavo6046> how do you maintain the trains?
22:22:38  <Gustavo6046> or service them, I think that's what maintenance refers to
22:22:43  <Gustavo6046> oh waitttt
22:22:44  <Gustavo6046> you disable breakdowdns
22:22:46  <Gustavo6046> breakdowns*
22:22:53  <Gustavo6046> I forgot :D
22:23:55  <_aD> hey now, where's the challenge, when running 10-unit trains, without servicing? :-D
22:25:21  <Gustavo6046> so, my roundabout station junction design is probably dumb and crapo
22:25:37  <_aD> but is it beautiful?
22:27:52  <Gustavo6046> I don't know, I'll let you be the judge of that. I linked a screenshot earlier
22:28:57  <supermop_Home>
22:29:21  <supermop_Home> this lets trains replace or service if needed and is still pretty functional
22:29:47  <supermop_Home> you can of course add mor platforms or double the line coming into it
22:30:35  <supermop_Home> again, I've scheduled the trains to wait at the station loading until the next one arrives, but you don't really need to
22:32:36  <Gustavo6046> ah
22:32:45  <_aD> oh that's much more svelte than mine :-\
22:33:02  <Gustavo6046> it's so simple yet so elegant
22:33:15  <Gustavo6046> I generally avoid putting depots behind stations, not sure why
22:33:36  <Gustavo6046> I guess so I can extend the station length if needed?
22:37:32  <_aD>
22:38:02  <_aD> pls excuse the non-path signals, don't taze me bro.
22:38:10  <supermop_Home> i generally like to keep my stations at mines, farms etc as close as possible to simple sidings
22:38:42  <_aD> Service before loading.
22:38:57  <_aD> These were for long-distance journeys...them trains were haulin' for a while.
22:42:35  *** sla_ro|master has quit IRC
22:44:20  <DorpsGek> [OpenTTD/team] frosch123 commented on issue #282: [nb_NO] Translator access request
22:44:54  <DorpsGek> [OpenTTD/team] frosch123 commented on issue #283: [nn_NO] Translator access request
22:50:39  *** frosch123 has quit IRC
23:04:12  *** Gustavo6046 has quit IRC
23:14:06  *** andythenorth has quit IRC
23:27:49  *** Gustavo6046 has joined #openttd
23:30:32  *** Wolf01 has quit IRC
23:36:24  <TrueBrain> <- added type definition .. now tomorrow we try to actually implement this :P

Powered by YARRSTE version: svn-trunk