Log for #openttd on 12th August 2018:
Times are UTC Toggle Colours
00:05:52  *** chomwitt has quit IRC
00:10:04  <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison updated pull request #6881: Fix: Script/AI construction of rail track and waypoints
00:18:54  <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison commented on pull request #6881: Fix: Script/AI construction of rail track and waypoints
00:21:40  *** tokai has joined #openttd
00:21:40  *** ChanServ sets mode: +v tokai
00:25:58  <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison updated pull request #6883: Fix: Depot building cost does not include foundation build cost (#6875)
00:28:18  *** tokai|noir has quit IRC
01:07:53  *** glx has quit IRC
02:41:26  *** Supercheese has quit IRC
02:41:48  *** Supercheese has joined #openttd
03:49:37  *** haudrauf has quit IRC
03:50:56  *** haudrauf has joined #openttd
04:31:01  <k-man> how do you increase the size of an airport?
04:31:29  <k-man> can i just destroy and build over the top? will that void all orders of aircraft going to that airport?
05:34:02  <Supercheese> As long as you do it very quicky, or while paused, it should maintain all your aircraft orders
05:44:02  *** Alberth has joined #openttd
05:44:02  *** ChanServ sets mode: +o Alberth
05:44:08  <Alberth> moin
05:45:12  <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
05:49:27  <Supercheese> that works too
05:54:41  <Alberth> if you're quick enough in destroy & rebuild, the name is kept
05:55:16  <Alberth> shouldn't have any pesky AIs around that plop down their airport as soon as you destroy yours :p
05:58:39  <k-man> yeah
05:58:41  <k-man> ok
05:58:46  <k-man> i don't have any AIs
05:59:11  <k-man> i let my son play on my game for a bit
05:59:20  <k-man> random airports popped up all over the place :)
06:03:05  <k-man> what is the rule for maximising speed around corners?
06:03:09  <k-man> of trains that is
06:21:59  <Alberth> depends on the train-type
06:22:34  <Alberth> but no 2x 45 degrees directly after each other is a first big step :)
06:23:39  <Alberth> but to some extent it's not that important
06:24:06  <Alberth> near stations you usually have the least amount of space, but trains don't go fast there either
06:24:33  <Alberth> on open field trains go faster, but you also have plenty of room to smooth out the edges
06:25:34  <Alberth> ie 2x45 degrees is fine near a station, as a train isn't traveling > 80-something km/h there
06:31:34  *** eirc has quit IRC
06:38:44  *** nielsm has joined #openttd
06:42:07  <k-man> ah ok
06:42:22  *** snail_UES_ has quit IRC
06:42:55  <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
06:43:07  <k-man> is there a way to do that?
06:43:34  *** andythenorth has joined #openttd
06:53:58  <Alberth> place station, but hold control while placing it, you'll get a window to select what you want
06:54:02  <Alberth> moin andy
06:54:06  <andythenorth> o/
06:57:25  <k-man> thanks Alberth
07:04:33  * andythenorth testing nml for 16 cargos in / 16 out
07:07:21  <nielsm> yay
07:08:12  <andythenorth> tip of the branch gives me a python syntax error in make test
07:08:19  <nielsm> heh
07:08:24  <andythenorth> I'm working through the other commits one hash at a time, testing
07:08:34  <nielsm> I did warn you that I didn't even attempt to run this :)
07:08:49  <andythenorth> you did
07:11:29  *** Supercheese has quit IRC
07:11:51  *** Supercheese has joined #openttd
07:14:18  <andythenorth> hmm
07:15:40  <andythenorth> afaict this looks right
07:15:53  <andythenorth> but the result in-game is that industry produces only Acid cargo
07:16:08  <andythenorth> no acceptance, and is missing industry window text
07:16:55  <nielsm> what does it produce as NFO output?
07:18:05  <andythenorth> this may take some time :)
07:18:15  <andythenorth> 107k lines :)
07:18:16  <andythenorth> of nfo
07:18:18  <nielsm> ouch
07:18:44  <andythenorth> I think I need to patch FIRS compile to just do one industry nfo
07:19:29  <andythenorth> oh I already have that :)
07:19:39  <nielsm> think you can maybe try producing something simple like my test grf?
07:20:14  <andythenorth> just 13k lines now
07:20:55  <andythenorth> so prop 26 I need to find
07:20:59  <nielsm> but it's only the action0's that are interesting
07:22:38  * andythenorth lost in the varaction 2s
07:22:43  <andythenorth> glad I didn't write those in nfo
07:23:01  <andythenorth>
07:24:27  <nielsm> what's those rst escapes?
07:25:02  <nielsm> oh wait it's an action 2, so something to indicate operators I guess
07:27:09  <andythenorth> afaict prop 26 should be in this sprite
07:28:07  <andythenorth> hmm prop 26 is in there
07:28:09  <andythenorth> 25 isn't
07:28:18  <Alberth> nielsm:
07:28:20  *** Progman has joined #openttd
07:28:47  <andythenorth> other sprites have prop 11 and 10 where 26 is in this sprite, which is encouraging
07:29:21  <nielsm> maybe my nml implementation is resolving the cargoids wrong
07:31:00  <andythenorth> ctt_list?
07:31:33  <nielsm> ah that's an existing function I re-used that seemed to be doing the right thing
07:31:39  <nielsm> maybe it isn't
07:32:48  <andythenorth> can't remember if it's industries that use absolute cargo IDs, not the CTT
07:32:54  <andythenorth> something does, or used to
07:33:34  <andythenorth> no CTT values should work
07:34:30  <andythenorth> oh
07:34:49  * andythenorth might have an answer, testing
07:38:02  <andythenorth> nielsm: my local checkout of your ottd PR was stale :)
07:38:09  <nielsm> oh
07:38:12  <nielsm> :D
07:38:47  <andythenorth> but at least I learnt how to read nfo again :P
07:39:39  <Alberth> ignore most numbers? :)
07:39:53  <andythenorth> yes
07:40:07  <andythenorth> look for patterns of prop number + feature number
07:41:04  <andythenorth> is good
07:41:11  <andythenorth> and
07:41:19  <andythenorth> I'll move on to the others
07:41:26  <andythenorth> we need some kind of online review tool :P
07:43:48  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #6881: Fix: Script/AI construction of rail track and waypoints
07:45:40  <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison merged pull request #6881: Fix: Script/AI construction of rail track and waypoints
07:45:41  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain pushed 1 commits to master:
07:45:41  <DorpsGek_II>   - Fix bf8d7df: Script/AI construction of rail track and waypoints (#6881) (by JGRennison)
07:45:42  <DorpsGek_II>
07:54:02  <andythenorth> seems to fail
07:54:09  <andythenorth> I'm checking it's not EBKAC
07:55:42  <andythenorth>
07:56:05  <andythenorth> curious about what ByteListProp is
07:56:46  <nielsm> it generates a property value that's a length byte followed by that many byte-sized items
07:57:12  *** eirc has joined #openttd
07:57:13  <nielsm> renamed CargoListProp because that class didn't have anything to do specifically with cargo types
07:57:21  <andythenorth> ok
07:57:24  <andythenorth> so the input is prod_multiplier: [9, 7, 20, 14];
07:58:03  <andythenorth> line that reports failure is
07:58:04  <andythenorth>         if -0x80 <= value < 0 : value += 0x100
07:58:23  <nielsm> huh
07:58:26  <andythenorth> which looks like it's handling 80+ vars at my first guess
08:00:51  <andythenorth> ah do I have the spec wrong?
08:01:30  <andythenorth> what's the expected format for prod_multiplier?
08:02:58  <nielsm> the output is a byte counting number of values, followed by byte values for each output cargo slot
08:03:28  <andythenorth> so my input is correct?
08:03:32  <andythenorth> ok
08:03:33  <nielsm> I think so
08:04:33  <andythenorth> this is where we hit the limit of 'andythenorth can't use pdb'
08:04:37  <andythenorth> so I have to put prints in
08:05:52  <andythenorth> oh it's type comparison error no?
08:05:59  <andythenorth> Error:    (TypeError) "unorderable types: int() <= ConstantNumeric()".
08:06:47  <andythenorth> what does value.values[i].reduce_constant() do? o_O
08:06:48  <andythenorth> let's see
08:07:30  <Alberth> simplifying the expression
08:07:41  <Alberth> or constant, probably
08:08:12  <Alberth> you have to wrap the "int" into an expression object
08:09:02  <Alberth> not sure if you have a comparison then :)
08:09:21  <nielsm> or extract the resulting value from the reduced expression
08:09:40  <andythenorth> firs.nml, if anyone wants to play along at home
08:09:51  <andythenorth> I am currently at rev.
08:11:38  *** Supercheese has quit IRC
08:18:12  <andythenorth> [ByteListProp(0x27, [[i.reduce_constant().value for i in value.values]])] appears to work
08:18:19  <andythenorth> but I am cargo-culting from other places
08:18:28  <andythenorth> it's _probably_ wrong
08:18:36  <nielsm> same as me!
08:18:53  <andythenorth> the results are as expected
08:19:57  <andythenorth> Alberth o_O ?
08:20:07  <nielsm> bbl
08:20:22  <andythenorth> k
08:20:30  <andythenorth> I'm not sure reduce_constant() is even needed here
08:21:27  <andythenorth> hmm, fails without it
08:22:47  <Alberth> too many [ ] ?
08:23:27  <Alberth> maybe not
08:23:52  <andythenorth> seems not
08:24:00  <andythenorth> it's lists in lists :P
08:24:26  <Alberth> I don't think nml make a clean distinction between input expressions, and reduced expressions
08:24:46  <Alberth> so depending on where stuff comes from it may or may not fail
08:25:38  <Alberth> hmm, wondering what would happen if you make a second set of classes for normalized expressions
08:25:59  <Alberth> would solve the "double reduce" problem at least
08:26:30  <andythenorth> worth doing?
08:26:57  <Alberth> if we keep nml, likely worth a try
08:28:43  <Alberth> problem is that I don't know if any code tries to sneakily change expressions without making a new object
08:31:56  <andythenorth> we have....some regression tests :P
08:32:10  <andythenorth> it's probably TMWFTLB for current nml
08:41:02  *** frosch123 has joined #openttd
08:42:34  <andythenorth> quak and stuff
08:42:44  <frosch123> moi
08:45:59  <Alberth> moo
09:01:41  <andythenorth> so is this expecting an array of pairs?
09:02:38  <andythenorth> it's for prop 28
09:02:52  <andythenorth> seems it could have 256 possible entries :o
09:10:06  <nielsm> btw I also put all the docs for the new props in the initial comment on the PR :)
09:10:39  <nielsm> that's the maintained documentation right now
09:11:48  <nielsm> and yes prop 28 is stupid and annoying because it can take such a large number of values
09:12:25  <nielsm> I'm not sure if the format should be kept in either GRF or NML
09:12:47  *** juzza1 has quit IRC
09:13:32  <nielsm> the GRF format could be changed to a 2D array and so could the NML format
09:15:01  <andythenorth> do we need 16*16 multipliers?
09:15:04  <andythenorth> they can use cb for that
09:16:17  <nielsm> you mean scrapping prop 28 entirely?
09:16:59  <nielsm> that would close off part of the core industry type definition to GRF which I'd argue is conceptually wrong
09:18:15  *** juzza1 has joined #openttd
09:19:20  <andythenorth> maybe
09:19:30  <andythenorth> it just seems very faceted
09:20:51  <nielsm> part of the reason is also that I don't understand how production callback actually works :D
09:23:48  <andythenorth> oh it just returns the amount to produce :)
09:23:59  <andythenorth> it looks complex, but it literally returns 'produce n' for each cargo
09:25:03  <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
09:25:33  <andythenorth> I'm only querying it because FIRS doesn't use it, so I have to write a test case from scratch
09:25:40  <andythenorth> and test it :P
09:25:47  <nielsm> weak!
09:25:47  <nielsm> :)
09:25:57  <andythenorth> you've tested prop 28 works?
09:26:03  <nielsm> yes
09:26:09  <nielsm> not in NML but it does in GRF
09:26:18  <nielsm> (I use it in my own test file)
09:26:25  <andythenorth> I saw :)
09:26:53  <andythenorth> ok I'll make test case for that
09:26:58  <andythenorth> meanwhile,
09:27:00  <andythenorth> is the other fix
09:29:49  <nielsm> I have two birds on my head
09:29:56  <nielsm> one of their tails is partially blocking my view
09:31:40  <Alberth> turn your head :p
09:36:19  <andythenorth> go north
09:36:21  <andythenorth> inventory
09:37:07  <nielsm> movement is not currently possible
09:37:30  <nielsm> you have one bird dropping in your hair
09:37:49  <nielsm> you hear beaks grinding
09:48:21  *** Wormnest has joined #openttd
09:53:02  <andythenorth>  multipliers = multipliers + [(in_slot.value, out_slot.value, int(mul.value * 256)]
09:53:09  <andythenorth> invalid syntax :)
09:53:10  * andythenorth looks
09:53:18  <andythenorth> parentheses
09:53:52  <andythenorth> but where should the missing one be?
09:56:09  <andythenorth> should that line be multipliers.extend?
09:56:15  <k-man> how do you replace vehicles from electric trains to monorail?
09:56:16  <andythenorth> seems like list concatenation...
09:56:48  <k-man> the monorail train isn't listed in the replace window
09:58:35  <k-man> oh, apparently its not easy? you have to sell the old trains and buy new ones?
09:59:19  <andythenorth> syntax error is here
10:10:11  <nielsm> just before the end ]
10:10:15  <nielsm> another paren there
10:11:50  <Alberth> not the "int" ?    * 256 seems to need an integer :)
10:12:14  <nielsm> multipliers = multipliers + [(in_slot.value, out_slot.value, int(mul.value * 256))]
10:14:03  <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
10:14:42  <Alberth> alternatively, stop playing before you hit the forced railtype change, or us a newgrf that is not forcing you into it
10:14:50  <Alberth> *use
10:15:03  <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
10:15:19  <nielsm> or even just run monorail trains on the same rail as conventional
10:15:31  <nielsm> arguably that's cheating
10:16:45  <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 :)
10:24:51  <andythenorth> hmm
10:26:32  <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]];
10:26:42  <andythenorth> is that the correct format?
10:26:47  <nielsm> no
10:26:53  <andythenorth> ok
10:27:28  <nielsm> the format I'm expecting is kinda bad
10:28:07  <andythenorth> I'm trying to reverse engineer it from the nml code :)
10:28:11  <nielsm> but basically: [0, 1, 5, 1, 2, 2, 1, 3, 1]
10:28:14  *** Wolf01 has joined #openttd
10:28:25  <nielsm> that's three triplets of values
10:28:27  <andythenorth> it's B B W
10:28:28  <andythenorth> ?
10:28:30  <Wolf01> o/
10:28:41  <nielsm> yes
10:28:45  <andythenorth> ow that format hurts :)
10:28:52  <nielsm> input cargo slot, output cargo slot, multiplier
10:29:21  <nielsm> feel free to change it entirely
10:29:28  <andythenorth> oof
10:29:32  <nielsm> (in NML)
10:29:36  <andythenorth> I have no idea what's better :)
10:29:50  <andythenorth> I just would never use this property :)
10:30:04  <andythenorth> no eddi?
10:30:13  <nielsm> [ [0, 1, 5], [1, 2, 2], [1, 3, 1] ]
10:30:17  <nielsm> could be one option
10:30:24  <andythenorth> it's easier to read at least
10:30:49  <nielsm> [ [0, 5], [0, 0, 2, 1] ]
10:30:51  <nielsm> could be another
10:31:28  <k-man> cool, thanks for the tips guys
10:32:00  <Alberth> just use triplets
10:32:19  <Alberth> industry tiles are just as silly :)
10:33:35  <andythenorth> so that needs the patch changed? :)
10:34:15  <nielsm> well you can change the NML format without changing the GRF format, and vice versa, NML just needs to transform it appropriately
10:35: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
10:37:59  <nielsm> yeah
10:38:10  <nielsm> should probably change prop 28 format in GRF too
10:38:18  <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 :)
10:38:41  <nielsm> to maybe "B<n> B<m> n*m*W"
10:39:44  <nielsm> num_inputs, num_outputs, num_inputs * [num_outputs * multiplier]
10:40:42  <andythenorth> varying the output per input is bonkers
10:40:48  <andythenorth> but that ship apparently sailed a long time ago
10:48:02  *** Heiki has quit IRC
10:50:59  <Alberth> andy: that would mean each row is the same?
10:52:59  <Alberth> you could split it, have a "reset + initial value" for all entries, and a "add these numbers to the current"
10:53:50  <Alberth> or are properties supposed to be written in a single sprite?
10:55:43  <andythenorth> dunno :)
10:55:51  <andythenorth> I would have thought so though
10:56:14  <andythenorth> anything to make it more sane heads toward the production cb which already solves this :P
10:56:39  <andythenorth> this new prop 28 is just to keep parity with residual bits of spec
10:57:12  <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
10:57:17  <andythenorth> repeat for 16 cargos
10:57:25  <andythenorth> and you're not capable of using production cb
10:57:53  <andythenorth> sometimes I really hate backwards compatibility :(
10:58:02  <andythenorth> dragging along dead bits of spec, and all the associated code
11:00:32  <andythenorth> :)
11:03:27  <Wolf01> <andythenorth> sometimes I really hate backwards compatibility :( <- don't
11:03:53  <Wolf01> If people want new features move on
11:04:21  <andythenorth> don't do the compatibility?
11:04:24  <andythenorth> or don't hate it?
11:04:38  <Wolf01> Don't do
11:06:18  *** Maraxus has joined #openttd
11:06:33  <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
11:06:50  <andythenorth> not doing prop 28 doesn't break old grfs
11:06:57  <andythenorth> it just doesn't update an old way of doing things
11:07:17  <andythenorth> this is a new property and format introduced to support a legacy spec
11:07:52  <k-man> are there examples of building junctions where one of the track pairs is at 45%?
11:14:32  <andythenorth> frosch123: do you think it would be acceptable to drop prop 28?
11:15:27  <frosch123> andythenorth: i did not invent it :p
11:23:02  <Alberth> k-man, one standard junction is to add 2-tile long bridge to let the 45 degrees track under it
11:26:51  <nielsm> k-man have you considered this option?
11:26:52  <nielsm> :)
11:27:50  <nielsm> (obviously won't be efficient with heavy traffic, but for low traffic it's unbeatable)
11:32:57  <k-man> hmm, thanks
11:33:15  <k-man> i sent all my trains to depot
11:33:22  <k-man> is there some way to start them all again?
11:33:28  <k-man> without 100s of clicks
11:33:54  <nielsm> the master vehicle list should let you
11:34:06  <nielsm> each depot also has a "start all vehicles" button
11:34:54  <k-man> ah thanks
11:58:26  *** Compu has joined #openttd
12:47:41  *** andythenorth has quit IRC
12:55:16  *** Maraxus has quit IRC
13:22:45  *** ToBeFree has joined #openttd
14:08:16  * LordAro wonders if it's worth turning off +R now
14:10:19  <Wolf01> Why? I fixed my script now :>
14:11:18  <LordAro> :p
14:11:27  <frosch123> @mode -R
14:11:27  *** DorpsGek sets mode: -R 
14:11:32  <frosch123> let's try 5 minutes :p
14:15:23  *** AndroUser2 has joined #openttd
14:22:10  *** andythenorth has joined #openttd
14:22:20  <andythenorth> so we're all on the fence about prop 28? :P
14:22:30  <andythenorth> I have to just re-implement it in nml as a list of triples?
14:23:42  <frosch123> do you use those properties in firs?
14:23:49  <frosch123> or is it all production callback?
14:23:56  <andythenorth> production cb of course :)
14:24:58  <frosch123> how likely is it that some newgrf would want to use many input/output, but not use complex production mechanics?
14:25:17  <andythenorth> no idea :)
14:25:30  <andythenorth> how likely is it that I want to rewrite the nmlc code for this? o_O
14:25:31  <andythenorth> 0/1
14:26:06  <michi_cc> Is the problem with the prop itself or just with the NML syntax?
14:26:16  <frosch123> just the nml syntax :)
14:26:34  <frosch123> you can't implement it with just c&p
14:26:57  <frosch123> apparently
14:27:28  <michi_cc> m4nfo is obviously superior then :p
14:27:33  *** APTX_ has joined #openttd
14:27:56  <frosch123> actually, it's not the syntax that is complicated. just noone knows the nml implementation :p
14:28:24  <frosch123> m4 is the most advanced preprocessor
14:29:25  <andythenorth> I'll just rewrite this for a list of triples
14:29:29  <andythenorth> probably wrong :P
14:34:58  <andythenorth> eh how about 'nml doesn't implement this prop' :)
14:35:00  <Alberth> I don't understand why it needs a new triplet format, just make an extended version of large number of multipliiers
14:36:24  <Alberth> it may be based on the idea of sparse array, but I don't think it will be sparse
14:36:41  <Alberth> unless you get specific outputs for specific inputs
14:36:58  <Alberth> but you can also express that in the list of multipliers
14:37:42  <Alberth> given that few people will use it, reduce the amount of work?
14:38:27  <andythenorth> maybe I just leave the current format, and fix the bug? o_O
14:39:42  <Alberth> generate an extended version isn't that mucjh work is it?
14:39:45  <Alberth> *much
14:40:15  *** HeyCitizen has joined #openttd
14:40:18  <andythenorth> extended in what way?  Just more named props?
14:40:41  <Alberth> 3x2 does a row of output multipliers for each input
14:40:56  <Alberth> so if I have 5x4, have 5 rows of 4 numbers
14:41:28  <Alberth> and since that won't fit in the old property, add a new property, preferably with a 5 and 4 in there too
14:42:18  <Alberth> so you keep the old solution for those who want it with little effort, as far as I can see
14:42:57  <Alberth> maybe the 5 and 4 are implied elsewhere already
14:43:45  *** HeyCitizen_ has joined #openttd
14:44:03  <Alberth> ^ frosch123
14:44:51  <Alberth> same users different ip
14:45:54  <andythenorth> the (in the patch already) solution with a different prop name seems to fragment the API a bit
14:46:05  <andythenorth> it will make the docs more complicated
14:46:20  <andythenorth> 'use this prop for more than 3 cargos, otherwise use these 3 props'
14:46:34  <Alberth> I'd use the new one for all cases
14:46:51  <andythenorth> yeah, that makes more sense
14:46:55  <andythenorth> deprecate the old one
14:47:14  <andythenorth> but I think that will upset authors, as the new format is hard
14:47:20  <andythenorth> so I'd better figure out the triples :P
14:48:26  <Alberth> I think grf-format should allow the new one for any number of input and output
14:48:29  *** HeyCitizen has quit IRC
14:49:00  <Alberth> nml may want to generate the old property if possible to be backwards compatible with older openttds
14:52:36  <Alberth> is "mul.value" a floating point value? otherwise * 256 looks weird
14:53:00  <andythenorth> Error:    (TypeError) "'float' object cannot be interpreted as an integer".
14:53:08  <andythenorth> ^ current error :P
14:56:19  <Alberth> I'd need a line with that :)
14:57:13  <Alberth> hmm, so chips does cooperative GRM stuff
14:57:21  <Alberth> now I have to write a decoder for it :p
14:58:02  <frosch123> or rewrite chips to no longer use it
14:58:22  <frosch123> when chips was written GRM was necessary for recolour sprites
14:58:27  <frosch123> but that  is no longer the case
14:58:33  <frosch123> you can do recoluring with action1 sprites now
14:59:27  <Alberth> I am yet to understand what all these grf actions do, let alone I understand the bigger picture yet :p
15:00:17  <Alberth> it seems to do "reserve" which is in line with what you say
15:00:48  <Alberth> 217 entries, feature 8
15:02:24  <Alberth> not to mention an action 6 next, which is likely black magic :p
15:02:48  <frosch123> GRM always involves A6 :)
15:03:01  <frosch123> essentially, you need N recolour sprites
15:03:17  <frosch123> you do a malloc for those sprites and get a pointer to them (GRM reserve)
15:03:32  <frosch123> then you insert that pointer in places where you need the sprites (action 6)
15:05:35  <andythenorth> not quite witchcraft
15:05:48  <andythenorth> +1 to rewrite chips :P
15:05:55  <andythenorth> give me a station spec, I'll rewrite it
15:05:59  <andythenorth> gladly
15:06:36  <Alberth>   >> 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
15:08:20  <Alberth> no idea where the 32, 33, and 34 come from, but perhaps, they are just random numbers
15:08:59  <frosch123> are they register numbers?
15:09:18  <frosch123> s/register/parameter/
15:09:23  <Alberth> could be, is there a list of register numbers?
15:09:39  <frosch123> they are freely usaable
15:09:46  <frosch123> just variables for stuff
15:10:15  <frosch123> anyway, does the action6 have the 0x80 add flag?
15:12:53  <frosch123> the 32/33 thing seems to be the silly differential add method to work around GRF loading stages
15:13:19  <frosch123> it's really stupid, i think people only came up with it to impress clueless people
15:13:34  * LordAro wonders how nielsm has managed to create house-watched_cargoes-64 branch on the main repo
15:13:40  <Alberth> there is no 80+ value in the action 6, except for the terminating ff
15:14:03  <frosch123> LordAro: good question
15:14:30  <nielsm> LordAro uh I did that? :s
15:14:44  <Alberth> developers can push non-protected branches, I think
15:16:33  <Alberth> I don't understand why they didn't use a new action number, instead of merging 4 different functionalities into 1 action
15:17:27  <Alberth> special values with different meaning depending on other special values :p
15:17:59  <frosch123> looks like the branch protection stuff can use wildcards
15:18:17  <Alberth> ah, that's nice
15:18:31  <Alberth> global, or per developer?
15:18:48  <frosch123> TrueBrain: do you remember whether any of the protected branch rules are different? or can we just merge them into one "*"?
15:18:55  <Alberth> ie have alberth_* branches for me, eg
15:19:05  <LordAro> nielsm: grats on making developer tho :>
15:21:00  <frosch123> why is the 0.4 branch newer than the 0.4.5?
15:21:33  <Alberth> people continued making patches for 0.4.6 ?
15:22:34  <frosch123> i mean there is a 0.4 branch and a 0.4.5 branch
15:22:42  <frosch123> 0.4.5 had a separate branch for some reason
15:22:56  <frosch123> while 0.4.6 was again done from 0.4 brnach
15:23:12  <Alberth> confusion on the used branch model I guess
15:23:18  <frosch123> i know thar 0.4.5 was more like 0.5
15:23:27  <frosch123> but i expected 0.4.6 from the 0.4.5 branch
15:24:02  <Alberth> and never update 0.4.5, thus
15:27:42  <frosch123> so, i merged all the release/* rules
15:27:52  <frosch123> i'll keep master separate for now
15:28:04  <frosch123> not sure whether that may get different rules
15:28:07  <Alberth> does "branch protection" even work?  says it rericts pushing to a branch, but what if you make a new branch?
15:28:40  <Alberth> ie I can't push to master, but I can push "mymaster" on top of master
15:28:51  <frosch123> yes, that's exactly the problem we had here :)
15:28:58  <frosch123> i think we would need a rule "*"
15:29:05  <frosch123> but gh does not allow overlapping rules
15:29:25  <frosch123> and the master rule is actually different from the release rule
15:30:02  <Alberth> that makes all branches restricted, but I am not pushing to an existing branch
15:30:27  <Alberth> I make a new branch
15:31:03  <frosch123> no idea
15:31:09  <frosch123> maybe it is considered easy to fix
15:31:14  <frosch123> just deleting the branch
15:31:20  <frosch123> (which i already did)
15:32:12  <andythenorth> does "for i in range(len(value.values) / 3):" choke on floats?
15:32:14  <Alberth> yeah, so perhaps they assume you wouldn't give developer rights
15:32:19  * andythenorth should know, after 10 years of python
15:32:31  <Alberth> yes, / in python3 is always a float
15:32:34  <Alberth> use //
15:33:51  <Alberth> don't you want a range with a stepsize of 3 ?
15:33:56  <andythenorth> not sure
15:34:01  <andythenorth> I'm just trying to make it run :)
15:34:12  <andythenorth> my competency here is below what's needed :P
15:34:14  <Alberth> fair enough :)
15:34:48  <Alberth> but yeah, / got changed from 2 to 3
15:35:07  <andythenorth> ok these are my patches so far
15:36:33  <frosch123> nielsm: <- please add a separate push-url to your git config
15:38:38  <andythenorth> hmm
15:40:00  <nielsm>  <- should be safe now
15:41:07  <andythenorth> tile acceptance flag isn't working yet
15:41:12  <andythenorth> checking for EBKAC again :)
15:46:13  <andythenorth>  3417 * 15	 00 09 04 01 FF AA 00 08 00 0D 00 12 01 11 00
15:46:17  <andythenorth> looks like prop 12 is 01?
15:46:23  <andythenorth> which is the expected value
15:47:27  <andythenorth> oh does it need to set a bitmask?
15:47:32  <andythenorth> is the expected value 2?
15:48:29  <frosch123> yes
15:48:41  <andythenorth> hmm
15:48:48  <andythenorth> the patch looks correct
15:48:53  <andythenorth>
15:49:01  <andythenorth> we specify flags as numbers, not the bitmask values
15:49:03  <frosch123> bit 0 is "cb26 needs random bits"
15:49:21  <frosch123> andythenorth: yes, your nml code need to have "bitmask(...)"
15:49:32  <andythenorth> ok EBKAC
15:54:23  <andythenorth> ok prop 2 is now set in the nfo
15:54:36  <andythenorth> prop 12, bit 1 set, I mean
15:54:44  <andythenorth> words
15:55:29  <andythenorth> nielsm: have you tested prop 12 special flag for tiles?
15:55:30  <andythenorth> o_O
15:58:23  <andythenorth> I've cleared the tile acceptance in 0A, 0B, 0C, and set the flag
15:58:29  <andythenorth> it's accepting 3 cargos, but 5 are set
16:21:08  <nielsm> the "accepts everything" flag? yes that one works
16:24:28  <andythenorth> hmm what do I do wrong :)
16:24:29  <andythenorth>  3405 * 15	 00 09 04 01 FF AA 00 08 00 0D 00 12 02 11 00
16:24:29  <andythenorth> prop 12 is now 02
16:24:58  <andythenorth>
16:25:18  <andythenorth> and props 0A / 0B / 0C aren't set
16:52:17  <frosch123> i see, no need to find new names for different harbors
16:56:42  *** snail_UES_ has joined #openttd
16:59:33  <andythenorth> also more chance of them being place
16:59:40  <andythenorth> placed *
16:59:59  <andythenorth> harbours can currently ruin a map
17:00:33  <andythenorth> too few of one type, or awkward locations
17:08:53  *** ToBeFree has joined #openttd
17:13:36  *** ToBeFree has joined #openttd
17:24:46  *** chomwitt has joined #openttd
17:46:59  *** Alberth has left #openttd
17:56:22  *** ToBeFree has quit IRC
18:00:00  *** KouDy has joined #openttd
18:04:43  <andythenorth> trying to understand
18:04:57  <andythenorth> is capping to 3 here for the legacy support?
18:08:40  *** AndroUser2 has quit IRC
18:09:01  <nielsm> yes
18:10:35  <nielsm> or rather, there are no new callbacks for tile accepts, so the old callbacks can only supply 3
18:13:27  <andythenorth> and MemSetT is where we put up to 16?
18:13:54  <andythenorth> maybe not
18:14:48  <andythenorth> INDTILE_SPECIAL_ACCEPTS_ALL_CARGO     = 1 << 1 is to read the second bit?
18:14:54  * andythenorth is such a noob :P
18:15:02  <nielsm> yes
18:15:50  <andythenorth> trying to reverse engineer if anything is missing in my nfo
18:18:42  *** AndroUser2 has joined #openttd
18:19:52  <andythenorth> in-game debug tools don't include tile flags
18:22:59  <andythenorth> this is the tile nfo
18:23:07  <andythenorth> it's in 2 blocks because that's how nml inserts the cb flag
18:23:37  <andythenorth> I wondered if prop 8 being 0 is a problem, but shouldn't be
18:23:50  <andythenorth> 0D is land shape
18:24:01  <andythenorth> 11 is triggers for cb25
18:24:09  <andythenorth> 0E is the cb flags
18:24:19  <andythenorth> and 12 is special flags
18:30:37  <snail_UES_> michi_cc: I tried your corrected patch for 90-degree curves and it works
18:31:17  <snail_UES_> i.e. railtypes that are supposed to allow tight curves do allow them, and those that don’t actually forbid them
18:31:45  <snail_UES_> pathfinder seems to work correctly as well… anything specific you might think of I should check further?
18:39:28  <peter1138> Why is it a railtype option? o_O
18:43:25  <michi_cc> snail_UES_: Nothing except support from other devs :)
18:45:07  <snail_UES_> michi_cc: heh, got it...
18:45:37  <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.
18:45:59  <nielsm> andythenorth, sorry can't really look into anything more right now, I have a growing headache and looking at monitors is painful
18:46:09  <michi_cc> The allow flag is a lot less problematic as doesn't surprisingly breaks layouts.
18:46:11  <andythenorth> np :)
18:46:24  <andythenorth> nielsm: I just don't want to forget it all by september :)
18:46:28  <andythenorth> after all our holidays
18:46:40  <andythenorth> it's near done, but I have git stash patches :P
18:46:45  <snail_UES_> michi_cc: so we could only have an “allow” flag that overrides the OTTD main setting and allows sharp curves
18:46:51  <snail_UES_> it would be OK with me
18:47:17  <andythenorth> doesn't this need to be inverse boolean matrix thing?
18:47:24  <andythenorth> isn't the point to over-ride player settings?
18:49:06  <andythenorth> so if player has forbid, set allow
18:49:12  <andythenorth> and if player has allow, set forbid
18:49:13  <andythenorth> no?
18:56:08  <peter1138> Why does the player's setting need to be ignored?
18:56:21  <peter1138> Why do we need this flag?
19:00:59  <snail_UES_> peter1138: we need it to give an advantage to railtypes such as narrow gauge, which in reality could do sharper curves
19:01:13  <snail_UES_> andythenorth: inverting the player setting would miss the point…
19:01:52  <andythenorth> eh?
19:01:52  <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
19:02:08  <andythenorth> but there's no advantage if user allows sharp curves
19:02:15  <andythenorth> so it needs to invert user setting
19:02:22  <andythenorth> in fact, just ignore user setting
19:02:25  *** Gja has joined #openttd
19:02:45  <snail_UES_> andythenorth: yes, the point is to ignore the user setting for certain railtypes
19:04:00  <andythenorth> so if user setting is 'allow', then railtype inverts
19:04:08  <andythenorth> and if 'disallow' then railtype inverts
19:04:24  <snail_UES_> andythenorth: it would be pointless to disallow sharp curves for narrow gauge railtypes
19:04:28  <andythenorth> in fact, why not just remove user setting?
19:04:47  <snail_UES_> andythenorth: as I said, this is about giving NG an in-game advantage
19:04:58  <snail_UES_> in reality, narrow gauge rails have sharper curver
19:05:20  <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
19:06: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 :)
19:08:14  <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
19:10:54  <frosch123> why don't you improve the curve-speed-bonus/penalty property for a larger range or something?
19:11:09  <snail_UES_> frosch123: because NG trains are already very slow
19:11:24  <snail_UES_> they’re trains running at 50-60km/h in general, so they already don’t slow down much around curves
19:16:29  <andythenorth> snail_UES_: I don't get it :)
19:16:47  <snail_UES_> andythenorth: ok, what part don’t you get?
19:16:52  <andythenorth> it's not an advantage if player enables 90 degree
19:16:59  <andythenorth> so you need to also forbid 90 degree
19:17:09  <andythenorth> for other types
19:17:18  <andythenorth> i.e. remove player setting, force it in newgrf
19:17:25  <snail_UES_> yes, but Michi just said this would be more problematic
19:17:59  <snail_UES_> if forbidding 90 degrees is more difficult, then even just allowing 90 degrees for certain types would be an acceptable result
19:18: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
19:18:29  <andythenorth> seems like quite a bit of work for not a lot of result :)
19:19:02  <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.
19:19:04  <snail_UES_> andythenorth: work is done...
19:19:12  <andythenorth> but what will the setting say in game?
19:19:23  <andythenorth> 'forbid 90 degrees unless the railtype allows it' ?
19:19:35  <andythenorth> or is it a tri-state setting now?
19:19:48  <LordAro> that sounds a bit silly
19:20:06  <snail_UES_> the in-game setting would remain unchanged
19:20:25  <LordAro> why would you want grfs to be able to override a game setting?
19:20:38  <snail_UES_> LordAro: for what I described before…
19:21:03  <snail_UES_> that I might want to give an advantage to a certain railtype, which I can’t do now
19:21:17  <LordAro> i don't see that as a valid reason
19:21:53  <snail_UES_> why not? in reality, having sharper curves was actually one of the motivations to build narrow gauge instead of standard
19:21:57  <snail_UES_> the other was cost
19:22:24  <LordAro> OTTD is not real life
19:22:35  <andythenorth> the setting description has to change
19:22:36  <LordAro> sharper curves are one thing, 90 degree sudden turns are not
19:22:41  <andythenorth> can't have a setting that isn't a setting eh
19:22:43  <LordAro> s/not/another/
19:22:48  <andythenorth> it just causes bug reports
19:22:53  <andythenorth> and angry server owners
19:23:04  <andythenorth> I would just bin the setting tbh
19:23:07  <andythenorth> we have too many
19:23:13  <andythenorth> do it in content
19:23:21  <snail_UES_> andythenorth: I wouldn’t disagree with your idea
19:23:40  <snail_UES_> bin the setting and let single tracksets define whether 90-degree curves are allowed or not
19:24:01  <LordAro> that will cause more confusion
19:24:42  <snail_UES_> there could be a default behavior
19:24:47  <LordAro> even so
19:25:08  <LordAro> "i can create tracks with 90 degree turns with x railtype, but not with y"
19:25:12  <andythenorth> we could call it OpenTTD Revolution
19:25:17  <andythenorth> remove lots of settings
19:25:30  <snail_UES_> LordAro: why not?
19:25:36  <LordAro> or, depending on how it is implemented, "i upgraded my tracks and now they don't go past the 90 degree turn"
19:26:27  <snail_UES_> LordAro: again, why not? we already have something like this if I upgrade tracks with a different electrification system
19:26:37  *** AndroUser2 has quit IRC
19:26:48  <snail_UES_> “I upgraded my tracks to highspeed and now my 3rd rail trains won’t run there anymore”. We’re there already
19:26:59  <snail_UES_> so this is not a valid reason to shoot this proposal down
19:27:19  <LordAro> apart from the fact that it would increase the number of said reports
19:28:51  <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
19:29:12  <snail_UES_> of course it could be misused, but then again, so could any other feature or option
19:29:13  *** Supercheese has joined #openttd
19:29:59  <andythenorth> is it not just tri-state instead of boolean?
19:30:08  <andythenorth> 90 degree: allow, forbid, delegate to newgrf?
19:30:30  <snail_UES_> andythenorth: we could even do that
19:34:17  *** glx has joined #openttd
19:34:17  *** ChanServ sets mode: +v glx
19:35:43  *** AndroUser2 has joined #openttd
19:37:46  <andythenorth> I am potato / potato
19:38:00  <andythenorth> I would rather find another way
19:38:10  <andythenorth> not my decision anyway
19:38:19  <andythenorth> it's $someone, because no-one is in charge :)
19:42:22  <snail_UES_> andythenorth: potatoes in FIRS?
19:43:06  <andythenorth> what else could distinguish NG?
19:43:35  <snail_UES_> low costs, low speed and capacity…
19:43:48  <andythenorth> currently it's nerfed
19:44:01  <andythenorth> if it's at all realistic, it has lower capacity per tile
19:44:30  *** Happpy has joined #openttd
19:44:34  <andythenorth> so it would need to be so cheap
19:44:42  *** Gja has quit IRC
19:44:49  <snail_UES_> lower capacity and lower costs by tile
19:45:17  <andythenorth> wondering about maintenance cost, but I don't use them
19:45:26  *** Happpy has left #openttd
19:45:34  <snail_UES_> maintenance costs are also lower than SG
19:46:51  <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
19:46:57  <nielsm> so that's not unrealistic at least
19:47:30  <nielsm> not sure whether sleepers, ballast, and whatever else makes up the track bed is different
19:47:37  <snail_UES_> nielsm: yes, that’s the point. So tracks are cheaper
19:48:08  <snail_UES_> older tracks were built with a mix of sand and pebbles, and wooden sleepers of not so high quality
19:48:15  <snail_UES_> so the final result was cheaper
19:48:49  <snail_UES_> and the narrower gauge allowed for sharper curves, so they were used especially on mountain lines
19:50:07  <andythenorth> tbh
19:50:17  <andythenorth> realism is no help to me here for Iron Horse
19:50:33  <andythenorth> fundamentally, it's a tile based game with a capacity-per-tile :)
19:50:35  <snail_UES_> does IH have different gauges?
19:50:38  <andythenorth> yers
19:50:53  <snail_UES_> so this proposal could help you as well :)
19:50:56  <andythenorth> no
19:51:04  <andythenorth> I always allow 90 degree curves
19:51:12  <snail_UES_> ah… ok
19:51:17  <andythenorth> the problem of NG is that the capacity-per-tile is nerfed
19:51:22  <snail_UES_> but it would help other players who don’t
19:51:50  <snail_UES_> andythenorth: but then your NG vehicles and tracks should be significantly cheaper
19:51:51  <andythenorth> IRL NG simply takes up less space
19:52:06  <andythenorth> whereas in-game it still uses a whole tile
19:52:17  <snail_UES_> correct
19:52:18  <andythenorth> OpenTTD is primarily a tile-contention game
19:52:26  <andythenorth> at least for smaller maps and advanced games
19:52:45  <andythenorth> maybe NG should just be trams
19:52:52  <andythenorth> possibly the correct solution
19:53:14  <nielsm> but you can't build road vehs from parts
19:53:18  <snail_UES_> andythenorth: that would give them huge disadvantages...
19:53:31  <snail_UES_> you couldn’t have horizontal or vertical tracks…
19:53:43  <snail_UES_> and only 90-degree curves
19:53:46  <andythenorth> can we have smaller tiles?
19:53:48  <andythenorth> o_O
19:54:01  <snail_UES_> andythenorth: that is the question :D
19:54:06  <andythenorth> can we have multi-track station tiles?
19:54:21  <andythenorth> can we have state machine depots that allow 1-in-1-out at once
19:54:28  <andythenorth> instead of contending the entrance?
19:54:43  <andythenorth> can we have auto-PBS on bridges, so that trains can safely follow even without a signal?
19:55:30  *** cHawk has joined #openttd
20:03:34  <AndroUser2> Hey all
20:03:47  *** AndroUser2 is now known as DanMacK
20:04:11  <DanMacK> Much better
20:05:15  <DanMacK> Query andythenorth
20:05:23  <andythenorth> yo DanMacK
20:05:52  <Wolf01> So it was him all the time :D
20:06:17  <DanMacK> Yeah... androirc decided to log me in
20:09:33  *** KouDy has quit IRC
20:10:44  <DanMacK> !seen
20:10:57  <DanMacK> So that doesnt work lol
20:11:07  <LordAro> not in this channel
20:11:14  <LordAro> and not like that anyway :p
20:11:21  <LordAro> @seen DanMacK
20:11:21  <DorpsGek> LordAro: DanMacK was last seen in #openttd 23 seconds ago: <DanMacK> So that doesnt work lol
20:11:49  <DanMacK> @seen Pikka
20:11:49  <DorpsGek> DanMacK: Pikka was last seen in #openttd 8 weeks, 6 days, 10 hours, 53 minutes, and 52 seconds ago: <Pikka> oops
20:27:01  <peter1138> Yeah, where did he go?
20:32:11  <FLHerne> The root-cause fix for many of these "[x] is useless/non-differentiated" problems would be to somehow make costs meaningful...
20:32:31  <FLHerne> Being infinity times cheaper is still meaningless when you have unlimited money
20:33:11  <FLHerne> Can just turn the base-costs up massively, but then people lose instead
20:33:18  <andythenorth> where *did* he go
20:33:21  <FLHerne> Non-linear infra costs work
20:33:29  <FLHerne> Just not enough
20:35:18  <andythenorth> costs are irrelevant
20:35:29  <andythenorth> the real significant thing is tile contention :)
20:35:40  <andythenorth> that's why RVs are so different to trains
20:35:41  <andythenorth> etc
20:35:49  <FLHerne> Well, yes, that's what I'm complaining about :P
20:36:05  <andythenorth> so more transport types :P
20:36:07  <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)
20:36:12  <andythenorth> or mess with routing or something
20:36:13  <FLHerne> Capital costs are functionally 0, because everyone has infinite money
20:36:52  <FLHerne> So the only constraints on what you can build are time, map space and imagination, which is silly
20:37:13  <FLHerne> Well, it's fun until the imagination runs out...
20:38:26  <nielsm> shouldn't maintenance costs of vehicles also rise as they age, so an old fleet is significantly more expensive than a new one
20:38:43  <nielsm> (but the costs of replacing everything all the time should be even worse)
20:39:01  <FLHerne> Eh
20:39:19  <FLHerne> I don't think the current balance of /costs/ is too bad
20:39:30  <FLHerne> Most things seem to be vaguely in proportion
20:39:45  <andythenorth> the scarce resource is tiles
20:39:56  <andythenorth> especially as cities grow, or at busy industry
20:40:30  <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
20:40:53  <andythenorth> money is not the correct scarcity resource :)
20:41:16  <FLHerne> andythenorth: ...and so NG rail is useless, because it's not optimised for that one meaningful resource
20:41:18  <andythenorth> adding tech tree might actually help
20:41:24  <andythenorth> then vehicles are scarce
20:41:37  *** Supercheese has quit IRC
20:41:43  <FLHerne> Tech tree would be fun
20:41:54  <FLHerne> Or those vehicle factories that people proposed
20:41:59  *** Supercheese has joined #openttd
20:42:17  <nielsm> maximum number of vehicles that can be purchased over a time period
20:42:21  *** frosch123 has quit IRC
20:42:33  <FLHerne> "Produces one locomotive per month when supplied with >200tons of Metal"
20:43:14  <nielsm> to somewhat simulate production/delivery time on vehicles without actually delaying the player getting control after clicking buy
20:43:19  <FLHerne> Except then every industry/vehicle set would need pairing, or some really weird interface
20:43:35  <andythenorth> NG could be unlocked on the tech tree
20:43:57  <andythenorth> whereas bigger trains would require more research / gold / dragons teeth / whatever
20:44:16  <andythenorth> and we decouple any IRL dates
20:44:22  <andythenorth> because all nonsense
20:44:27  <FLHerne> No thx
20:44:29  <nielsm> isn't that kinda like maschinky or however it's spelled?
20:44:47  <andythenorth> dunno
20:44:49  <FLHerne> You can tear my pseudo-accurate BR train progression from my cold dead hands
20:45:01  <andythenorth> well you just script a tech tree for that
20:45:04  <andythenorth> it's fine
20:45:07  <andythenorth> tech tree scriprt
20:45:58  <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
20:46:27  <FLHerne> If buying vehicles required cargo being delivered to an industry, availability could be governed by cargo chains...
20:46:40  <nielsm> and you have to choose two of cheap, powerful, reliable
20:47:07  <FLHerne> i.e. you can't deliver CoolTechStuff to make maglevs until you've got vehicles that can carry CoolTechStuff
20:47:49  <FLHerne> And those need SemiInterestingStuff to make, and so forth
20:48:28  <FLHerne> With 64 cargos, and umpteen cargoes-per-industry, you can force players through a /really/ insane cargo production graph
20:48:39  <FLHerne> [/nutso idea]
20:49:05  <andythenorth> tech tree
20:49:09  <andythenorth> unlock goals
20:49:23  <FLHerne> "goals"?
20:49:43  *** sim-al2 has joined #openttd
20:49:45  <andythenorth> GS innit
20:49:51  <nielsm> we did talk a bit about some kind of game script interface the other day
20:50:00  <nielsm> to let GS control vehicle availability
20:51:39  <FLHerne> SO is the next patch for 64 GSes per game? :P
20:52:04  <FLHerne> (but seriously, more than one would be nice, there are so many orthogonal uses for them)
20:55:38  <andythenorth> they would conflict
20:55:39  <andythenorth> but yes
21:17:55  *** andythenorth has left #openttd
21:39:32  *** KouDy has joined #openttd
21:42:30  *** AndroUser2 has joined #openttd
21:42:31  *** DanMacK has quit IRC
21:53:16  *** AndroUser2 has quit IRC
21:54:24  *** AndroUser2 has joined #openttd
22:02:31  *** Wormnest has quit IRC
22:50:44  *** Progman has quit IRC
22:59:03  *** snail_UES_ has quit IRC
22:59:40  *** snail_UES_ has joined #openttd
23:06:46  *** nielsm has quit IRC
23:06:53  *** Thedarkb-T60 has joined #openttd
23:12:35  *** AndroUser2 has quit IRC
23:13:05  *** AndroUser2 has joined #openttd
23:13:35  *** Thedarkb-T60 has quit IRC
23:14:06  *** Thedarkb-T60 has joined #openttd
23:19:40  *** APTX_ has quit IRC
23:34:37  *** AndroUser2 has quit IRC
23:34:49  *** AndroUser2 has joined #openttd
23:36:59  *** APTX_ has joined #openttd
23:49:52  *** Wolf01 has quit IRC

Powered by YARRSTE version: svn-trunk