IRC logs for #openttd on OFTC at 2018-12-21
⏴ go to previous day
00:03:07 <Samu> when I get the name of a bridge, AIBridge.GetName(old_bridge)
00:03:27 <Samu> I always end up with the rail version of the name, even though the bridge is road
00:12:18 <Samu> it's only a naming issue
00:12:23 <Samu> the bridge is actually road
00:16:58 <LordAro> (the transport_name[0])
00:17:24 <LordAro> probably wants some sort of optional boolean parameter adding to that function
00:43:51 *** smilesdude98 has joined #openttd
01:20:06 <Samu> what about trams, how the bridge named?
01:24:45 <Samu> "Note: The speed is in OpenTTD's internal speed unit. This is mph / 1.6, which is roughly km/h. To get km/h multiply this number by 1.00584. "
01:25:23 <Samu> it's ((1 * 10 * 103) >> 6) / 16
01:25:39 <Samu> @calc ((1 * 10 * 103) >> 6) / 16
01:25:39 <DorpsGek> Samu: Error: Something in there wasn't a valid number.
01:26:18 <Samu> @calc ((1 * 10 * 103) / 64) / 16
02:17:22 <Samu> aqueduct bridges are named Wooden rail bridges too
02:18:41 <LordAro> Samu: sounds like you have some issues to file
02:22:06 *** m1cr0man has joined #openttd
02:30:09 <Samu> GetBridgeSpec->transport_name is only road and rail, doesn't include water?
02:40:05 <Samu> is the name I get for aqueducts atm
03:27:29 <Samu> looks like #include "table/strings.h" solves my issue
05:14:44 *** Mahjong2 has joined #openttd
07:39:41 *** Wacko1976 has joined #openttd
08:47:47 *** Mahjong has joined #openttd
09:08:06 *** tokai|noir has joined #openttd
09:08:06 *** ChanServ sets mode: +v tokai|noir
09:31:51 *** andythenorth has joined #openttd
10:29:28 *** Progman has joined #openttd
10:44:15 <andythenorth> so in nml, what is 'shorten_vehicle' ?
10:53:39 <Flygon> It's the counterpart to 'scomo_vehicle', the bus that traverses Queensland.
10:53:43 <Flygon> (Sorry. Awful. I know.)
11:34:05 *** Alberth has joined #openttd
11:34:05 *** ChanServ sets mode: +o Alberth
11:42:04 <Alberth> quite useful pictures to add to firs docs perhaps
11:42:35 <andythenorth> could use it's own page
11:43:05 <Alberth> note sure why the cursor tile is outside the industry building, seems a bit weird?
11:43:19 <andythenorth> there are water tiles
11:43:23 <andythenorth> to ensure clearance
11:43:36 <Alberth> oh right, makes sense
11:43:58 <andythenorth> sometimes I wonder about some kind of industry layout preview
11:44:14 <Alberth> I was wondering about that too currently :)
11:44:50 <Alberth> in the place-object code somewhere
11:45:17 <Alberth> I once messed in reorganizing that, not sure if it ever got committed
11:46:55 <LordAro> Alberth: am good, christmassing it up. you?
11:48:00 <Alberth> quite good, burning free days from work before the year ends :)
11:48:46 <Alberth> not quite in christmas mood, but that's usual the case
11:49:56 <Alberth> and warm temperatures, and only a single morning some snow doesn't help
11:50:45 <Alberth> I wrote some docs about the servers, TB is likely busy?
11:51:32 <andythenorth> I am slightly christmasy
11:51:37 <andythenorth> but not as much as I wanted
11:51:55 <Alberth> more jingle bells music needed :)
11:52:03 <Alberth> busy with the end of the year I guess
11:53:43 <andythenorth> I keep trying to achieve OpenTTD things as I have a day or two spare, and find I'm blocked :)
11:55:02 <andythenorth> the problem with improving things is that lots gets broken :)
11:55:18 <andythenorth> not on a Friday, games are full of drunks
11:55:40 <Alberth> oh, yes, improving is always a disaster
11:56:01 * andythenorth wonders which nml repo we're using now
11:56:05 <andythenorth> as there are two
11:57:07 <Alberth> the openttd github one and the devzone one?
11:57:19 <Alberth> yes, I'd assume that too
11:59:03 <andythenorth> oh the issues aren't moved
12:00:00 * andythenorth adds a news item
12:01:59 <andythenorth> I guess the intent is to script moving the issues
12:02:42 <Alberth> script would be useful, assuming more devzone stuff will be moved?
12:02:53 <andythenorth> that was frosch's plan
12:03:06 <andythenorth> ha, all I was trying to do was write a test case for a possible bug
12:03:13 <andythenorth> but of course, bureaucracy
12:09:14 <planetmaker> good point about those news, andythenorth !
12:09:37 <planetmaker> And yes, more of that stuff should be moved. At best probably all...
12:09:51 <planetmaker> would make some things a lot easier
12:14:38 <planetmaker> grfcodec ... would want to get moved, too
12:14:54 <planetmaker> and OpenGFX, I'd think
12:40:00 *** andythenorth has joined #openttd
12:41:08 <Alberth> andy: industry preview may be tricky, currently, it's only drawn after placement, so the newgrf can query the specific tiles
12:41:42 <andythenorth> pre-composed sprite has been suggested
12:41:53 <andythenorth> all that's needed is the tile layout, similar to airports
12:42:02 <planetmaker> basically like bridges have a sprite in the selection menu?
12:42:11 <planetmaker> or airports view pre-view?
12:42:13 <andythenorth> but I never thought of a way to cycle through the layouts
12:42:21 <Alberth> for all orientations, ie adapting to height diferences etc?
12:42:29 <andythenorth> all we really need to know is 'valid location or not?'
12:42:34 <planetmaker> that sounds too complicated, @Alberth
12:42:53 <planetmaker> airports are simpler in their view.... just a fixed choice of layouts. Easy to draw
12:44:52 <Alberth> a list of available configurations, and possibly some code deciding yes/no would be most useful
12:45:45 <Alberth> already "would it be buildable here" is not available :(
12:46:32 <planetmaker> it would simply mean to run the building code on the current cursor location
12:46:33 <Alberth> we need a newnewgrf :p
12:46:38 <planetmaker> could possibly be automated
12:46:39 <andythenorth> planetmaker: any idea what 'shorten_vehicle' is? o_O
12:46:56 <planetmaker> andythenorth, yes. lengths different than 8/8
12:47:57 <planetmaker> I thought you use it already a lot? :)
12:48:26 <andythenorth> it's not in the docs :)
12:48:27 <planetmaker> it's the vehicle-length callback
12:48:41 <Alberth> nah, the generator eons ago written by andy does :)
12:49:40 <planetmaker> ah, yes. Called 'length' now
12:51:33 <planetmaker> so... where is shorten_vehicle used still? :D
12:51:58 <andythenorth> then I can try and replicate the broken sprite stack issue
12:52:02 <andythenorth> one thing at a time :P
12:57:40 <andythenorth> looks like I can approve my own work, that's....interesting :)
12:57:53 * andythenorth hasn't approved it
13:16:48 <Eddi|zuHause> i'm getting some annoying freezes in TF, i don't remember those from before... :/
13:21:09 <planetmaker> hm, I guess I get again a notice from frosch that I abandoned all commit message styles now with NML :P
13:21:29 <planetmaker> it should get the commit message hook like OpenTTD
13:25:29 * andythenorth tries to remember how to make a train in nml :P
13:25:35 <andythenorth> been a long time since I did this
13:28:20 *** Lejving has joined #openttd
13:29:04 * andythenorth finds a bunch of 'new' nml properties
13:29:11 <andythenorth> 'extra_weight_per_wagon' eh? o_O
13:29:17 <andythenorth> and something about powered wagons
13:30:44 <andythenorth> so many possibilities :P
13:39:14 <andythenorth> I am really bad at nml :P
13:57:46 *** HerzogDeXtEr has joined #openttd
14:11:27 <andythenorth> the bug must be in Horse
14:40:52 <planetmaker> andythenorth, feel free to ignore my comment and merge it nonetheless :)
15:02:18 *** sla_ro|master has joined #openttd
15:33:53 *** chomwitt has joined #openttd
15:54:19 <andythenorth> I have spent hours now trying to figure out why sprite stack doesn't work for articulated vehicles in Iron Horse
15:54:19 <andythenorth> it works in the nml test case
15:54:39 <Eddi|zuHause> it'll be a trivial typo somewhere
15:54:47 <Eddi|zuHause> or compiling the wrong codebase
15:55:39 <andythenorth> that's what I expected
15:56:41 <andythenorth> or testing the wrong grf :P
15:56:41 <andythenorth> it works for non-articulated vehicles
15:56:41 <andythenorth> it works for units of articulated vehicles which have a different ID to lead vehicle
15:56:41 <andythenorth> but it doesn't work for lead unit of an articulated vehicle, or any other unit sharing that ID
15:56:41 <andythenorth> the extra layers are simply not drawn
15:56:49 * andythenorth wonders if register 100 is blitzed by something else
15:57:10 <andythenorth> I'm still favouring type, but it's all the same template
15:58:38 <andythenorth> I wondered if nml was writing the flag wrong
15:58:43 <andythenorth> but it seems to be correct
15:59:31 <Eddi|zuHause> * andythenorth wonders if register 100 is blitzed by something else <-- nml internal usage? i think we had such a case before
16:00:00 <andythenorth> I am trying to isolate it
16:00:07 <Eddi|zuHause> you could try looking at the nfo output
16:03:10 <andythenorth> the action 0 props look correct, but reading the varaction 2 is :(
16:03:45 <andythenorth> hmm, FORWARD_SELF(0) is in the non-working graphics chain
16:03:45 <andythenorth> but not the working one
16:03:45 <andythenorth> let's remove that
16:04:31 <Eddi|zuHause> that sounds right
16:04:40 <andythenorth> # cannot rely on returning FORWARD_SELF(0), it causes register 0x100 to be read and cleared, where 0x100 is needed for graphics layers
16:04:54 <Eddi|zuHause> allowed values are 1-15 if you want to keep 0x100
16:05:20 <andythenorth> I have read nfo output, nml src, openttd src, I made an nml test case
16:05:22 <andythenorth> and I read nearly all my own src
16:05:36 <andythenorth> and then I find that I've solved this before :P
16:05:38 <andythenorth> always the last place you look
16:06:16 <Eddi|zuHause> well, as soon as you said 100, i thought of exactly that...
16:06:54 <andythenorth> I found it by diffing working + non-working nml
16:07:06 <andythenorth> now I have to figure out how to fix it :P
16:07:53 <Eddi|zuHause> i don't know anything about the layer stuff
16:08:33 <andythenorth> FORWARD_SELF(x)...Uses register 0x100 if x is not a constant expression between 1 and 15
16:08:40 <andythenorth> so I just don't set x=0
16:09:24 <Eddi|zuHause> yes, x=0 means "use value of 0x100"
16:13:36 <andythenorth> one step closer to done
16:14:29 <andythenorth> merge NRT next? :P
16:21:19 *** andythenorth is now known as Guest719
16:21:19 *** andythenorth has joined #openttd
16:22:55 <Eddi|zuHause> how does merging NRT progress horse?
16:23:16 <andythenorth> sometimes projects need a break
16:23:33 <andythenorth> and people doing them need less overall to-do list
16:23:49 <andythenorth> and fewer shells with unresolved merge conflicts in them :P
16:24:50 * andythenorth could just close the shells and all the browser tabs
16:35:34 *** quiznilo has joined #openttd
16:50:00 <Samu> forgot how to create a brach :(
16:50:23 <Samu> do i make the changes first, then create a branch, or do I branch first, then i make the changes in it?
16:51:48 <andythenorth> doesn't matter, but usually make the branch first
16:54:26 <Samu> one other thing, how do i make the old APIs compatible to the updated changes?
16:54:45 <Samu> "compatibility mode in effect" thingy
16:55:47 <Samu> from this: static char *GetName(BridgeID bridge_id)
16:55:50 <Samu> to this: static char *GetName(BridgeID bridge_id, ScriptVehicle::VehicleType vehicle_type);
17:11:13 <Zuu> Hello all and andythenorth :-)
17:11:21 <Samu> Zuu: are you the API expert?
17:11:33 <andythenorth> give him a minute
17:11:40 <andythenorth> he's been away for ages
17:11:48 <andythenorth> don't drive him away instantly with questions :P
17:12:12 <Samu> I tried to use zuu pathfinder in superlib, i failed :(
17:12:30 <Samu> so i went with copy pasting from roadpathfinder
17:13:42 <Samu> oh, cluelessplus has air support but it's not enabled by default, why's that?
17:14:10 <Zuu> I'd say you can use superlib pathfinder if you need a high level path finder or if it does the things the way you like it by default. But if you have other opinions or what to dig deep into details, you better probably roll your own pathfinder based on the plain pathfinder library.
17:14:59 <Zuu> I didn't get around to truely balance out air support in clueless plus. Aircraft tend to be more expansive while clueless logic work better with swarms of cheaper vehicles.
17:17:36 <Samu> compat_1.8.nut, 1.7, 1.6, etc.. do they belong to bin/ folder only, or are they generated from somewhere in src into the bin folder?
17:18:27 <Zuu> Yes keep them in the installation directory tree and don't put them in content_download or other shared places.
17:19:08 <Samu> hmm, so for the function I'm editing, i have to change all those from 0.7 to 1.8, isn't it? I'm not sure how to go at it
17:19:10 <Zuu> The compat files are provided by OpenTTD and correspond to a specific release/nightly version which is why they should not me copied/moved to shared folders.
17:20:01 <Zuu> You shall never edit the compat files yourself as a script author. Only if you write a patch (or pull request), you want to make changes in them.
17:20:07 <Samu> I'm trying to create a pull request, which changes AIBridge.GetName from taking 1 paramenter, to 2 parameters
17:21:10 <Zuu> In that case, when OpenTTD loads an AI or GS it looks which OpenTTD version it is made for and then it will load the compat file that relates to that version.
17:21:52 <Zuu> Eg. if I have an AI that is declared to work for 1.2, compat_1.2.nut is loaded. (and I think it is loaded before, but those details is beyond what I remember)
17:22:23 <Samu> I see, so i gotta add them all the way down to 0.7
17:22:41 <Zuu> Yep if 0.7 had AIBridge.GetName it has to be in each file down to 0.7 I think.
17:23:38 <Zuu> Because I don't think they are layerd ontop of each other, but you can probably open the files and see if it looks like they are being layered ontop or not. Or just grep for "compat_" in OpenTTD source code to figure that out.
17:23:56 <Samu> i dunno how to make the conversion code
17:24:44 <Samu> i wanna take the old AIBridge.GetName(blabla) and make it call the new AIBridge.GetName(blabla, 0)
17:26:44 <Samu> not sure how to use the <- thingy
17:26:49 <Zuu> I think something along the lines of this:
17:26:50 <Zuu> _AIBridge_GetName <- AIBridge.GetName;
17:26:50 <Zuu> AIBridge.GetName <- functionb(blabla) {
17:26:50 <Zuu> _AIBridge_GetName(blabla, 0);
17:29:16 <Zuu> You can look it AIAI and myAPIpatch.nut for lots of API override magic :-)
17:30:43 <Zuu> Using AIBridge.GetName_ <- ... may be better to avoid conflicting with AI/GS namespaces.
17:31:17 <Zuu> But have a look in the existing compat files and chances are there is some convention already set on how to name it in the compat files?
17:32:25 <Zuu> In compat_1.2.nut it looks like it put the underscore first. So I'd go with that.
17:40:51 <Samu> AIBridge._GetName <- AIBridge.GetName; AIBridge.GetName <- function(bridge_id) { return AIBridge._GetName(bridge_id, AIVehicle.VT_RAIL); }
17:47:29 <Samu> AIVehicle.VT_RAIL must also exist in 0.7 right?
17:48:01 <Zuu> I beleive so as rail was supported originally.
17:48:20 <Zuu> You could see if any API accept it and was available in 0.7
17:48:54 <Zuu> But that's not the point.
17:49:14 <Zuu> The compat file is run by OpenTTD 1.9 which has AIVehicle.VT_RAIL.
17:49:54 <Samu> ah, nice, so in the case of GS, I have to use GSVehicle.VT_RAIL. probably
17:50:27 <Samu> boring, gotta eddit 15 or so compat.nut files
17:51:05 <Zuu> The new compat file you create should only be used by OpenTTD 1.9 and not older versions of OpenTTD. Because that would break as they don't know the second parameter. (which is why you shouldn't move compat files to shared folders)
17:51:58 <Zuu> Assuming it can go on the end you could do cat new_text.txt >> compat_0.7.nut etc.
17:52:26 <Zuu> Or do some clever find replace on the file ending symobology or similar.
17:58:23 <Samu> GSBridge._GetName <- GSBridge.GetName; GSBridge.GetName <- function(bridge_id) { return GSBridge._GetName(bridge_id, GSVehicle.VT_RAIL); }
18:06:56 <Samu> Change: AI/GS ScriptBridge::GetName takes one extra parameter to refer the vehicle type
18:14:22 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick opened pull request #6988: Change: AI/GS ScriptBridge::GetName takes one extra parameter to refer the vehicle type https://git.io/fhfaC
18:14:58 <Samu> already advertised here, heh
18:15:37 <andythenorth> but the docs might need expanded :P
18:15:40 <Samu> i didnt' test the compat modes other than AI 1.4
18:18:26 *** frosch123 has joined #openttd
18:20:57 <andythenorth> frosch123 nml's use of 0x100 rolled me again :P
18:22:28 <andythenorth> I'll make a test case for those
18:22:51 <andythenorth> I don't see any support there for vars 69-6F
18:24:35 <Samu> error: cannot initialize return object of type 'char *' with an rvalue of type 'bool'
18:24:47 <andythenorth> hmm, looks like nml still has a .hgignore :)
18:27:18 <Samu> visual studio never errors me in these parts, why the other compilers hate it ? :(
18:29:15 <Samu> error: cannot convert 'bool' to 'char*' in return
18:30:52 <nielsm> the "false" in EnforcePrecondition(false, morestuffhere) is the return value for the containing function
18:31:19 <nielsm> (I discovered this in 10 seconds by hovering over the use of EnforcePrecondition in visual studio to see the macro expansion)
18:31:34 <nielsm> and your ScriptBridge::GetName function has a return type of char*
18:31:46 <nielsm> so obviously the type is wrong
18:32:33 <nielsm> visual c++ might accept false because it can convert to integer 0, and integer 0 converts to nullptr which is a valid value for char*
18:32:59 *** Alberth has joined #openttd
18:32:59 *** ChanServ sets mode: +o Alberth
18:33:16 <nielsm> and it's probably a bug that visual c++ accepts it
18:34:01 <Samu> hmm if I don't use EnforcePreCondition, what do I do?
18:34:11 <nielsm> there's nothing wrong with using EnforcePrecondition
18:34:23 <nielsm> but you need to figure out what you want the function to return when the precondition fails
18:34:44 <Samu> well, default it to VT_RAIL then
18:35:08 <nielsm> you can't return false from a function that's declared to return a string, so you need to return an empty string or a nullptr or a string indicating an error
18:40:51 <Samu> EnforcePreconditionEncodedText
18:41:37 <nielsm> why do you think that would be correct at all?
18:41:51 <nielsm> EnforcePrecondition is the correct thing to use, but you're using it wrong
18:42:48 <Samu> how to i make it error out with precondition failed?
18:43:13 <nielsm> EnforcePreconditionEncodedText checks if a string type parameter is missing or empty and produces an error if it is, but you are not checking a string type parameter so it's incorrect
18:44:55 <Samu> EnforcePrecondition(NULL, vehicle_type == ScriptVehicle::VT_ROAD || vehicle_type == ScriptVehicle::VT_RAIL || vehicle_type == ScriptVehicle::VT_WATER);
18:45:18 <Samu> return NULL, much like the other above
18:46:56 <Samu> i don't see any enforce precondition with a NULL anywhere, it's awlays with a false
18:47:11 <nielsm> that's because all the other functions return bool
18:47:54 <nielsm> in script_goal.cpp you'll find some that return GOAL_INVALID rather than false
18:54:47 * andythenorth really wants to get the 16 industry support into nml
18:54:54 <andythenorth> and $stuff gets in the way :)
18:56:15 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #6988: Change: AI/GS ScriptBridge::GetName takes one extra parameter to refer the vehicle type https://git.io/fhfaC
18:56:33 <Samu> hmm, forgot how to rebase stuff
18:57:00 <andythenorth> dorpsgek doesn't know about the nml repo :P
18:57:08 <andythenorth> should I fix dorpsgek?
18:57:33 <Samu> ok, the NULL is there, so i guess I rebased this correctly, let's hope now the commit-dude likes it
19:00:37 <andythenorth> nielsm: can you remember where we got to with your nml patches? o_O
19:00:42 <andythenorth> my notes locally aren't great :P
19:00:48 <andythenorth> I think I tested all of them
19:01:54 <nielsm> uh, I think three properties implemented, one half-implemented (the input-output production rates one), and nothing done for callbacks or properties
19:02:00 <nielsm> is what I did at least
19:02:24 <andythenorth> I am going to assume all your patches are good :P
19:02:31 <andythenorth> and rebase to them in my branch
19:02:52 <nielsm> I think I might have syntax checked them, and nothing else :)
19:04:09 <andythenorth> I'm sure I tested and ran them
19:04:20 <andythenorth> and I need to write test cases against them so eh :)
19:06:58 <nielsm> I can help implement it, but I don't know the first thing about NML coding or what would be idiomatic ways to express the new things
19:07:23 <andythenorth> well planetmaker is here too :D
19:07:31 <nielsm> a target "want this to parse and generate this NFO" would be great to have
19:17:20 <Samu> regression test fail because... why?
19:17:28 <Samu> wrong number of parameters
19:19:06 <Samu> print(" GetName(): " + AIBridge.GetName(i));
19:19:18 <Samu> what is the API version used for the regression test?
19:19:33 <Samu> ah, that's why it failed
19:20:26 <Samu> how am I handling this peculiar situation :(
19:20:37 <nielsm> although I hope there are tests for all api versions
19:21:02 <nielsm> well you update the test so it still tests the function in full
19:21:18 <nielsm> or at least tests is sufficiently
19:22:06 <Samu> print(" GetName(): " + AIBridge.GetName(i, AIVehicle.VT_RAIL));
19:22:20 <Samu> this should equal the name of the file it's comparing to
19:22:30 <Samu> but there's also 2 other names now
19:22:46 <Samu> or, rather, the regression is not testing them
19:24:43 <Samu> if i make the regression test them, the results will differ yet, i have to also edit the results :(
19:24:53 <Samu> i'm unsure what's the best thing to do
19:32:00 <andythenorth> I need a recent build of ottd
19:32:04 <andythenorth> I'd better unbreak mine :(
19:34:11 <andythenorth> oof build is broken again
19:34:27 <andythenorth> src/ai/../rail_type.h:53:6: note: forward declaration of 'RailTypes'
19:34:28 <andythenorth> enum RailTypes : uint64 {
19:35:02 <andythenorth> oh I need to patch
19:35:39 <Samu> I'm going with the "tests it sufficiently" theory
19:37:42 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #6988: Change: AI/GS ScriptBridge::GetName takes one extra parameter to refer the vehicle type https://git.io/fhfaC
19:42:39 <andythenorth> wow FIRS code is bonkers
19:42:47 <andythenorth> soooooo much code
19:44:13 <Eddi|zuHause> the trick is to do the same thing with less code
19:45:45 <Samu> there's still a lack of distinction between road and tram for bridges
19:46:19 <Samu> a tram bridge is still named as a road bridge
19:48:01 *** Eddi|zuHause has joined #openttd
19:50:07 <andythenorth> ok I have an nml industry with prop 25 and 26 working, and the tile acceptance
19:50:13 <andythenorth> but the prod multiplier baffles me :)
19:50:19 <andythenorth> I think we got stuck on the format for that?
19:53:28 <andythenorth> nielsm: ^ what's the intended property format there? o_O
19:53:38 <andythenorth> I can at least make the test case use it :)
19:56:09 <peter1138> What was thet opensource github clone?
19:57:32 <peter1138> I think nielsm mentioned it.
19:58:56 <peter1138> Had CI and CF abilities.
19:59:07 <peter1138> Some hosted thing for open source projects
19:59:24 <peter1138> Sure but it wasn't gitlab
20:03:36 *** gelignite has joined #openttd
20:05:31 <Samu> one simple fix, required 24 files to be changed... annoying
20:09:58 <andythenorth> he found azure pipelines
20:10:02 <andythenorth> but that's different :P
20:10:54 <nielsm> andythenorth, the NFO format of the property?
20:10:55 <Samu> oh, the comment needs fixing too, lol
20:13:43 <nielsm> okay the second line comment is wrong, it's 5 props ;)
20:16:16 <andythenorth> I'm just puzzled by what the nml format is :)
20:16:31 <andythenorth> I think this is where we got stuck last time
20:17:29 <nielsm> what would you like the NML format to be?
20:17:51 <andythenorth> I'll just implement the test case as whatever is already doen
20:18:05 <nielsm> probably an array of arrays is the most sensible way to do it
20:18:19 <andythenorth> this is the replacement for props 1C-1E, which are stupid anyway :)
20:18:45 <andythenorth> if I read the python correctly, it expects an arrray of arrays
20:19:56 <andythenorth> oh I got a 'nope' :)
20:20:02 <andythenorth> nmlc ERROR: "example_industry.nml", line 40: Input multiplier must be an array with a multiple of 3 values
20:20:15 <andythenorth> input_multiplier: [[1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1]];
20:20:20 <andythenorth> I have 4 in / 4 out
20:22:51 <andythenorth> or I'm doing it wrong?
20:23:52 <nielsm> ahh, no that's for the old format
20:24:26 <nielsm> which was [input-cargo-slot, output-cargo-slot, multiplier] sequences
20:25:09 <nielsm> (those are "local" slots i.e. the order of input or output cargo types defined on the industry)
20:26:39 <andythenorth> so we need to update the nml patch for prop 28? o_O
20:29:36 <andythenorth> I'll write a test case for prop 27 meanwhile
20:35:57 <andythenorth> is IND_FLAG_LONG_CARGO_TYPE_LISTS needed if CBs aren't used?
20:36:11 <andythenorth> seems not to be needed for action 0 props
20:38:52 <nielsm> I think it's only required for those yes
20:40:31 * andythenorth wonders if we can just not support prop 28 in nml :P
20:40:40 <andythenorth> currently though, only the first cargo is produce
20:41:53 <andythenorth> should we change the default so it divides evenly over all output cargos?
20:42:45 <andythenorth> oh max out is capping to 3 for some reason
20:43:14 <andythenorth> what the hell is moreindustriesperclimate?
20:43:25 <andythenorth> Eddi|zuHause: ^ any idea? o_O
20:43:45 <nielsm> sounds like a ttdpatch thing
20:43:51 <Eddi|zuHause> sounds like an ancient ttdpatch option
20:43:52 <andythenorth> adds paper to temperate
20:43:52 <nielsm> probably no longer relevant
20:44:00 <andythenorth> I was trying to use that in my test case :P
20:44:31 <Eddi|zuHause> openttd most likely hardcodes these to always apply
20:45:05 <andythenorth> ok, the output cargos are fine, as long as author doesn't do stupid things
20:45:24 <andythenorth> ah the 'requires' in fund menu is interesting
20:45:42 <Zuu> Samu: edit 24 files to add an API. That is like what updating the API is. It is rewarding when it allow script authors to make new cool stuff, but the actual work is mostly binding different parts togeather which can be fun sometimes but also lot of small edits here and there. :-)
20:46:42 <andythenorth> string handling :)
20:46:43 <nielsm> looks like something was missed
20:47:52 <Zuu> Some new fancy goals? :-)
20:51:55 <Samu> made a typo in the comments
20:52:14 <Samu> "Other changes." should be "Other changes:"
20:53:46 <Samu> do i fix it? or it's not needed?
20:59:30 <nielsm> if you're changing the file anyway, go ahead
21:00:15 <Samu> giving more work to your servers
21:05:01 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #6988: Change: AI/GS ScriptBridge::GetName takes one extra parameter to refer the vehicle type https://git.io/fhfaC
21:07:34 <andythenorth> so 64 cargos, 16 in/out at industries, 64 railtypes, NRT
21:07:42 <andythenorth> so are we shipping 2.0 in April?
21:08:28 <nielsm> I think the version number is secretly the release year
21:10:37 <andythenorth> so 2.0 in 16 months time?
21:40:26 <Zuu> Wow 16 cargoes in/out to industries. :-)
21:41:03 <nielsm> maybe format the input multipliers across multiple lines as a matrix
21:41:36 <nielsm> clarifying that each row represents one input cargo, and each column is the amount of output
21:41:41 <Zuu> Are we still only having 2 companies transporting away from an industry, or is that per cargo?
21:42:08 <nielsm> I don't know, that hasn't changed
21:42:23 <nielsm> but I think it's determined per cargo which station gets it
21:42:34 <nielsm> * which stations get it
21:43:02 <Zuu> If it is per cargo, I think it is fine or at least no worse than before.
21:43:36 <Zuu> Is there any NewGRF planning to have any monster industries with that many cargoes?
21:44:40 <Zuu> nielsm: I like the matrix format and how it corresponds with an OD matrix. :-)
21:45:39 <andythenorth> Zuu: I'm not planning to have 16 in / 16 out
21:45:41 <nielsm> andythenorth has indicated working on a FIRS version with more cargoes
21:46:08 <andythenorth> unless station walking is used, it's ~impossible to get 16 cargos out with trains / RVs / planes
21:46:15 <andythenorth> only ships can do it
21:46:16 <nielsm> yeah using the full 16 in or 16 out won't be fun to play with, probably
21:46:19 <andythenorth> everything else will block
21:46:32 <Zuu> But you could have many in or many out.
21:46:40 <andythenorth> many in is easiest
21:46:43 <nielsm> the thought was that you may as well set the limit higher than someone will realistically want to use
21:46:45 <andythenorth> dropoff stations rarely block
21:47:02 <andythenorth> also could do a huge industry (many tiles) :P
21:47:13 <andythenorth> then more stations fit
21:47:18 <Zuu> 16x16 is that maximum size of industries?
21:47:32 <andythenorth> never pushed it that
21:47:35 <Zuu> IIRC there is some maximum in tiles.
21:47:42 <andythenorth> game can't build them if they're too big
21:47:45 <nielsm> I don't think industries actually have a maximum size
21:47:45 <andythenorth> no suitable locations
21:47:54 <nielsm> right that's one limitation :P
21:47:58 <andythenorth> there will be a town or transmitter or uneven ground
21:48:10 <andythenorth> so how do we change prop 28 then?
21:48:22 <andythenorth> I have failed to grok this entirely :)
21:48:39 <nielsm> I had an idea for making a feature where the newgrf industry supplies multiple possible sub-buildings and the game picks a random number of those sub-buildings and place separately, near the main building
21:48:58 <andythenorth> there's a variant of that using objects
21:49:06 <andythenorth> fields and stuff
21:49:20 <andythenorth> 'satellite locations'
21:49:25 <nielsm> objects won't accept cargo and produce stuff, will they?
21:49:41 <andythenorth> there is an idea that everything gets redone as objects, including stations
21:49:48 <andythenorth> but eh, smells of OneBigIdea
21:57:26 *** Wormnest has joined #openttd
21:58:43 <andythenorth> nielsm: shall we ignore prop 28?
22:11:41 <Zuu> Oh.. I crashed openttd on worldgen (last nightly from openttd.org). Is there any dumpfile I should rescue?
22:12:25 <nielsm> no new nightlies have been released for a long time, so it might not be relevant any longer
22:13:08 <nielsm> unless TrueBrain suddenly set it up again :)
22:13:11 <Zuu> Ah ok. Everyone compiles on their own?
22:13:44 <nielsm> it just hasn't been set up after the move to github and other changes to infrastructure
22:14:21 <Zuu> No blame, just been away for years so I don't know exactly how it is set up now.
22:15:15 <nielsm> if you dare to use random links from me, you can try one of these:
22:16:06 <nielsm> I set up an experimental build a few days ago, and we're probably going ahead with using ms azure devops cloud for future nightlies
22:25:05 <nielsm> actually, those pipelines should also output the PDB files now that you mention it
22:25:12 <nielsm> so thanks, will have to note that somewhere
22:25:47 <Zuu> By the way the 7z file is missing the readme and COPYING file.
22:26:19 <Zuu> and probably changelog.txt should be included too.
22:26:23 <nielsm> I just made it do a simple pack up of the bin folder
22:26:50 <nielsm> well, something would have to update the changelog.txt automatically then :P because it's certainly not being maintained manually right now
22:28:14 <Zuu> I think it used to be compiled before a release possible by parsing the svn log. But I never did that part and does not know exacly how it was caried out.
22:28:48 <andythenorth> defer to github?
22:29:31 <nielsm> one problem of automated changelog generating is that you might end up with a bunch of small "fix mistake in previous commit" non-changes
22:29:43 <nielsm> unless you're careful to filter those out some way or other
22:30:18 <Zuu> I think there was manual work involved.
22:30:52 <nielsm> there was also one recent case of a change being reverted entirely, an improvement to the blitter performance, that turned out to cause bugs in sprite sorting
22:30:55 <Zuu> Hmm 512x256 map and FIRS 0.3 is giving me 1 industry of each. :-)
22:32:47 * nielsm tries running make in nml
22:33:09 <nielsm> up to test 32 without errors
22:39:30 * Zuu makes all sorts of noob mistakes like forgetting to refit vehicles.
22:40:09 <Zuu> We should have a CTRL-feature to refit all vehicles in the depot :-)
22:40:45 <nielsm> andythenorth: I pushed to my indcargonum branch of nml
22:41:49 <Zuu> But most noticable, if I've filtered vehicles on sand cargo, why doesn't it refit to sand automatically? (I know I ask for code work.. :-p )
22:42:26 <nielsm> yes, that's also one of my small gripes
22:42:55 <andythenorth> I'll pull in a minute
22:42:59 <Zuu> Is it that some NewGRFs have multiple cargoes and eye candy refits that blocks it?
22:43:01 <andythenorth> Zuu: just use station refits
22:43:23 <nielsm> hmm, "gripes: Pinching and spasmodic pain in the intestines."
22:43:35 <nielsm> good thing that's not the only definition
22:44:11 <Zuu> Oo station refits. I don't remember that feature.
22:51:01 <Samu> who can implement timetables for AIs?
22:52:07 <Zuu> Nah, I won't dig that deep into code. I might sew a bit but not code.
22:55:07 <Zuu> Also, I think AIs are not that limited by not having timetables. They can do vehicle micro management on a lever humans cannot do.
22:55:09 <Samu> other stuff I'd like the AIs to be able to do was to get the refited cargo capacity of an engine, rather than a vehicle
22:55:14 <andythenorth> oh I have to build nml :P
22:56:05 <Samu> right now i need to buy the vehicle, refit it to the cargo to retrieve its capacity, that means wasting money :(
22:56:22 <Zuu> I think that may be related to the nml/nfo spec
22:56:25 <andythenorth> nielsm: prop 28 works
22:56:38 <andythenorth> I assume we squash most of these commits at the end?
22:57:07 <andythenorth> so what else did we get new?
22:57:13 <Zuu> If it has not been improved, NewGRFs can display one thing on the veihcel purchase list (text) and provide other props when the vehicle is built.
22:57:56 <Samu> when i have to manage 300+ routes, my ai is slow
22:57:59 <andythenorth> ideally they wouldn't
22:58:31 <Samu> can't micromanage that many vehicles
22:58:59 <Zuu> Yes for scaling up timetables for AIs could help.
22:59:30 <andythenorth> ok so vars need named :P
22:59:33 <Zuu> But then you would only set the wait time on stations right, not actually make a full timetable?
22:59:49 <andythenorth> and they have to be given a parameter
22:59:59 <Zuu> With slack and ability for schedules to recover from disturbances and delays.
23:00:32 <andythenorth> not sure about naming
23:00:32 <Samu> i was looking for a way to maintain a 50% cargo rating on the stations
23:00:50 <andythenorth> if we have produced_this_month_1 and produced_this_month_2 in old spec
23:00:56 <andythenorth> is the new spec just produced_this_month?
23:01:22 <andythenorth> with the cargo in the 60+X param?
23:01:26 <Zuu> CluelessPlus toggles its routes between full load on/off depending on station rating. Which is a bit more micro management than you can expect humans to do.
23:01:55 <Samu> i thought of timetables to force buses 5-6 days waiting at a loading bay
23:02:03 <andythenorth> does the 60+ param really do this? "The 60+x parameter specifies the cargo type as index into the cargo translation table."
23:02:42 <andythenorth> that suggests knowing the cargo index in the CTT
23:02:47 <andythenorth> which is not commonly known
23:02:53 <Samu> my main problem is actually with mail
23:03:16 <Eddi|zuHause> uhm what? you have full control over your CTT
23:03:21 <Samu> its hard to make a profit in desert/ice landscape
23:04:17 <andythenorth> Eddi|zuHause: am I misreading it?
23:04:30 <andythenorth> it's very rare to rely on the position of a cargo in the CTT
23:04:46 <andythenorth> nml abstracts that
23:05:06 <andythenorth> maybe there's an nml built-in that handles it
23:05:11 <Zuu> Samu: Then choose other cargo than mail? Or implement timetables. :-p
23:05:36 <Eddi|zuHause> nml automatically translates cargo labels into CTT entry positions
23:05:55 <andythenorth> usually with industry stuff, it's 'check cargos 1..3' in the industry scope, rather than looking up global cargos in the CTT
23:05:59 <andythenorth> probably doesn't matter
23:06:20 <andythenorth> I am just curious if the docs are accurate
23:06:33 <andythenorth> this means I can query an industry for a cargo it doesn't accept or produce?
23:07:01 <Eddi|zuHause> i can't say i have enough context to judge that
23:07:17 <andythenorth> I am looking for the commit
23:07:50 <Eddi|zuHause> i don't even have a clue what var you're talking about
23:08:25 <Eddi|zuHause> industries? industrytiles? whatever?
23:08:47 <andythenorth> commit tells more than I can
23:08:50 <Samu> ah, its not cluelessplus i got an issue with. it's roadai using superlib
23:08:50 <Eddi|zuHause> a var number is meaningless without the feature
23:09:37 <andythenorth> it does look like it's CTT index
23:09:57 <Samu> roadai authoer updated library versions to the latest superlib and has since been a failure of an AI. i wonder what the 500 loops warning mean
23:10:50 <andythenorth> I wonder about naming the nml vars same as the ottd vars
23:12:23 <Zuu> Samu: superlib pf/builder will try X loops from A to B and then abort and search from B to A.
23:12:36 <Samu> SuperLib: Timed out to find path. Used 500 of 500 loops.
23:12:48 <Zuu> X is choosen so that it if A or B is on a small island it should figure that out sooner than later.
23:13:33 <Zuu> But the drawback is that path searches take a bit longer time to perform unless they are very short.
23:13:50 <Samu> ever since this is displayed, RoadAI has been failing to build more than 1 or 2 routes :(
23:14:00 <Samu> it's severely handicapped
23:14:11 <Samu> it didn't use to be like this with older library version
23:14:19 <Samu> i dunno if it's actually the issue
23:14:54 <Samu> SynTrans, on the other hand, does fine
23:15:00 <Samu> seems to be using an older lib
23:16:36 <Zuu> Well there is a fix in version 40 for RoadPathFinder not returning as documented, and also a fix for timeout not working.
23:17:03 <Zuu> Inside the tar there is a changelog.txt detailing what changes between the versions.
23:17:51 *** sla_ro|master has joined #openttd
23:19:59 <Samu> import("util.superlib","SuperLib",40);
23:20:16 <Samu> RoadAI-5 imports version 40
23:20:33 <Samu> how would i get older RoadAI's now from bananas?
23:21:46 <Samu> syntrans imports superlib 36
23:21:53 <Samu> but also imports road pathfinder 4
23:22:46 <Zuu> Not all AIs use SuperLib to pathfind. The one in SuperLib is quite opiniated and if you don't like my opinions, you are better of using pathfinder 4.
23:23:31 <Samu> must find out what was RoadAI using on older versions, if it was SuperLib or something else
23:25:44 *** andythenorth has left #openttd
23:26:00 <Zuu> Not sure if you can obtain older versions of AIs on the web. I think you can get it as a dependency via openttd.exe.
23:26:52 <Zuu> I mean if you download a scenario that depend on an older version of RoadAI, you get that older version assuming they set up the dependencies correctly upon uploading the scenario.
23:28:09 <Zuu> I thnk your best bet is too look for a VCS.
23:28:35 <Samu> that image shows 500 road vehicles
23:29:46 <Samu> gonna trust the forum and download that tar
23:29:48 <Zuu> Well SuperLib 40 has this change "- RoadPathFinder::FindPath and ::GetFindPathError was not responding as
23:29:48 <Zuu> " which I assume could break AIs if they expect the undocumented behaviour.
23:30:27 <Samu> let me try 39 on roadAI 5
23:32:35 <Samu> it was the change from 39 to 40 that broke it
23:39:10 <Samu> so RoadAI prefers the unexpected behaviour :p
23:39:20 <Samu> already with 740 road vehicles
23:40:14 <Zuu> But a grep on the code shows that it doesn't call the mentioned methods directly but rather using the high level road builder.
continue to next day ⏵
