IRC logs for #openttd on OFTC at 2019-01-29
⏴ go to previous day
00:00:35 <glx> so many windows having issues with window closing
00:00:47 <glx> at least it doesn't crash ;)
00:02:18 <nielsm> controversial opinion: the in-game wrench button should be changed to open the Settings window rather than Game Options
00:02:39 <nielsm> Game Options is so rarely needed, all the useful stuff is in Settings
00:03:19 <Samu> what if i want to delight in the readme.txt :)
00:03:25 <glx> it's still in the dropdown so why not
00:04:05 <glx> when you close the option menu I think you don't care about the licenses or changelog of basesets
00:04:21 <Samu> GameOptionsWindow, which one is this
00:04:44 <glx> the one where you set language and other stuff
00:05:38 <nielsm> huh, Options and Settings can't be opened at the same time, never noticed that before
00:06:03 <glx> but you can work around it using window_number
00:06:12 <nielsm> (also, some of the options in Options should be moved to Settings, like the town names)
00:06:37 <nielsm> hmm I should move myself to bed :P
00:07:42 <glx> indeed options related to game play should move to settings
00:07:53 <Samu> is it just me or the number of changed files keep decreasing everytime I update?
00:08:21 <Samu> Files changed 70 nvm, it increased
00:08:34 <LordAro> are you expecting it to stay constant?
00:08:49 <Samu> i edited one more file, it was 69
00:08:56 <peter1138> Ok... what the fuck is SLE_WRITEBYTE?
00:09:01 <glx> you change a lot of files for just a window ;)
00:10:49 <glx> anyway removing outdated strings is useless if the string is still in english.txt
00:13:11 <peter1138> Used to work with WT, IIRC?
00:14:41 <glx> yes it worked with the old system
00:18:47 <peter1138> As glx wrote about 8 minutes ago...
00:18:48 <LordAro> Samu: yeah, not your issue, peter1138 broke it :p
00:19:05 <peter1138> Not my fault that EINTS is dumb.
00:19:20 <LordAro> peter1138: glx: frosch pointed at a line of code in eints yesterday, but i don't understand enough about it to do anything with it (easily)
00:25:18 <peter1138> And it loaded a saveload
00:26:01 <peter1138> vehicle types aren't messed up.
00:27:34 <peter1138> I had to fiddle with SLWRITEBYTE.
00:27:36 <peter1138> Because that is... wtf.
00:28:49 <peter1138> It's used for writing a fixed value to the savegame, but the value is stored in the version from and version to fields.
00:29:13 <peter1138> Which causes issues when I make them an enum.
00:30:11 <peter1138> Also it takes about translating a value, but I can't see any translation.
00:37:18 <peter1138> Hmm, I ought to check saving a game.
00:39:51 <peter1138> It could just write the value of the variable it references, but...
00:41:59 <peter1138> I suspect it's kinda legacy and doesn't really do what the comment says any more.
00:42:59 <peter1138> Rubidium tried to remove it in 2007 :-)
00:43:13 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #7129: Add: allow opening of one TextfileWindow per type https://git.io/fhPSV
00:43:22 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro merged pull request #7129: Add: allow opening of one TextfileWindow per type https://git.io/fhPMP
00:43:46 <Samu> #include "../strings_func.h" - removed this line and it still builds!
00:45:41 <glx> hmm it writes something in the savegame, and discard it on load if I read correctly
00:46:19 <peter1138> It's read directly with SlReadByte() in the loading code, in say vehicle_sl.cpp
00:46:30 <peter1138> Ok. It currently does not do translation
00:47:07 <peter1138> eab8ac49cee is where rubidium removed it
00:47:21 <glx> I'm reading in SlObjectMember
00:47:22 <peter1138> 622a4d10b92 is where it is put back
00:47:40 <peter1138> Before, it had 2 values, after it doesn't.
00:48:03 <glx> case SLA_SAVE: SlWriteByte(sld->version_to); break;
00:48:03 <glx> case SLA_LOAD: *(byte *)ptr = sld->version_from; break;
00:48:27 <glx> write, and discard on load
00:48:31 *** Thedarkb-T60 has joined #openttd
00:48:52 <peter1138> in Load_VEHS() there's VehicleType vtype = (VehicleType)SlReadByte();
00:49:03 <peter1138> Which is reading that value directly.
00:49:46 <glx> I think it was to automatically convert vehicle types to the right value
00:50:31 <peter1138> Yes, we changed the enum.
00:50:36 <peter1138> IIRC it was +0x10 originally.
00:52:07 *** Thedarkb1-T60 has joined #openttd
00:52:17 <peter1138> So discard on load...
00:52:29 <peter1138> It assigns that value to the pointer, but is that ecessary?
00:53:09 <glx> well discard the saved data and replace by what's in the source
00:54:29 <peter1138> It's always read directly with SlReadByte(), rather than through the description system.
00:55:52 *** supermop_Home has joined #openttd
00:59:36 <glx> SLE_WRITEBYTE is used only for types it seems (vehicles and station)
01:00:16 <peter1138> Looking at both cases, it could actually just write the value of the variable, instead of storing it from/to.
01:03:33 *** Thedarkb2-T60 has joined #openttd
01:08:59 <glx> oh was about to say I wasn't understanding how loading could work, but it's ok it read the byte before SlObject, and SlObject just does "nothing" for SLE_WRITEBYTE
01:09:13 <peter1138> That's what I was trying to say but wasn't clear :)
01:10:32 <glx> indeed it could just write for SLA_SAVE and break for other cases
01:10:36 <peter1138> It's slightly different for stations as the fixed value may not be the value stored in facilities, but in any case we're only looking for a specific bit, so it doesn't hurt to write the proper value.
01:12:22 <glx> SLE_WRITEBYTE is just a hack to write a constant
01:12:46 <glx> abusing SLE_GENERAL fields
01:12:49 <Samu> if i set up a GS in the scenario editor, save the scenario and load it back, the GS is loaded as active
01:12:51 <peter1138> Yes, and that hasn't been necessary since we changed the enum.
01:13:47 <glx> special load handling is still required, we still want to ignore the field on load
01:14:10 <peter1138> SlReadByte still needs to stay, but that's fine. That isn't abuse.
01:14:20 <Samu> oh, you're also dealing with saving stuff
01:15:22 <glx> yes but SLE_WRITEBYTE still needs to be a special case, we can't use SLE_VAR there
01:15:42 <peter1138> It's a "write only" part of the description :)
01:15:43 <glx> because we read the var before the _desc
01:15:54 <peter1138> But it's possible to write the var's value, not a fixed value.
01:16:25 <glx> and discard the SLE_GENERAL abuse
01:16:38 <peter1138> 037d6367349afa5a27ddf2cf015f6490167cf786
01:16:46 <glx> allowing SLE_CONDWRITEBYTE if needed one day
01:16:55 <peter1138> That's the commit that renumbered the types.
01:17:22 <peter1138> git show 037d6367349afa5a27ddf2cf015f6490167cf786
01:19:30 <glx> "Surprisingly this can be done without changing the savegame format" <-- of course SLE_WRITEBYTE did its job ;)
01:20:50 <glx> and at that time we weren't reading the byte before SlObject
01:21:47 <glx> I wonder what happens if we try to load a savegame from before that commit with master
01:22:14 <peter1138> Like the titlegame that still loads?
01:22:32 <glx> it's been updated I think
01:23:30 <Samu> any GS expert around that uses scenario editor? I have... questions, doubts
01:23:31 <peter1138> Before then the data structure was static.
01:23:47 <peter1138> waypoints were actually stations.
01:23:56 <glx> if SlReadByte gets a pre enum change it will SlErrorCorrupt("Invalid vehicle type");
01:24:16 <peter1138> glx, the enum changed, the savegame value was correct already.
01:24:30 <peter1138> the enum was changed and it happens to make the savegame value that was being written before.
01:26:44 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7130: Codechange: Remove value mangling and field misuse in SLE_WRITEBYTE. https://git.io/fhPQ2
01:28:07 <Samu> I have a delicate situation on my hands: on 1.8.0 and master, GS can be edited in scenario editor with no visual indication of its instance being active or not
01:29:06 <Samu> my gui stuff exposes that loading a scenario, will always activate the GS
01:29:23 <Samu> even if i saved it as a configuration
01:30:09 <Samu> i don't think it's intended for it to load as active, if it wasn't saved as active
01:30:34 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7130: Codechange: Remove value mangling and field misuse in SLE_WRITEBYTE. https://git.io/fhPQ7
01:30:38 <Samu> need your thoughts on it
01:31:24 <peter1138> Nothing should really be active within the scenario editor.
01:32:12 <Samu> so, it's a bug? a very hidden one?
01:34:19 <Samu> how am I gonna report the steps for this... it's unnoticeable on 1.8.0
01:35:13 <peter1138> Nobody cares about 1.8.0 :p
01:35:25 <Samu> okay, it's the same as current master
01:35:33 <Samu> unnoticeable, but it's there
01:35:51 <peter1138> Anyway, I thought you said that it's *your* stuff that activates the GS.
01:36:11 <Samu> no, it's not activated by me
01:36:34 <peter1138> 00:29 < Samu> my gui stuff exposes that loading a scenario, will always activate the GS
01:36:41 <Samu> i simply made the gui to be able to detect what's active, and it's how I spotted the bug
01:36:55 <peter1138> So by "active" what does it do?
01:37:07 <peter1138> Maybe it is meant to run? I don't kno!
01:37:10 <Samu> doesn't seem to be doing anything
01:37:53 <Samu> the issue is that on master, the slot is always configurable, i can change to other gs
01:38:12 <Samu> that's gonna mix configs of GS's from each other
01:39:06 <Samu> saved data may be of one GS, but then loaded into the other, that's gonna conflict for sure and cause issues
01:40:41 <glx> oh after checking source from that time SLE_WRITEBYTE macro was indeed different :)
01:40:44 <Samu> i'm gonna try fill a report
01:41:11 <glx> but it's a pain to navigate in old files, everything is moved :)
01:41:28 <peter1138> git blame xxx -- filename
01:41:42 <peter1138> And xxx~1 is useful.
01:41:45 <glx> had to remember where the saveload stuff was stored
01:51:58 *** sushibear has joined #openttd
01:54:00 *** snail_UES_ has joined #openttd
01:54:25 <glx> and indeed for stations the value can be anything as long as the flag is correct
02:14:53 *** Wormnest has joined #openttd
02:52:51 *** Thedarkb-X40 has joined #openttd
03:07:02 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas commented on issue #6584: Preview GUI text drops text in German translation https://git.io/fhPbn
03:17:17 *** supermop_Home has joined #openttd
03:59:31 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas opened pull request #7132: Fix #6584: text layout problem in engine preview dialog https://git.io/fhPNF
03:59:50 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7132: Fix #6584: text layout problem in engine preview dialog https://git.io/fhPNF
04:07:43 <nnyby> hehe am i the only one in here not in europe? :P this channel gets pretty dead silent at like 9pm my time
04:58:58 *** luaduck has joined #openttd
05:42:47 *** HerzogDeXtEr has joined #openttd
06:05:23 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhamZ
06:28:33 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7086: Change #6173: Update SDL driver to use SDL 2.0 https://git.io/fhamZ
07:33:13 *** andythenorth has joined #openttd
07:50:22 <Pikka> GarryG broke 64 cargos?
08:01:38 * andythenorth wonders why it doesn't work though :P
08:02:32 <andythenorth> maybe the vehicle refit overflows or something
08:03:04 <andythenorth> or maybe that test FIRS is wrong
08:10:10 <andythenorth> ugh, can't compile FIRS
08:17:23 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #6584: Preview GUI text drops text in German translation https://git.io/fhXJP
08:18:40 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN approved pull request #7132: Fix #6584: text layout problem in engine preview dialog https://git.io/fhXJS
08:18:51 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN merged pull request #7132: Fix #6584: text layout problem in engine preview dialog https://git.io/fhPNF
08:23:36 <peter1138> So I made version numbers into an enum last night, and then started changing from numbers to names.
08:23:53 <peter1138> And then I typoed and converted all text in all files with a regex.
08:24:02 <peter1138> So that was lost :p
08:24:16 <peter1138> The numbers are still there
08:24:24 <peter1138> It's a simple regex to replace though, so it hadn't taken long.
08:25:11 <peter1138> ^ That's now the position I'm at.
08:25:27 <peter1138> The enum part was already commited, so nothing much lost.
08:26:09 <peter1138> There's definitely some alignment issues with those changes.
08:26:33 <peter1138> But if we start changing from numbers to names then there's not much point fixing yet.
08:32:07 <peter1138> We lose the "git blame" support by dropping the old comment in saveload.cpp though.
08:32:18 <peter1138> Not sure how use that is anyway.
08:33:17 <andythenorth> hmm, how to fix nml :P
08:34:11 <andythenorth> local changes to try and add the 16 cargo in/out support
08:34:21 <andythenorth> but eh, it's in git, and we have branching
08:34:45 <peter1138> Oh, is that what's not working for Garry?
08:34:57 <andythenorth> no, it's vehicle refit that's broken
08:36:28 <andythenorth> select a cargo like Acid in refit menu
08:36:35 <andythenorth> vehicle isn't refitted
08:36:45 <andythenorth> dunno if it's FIRS or not
08:37:28 <andythenorth> newgrf features should get a reference grf in nml always
08:37:29 <peter1138> Oh, so that's a separate thing.
08:37:55 <andythenorth> testing with FIRS or whatever introduces a shitload more moving parts
08:42:26 <peter1138> CargoID new_cid = GB(p2, 0, 5);
08:42:42 <peter1138> CmdRefitVehicle limits it to 32 still. Oops.
08:43:03 <andythenorth> blame your tester :P
08:43:06 <peter1138> Fortunately there's space within the parameters to add made.
08:43:23 <peter1138> No, I think you for testing. I didn't at all.
08:43:59 <andythenorth> oops, I fixed nml and FIRS :P
08:44:06 <andythenorth> activated a virtualenv :P
08:45:08 <andythenorth> too many pythons, I delete some
08:45:23 <andythenorth> 13 different versions
08:48:41 <peter1138> Ok but I have duck egg on toast.
08:49:38 <andythenorth> python2.4 is no longer my default
08:49:43 * andythenorth mega bash skills
08:51:23 *** gelignite has joined #openttd
09:05:11 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7134: Fix 11ab3c4ea2f: Vehicles could not be refitted to cargo IDs higher than 32. https://git.io/fhXTA
09:05:19 <peter1138> andythenorth, can you try that out? ^
09:07:33 <peter1138> Gotta make lunch and then go to work :/
09:07:47 <peter1138> Also I burnt the roof of my mouth on the egg yolk, damn it.
09:10:21 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7134: Fix 11ab3c4ea2f: Vehicles could not be refitted to cargo IDs higher than 32. https://git.io/fhXkk
09:38:54 *** WWacko1976-work has joined #openttd
09:43:39 <Markk> peter1138: I thought your work comprised of answering questions and chatting here in #openttd?
09:45:07 <peter1138> "Waiting for the compiler"
09:46:43 <Markk> Ah, that's your excuse :)
09:47:13 <peter1138> Not much waiting with the 6-core i7s these days, though.
09:57:31 *** andythenorth has joined #openttd
09:59:22 <andythenorth> "Tropic is broken" v
09:59:49 <andythenorth> but today I need to make a UI library and some enterprise software
09:59:52 <andythenorth> maybe also fix my keys
10:03:05 <andythenorth> I fix my keys first though
10:03:32 <peter1138> That's not helpful.
10:03:49 <andythenorth> TGP flattens sub-tropic horribly
10:03:57 <andythenorth> which leads to flat desert maps
10:04:53 <peter1138> "Tropic is broken" -> "TGP generates shit maps for tropic", right?
10:05:31 <andythenorth> ha ha can't type, took my key caps off
10:05:38 <andythenorth> dirty under here
10:05:40 <peter1138> That's not exactly "Everything" then.
10:05:59 <LordAro> peter1138: everything is always broken
10:06:04 <LordAro> andythenorth: that was fast
10:06:07 <andythenorth> especially my keys
10:06:21 <peter1138> You can switch to the original generator...
10:06:23 <andythenorth> wonder if this is crumpett
10:06:32 <peter1138> Anyway, I did find my map generator code, eventually.
10:06:38 <peter1138> Maybe I should relook into it.
10:06:42 <andythenorth> these keys are sci-fi
10:08:08 <andythenorth> oh they work now
10:13:38 <andythenorth> such stupid bugs I've done in Horse :)
10:13:46 <andythenorth> but not as stupid as Group Facetime bug
10:35:41 <andythenorth> wonder if we could make a double-track autorail tool :P
10:45:52 <andythenorth> is air drag worth bothering with Pikka ?
10:53:53 *** Gustavo6046 has joined #openttd
10:57:13 <Pikka> not really, I don't think
10:57:29 <peter1138> It matters at high speed.
10:57:45 <Pikka> high speed is no fun though
10:57:51 <andythenorth> so this 186mph bendolino?
10:58:28 <Pikka> well, if it doesn't behave how you want it to, you could fiddle with it. Or you could just give it more powa
10:58:38 <peter1138> Fiddle with it to make it streamlined, etc.
10:58:41 <andythenorth> it has enough power
10:58:49 <andythenorth> THE SPEC EXISTS IT MUST ALL BE USED
10:58:54 <andythenorth> it's fast enough
10:59:22 <peter1138> Filling in a functional requirements spec for a client.
10:59:33 <peter1138> It's just been dumped on me with 150 requirements.
11:00:01 <peter1138> I was told by colleague "just fill in your bit, we've filled in the rest"
11:00:12 <peter1138> the "rest" comprises about a dozen questions.
11:00:23 <andythenorth> best way to design anything good
11:00:35 <peter1138> Anyway, there's loads which is marked as mandatory which we don't do.
11:00:43 <peter1138> And I'm not going to say we do, fuck that.
11:00:53 * andythenorth answers a lot of those
11:13:13 <peter1138> So I know the rest of the day is going to be saying "no" to "can we do that?"
11:14:59 <andythenorth> pretty much my entire job that
11:47:08 *** WWacko1976-work has quit IRC
12:05:05 <planetmaker> <andythenorth> newgrf features should get a reference grf in nml always <-- yes-ish. However even an existing reference grf there does not ensure that it's actually working in OpenTTD as expected
12:05:24 <andythenorth> simplifies testing though
12:05:26 <planetmaker> So test cases there ... are of limited value
12:05:37 * andythenorth has some basic ideas, will expand tonight, for feedback
12:05:55 <andythenorth> friction can't be eliminated, but can be reduced :)
12:05:56 <planetmaker> Yet, there's no problem with adding that to NML. It has regression tests, so that's a place to add these minimal test cases
12:06:10 <peter1138> Any approvals today?
12:06:29 <andythenorth> I can't, I am supposed to be making enterprise software
12:06:36 <andythenorth> also, you know, C++ clown shoes here
12:06:45 <peter1138> And does "Auto Reload Tab" break any T&Cs of Azure?
12:12:03 * peter1138 awaits tea to brew.
12:13:09 <andythenorth> time for the KLF
12:21:15 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7134: Fix 11ab3c4ea2f: Vehicles could not be refitted to cargo IDs higher than 32. https://git.io/fhXne
12:21:35 <peter1138> Okay, skin just peeled off my mouth from that yolk burn.
12:21:46 <andythenorth> I am no longer jealous tbh
12:22:00 <peter1138> Yeah, stupid me. Microwaved an egg...
12:22:22 <peter1138> Should've done it for less time and let it sit to cook itself.
12:22:31 <andythenorth> always a winner that
12:24:20 <peter1138> Also I switch from "chocolate digestive thin" biscuit to "hazelnut cookie" for this mug of tea. It's about 8x as unhealthy, because there's about 8x as much of it. In a single serving.
12:39:52 <andythenorth> 3 minutes left on jenkins job
12:41:41 <andythenorth> ducks are getting the short end of life today
12:48:45 <peter1138> Speaking of ducks. Docks.
12:51:16 <andythenorth> function requirement?
12:52:25 <peter1138> Step 1) Look back at how that guy did that other patch.
12:52:41 <peter1138> Step 3) Forget all about them when you get bored of OpenTTD developing again.
12:54:27 *** erratic has joined #openttd
13:54:49 <peter1138> andythenorth, it is, of course, lunch time.
13:58:44 <peter1138> My staple, a cheese salad sandwich.
13:59:22 <andythenorth> cheese salad crumpet
13:59:32 <peter1138> Cheese today is mature gouda, which is nice but perhaps doesn't work as well as mature cheddar in a sandwich.
14:01:42 <peter1138> lol theresa, you mad
14:02:16 * andythenorth watching parliament
14:02:55 <andythenorth> yeah crumpets ok
14:05:03 <andythenorth> 10 downloads of Horse!
14:08:42 *** Gustavo6056 has joined #openttd
14:08:55 <peter1138> LordAro, the down sides of committing someone else's changes...
14:09:17 *** Gustavo6056 is now known as Gustavo6046
14:09:44 <andythenorth> regressions savegame
14:09:51 <andythenorth> visual diff on giant screenshot
14:10:19 <peter1138> But... is that a bug or a feature?
14:11:38 *** snail_UES_ has joined #openttd
14:12:35 <andythenorth> depends if you expected it or not :P
14:12:42 * andythenorth has been reviewing visual diffs for last hour
14:13:43 <peter1138> Problem with running Linux in a VM is I don't get to fully utilize my triple screen setup.
14:13:59 <peter1138> And MSVC is horrible for actually developing and navigating code in.
14:50:37 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 updated pull request #7106: Fix #7089: close NewGRF textfile windows when their data are invalid https://git.io/fhKuB
14:55:41 <andythenorth> 3 minute visual diff cycles
14:55:46 <andythenorth> still faster than eyeballing it all :P
14:58:42 <andythenorth> how do we do translation?
14:58:47 <andythenorth> do we use gettext or something?
15:04:52 <glx> I just close when the selection changes
15:05:18 <glx> and selection can change in many places
15:08:39 <Eddi|zuHause> <peter1138> We lose the "git blame" support by dropping the old comment in saveload.cpp though. <-- but we get a new one by "git blame" on the enum, right?
15:10:39 <peter1138> Yes but it's new :p
15:12:33 <peter1138> Right, now logged in to Github on my tablet, but not in the Github app, as that won't accept my password.
15:13:28 <glx> github app doesn't OAuth ?
15:17:22 <glx> oh the "savegame upgrade" is recent
15:18:28 <Samu> getting a bit familiarized with newgrf, hmm... the design phisolophy is different
15:18:54 <Samu> by just clicking on a different newgrf, the parameters window is closed
15:19:34 <peter1138> I think that's how it should be.
15:20:19 <Eddi|zuHause> peter1138: i assume git has a way to continue the blame from the old version, like svn did with "svn blame file@XXXX"
15:20:20 <Samu> keep everything open, until it's really necessary to close (it's gonna crash, or it's gonna cause issues)
15:20:32 <glx> the parameter window can't change the source
15:20:34 <Eddi|zuHause> peter1138: so i don't think that's a reason
15:20:41 <peter1138> Eddi|zuHause, yes, if you remember which version it is, in 10 years.
15:20:55 <peter1138> Not that it's a huge issue.
15:21:10 <peter1138> git history is all local and it's way way faster than searching svn history.
15:21:15 <glx> so if the source changes, close the window
15:21:50 <Eddi|zuHause> peter1138: well, regular git blame will result in the version when the enum is introduced, so as long as that's the same as when the comment was dropped?
15:22:40 <peter1138> Samu, newgrf parameters staying open doesn't make much sense.
15:22:44 <glx> svn tracked file copy/move too
15:23:14 <andythenorth> all these params windows should be modal imo
15:23:17 <peter1138> With AIs it's a bit more reasonable, as you may want to copy the settings over if the AI is the same type.
15:23:34 <peter1138> glx, it does, but I'm changing every line as it's converted to an enum.
15:23:34 <andythenorth> far less state crap if modality is enforced :D
15:24:09 <glx> still need a window per AI
15:24:27 <Samu> much google what modality means
15:24:38 <glx> instead of one window for all
15:24:38 <andythenorth> locks the application state while the window is open
15:25:09 <glx> that should be easy, and close the window when the slot is changed
15:25:16 <andythenorth> modality is considered bad UI
15:25:24 <andythenorth> but it's very practicalt when state is complex
15:25:31 <andythenorth> and users do understand it afaict
15:25:44 <glx> we have modal windows, for newgrf scan
15:26:26 <glx> if lauched from newgrf window it hides all windows while it's running
15:26:29 <andythenorth> when you say window per AI, do you mean on screen? Or a window object in a tree somewhere, holding state?
15:26:55 <glx> should be easy with window_number
15:27:55 <glx> you put the slot number in window_number and when you change the AI in a slot you call DeleteWindowById(class, slot)
15:28:38 <glx> but when you click on another line in the list the window is still valid
15:29:14 <Samu> i do invalidate window data (class, slot)
15:29:32 <glx> but you have only one window
15:29:44 <glx> my idea is one window per slot
15:30:36 <Samu> there are 15 slots, the parameters window only display 1 window at a time, of one of those slots
15:30:57 <glx> yes but that can be changed so you have 15 windows
15:31:27 <glx> I did it to allow 3 textfile windows
15:32:10 <Samu> ew... 15 windows open that's hmm ... interesting
15:32:30 <glx> will proably simplify your work too
15:33:41 <LordAro> Samu: no one said you should, just that you can :p
15:33:55 <glx> hmm AIConfigWindow already set a window_number
15:34:00 <Samu> it's an interesting proposition
15:34:26 <Samu> the AISettings window is parameters
15:34:40 <Samu> i could display up to 16 of those, if including the gs
15:36:47 <Samu> the names are quite similar, it's easy to get confused
15:37:49 <Samu> might need a better window title, to reflect which # it belongs to
15:38:07 <glx> this->FinishInitNested(slot); // Initializes 'this->line_height' as side effect. <-- window_number is already setup in AISettingsWindow
15:39:00 <glx> so ShowAISettingsWindow() just need a little change and you get one window per slot
15:39:40 <glx> replace DeleteWindowByClass(WC_AI_SETTINGS); with DeleteWindowById(WC_AI_SETTINGS, slot);
15:40:06 <Samu> is that in master code or in my code?
15:40:11 <peter1138> AI Settings (slot {JUST_INT})
15:40:41 <glx> but I think you haven't touch this part :)
15:40:57 <Samu> i touched many stuff related to window closures
15:41:21 <glx> that one is called when you click on config button
15:42:34 <Samu> static void ShowAISettingsWindow(CompanyID slot)
15:42:43 <Samu> ah, this one, yeah, i didn't touch this
15:44:02 <glx> and with one window per slot you just need to close a window when you change the AI in a given slot
15:44:24 <Samu> I don't close, I invalidate
15:44:39 <Samu> dont know what master do, it's been awhile
15:44:46 <glx> better to close it when you change the slot content
15:48:06 <glx> hmm master invalidates it seems
15:49:09 *** supermop_work has joined #openttd
15:49:21 <glx> ah yes the caption will need an update
15:49:33 <glx> to show slot and ai name :)
15:50:15 *** supermop_work_ has joined #openttd
15:54:17 <Samu> this is incredible, i like it!
15:54:45 <Samu> i can visualize the entirety of parameters of all ais in gui mode
15:55:40 <andythenorth> wow....you have a big screen :o
15:56:34 <andythenorth> 4 of those windows fill my screen
15:56:38 <Samu> ok, needs some fixings indeed, company number
15:56:59 <Samu> not sure about company name of the ai
15:57:06 <Samu> i guess ai name is better
15:57:35 <glx> just show the name the same way DrawWidget does
15:58:33 <glx> SetStringParameters() should be modified
15:59:35 <glx> first STR_AI_SETTINGS_CAPTION_GAMESCRIPT and STR_AI_SETTINGS_CAPTION_AI need an update adding a {STRING} for the script name
16:02:32 <glx> and an extra stuff to also put the slot for AIs
16:03:00 <nielsm> https://github.com/OpenTTD/OpenTTD/pull/7081 <-- unsure about if this is "done", it works as advertised but I think it ought to address the frame rate window in some way or other; also not sure I'm entirely on board with the wording of the strings
16:04:15 <glx> indeed if the frame rate doesn't count your added sleep something is wrong
16:04:54 <glx> hmm but link graph stuff is threaded
16:05:56 <nielsm> but syncs every N game days
16:06:20 <glx> and if it pauses openttd then no calculation happen
16:06:22 <nielsm> if the threaded calculation takes longer than the simulation of those N days, the game hangs atm
16:06:51 <nielsm> what this patch does is effectively just giving visual feedback what's going on
16:07:11 <glx> always nice to give feedback
16:08:21 <Eddi|zuHause> i'm not sure how you could meaningfully add threads to the framerate window
16:09:08 <nielsm> right now, the framerate window has a line for how long was last spent waiting for the link graph thread to join the main thread
16:09:15 <nielsm> which is usually near zero
16:09:16 <glx> well the delay is calculable from main thread
16:09:38 <nielsm> with this patch the number will always be zero, because the main thread does not hang while joining the link graph thread
16:11:09 <peter1138> It's still countable, just needs to be done differently.
16:11:15 <nielsm> so either remove that line from the framerate window, or change the calculation to either show total time spent on each link graph cycle, or rework how the delay is determined
16:11:40 <glx> but it could start a chrono on expected join and stop on effective join
16:13:52 *** sla_ro|master has joined #openttd
16:17:05 <peter1138> Samu, careful what you copy & paste from IRC to github. You made an issue reference that is irrelevant and wrong.
16:17:46 <peter1138> Samu, better yet, don't copy & paste from IRC at all.
16:18:03 <peter1138> It's not your notepad.
16:29:36 <peter1138> glx, ah, the github app was discontinued ages ago.
16:30:51 <glx> btw I hate the guy that decided an integrated gps controlable only with a remote control was a nice idea
16:32:08 <glx> in the car the integrated navigation system is controled by remote, and this morning the remote batteries died
16:33:20 <nielsm> huh.. the {HEX} code for string formatting gives me a five byte value printed
16:33:35 <glx> I could set it for the first travel, but couldn't not stop it then set the return travel
16:35:00 *** Wormnest has joined #openttd
16:35:28 <glx> return buff + seprintf(buff, last, "0x" OTTD_PRINTFHEX64, number);
16:36:26 <nielsm> maybe I should just format to a 10 byte fixed buffer and print it as raw_string
16:36:40 <nielsm> since I don't want the 0x either
16:39:06 <glx> {HEX} is better than nothing ;)
16:39:12 *** Vasatko has joined #openttd
16:39:28 <glx> but yeah doesn't work for any possible case
16:45:34 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7128: Add: Unique ID to savegames to prevent accidental overwriting https://git.io/fhX1n
16:48:44 *** andythenorth has joined #openttd
16:51:17 <andythenorth> the red has contrast issue btw
16:51:31 <peter1138> Why do we need game ID?
16:51:36 <Samu> the color or warning? yellow?
16:51:59 <nielsm> peter1138 I don't know, do we actually?
16:52:09 <nielsm> someone also brought it up in the PR comments
16:52:21 <nielsm> if it's really the right solution to the problem
16:52:25 <glx> no need to display the game ID, just tell it's different
16:53:10 <peter1138> Can't we just have the "overwrite this file?" prompt?
16:53:12 <nielsm> {SILVER}Game ID: {WHITE}Match // {SILVER}Game ID: {YELLOW}Different
16:53:47 <peter1138> I don't care if it's the same game or not, I probably don't want to accidentally overwrite an older save of the same game.
16:53:58 <Samu> the darn livery str is getting in the way
16:54:08 <peter1138> And I feel having a savegame bump for this is pretty weird.
16:54:16 <peter1138> Samu, ignore it, it doesn't hurt.
16:54:52 <glx> it's just noisy, but not blocking
16:55:16 <nielsm> peter1138 you mean just always warn when overwriting a savegame, regardless of which one it is?
16:55:22 <nielsm> yeah maybe that's good enough
16:55:30 <peter1138> I'm absolutely positive that's enough.
16:55:50 <Samu> my string edit could get lost inbetween all those livery
16:55:51 <glx> and similar too many other programs
16:55:57 <peter1138> And saves you a ton of effort you've, er, already spent :/
16:56:59 <glx> and maybe a setting to disable the warning for people not wanting it
16:57:24 <glx> can be annoying if you use one save only I guess
16:59:15 <glx> but on the other hand people don't save manully more frequently than autosave
17:00:46 <glx> Samu: no, if you make an error in english.txt compile stops
17:00:59 <glx> because english.txt is important
17:02:34 <glx> hmm or not, just tried it warns but continue
17:03:58 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh opened pull request #7135: Update: Visual Studio 2019 insists on upgrading the solution file https://git.io/fhXDn
17:05:48 <Samu> hmm, something's wrong with the name for the random ai
17:06:01 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 approved pull request #7135: Update: Visual Studio 2019 insists on upgrading the solution file https://git.io/fhXDK
17:06:05 <Samu> sometimes I get (none), some other times I get (random)
17:06:37 <Samu> i want it to be (random) in all cases
17:08:01 <glx> show your SetStringParameters and the strings
17:08:25 <Samu> seems to be an issue only in main menu
17:08:50 <Samu> how is the main menu save loaded? must find
17:08:59 <Samu> something in there is missing
17:09:18 <glx> ignore the saveload, main_menu doesn't care
17:10:17 <Samu> it didn't load the ai infos apparently
17:10:20 <DorpsGek_II> [OpenTTD/OpenTTD] orudge commented on pull request #7135: Update: Visual Studio 2019 insists on upgrading the solution file https://git.io/fhXyZ
17:11:04 <glx> and check how AIConfigWindow::DrawWidget draws the names
17:15:42 <glx> ignore the saveload in main menu, AIConfig is not from the save
17:18:14 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh merged pull request #7135: Update: Visual Studio 2019 insists on upgrading the solution file https://git.io/fhXDn
17:18:51 <glx> it seems you always jump in the wrong direction
17:20:26 <glx> every settings and options you see in main menu come from openttd.cfg, never from a savegame
17:31:45 <Samu> openttd.cfg has the name "none" for random ais, maybe it literally read the word "none" and im now using it as name
17:33:00 <Samu> it's "none", not "(none)", big small difference
17:33:54 <glx> yes because you haven't checked how it's done in AIConfigWindow::DrawWidget
17:35:10 <Samu> I'm editing the title for AI Settings Window, not AIConfigWindow
17:35:56 <glx> yes, but AIConfigWindow draws all the stuff you want to put in AISettings caption
17:36:17 <glx> and if it works there, you should see how it's done
17:36:29 <Samu> i see, i see now, thx, my bad
17:37:18 <glx> always enlarge your vision :)
17:42:36 <Samu> that's the heavily modified part of my code
17:52:50 <Samu> 0x0000002efafad370 "î†AI Parameters of ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
17:53:21 <LordAro> maybe don't paste that into irc?
17:54:56 *** Progman has joined #openttd
17:55:16 <peter1138> LordAro, I wonder if we need to have a note on "how to report a bug" on github?
17:55:28 <peter1138> It seems that people think just a title and an image is sufficient :/
17:56:20 *** supermop_work_ has quit IRC
18:01:44 <Samu> can't read the name directly, must check first if there's AIInfo or GameInfo
18:01:50 <nielsm> gah I'm having issues with VS converting line endings in files
18:02:04 <nielsm> at this point I really want to convert my entire working copy to CRLF instead of LF
18:02:08 <Samu> or else it's gonna read the name from openttd.cfg
18:02:09 <nielsm> but not sure how to do that best
18:02:41 <peter1138> planetmaker, it needs to be actually READ by reporters :/
18:02:51 <planetmaker> *that* is a common problem :)
18:03:07 <peter1138> I wonder if there's a way to tweak the issue reporting page.
18:03:25 <peter1138> Just a template in the comments would be handy.
18:04:11 <peter1138> So we just need a .github/ISSUE_TEMPLATE.md file... in the repo?
18:04:28 <peter1138> We already have a .github, so I guess it's fine :D
18:04:41 <peter1138> planetmaker, Yeah, I know :/
18:05:31 *** FLHerne has joined #openttd
18:06:36 <LordAro> peter1138: we can do things like image templates
18:06:36 <planetmaker> CONTRIBUTING.md it is, so it seems
18:06:54 <peter1138> That's got more detail than what I was looking at.
18:07:52 <glx> nielsm: set autocrlf maybe
18:07:58 <peter1138> There's a template builder? o_O
18:08:22 <LordAro> set autocrlf is the first thing i do with any git stuff
18:08:32 <LordAro> (well, import my dotfiles with my git config, i guess)
18:08:58 <peter1138> Ah, I guess that needs admin rights to the repository.
18:09:34 <planetmaker> That could be done...
18:11:18 <planetmaker> we want it in .github, I guess
18:11:44 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7137: Add: [GitHub] Add issue template to encourage better issue reporting. https://git.io/fhXdl
18:13:56 <planetmaker> I guess I can only approve it w/o admin override when it finished building
18:14:54 <peter1138> Hmm, I need a Mac OS machine to test #7126 ;(
18:15:17 <peter1138> Shame my MacBook died, although that was running Debian anyway come to think of it.
18:15:57 <DorpsGek_II> [OpenTTD/OpenTTD] planetmaker merged pull request #7137: Add: [GitHub] Add issue template to encourage better issue reporting. https://git.io/fhXdl
18:16:02 <planetmaker> let's see whether my admin power works :P
18:16:05 <peter1138> Well damn, no cycling today so I'm well over on my calories :/
18:16:35 <planetmaker> was a dangerous-free test ;)
18:16:43 <peter1138> Uh, so much for markdown. Never mind.
18:16:57 <peter1138> But yes, there's a little template now :D
18:17:12 <peter1138> You can "preview" your issue and the MD works, but that's pretty dumb, heh.
18:17:20 <planetmaker> Well, no mark-down but that is actually a good topic indicator
18:17:35 <peter1138> It is markdown but not in the text editor, makes sense really.
18:19:12 <Markk> peter1138: Is the compiling of a new human done? So you can send that "human" to the workplace.
18:19:48 <LordAro> planetmaker: peter1138: nono, we must check that the PR compiles on all platforms before merging :p
18:19:52 <peter1138> This human doesn't need to be in the workplace at this time of day.
18:20:09 <Markk> peter1138: Wasn't this channel your workplace?
18:20:45 <planetmaker> nielsm, and *.h *,cpp text eol=lf ?
18:21:55 <Markk> It just seemed like you're with us in here all day.
18:22:10 <nielsm> planetmaker, left out for "user preference"
18:22:13 <peter1138> Yes, I am able to lurk here all day and then comment sometimes.
18:22:52 <peter1138> That sort of comment feels like "why aren't you working?" hence my rudeness. Sorry.
18:22:59 <planetmaker> how can the line endings in the tracked source files be a "user preference"?
18:23:04 <glx> nielsm: core.autocrlf is enough for me
18:23:32 <peter1138> planetmaker, git can convert, right?
18:23:41 <planetmaker> yes, it can. But should it?
18:23:48 <nielsm> glx: it becomes weird when using git in WSL :(
18:24:10 <nielsm> also, converting a working copy from one EOL style to another seems to be a major bother
18:24:12 <glx> I feel a problem with generate
18:24:47 <peter1138> Which files are generated 'wrong'?
18:25:21 <peter1138> [core] autocrlf = true
18:25:32 <glx> yes I have it too, works well
18:25:40 <nielsm> the specific problem I'm having here is that vs2019 regenerates the .sln file every time I build, and that converts it from LF to CRLF, but no other changes
18:26:13 <glx> but why does it regenerate the .sln
18:26:30 <peter1138> nielsm, yes, set autocrlf.
18:26:41 <peter1138> Then your .sln files should start off as CRLF.
18:26:59 <nielsm> peter1138 no, because I'm running git in WSL where the eol is LF
18:27:11 <nielsm> so autocrlf will output LF files
18:27:17 <peter1138> glx, it's not running "generate" it's just saving the file its opened, with CRLF.
18:27:32 <nielsm> windows subsystem for linux, aka "ubuntu bash on windows"
18:27:32 <glx> you can tell it to always use CRLF I think
18:27:48 <peter1138> I'm using... git-bash or powershell
18:27:55 <peter1138> But I don't think that's relevant.
18:28:05 <nielsm> but changing the git settings is one thing
18:28:19 <nielsm> how do I make git re-checkout every file to convert to the new eol style
18:28:41 <peter1138> I can't remember :-)
18:28:44 <LordAro> anyone care one way or another about #7124?
18:28:49 <nielsm> just delete everything and 'git checkout .' maybe
18:28:50 <glx> it does it magically I think
18:29:12 <Eddi|zuHause> git reset --hard?
18:29:56 <glx> I don't understand how strgen reports errors
18:30:14 <planetmaker> LordAro, not much one way or another. He might have a point... dunno
18:30:22 <LordAro> nielsm: find -type f -exec unix2dos {} \;
18:31:04 <Samu> STR_AI_SETTINGS_CAPTION :{WHITE}{STRING} Parameters of {RAW_STRING}
18:31:07 *** HerzogDeXtEr has joined #openttd
18:31:30 <peter1138> Or is that how AI names are done?
18:31:30 <glx> it parses master, error count is 0, then it prints errors, but the test for error count is already behind
18:32:22 <Samu> STRING crashes a different way
18:32:24 <nielsm> #7124 is... eh are anyone even going to ever see that string?
18:32:38 <nielsm> I mean it may as well be one of the first strings anyone translates
18:32:56 <nielsm> since it would be screaming at everyone trying out the translation while it's incomplete
18:33:29 <Samu> or is it STRING1 when i got 2 strings?
18:33:39 <planetmaker> nielsm, yes. As long as a translation is outdated or missing (or a threshold - dunno), it's visible
18:33:49 <peter1138> Samu, please read out the string system works.
18:33:53 <nielsm> RAW_STRING is for passing in a char* to SetDParamStr()
18:34:03 <nielsm> STRING is for passing in a StringID to SetDParam()
18:34:07 <LordAro> naturally it's 3 years old
18:34:18 <nielsm> STRING1 is for passing in a StringID that will reference another string that has one insert
18:35:07 <Samu> the name of the ai is read from AIInfo->GetName
18:35:37 <Samu> i must read from StringID
18:36:45 <Samu> {STRING} Parameters of ... {WHAT}?
18:37:38 <glx> for AIInfo->GetName you need {RAW_STRING}
18:39:15 <Samu> I have a way, the char[1024] way
18:40:44 <glx> and compare with your SetStringParameters()
18:40:48 <Samu> that only works when it's the only string
18:41:12 <Samu> i got a {WHITE}{STRING} Parameters of {RAW_STRING}
18:42:06 <Samu> and it crashes for randomai
18:42:23 <peter1138> You do know what the first parameter of SetDParam(Str) is for, right?
18:42:24 <glx> SetDParam(0, <the first string>); SetDParamStr(1, <the raw string>);
18:43:21 <Samu> hmm, i must be doing something wrong then, brb
18:43:51 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7124: Fix: grammar in translator intro notice https://git.io/fhXNk
18:44:12 <glx> for random AI you are using a StringID, not a raw string
18:45:18 <glx> but you can still replace RAW_STRING with STRING1, and pass a StringID for random, or STR_JUST_RAW and the raw value for the rest
18:45:37 <glx> our string system can do a lot
18:46:13 <glx> you just need to know what you are doing
18:47:23 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7124: Fix: grammar in translator intro notice https://git.io/fhXNR
18:47:41 <glx> and the link I gave above just does that
18:48:30 <glx> it's for a DrawString call but could be a SetDParam
18:48:34 <peter1138> Any chance #7134 can be looked at before this evening's nightly?
18:48:51 <peter1138> Would help a NewGRF developer ;)
18:48:54 <nielsm> I don't feel confident to review it
18:49:42 <peter1138> Just bit-packing. Nothing complex :)
18:50:13 <Samu> the commented out way works, but you don't like that method
18:50:36 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7134: Fix 11ab3c4ea2f: Vehicles could not be refitted to cargo IDs higher than 32. https://git.io/fhXNr
18:51:27 <glx> and SetDParam(1, text) after the if block
18:51:48 <planetmaker> do we have so many bits actually in p2?
18:52:16 <glx> you just need to follow the logic Samu
18:52:41 <peter1138> 25 bits? It's a uint32 so I hope so.
18:52:55 <nielsm> any chance all the manual bitstuffing code could be replaced with C bitfield syntax structs? :(
18:53:12 <glx> and put the args in the right place, matching the string
18:53:16 <peter1138> nielsm, no, but I've got a PR in mind that creates a helper function to do all the bitpacking.
18:53:43 <peter1138> We already have CommandContainer which helps that.
18:54:24 <peter1138> nielsm, bitfields are very much compiler defined, and this one place where that can't be done.
18:55:13 <LordAro> nielsm: can't say i do either :p
18:55:48 <LordAro> crap, was scrolled: i feel comfortable reviewing*
18:55:51 <DorpsGek_II> [OpenTTD/OpenTTD] planetmaker approved pull request #7134: Fix 11ab3c4ea2f: Vehicles could not be refitted to cargo IDs higher than 32. https://git.io/fhXAt
18:56:19 <peter1138> ^ although the only one i've done so far doesn't actually have any bit packing, lol
18:56:22 <peter1138> But that's my concept.
18:56:43 <Eddi|zuHause> milek7: doesn't sound like anything i would trust without a pile of regression tests
18:56:51 <peter1138> planetmaker, thanks!
18:57:31 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN merged pull request #7134: Fix 11ab3c4ea2f: Vehicles could not be refitted to cargo IDs higher than 32. https://git.io/fhXTA
18:57:50 <nielsm> 2-3 minutes until nightly triggers?
18:57:52 <Samu> can't make this work, crashes at Utf8Decode
18:58:37 <LordAro> peter1138: i've beem wondering about that as well, the best i could come up with was some vague idea of a templated function
18:59:04 <milek7> anyway, looks like pragma pack doesn't affect bitfields
18:59:09 <LordAro> some sort of compiletime error is obviously preferred
19:00:17 <peter1138> bitfields are very rarely used.
19:00:25 <peter1138> Probably in the Linux kernel :-)
19:00:45 <peter1138> LordAro, what I've done makes the parameters type-safe as well.
19:00:53 <planetmaker> how do bitfields break the game? Cross-platform command stuff?
19:01:03 <peter1138> LordAro, so it'll need different variants when the same command is used for, say, road types and railtypes.
19:01:25 <LordAro> peter1138: yeah, the boilerplate is probably going to add up
19:01:43 <glx> Samu: show your current SetStringParameters and the caption base string
19:01:54 <peter1138> "Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit."
19:02:01 <peter1138> ^ This is the spec for bitfields
19:02:29 <peter1138> That says "don't use for network protocol stuff" to me!
19:03:26 *** Gustavo6046 has joined #openttd
19:03:36 <peter1138> I'm gonna proceed with my packing helpers, sometimes it's just a bit difficult to find the right place to put a specific helper :p
19:07:59 <glx> I said to use {STRING1} earlier
19:08:11 *** Thedarkb2-T60 has joined #openttd
19:09:49 <nielsm> how about something like that?
19:10:10 <nielsm> should also be possible to do with variadic templates
19:10:19 <nielsm> although that would cut out visual c++ 15 as well afaik
19:11:46 <peter1138> nielsm, seems overly complex.
19:11:57 <Samu> crashing for random ai, not the others
19:12:06 <peter1138> nielsm, and also we have 2 bitpacked uint32s per command.
19:12:17 <nielsm> peter1138 it's not a complete example :P
19:12:33 <glx> then try to find why using the debugger
19:12:57 <nielsm> the idea is to have a base BitpackedUint32 template that can handle a large number of fields, and then create specialisations of that for each value type
19:13:26 <nielsm> which would hopefully compile into equivalent code to the current
19:13:37 <Samu> it's NULL when it tries to read something in utfdecode function~
19:14:19 <glx> check the call stack to check what slot it is
19:16:02 <Samu> slot 2, which is configured with random ai
19:17:29 *** andythenorth has joined #openttd
19:17:38 <Samu> the call stack is something about updatewindows, drawing dirty blocks
19:18:01 <Samu> external code, doesn't go back to where it originated
19:18:51 <peter1138> Okay so that change was incomplete ;(
19:21:23 <glx> Samu: I'll try your code locally, will be easier for me to see what could be wrong
19:21:31 <peter1138> Just one place where the command was split across multiple lines.
19:21:38 <glx> because I think it should work
19:23:43 <peter1138> Oh, and another. Shit.
19:24:41 <Samu> now my code fails too, wtf
19:25:00 <andythenorth> oh george found the FIRS bugs
19:25:06 <andythenorth> I assumed they were my fault
19:25:09 <andythenorth> been there for years
19:25:11 <Samu> ah, STRING1 is bad for my code
19:25:24 <peter1138> andythenorth, in that case...
19:25:24 <DorpsGek> andythenorth: I have not seen BrainTrue.
19:25:42 <DorpsGek> andythenorth: TrueBrain was last seen in #openttd 21 hours, 54 minutes, and 7 seconds ago: <TrueBrain> funny
19:25:44 <peter1138> If it's old, it's something else.
19:28:07 <Samu> it's not the way you wanted
19:28:10 <andythenorth> peter1138: you suggested the issue template I was going to suggest :)
19:28:29 <andythenorth> I do not love bureaucracy, but issue template FTW
19:30:08 <Samu> oh, i dont need that text for anything too
19:30:12 <DorpsGek_II> [OpenTTD/OpenTTD] andythenorth commented on pull request #7137: Add: [GitHub] Add issue template to encourage better issue reporting. https://git.io/fh1eB
19:30:57 <peter1138> andythenorth ... it was already commited.
19:31:27 <LordAro> andythenorth: arbitrary #7109 reminder
19:32:26 <glx> some of your other changes probably, Samu
19:32:31 *** D-HUND is now known as debdog
19:32:57 <Samu> i changed STRING to STRING1 :(
19:33:04 <DorpsGek> TrueBrain: andythenorth was last seen in #openttd 4 minutes and 35 seconds ago: <andythenorth> I do not love bureaucracy, but issue template FTW
19:33:17 <andythenorth> @seen norththeandy
19:33:17 <DorpsGek> andythenorth: I have not seen norththeandy.
19:33:57 <glx> [18:45:20] <+glx> but you can still replace RAW_STRING with STRING1, and pass a StringID for random, or STR_JUST_RAW and the raw value for the rest
19:33:59 <andythenorth> can I buy someone a mac? :P
19:34:07 <andythenorth> Wolf01: Liebherr :)
19:34:47 <Wolf01> And 2 control units, possibility to use touch screen to control it
19:34:57 <andythenorth> lego might get on another good run
19:35:03 <andythenorth> past few years are mostly meh
19:35:22 <andythenorth> €400 though Wolf01 ?
19:36:33 <glx> btw Samu, STR_AI_CONFIG_NONE will probably never be displayed as you can't open the settings window in this case
19:37:19 <glx> I know, and if there's no GS, there's no settings
19:37:32 <Wolf01> But that's not a problem, I might afford a real one :P
19:38:40 <Samu> hmm game script parameters on (none), it's not closing
19:38:51 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7128: Add: Unique ID to savegames to prevent accidental overwriting https://git.io/fh1v3
19:38:51 <Samu> looks like there's more stuff to fix
19:39:42 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7134: Fix 11ab3c4ea2f: Vehicles could not be refitted to cargo IDs higher than 32. https://git.io/fh1vC
19:39:46 <glx> anyway the script name is probably not enough, I would add the slot too for AIs
19:41:01 <Samu> yes, I know, I'm just not sure where to display, which order
19:41:56 <Samu> AI #xx Parameters of name
19:42:09 <Samu> AI Parameters of name (#xx)
19:42:57 <Samu> AI Parameters of name for Company xx
19:43:27 <andythenorth> TrueBrain: so...issue templates? o_O
19:43:31 <Samu> AI Parameters of name (Company xx)
19:43:35 <glx> (#xx) at the end I think but that's not the easier choice
19:44:38 <Samu> there's COMPANY_NUM string i believe
19:44:53 <Samu> but it requires the company to already exist
19:45:01 <glx> just use {NUM} and give it the slot
19:45:44 <glx> and that's where the complications start
19:49:13 *** Thedarkb2-T60 has joined #openttd
19:49:22 <glx> invalid for {NUM} but {NUM} can be {STRING1} and STR_JUST_INT
19:52:53 <glx> or easier, STR_JUST_RAW_STRING for GS and a string containing "{RAW_STRING} ({NUM})" for AIs
19:53:13 <peter1138> Oh well, that fix is "no worse" than it was before.
19:53:28 <glx> and just add slot as DParam 3
19:53:49 <peter1138> How can I test autorefit?
19:55:25 <glx> working with strings is not that hard
19:58:03 <andythenorth> peter1138: make a train, send it to a station?
19:58:13 <peter1138> With the no NewGRFs?
19:58:23 <andythenorth> got a branch? I can test
19:58:28 <peter1138> Well, I've never used autorefit, so I don't know how it's meant to behave, either.
19:58:34 <peter1138> andythenorth, I *know* it's broken :-)
19:59:05 <andythenorth> 'refit to fixed cargo' is trivial, you need a newgrf
19:59:21 <andythenorth> 'refit to available cargo' is super exciting magic
19:59:52 <peter1138> I might get away with just moving the last bit correctly. It was split over multiple lines so I missed it.
20:00:55 <peter1138> Autorefit should work.
20:01:27 <peter1138> GetCapacityString() for an auto-refit won't.
20:01:35 <peter1138> But I don't know where that's used.
20:02:06 <peter1138> It's in the RefitWindow itself.
20:02:25 <peter1138> So I need to get the GUI that opens the RefitWindow in auto-refit mode.
20:02:55 <peter1138> Any idea which set and which vehicle I can use to find it?
20:03:07 <peter1138> And should I throw away this deathdapter?
20:03:46 <Eddi|zuHause> throw everything away and buy new things, as often as possible.
20:03:57 <Eddi|zuHause> because the economy needs you
20:04:30 <peter1138> Has shielding on the earth pin.
20:04:51 <peter1138> Not enough space around the outside of the pins.
20:05:19 <TrueBrain> andythenorth: what about them?
20:05:39 <Samu> my excelent copy pasting skills found a solution, let's see if it actually works
20:06:05 <andythenorth> TrueBrain: (a) +/-1 from you (b) know of any we can steal? o_O
20:06:27 <TrueBrain> not sure my opinion matters in this, but it is also already merged, isnt it? :)
20:06:42 <TrueBrain> and no; all projects that I have seen that use it, are complete rubbish :P
20:06:50 <andythenorth> I am well behind in my notification :P
20:06:59 <andythenorth> keep up andythenorth
20:07:21 <TrueBrain> I disabled notifications :P
20:09:39 <Eddi|zuHause> notifications are evil...
20:10:53 <andythenorth> I like the web notifications
20:10:59 <andythenorth> obviously email notifications are evil
20:12:15 <peter1138> Nobody knows of a NewGRF that supports auto-refit?
20:13:54 <peter1138> Ok, found it in UKRS2.
20:18:12 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7139: Fix 11ab3c4ea2f: Fix showing cargo capacity for auto-refits (missed in #7134) https://git.io/fh1UH
20:20:19 <peter1138> Hmm, maybe need to check one more case.
20:21:33 <peter1138> Oh, no, I already confirmed that.
20:24:18 <peter1138> Right, how to put nielsm's code into practice...
20:27:38 <peter1138> Oh. BaseVehicle doesn't have index
20:32:42 * peter1138 tries a different tack
20:40:30 <Samu> why can't the Delete hotkey close windows in main menu
20:43:48 <Samu> i can now open 16 configs at the same time
20:46:34 <nielsm> oh, the FieldOffset/FieldWidth functions really oughgt to be constexpr, but then they may have to be rewritten with specialization for N==0 instead of conditional, to be valid C++11
20:48:10 <Samu> :{WHITE}{STRING} Parameters of {STRING1} {STRING1}
20:49:39 <Samu> SetDParam(3, STR_FORMAT_COMPANY_NUM);
20:49:39 <Samu> SetDParam(4, this->slot + 1);
20:50:15 <Samu> SetDParam(3, STR_EMPTY);
20:53:38 <Samu> if (visible_settings.empty()) delete this;
20:53:51 <Samu> the window now closes when there's nothing to display
20:57:17 *** Progman_ has joined #openttd
20:58:31 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #7139: Fix 11ab3c4ea2f: Fix showing cargo capacity for auto-refits (missed in #7134) https://git.io/fh1LE
20:59:55 <Samu> i dont know if it's sensible to allow 16 readmes + 16 licenses + 16 changelogs = 48 textfile windows open
21:00:31 <Samu> yeh, but it's what you suggested
21:00:33 <LordAro> Samu: it's not sensible to have 64 track types, it's still possible
21:00:58 <glx> no I suggested one settings window per AI
21:01:12 <glx> and one textfile per type
21:01:28 *** supermop_work has joined #openttd
21:02:18 <glx> (one textfile per type is in master btw)
21:02:38 *** Progman_ is now known as Progman
21:03:43 *** supermop_work_ has joined #openttd
21:14:14 <nielsm> oh, the FieldOffset/FieldWidth functions really oughgt to be constexpr, but then they may have to be rewritten with specialization for N==0 instead of conditional, to be valid C++11
21:14:42 <nielsm> meant to press up+enter in console...
21:30:39 <andythenorth> can we windowshade the station construction window? o_O
21:32:51 <Samu> (random) in that context looks weird
21:32:58 <Samu> Random AI would be better
21:34:13 <Samu> AI Parameters of Random AI
21:36:15 *** ChanServ sets mode: +v tokai
21:36:23 <andythenorth> so I have made some enterprise software now
21:40:08 <andythenorth> what was I fixing?
21:40:27 <andythenorth> replacing Tropic TGP? o_O
21:40:57 <peter1138> Easy, turn TGP off.
21:41:08 <andythenorth> it's an approach yes
21:41:20 <peter1138> Hmm, I could do with treat-warnings-as-errors.
21:42:27 <andythenorth> I like how original makes pyramids
21:42:56 <andythenorth> it does have a certain something
21:44:59 <andythenorth> shall I just delete the crap transform?
21:45:09 *** Supercheese has joined #openttd
21:45:41 <peter1138> Should I buy ADR1FT for 75p?
21:45:59 <andythenorth> practically free
21:46:09 <andythenorth> is there 75p of entertainment in it?
21:46:25 <peter1138> Possible. It's one of these new-fangled VR things.
21:46:32 <peter1138> Yes, I have a VR headset.
21:46:40 <peter1138> Yes, I'd rather just sit and develop code for OpenTTD.
21:47:30 <peter1138> That would've helped...
21:48:27 <peter1138> Is this the future? I don't know.
21:49:12 <peter1138> Logically it could just call the DoCommandP() itself, but then there's also the DoCommand() instances.
21:49:31 <LordAro> i wonder whether it might be nicer to have a DoCommandFooRefit function that just calls through to DoCommand
21:49:49 <LordAro> which is basically what you just said
21:50:07 <peter1138> Yeah, you'd need two of them, so more duplication.
21:50:13 <andythenorth> let's just delete case LT_TROPIC
21:53:41 <andythenorth> using the arctic generator gets more rainforest
21:54:04 <andythenorth> not sure it's really better eh
21:55:02 <andythenorth> can I reverse rivers so they flow from coast? :P
21:56:41 <andythenorth> oh no, just span the river gen for a bit
21:56:43 <andythenorth> trying to go up hill
21:57:03 <Samu> STR_TEXTFILE_README_CAPTION :{WHITE}{STRING} readme of {RAW_STRING}:{WHITE}{STRING} readme of {RAW_STRING}
21:57:08 <andythenorth> let's screenshot this :D
21:57:10 <Samu> what can I do with RAW_STRING?
21:57:53 <Samu> can {RAW_STRING} be turned into {STRING1}{STRING1} for example?
21:58:46 <Samu> first string1 for the script name, second string1 for which company slot it belongs?
21:59:19 <LordAro> Samu: there's not a lot of useful dev stuff on the wiki, but there is some :p
21:59:26 <nielsm> and it does build with --std=c++11
22:01:24 <LordAro> should probably have a static_assert for the fieldwidths being <=32
22:01:41 <LordAro> that is terrifying though
22:02:07 <andythenorth> return heightEnd >= heightBegin instead of return heightEnd <= heightBegin
22:02:14 <nielsm> LordAro, it does have that static_assert
22:02:36 <andythenorth> all rivers are flat
22:02:46 <LordAro> be nice if it could somehow "autogenerate" the get/set functions (or at least validate them), but i suspect templates aren't powerful enough for that
22:02:51 <LordAro> nielsm: ah yeah, same effect
22:04:17 <LordAro> also arbitrary return/parameter for the get/set :p
22:05:40 <andythenorth> I think I made mangrove swamps :P
22:06:09 <Samu> oh, SetDParamMaxDigits(uint n, uint count)
22:06:21 <Samu> this is useful for that 1-15 counter i have
22:06:56 <nielsm> so I think yeah this can be a good way to add type safety and enforced consistency to those bitpacks
22:08:03 <LordAro> nielsm: it is more code than peter1138's one or two line functions though
22:08:19 <LordAro> and i'm not sure it improves type safety *that* much more...
22:10:54 <nielsm> well he's shown packing, but not unpacking yet
22:11:15 <nielsm> it's the unpacking that's really interesting imo, since you want individual field access in some way
22:11:32 <nielsm> and I think my solution offers better syntax there
22:12:17 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 opened pull request #7140: Fix: make sure strgen fails when english.txt contains invalid commands https://git.io/fh13d
22:12:20 <nielsm> although it is boilerplatey
22:13:18 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh approved pull request #7140: Fix: make sure strgen fails when english.txt contains invalid commands https://git.io/fh13h
22:15:24 <peter1138> nielsm, we already have helpers for unpacking.
22:15:53 <glx> there's already an error check after parsing, but parsing doesn't check commands in strings.h phase, but they are checked when writing strings.h content, I just added a check after that
22:15:55 <nielsm> peter1138, the problem is keeping the bitfield addresses in sync everywhere that depends on them
22:16:10 <Samu> SetDParamMaxDigits(0, 20);
22:16:11 <Samu> uint widest_cid = GetStringBoundingBox(STR_JUST_INT).width;
22:16:17 <peter1138> nielsm, that's why in my patch I intend to place the Pack version directly before the command handler.
22:16:18 <Samu> it works! just 2 lines, no for cycle needed
22:16:23 <peter1138> (I didn't for Autoreplace, yeah)
22:16:36 <Samu> oops, it's not 20, it's 2, typo
22:16:38 <peter1138> Not perfect, but it's not spread out everywhere!
22:18:02 <peter1138> Also I don't see how you'd fit your stuff in at the moment.
22:19:56 <glx> windows tasks on CI are slow since the addition of baseset project ;)
22:20:37 <peter1138> I think I am spoiled by having lots of CPU cores.
22:20:56 <LordAro> someone should finish rewriting the build system into cmake
22:21:05 <peter1138> Yes. Who was working on it?
22:21:19 <LordAro> more recently than TB, anyway
22:22:28 <peter1138> Urgh, there's so many commands :D
22:22:32 <nielsm> the build on windows also stalls on the basesets with VS, since the baseset builds are single-threaded, and the main project is declared as depending on it
22:22:47 <peter1138> It should only build once.
22:23:00 <nielsm> well it rebuilds every time a language file changes :)
22:23:01 <peter1138> Hmm, I guess it's because we're getting a lot of language updates.
22:23:20 <peter1138> If the baseset translations were separate then that'd be better.
22:23:31 <peter1138> Why *are* the baseset translations in the language files?
22:23:40 <glx> pff CI passed but failed to notify github
22:23:44 <LordAro> simplicity, i imagine
22:23:48 <peter1138> Just for ease of webtranslator/eints integration?
22:24:23 <peter1138> And also, if the strings are in our language packs...
22:24:32 <peter1138> Can't the baseset refer to them by string ID?
22:24:54 <peter1138> Oh right, we don't have a method to look up string ID by name.
22:25:00 <LordAro> the baseset itself doesn't refer to them, it's the metadata
22:25:02 <peter1138> Because that's compile time.
22:25:14 <peter1138> Yes of course, that's what I meant.
22:25:30 <peter1138> Ever so pedantic :)
22:25:53 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 merged pull request #7140: Fix: make sure strgen fails when english.txt contains invalid commands https://git.io/fh13d
22:26:12 <glx> at least I can bypass CI ;)
22:26:13 <peter1138> glx, is this to "help" Samu? :p
22:26:29 <nielsm> hm better get to bed, back to work tomorrow
22:26:52 <Eddi|zuHause> some people can't be helped
22:27:03 <glx> don't know if it will help, but at least it cancels the build
22:28:54 <glx> and no string warnings spam when there's an error in english ;)
22:29:00 <Samu> i have the language files with STR LIVERY and now STR AI CAPTION blabla
22:29:22 <Samu> do i have to delete the strings from languages?
22:31:20 <Samu> let's see how it complains now
22:32:24 <Samu> arg, can't rebase before commiting
22:32:35 <peter1138> Or stash, then unstash
22:33:02 <glx> yes git stash, rebase, git stash pop
22:44:15 <Eddi|zuHause> i love that the traffic light turns red but he still goes
22:45:20 *** Wormnest has joined #openttd
22:47:00 <Wolf01> <Eddi|zuHause> i love that the traffic light turns red but he still goes <- is really traffic lights or an overheight indicator?
22:47:43 <Eddi|zuHause> it's apparently an overheight indicator disguised as a traffic light
22:48:08 <Samu> alright, let's see how it builds now
22:48:55 <Samu> str livery and now str caption
22:49:16 <Samu> I hate editing existant strings
22:56:24 <Samu> I can't edit the TEXTFILE window caption the same way as you did for AI Settings window
22:57:17 <Samu> unless I break everywhere else it's used
22:58:16 <Samu> the livery error seems to be the same kind of error i'm getting, interesting
23:02:47 <DorpsGek_II> [OpenTTD/OpenTTD] michicc merged pull request #7139: Fix 11ab3c4ea2f: Fix showing cargo capacity for auto-refits (missed in #7134) https://git.io/fh1UH
23:02:49 <andythenorth> scaling run costs is a total PITA
23:03:32 <andythenorth> might be easier to set them manually, compared to the algorithm I have that applies them same to all vehicles
23:03:39 <andythenorth> but eh, manual :P
23:05:58 <LordAro> andythenorth: #7109 poke
23:06:20 <andythenorth> I am running savegames on FFWD watching costs :P
23:08:00 <andythenorth> very high speed trains are making less money than slightly high speed train
23:08:53 <andythenorth> run costs might need to scale by game era, but that sucks for game start :P
23:09:05 <andythenorth> and might be inverse to RL, dunno
23:09:21 <andythenorth> inflation is definitely out of scope :)
23:10:06 <Samu> so, the only way these livery errors disappear is when all translators update them?
23:10:06 *** Thedarkb-X40 has joined #openttd
23:10:34 <peter1138> But eints decided it knew better and put them back.
23:11:20 <Samu> uhm, i see {COMPANY} in english.txt
23:11:40 <Samu> STR_LIVERY_CAPTION :{WHITE}{COMPANY} - Colour Scheme
23:12:19 <peter1138> I removed the strings from the *other* language.
23:12:54 <Samu> ah, EINTS is the dude that edits strings in
23:13:55 <andythenorth> hmm, scale costs by type of train maybe?
23:14:10 * andythenorth was just using speed + power
23:14:15 <andythenorth> but it's too crude
23:14:28 *** andythenorth has left #openttd
23:21:10 <Samu> maybe because the string has still the same name?
23:23:29 <Samu> yeah, i dont know how eints machine decides what to do
23:35:15 <Samu> hmm the .lng file STR_LIVERY_CAPTION was compiled with the english version
23:35:35 <peter1138> What are you going on about?
23:36:09 <Samu> but the .txt file conatins the string with the other language
23:36:22 <Samu> .lng and .txt don't match
23:36:34 <peter1138> What are you going on about?
23:37:47 <Samu> looking at the contents of portuguese.txt and portuguese.lng
23:38:27 <peter1138> I mean, why are you looking at it? What's the purpose?
23:39:05 <Samu> î€î€¥î†î€ - Colour Scheme
23:39:36 <Samu> {WHITE}Novo Esquema de Cores
23:39:48 <peter1138> Why are you bothering?
23:39:56 <peter1138> We know the language files are wrong.
23:40:03 <peter1138> The language system is working as intended.
23:40:14 <Samu> but the mismatch is on purpose?
23:40:46 <peter1138> warning: STR_LIVERY_CAPTION: Param idx #0 '<empty>' doesn't match with template command 'COMPANY'
23:41:07 <peter1138> strgen knows the translations are wrong, so it can't use that translation.
23:41:25 <peter1138> If it can't use the translation, it'll use English.
23:41:50 <Samu> ah, I see, it avoids crashes
23:42:54 <peter1138> Yes, strgen didn't spend an hour or so pointlessly.
23:47:42 <LordAro> peter1138: well, who hasn't spend a pointless hour or so trying to work out how something works?
23:51:55 <Samu> SetDParamMaxValue is actually better for what i need
23:53:44 <peter1138> I spend ages writing patches and then rewriting them and then just ditching them.
23:55:34 <Samu> SetDParamMaxValue(0, MAX_COMPANIES);
23:55:34 <Samu> uint widest_cid = GetStringBoundingBox(STR_JUST_INT).width;
23:56:02 *** Thedarkb-T60 has joined #openttd
continue to next day ⏵
