Back to Home / #openttd / 2018 / 08 / Prev Day | Next Day
#openttd IRC Logs for 2018-08-12

---Logopened Sun Aug 12 00:00:02 2018
00:31<k-man>how do you increase the size of an airport?
00:31<k-man>can i just destroy and build over the top? will that void all orders of aircraft going to that airport?
01:34<Supercheese>As long as you do it very quicky, or while paused, it should maintain all your aircraft orders
01:44-!-Alberth [~alberth@00015f9e.user.oftc.net] has joined #openttd
01:44-!-mode/#openttd [+o Alberth] by ChanServ
01:44-!-Alberth is "purple" on @#openttd
01:44<@Alberth>moin
01:45<k-man>i saw a tip online where you add a train station or bus depot to the airport, then you can destroy the airport and rebuild
01:49<Supercheese>that works too
01:54<@Alberth>if you're quick enough in destroy & rebuild, the name is kept
01:55<@Alberth>shouldn't have any pesky AIs around that plop down their airport as soon as you destroy yours :p
01:58<k-man>yeah
01:58<k-man>ok
01:58<k-man>i don't have any AIs
01:59<k-man>i let my son play on my game for a bit
01:59<k-man>random airports popped up all over the place :)
02:03<k-man>what is the rule for maximising speed around corners?
02:03<k-man>of trains that is
02:21<@Alberth>depends on the train-type
02:22<@Alberth>but no 2x 45 degrees directly after each other is a first big step :)
02:23<@Alberth>but to some extent it's not that important
02:24<@Alberth>near stations you usually have the least amount of space, but trains don't go fast there either
02:24<@Alberth>on open field trains go faster, but you also have plenty of room to smooth out the edges
02:25<@Alberth>ie 2x45 degrees is fine near a station, as a train isn't traveling > 80-something km/h there
02:31-!-eirc [5e47f48c@107.161.19.109] has quit [Remote host closed the connection]
02:38-!-nielsm [~nielsm@62-243-118-198-cable.dk.customer.tdc.net] has joined #openttd
02:38-!-nielsm is "Niels Martin Hansen" on #openttd #tycoon
02:42<k-man>ah ok
02:42-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has quit [Quit: snail_UES_]
02:42<k-man>i seem to recall there was a way to place 2 platforms not adjacent to each other, but so they are the same station
02:43<k-man>is there a way to do that?
02:43-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has joined #openttd
02:43-!-andythenorth is "andythenorth" on #openttd
02:53<@Alberth>place station, but hold control while placing it, you'll get a window to select what you want
02:54<@Alberth>moin andy
02:54<andythenorth>o/
02:57<k-man>thanks Alberth
03:04*andythenorth testing nml for 16 cargos in / 16 out
03:07<nielsm>yay
03:08<andythenorth>tip of the branch gives me a python syntax error in make test
03:08<nielsm>heh
03:08<andythenorth>I'm working through the other commits one hash at a time, testing
03:08<nielsm>I did warn you that I didn't even attempt to run this :)
03:08<andythenorth>you did
03:11-!-Supercheese [~Superchee@cpe-98-146-230-183.natnow.res.rr.com] has quit [Remote host closed the connection]
03:11-!-Supercheese [~Superchee@cpe-98-146-230-183.natnow.res.rr.com] has joined #openttd
03:11-!-Supercheese is "Supercheese" on #openttd
03:14<andythenorth>hmm
03:15<andythenorth>afaict this looks right https://paste.openttdcoop.org/plp8lyhxn/z2insl/raw
03:15<andythenorth>but the result in-game is that industry produces only Acid cargo
03:16<andythenorth>no acceptance, and is missing industry window text
03:16<nielsm>what does it produce as NFO output?
03:18<andythenorth>this may take some time :)
03:18<andythenorth>107k lines :)
03:18<andythenorth>of nfo
03:18<nielsm>ouch
03:18<andythenorth>I think I need to patch FIRS compile to just do one industry nfo
03:19<andythenorth>oh I already have that :)
03:19<nielsm>think you can maybe try producing something simple like my test grf? https://0x0.st/sJia.txt
03:20<andythenorth>just 13k lines now
03:20<andythenorth>so prop 26 I need to find
03:20<nielsm>but it's only the action0's that are interesting
03:22*andythenorth lost in the varaction 2s
03:22<andythenorth>glad I didn't write those in nfo
03:23<andythenorth>https://paste.openttdcoop.org/pyvejhpar/fbwaov/raw
03:24<nielsm>what's those \2rst escapes?
03:25<nielsm>oh wait it's an action 2, so something to indicate operators I guess
03:27<andythenorth>afaict prop 26 should be in this sprite https://paste.openttdcoop.org/pny2wqh66/pn3wbb/raw
03:28<andythenorth>hmm prop 26 is in there
03:28<andythenorth>25 isn't
03:28<@Alberth>nielsm: https://newgrf-specs.tt-wiki.net/wiki/VarAction2Advanced
03:28-!-Progman [~progman@p57A2B2E8.dip0.t-ipconnect.de] has joined #openttd
03:28-!-Progman is "Peter Henschel" on #openttdcoop.dev #openttdcoop #openttd
03:28<andythenorth>other sprites have prop 11 and 10 where 26 is in this sprite, which is encouraging
03:29<nielsm>maybe my nml implementation is resolving the cargoids wrong
03:31<andythenorth>ctt_list?
03:31<nielsm>ah that's an existing function I re-used that seemed to be doing the right thing
03:31<nielsm>maybe it isn't
03:32<andythenorth>can't remember if it's industries that use absolute cargo IDs, not the CTT
03:32<andythenorth>something does, or used to
03:33<andythenorth>no CTT values should work https://newgrf-specs.tt-wiki.net/wiki/Action0/Industries#Production_cargo_types_.2810.29
03:34<andythenorth>oh
03:34*andythenorth might have an answer, testing
03:38<andythenorth>nielsm: my local checkout of your ottd PR was stale :)
03:38<nielsm>oh
03:38<nielsm>:D
03:38<andythenorth>but at least I learnt how to read nfo again :P
03:39<@Alberth>ignore most numbers? :)
03:39<andythenorth>yes
03:40<andythenorth>look for patterns of prop number + feature number
03:41<andythenorth>https://github.com/nielsmh/nml/commit/869e0ece0785a2d20c278dd77353e11aa1192fbb is good
03:41<andythenorth>and https://github.com/nielsmh/nml/commit/cb30dcf1f1da664a6c36a187d5d7ad44c0c02b2e
03:41<andythenorth>I'll move on to the others
03:41<andythenorth>we need some kind of online review tool :P
03:43<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on pull request #6881: Fix: Script/AI construction of rail track and waypoints https://github.com/OpenTTD/OpenTTD/pull/6881#issuecomment-412325053
03:45<DorpsGek_II>[OpenTTD/OpenTTD] JGRennison merged pull request #6881: Fix: Script/AI construction of rail track and waypoints https://github.com/OpenTTD/OpenTTD/pull/6881
03:45<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain pushed 1 commits to master:
03:45<DorpsGek_II> - Fix bf8d7df: Script/AI construction of rail track and waypoints (#6881) (by JGRennison)
03:45<DorpsGek_II>https://github.com/OpenTTD/OpenTTD/commit/d839526365e6
03:54<andythenorth>https://github.com/nielsmh/nml/commit/9f31ca6f9a416fd3fc4ffa3b728f51ab1b2d67d7 seems to fail
03:54<andythenorth>I'm checking it's not EBKAC
03:55<andythenorth>https://paste.openttdcoop.org/pl05g9k8b/e89fco/raw
03:56<andythenorth>curious about what ByteListProp is
03:56<nielsm>it generates a property value that's a length byte followed by that many byte-sized items
03:57-!-eirc [5e47f48c@107.161.19.53] has joined #openttd
03:57-!-eirc is "[https://kiwiirc.com] Development release" on #openttd
03:57<nielsm>renamed CargoListProp because that class didn't have anything to do specifically with cargo types
03:57<andythenorth>ok
03:57<andythenorth>so the input is prod_multiplier: [9, 7, 20, 14];
03:58<andythenorth>line that reports failure is
03:58<andythenorth> if -0x80 <= value < 0 : value += 0x100
03:58<nielsm>huh
03:58<andythenorth>which looks like it's handling 80+ vars at my first guess
04:00<andythenorth>ah do I have the spec wrong?
04:01<andythenorth>what's the expected format for prod_multiplier?
04:02<nielsm>the output is a byte counting number of values, followed by byte values for each output cargo slot
04:03<andythenorth>so my input is correct?
04:03<andythenorth>ok
04:03<nielsm>I think so
04:04<andythenorth>this is where we hit the limit of 'andythenorth can't use pdb'
04:04<andythenorth>so I have to put prints in
04:05<andythenorth>oh it's type comparison error no?
04:05<andythenorth>Error: (TypeError) "unorderable types: int() <= ConstantNumeric()".
04:06<andythenorth>what does value.values[i].reduce_constant() do? o_O
04:06<andythenorth>let's see
04:07<@Alberth>simplifying the expression
04:07<@Alberth>or constant, probably
04:08<@Alberth>you have to wrap the "int" into an expression object
04:09<@Alberth>not sure if you have a comparison then :)
04:09<nielsm>or extract the resulting value from the reduced expression
04:09<andythenorth>firs.nml, if anyone wants to play along at home https://paste.openttdcoop.org/poxrildbu/tigpn4/raw
04:09<andythenorth>I am currently at rev. https://github.com/nielsmh/nml/commit/9f31ca6f9a416fd3fc4ffa3b728f51ab1b2d67d7#diff-d1a886cb2dde0af9578bb803357ee81bR754
04:11-!-Supercheese [~Superchee@cpe-98-146-230-183.natnow.res.rr.com] has quit [Quit: Valete omnes]
04:18<andythenorth>[ByteListProp(0x27, [[i.reduce_constant().value for i in value.values]])] appears to work
04:18<andythenorth>but I am cargo-culting from other places
04:18<andythenorth>it's _probably_ wrong
04:18<nielsm>same as me!
04:18<andythenorth>the results are as expected
04:19<andythenorth>Alberth o_O ? https://paste.openttdcoop.org/pavp9yoku/gcgcpe/raw
04:20<nielsm>bbl
04:20<andythenorth>k
04:20<andythenorth>I'm not sure reduce_constant() is even needed here
04:21<andythenorth>hmm, fails without it
04:22<@Alberth>too many [ ] ?
04:23<@Alberth>maybe not
04:23<andythenorth>seems not
04:24<andythenorth>it's lists in lists :P
04:24<@Alberth>I don't think nml make a clean distinction between input expressions, and reduced expressions
04:24<@Alberth>so depending on where stuff comes from it may or may not fail
04:25<@Alberth>hmm, wondering what would happen if you make a second set of classes for normalized expressions
04:25<@Alberth>would solve the "double reduce" problem at least
04:26<andythenorth>worth doing?
04:26<@Alberth>if we keep nml, likely worth a try
04:28<@Alberth>problem is that I don't know if any code tries to sneakily change expressions without making a new object
04:31<andythenorth>we have....some regression tests :P
04:32<andythenorth>it's probably TMWFTLB for current nml
04:41-!-frosch123 [~frosch@00013ce7.user.oftc.net] has joined #openttd
04:41-!-frosch123 is "frosch" on #openttdcoop.devzone +#openttd.dev #openttd
04:42<andythenorth>quak and stuff
04:42<frosch123>moi
04:45<@Alberth>moo
05:01<andythenorth>so is this expecting an array of pairs? https://github.com/nielsmh/nml/commit/10b3a269bd0d1b235631ddfe848f7b904c2c77c5
05:02<andythenorth>it's for prop 28 https://github.com/OpenTTD/OpenTTD/pull/6867#issuecomment-408407249
05:02<andythenorth>seems it could have 256 possible entries :o
05:10<nielsm>btw I also put all the docs for the new props in the initial comment on the PR :)
05:10<nielsm>that's the maintained documentation right now
05:11<nielsm>and yes prop 28 is stupid and annoying because it can take such a large number of values
05:12<nielsm>I'm not sure if the format should be kept in either GRF or NML
05:12-!-juzza1 [~juzza1@0001bead.user.oftc.net] has quit [Quit: leaving]
05:13<nielsm>the GRF format could be changed to a 2D array and so could the NML format
05:15<andythenorth>do we need 16*16 multipliers?
05:15<andythenorth>they can use cb for that
05:16<nielsm>you mean scrapping prop 28 entirely?
05:16<nielsm>that would close off part of the core industry type definition to GRF which I'd argue is conceptually wrong
05:18-!-juzza1 [~juzza1@0001bead.user.oftc.net] has joined #openttd
05:18-!-juzza1 is "juzza1" on #openttdcoop.devzone #openttd
05:19<andythenorth>maybe
05:19<andythenorth>it just seems very faceted
05:20<nielsm>part of the reason is also that I don't understand how production callback actually works :D
05:23<andythenorth>oh it just returns the amount to produce :)
05:23<andythenorth>it looks complex, but it literally returns 'produce n' for each cargo
05:25<nielsm>but yes in the core code, input_multipliers is a 16x16 matrix (originally 3x2), in prop 28 I specify it in a sparse format where you only provide the non-zero values
05:25<andythenorth>I'm only querying it because FIRS doesn't use it, so I have to write a test case from scratch
05:25<andythenorth>and test it :P
05:25<nielsm>weak!
05:25<nielsm>:)
05:25<andythenorth>you've tested prop 28 works?
05:26<nielsm>yes
05:26<nielsm>not in NML but it does in GRF
05:26<nielsm>(I use it in my own test file)
05:26<andythenorth>I saw :)
05:26<andythenorth>ok I'll make test case for that
05:26<andythenorth>meanwhile, https://paste.openttdcoop.org/pavp9yoku/gcgcpe/raw
05:27<andythenorth>is the other fix
05:29<nielsm>I have two birds on my head
05:29<nielsm>one of their tails is partially blocking my view
05:31<@Alberth>turn your head :p
05:36<andythenorth>go north
05:36<andythenorth>inventory
05:37<nielsm>movement is not currently possible
05:37<nielsm>you have one bird dropping in your hair
05:37<nielsm>you hear beaks grinding
05:48-!-Wormnest [~Wormnest@s5596abd2.adsl.online.nl] has joined #openttd
05:48-!-Wormnest is "Wormnest" on #openttd
05:53<andythenorth> multipliers = multipliers + [(in_slot.value, out_slot.value, int(mul.value * 256)]
05:53<andythenorth>invalid syntax :)
05:53*andythenorth looks
05:53<andythenorth>parentheses
05:53<andythenorth>but where should the missing one be?
05:56<andythenorth>should that line be multipliers.extend?
05:56<k-man>how do you replace vehicles from electric trains to monorail?
05:56<andythenorth>seems like list concatenation...
05:56<k-man>the monorail train isn't listed in the replace window
05:58<k-man>oh, apparently its not easy? you have to sell the old trains and buy new ones?
05:59<andythenorth>syntax error is here https://github.com/nielsmh/nml/commit/10b3a269bd0d1b235631ddfe848f7b904c2c77c5#diff-d1a886cb2dde0af9578bb803357ee81bR832
06:10<nielsm>just before the end ]
06:10<nielsm>another paren there
06:11<@Alberth>not the "int" ? * 256 seems to need an integer :)
06:12<nielsm>multipliers = multipliers + [(in_slot.value, out_slot.value, int(mul.value * 256))]
06:14<@Alberth>k-man: yep, most fun way to do that is to make new routes with the monorail, as mass-replace is both boring and not taking opportunities that have been made possible by the faster train type
06:14<@Alberth>alternatively, stop playing before you hit the forced railtype change, or us a newgrf that is not forcing you into it
06:14<@Alberth>*use
06:15<nielsm>the less-friction way is to play with "universal rail" newgrf which will let you build a depot that can build any kind of train
06:15<nielsm>or even just run monorail trains on the same rail as conventional
06:15<nielsm>arguably that's cheating
06:16<@Alberth>I think the biggest issue is that you are denying yourself the chance to have a fresh look at your network, and re-organize it for the faster trains :)
06:24<andythenorth>hmm
06:26<andythenorth>input_multiplier: [[0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0], [0, 0]];
06:26<andythenorth>is that the correct format?
06:26<nielsm>no
06:26<andythenorth>ok
06:27<nielsm>the format I'm expecting is kinda bad
06:28<andythenorth>I'm trying to reverse engineer it from the nml code :)
06:28<nielsm>but basically: [0, 1, 5, 1, 2, 2, 1, 3, 1]
06:28-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
06:28-!-Wolf01 is "Wolf01" on #openttd
06:28<nielsm>that's three triplets of values
06:28<andythenorth>it's B B W
06:28<andythenorth>?
06:28<Wolf01>o/
06:28<nielsm>yes
06:28<andythenorth>ow that format hurts :)
06:28<nielsm>input cargo slot, output cargo slot, multiplier
06:29<nielsm>feel free to change it entirely
06:29<andythenorth>oof
06:29<nielsm>(in NML)
06:29<andythenorth>I have no idea what's better :)
06:29<andythenorth>I just would never use this property :)
06:30<andythenorth>no eddi?
06:30<nielsm>[ [0, 1, 5], [1, 2, 2], [1, 3, 1] ]
06:30<nielsm>could be one option
06:30<andythenorth>it's easier to read at least
06:30<nielsm>[ [0, 5], [0, 0, 2, 1] ]
06:30<nielsm>could be another
06:31<k-man>cool, thanks for the tips guys
06:32<@Alberth>just use triplets
06:32<@Alberth>industry tiles are just as silly :)
06:33<andythenorth>so that needs the patch changed? :)
06:34<nielsm>well you can change the NML format without changing the GRF format, and vice versa, NML just needs to transform it appropriately
06:35<@Alberth>I am not so sure it's going to be sparse, if you want to produce something at all outputs no matter what cargo you insert (ie standard industry behavior), it's not sparse at all
06:37<nielsm>yeah
06:38<nielsm>should probably change prop 28 format in GRF too
06:38<+michi_cc>I don't think the 16-in-16-out industry is going to be the standard industry (and if it is, the NewGRF authors deserves it :)
06:38<nielsm>to maybe "B<n> B<m> n*m*W"
06:39<nielsm>num_inputs, num_outputs, num_inputs * [num_outputs * multiplier]
06:40<andythenorth>varying the output per input is bonkers
06:40<andythenorth>but that ship apparently sailed a long time ago
06:48-!-Heiki [hp@taimen.sr2.fi] has quit [Ping timeout: 480 seconds]
06:50<@Alberth>andy: that would mean each row is the same?
06:52<@Alberth>you could split it, have a "reset + initial value" for all entries, and a "add these numbers to the current"
06:53<@Alberth>or are properties supposed to be written in a single sprite?
06:55<andythenorth>dunno :)
06:55<andythenorth>I would have thought so though
06:56<andythenorth>anything to make it more sane heads toward the production cb which already solves this :P
06:56<andythenorth>this new prop 28 is just to keep parity with residual bits of spec
06:57<andythenorth>in case you really need to design a newgrf where 8t coal gives 2t steel and 6t goods, but 8t iron ore gives 6t steel and 2t goods
06:57<andythenorth>repeat for 16 cargos
06:57<andythenorth>and you're not capable of using production cb
06:57<andythenorth>sometimes I really hate backwards compatibility :(
06:58<andythenorth>dragging along dead bits of spec, and all the associated code
07:00<andythenorth>:)
07:03<Wolf01><andythenorth> sometimes I really hate backwards compatibility :( <- don't
07:03<Wolf01>If people want new features move on
07:04<andythenorth>don't do the compatibility?
07:04<andythenorth>or don't hate it?
07:04<Wolf01>Don't do
07:06-!-Maraxus [~chatzilla@87-56-231-247-dynamic.dk.customer.tdc.net] has joined #openttd
07:06-!-Maraxus is "Maraxus" on #openttd #factoriocoop @#openttdcoop.stable @#openttdcoop
07:06<Wolf01>Look at minecraft, there are people playing 1.4.7 because it was the last one with a particular spec which allowed to do "easily" some stuff, now we are at 1.13. If people want a specific grf they could play 1.8 until the end of time
07:06<andythenorth>not doing prop 28 doesn't break old grfs
07:06<andythenorth>it just doesn't update an old way of doing things
07:07<andythenorth>this is a new property and format introduced to support a legacy spec
07:07<k-man>are there examples of building junctions where one of the track pairs is at 45%?
07:14<andythenorth>frosch123: do you think it would be acceptable to drop prop 28? https://github.com/OpenTTD/OpenTTD/pull/6867#issuecomment-408407249
07:15<frosch123>andythenorth: i did not invent it :p
07:23<@Alberth>k-man, one standard junction is to add 2-tile long bridge to let the 45 degrees track under it
07:26<nielsm>k-man have you considered this option? https://0x0.st/sJ-p.png
07:26<nielsm>:)
07:27<nielsm>(obviously won't be efficient with heavy traffic, but for low traffic it's unbeatable)
07:32<k-man>hmm, thanks
07:33<k-man>i sent all my trains to depot
07:33<k-man>is there some way to start them all again?
07:33<k-man>without 100s of clicks
07:33<nielsm>the master vehicle list should let you
07:34<nielsm>each depot also has a "start all vehicles" button
07:34<k-man>ah thanks
07:58-!-Compu [~Compu@0001feeb.user.oftc.net] has joined #openttd
07:58-!-Compu is "Compu" on #help #openttd #openttdcoop.stable #openttdcoop #/r/openttd
07:58-!-Compu [~Compu@0001feeb.user.oftc.net] has quit [Remote host closed the connection]
08:47-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has quit [Quit: andythenorth]
08:55-!-Maraxus [~chatzilla@87-56-231-247-dynamic.dk.customer.tdc.net] has quit [Quit: ChatZilla 0.9.93 [Firefox 56.0.2/20171024165158]]
09:22-!-ToBeFree [~tobefree@00019d36.user.oftc.net] has joined #openttd
09:22-!-ToBeFree is "Tobias "ToBeFree" Frei" on #debian #openttd @#freiwuppertal #https-everywhere #oolite-dev @#linux #oolite #oolite-ger
09:23-!-ToBeFree [~tobefree@00019d36.user.oftc.net] has quit [Remote host closed the connection]
10:08*LordAro wonders if it's worth turning off +R now
10:10<Wolf01>Why? I fixed my script now :>
10:11<LordAro>:p
10:11<frosch123>@mode -R
10:11-!-mode/#openttd [-R] by DorpsGek
10:11<frosch123>let's try 5 minutes :p
10:15-!-AndroUser2 [~androirc@2605:b100:f24f:b964:d4e8:5f6:11ef:7263] has joined #openttd
10:15-!-AndroUser2 is "Android IRC Client" on #openttd
10:22-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has joined #openttd
10:22-!-andythenorth is "andythenorth" on #openttd
10:22<andythenorth>so we're all on the fence about prop 28? :P
10:22<andythenorth>I have to just re-implement it in nml as a list of triples?
10:23<frosch123>do you use those properties in firs?
10:23<frosch123>or is it all production callback?
10:23<andythenorth>production cb of course :)
10:24<frosch123>how likely is it that some newgrf would want to use many input/output, but not use complex production mechanics?
10:25<andythenorth>no idea :)
10:25<andythenorth>how likely is it that I want to rewrite the nmlc code for this? o_O
10:25<andythenorth>0/1
10:26<+michi_cc>Is the problem with the prop itself or just with the NML syntax?
10:26<frosch123>just the nml syntax :)
10:26<frosch123>you can't implement it with just c&p
10:26<frosch123>apparently
10:27<+michi_cc>m4nfo is obviously superior then :p
10:27-!-APTX_ [~APTX@2001:470:71:71d:defe:7ff:fee1:3d5d] has joined #openttd
10:27-!-APTX_ is "APTX" on #kernelnewbies #openttd
10:27<frosch123>actually, it's not the syntax that is complicated. just noone knows the nml implementation :p
10:28<frosch123>m4 is the most advanced preprocessor
10:29<andythenorth>I'll just rewrite this for a list of triples https://github.com/nielsmh/nml/commit/10b3a269bd0d1b235631ddfe848f7b904c2c77c5#diff-d1a886cb2dde0af9578bb803357ee81bR832
10:29<andythenorth>probably wrong :P
10:34<andythenorth>eh how about 'nml doesn't implement this prop' :)
10:35<@Alberth>I don't understand why it needs a new triplet format, just make an extended version of large number of multipliiers
10:36<@Alberth>it may be based on the idea of sparse array, but I don't think it will be sparse
10:36<@Alberth>unless you get specific outputs for specific inputs
10:36<@Alberth>but you can also express that in the list of multipliers
10:37<@Alberth>given that few people will use it, reduce the amount of work?
10:38<andythenorth>maybe I just leave the current format, and fix the bug? o_O
10:39<@Alberth>generate an extended version isn't that mucjh work is it?
10:39<@Alberth>*much
10:40-!-HeyCitizen [~HeyCitize@sttrpq3809w-lp130-05-69-156-204-156.dsl.bell.ca] has joined #openttd
10:40-!-HeyCitizen is "Got ZNC?" on #openttd
10:40<andythenorth>extended in what way? Just more named props?
10:40<@Alberth>3x2 does a row of output multipliers for each input
10:40<@Alberth>so if I have 5x4, have 5 rows of 4 numbers
10:41<@Alberth>and since that won't fit in the old property, add a new property, preferably with a 5 and 4 in there too
10:42<@Alberth>so you keep the old solution for those who want it with little effort, as far as I can see
10:42<@Alberth>maybe the 5 and 4 are implied elsewhere already
10:43-!-HeyCitizen_ [~HeyCitize@ip-45-41-54-196.montreal.ca.northamericancoax.com] has joined #openttd
10:43-!-HeyCitizen_ is "Got ZNC?" on #openttd
10:44<@Alberth>^ frosch123
10:44<@Alberth>same users different ip
10:45<andythenorth>the (in the patch already) solution with a different prop name seems to fragment the API a bit
10:46<andythenorth>it will make the docs more complicated
10:46<andythenorth>'use this prop for more than 3 cargos, otherwise use these 3 props'
10:46<@Alberth>I'd use the new one for all cases
10:46<andythenorth>yeah, that makes more sense
10:46<andythenorth>deprecate the old one
10:47<andythenorth>but I think that will upset authors, as the new format is hard
10:47<andythenorth>so I'd better figure out the triples :P
10:48<@Alberth>I think grf-format should allow the new one for any number of input and output
10:48-!-HeyCitizen [~HeyCitize@sttrpq3809w-lp130-05-69-156-204-156.dsl.bell.ca] has quit [Ping timeout: 480 seconds]
10:49<@Alberth>nml may want to generate the old property if possible to be backwards compatible with older openttds
10:52<@Alberth>is "mul.value" a floating point value? otherwise * 256 looks weird
10:53<andythenorth>Error: (TypeError) "'float' object cannot be interpreted as an integer".
10:53<andythenorth>^ current error :P
10:56<@Alberth>I'd need a line with that :)
10:57<@Alberth>hmm, so chips does cooperative GRM stuff
10:57<@Alberth>now I have to write a decoder for it :p
10:58<frosch123>or rewrite chips to no longer use it
10:58<frosch123>when chips was written GRM was necessary for recolour sprites
10:58<frosch123>but that is no longer the case
10:58<frosch123>you can do recoluring with action1 sprites now
10:59<@Alberth>I am yet to understand what all these grf actions do, let alone I understand the bigger picture yet :p
11:00<@Alberth>it seems to do "reserve" which is in line with what you say
11:00<@Alberth>217 entries, feature 8
11:02<@Alberth>not to mention an action 6 next, which is likely black magic :p
11:02<frosch123>GRM always involves A6 :)
11:03<frosch123>essentially, you need N recolour sprites
11:03<frosch123>you do a malloc for those sprites and get a pointer to them (GRM reserve)
11:03<frosch123>then you insert that pointer in places where you need the sprites (action 6)
11:05<andythenorth>not quite witchcraft
11:05<andythenorth>+1 to rewrite chips :P
11:05<andythenorth>give me a station spec, I'll rewrite it
11:05<andythenorth>gladly
11:06<@Alberth>https://paste.openttdcoop.org/pwm7jgtvu >> is the decoded action D, with a 10 and 6 action in-between, and "change sprites below the action 6, which likely writes the sprites at the address changed by the action 6
11:08<@Alberth>no idea where the 32, 33, and 34 come from, but perhaps, they are just random numbers
11:08<frosch123>are they register numbers?
11:09<frosch123>s/register/parameter/
11:09<@Alberth>could be, is there a list of register numbers?
11:09<frosch123>they are freely usaable
11:09<frosch123>just variables for stuff
11:10<frosch123>anyway, does the action6 have the 0x80 add flag?
11:12<frosch123>the 32/33 thing seems to be the silly differential add method to work around GRF loading stages
11:13<frosch123>it's really stupid, i think people only came up with it to impress clueless people
11:13*LordAro wonders how nielsm has managed to create house-watched_cargoes-64 branch on the main repo
11:13<@Alberth>there is no 80+ value in the action 6, except for the terminating ff
11:14<frosch123>LordAro: good question
11:14<nielsm>LordAro uh I did that? :s
11:14<@Alberth>developers can push non-protected branches, I think
11:16<@Alberth>I don't understand why they didn't use a new action number, instead of merging 4 different functionalities into 1 action
11:17<@Alberth>special values with different meaning depending on other special values :p
11:17<frosch123>looks like the branch protection stuff can use wildcards
11:18<@Alberth>ah, that's nice
11:18<@Alberth>global, or per developer?
11:18<frosch123>TrueBrain: do you remember whether any of the protected branch rules are different? or can we just merge them into one "*"?
11:18<@Alberth>ie have alberth_* branches for me, eg
11:19<LordAro>nielsm: grats on making developer tho :>
11:21<frosch123>why is the 0.4 branch newer than the 0.4.5?
11:21<@Alberth>people continued making patches for 0.4.6 ?
11:22<frosch123>i mean there is a 0.4 branch and a 0.4.5 branch
11:22<frosch123>0.4.5 had a separate branch for some reason
11:22<frosch123>while 0.4.6 was again done from 0.4 brnach
11:23<@Alberth>confusion on the used branch model I guess
11:23<frosch123>i know thar 0.4.5 was more like 0.5
11:23<frosch123>but i expected 0.4.6 from the 0.4.5 branch
11:24<@Alberth>and never update 0.4.5, thus
11:27<frosch123>so, i merged all the release/* rules
11:27<frosch123>i'll keep master separate for now
11:28<frosch123>not sure whether that may get different rules
11:28<@Alberth>does "branch protection" even work? https://help.github.com/articles/enabling-branch-restrictions/ says it rericts pushing to a branch, but what if you make a new branch?
11:28<@Alberth>ie I can't push to master, but I can push "mymaster" on top of master
11:28<frosch123>yes, that's exactly the problem we had here :)
11:28<frosch123>i think we would need a rule "*"
11:29<frosch123>but gh does not allow overlapping rules
11:29<frosch123>and the master rule is actually different from the release rule
11:30<@Alberth>that makes all branches restricted, but I am not pushing to an existing branch
11:30<@Alberth>I make a new branch
11:31<frosch123>no idea
11:31<frosch123>maybe it is considered easy to fix
11:31<frosch123>just deleting the branch
11:31<frosch123>(which i already did)
11:32<andythenorth>does "for i in range(len(value.values) / 3):" choke on floats?
11:32<@Alberth>yeah, so perhaps they assume you wouldn't give developer rights
11:32*andythenorth should know, after 10 years of python
11:32<@Alberth>yes, / in python3 is always a float
11:32<@Alberth>use //
11:33<@Alberth>don't you want a range with a stepsize of 3 ?
11:33<andythenorth>not sure
11:34<andythenorth>I'm just trying to make it run :)
11:34<andythenorth>my competency here is below what's needed :P
11:34<@Alberth>fair enough :)
11:34<@Alberth>but yeah, / got changed from 2 to 3
11:35<andythenorth>ok these are my patches so far https://paste.openttdcoop.org/pncrp9vcg/dfe8ht/raw
11:36<frosch123>nielsm: https://paste.openttdcoop.org/p8km7i1t3 <- please add a separate push-url to your git config
11:38<andythenorth>hmm
11:40<nielsm>https://0x0.st/sJH6.txt <- should be safe now
11:41<andythenorth>tile acceptance flag isn't working yet
11:41<andythenorth>checking for EBKAC again :)
11:46<andythenorth> 3417 * 15 00 09 04 01 FF AA 00 08 00 0D 00 12 01 11 00
11:46<andythenorth>looks like prop 12 is 01?
11:46<andythenorth>which is the expected value
11:47<andythenorth>oh does it need to set a bitmask?
11:47<andythenorth>is the expected value 2?
11:48<frosch123>yes
11:48<andythenorth>hmm
11:48<andythenorth>the patch looks correct
11:48<andythenorth>https://github.com/nielsmh/nml/commit/0a8ebd97275607c7fc9b7ff997c624f1d493d62b
11:49<andythenorth>we specify flags as numbers, not the bitmask values
11:49<frosch123>bit 0 is "cb26 needs random bits"
11:49<frosch123>andythenorth: yes, your nml code need to have "bitmask(...)"
11:49<andythenorth>ok EBKAC
11:54<andythenorth>ok prop 2 is now set in the nfo
11:54<andythenorth>prop 12, bit 1 set, I mean
11:54<andythenorth>words
11:55<andythenorth>nielsm: have you tested prop 12 special flag for tiles?
11:55<andythenorth>o_O
11:58<andythenorth>I've cleared the tile acceptance in 0A, 0B, 0C, and set the flag
11:58<andythenorth>it's accepting 3 cargos, but 5 are set
12:21<nielsm>the "accepts everything" flag? yes that one works
12:24<andythenorth>hmm what do I do wrong :)
12:24<andythenorth> 3405 * 15 00 09 04 01 FF AA 00 08 00 0D 00 12 02 11 00
12:24<andythenorth>prop 12 is now 02
12:24<andythenorth>https://dev.openttdcoop.org/attachments/download/9072/prop_12.png
12:25<andythenorth>and props 0A / 0B / 0C aren't set
12:52<frosch123>i see, no need to find new names for different harbors
12:56-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has joined #openttd
12:56-!-snail_UES_ is "Jacopo Coletto" on #openttd
12:59<andythenorth>also more chance of them being place
12:59<andythenorth>placed *
12:59<andythenorth>harbours can currently ruin a map
13:00<andythenorth>too few of one type, or awkward locations
13:08-!-ToBeFree [~tobefree@00019d36.user.oftc.net] has joined #openttd
13:08-!-ToBeFree is "Tobias "ToBeFree" Frei" on #https-everywhere #oolite-dev #openttd @#linux #oolite #oolite-ger
13:08-!-ToBeFree [~tobefree@00019d36.user.oftc.net] has quit []
13:13-!-ToBeFree [~tobefree@00019d36.user.oftc.net] has joined #openttd
13:13-!-ToBeFree is "Tobias "ToBeFree" Frei" on #https-everywhere #oolite-dev #openttd @#linux #oolite #oolite-ger
13:24-!-chomwitt is "chomwitt" on #debian #debian-games
13:24-!-chomwitt [~chomwitt@ppp-94-66-223-177.home.otenet.gr] has joined #openttd
13:47-!-Alberth [~alberth@00015f9e.user.oftc.net] has left #openttd []
13:56-!-ToBeFree [~tobefree@00019d36.user.oftc.net] has quit [Quit: Leaving]
14:00-!-KouDy [~koudy@ip4-83-240-28-102.cust.nbox.cz] has joined #openttd
14:00-!-KouDy is "KouDy" on #openttd
14:04<andythenorth>trying to understand https://github.com/OpenTTD/OpenTTD/pull/6867/commits/aba662dadd3397684b7091077a7728a6a4cbad8c#diff-04c1eb90cc9761ed756a604e9e6b4c6dR433
14:04<andythenorth>is capping to 3 here for the legacy support? https://github.com/OpenTTD/OpenTTD/pull/6867/commits/aba662dadd3397684b7091077a7728a6a4cbad8c#diff-04c1eb90cc9761ed756a604e9e6b4c6dR424
14:08-!-AndroUser2 [~androirc@2605:b100:f24f:b964:d4e8:5f6:11ef:7263] has quit [Read error: Connection reset by peer]
14:09<nielsm>yes
14:10<nielsm>or rather, there are no new callbacks for tile accepts, so the old callbacks can only supply 3
14:13<andythenorth>and MemSetT is where we put up to 16?
14:13<andythenorth>maybe not
14:14<andythenorth>INDTILE_SPECIAL_ACCEPTS_ALL_CARGO = 1 << 1 is to read the second bit?
14:14*andythenorth is such a noob :P
14:15<nielsm>yes
14:15<andythenorth>trying to reverse engineer if anything is missing in my nfo
14:18-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has joined #openttd
14:18-!-AndroUser2 is "Android IRC Client" on #openttd
14:19<andythenorth>in-game debug tools don't include tile flags
14:22<andythenorth>this is the tile nfo https://paste.openttdcoop.org/pj69kvij2/ajf7xo/raw
14:23<andythenorth>it's in 2 blocks because that's how nml inserts the cb flag
14:23<andythenorth>I wondered if prop 8 being 0 is a problem, but shouldn't be
14:23<andythenorth>0D is land shape
14:24<andythenorth>11 is triggers for cb25
14:24<andythenorth>0E is the cb flags
14:24<andythenorth>and 12 is special flags
14:30<snail_UES_>michi_cc: I tried your corrected patch for 90-degree curves and it works
14:31<snail_UES_>i.e. railtypes that are supposed to allow tight curves do allow them, and those that don’t actually forbid them
14:31<snail_UES_>pathfinder seems to work correctly as well… anything specific you might think of I should check further?
14:39<@peter1138>Why is it a railtype option? o_O
14:43<+michi_cc>snail_UES_: Nothing except support from other devs :)
14:45<snail_UES_>michi_cc: heh, got it...
14:45<+michi_cc>I'm not sure the forbid flag would be a good idea though, as somebody playing with the 'forbid 90deg' setting to off has no indication that a particular layout will break with some railtypes.
14:45<nielsm>andythenorth, sorry can't really look into anything more right now, I have a growing headache and looking at monitors is painful
14:46<+michi_cc>The allow flag is a lot less problematic as doesn't surprisingly breaks layouts.
14:46<andythenorth>np :)
14:46<andythenorth>nielsm: I just don't want to forget it all by september :)
14:46<andythenorth>after all our holidays
14:46<andythenorth>it's near done, but I have git stash patches :P
14:46<snail_UES_>michi_cc: so we could only have an “allow” flag that overrides the OTTD main setting and allows sharp curves
14:46<snail_UES_>it would be OK with me
14:47<andythenorth>doesn't this need to be inverse boolean matrix thing?
14:47<andythenorth>isn't the point to over-ride player settings?
14:49<andythenorth>so if player has forbid, set allow
14:49<andythenorth>and if player has allow, set forbid
14:49<andythenorth>no?
14:56<@peter1138>Why does the player's setting need to be ignored?
14:56<@peter1138>Why do we need this flag?
15:00<snail_UES_>peter1138: we need it to give an advantage to railtypes such as narrow gauge, which in reality could do sharper curves
15:01<snail_UES_>andythenorth: inverting the player setting would miss the point…
15:01<andythenorth>eh?
15:01<snail_UES_>what we need here is to always allow sharp curves, regardless of what the user sets. This is only for narrow gauge railtypes, to give them an historically accurate advantage
15:02<andythenorth>but there's no advantage if user allows sharp curves
15:02<andythenorth>so it needs to invert user setting
15:02<andythenorth>in fact, just ignore user setting
15:02-!-Gja [~Martin@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd
15:02-!-Gja is "Martin" on #ceph #bcache #openttd
15:02<snail_UES_>andythenorth: yes, the point is to ignore the user setting for certain railtypes
15:04<andythenorth>so if user setting is 'allow', then railtype inverts
15:04<andythenorth>and if 'disallow' then railtype inverts
15:04<snail_UES_>andythenorth: it would be pointless to disallow sharp curves for narrow gauge railtypes
15:04<andythenorth>in fact, why not just remove user setting?
15:04<snail_UES_>andythenorth: as I said, this is about giving NG an in-game advantage
15:04<snail_UES_>in reality, narrow gauge rails have sharper curver
15:05<snail_UES_>a way to model this in a game is to only allow 90-degree curves for NG, when the user disallows them in general
15:06<snail_UES_>if a player allows 90-degrees curves in general, then they should be allowed everywhere. It would make totally no sense to have sharpe curves for broader gauges and not for narrower gauges :)
15:08<snail_UES_>alternatively we could remove user setting at a game level and place it to a railtype level, but this would require major work. The change Michi has put in place is simpler
15:10<frosch123>why don't you improve the curve-speed-bonus/penalty property for a larger range or something?
15:11<snail_UES_>frosch123: because NG trains are already very slow
15:11<snail_UES_>they’re trains running at 50-60km/h in general, so they already don’t slow down much around curves
15:16<andythenorth>snail_UES_: I don't get it :)
15:16<snail_UES_>andythenorth: ok, what part don’t you get?
15:16<andythenorth>it's not an advantage if player enables 90 degree
15:16<andythenorth>so you need to also forbid 90 degree
15:17<andythenorth>for other types
15:17<andythenorth>i.e. remove player setting, force it in newgrf
15:17<snail_UES_>yes, but Michi just said this would be more problematic
15:17<snail_UES_>if forbidding 90 degrees is more difficult, then even just allowing 90 degrees for certain types would be an acceptable result
15:18<snail_UES_>NG would have an advantage if the player forbids 90 degrees game-wise. That’s what I would recommend for my set
15:18<andythenorth>seems like quite a bit of work for not a lot of result :)
15:19<+michi_cc>It's not difficult in a technical sense, but it is not very intuitive without some way to show more info about a railtype than just the name string.
15:19<snail_UES_>andythenorth: work is done...
15:19<andythenorth>but what will the setting say in game?
15:19<andythenorth>'forbid 90 degrees unless the railtype allows it' ?
15:19<andythenorth>or is it a tri-state setting now?
15:19<LordAro>that sounds a bit silly
15:20<snail_UES_>the in-game setting would remain unchanged
15:20<LordAro>why would you want grfs to be able to override a game setting?
15:20<snail_UES_>LordAro: for what I described before…
15:21<snail_UES_>that I might want to give an advantage to a certain railtype, which I can’t do now
15:21<LordAro>i don't see that as a valid reason
15:21<snail_UES_>why not? in reality, having sharper curves was actually one of the motivations to build narrow gauge instead of standard
15:21<snail_UES_>the other was cost
15:22<LordAro>OTTD is not real life
15:22<andythenorth>the setting description has to change
15:22<LordAro>sharper curves are one thing, 90 degree sudden turns are not
15:22<andythenorth>can't have a setting that isn't a setting eh
15:22<LordAro>s/not/another/
15:22<andythenorth>it just causes bug reports
15:22<andythenorth>and angry server owners
15:23<andythenorth>I would just bin the setting tbh
15:23<andythenorth>we have too many
15:23<andythenorth>do it in content
15:23<snail_UES_>andythenorth: I wouldn’t disagree with your idea
15:23<snail_UES_>bin the setting and let single tracksets define whether 90-degree curves are allowed or not
15:24<LordAro>that will cause more confusion
15:24<snail_UES_>there could be a default behavior
15:24<LordAro>even so
15:25<LordAro>"i can create tracks with 90 degree turns with x railtype, but not with y"
15:25<andythenorth>we could call it OpenTTD Revolution
15:25<andythenorth>remove lots of settings
15:25<snail_UES_>LordAro: why not?
15:25<LordAro>or, depending on how it is implemented, "i upgraded my tracks and now they don't go past the 90 degree turn"
15:26<snail_UES_>LordAro: again, why not? we already have something like this if I upgrade tracks with a different electrification system
15:26-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has quit [Read error: Connection reset by peer]
15:26<snail_UES_>“I upgraded my tracks to highspeed and now my 3rd rail trains won’t run there anymore”. We’re there already
15:26<snail_UES_>so this is not a valid reason to shoot this proposal down
15:27<LordAro>apart from the fact that it would increase the number of said reports
15:28<snail_UES_>LordAro: not if I document it well in my trackset… I would clearly explain which gauge is the one that can do sharp curves
15:29<snail_UES_>of course it could be misused, but then again, so could any other feature or option
15:29-!-Supercheese [~Superchee@cpe-98-146-230-183.natnow.res.rr.com] has joined #openttd
15:29-!-Supercheese is "Supercheese" on #openttd
15:29<andythenorth>is it not just tri-state instead of boolean?
15:30<andythenorth>90 degree: allow, forbid, delegate to newgrf?
15:30<snail_UES_>andythenorth: we could even do that
15:34-!-glx [~glx@000128ec.user.oftc.net] has joined #openttd
15:34-!-mode/#openttd [+v glx] by ChanServ
15:34-!-glx is "Loïc GUILLOUX" on +#openttd
15:35-!-AndroUser2 [~androirc@184.151.179.237] has joined #openttd
15:35-!-AndroUser2 is "Android IRC Client" on #openttd
15:37<andythenorth>I am potato / potato
15:38<andythenorth>I would rather find another way
15:38<andythenorth>not my decision anyway
15:38<andythenorth>it's $someone, because no-one is in charge :)
15:42<snail_UES_>andythenorth: potatoes in FIRS?
15:43<andythenorth>what else could distinguish NG?
15:43<snail_UES_>low costs, low speed and capacity…
15:43<andythenorth>currently it's nerfed
15:44<andythenorth>if it's at all realistic, it has lower capacity per tile
15:44-!-Happpy [~5ac0c755@000275fa.user.oftc.net] has joined #openttd
15:44-!-Happpy is "90.192.199.85 - http://irc.openttdcoop.org/" on #openttd #/r/openttd +#openttdcoop.stable +#openttdcoop
15:44<andythenorth>so it would need to be so cheap
15:44-!-Gja [~Martin@93-167-84-102-static.dk.customer.tdc.net] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
15:44<snail_UES_>lower capacity and lower costs by tile
15:45<andythenorth>wondering about maintenance cost, but I don't use them
15:45-!-Happpy [~5ac0c755@000275fa.user.oftc.net] has left #openttd []
15:45<snail_UES_>maintenance costs are also lower than SG
15:46<nielsm>I believe NG often supports lower axle loads so it's built with less heavy rails, so significantly less cost in steel to build
15:46<nielsm>so that's not unrealistic at least
15:47<nielsm>not sure whether sleepers, ballast, and whatever else makes up the track bed is different
15:47<snail_UES_>nielsm: yes, that’s the point. So tracks are cheaper
15:48<snail_UES_>older tracks were built with a mix of sand and pebbles, and wooden sleepers of not so high quality
15:48<snail_UES_>so the final result was cheaper
15:48<snail_UES_>and the narrower gauge allowed for sharper curves, so they were used especially on mountain lines
15:50<andythenorth>tbh
15:50<andythenorth>realism is no help to me here for Iron Horse
15:50<andythenorth>fundamentally, it's a tile based game with a capacity-per-tile :)
15:50<snail_UES_>does IH have different gauges?
15:50<andythenorth>yers
15:50<snail_UES_>so this proposal could help you as well :)
15:50<andythenorth>no
15:51<andythenorth>I always allow 90 degree curves
15:51<snail_UES_>ah… ok
15:51<andythenorth>the problem of NG is that the capacity-per-tile is nerfed
15:51<snail_UES_>but it would help other players who don’t
15:51<snail_UES_>andythenorth: but then your NG vehicles and tracks should be significantly cheaper
15:51<andythenorth>IRL NG simply takes up less space
15:52<andythenorth>whereas in-game it still uses a whole tile
15:52<snail_UES_>correct
15:52<andythenorth>OpenTTD is primarily a tile-contention game
15:52<andythenorth>at least for smaller maps and advanced games
15:52<andythenorth>maybe NG should just be trams
15:52<andythenorth>possibly the correct solution
15:53<nielsm>but you can't build road vehs from parts
15:53<snail_UES_>andythenorth: that would give them huge disadvantages...
15:53<snail_UES_>you couldn’t have horizontal or vertical tracks…
15:53<snail_UES_>and only 90-degree curves
15:53<andythenorth>can we have smaller tiles?
15:53<andythenorth>o_O
15:54<snail_UES_>andythenorth: that is the question :D
15:54<andythenorth>can we have multi-track station tiles?
15:54<andythenorth>can we have state machine depots that allow 1-in-1-out at once
15:54<andythenorth>instead of contending the entrance?
15:54<andythenorth>can we have auto-PBS on bridges, so that trains can safely follow even without a signal?
15:55-!-cHawk [chawk@3-0-0-244-187.cpe.cableone.net] has joined #openttd
15:55-!-cHawk is "realname" on #openttd
16:03<AndroUser2>Hey all
16:03-!-AndroUser2 is now known as DanMacK
16:04<DanMacK>Much better
16:05<DanMacK>Query andythenorth
16:05<andythenorth>yo DanMacK
16:05<Wolf01>So it was him all the time :D
16:06<DanMacK>Yeah... androirc decided to log me in
16:09-!-KouDy [~koudy@ip4-83-240-28-102.cust.nbox.cz] has quit [Remote host closed the connection]
16:10<DanMacK>!seen
16:10<DanMacK>So that doesnt work lol
16:11<LordAro>not in this channel
16:11<LordAro>and not like that anyway :p
16:11<LordAro>@seen DanMacK
16:11<@DorpsGek>LordAro: DanMacK was last seen in #openttd 23 seconds ago: <DanMacK> So that doesnt work lol
16:11<DanMacK>@seen Pikka
16:11<@DorpsGek>DanMacK: Pikka was last seen in #openttd 8 weeks, 6 days, 10 hours, 53 minutes, and 52 seconds ago: <Pikka> oops
16:27<@peter1138>Yeah, where did he go?
16:32<FLHerne>The root-cause fix for many of these "[x] is useless/non-differentiated" problems would be to somehow make costs meaningful...
16:32<FLHerne>Being infinity times cheaper is still meaningless when you have unlimited money
16:33<FLHerne>Can just turn the base-costs up massively, but then people lose instead
16:33<andythenorth>where *did* he go
16:33<FLHerne>Non-linear infra costs work
16:33<FLHerne>Just not enough
16:35<andythenorth>costs are irrelevant
16:35<andythenorth>the real significant thing is tile contention :)
16:35<andythenorth>that's why RVs are so different to trains
16:35<andythenorth>etc
16:35<FLHerne>Well, yes, that's what I'm complaining about :P
16:36<andythenorth>so more transport types :P
16:36<nielsm>yeah, need to peek at reality a bit and figure out why real world transportation companies aren't swimming in money (or at least act like they aren't)
16:36<andythenorth>or mess with routing or something
16:36<FLHerne>Capital costs are functionally 0, because everyone has infinite money
16:36<FLHerne>So the only constraints on what you can build are time, map space and imagination, which is silly
16:37<FLHerne>Well, it's fun until the imagination runs out...
16:38<nielsm>shouldn't maintenance costs of vehicles also rise as they age, so an old fleet is significantly more expensive than a new one
16:38<nielsm>(but the costs of replacing everything all the time should be even worse)
16:39<FLHerne>Eh
16:39<FLHerne>I don't think the current balance of /costs/ is too bad
16:39<FLHerne>Most things seem to be vaguely in proportion
16:39<andythenorth>the scarce resource is tiles
16:39<andythenorth>especially as cities grow, or at busy industry
16:40<FLHerne>It's that income vastly outweighs them, and that economies of distance/utilisation mean that any settings that make large companies non-infinitely-rich make small ones impossible
16:40<andythenorth>money is not the correct scarcity resource :)
16:41<FLHerne>andythenorth: ...and so NG rail is useless, because it's not optimised for that one meaningful resource
16:41<andythenorth>adding tech tree might actually help
16:41<andythenorth>then vehicles are scarce
16:41-!-Supercheese [~Superchee@cpe-98-146-230-183.natnow.res.rr.com] has quit [Read error: Connection reset by peer]
16:41<FLHerne>Tech tree would be fun
16:41<FLHerne>Or those vehicle factories that people proposed
16:41-!-Supercheese [~Superchee@cpe-98-146-230-183.natnow.res.rr.com] has joined #openttd
16:41-!-Supercheese is "Supercheese" on #openttd
16:42<nielsm>maximum number of vehicles that can be purchased over a time period
16:42-!-frosch123 [~frosch@00013ce7.user.oftc.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
16:42<FLHerne>"Produces one locomotive per month when supplied with >200tons of Metal"
16:43<nielsm>to somewhat simulate production/delivery time on vehicles without actually delaying the player getting control after clicking buy
16:43<FLHerne>Except then every industry/vehicle set would need pairing, or some really weird interface
16:43<andythenorth>NG could be unlocked on the tech tree
16:43<andythenorth>whereas bigger trains would require more research / gold / dragons teeth / whatever
16:44<andythenorth>and we decouple any IRL dates
16:44<andythenorth>because all nonsense
16:44<FLHerne>No thx
16:44<nielsm>isn't that kinda like maschinky or however it's spelled?
16:44<andythenorth>dunno
16:44<FLHerne>You can tear my pseudo-accurate BR train progression from my cold dead hands
16:45<andythenorth>well you just script a tech tree for that
16:45<andythenorth>it's fine
16:45<andythenorth>tech tree scriprt
16:45<nielsm>what I really want in a train game is no predefined models but instead you order by requirements from a factory and they try to develop a model to your specs
16:46<FLHerne>If buying vehicles required cargo being delivered to an industry, availability could be governed by cargo chains...
16:46<nielsm>and you have to choose two of cheap, powerful, reliable
16:47<FLHerne>i.e. you can't deliver CoolTechStuff to make maglevs until you've got vehicles that can carry CoolTechStuff
16:47<FLHerne>And those need SemiInterestingStuff to make, and so forth
16:48<FLHerne>With 64 cargos, and umpteen cargoes-per-industry, you can force players through a /really/ insane cargo production graph
16:48<FLHerne>[/nutso idea]
16:49<andythenorth>tech tree
16:49<andythenorth>unlock goals
16:49<FLHerne>"goals"?
16:49-!-sim-al2 [~sim-al2@c-75-65-196-171.hsd1.tn.comcast.net] has joined #openttd
16:49-!-sim-al2 is "sim-al2" on #openttd
16:49<andythenorth>GS innit
16:49<nielsm>we did talk a bit about some kind of game script interface the other day
16:50<nielsm>to let GS control vehicle availability
16:51<FLHerne>SO is the next patch for 64 GSes per game? :P
16:52<FLHerne>(but seriously, more than one would be nice, there are so many orthogonal uses for them)
16:55<andythenorth>they would conflict
16:55<andythenorth>but yes
17:17-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has left #openttd []
17:39-!-KouDy [~koudy@ip4-83-240-28-102.cust.nbox.cz] has joined #openttd
17:39-!-KouDy is "KouDy" on #openttd
17:42-!-AndroUser2 [~androirc@184.151.179.237] has joined #openttd
17:42-!-AndroUser2 is "Android IRC Client" on #openttd
17:42-!-DanMacK [~androirc@184.151.179.237] has quit [Read error: Connection reset by peer]
17:53-!-AndroUser2 [~androirc@184.151.179.237] has quit [Remote host closed the connection]
17:54-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has joined #openttd
17:54-!-AndroUser2 is "Android IRC Client" on #openttd
18:02-!-Wormnest [~Wormnest@s5596abd2.adsl.online.nl] has quit [Quit: Leaving]
18:50-!-Progman [~progman@p57A2B2E8.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
18:59-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has quit [Remote host closed the connection]
18:59-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has joined #openttd
18:59-!-snail_UES_ is "Jacopo Coletto" on #openttd
19:06-!-nielsm [~nielsm@62-243-118-198-cable.dk.customer.tdc.net] has quit [Ping timeout: 480 seconds]
19:06-!-Thedarkb-T60 [~Thedarkb-@51-171-111-18-dynamic.agg2.kny.prp-wtd.eircom.net] has joined #openttd
19:06-!-Thedarkb-T60 is "realname" on #openttd
19:12-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has quit [Remote host closed the connection]
19:13-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has joined #openttd
19:13-!-AndroUser2 is "Android IRC Client" on #openttd
19:13-!-Thedarkb-T60 [~Thedarkb-@51-171-111-18-dynamic.agg2.kny.prp-wtd.eircom.net] has quit [Read error: Connection reset by peer]
19:14-!-Thedarkb-T60 [~Thedarkb-@51-171-111-18-dynamic.agg2.kny.prp-wtd.eircom.net] has joined #openttd
19:14-!-Thedarkb-T60 is "realname" on #openttd
19:19-!-APTX_ [~APTX@2001:470:71:71d:defe:7ff:fee1:3d5d] has quit [Remote host closed the connection]
19:34-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has quit [Remote host closed the connection]
19:34-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has joined #openttd
19:34-!-AndroUser2 is "Android IRC Client" on #openttd
19:36-!-APTX_ [~APTX@2001:470:71:71d:defe:7ff:fee1:3d5d] has joined #openttd
19:37-!-APTX_ is "APTX" on #openttd #kernelnewbies
19:49-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.]
20:21-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
20:21-!-mode/#openttd [+v tokai|noir] by ChanServ
20:21-!-tokai|noir is "Christian Rosentreter" on +#openttd
20:22-!-eirc [5e47f48c@107.161.19.53] has quit [Remote host closed the connection]
20:28-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
20:32-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has quit [Remote host closed the connection]
20:33-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has joined #openttd
20:33-!-AndroUser2 is "Android IRC Client" on #openttd
20:53-!-AndroUser2 [~androirc@2605:b100:f24f:b964:481e:437b:f833:5ad7] has quit [Ping timeout: 480 seconds]
20:54-!-AndroUser2 [~androirc@2607:fea8:2a20:34d:481e:437b:f833:5ad7] has joined #openttd
20:54-!-AndroUser2 is "Android IRC Client" on #openttd
21:00-!-AndroUser2 [~androirc@2607:fea8:2a20:34d:481e:437b:f833:5ad7] has quit [Remote host closed the connection]
21:11-!-Supercheese [~Superchee@cpe-98-146-230-183.natnow.res.rr.com] has quit [Read error: Connection reset by peer]
21:12-!-Supercheese [~Superchee@cpe-98-146-230-183.natnow.res.rr.com] has joined #openttd
21:12-!-Supercheese is "Supercheese" on #openttd
21:56-!-Flygon [~Flygon@124-148-144-253.dyn.iinet.net.au] has joined #openttd
21:56-!-Flygon is "Flygon" on #openttd
22:31-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
22:31-!-mode/#openttd [+v tokai] by ChanServ
22:31-!-tokai is "Christian Rosentreter" on +#openttd
22:38-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
22:44-!-chomwitt [~chomwitt@ppp-94-66-223-177.home.otenet.gr] has quit [Ping timeout: 480 seconds]
22:57-!-glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye]
23:23-!-AndroUser2 [~androirc@CPEf81d0f8a7353-CMf81d0f8a7350.cpe.net.cable.rogers.com] has joined #openttd
23:23-!-AndroUser2 is "Android IRC Client" on #openttd
23:36-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has quit [Quit: snail_UES_]
23:48-!-haudrauf [~haudrauf2@00021656.user.oftc.net] has quit [Ping timeout: 480 seconds]
23:49-!-haudrauf [~haudrauf2@p200300C35F0AD800D234D73B72EDD0F9.dip0.t-ipconnect.de] has joined #openttd
23:49-!-haudrauf is "Haudrauf" on #openttd #frickelplatz @#ffod @#ffnord @#ffki @#ffhl @#ffhh @#fffl #cryptoparty @#ccchh @#ccc.do
---Logclosed Mon Aug 13 00:00:04 2018