IRC logs for #openttd on OFTC at 2019-12-21
⏴ go to previous day
00:04:31 *** andythenorth has left #openttd
00:04:48 *** WormnestAndroid has quit IRC
00:08:51 *** WormnestAndroid has joined #openttd
00:08:57 *** supermop_work has joined #openttd
00:39:22 *** supermop_work has joined #openttd
01:08:34 *** snail_UES_ has joined #openttd
01:10:02 *** supermop_work has joined #openttd
01:40:41 *** supermop_work has joined #openttd
01:40:57 *** snail_UES_ has joined #openttd
02:11:19 *** supermop_work has joined #openttd
02:23:02 *** WormnestAndroid has quit IRC
02:23:25 *** WormnestAndroid has joined #openttd
02:41:59 *** supermop_work has joined #openttd
03:12:47 *** supermop_work has joined #openttd
03:27:43 *** Wormnest has joined #openttd
03:34:25 *** floodious has joined #openttd
03:35:02 <floodious> although the lake is filled incorrectly and those tiles are most definitely not set to river
03:39:30 <floodious> it seems to me a "tile" is in fact "vertex"
03:43:27 *** supermop_work has joined #openttd
04:43:07 *** supermop_work has joined #openttd
04:50:35 <Pikka> floodious, yep, a tile coord often means the northern corner vertex for landscape operations. So you have to go one more tile in the +x and +y directions to get an area.
04:59:59 <floodious> for what i'm attempting i can probably get away with verifying the target tile is flat, but the weird result i got shows there is something else strange going on... i'm switching my code to use c-style callbacks now which should simplify it a ton
05:00:23 <floodious> typical debugging though, only too predictable "after the first 90%, comes the second 90%"
05:07:19 <floodious> can now "flood" lakes up to N depth in low areas
05:07:57 <floodious> total invested effort so far: 4 hours research, about 2 hours fiddling with writing code and testing
05:09:10 <floodious> since callbacks are used it's possible to apply this in a generic way, the means to "match" to a target during fill isn't limited to height, it could be anything like testing inside a city block or similar, and the application need not be "set river", it could be anything like planting a tree
05:13:46 *** supermop_work has joined #openttd
05:16:47 <floodious> that's so insanely cool that yesterday i got mad trying to manually do this on a 4096x4096 heightmap lol
05:17:04 <floodious> watching it work in 4.1 ms now is like... ugh
05:18:25 <floodious> bug = fails on contact with map edge
05:18:43 <floodious> i thought so but weirdly enough it does work sometimes, probably an off-by-one error in the range limiting
05:22:41 <floodious> like test(tile) { return distance(tile, city center) < radius; }, and apply(tile) { if (is_empty_land(tile)) { plant_trees(tile); } } = fill circle around city with trees
05:32:57 <floodious> since it includes running state data, it could be made to flow downhill and mark sloped edges for overflow at high current and stuff... so could function as a more complex water-flow simulation (although i'm not sure if the flood-fill algorithm is compatible as-is with recursive loops)
05:34:41 <floodious> or "growing" a forest based upon simulated water table flow
05:36:43 <floodious> auto-erosion, ... lots of ideas
05:39:20 <Pikka> it's fun once you get into it ;)
05:40:34 <floodious> i think a few of these sorts of tools in the scenario editor would vastly improve the quality of scenarios... since just this flood-fill thing cut like 1/2 of the effort i'd need to invest
05:43:16 <Pikka> I've never liked the generated rivers... I usually have them turned off and forget they exist. But I can see them being useful for high lakes in scenarios.
05:44:25 *** supermop_work has joined #openttd
05:44:35 <floodious> lakes are essential if you want to do something like reproduce the forestry of the west coast or similar... need lakes + rivers, log barges for rivers, lakes and oceans
05:45:33 <floodious> as fun as model trains may be, they didn't exist really until the mid 1800s, and it was always totally impractical to move tens of thousands of tons of logs from mountainside to mill via something like rail with little putter-putter engines
05:46:22 <floodious> i think around here the remnants of wooden log train trestles and such were only used to move people, fuel and supplies
05:47:04 <floodious> you can still walk around in the woods on mountainsides and come upon lumps in the ground from the sleeprs
05:47:49 <floodious> huge trenches dug by steam shovels during 1820s and such :)
05:49:33 <floodious> the way stuff used to work back then is super cool, wooden hand-carved rails made by guys with axes and saws
05:52:59 <Pikka> afaic openttd is a train game, and a road traffic game, and a plane game, and a heavy industry game... I'm not sure it's possible to make it interesting (and 'realistic') pre 20th century. But that's just me and my bad opinions ;)
05:53:45 <floodious> it's certainly possible to approximate it, but the limited scale makes proper scaling pretty close to impossible
05:54:24 <floodious> i think my centuries were off, 1920s not 1820s
05:54:41 <floodious> 1820s would've been a bunch of chinese guys shoving stuff by hand and pushing wooden carts
05:55:37 <floodious> lots of little "Nth creek chinese coal mine" type stuff around here, little openings from the 1800s four feet tall
06:11:51 <floodious> that's the heightmap at 1k
06:12:24 <floodious> the inlet from the lower left and the straight in the upper right are ocean, everything else is lake
06:13:55 <floodious> realistically it would need about 12k, and max height near 200 (i think)
06:14:34 <floodious> the white peak is 1820 meters
06:15:07 *** supermop_work has joined #openttd
06:18:05 *** Wormnest has joined #openttd
06:23:37 <floodious> that's the head of the inlet, the first lake visible on the left
06:46:05 *** supermop_work has joined #openttd
06:58:42 *** HerzogDeXtEr has joined #openttd
07:16:43 *** supermop_work has joined #openttd
07:35:40 *** andythenorth has joined #openttd
07:39:40 *** sla_ro|master has joined #openttd
07:47:22 *** supermop_work has joined #openttd
08:18:02 <andythenorth> well I have crashed nmlc
08:19:31 *** supermop_work has joined #openttd
08:24:22 <andythenorth> oof varact 2 can only check 255 ranges?
08:27:10 <andythenorth> I was stuffing everything into one giant varact 2 by combining the results of procedures
08:27:21 <andythenorth> cargos * loaded_states etc
08:28:30 <andythenorth> apparently not :P
08:28:37 <floodious> stufficiency, stuff it all in there
08:28:51 <floodious> no need for breathing room
08:33:47 <andythenorth> maybe we could have a dword for ranges :P
08:35:29 <floodious> there can be a surprising impact on cache and such between bytes and larger words packed into structures
08:36:08 <floodious> like ^2 or worse, so 1 byte = 1 time, 2 = 4, 3 = 8, 4 = 16
08:37:49 <floodious> would be interesting to profile such changes though to see if 32-bit words as default would be significant
08:50:10 *** supermop_work has joined #openttd
09:20:53 *** supermop_work has joined #openttd
09:51:34 *** supermop_work has joined #openttd
09:59:16 <Wolf01> Hmmm, I need road stations with platforms for different directions, not really perpendicular, but double war ro-ro would be good enough
09:59:41 * andythenorth wonders about class vars for newgrf vehicles
09:59:50 <andythenorth> i.e. extensible properties
10:10:37 *** WormnestAndroid has quit IRC
10:10:50 *** WormnestAndroid has joined #openttd
10:22:14 *** supermop_work has joined #openttd
10:23:11 <andythenorth> so how do I do '0.67 * n' in integer maths? :P
10:24:04 <andythenorth> "Floating-point operations are only possible when both operands are compile-time constants."
10:26:38 <floodious> 2/3 = 666/999 = etc
10:27:12 <floodious> with 16 bit precision assuming both source numbers are <256 it's 65536/3 / 65536
10:27:58 <floodious> 21845 + 1/3rd which can be approximated with mul+shift+add if you want max precision
10:28:35 <floodious> but 21845 should get you close enough for 1/3rd
10:28:42 <floodious> 2/3rd = 43690 + 2/3rds
10:29:21 <floodious> since it's 2/3rds... i think you can round by
10:29:35 <floodious> (i * 43690 + 1) / 65536
10:31:36 <floodious> but then you need to get your 8 bits, so you have to divide 43690/256 first, = 170.6640625
10:32:14 <floodious> (i * 170 + 1) / 256 should fit in a 16-bit word register
10:35:28 <andythenorth> yeah, a simple '(n / 3) * 2' is wrong due to rounding
10:39:20 <nielsm> <floodious> (i * 43690 + 1) / 65536 <-- but if you have 32 bit registers and your inputs are sufficiently small do this as a microoptimization
10:39:44 <andythenorth> nielsm: (n * 3) / 3 returns 498 when n is 500
10:40:28 <andythenorth> that was another 500KB of nml I could have saved, but eh no
10:40:45 <floodious> (100 * 170 + 1) / 256 = 66.41015625, error is 0.38%
10:41:05 <Wolf01> Hmmm, doubled $100M without noticing
10:41:09 <floodious> that's just using 8-bits of fraction (1/256th precision)
10:43:18 <andythenorth> maybe I can put 3 compile time constants in 3 registers
10:43:27 <andythenorth> there's always _some_ horrible hack eh
10:43:50 <floodious> this is just fixed-point integer math stuff, been this way since the dawn of binary computing
10:44:41 <floodious> doing long-division via various tricks you can improve precision if you really need it, but being off a fraction of a percent isn't going to have a major effect on stuff in a game, usually
10:44:54 <andythenorth> except when it trivially does
10:45:04 <planetmaker> <andythenorth> so how do I do '0.67 * n' in integer maths? :P <--- n * 67 / 100
10:45:22 <floodious> well you're rounding to integers anyway, so if the error is less than the range of integers you get zero error in the result
10:45:37 <planetmaker> mind that multiplication should be befor division (unless you run in overflow situations)
10:49:43 <andythenorth> compile time constants ftw I think :D
10:52:54 *** supermop_work has joined #openttd
10:54:56 <andythenorth> ok another 400KB of nml gone
11:12:18 <floodious> no, more like precrime detective, eliminated 400 killerbytes before they could strike
11:13:26 <TrueBrain> that doesn't sound like andythenorth :P
11:14:23 <andythenorth> TrueBrain: trying to save you the AWS fees :D
11:14:28 <andythenorth> not working though
11:14:47 <andythenorth> nfo is 3MB smaller, grf is same size :P
11:14:58 <TrueBrain> I noticed that finally we got an email back about the Open Source credits .. that it will take another 5 to 10 workdays for an answer :P
11:15:16 <andythenorth> does Bezos work christmas day?
11:16:24 <TrueBrain> which overflowed to -1, explains a lot
11:16:29 <TrueBrain> he found the infinite money cheat
11:18:26 <TrueBrain> right, I had to rework my CDK stuff ... lets get this stuff running on AWS or something ..
11:19:04 *** Progman has joined #openttd
11:23:31 *** supermop_work has joined #openttd
11:54:13 *** supermop_work has joined #openttd
11:58:09 <FLHerne> andythenorth: What are your times for parsing/preprocess/output with nml and pypy?
11:58:59 <FLHerne> Here output is negligible compared to parsing FIRS taking 25s, probably because I have an SSD and a /reaaally/ slow CPU
12:00:38 <andythenorth> are you outputting nml or nfo?
12:02:55 <andythenorth> FLHerne: also actual times, or relative to py38?
12:17:21 <andythenorth> FLHerne: output firs nfo is 2.3s
12:17:29 <andythenorth> relatively negligible
12:19:07 <andythenorth> it's 7-8s for Iron Horse, for a smaller nml input file
12:23:34 <andythenorth> with my horrible patch it's 1.5s to output Horse
12:24:57 *** supermop_work has joined #openttd
12:26:51 *** Wolf01 is now known as Guest12093
12:28:06 <TrueBrain> so what are two good words to differentiate these two pairs: Development/Production and Staging/Production
12:28:13 <TrueBrain> "env" doesn't cover it, as .. it can be either :P
12:28:29 <TrueBrain> (it is a 2 by 2 matrix)
12:28:54 <nielsm> maturity and deployment?
12:34:59 <andythenorth> FLHerne oops clown shoes, FIRS nfo output time is 7.5s
12:35:09 <andythenorth> my previous time was with the horror-patch
12:35:20 <andythenorth> I forgot I had patched nmlc in my path
12:42:08 <andythenorth> anyone know what I should do about loading speeds? :P
12:42:27 <TrueBrain> fixes it every time
12:55:34 *** supermop_work has joined #openttd
13:02:07 * andythenorth wonders what Eddi|zuHause thinks :P
13:02:12 <andythenorth> the question is, should loading speed be normalised so all vehicles load in constant time, regardless of capacity?
13:02:31 <andythenorth> the current Iron Horse code appears to try and do that, I do not really know why
13:06:03 <nielsm> loading speed can be a tradeoff between different car types that carry the same cargo
13:06:50 <andythenorth> I thought that was implemented, but code says
13:06:53 <nielsm> e.g. long-distance passer cars (in real life) often trade smaller doors for bigger comfort inside
13:07:13 <andythenorth> currently Horse normalises so all vehicles take 240 ticks to load
13:07:25 <andythenorth> I'm sure that was well-intentioned, but it seems odd
13:17:58 <FLHerne> andythenorth: I think it makes sense to normalize by default?
13:18:23 <andythenorth> it implies a 16t wagon takes same time to load as 48t?
13:18:25 <FLHerne> Then you can combine that with any adjustments for partiular vehicles
13:18:45 <FLHerne> I think that's probably true
13:19:01 <FLHerne> 16t wagons are loaded with shovels, 48t with big mechanical grabs
13:19:24 <FLHerne> (clearly stations should be able to modify loading speed, but...)
13:20:11 <FLHerne> Similarly, modern high-capacity carriages have wide aisles and big fast-acting sliding doors
13:20:35 <andythenorth> dwell time is one of the most significant factors in journey time :P
13:26:12 *** supermop_work has joined #openttd
13:50:08 <Wolf01> Hmmm nielsm, how do I upgrade tracks with catenary?
13:53:05 <nielsm> Wolf01: save your game, exit, and reload
13:53:27 <nielsm> if catenary is invented during play the upgrade function doesn't appear
13:53:35 <nielsm> you have to reload the game for it to appear
13:53:55 <nielsm> I wrote a bug report on the steam forum about it
13:54:48 <Wolf01> Meh, I'll wait then, it's just that only the new laid tracks have catenary so I need to remember to upgrade the old bits, or just disable catenary until I'm ready to upgrade
13:55:16 <nielsm> if you have stone bridges and want to upgrade them to steel you have to rebuild the track anyway
13:55:36 <Wolf01> Also I need to skip like 1 in 3 songs because they won't play
13:56:11 <nielsm> I haven't had trouble with music not playing, I think
13:56:58 *** supermop_work has joined #openttd
14:04:21 <Wolf01> I'm station-walking more than OTTD, specially with docks
14:05:04 <nielsm> as in, using the module system to extend the vehicle stopping area from the road connection?
14:10:37 <FLHerne> andythenorth: Ok, so with iron horse on pypy I get
14:11:02 <FLHerne> Parsing 40s, preproc 35s, writing 105s
14:11:16 <andythenorth> try my horrid nml patch :)
14:11:30 <FLHerne> I'm about to try a different horrid patch :P
14:15:55 *** frosch123 has joined #openttd
14:19:40 <nielsm> thing I like about the train fever engine (that has remained through transport fever 2) is how fast it starts up to the main menu, with no weird window flashing or anything else
14:20:45 <Wolf01> Yeah, it doesn't load anything at startup... but you have to wait 10 minutes to load a game
14:21:16 <nielsm> hmm my savegame currently takes a minute or so to load (haven't timed it)
14:22:11 <michi_cc> Many other games nowadays have a launcher to launch the game, which means your Steam/GOG/Epic/Whatever launcher launches the launches that launches your game :p
14:24:06 <nielsm> carving out a large bay to get a dock to a distant industry
14:24:22 <nielsm> was maybe 15 million for that terrain mod
14:25:46 <Wolf01> I'm experimenting with mixed platforms for trains, I have 6 lines in a 4 platform stations and no space to expand without rebuilding the entire thing and demolishing a lot of tracks/roads/other stations
14:26:15 <andythenorth> stern wheel paddle steamers?
14:26:46 <FLHerne> Wolf01: What do you mean by 'mixed platforms' ?
14:27:18 <FLHerne> Wolf01: Oh, TF2 again
14:27:37 *** supermop_work has joined #openttd
14:28:34 <nielsm> also great change: stations can actually connect directly to industries, you don't _need_ a road between a train station and an industry, as long as an entry to the train station touches the industry in the right place
14:30:52 <Samu> the restart command is sometimes regenerate the map differently than that in the save
14:32:37 <planetmaker> Samu, yes. If the OpenTTD version is different. Identical map is only guaranteed when version is the same, including the versions of all NewGRFs and scripts used
14:35:07 <FLHerne> Why does nml write "// Automatically generated by GRFCODEC. Do not modify!" to the output NFO file?
14:35:27 <Samu> which vesion is gee91490e816a3
14:35:42 <FLHerne> Is there some tool that would get confused if it said `NML` instead?
14:36:14 <andythenorth> I wonder if it's legacy artefact
14:38:55 <Samu> it's samupatchpackrebase
14:44:12 <Wolf01> Ha! I found hot to enable traffic lights
14:44:42 <nielsm> FLHerne: I think older grfcodec versions were very strict about that header
14:45:46 <nielsm> the first line can be any comment, the second line must be an // (Info version x) line
14:47:36 <planetmaker> FLHerne, I seem to remember that nforenum likes that
14:48:09 <FLHerne> Ok, so there's probably a reason for it
14:49:16 <nielsm> nforenum shares the inforeader class in that file with grfcodec, so it probably accepts anything nowadays
14:50:10 <planetmaker> yes, might simply be legacy
14:50:11 <andythenorth> Horse compile with pypy, and my changes is 22s with primed caches
14:50:21 <andythenorth> that's a lot faster than 1m 10s or so
14:50:52 <andythenorth> that relies on nmlc being patched for output speed
14:58:18 *** supermop_work has joined #openttd
15:01:04 *** Maarten has joined #openttd
15:04:46 <FLHerne> It would be nice if Python would document the `rename() fails across different filesystems` thing
15:04:54 <FLHerne> ISTR having the same problem before
15:11:07 <Eddi|zuHause> Wolf01: i was looking for that, but assumed the feature doesn't exist with 1910 roads
15:12:46 <Wolf01> You need to activate the traffic layer and then zoom in until the overlay icons appear on road intersections
15:13:35 <Eddi|zuHause> i've used that mode to tell the game "don't modify these roads". it's an awfully hidden feature
15:16:06 <Eddi|zuHause> no, youtube, i do not want to try out youtube kids...
15:17:23 <Wolf01> TBH, traffic lights are useless now, people still cross with red light most of the time even with passing vehicles
15:18:06 <Wolf01> Maybe with a lot of traffic there's a noticeable difference
15:19:02 <nielsm> I still want a "wait for any load" option here (too)
15:19:04 <Wolf01> Had it like 2 hours ago
15:19:22 <nielsm> I should add some food to myself
15:19:48 <Wolf01> Time to electrify the main line
15:28:59 *** supermop_work has joined #openttd
15:30:47 <Wolf01> Is it me or trains won't slow down if the next signal is red anymore?
15:32:21 <Wolf01> Yes, you can, put it in the middle and add modules on both ends, then connect the industries with a piece of road and win
15:35:22 <andythenorth> FLHerne: 0.9s output now for Horse, no errors reported
15:36:06 <nielsm> not allowed to make the station any longer than that
15:36:10 <Eddi|zuHause> i made a dock stretch a bit inland, to avoid hauling back and forth by car
15:36:19 <FLHerne> andythenorth: Sounds good
15:36:42 <andythenorth> making the image palette check optional would cut 1 second out also :P
15:37:02 <Eddi|zuHause> andythenorth: sounds like a terrible idea
15:42:54 <Samu> i'm getting weird conflicts that aren't conflicting at all
15:43:20 <Samu> it's the exact same code one side and the other
15:44:31 <Samu> i had conflicts there in the past
15:44:41 <Samu> in a previous rebase, but I solved back then
15:47:37 <Samu> looks like it's repeating
15:47:43 <Samu> whatever, i just hope it's working
15:50:04 <andythenorth> just because OpenTTD doesn't transform offsets for reversed vehicles :P
15:51:24 <Samu> well, it's not crashing, so the fix is in
15:51:41 <andythenorth> @calc (22-16) / 22
15:51:41 <DorpsGek> andythenorth: 0.272727272727
15:51:58 <andythenorth> removing just part of the duplication saves 27% of compile time :P
15:52:22 <andythenorth> and cuts 6MB off the final grf size
15:53:27 <andythenorth> @calc (19-6) / 19
15:53:27 <DorpsGek> andythenorth: 0.684210526316
15:53:53 * andythenorth wonders where openttd keeps the offsets :P
15:55:44 <frosch123> i had some wip for longer vehicle sprites, that changed the offset to be in the center
15:56:39 <andythenorth> frosch123: was it non-trivial?
15:57:09 <andythenorth> presumably there's 99 kinds of legacy string and edge cases
15:59:39 *** supermop_work has joined #openttd
15:59:44 <Samu> oh crap, i commited on master, how do I undo now?
16:00:03 *** WormnestAndroid has quit IRC
16:00:32 <Samu> also submitted to the internet bah
16:00:47 <frosch123> i probably have some design text somewhere
16:01:37 <frosch123> but it was about grouping multiple articulated parts to display a single sprite, while ottd would figure out the position and bounding box of the sprite
16:02:26 <milek7_> Samu: reset --hard to good commit and push --force
16:02:30 <peter1138> Samu, git reset... ^^
16:02:50 <milek7_> (and probably branch before reset to keep changes for later use)
16:03:04 <frosch123> there is probably some irc talk in the logs
16:03:11 <frosch123> if it was not with andy, then probably with V
16:03:19 <Samu> can i do rebase and then drop the commit?
16:03:23 *** supermop_Home has joined #openttd
16:04:12 <andythenorth> frosch123: that looks like an Eddi|zuHause thing :D
16:04:15 <glx> yes rebase with drop works too
16:04:31 <frosch123> andythenorth: it probably was about removing that cets mess :)
16:05:21 <andythenorth> unrelated: extensible properties for vehicles? o_O
16:05:27 <andythenorth> per ID, not per instance
16:05:32 <andythenorth> like python class vars
16:05:47 <Eddi|zuHause> frosch123: in all likelyhood i commented something about the blue "anchor" dots having to be moved further inwards
16:06:24 <Samu> oh, must push with force now, right?
16:06:24 <Eddi|zuHause> like, to the center of the front/back vehicle
16:06:57 <Samu> cool, it's gone from the website too
16:07:05 <Wolf01> The blue anchor points should be the boogies pivots
16:08:37 <Eddi|zuHause> frosch123: log says that you highlighted V with this png
16:12:05 <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick opened pull request #7866: Fix: Custom sea level default value is now equal to minimum value, not lower https://git.io/JedwY
16:26:42 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh approved pull request #7866: Fix: Custom sea level default value is now equal to minimum value, not lower https://git.io/Jedwo
16:27:42 *** WormnestAndroid has joined #openttd
16:30:20 *** supermop_work has joined #openttd
16:30:36 *** WormnestAndroid has quit IRC
16:31:39 *** WormnestAndroid has joined #openttd
16:35:00 *** WormnestAndroid has joined #openttd
16:35:47 <andythenorth> FLHerne: going to PR then? :)
16:35:50 <DorpsGek_III> [OpenTTD/nml] glx22 opened pull request #77: Fix: don't try to debug_print not set optional GRF param number https://git.io/JedwS
16:36:38 *** WormnestAndroid has joined #openttd
16:54:25 <andythenorth> oof Eddi|zuHause needs to finish that town grid patch
16:54:33 <andythenorth> I am playing master, towns are not very nice :|
16:55:32 <Eddi|zuHause> there exist things in this world that are more likely to happen
16:58:20 <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #77: Fix: don't try to debug_print not set optional GRF param number https://git.io/Jedr3
16:59:38 <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #71: Add: nmlc option to force regeneration of parser tables https://git.io/Jedrs
17:00:08 <DorpsGek_III> [OpenTTD/nml] LordAro requested changes for pull request #68: Fix: close image files after use during palette check https://git.io/JedrZ
17:01:02 *** supermop_work has joined #openttd
17:04:56 <DorpsGek_III> [OpenTTD/nml] planetmaker merged pull request #71: Add: nmlc option to force regeneration of parser tables https://git.io/Jeyxo
17:06:45 <DorpsGek_III> [OpenTTD/nml] planetmaker merged pull request #77: Fix: don't try to debug_print not set optional GRF param number https://git.io/JedwS
17:18:29 *** Wormnest has joined #openttd
17:19:21 <TrueBrain> w00p, seems I have IPv6 running on AWS, via CDK .. \o/
17:19:38 <TrueBrain> lets see if this means I can now provision the OpenTTD website ...
17:20:57 * andythenorth wonders about changing cdist
17:21:16 <andythenorth> it disincentives connected networks
17:22:12 <planetmaker> so we need cargodest :P
17:23:46 <andythenorth> I have 'effect of distance on demand' at 0%
17:23:54 <andythenorth> which is required for e.g. FIRS supplies to work
17:24:01 <andythenorth> but destroys pax networks :)
17:25:17 <nielsm> so hack it by having per cargo type/class tuning?
17:26:11 <andythenorth> I think any further changes to cdist need to be very careful
17:26:31 <planetmaker> cdist can be configured for pax + other cargoes separately, not?
17:31:43 *** supermop_work has joined #openttd
17:32:47 <supermop_Home> planetmaker: you can't set different distance effect per that differentiation
17:33:26 <supermop_Home> andythenorth you can work around supplies a bit by constraing them
17:33:56 <supermop_Home> industry can give cargo to two stations
17:34:32 <supermop_Home> so for an industry that makes supplies, I generally have one station that is for near and one for far destinations
17:35:17 <TrueBrain> "Dev-Staging-BinariesProxy-BinariesProxyNestedNestedStackNestedNestedStackResourceDF7EF-51P2LUWCR3C" <- you think it is nested?
17:35:39 <TrueBrain> I am not completely sure either ..
17:35:46 <TrueBrain> CDK can generate the weirdest names
17:35:58 <nielsm> imagine if it was abstract tho
17:45:16 *** HerzogDeXtEr1 has joined #openttd
17:47:47 <TrueBrain> I think IPv6 is not working tbh :P
17:48:00 <glx> but at least it doesn't fail
17:48:08 <TrueBrain> well, that is just the fallback at work in that case :D
17:48:44 <TrueBrain> now only the question .. why does it fail .. *puzzle time*
17:49:30 <TrueBrain> oops, egress-only-gateway
17:49:35 <TrueBrain> that ... might be the reason I guess? :D
17:58:53 <TrueBrain> glx: how about now?
18:00:09 *** ChanServ sets mode: +v tokai
18:02:23 *** supermop_work has joined #openttd
18:18:35 <andythenorth> Franco-Swiss-German Horse?
18:18:48 * andythenorth doesn't have enough projects
18:26:53 <frosch123> what would be different about that?
18:27:14 <frosch123> mountainious? iron ibex?
18:28:42 <frosch123> oh, btw... did you see that hillarious thread on reddit? someone complaining about oxygen in steeltown being unrealisitic, followed by other people citing wikipedia that it is realistic?
18:31:14 <Eddi|zuHause> a swiss horse is a sworse?
18:32:55 <andythenorth> frosch123: reddit has discovered timetables also
18:33:01 *** supermop_work has joined #openttd
18:35:51 *** snail_UES_ has joined #openttd
18:53:56 <Samu> working with rebase is AIDS
18:54:18 <andythenorth> no Samu, AIDS is AIDS
18:54:21 <andythenorth> have some perspective
18:54:38 <Samu> why do I have to resolve conflicts everytime I rebase
18:55:12 <LordAro> Samu: probably because whatever your changing is also being changed by master
18:55:21 <Samu> the change I did today, breaks something that was changed in the past
18:55:33 <Samu> why the heck do I care about what it was in the past
18:55:37 <LordAro> alternatively, you're doing the rebase wrong
18:56:02 <LordAro> or rather, using a suboptimal method
18:56:34 <Samu> seems that the chronological order is messed up
19:03:42 *** supermop_work has joined #openttd
19:12:05 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro merged pull request #7866: Fix: Custom sea level default value is now equal to minimum value, not lower https://git.io/JedwY
19:27:27 <andythenorth> track on tunnel entrances!
19:33:04 <Samu> code shows repeating after the rebase, this sucks :(
19:33:12 <Samu> i wonder what else gone wrong
19:33:32 <Samu> erbase, merge, whatever..
19:34:22 *** supermop_work has joined #openttd
19:36:59 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7864: Codechange: Replace FOR_ALL_XXX with range-based for loops https://git.io/Jed6z
19:37:26 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #7860: Fix: [MinGW] undefined references when _FORTIFY_SOURCE > 0 https://git.io/Jed62
19:38:43 <LordAro> Samu: an actual rebase should remove the duplicated/empty commits
19:39:10 <nielsm> LordAro: I think he means there are code blocks that have become repeated
19:40:32 <Samu> the end result is what matters more, the way it gets there is just a mess though
19:40:39 <LordAro> that's more difficult to fix
19:40:47 *** Progman has joined #openttd
19:40:58 <LordAro> still necessary though ;)
19:41:35 <glx> first step is to return to the state before the weird rebase/merge
19:42:20 <nielsm> it's a good idea to test compile before every commit in a difficult rebase or merge
19:42:29 <nielsm> and review the diffs before committing
19:42:35 <andythenorth> I like rebase now
19:42:44 <andythenorth> it's not an immediately obvious tool though
19:43:21 <Samu> i feel like just doing fix up on everything :(
19:43:25 <glx> you can merge commits, split commits, reorder commits
19:45:50 <DorpsGek_III> - Update: Translations from eints (by translators)
19:46:35 <Samu> found repeating code in framerate_gui
19:46:49 <milek7_> git interface is generally horrid
19:47:09 <glx> usually repeating code means a patch has been applied twice or more
19:47:55 *** Beerbelott has joined #openttd
19:48:09 <Beerbelott> Problems on the website?
19:48:44 <glx> oh broken ipv6 bouncer again
19:53:56 <Beerbelott> TLS session on [2a03:b0c0:2:d0::dc6:7001]:443 fails indeed
20:05:02 *** supermop_work has joined #openttd
20:10:02 <LordAro> oh hey, i got a Jedi url
20:10:59 <nielsm> Jedi J... is that Juke Jaywalker?
20:13:06 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7864: Codechange: Replace FOR_ALL_XXX with range-based for loops https://git.io/Je5LF
20:13:31 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh merged pull request #7860: Fix: [MinGW] undefined references when _FORTIFY_SOURCE > 0 https://git.io/JeQZm
20:14:05 *** snail_UES_ has joined #openttd
20:14:33 <LordAro> always good to make half of all PRs conflict :)
20:21:16 <frosch123> i think i can catch the other half
20:35:40 *** supermop_work has joined #openttd
21:02:13 <frosch123> imo some cheats should be moved into settings
21:02:40 <frosch123> for some reason some people refuse to use stuff labeled "cheat"
21:03:21 <milek7_> isn't it tricky to use in MP?
21:04:14 <andythenorth> it's just a non-issue :P
21:04:18 <frosch123> yes, for those which change the game state actively, but not for the "settings"
21:04:30 <andythenorth> never change anything :)
21:04:40 <andythenorth> spend all time on making nml faster :D
21:05:02 <frosch123> essentially "magic bulldozer", "tunnels crossing" and "small airport crashes" could become settings just fine
21:05:20 <nielsm> how about max map height?
21:05:21 <frosch123> they already work if you start the game in single player and then reload the game in multiplayer
21:05:27 <nielsm> that's a worldgen setting already
21:05:33 <frosch123> nielsm: i am currently wondering why it is there at all
21:05:43 <frosch123> probably because stuff breaks badly
21:06:16 <nielsm> I guess if you lower the value, you risk being unable to modify some of the terrain?
21:06:18 <frosch123> i cannot imagine another reason other than not working correctly
21:06:20 *** supermop_work has joined #openttd
21:06:52 <nielsm> but it's not like the size of any memory allocations or such depend on that setting
21:07:03 <nielsm> no data needs to be moved around for it
21:07:35 <frosch123> i guess it requires reloading newgrf, so it would be a one of the "cannot change in running multiplayer game" settings
21:07:47 <frosch123> but there are many of those
21:11:16 <frosch123> (svn r26887) -Add: cheat for changing the height level (mostly due to the mess with changing snow levels and such)
21:12:20 <frosch123> "this is a cheat because of the fact that it needs to reset NewGRF game state and doing so as a simple configuration breaks the expectation of many"
21:13:46 <andythenorth> but modes also manage expectations
21:37:00 *** supermop_work has joined #openttd
22:07:40 *** supermop_work has joined #openttd
22:13:01 <TrueBrain> okay, it seems I did everything I had to do to get the website on AWS ..
22:13:09 <TrueBrain> well, besides auto-deploy on commit/tag :)
22:17:34 <TrueBrain> now I need to fix the Docker of 'website', as it has some annoying quirks :P
22:34:19 <Samu> my AI won't showcase its best with default presets. Easy profile is the default :(
22:35:06 <Samu> looking for the best AI and then using easy preset, feels like...
22:35:53 <Samu> maybe I don't like losing
22:38:21 *** supermop_work has joined #openttd
22:39:06 <nielsm> well suggest it? that games should be run with a variety of settings
22:40:23 <Samu> map is size is kinda small, 256 x 256, my tests usually involve 512x256 or 512x512 minimum, but i guess that's just me
22:40:49 <Samu> but interesting to see others run competitions instead of me
22:43:05 <Samu> the tests are being run with inflation on and airports noise disabled, hmm
22:45:06 <peter1138> Next you'll be telling me 640x480 is low resolution.
22:46:25 <Samu> the original ludiai just places 2 airports no matter the distance between them
22:46:47 <Samu> on small maps, that's not a problem, but in large maps, such big distances can lead to negative profits
22:47:11 <Samu> it's funny to see the original LuDiAI ranked #1
22:47:53 <Samu> it's not being exposed of its weaknesses, also there's no difference between easy/medium/hard on the original
22:48:15 <Samu> so, it's performing better than mine
22:48:46 <Samu> sad to see LuDiAI AfterFix ranked #30+
22:49:37 <nielsm> over-optimized for certain cases?
22:49:58 <Samu> mine won't build near competitors with easy preset
22:50:12 <Samu> also picks towns at random, instead of the most productive one
22:51:58 <Samu> the original just picks the better towns
22:52:27 <Samu> but that's because of the preset, mine would also do that if the preset was Hard
23:08:58 *** supermop_work has joined #openttd
23:10:53 *** gelignite2nd has joined #openttd
23:13:21 <Samu> perhaps the default should be changed to hard? what do you think about that?
23:13:33 <Samu> make a PR changing the default
23:13:53 <supermop_Home> what's all this airport size business
23:14:47 <Samu> town council airport noise
23:15:03 <Samu> a default openttd install has this setting disabled
23:18:04 <nielsm> no it's the change of large airplanes now always having a risk of crashing at small airports, in 1.10
23:18:17 <nielsm> (unless you use the cheat)
23:21:55 <Samu> i actually wanted one extra setting
23:22:26 <Samu> but somebody else said that disabled wasn't supposed to never crash
23:23:27 <nielsm> TTD originally didn't have any way to control the risk of airplane crashes at all
23:24:26 <nielsm> ttdpatch allows the disasters difficulty setting to affect it, and also allows the higher risk of jet planes on small airports to be removed or reduced
23:29:00 <andythenorth> why aren't crashes a function of newgrf airports?
23:35:58 <Samu> it was because of that PR that 1.10 is now like that, regarding aircraft
23:38:25 <nielsm> the first step for nmlc to become an optimizing compiler!
23:38:42 <glx> small step, but I think it's a good idea
23:39:35 *** supermop_work has joined #openttd
23:39:46 <nielsm> yeah, basic reductions of "obvious" cases is a very good start
23:44:01 <supermop_Home> andythenorth should I start a new game of something?
23:44:16 <andythenorth> I am playing steeltown
23:45:43 <andythenorth> btw those switches are a bug, but faster nml is always good
23:45:51 *** Progman has joined #openttd
23:46:56 <glx> not sure it will be faster, but at least it will report them while replacing
23:47:48 <glx> but it will definitely generate a faster grf
23:49:59 <andythenorth> we don't performance measure grfs, currently?
23:50:16 <glx> it's part of the gameloop
23:51:10 <nielsm> I guess it'd be possible to instrument newgrf callbacks for performance measurement
23:51:42 <nielsm> it would probably also be another case of the act of measuring affecting total performance
23:56:48 *** andythenorth is now known as Guest12117
23:56:49 *** andythenorth has joined #openttd
continue to next day ⏵
