IRC logs for #openttd on OFTC at 2023-08-20
00:41:17 *** ChanServ sets mode: +v DorpsGek
00:41:18 *** ChanServ sets mode: +v Rubidium
02:16:28 *** D-HUND has joined #openttd
02:19:55 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:21:06 *** D-HUND is now known as debdog
02:51:56 *** tokai has joined #openttd
02:51:56 *** ChanServ sets mode: +v tokai
02:58:43 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
03:58:18 *** keikoz has joined #openttd
06:05:08 *** HerzogDeXtEr has joined #openttd
06:16:30 <peter1138> Is it now 3 seconds intseda of 4 seconds?
06:33:49 *** nielsm has joined #openttd
07:17:10 <andythenorth> 9 not 12 πŸ˜›
07:18:53 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
07:32:34 *** SergioMassa[m] has joined #openttd
08:04:10 *** bryjen has quit IRC (Quit: Leaving)
08:15:08 *** michi_cc has quit IRC ()
08:15:17 *** michi_cc has joined #openttd
08:29:34 *** michi_cc has quit IRC ()
08:29:41 *** michi_cc has joined #openttd
08:32:48 *** michi_cc has quit IRC ()
08:32:53 *** michi_cc has joined #openttd
08:36:40 *** michi_cc has quit IRC ()
08:36:44 *** michi_cc has joined #openttd
08:36:45 *** ChanServ sets mode: +v michi_cc
08:42:56 *** nielsm has quit IRC (Ping timeout: 480 seconds)
08:48:11 <andythenorth> hmm that Minecraft video is Henrik
08:48:25 <andythenorth> who wrote "Kanban vs Scrum" which is a good presentation
08:48:33 <andythenorth> used to work at spotify
08:48:36 <andythenorth> probably knows Ludde πŸ˜›
08:52:55 <peter1139> Is who?
08:54:00 <andythenorth> internet bloke
08:56:30 <andythenorth>
08:56:30 <andythenorth> hmm need some fancier variants
08:56:46 <andythenorth> also name clipping eh πŸ˜›
08:59:31 <alfagamma_0007>
08:59:31 <alfagamma_0007> Literally any newgrf
09:00:05 <cryoshakespeare> I'm in the depths of figuring out how to run a makefile on Windows, I've installed MinGW, msys64, I've got Python, GIMP, NML, and make. When I naively run in cmd `make -f C:\etc\ogfx-landscape-1.1.2-source\makefile`, it returns a lot of errors, mostly 'cut' and '[' are not recognised as commands. I suspect I also have to enter some params for filename and such, but that's the next step. As a non-
09:00:05 <cryoshakespeare> dev, I am flying by the seat of my pants, so any insight would be much appreciated.
09:00:44 <andythenorth> hmm
09:01:50 <_jgr_> cryoshakespeare: You'll need to run it from a proper shell (bash, etc), not the Windows command prompt
09:02:14 <cryoshakespeare> Ah, I see, let me give that a shot
09:02:26 <_jgr_> Msys/mingw should come with that
09:03:42 <alfagamma_0007> Powershell doesn't work?
09:09:30 <cryoshakespeare> I tried it there with powershell and it returned the same errors, getting different errors now with MinGW
09:10:42 <alfagamma_0007> Might try out WSL
09:10:54 <alfagamma_0007> *You can
09:11:02 <alfagamma_0007> I guess it works
09:11:04 <alfagamma_0007> ??
09:11:24 <cryoshakespeare> Hm, these errors seem like progress though:
09:11:24 <cryoshakespeare> `process_begin: CreateProcess(NULL, ./, ...) failed.
09:11:24 <cryoshakespeare> [CPP] mynewgrf.nml
09:11:24 <cryoshakespeare> process_begin: CreateProcess(NULL, cc -D REPO_REVISION= -D NEWGRF_VERSION= -C -E -nostdinc -x c-header -o mynewgrf.nml mynewgrf.pnml, ...) failed.
09:11:24 <cryoshakespeare> make (e=2): The system cannot find the file specified.`
09:11:40 <peter1139> WSL2 is probably the least frictionless way these days. You get a proper Linux install, instead of tools built with wonky libraries to make it run on Windows.
09:11:42 <cryoshakespeare> I think that means a failure in not setting any params for the make?
09:11:56 <_jgr_> Are you running make from the source directory?
09:11:58 <truebrain> tell LordAro that peter1139! πŸ˜„
09:12:28 <cryoshakespeare> _jgr_: No, but I do have it in path
09:12:37 <peter1139> It's a failure to start sub-processes, because the tools it expects are not installed.
09:12:54 <_jgr_> You should cd to where the makefile is and run make from there
09:13:21 <cryoshakespeare> Oh, I see
09:13:44 <cryoshakespeare> :O
09:13:54 <cryoshakespeare> All new errors
09:13:59 <_jgr_> CreateProcess will not be able to run a shell script
09:14:40 <cryoshakespeare> Now it says gimp processing is required, but gimp isn't found. Do I add gimp to path?
09:15:09 <andythenorth> I can build ogfx without gimp I think
09:15:12 <andythenorth> haven't tried for a while
09:17:35 <andythenorth> nah seems not
09:18:01 <andythenorth> different errors here though
09:19:00 <andythenorth> `Cannot create obg files without grfid. Please install grfcodec, and try again. Aborting.`
09:19:09 <andythenorth> I do have grfcodec in the path
09:20:18 <michi_cc[d]> But also `grfid`?
09:20:32 <michi_cc[d]> It's part of grfcodec repo, but a separate exe.
09:22:51 <andythenorth> oh
09:22:57 <andythenorth> probably not
09:24:30 *** gelignite has joined #openttd
09:25:48 <andythenorth> fixed
09:25:50 <andythenorth> no gimp
09:25:57 <andythenorth> ogfx make works for me
09:26:31 <andythenorth> "[GIMP disabled]"
09:26:52 <andythenorth> the GIMP stuff was never needed for anything I did in ogfx
09:27:54 <cryoshakespeare> How did you fix it?
09:28:44 <truebrain> run `GIMP= make`; that should make it not try to autodetect gimp πŸ™‚
09:29:21 <cryoshakespeare> Coding and development is an arcane subject man
09:29:35 <cryoshakespeare> Will give that a shot :P
09:29:47 <truebrain> it is a bit odd; it tries to detect your gimp, finds some traces of that, but it fails when to actually want to execute it. Unusual.
09:30:02 <frosch123> cryoshakespeare: pay attention to the spaces, when you do πŸ™‚
09:31:43 <cryoshakespeare> truebrain: After cding to where the makefile is, I ran `GIMP= make -f makefile`, returned an error saying GIMP= is not a command. Take it you didn't mean to run it like that?
09:32:04 <truebrain> you are in a msys bash shell, right?
09:32:13 <cryoshakespeare> Ah, no, powershell
09:32:21 <cryoshakespeare> So many shells to choose from
09:32:32 <truebrain> regression detected πŸ˜› User went back to default πŸ˜„
09:32:36 <dwfreed> can also just 'make -f makefile GIMP='
09:32:48 <truebrain> don't confuse the user more than needed please
09:32:49 <dwfreed> which works in both bash and powershell
09:33:02 <truebrain> the `make` didn't work in powershell dwfreed πŸ™‚
09:34:31 <cryoshakespeare> Ah, but it did, tried that dwfreed, and progress was made, exciting new errors.
09:34:48 <truebrain> so earlier you said it didn't work with powershell, and now it does? Now you have us confused! πŸ˜›
09:35:36 <cryoshakespeare> Yeah, I'm not sure what that was about, it wasn't working, and then it started to. I might have changed some path variables or whatnot.
09:36:08 <cryoshakespeare> anyway, returns
09:36:08 <cryoshakespeare> `[GIMP] src/gfx/water/river_water.gimp.png
09:36:08 <cryoshakespeare> /usr/bin/sh: : command not found`
09:36:08 <cryoshakespeare> and then a write error
09:36:49 <cryoshakespeare> Maybe I should be doing this in msys
09:36:51 <truebrain> I already knew this Makefile was poorly created, but brr .. right ..
09:37:01 <truebrain> yeah, try it in msys bash, just run `make` in the right folder
09:37:08 <truebrain> it should fail to detect gimp, and just continue on
09:37:29 <truebrain> I really doubt anyone ever used Powershell to build this; as we don't do that πŸ™‚
09:48:54 <pickpacket> Too much I want to do. Not enough time. Too much I *have* to do
09:51:32 <cryoshakespeare> alright, in msys2, I ran
09:51:32 <cryoshakespeare> `/c/Program Files (x86)/GnuWin32/bin/make.exe' -f makefile GIMP=`
09:51:44 <cryoshakespeare> cryoshakespeare: returns this error again though
09:51:57 <truebrain> again, just run `make` in the right folder from a msys bash
09:52:36 <cryoshakespeare> I don't know what you mean by that. I tried just running make, but it said it make was not a found command :P
09:52:54 <cryoshakespeare> Which is an odd discrepancy between msys2 and powershell in this case.
09:53:02 <truebrain> you are in a msys bash? This black background with white letters?
09:54:01 <cryoshakespeare> I'm not sure actually. There were a lot of exe options in the msys64 folder, so I just went for msys2.exe
09:54:19 <truebrain> it should be in your start menu after installation, I believe
09:54:46 <truebrain> well, maybe others can guide you better here; but it seems you didn't install the right tools in the msys system there
09:55:00 <truebrain> not sure what guide you followed πŸ™‚ So hard to guess how your system turned out now
09:55:27 <truebrain> as mentioned earlier, using WSL2 is far easier, as that gives you an actual Linux shell, instead of this hybrid you currently have; it is always a bit challenging to figure out how a setup turned out πŸ˜„
09:55:28 <cryoshakespeare> It seems quite possible! Sorry for all the basic questions. I'll take a look to specifically intalling bash.
09:55:40 <wormnest[m]> You should start from the start menu, but usually not the Msys2 one.
09:55:43 <cryoshakespeare> Yeah, I think I managed to install wsl2?
09:56:10 <cryoshakespeare> I just ran wsl --install or whatever the command was in powershell admin, then restarted
09:56:23 <truebrain> so now go to the Windows Store, and install Ubuntu
09:56:27 <wormnest[m]> Use mingw64 or ucrt, or... Depending for which version you installed deps
09:57:20 <truebrain> GnuWin hasn't been updated in 10 years, lol
10:06:44 <cryoshakespeare> Same errors, different shell :gui_company: (did this from wsl2):
10:06:44 <cryoshakespeare> `make[1]: Entering directory '/mnt/c/Users/cryos/Downloads/ogfx-landscape-1.1.2-source'
10:06:44 <cryoshakespeare> [GIMP-SCRIPT] Makefile_gfx.dep
10:06:44 <cryoshakespeare> [GIMP] src/gfx/water/river_water.gimp.png
10:06:44 <cryoshakespeare> /bin/sh: 1: : Permission denied
10:06:46 <cryoshakespeare> make[1]: *** [Makefile_gfx:11: src/gfx/water/river_water.gimp.png] Error 127
10:06:46 <cryoshakespeare> rm src/gfx/water/river_water.gimp.scm`
10:07:15 <truebrain> that is with just `make` ?
10:07:39 <cryoshakespeare> that was from doing `make -f makefile GIMP=`, not setting GIMP= brought back the old error
10:07:47 <cryoshakespeare> after cding to the directory
10:07:52 <truebrain> what is "the old error"?
10:07:59 <truebrain> just forget about `GIMP=` now, now you are in a Linux-env
10:08:09 <cryoshakespeare> gimp not found or specified was the old error
10:08:44 <truebrain> where did you get the source from? (too lazy to look it up myself)
10:09:27 <cryoshakespeare> Emperor Jake here linked it to me since it wasn't on github:
10:10:14 <truebrain> ah, okay, yeah, ogfx+landscape .. andythenorth is a poopy liar πŸ˜„
10:10:32 <truebrain> `sudo apt install gimp` will solve one part of this problem
10:10:41 <alfagamma_0007> Gimp
10:10:49 <alfagamma_0007> Splendid piece of software
10:11:01 <andythenorth> oh we what now? ogfx+
10:11:04 <andythenorth> oops
10:11:08 <cryoshakespeare> I have gimp though already, strange
10:11:09 <truebrain> yes, "oops" indeed πŸ˜›
10:11:14 <truebrain> not in your WSL setup
10:11:19 <truebrain> that is totally isolated from your Windows
10:11:23 <truebrain> (which is kinda the point πŸ˜„ )
10:11:23 <cryoshakespeare> Ahh
10:11:46 <cryoshakespeare> package gimp is not available πŸ€”
10:11:55 <truebrain> `sudo apt update` first
10:12:12 <cryoshakespeare> The plot thickens
10:12:31 <alfagamma_0007> WSL is debian ?
10:12:34 <cryoshakespeare> This is probably a good gateway drug for me getting into Linux, I've been meaning to make the switch for a while
10:12:34 <alfagamma_0007> Woah
10:12:41 <alfagamma_0007> Good
10:12:47 <alfagamma_0007> Try linux mint
10:13:17 <alfagamma_0007> It's a good beginner friendly linux distro
10:13:42 <truebrain> this Makefile ... wauw ... it is ... yeah, difficult πŸ˜›
10:14:31 <truebrain> after installing gimp, run `rm Makefile_gfx.dep Makefile_gfx`, and run `make` again
10:18:19 <cryoshakespeare> truebrain: `$ rm Makefile_gfx.dep Makefile_gfx
10:18:19 <cryoshakespeare> rm: cannot remove 'Makefile_gfx.dep': No such file or directory
10:18:19 <cryoshakespeare> rm: cannot remove 'Makefile_gfx': No such file or directory`
10:18:19 <cryoshakespeare> πŸ‘€
10:18:26 <truebrain> run `make` now
10:19:22 <andythenorth>
10:19:22 <andythenorth> made them fancier
10:21:33 <cryoshakespeare> cryoshakespeare: alright, `make -f makefile` in the folder returns exactly this error now
10:22:23 <truebrain> and you are sure there is no `Makefile_gfx.dep` in that folder?
10:22:57 <cryoshakespeare> Ohhh
10:22:59 <cryoshakespeare> In that folder
10:23:08 <truebrain> ..... yes, ofc in that folder πŸ˜›
10:23:52 <peter1139> Why am I punishing myself trying to run Linux natively...
10:24:29 *** D-HUND has joined #openttd
10:24:31 <peter1139> Installed a Linux game from GOG via "gamehub"
10:24:44 <truebrain> I hope it is OpenTTD? πŸ˜›
10:24:47 <cryoshakespeare> I used my meta-Linux powers and simply deleted those files in the windows folder, lo and behold, it seems to be working ._.
10:24:55 <peter1139> Starts up... Gnome errors and requires restarting...
10:24:56 <truebrain> gratz
10:25:27 <peter1139> OpenTTD works, of course :)
10:25:31 <cryoshakespeare> This is pretty huge, thank you so much TrueBrain, you have been a massive help through my relative noobishness
10:25:43 <truebrain> no worries; now enjoy a ... 1 hour? compile time πŸ˜›
10:25:48 <cryoshakespeare> To everyone else too, this has been quite a bit of error handling
10:25:57 <cryoshakespeare> Oh
10:26:12 <cryoshakespeare> Well, I should probably actually try and make the changes I wanted, instead of just compiling this with no edits.
10:26:39 <peter1139> Making sure compiling without edits works first is useful.
10:28:09 <cryoshakespeare> I'm only trying to do a very small subset of what ogfx+landscape does, which is to just allow me to swap desert/tropical terrain for something else, similar to the temperate grass for arctic toggle in the default mod.
10:28:52 <cryoshakespeare> But yeah, perhaps you are right. Perhaps... but it is a whole hour.
10:30:54 <cryoshakespeare> Is it possible for me to compile a version with only the desert/tropical terrain and whatever I switch it to, and then run that alongside the normal terrain grf, or do I have to specify some kind of overwrite procedure?
10:31:25 <alfagamma_0007> andythenorth: Lovely
10:31:34 <alfagamma_0007> Remasks?
10:33:36 <peter1139> Is it really 1 hour? Seems a lot...
10:34:47 <truebrain> I dunno if it is 1 hour
10:34:49 <truebrain> but it is slow
10:35:03 <frosch123> if you enable gimp it is slow
10:35:09 <truebrain> you can't not enable gimp
10:35:14 <frosch123> mostly because it starts/exits gimp 300 times or so
10:35:25 <truebrain> so that is a rather redundant remark πŸ˜›
10:35:29 <truebrain> πŸ˜„
10:35:54 <frosch123> no idea, quite some time since i built it πŸ™‚
10:36:04 <Eddi|zuHause> cryoshakespeare: any edits to the base grf you can also do with a (static) newgrf
10:36:17 <truebrain> andythenorth: was already a poopy liar for saying you don't need gimp; that is simply not true πŸ˜›
10:36:26 <cryoshakespeare> Eddi|zuHause: I have no idea what this is, but interesting
10:36:38 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #11217: Fix #11215: Assert in NewGRF parameters window (manual parameter mode)
10:36:59 <truebrain> is ogfx+landscape a base grf?
10:37:06 <truebrain> or do we all just selectively read ogfx, and stop reading?
10:38:25 <Eddi|zuHause> i didn't really see anything about what he was actually trying to edit. i was just assuming
10:38:35 <frosch123> the oldest file in my checkout is from 2011, the newest binary is from january 2015
10:38:36 <truebrain> you know what they say about assumptions πŸ™‚
10:38:37 <brickblock19280> I am not sure it could be it mostly changes the look of the terrain
10:39:10 <frosch123> it also adds objects, and can change industries
10:39:20 <frosch123> hmm, no industries is ogfx+industries
10:39:39 <frosch123> but i think landscape had a windgenerator object
10:40:15 <truebrain> and the Makefile is excellent πŸ˜›
10:40:16 <truebrain> hihi
10:40:24 <truebrain> I understand why it is what it is, but it short of a horror story πŸ˜„ (sorry)
10:40:28 <frosch123> yeah, all coop makefiles are like that
10:40:53 <truebrain> like, it uses `which` to find the `gimp` binary, which is good
10:40:59 <truebrain> but then overwrites that with just `gimp` to execute
10:41:08 <truebrain> as ... using the result of `which` is .. bad?
10:41:13 <frosch123> someone tried to write a makefile to rule them all, project N+1 copies the makefile and adds missing parts, and so on
10:41:32 <cryoshakespeare> It seems possible to me that this is all an overcomplicated way of trying to do what I want, which is just to give a parameter switch that will replace one terrain type with another. Do I even need to make a grf with any sprites in it for that, or can my grf manipulate the sprites provided by other grfs?
10:41:50 <truebrain> ah, yes, the "uber"-Makefile idiology ... I am so happy I can say I haven't written a Makefile of more than 20 lines in .. 5 years now? πŸ˜„
10:42:45 *** Wolf01 has joined #openttd
10:42:56 <Eddi|zuHause> and cmake is any better?
10:43:07 <brickblock19280> cryoshakespeare: It can not manipulate sprites from other grfs even if it would be really nice
10:43:15 <frosch123> cryoshakespeare: most of the sprites of other climates are inaccessible
10:43:27 <brickblock19280> oh yeah that too
10:43:31 <cryoshakespeare> I see
10:43:53 <cryoshakespeare> What about changing the colour palette of the tropical/desert sprites?
10:44:17 <_jgr_> Eddi|zuHause: It is if you want to support Windows as well
10:44:21 <cryoshakespeare> My main goal is just to make an option that gives it more of a drylands/savannah feel, rather than harsh desert and tropics
10:44:48 <brickblock19280> you could just use the sprites you want and override with them from a different grf
10:45:29 <cryoshakespeare> Hm, yeah, that might be simplest.
10:46:42 <cryoshakespeare> Now to figure out how to do all this, given I've only thus far made a grf which increases cargo capacity for the vanilla ships :P But, there's good documentation on this at least, rather than the difficult process of getting makefiles to work.
10:46:52 <brickblock19280> you will probably still be able to steal some of the code
10:47:36 <cryoshakespeare> Yeah, I was thinking I could just comment out some of the inclusions, to make compiling faster for one, and then edit the base sprites myself directly.
10:47:49 <cryoshakespeare> I don't know if that would break it, suppose I can test and see.
10:48:47 <brickblock19280> that could work but did you want to change them or just use other sprites?
10:50:01 <cryoshakespeare> I mean, either works. I'd be happy even just recolouring the terrain now, I find the contrast between the desert and the tropic tiles way too much extreme for my liking
10:50:55 <Eddi|zuHause> why do you need ogfx+landscape for that at all?
10:51:13 <Eddi|zuHause> just start a grf by yourself.
10:51:30 <cryoshakespeare> In principle I do not, but I have no idea what I'm doing and so I thought editing something which already works would be easier than building a newGRF from scratch
10:51:49 <Eddi|zuHause> try the newgrf tutoral...
10:52:22 <brickblock19280> all you need is a grf block which it seems that you already know and a simple replace block which you could just steal
10:52:26 <brickblock19280> that is it
10:52:42 <cryoshakespeare> Hm
10:53:15 <cryoshakespeare> *so you're saying all my work was pointless?* :P
10:53:29 <cryoshakespeare> Sounds like beginner development.
10:56:38 <Eddi|zuHause> the real adventure was the friends we made on the way... :p
11:06:00 <locosage> cryoshakespeare: here is a simple grf that replaces some terrain <>
11:06:06 <locosage> you can ignore all the river and meadow stuff
11:06:49 <locosage> but keep in mind that if you only replace some of the terrain sprites it will be visually broken if player uses different baseset
11:07:48 <cryoshakespeare> Thanks! I'll take a look at that
11:08:09 <cryoshakespeare> And yeah, I see. Well, seems like a future problem
11:34:13 <brickblock19280> you could always error when the wrong baseset is loaded this will kick people in multiplayer tho
11:40:57 <talltyler> So definitely don’t do that lol
11:41:16 <talltyler> I’d just replace all the terrain sprites for everyone
11:41:49 <talltyler> Like what OpenGFX+ Landscape does, which is why it can do stuff like gridless terrain or green grass with snow
11:43:16 <brickblock19280> you could look for opengfx+ landscape tho since I assume you want grid less that would be multiplayer safe
11:58:25 <Eddi|zuHause> i don't think grfs can disable themselves based on what baseset is loaded
11:59:24 <brickblock19280> they can look for the extra grf
11:59:32 <brickblock19280> not for ttd but for all others
12:03:14 <cryoshakespeare> with this `replace (3981, "gfx/grass_grid_temperate.gimp.png") { tmpl_groundsprites(1, 1) }`, I'm unsure of how I'd get this to replace the default terrain in the sub-tropic climate
12:04:11 <cryoshakespeare> Nevermind right now that this would be awful, but how do I specify replacing the sprite for the desert? As far as I can tell, the different base terrains for the climates are all 3981?
12:04:40 <brickblock19280> do you want to replace the desert or the grass?
12:04:57 <cryoshakespeare> Either, honestly, for now
12:05:28 <brickblock19280> the grass is just the code you have right there
12:06:06 <cryoshakespeare> Oh, I see. But this code as it stands would replace the base terrain for every climate?
12:07:03 <brickblock19280> yes but is that really a problem?
12:07:12 <brickblock19280> dessert is 4550
12:07:35 <brickblock19280> it can be changed with an if block checking climate
12:07:50 <cryoshakespeare> No, I was just confused. This was taken directly from that alpine set for citymania dP linked above^, and I figured the code was doing something which made it somehow only apply to arctic
12:08:10 <cryoshakespeare> I see, figured as much, thanks!
12:08:31 <cryoshakespeare> I think it may have just been that the code for that grf was unfinished.
12:08:46 <brickblock19280> you probably want to replace the half dessert half grass tiles as well I don't remember what sprite number that is
12:09:53 <brickblock19280>
12:10:05 <brickblock19280> I think there are constants somewhere
12:12:06 <cryoshakespeare> Thank you! I should be able to find them by poking around in the OpenGFX+ Landscape source
12:12:42 <brickblock19280> this has the constants
12:31:39 <_glx_> easy way to find base sprite number is the sprite aligner tool
12:54:00 <andythenorth>
12:54:00 <andythenorth> wonder why this is πŸ˜›
12:54:07 <andythenorth> I can't set that value
12:54:24 <truebrain> go via Game Options
12:54:30 <truebrain> why do we have 2 places to tell about autosave anyway πŸ˜›
12:54:33 <alfagamma_0007> There's a setting for this?
12:54:40 <alfagamma_0007> Oh we have
12:54:44 <alfagamma_0007> Smh me
12:59:49 <_glx_> checking locally
13:00:16 <truebrain> it is also in the nightly, no worries πŸ™‚
13:00:32 <_glx_> yeah that's what I was checking
13:00:43 <_glx_> you fix it or I do ?
13:00:43 <truebrain> I keep reminding myself to kick it out of the settings
13:00:47 <truebrain> go for it
13:02:47 <truebrain> I wanted to check if there were any other options both in settings and game options
13:03:02 <truebrain> I hope you can't change the video driver and refresh rate etc in settings πŸ˜›
13:09:25 <truebrain> (owh, btw, I am sure you found this by now, but in the latest autosave change I made, I forgot to change the type of the setting (from VAR to UINT<something>)
13:20:10 <_glx_> it's type = SLE_UINT32
13:20:34 <_glx_> and it's not in save anyway
13:20:47 <truebrain> I did fix it? I am shocked!
13:21:40 <truebrain> so I guess the next issue that pops to mind, is that I didn't rename the field in the settings GUI
13:22:09 <truebrain> I even did that!
13:22:17 <truebrain> this guy ... doing all the right things!
13:22:28 <truebrain> okay, then I will shut up and let you see what is broken / remove the setting πŸ˜„
13:33:39 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #11218: Fix 4f4810d: Remove autosave from settings window
13:34:06 <truebrain> it is not actually fixing that commit, is it?
13:34:37 <truebrain> it should in theory just work; still silly, but ..
13:34:59 <_glx_> I think this commit should have removed it from the window
13:35:00 <truebrain> I would say it is more a `Change`, with a footnote that since 4f48 it was broken anyway?
13:35:08 <truebrain> it should have been removed from that window ages ago
13:35:17 <truebrain> that commit doesn't add it to the game options πŸ™‚
13:35:44 <_glx_> I can always amend πŸ™‚
13:36:08 <truebrain> since r1 this has been in 2 places πŸ™‚
13:36:14 <truebrain> I more mention this, for ease of changelog
13:36:28 <truebrain> basically, #11218 makes a change, to no longer mention autosave interval in two places
13:36:42 <truebrain> this to hide a bug introduced by 4f48 .. I guess `{STRING2}` is the broken part πŸ˜›
13:37:36 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #11218: Change: Remove autosave from settings window
13:37:50 <truebrain> tnx πŸ™‚
13:37:56 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #11218: Change: Remove autosave from settings window
13:40:59 <_glx_> eints will remove the useless translations πŸ™‚
13:41:26 <truebrain> that it will .. WITH FIRE
13:43:37 <Azusa> Do I no longer need to translate blank to blank?
13:46:22 <_glx_> it was never required, except for completion counter
13:47:40 <_glx_> as translation fallbacks to base string
13:48:37 <truebrain> and I hope you only did it once πŸ˜›
13:51:16 <_glx_> oh I still "copy base string" for them else it's not 100% translated
14:29:52 <frosch123> truebrain: the idea of the settings tree was to have all settings, so you can use the filter for "different value"
14:30:11 <frosch123> that's why it also contains the settings from mapgen and game options, ...
14:30:22 <frosch123> well, except that it does not support all setting types :p
14:31:01 <truebrain> but there isn't resolution, or refresh rate
14:31:10 <frosch123> yes, those are not "supported" :p
14:31:13 <truebrain> or baseset πŸ˜›
14:31:23 <frosch123> i guess if autosave is no longer supported either, it can also go
14:31:26 <truebrain> is there any setting in Game Options that is also in settings ... πŸ˜›
14:31:41 <frosch123> maybe we removed the other settings from game options
14:31:48 <frosch123> it had driving side and town names and stuff
14:32:14 <truebrain> even currency is not in the settings πŸ˜„
14:32:40 <frosch123> yes, all dynamic dropdowns are not supported
14:32:47 <frosch123> only fixed ones
14:32:56 <truebrain> from what I can see in a quick 1-2-3, only autosave was in both πŸ˜„
14:33:06 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #11218: Change: Remove autosave from settings window
14:33:26 <frosch123> and before you ask: map size and coast settings are also not there, but all the other mapgen settings :p
14:35:40 <truebrain> I think especially for something like autosave (and resolution, en refresh-rate, etc etc) it is silly to have it in settings .. what the default value for these is, is not useful. Their aren't stored in savegames either. So mapgen can stay, that makes more sense πŸ™‚
14:36:40 <truebrain> as for why it didnt work in settings, it is not because it can't be supported .. it is now just a number πŸ˜›
14:36:47 <truebrain> I just didn't know the string had a {STRING2} in there
14:37:44 <_glx_> but in game option you are limited to the dropdown choices
14:37:58 <_glx_> which should be enough
14:38:02 <truebrain> yeah, because peter isn't finished with his PR yet πŸ˜›
14:38:23 <_glx_> of course any other value can be set via console
14:38:56 <truebrain> The intention is, if we can find a correct GUI element for it, to bring customization to the field
14:39:11 <truebrain> Or otherwise we can replicate the refresh rate approach
14:39:51 <truebrain> (Which had a "custom" entry as last item in the dropdown)
14:40:55 <frosch123> "custom" probably does not work in the tree either πŸ™‚
14:42:58 <truebrain> The three could just show the number πŸ˜› still silly to have things in two places, so let's not πŸ™‚
14:48:24 <truebrain> anyway, comments / approvals on my crashlog PRs? πŸ˜„
14:55:28 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11212: Remove: [Win32] register values in crash.log
14:59:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11212: Remove: [Win32] register values in crash.log
14:59:39 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11211: Remove: [MinGW] (pointer-only) stack trace in crash.log
15:00:42 <truebrain> _glx_: it actually isn't, but the code is so shit ... the duplication of the crashlog handling between the generic and windows one makes it impossible to see what is actually going on πŸ˜„
15:02:06 <truebrain> owh, it is, via via ... so wtf, that makes even less sense ...
15:02:39 <truebrain> `AppendDecodedStacktrace` is actually adding it for MSVC
15:02:54 <truebrain> but .. not by overloading that function ..
15:02:58 <truebrain> I just ..
15:03:47 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11211: Remove: [Win32] (pointer-only) stack trace in crash.log
15:04:11 <truebrain> after these PRs are in master, I have a PR that refactors most of the crashlog stuff back into a single flow again πŸ™‚
15:06:44 <truebrain> `Stack trace: A5C97D60 00000239 00000064 00000239 00000000 00000000 A373E870 00000239`
15:06:51 <truebrain> it is even worse than I imagined
15:06:55 <_glx_> oh macos does actally decode stack trace here
15:07:02 <truebrain> Linux does too
15:07:08 <truebrain> but Windows was like: I AM GOING TO DO IT MY WAY
15:07:22 <truebrain> and invented its own function for it πŸ˜›
15:07:32 <truebrain> most likely makes sense when you look at how it formed
15:07:42 <truebrain> but in the current state, it is just weirdddddddd πŸ˜„
15:08:19 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11211: Remove: [Win32] (pointer-only) stack trace in crash.log
15:08:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11211: Remove: [Win32] (pointer-only) stack trace in crash.log
15:08:24 <_jgr_> The way that exceptions are handled on Windows is totally different to POSIX, so it's not too surprising that it looks different
15:08:29 <alfagamma_0007> Pseudo proprietary software be like
15:08:37 <truebrain> _jgr_: not actually talking about how it is done
15:08:48 <truebrain> more that there is a function that does it on 2 OSes
15:08:54 <truebrain> but the 3rd is like: I am going to name this function differently
15:09:13 <truebrain> just code-wise it is odd πŸ™‚
15:10:20 <truebrain> so we have `LogStacktrace` for MacOS and Linux, but `AppendDecodedStacktrace` for Windows .. but also `LogStacktrace`, which doesn't decode it .. but it does on MacOS and Linux .. that is what I mean πŸ˜›
15:10:52 <Eddi|zuHause> yay for consistency!
15:11:34 <truebrain> if I would guess, it was just: owh, I can decode the stacktrace, but maybe for some reason someone added to the crashlog the non-decoded, so let's keep it, as I am not 100% sure I can remove it. At least, that is how I would think πŸ™‚
15:11:57 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11202: Add: use breakpad to create crash.dmp on MacOS / Linux too
15:12:10 <_jgr_> The non-decoded stack trace is totally useless, in practice
15:12:18 <truebrain> exactly πŸ™‚
15:12:30 <truebrain> so just a bit confused by this code .. but I am going to fix it!
15:12:34 <truebrain> and then people can yell I broke shit πŸ˜„
15:12:35 <_glx_> the decoded one isn't very useful if the pdb is not near the exe
15:12:37 <truebrain> tnx _glx_ !
15:13:53 <michi_cc[d]> If my memory isn't totally failing, the inital decodec stack trace for win was initially coded by me. The argument back then was to append it to the crash log afterwards as people where worried that some problem with the decoding might corrupt the exisitng croash log/save process.
15:14:23 <truebrain> I wasn't far off πŸ˜„
15:14:43 <michi_cc[d]> Linux/OSX might have come later.
15:14:46 <truebrain> ironically, the crash.log is only saved after the decoding is done πŸ˜›
15:14:56 <truebrain> so if it fails, nothing is logged anyway
15:14:59 <_jgr_> The vanilla crash log implementation won't output anything at all if the crash logger fails part way through, so putting it near the end doesn't really help
15:15:08 <truebrain> πŸ˜„
15:15:27 <michi_cc[d]> I think it used to be differently once, but in some code change it was probably forgotten.
15:15:34 <truebrain> as that goes πŸ™‚
15:15:39 <truebrain> anyway, cleanup time πŸ™‚
15:16:12 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11202: Add: use breakpad to create crash.dmp on MacOS / Linux too
15:16:35 <truebrain> will take a few more PRs to get there, but we will get there πŸ™‚
15:19:01 <truebrain> not 100% sure why we calculate a CRC for the Module information on Windows
15:19:07 <truebrain> is that something universal to do?
15:19:25 <truebrain> (similar, why do we print the filesize, I am not sure about)
15:19:52 <truebrain> `C:\WINDOWS\System32\ksuser.dll handle: 00007FFB17C80000 size: 23264 crc: A73C3DE9 date: 2019-12-07 09:08:07` for reference
15:20:06 <truebrain> the handle and date I can understand. The size .. I guess? but the crc puzzles me
15:22:02 <truebrain> (mainly what triggers me about it, we actually read those DLL files to calculate the CRC on crash .. which feels like a really odd thing to do)
15:22:46 <_jgr_> "DLL hell" used to be a bit of a problem on Windows
15:22:54 <_jgr_> Probably related to that?
15:23:09 <truebrain> I guess .. did you ever use that information? The CRC and filesize?
15:23:25 <_jgr_> No, I just ignore the whole module section
15:23:40 <truebrain> I do use that section to find the GPU driver, and how old it is
15:23:45 <truebrain> for that I have noticed it is useful
15:25:50 <truebrain> it already existed in the r1 revision
15:25:56 <truebrain> so I guess ... "reasons"
15:26:06 <truebrain> _glx_: did you ever use the CRC and/or filesize?
15:26:33 <truebrain> otherwise I vote to remove it; doing less on crashes is better πŸ™‚
15:35:36 <_glx_> size and crc I'd say never
15:36:51 <truebrain> So burning it with fire, check!
15:38:33 <_glx_> and for the exact dll version I get it from minidump (always fun to look for video driver dlls)
15:39:59 <_glx_> well not having the dll doesn't prevent opening, but it's better to have the dll
15:40:18 <_glx_> especially when the crash is inside it
16:04:12 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11214: Fix: Road stops should not draw a ground sprite of 0
16:10:44 <frosch123> truebrain: whatever the stacktrace looks like now, in 3 years it will look like
16:11:45 <truebrain> can't wait
16:12:12 <truebrain> I like how the example shows that compilers will show different layouts
16:12:29 <truebrain> I especially hate GCC's output already πŸ˜„
16:13:00 *** Wormnest has joined #openttd
16:15:41 <frosch123> wtf. they defined std::hash for stacktraces
16:16:00 <frosch123> when do you need stacktraces as map keys?
16:17:01 <frosch123> anyhow, looks like there is no module information in it
16:17:40 <truebrain> so just remove all of the module info, you say? πŸ˜„
16:18:31 <frosch123> kind of, unless someone considers it important enough to keep a custom implementation in the future
16:19:02 <truebrain> as mentioned, the only reason I use it to eyeball if someone updated their GPU-driver ... not really -that- important, honestly
16:19:24 <frosch123> isn't that info already in the opengl version
16:19:25 <truebrain> and I was not looking forward to adding similar functionality to Linux and MacOS πŸ˜›
16:19:33 <frosch123> it's visible in game options, not sure about crashlog
16:19:36 <truebrain> depends on the GPU driver if they include a version
16:20:04 <truebrain> but the date is just the create-date, so it is also not always the right conclusion I draw πŸ˜›
16:20:45 <frosch123> do you conclude more than "it's the intel driver, so not our bug"
16:21:08 <truebrain> yeah, for NVidia I had one case where I was like: your driver is 4 years old .. maybe update?
16:21:18 <truebrain> but the OpenGL string also tells me that
16:21:20 <truebrain> so that is fine
16:24:27 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11219: Remove: [Win32] module-list from crash.log
16:24:40 <truebrain> so much removal, I await a nasty tt-forums post
16:25:26 <truebrain> removing the module-list is kinda nice, as now the crashlog information is even more similar to survey information .. so unifying them would be nice, less duplicated gathering of system information πŸ˜„
16:35:27 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #11220: Codechange: [Win32] unify AppendDecodedStacktrace and LogStacktrace
16:35:54 <truebrain> there we go, another step closer to similar crashlog implementations πŸ˜„
16:36:17 <truebrain> now do I integrate the mingw backtrace decoder from JGRPP .. hmm .. not now, maybe later.
16:36:41 <truebrain> (as it would require me to setup a mingw dev-env ... and I don't feel like doing that atm πŸ˜› )
16:37:29 <DorpsGek> [OpenTTD/OpenTTD] michicc approved pull request #11220: Codechange: [Win32] unify AppendDecodedStacktrace and LogStacktrace
16:48:12 *** nielsm has joined #openttd
17:04:37 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11219: Remove: [Win32] module-list from crash.log
17:09:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11219: Remove: [Win32] module-list from crash.log
17:54:19 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain dismissed a review for pull request #11220: Codechange: [Win32] unify AppendDecodedStacktrace and LogStacktrace
17:54:21 <truebrain> rebase ^^ (I was wondering why automerge didn't kick in)
17:54:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11220: Codechange: [Win32] unify AppendDecodedStacktrace and LogStacktrace
17:58:20 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11220: Codechange: [Win32] unify AppendDecodedStacktrace and LogStacktrace
18:05:55 *** esselfe has quit IRC (Ping timeout: 480 seconds)
18:11:25 *** kolcon has joined #openttd
18:11:49 <kolcon> hi, where do I enable multi-cargo ships in jgrpp?
18:39:17 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:39:18 <DorpsGek> - Update: Translations from eints (by translators)
18:57:05 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #11220: Codechange: [Win32] unify AppendDecodedStacktrace and LogStacktrace
19:41:20 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #11221: Codechange: Break up date_type.h into timer classes
19:42:32 <talltyler> Oof, such fun with includes and class identifiers
19:46:22 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler merged pull request #11214: Fix: Road stops should not draw a ground sprite of 0
19:46:43 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler approved pull request #11217: Fix #11215: Assert in NewGRF parameters window (manual parameter mode)
19:50:05 <talltyler> TallTylerviaGitHub: As we discussed, truebrain πŸ™‚
19:57:15 *** gelignite has quit IRC (Quit: Stay safe!)
20:05:14 *** bryjen has joined #openttd
20:24:35 *** esselfe has joined #openttd
20:25:23 <FLHerne> kolcon: JGRPP makes it possible (unconditionally) for NewGRFs to provide ships that carry more than one cargo
20:25:55 <FLHerne> so you'd use the feature by loading a ship grf that does; I don't know if any of those actually exist yet
20:26:35 *** D-HUND has quit IRC (Quit: - Chat comfortably. Anywhere.)
20:29:06 <andythenorth> goes it I switch to JGRPP?
20:29:14 <andythenorth> it's quite a lot more advanced on grf
20:30:02 <_jgr_> There are /that/ many changes
20:31:24 *** bryjen has quit IRC (Quit: Leaving)
20:32:43 <_jgr_> That said, if you make GRFs which don't work in vanilla, I'd expect that you'd soon have a full inbox πŸ˜›
20:33:06 <andythenorth> this discord seems to believe everyone plays JGRPP πŸ˜„
20:33:16 <andythenorth> I think the stats are somewhat different so far πŸ™‚
20:36:26 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11142: Feature: Setting to automatically restart dedicated server based on hours played
20:39:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:41:09 <andythenorth> oops my build doesn't include
20:41:13 <andythenorth> so my GS crashed πŸ˜›
21:13:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #11222: Fix #11181: attempting to read string as int triggers assertion
21:14:40 <andythenorth> `2023-08-20 22:14:05.704 openttd[24376:2597764] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'`
21:15:04 <andythenorth> ^ can post crashlog if helpful, game contains as usual unreleased grfs and GS
21:30:58 *** Deep3D has joined #openttd
21:37:33 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:49:26 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #11222: Fix #11181: attempting to read string as int triggers assertion
21:50:14 <_glx_> andythenorth: GS and grf are most likely not the cause
21:52:15 <_glx_> but crashlog is a must
21:56:00 <andythenorth> I wish the mac build crash logs didn't leak usernames by default
21:56:10 <andythenorth> I have to remember to redact them every time
21:57:46 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #11222: Fix #11181: attempting to read string as int triggers assertion
21:57:49 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #11181: [Crash]: in string handling
21:57:51 <andythenorth> wait, we have new crash logs?
21:57:59 <andythenorth> seems they are segmented by date now?
21:59:49 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:01:37 <DorpsGek> [OpenTTD/OpenTTD] andythenorth opened issue #11223: [Crash]: 'NSWindow drag regions should only be invalidated on the Main Thread!'
22:02:34 <andythenorth> no username in the current crash logs πŸ™‚
22:06:42 <andythenorth> and again, similar crash
22:07:58 <DorpsGek> [OpenTTD/OpenTTD] andythenorth commented on issue #11223: [Crash]: 'NSWindow drag regions should only be invalidated on the Main Thread!'
22:08:46 <andythenorth> and again
22:08:51 <andythenorth> ok quite unplayable πŸ˜„
22:29:09 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on issue #11223: [Crash]: 'NSWindow drag regions should only be invalidated on the Main Thread!'
22:37:21 * andythenorth pulls
22:37:32 <andythenorth> looks like I need to install unofficial-breakpad?
22:42:24 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #11223: [Crash]: 'NSWindow drag regions should only be invalidated on the Main Thread!'
22:42:42 <_glx_> breakpad is optional
22:43:55 <_glx_> it is only needed to generate crash dumps, and they are not usable for custom builds
22:54:45 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)