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