IRC logs for #openttd on OFTC at 2024-02-02
โด go to previous day
00:02:21 <_glx_> and of course now I can't reproduce the timeout
00:05:19 <truebrain> _glx_: Change dns to local host should do the trick ๐
00:05:57 <wensimehrp> Is there a way to fix this?
00:07:13 <truebrain> Without any doubt; just someone would have to put in the effort ๐
00:07:39 <truebrain> Just make a bug out of it, easier and more visible ๐
00:08:26 <wensimehrp> I won't say it's a bug... More of an enchantment on localization.
00:08:47 <truebrain> It is a bug you can't translate it to your language ๐
00:09:11 <wensimehrp> Technically I can, it's just that nobody uses that kind of format
00:09:30 <truebrain> So practically you can't ๐
00:09:34 <wensimehrp> But yeah, localization thingy
00:10:14 <truebrain> You have to know, there are so many languages in the world, and many methods look foreign to most of us. So we need these kind of input to know about what is needed
00:11:20 <truebrain> As example, I live in a world where there is one or many. Never did I know before OpenTTD there was so many more counting systems
00:11:26 <_glx_> oh for once it looks like a clean fix
00:11:33 *** Wormnest has joined #openttd
00:12:31 <_glx_> of course description is off
00:14:57 <truebrain> @glx: do I read it right 11950 fixes the symptom, and only for one case? Guess a proper fix is to restore settings to their newgame variant, not?
00:16:15 <_glx_> well restoring all settings will be harder, ideally running AI and `start_ai` should not affect game_settings at all
00:16:53 <_glx_> but at least when a random ai is stopped it will return to random for next start
00:17:11 <LordAro> perfection enemy of progress, etc
00:17:24 <truebrain> Yeah, but seems a point solutions which will bite us in the ass the next day ๐
00:17:24 <LordAro> if it fixes xarick's issues, and isn't too overly complex, why not?
00:18:01 <_glx_> ai_config is a mess ๐
00:18:04 <truebrain> LordAro: It fixes one of the two problems with an identical cause ๐
00:19:15 <_glx_> but deviation+random ai can be fixed with adding AIConfig field to company
00:19:34 <truebrain> There are so many bloody functions in the AI code to fix edge cases instead of fixing the problem ๐
00:19:43 <_glx_> will not fix `start_ai` overwritting slots
00:20:39 <truebrain> I was thinking about storing the original value in the ScriptConfig
00:21:12 <truebrain> _glx_: Overwriting slots? What do you mean?
00:23:47 <truebrain> If it cannot start an AI, it tries the version less variant .. what does that hurt?
00:24:11 <truebrain> A restart still won't find the original either, I guess?
00:24:31 <_glx_> no it does change the configured AI in the slot when you use `start_ai <AI>`
00:24:48 <truebrain> Owwhhh, you can say what AI to start, haha, forgot about that
00:25:02 <truebrain> Again a place that overwrites the configuration ๐
00:25:47 <truebrain> Yeah, we need to store the config at start, and revert to that, and fix all these issues in one swoop
00:25:56 <truebrain> Otherwise we keep on plugging holes
00:27:21 <truebrain> Only an issue with "restart", not? The rest should already revert?
00:27:26 <_glx_> or just copy newgame over game, like before start
00:28:09 <_glx_> the ai_config part only of course
00:28:30 <truebrain> Yeah, what I suggested earlier I guess .. but I still wonder if "restart" shouldn't revert all settings
00:28:49 <truebrain> Would also be a trivial fix
00:29:27 <_glx_> but the random ai fix still is a good idea
00:29:51 <_glx_> like if you click restart ai in debug window for a random AI
00:30:23 <truebrain> Haha, the restart AI was intentionally build to reset that exact AI ๐
00:30:30 <truebrain> Doesn't mean it still makes sense btw
00:30:41 <truebrain> But it was designed for exactly that ๐
00:31:13 <_glx_> for fixed AI it won't change anything
00:31:25 <truebrain> No, was also meant for Random AI
00:31:38 <truebrain> So when it crashes you can restart it and that AI goes again ๐
00:32:05 <truebrain> Again, not saying we still want that, but was useful when working on AIs ๐
00:32:36 <truebrain> As you cannot see it was random anymore, people would "get confused", bladiebla
00:32:40 <_glx_> but indeed might not be needed with proper `restart`
00:33:21 <truebrain> No, I think the question is: should restart AI get a new random one, or restart that AI
00:33:30 <truebrain> And it is a valid question
00:34:09 <rau117> What about extending the breakdown protection period?
00:34:09 <rau117> Now it's about 40 days. Extend to 365 days, then breakdowns will become more determinant and, as a result, playable. Then it will be possible to use just one depot complex per route, which also can be used for [auto]separation. Will also fit to changes in maximum delivery time/cargo aging
00:35:25 <truebrain> I can argue both cases in my head, what is right .. guess one is restart and the other reload?
00:40:45 <truebrain> Also really want to clean up the settings_profile mess .. so much things to do, so little time to do it in ๐
00:44:15 <_glx_> seems I have a working fix ๐
00:44:34 <_glx_> (it says "can't connect")
00:45:18 <truebrain> Btw, what if we just make 'restart' do 'newgame <seed of map>'?
00:47:04 <truebrain> Owh, funny, restart is made explicitly to not do that ๐
00:47:13 <truebrain> What a lovely contradiction ๐
00:47:59 <truebrain> One line says it wants to reproduce the exact game, the next says it can't ๐
00:51:00 <_glx_> doesn't `restart` do `reload` when it's from a savegame ?
00:53:30 <_glx_> and the nice thing is they are not failed jobs
00:55:44 <truebrain> It doesn't code-wise, but I think that is the solution: make it run newgame if it was a newgame, and reload if not
00:56:03 <truebrain> As restart is a developer command, that should cover all common cases
00:56:22 <truebrain> As most of the time you actually just want a newgame with the same seed
00:56:37 <truebrain> And if you use a savegame, best we can do is reload the game
00:57:03 <truebrain> Does mean in a savegame the AIs don't revert back, but there is also nothing we know to revert back to
00:57:21 <_glx_> hmm using FS2OTTD might not be smart actually, because the global buffer and threads
00:57:56 <truebrain> If it isn't threadsafe, that would be an issue ๐ฆ
00:58:06 <_glx_> I can use convert_from_fs and a local buffer
00:58:23 <truebrain> But why filesystem macros?
00:58:44 <truebrain> Or just badly named macro? ๐
01:00:27 <_glx_> comes from the time it was used only for file stuff
01:00:48 <truebrain> I totally see that being the case ๐
01:00:49 <_glx_> but it's indeed used anytime we talk to win32 API
01:01:13 <truebrain> Funny, how that grows ๐
01:01:36 <_glx_> and renaming now will just be annoying
01:01:43 <_glx_> we are used to the name
01:02:55 <truebrain> Do we know if a game was loaded .. hmm
01:04:21 <truebrain> _file_to_saveload.abstract_ftype
01:07:18 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:41:57 *** Wormnest has joined #openttd
01:55:55 *** Test_User has quit IRC (Quit: .)
03:16:21 *** Wormnest has quit IRC (Quit: Leaving)
03:25:50 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:32:05 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
05:29:09 <wensimehrp> oof, found another place where line changes might be werid...
05:35:46 <Rubidium> _glx_: what global buffers for FS2OTTD? It doesn't seem to use a global buffer
06:25:56 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:39:09 <emperorjake> Shouldn't this be greyed out if it can't be changed in-game?
06:43:12 <_zephyris> talltyler: talltyler there was a little chat. The classic variant is pretty good now, but needs more testing and bug reports
07:01:10 <_zephyris> Bug reports have slowed down, but it probably still needs focused testing by more eyes
07:59:52 *** nanapipirara has quit IRC (Quit: User went offline on Discord a while ago)
08:02:39 <truebrain> emperorjake: isn't it greyed out? Guess you talk about the other option ๐
08:05:49 <emperorjake> Yeah, the minutes per year
08:06:58 <emperorjake> it's not relevant in the traditional calendar timekeeping, and it's not changeable in-game in the wallclock based system. But in neither case is it greyed out
08:07:36 <truebrain> One for talltyler ๐
08:07:55 <emperorjake> Correction, it is changeable in-game now if it's set to wall clock
08:08:09 <emperorjake> seems to have changed from an earlier build
08:11:03 <merni> locosage: Yes, TB has one on github, but it just reads into a JSON representation of the savegame chunks. Still needs much interpretation.
08:14:06 <truebrain> can Excel read JSON files?
08:14:29 <truebrain> wouldnt a CSV not be better, in that case?
08:14:54 <merni> the fields vary depending on the type of order, though
08:17:48 <merni> I would prefer to leave to an external tool the job of converting it into any other representation, taking only the data that is wanted in some particular case. Or even something like https://www.tt-forums.net/viewtopic.php?t=89538 might read the json directly and present it
08:18:12 <truebrain> you just triggered me with Excel; so I was wondering
08:20:00 <truebrain> I am always surprised what kind of stuff people make ... people take this game wayyyy to serious, with all this timetable stuff ๐ But who I am to judge ๐
08:20:25 <merni> there are even more realistic programs like JTrainGraph and FPLEdit which are intended for RL railway enthusiasts/modellers
08:28:27 <truebrain> _jgr_: looking at how you fixed 11922, that kinda works, just don't reference a string, copy it ๐
08:29:10 <truebrain> You say: "for the time being", you plan to pick up allowing string references, or is that more like: this is not ideal, but at least doesn't corrupt memory?
08:33:02 <_jgr_> It's more that I wanted to do a release, and the temporary fix is a heavy handed way of making the problem go away until it's fixed in a more refined way
08:33:27 <truebrain> I have to admit, I kinda like this way ๐ Just remove any potential this ever becoming a problem again ๐
08:34:10 <truebrain> I normally would ask: mind if I PR it? But I know your answer to that by now ๐ Mostly curious if peter has a better solution in mind ๐
08:34:41 <peter1138[d]> Not fully yet, what I was working on is more intrusive.
08:35:38 <peter1138[d]> We deliberately use non-owning strings to avoid making copies of strings everywhere, but how much of a problem that really is I don't know.
08:36:53 <truebrain> ErrorWindow, Tooltip, QueryWindow, News window, they are non-issues, ofc. The ones I worry about is the news-ticker and texteffects, that might be a bit more problemetic.
08:39:24 <truebrain> TextEffect is never used with a string, so that helps ๐
08:40:17 <truebrain> funny .. error window just copies 20 params, news window copies just 10
08:40:22 <truebrain> why 20 or 10? Who knows! ๐
08:46:07 <truebrain> don't we have a way to discover how many dparams will be used to render a string?
08:48:34 <truebrain> now I also understand why I could trigger it more often with ErrorWindow than any other
08:48:44 <truebrain> it basically copies all parameters ๐
08:52:12 <truebrain> peter1138[d]: Couldn't we just put a tracker on DParam get access to evaluate the number? ๐
09:02:42 <_zephyris> talltyler: Checked my notes - the only thing outstanding that I'd like to do is revise the light signals. Everything else _should_ be done!
09:02:55 <peter1138[d]> I need to report more bugs then ๐
09:03:21 <peter1138[d]> And/or make sure I have the latest version.
09:08:01 <peter1138[d]> I definitely don't ๐
09:09:59 <truebrain> ah, the loveliness called `const` on a member ... can't even write a cache that way .. ๐
09:10:33 <truebrain> why don't I know about that?
09:10:43 <_zephyris> peter1138[d]: Yes please, more bugs please!
09:10:48 <peter1138[d]> Because you don't like abusing things ๐
09:11:28 <truebrain> that actually works ๐ฎ
09:29:26 <truebrain> meh; okay, News is called a lot more often than I expected. Still not terribly a lot, but also not not-often ๐
09:29:49 <peter1138[d]> `ClearDParam()` was an option I considered.
09:30:32 <peter1138[d]> But I couldn't think of a compile-time way to ensure it is always called when needed.
09:31:17 <truebrain> I just wrote some ugly code to track the highest parameter accessed; that kinda works, but how the string system works, it won't catch the highest in all cases (which is terrible, so we can't use it ๐ )
09:31:23 <peter1138[d]> The most intrusive way was to use a local parameter array instead of copying into and out of global parameters.
09:33:06 <truebrain> I was wondering why the error message was copying 20 parameters
09:33:12 <truebrain> but ... NewGRFs ๐
09:33:51 <truebrain> peter1138[d]: honestly, I kinda like this idea
09:34:05 <truebrain> the code has matured enough that it isn't even less readable
09:34:21 <truebrain> it forces compile-time for people to do the right thing
09:34:43 <truebrain> and drops the CopyOut (and CopyIn I guess) completely
09:35:41 <truebrain> the other solution is what `GuiShowTooltips` already does
09:35:49 <truebrain> and add a `param_count` to the remaining users of CopyOut
09:35:59 <truebrain> not sure why only `GuiShowTooltips` does that, tbh
09:36:38 <truebrain> well, sometimes it is wrong
09:36:53 <truebrain> linkgraph_gui sets 6 dparams, and gives 7 to the function ๐
09:37:18 <truebrain> doesn't break, ofc; but is also not helping ๐
09:41:05 <peter1138[d]> Yes, passing a number is not that helpful.
09:41:19 <peter1138[d]> It can vary depending on sub-parameters.
09:42:09 <truebrain> so yeah, if we would make a local parameters and request that the `params` that CopyOut is filling is given by the caller, we shouldn't have any troubles anymore
09:42:26 <truebrain> we just have to take ownership of the local parameters, I guess
09:42:55 <truebrain> sounds like a robust solution; just a lot of work ๐
09:43:55 <peter1138[d]> For news messages, I tweaked it so that you add the "idea" of the news message, and it returns a "string parameter array" to fill.
09:44:09 <peter1138[d]> If I can find that patch...
09:44:20 <truebrain> that also isn't a bad approach ๐
09:44:29 <truebrain> I now imagine you doing `git branch` and go: hmmmmmmmmm
09:45:24 <peter1138[d]> It's not unlikely that I called a branch "hmmmmmmmmm"
09:45:36 <truebrain> I am not even surprised ๐
09:51:51 <truebrain> meh, okay, not completely trivial to have users send params with the function .. `ArrayStringParameters` is bound in size compile-time ๐
09:53:28 <peter1138[d]> Means a lot of copying...
09:53:45 <truebrain> which was what we wanted to avoid ๐
09:53:57 <peter1138[d]> Or a unique_ptr I suppose
09:55:44 <truebrain> I was trying with `std::move` first, but it seems I am just not capable of doing that ๐
09:56:01 <truebrain> which is a skill issue, not a compiler issue ๐
09:56:22 <truebrain> StringParameter vs StringParameters ...
09:56:29 <peter1138[d]> StringParameter is one.
09:56:32 <peter1138[d]> StringParameters is multiple.
09:58:10 <peter1138[d]> Alright, bilinear sprite scaling does not know about tile edges.
10:11:55 <truebrain> lol, this does mean giving access to `strings_internal` to more places
10:11:58 <truebrain> getting less and less internal
10:12:03 <truebrain> meh; might be able to clean that up a bit
10:14:31 <truebrain> include-cycles, w00p!
10:15:34 <truebrain> nothing some well places `class` can't fix, ofc
10:18:29 <truebrain> okay ... I was trying to copy a `StringParameters` into `_global_string_params`, but this is more tricky than I was hoping for ... lol
10:22:29 <peter1138[d]> truebrain: With std::variant inside StringParameter that should be simpler. Yes, that is also a patch.
10:22:39 <truebrain> lol; yes, it would be
10:22:54 <truebrain> which also showed me another issue to deal with .. the StringParametersBackup copies the string
10:23:18 <merni> peter, how many patches do you have?
10:23:30 <peter1138[d]> Yes, and StringParametersBackup doesn't have a non-owning version, "coincidentally"
10:24:44 <peter1138[d]> I have directories of old patches from before 2008 lying around still.
10:25:50 <peter1138[d]> The timestamps have been lost at some point though ๐
10:26:12 <_zephyris> peter1138[d]: Pad with 1px transparent before scaling.
10:28:35 <_zephyris> As a slightly related note, I think sprites are downsampled using every 2^n th pixel from the top left of the sprite. So, adding 1 px to the top edge changes the appearance when zoomed out. It'd be nicer to sample in a sprite size-independent way, eg. sampling relative to the sprite origin given its x,y offset
10:28:49 <_zephyris> (but maybe too much work for too little gain)
10:35:23 <peter1138[d]> When downscaling, the algorithm prefers the second pixel across, unless it's transparent in which case it takes the first pixel across.
10:36:12 <peter1138[d]> But it only does that for one row -- and it takes the second row, the first row is always completely ignored.
10:36:54 <peter1138[d]> This is why thin horizontal details can lost, but thin vertical details should be retained.
10:38:23 <peter1138[d]> Hmm, sorry, wrong way around.
10:38:30 <peter1138[d]> It takes the first row and ignores the second row.
10:38:54 <peter1138[d]> Same result though.
10:43:42 <truebrain> ah, safety .. your password must be between 8 and 16 characters
10:43:44 <truebrain> as that makes sense
10:45:16 <peter1138[d]> For your security you are not allowed to copy & paste...
10:45:42 <truebrain> I tried to generate 7 new passwords, all were rejected, while it complies with the rules ... what-ever, stupid system, I will not be changing my password now
10:46:09 <truebrain> lol, my code has a bug .. at least, I think it is my code .. now sometimes the texteffect has `...` instead of a number ๐
10:50:58 <andythenorth> more than 16 characters leaks information
10:51:08 <andythenorth> like...you can name all your cats and dogs with that many chars
10:53:25 <truebrain> okay, texteffect just acts weird, and I don't see why .. ugh
10:54:49 <peter1138[d]> With my std::variant patch I tried to simply remove the non-owning version, and ended up with fios windows messing up.
10:55:18 <truebrain> I just now have texteffects that sometimes have the cost, but sometimes just `...`
10:55:21 <truebrain> and I don't understand why ๐
10:55:24 <peter1138[d]> Also apparently we asked Rubidium to not use std::variant there, as he seemed surprised when I used it.
10:55:36 <peter1138[d]> I don't know why or when we did that though.
10:55:57 <truebrain> maybe when we were scared of variants ๐
10:56:09 <peter1138[d]> It wasn't that long ago he was revamping the string system.
10:56:36 <peter1138[d]> But the current std::unique_ptr<std::string>> is clearly a work around for trying to know what type of parameter is there.
10:56:56 <truebrain> yeah ... we might have had the wrong opinion ๐
10:56:58 <truebrain> shocker, I know ๐
10:57:53 <truebrain> okay, I need to debug this a bit more, see if it is actually my code, or a bug that was just hiding because of how things used to be copied ..
11:01:23 <Rubidium> if you want to go for std::variant, that's fine by me. It's just that someone was against it in the PR
11:05:19 <Rubidium> not sure anymore why I tried to avoid copying the string
11:12:08 <peter1138[d]> (Just verifying it wasn't me, hehe)
11:13:01 <peter1138[d]> And yes, not copying the string would've been for performance reasons, but it probably isn't something to worry about in the grand scheme of things.
11:13:18 <peter1138[d]> Needs measurements instead of vague handwavy "might be a problem"
11:13:57 <truebrain> So undraft my PR and go? ๐
11:14:43 <truebrain> Still, not doing CopyOut from the global parameters would be better, I guess. More controlled ๐
11:15:48 <Rubidium> truebrain: I guess the "best" solution would be to just populate a new StringParameters for each call/function, instead of the global one. But I also reckon that's 15 territory
11:16:31 <truebrain> That is what I am doing, so I think we have some nice agreement there ๐
11:16:56 <peter1138[d]> Not "randomly" crashing should be fixed for 14 though ๐
11:17:35 <truebrain> Yeah, either the draft PR goes in 14 or I am in time to make a "proper" fix ๐
11:54:46 <peter1138[d]> Nice, a crashlog so long the gamelog is truncated.
11:55:55 <peter1138[d]> 1800 lines of NewGRF changes...
11:58:11 <peter1138[d]> Might just be a bug though, it says they're all at tick 1280.
11:58:44 <peter1138[d]> Or ticks are frozen, it's a JGRPP log, I was just interested ๐
12:17:32 <xarick> what do we want restart to do?
12:21:43 <xarick> SM_RESTARTGAME, ///< Restart --> 'Random game' with current settings.
12:21:54 <xarick> SM_NEWGAME, ///< New Game --> 'Random game'.
12:27:20 <xarick> store newgame settings in the savegame perhaps?
12:28:30 <xarick> because doing "restart" on a savegame will be going to use my local newgame settings and not that of the save
12:29:05 <xarick> or will not revert randomized ai back to Random AI
14:32:18 <xarick> that was my initial approach when designing the AI/GS
14:34:45 <xarick> when you select it, it's white, that was my initial problem, can't see if it started already
14:35:42 <xarick> then it evolved from there, i also wanted to know which ones died, as red
14:37:22 <xarick> decided to switch from green/red coloured text to tiny icons besides each
14:38:49 <xarick> then i also wanted to know which ones were started as random AI
14:44:02 <xarick> then i found the grayed ones rather limiting, I thought for myself, why can't I just select them, prepare a config in them, and then use the console to start one of the grey ones?
14:44:41 <xarick> and that's then when I thought adding a start/stop ai button here
14:45:24 <xarick> avoids using the console
15:00:21 <_glx_> before starting game vs game is started
15:02:36 <xarick> reinitialiser, restart button there?
15:02:57 <_glx_> it's the reset settings button
15:04:09 <xarick> does it work if the base value is negative?
15:04:31 <_glx_> it uses min_value and max_value as boundaries
15:05:06 <xarick> got me confused for a while
15:05:42 <_glx_> basically it just prints the +/- deviation range with boundary check
15:05:51 <xarick> I was thinking maybe show the base value and then (+/- random_deviation)
15:06:24 <_glx_> only GS settings done for now
15:06:52 <_glx_> I have an issue with boolean ones ๐
15:07:02 <_glx_> they can also have random_deviation
15:07:32 <truebrain> that should not be allowed ๐
15:08:12 <xarick> I thought boolean was exception to random_deviation, it used config_random
15:08:32 <_glx_> I can just add a "(random)" behind on/off
15:08:44 <truebrain> owh, btw, "fun" fact: there is only 1 AI that uses random_deviation
15:09:05 <truebrain> and none are boolean
15:09:08 <_glx_> I had to adapt my test GS ๐
15:09:22 <truebrain> so you can safely make it a condition that you cannot have random-deviation with a boolean
15:09:27 <truebrain> it makes very little sense to have that combination ๐
15:09:40 <truebrain> saves you having to write a weird UI for it ๐
15:09:50 <xarick> but was that already the case before SCRIPTCONFIG removal?
15:11:16 <truebrain> bit surprised random_deviation is used that little tbh ... but okay. It is what it is ๐
15:11:41 <truebrain> if I have some time tonight it will be used more, internally ๐ As I have an idea how to deal with the settings_profile bla
15:12:50 <truebrain> _glx_: Cherry-on-top would be if the caption read something like: "Change median value"
15:12:53 <truebrain> but that might be pushing it ๐
15:18:59 <xarick> I didn't know about it
15:21:10 <xarick> it's wrong to use random deviation for that, if it's 0 +/- 1, it clamps
15:22:45 <xarick> reinstate CONFIG_RANDOM ๐
15:30:00 <truebrain> did you know you could right-click a train in the depot, and that it shows a tooltip window?
15:30:22 *** HerzogDeXtEr has joined #openttd
15:30:41 <_glx_> it's mentionned in the tooltip
15:30:55 <truebrain> do you have any idea how many things are mentioned in our tooltips? ๐
15:32:14 <truebrain> _glx_: really, just make it impossible to have a deviation on a boolean .. it makes no sense ๐ฆ
15:32:18 <talltyler> truebrain: I learned this about a month ago, what a hidden feature
15:32:23 <talltyler> I wonder if anybody uses it ๐
15:32:36 <truebrain> and nobody is actively using it anyway, so there is also no regression
15:33:05 <truebrain> I mean, what does an integer deviation of any value mean for a boolean?
15:33:33 <_glx_> internally they are integer, bool is just a flag for the window
15:33:44 <truebrain> I don't think that has any impact on what I say ๐
15:33:54 <truebrain> think from the user ๐
15:33:57 <truebrain> what does it mean to the user
15:34:11 <truebrain> (both AI user as player)
15:34:22 <_glx_> yeah it's useless to set a bool if it's random anyway
15:34:39 <truebrain> so let's just make it an error, update the docs, and you don't have to do something like this ๐
15:38:15 *** keikoz has quit IRC (Ping timeout: 480 seconds)
15:43:15 <_glx_> hmm `rescan_game` doesn't seem to work
15:43:31 <truebrain> haha, falling into another bug? That nevah happens to any of us ๐
15:46:41 <_glx_> ah no it works, my script is still broken and I didn't check the timestamp
15:46:45 <truebrain> only 10% of the AI settings are booleans; for some reason I expected more
15:48:00 <_glx_> forced timestamp is helpful ๐
15:48:41 <_glx_> especially when an error fills the window
15:49:14 <truebrain> hihi, capital usage is inconsistent ๐
15:49:17 <truebrain> (sorry, I triggered :D)
15:49:35 <truebrain> `SCRIPTCONFIG_BOOLEAN`, that `SCRIPT` prefix feels odd ๐
15:50:07 <_glx_> haha I copy pasted the remove SCRIPTCONFIG_RANDOM
15:50:26 <truebrain> never said past-us (me?) was any good in being consistent ๐
15:52:01 <_glx_> ok, now the common script settings window
16:02:07 <_glx_> pff the max_no_competitor and disabling is stupid
16:02:25 <_glx_> I should have fixed that too
16:02:39 <truebrain> 1 issue at the time ๐
16:03:03 <_glx_> well it's fixed for running AIs
16:03:31 <truebrain> (not really sure what you mean btw, what part being stupid ๐ )
16:04:14 <_glx_> I can configure slots if max_no_competitor is lower
16:04:44 <_glx_> the color is fine, but they should be selectable
16:05:01 <truebrain> as I have that issue a lot too ๐
16:05:47 <truebrain> pff, this CopyOut dparam stuff is boring to fix
16:07:00 <truebrain> sadly also means boring to review ... I will have to see if I can make it a bit easier
16:15:11 <_glx_> hmm there's also the settings with labels
16:16:29 <_glx_> you can set labels for some setting values (text to show instead of the number)
16:16:48 <_glx_> and if all values have a label there's a dropdown
16:17:09 <truebrain> what is that key called? labels?
16:17:46 <_glx_> it's a map next to the settings
16:18:04 <truebrain> but it is assigned to it at some point, right? I should just look it up ๐
16:18:24 <truebrain> owh, really, `AddLabels`, haha
16:18:27 <truebrain> okay .. did not expect that ๐
16:18:47 <truebrain> that is actually used ๐
16:19:27 <truebrain> lol @ the negative part, that is a lovely hack ๐
16:29:21 <talltyler> My saveload bitshifting seems to work, but someone smarter than me should probably take a close look at it ๐
16:29:50 <truebrain> we will make an ad, see if anyone feels up for that challenge
16:31:30 <truebrain> your patch was so nice and clean, and now you get these things! ๐
16:31:41 <truebrain> why did you make action-type smaller?
16:32:16 <truebrain> owh, bigger I guess
16:33:50 <talltyler> It was, I was previously using it for the unbunching flag
16:34:09 <talltyler> It is also used for waiting times at stations, but this isnโt available for depots
16:34:09 <truebrain> how weird that a bit in the middle of a value was not used .. lol
16:34:55 <truebrain> but best way to know if you did it right is make a game before your change, add a bunch of depot orders, and then load it in1 ๐
16:35:01 <truebrain> if it works, you must have been doing it right ๐
16:35:12 <talltyler> Thatโs how I tested it, and it passed ๐
16:35:29 <truebrain> so your question was more a: look how awesome I am!
16:36:00 <talltyler> I am just leery of bitwise stuff, it seems easy to screw up in ways that are easy to miss ๐
16:36:48 <talltyler> Anyway, I like this solution even better using the dropdown instead of creating a new button
16:37:35 <talltyler> Now the space is back to being unused in a depotโฆ maybe someday Iโll get around to removing the space when a depot order is selected!
16:38:30 <talltyler> Not today though, I owe you some beta1 post text on my new features, and then I need a break. Maybe I will even play some OpenTTD soon once beta1 is released! ๐
16:42:18 <truebrain> talltyler: I still suggest you just make it a blog post, talking about what daylength is and how to use it
16:42:30 <truebrain> and if you like, one for the players, and one for authors
16:44:25 <peter1138[d]> +398-459, that's good at least.
16:45:25 <truebrain> It is a horrible PR to write and review ๐ I will do some cleanup before undraft. But curious to know if there are suggestions to make this even better
16:46:52 <peter1138[d]> Crap, I need to run Chrome/Edge :S
16:46:58 <talltyler> truebrain: Instead of notes for beta1?
16:48:04 <peter1138[d]> Hmm, maybe Chromium is enough... sullies system...
16:51:35 <truebrain> talltyler: Yeah, so we can point to it from releases and in general
16:55:17 <talltyler> It will be similar to the in-game document you requested, that we can link to from the Help & Manuals window
17:00:50 <truebrain> Doesn't need to be done by tomorrow btw; take your time
17:00:50 <_glx_> ok labels handled, it can show [0, ten] ๐
17:19:44 <_zephyris> Sorry talltyler... negative comments, and a possible bug ๐
17:20:17 <_zephyris> I like the idea of grouping with the service toggle, but needs a bit more work
17:23:26 *** Wormnest has joined #openttd
17:23:45 <peter1138[d]> Oh hey, it's home time.
17:23:53 <peter1138[d]> I better... "go home"
17:27:59 <truebrain> So you turn around and yell: HOME!
17:28:45 <peter1138[d]> Hmm, variant vs union...
17:33:45 <Rubidium> if it would've continued "by the map array", it would've been better
17:33:47 <truebrain> hmmm .. I want to know if a function is compiled in, but removing it doesn't help, as there is another overload that is compatible
17:36:16 <LordAro> _glx_: the GS name "Test" looks strangely offset
17:36:31 <frosch123> truebrain: add a "=delete" after the prototype
17:37:04 <LordAro> i know, just remarking on it
17:37:07 <LordAro> for peter1138[d]'s benefit :p
17:37:16 <truebrain> frosch123: smart cookie; I was hoping for a warning, but I take this ๐
17:38:56 <truebrain> still migration requests ... scary
17:41:44 <truebrain> right, another attempt at just removing `StringParameterBackup` ... this will be "fun" or something ๐
17:42:01 <peter1138[d]> It's actually the other text that is misaligned.
17:42:52 <truebrain> hmm, no, I am not going to do that for this PR .. let's just clean it up instead ..
17:42:55 <peter1138[d]> If you use the sprite font, or OpenTTD Sans (at least with FreeType) it'll be "correct"
17:43:42 <peter1138[d]> Probably space-bar breaking by now.
17:46:24 <truebrain> templates in C++ are still annoying, as in, you have to bring everything related to the templates in the header-file too .. which is bad for scoping ๐ฆ
17:48:08 <_glx_> well, you can use a dedicated header just for the template
17:48:20 <truebrain> still gives access to everything it needs ๐
17:48:35 <truebrain> so instead of a few files having access to StringParameters, EVERYONE now has access ๐
17:48:41 <truebrain> which annoys me .. but .. yeah
17:48:43 <peter1138[d]> I'm sure making sure it's an .hpp file will help... ๐ฎ
17:49:10 <frosch123> truebrain: i assume you do not want to refactor ottd into c++20 modules just before release ๐
17:49:31 <frosch123> hmm, wasn't there a PR to rename all hpp to h, should better rename to module :p
17:49:46 <peter1138[d]> There was but it got closed.
17:49:50 <truebrain> we are not allowed to make such changes anymore from our Lord ๐ฆ
17:50:03 <frosch123> but modules are more than renaming ๐
17:50:16 <frosch123> myths say "import std" takes 0.3 seconds on gcc c++23
17:50:21 <truebrain> just syntactic coating ๐
18:02:36 <xarick> guess I'm gonna have to stop using it
18:03:15 <truebrain> I wanted to use a bit more words, but yes.
18:03:35 <xarick> reload doesn't start the game from the beginning
18:03:41 <xarick> it's reloading the savegame
18:03:50 <xarick> that's not really helpful
18:04:04 <_glx_> it's impossible to restart exactly the same from a savegame
18:04:11 <xarick> sometimes the issue has already happened, and I wanna restart the game up to the point it happens again
18:05:03 <_glx_> important settings may have change before saving
18:05:41 <_glx_> user could even have added/removed newgrfs
18:06:42 <truebrain> the fun thing about "Random AI" is, it is random to your local installation
18:06:55 <truebrain> so reverting that from a savegame is not sensible
18:07:07 <truebrain> as it will have another pool to pick from
18:07:37 <xarick> if it comes from another installation yes, but sometimes it's the same installation
18:08:14 <_glx_> we can probably fix the "restart" issue for "newgame", but for savegames it's impossible
18:10:34 <_glx_> and storing newgame_settings in the save for rollback is not helpful because these can be modified before loading a game
18:11:07 <_glx_> which would then save the 'wrong' ones
18:15:19 <xarick> what 13.4 does for non-random AIs, it adds random deviation upon new game, then it never touches them again. restarting is possible, save and load is possible.
18:18:37 <xarick> but it has other inconsistencies during a running game though, so... I guess that's why you wanted to make it more uniform
18:19:17 <_glx_> yeah now it happens at a precise moment, and it's written in the doc
18:19:27 <_glx_> before it was just a mess
18:19:58 <xarick> weighting in the pros and cons... i still prefer the old approach ๐
18:20:27 <_glx_> you could modify AI settings after newgame, and deviation would never happen
18:33:02 <truebrain> owh boy, I found `SetupSubsidyDecodeParam`
18:35:29 <DorpsGek> - Update: Translations from eints (by translators)
18:37:43 *** gelignite has joined #openttd
18:39:07 <xarick> _glx_: That behaviour was fine, if I'm reading you correctly. You select a script, and deviation is automatically applied, isn't it? if you change the values at that point, I suppose it's expected that it won't deviate again.
18:44:28 <_glx_> according to the doc (before my change) "actual value of the setting in game will be randomised in the range [user_configured_value - random_deviation, user_configured_value + random_deviation] (inclusive)." but you don't actually know when that will happen, so you can't expect any behaviour
18:48:52 <xarick> hmm, documentation was perhaps in need of an update.
18:50:43 <_glx_> anyway there's only 1 script (well 2 with my test GS) known to use random_deviation
18:51:33 <xarick> but the functionality... it felt fine before, and now it feels like.. another lost feature.
19:27:29 <peter1138[d]> "pass parameters" would make more sense than "indicate parameters"
19:27:48 <truebrain> what is the context of that sentence? ๐
19:29:15 <peter1138[d]> Doing what I ask others not to. Hypocrite.
19:29:35 <truebrain> I have no clue why I wrote indicate, that is weird
19:29:47 <truebrain> but the whole PR is a fiasco if you ask me ๐ Burn it to the ground!
19:30:24 <peter1138[d]> Why? I like the idea.
19:30:34 <truebrain> I like the idea too, I just have no hope I didn't miss anything
19:30:45 <peter1138[d]> It is quite big, yeah.
19:30:47 <truebrain> it is so incredibly difficult to see if I got all params
19:30:57 <truebrain> well, big is one thing .. but sometimes we set DParam in another function
19:31:05 <truebrain> and .... well .. hard to know when/why ๐
19:31:21 <truebrain> but maybe tomorrow if I had a good night sleep I feel different ๐
19:32:42 <truebrain> ugh, I fucked up SetupSubsidyDecodeParam .. meh ๐
19:39:35 <xarick> what's it gonna be defaulted to
19:40:59 <truebrain> lol, unused string detector kicked in
19:41:22 <LordAro> reckon we'll get to #12000 before beta1?
19:44:13 <truebrain> index 7 requires 8 slots
19:44:17 <truebrain> .... really, this day
19:44:20 <truebrain> so many stupid coding errors
19:44:57 <peter1138[d]> New or existing?
19:45:08 <truebrain> this day? new. The issue? new ๐
19:45:49 <truebrain> those CodeQL errors are weird btw; guess it just doesn't understand the syntax
19:46:21 <truebrain> at least that should fix the redness of that PR ๐
19:49:35 <xarick> too many risky changes
19:50:08 <truebrain> frosch123: found where only the custom highscore profile is used ๐
19:50:37 <truebrain> yeah, let's not fix that in this PR ๐
19:52:01 <xarick> DummyAI should also use it
19:53:29 <truebrain> created a support ticket with Steam a week ago, to help out with the backend of OpenTTD (need a limit raised) .. no response. Ugh. I hope that is only because we are a free game, but imagine you are pushing for a release and that is the reply time to raise a limit ๐
19:56:27 <truebrain> of a Steam backend thingy, the "depot" limit
19:57:03 <truebrain> basically, all downloads are composed of depots; one for OpenTTD itself on Windows, one for Linux, and another one for OpenGFX, one for OpenMSX, etc.
19:57:11 <truebrain> and Steam downloads all those depots that match the OS
19:57:19 <truebrain> means I have uploaded OpenGFX once, and all OSes pick it up
19:57:39 <truebrain> for the social plugins, I need 3 depots per social plugin, to make my life easier .. but we reached the limit of 9
19:57:53 <xarick> setting both random_deviation and CONFIG_BOOLEAN is not allowed. How many scripts are gonna stop working?
19:58:19 <_glx_> Random deviation is used only by one script
19:58:39 <xarick> really? damn I'm so unique in this world
19:59:04 <frosch123> truebrain: i think old savegames keep the easy/medium/hard setting, just "custom" is converted to "medium"
19:59:12 <_glx_> And random deviation for a book value makes little sense
19:59:35 <_glx_> Why propose a setting which will be random anyway
19:59:47 <truebrain> frosch123: owh, might be. Still a bit wonky ๐
20:01:54 <xarick> custom existed when difficulty presets existed
20:02:05 <truebrain> okay, my grep capabilities today are really terrible .. lol
20:03:05 <xarick> if you changed one of the settings from easy/medium/hard, it would become custom
20:03:58 <truebrain> `_old_diff_level` is still used for `town_council_tolerance` when loading (very) old games
20:04:06 <truebrain> without that, a lot more related to difficulty can be removed ๐
20:04:09 <truebrain> but, not for this PR ๐
20:10:18 <truebrain> why do we have so many `SM`s, and so many "newgame" flows ๐
20:10:26 <truebrain> years and years of building stuff on top of each other ... "fun" ๐
20:13:27 <truebrain> #10953 says, for a NewGRF variable, "16 bit road stop ID of nearby tiles"
20:13:31 <truebrain> is it actually 16 bit?
20:16:38 <frosch123> truebrain: yay, i am not the only one reading PR descriptions ๐
20:17:37 <truebrain> even after reading the description ... I remember something about GRF system being weird
20:17:47 <truebrain> but even though I had to battle it with TrueGRF
20:17:50 <truebrain> I really don't know ๐
20:17:56 <truebrain> but wasn't it like 15bit? *shrug*
20:17:59 <peter1138[d]> It probably means the ID within the NewGRF file, which is 16 bits.
20:18:23 <truebrain> GRFs still hurt my little brain ๐ฆ
20:19:13 <truebrain> I wanted to fix the two small things in that PR, but found a bigger issue, of which I have no clue ๐ So lalalalalaaaaaaaaaaa ๐
20:19:51 <peter1138[d]> I guess the reason it was highlighted here is because the existing variable that road stop ID is only 8 bits, which is no longer enough.
20:20:07 <truebrain> don't most places call that Extended?
20:20:37 <xarick> I don't have a reply button?
20:20:57 <peter1138[d]> No, that's a file format thing when loading NewGRFs, this data within the game.
20:22:50 <truebrain> well, it shows I shouldn't talk NewGRF ๐
20:23:30 <frosch123> oh lol, i had some questions when reading that PR, but looks like i already had them last year
20:23:49 <truebrain> you never pressed the button? ๐
20:24:10 <frosch123> i did, they were even answered
20:25:58 <andythenorth> I should draw some trains
20:28:35 <truebrain> also btw tells me 10953 is untested
20:31:02 <truebrain> couldn't resist to troll ๐
20:33:05 <peter1138[d]> I wonder if there are any other NewGRFs it will ... break.
20:33:16 <peter1138[d]> It's kind of "undefined" at the moment.
20:33:56 <talltyler> The NewGRF will break, Iโm not saying you broke it ๐
20:34:10 <talltyler> Broken due to author using undefined behavior, to be sure
20:34:33 <talltyler> And I am happy to review it, once itโs rebased ๐
20:42:58 <frosch123> #11941 is a case of: sometimes it's easier to delete the code, than to fix it
20:44:05 <frosch123> oh, i need to rebase
20:46:03 <truebrain> for some reason I have issues with `CompileException`
20:46:07 <truebrain> but I have no better suggestions ๐
20:46:50 <frosch123> do you prefer `CompileError` ?
20:46:58 <truebrain> `CompileErrorException` ๐
20:47:53 <frosch123> or should i use `throw std::runtime_error` and base-class `catch std::exception` directly?
20:48:14 <truebrain> I kinda like you made it a name
20:48:23 <truebrain> and as I said, no suggestions; it just ticks me off ๐
20:48:36 <truebrain> it is a much cleaner solution btw
20:55:28 <truebrain> #11947 "looks fine", but NewGRF .. I think I just showed I don't know enough about that to be a judge on it ๐ But talltyler can be the chief here ๐
20:58:40 <xarick> random deviation almost worked in 13.4, except for RandomAI. my point of view was to first do the RandomAI restoration, then do another pr to fix the random deviation, possibly involves reverting some changes made by glx.
21:03:16 <frosch123> ah nevermind, there is already a "+1"
21:04:50 <locosage> that +1 isn't scaled though...
21:05:22 <frosch123> yes, it is a "at least one"
21:05:38 <frosch123> in the second case there is no "+1", so zero is possible
21:20:10 <xarick> now you keep telling me it's impossible to know what settings were there before, and I'm saying that wasn't the case before.
21:20:20 <peter1138[d]> `town_production_multiplier{TOWN_PRODUCTION_DIVISOR}`
21:20:28 <peter1138[d]> Yeah... where was I going with that...
21:20:58 <peter1138[d]> multiplier/divisor seem the wrong words here.
21:22:00 <peter1138[d]> Hmm, or not, it's just confusing me now that the default for multiplier is called divisor, but hey.
21:22:08 <peter1138[d]> Can't even read my own code :p
21:22:40 <frosch123> add std::ratio to make it less readable?
21:26:51 <truebrain> frosch123: wth is that thing?!
21:27:13 <frosch123> it's used for compile-time unit conversions
21:27:22 <frosch123> fractional numbers etc
21:27:39 <truebrain> I ... yeah, I wish I didn't know
21:27:43 <peter1138[d]> /me carefully eyes his fractional scaling branch :p
21:28:10 <frosch123> there is a 1h talk about the Au library at cppcon23
21:28:19 <frosch123> if you want to know :p
21:28:37 <truebrain> you say "au" like I should know what it means ๐
21:28:55 <frosch123> there is actually a snother talk as well, but i do not recommend that one
21:30:20 <frosch123> but well, 1 hour ๐
21:31:10 <frosch123> in standard c++ you have std::ratio in std::chrono for converting hours to milliseconds etc
21:31:33 <frosch123> in ottd most ratios are not compile time constants though, for some reason
21:32:46 <truebrain> I do with everything, no worries
21:33:12 <talltyler> peter1138[d]: Did you test #11947 with a modified ITI? I seem to remember that but could be mistaken.
21:37:27 <peter1138[d]> Oh yes I did didn't I. I remember finding your hardcoded paths ๐
21:37:40 <peter1138[d]> And you found that the bananas version was the wrong one ๐
21:42:12 <peter1138[d]> Hmm, ChooChoo crashes if MAIL is not available.
21:42:21 <peter1138[d]> As does LuDiAi AfterFix.
21:43:51 <_zephyris> talltyler: Feel free to ignore my gui comments if you want BTW. I've been playing with it more and got a bit more used to it. IMO it's not ideal, but probably good enough. Still think there might be some bugs in allowable changes to the depot order type though...
21:44:12 <talltyler> No, I am fixing it!
21:45:02 <peter1138[d]> talltyler: Yes I did ๐
21:45:36 <peter1138[d]> Hmm, therefore I have an NML patch ready somewhere.
21:46:24 <peter1138[d]> Oh, well I changed to 256 now ๐
21:46:31 <talltyler> _zephyris: Let me know if you find those bugs ๐
21:47:23 <talltyler> As for the UI, I am thinking of this:
21:47:23 <talltyler> 1. Instead of a toggleable `Service` button, show the currently selected action (and never show the button as lowered)
21:47:23 <talltyler> 2. Clicking on the button always opens the dropdown list
21:48:28 <_zephyris> I was thinking about the UI more broadly and I realised the station order buttons have a similar issue
21:48:48 <_zephyris> Might make the whole thing out of the scope of the unbunching PR
21:50:00 <_zephyris> (but, I like what you're saying for UI ideas, I think that might work better for the station orders too...)
21:50:21 <talltyler> By station orders, you mean loading and unloading buttons?
21:51:13 <_zephyris> talltyler: Will do, just need some time properly test!
21:51:59 <talltyler> Load/unload buttons are weird too, but that can be a later PR ๐
21:54:23 <_zephyris> That's why id suggest leaving the current unbunching UI. Save any changes for a PR which touches load/unload order UI too.
21:55:46 <talltyler> I'm not worried about changing this behavior without touching load/unload buttons, personally
21:58:13 <truebrain> We are going for the safe option? ๐
21:59:15 <peter1138[d]> We can do both, the copying thing is weird ๐
21:59:46 <truebrain> I see now 11952 is a bit weird ... std::string& is converted to const char * to be converted to a std::string ๐
21:59:50 <truebrain> but I am sure the compiler deals with that
22:01:01 <truebrain> and sure, both works for me; but then maybe the other one not for 14.0, to not have tons of bugs about that in beta1 ๐
22:01:15 <Rubidium> exactly my thoughts ;)
22:04:48 <truebrain> right, 7 more tickets for 14.0 .. of which 2 I think are unrealistic to expect to be done
22:05:46 <truebrain> but beta1 tomorrow shouldn't be an issue
22:08:59 <peter1138[d]> Oh, why is that all red ๐ฎ
22:21:05 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:29:10 <talltyler> Huh, vehicles with only a depot order never leave the depot...lol
22:29:15 <talltyler> Probably should fix that ๐
22:29:30 <talltyler> (can't believe I found a bug that _zephyris missed!) ๐
22:37:16 <talltyler> And I have a nullptr crash, what a rookie move
22:39:42 <truebrain> You were doing so well ๐
22:44:54 <_glx_> this limitation was annoying
22:45:07 <Eddi|zuHause> goes it throw out limitation?
22:45:20 <peter1138[d]> disturbs me very sprites
22:45:45 <truebrain> Is having the same color wise?
22:46:02 <truebrain> Now I will forget to increase the competitor limit ๐
22:47:20 <_glx_> at first I kept silver, but silver means disabled
22:48:09 <truebrain> Background color difference?
22:48:18 <truebrain> Some visual difference would be nice
22:49:18 <peter1138[d]> I think I saw something like that earlier.
22:50:44 <talltyler> Ugh, "only one order and it's a depot order" is an interesting and annoying edge case
22:53:15 <peter1138[d]> "SPR_BLOT" is the little colourable circle icon.
22:53:45 <peter1138[d]> Use with the company colour remaps.
22:54:12 <peter1138[d]> Not sure if appropriate though, kinda implies actually running which isn't the case from the intro screen.
22:54:26 <talltyler> Ha, it's not even my bug
22:55:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:57:38 <talltyler> Nifty, that's my nullptr crash ๐
22:57:49 <talltyler> (which I already fixed, but haven't pushed yet)
23:04:16 <_glx_> well, blue doesn't look good
23:05:50 <truebrain> No, it does not ๐
23:08:37 <frosch123> there are already grey, black and light blue text in that window
23:08:44 <frosch123> any more colors will make it look even sillier
23:09:04 <frosch123> oh, there is also orange
23:09:31 <frosch123> what does green mean?
23:10:22 <_glx_> you can't modify it, but you can access its configuration
23:10:36 *** Flygon has quit IRC (Read error: Connection reset by peer)
23:11:38 <frosch123> how about: grey=human/running, orange=editable, white=selected ?
23:12:01 <truebrain> Issue is that you don't see how many can start in your suggestion
23:12:22 <truebrain> Would be nice to visibly see how many AIs can start
23:12:35 <frosch123> but that is a lie anyway, if there are more human companies, it will pick later slots, doesn't it?
23:13:08 <truebrain> I never play with other humans
23:15:16 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:15:46 <_glx_> I could invert orange and yellow, so yellow means next to start
23:17:05 <frosch123> noone will understand those colors ๐
23:17:30 <frosch123> if you really want that info, add icons instead. but i don't think the info is important enough to display
23:18:11 <talltyler> Right, that's enough work for today
23:18:18 <andythenorth> I have drawn a small train
23:21:51 <_glx_> everything selectable except "Human player"
23:22:38 <_glx_> hmm I have a buggy disabling it seems
23:22:58 <truebrain> Kinda looks fine, these last shots
23:29:26 <_glx_> just forgot a little `slot < MAX_COMPANIES` ๐
23:29:28 *** tokai|noir has joined #openttd
23:29:28 *** ChanServ sets mode: +v tokai|noir
23:36:23 *** tokai has quit IRC (Ping timeout: 480 seconds)
continue to next day โต
