IRC logs for #openttd on OFTC at 2023-01-14
⏴ go to previous day
00:34:44 <glx[d]> from 2,5 hours to 12 minutes
01:03:28 <glx[d]> but version is norev0000
01:11:16 *** sla_ro|master has quit IRC ()
02:04:14 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:04:21 *** WormnestAndroid has joined #openttd
02:10:36 *** ChanServ sets mode: +v tokai
02:17:18 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
03:20:05 *** Wormnest has quit IRC (Quit: Leaving)
03:21:28 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:25:14 *** D-HUND is now known as debdog
05:00:40 *** _aD has quit IRC (Quit: leaving)
05:03:18 *** HerzogDeXtEr has joined #openttd
06:55:24 *** Speedy` has joined #openttd
08:34:58 *** All_Heil_Lord_Pepe has joined #openttd
08:34:58 <All_Heil_Lord_Pepe> How easy is it to get the font in the map window changed? Spent most of my time in the showcase server looking at print factory not paint factory because the the "A" and the "R" look the same...
08:37:55 <Pruple> All_Heil_Lord_Pepe: open the console with the ~ key, type "font small <the name of the font you want> <the size of the font you want>
08:38:53 <Pruple> just type "font" if you want to see what your current font settings are
08:39:16 <Gwyd> Is there a limit on varact2s in a grf?
08:39:56 <glx[d]> No, but you can't have more than 255 active ones
08:42:04 <All_Heil_Lord_Pepe> Pruple: is there a list I could reference?
08:42:31 <glx[d]> Depends on your system
08:45:19 <Pruple> "font settings" to see what you have installed in windows. or just look in your word processing software of choice 🙂
08:47:35 <All_Heil_Lord_Pepe> underspaces for multi word ones or no?
08:48:09 <Pruple> put it in "quotation marks"
08:50:42 <Pruple> glx[d]: unlimited per action 3, surely - you can reuse IDs in action 2 chains. You just can't have more than 255 places-it's-possible-to-get-from-here at any point in the tree.
08:52:14 <All_Heil_Lord_Pepe> "font small eurostar 13" gives me command not found red text...
08:52:30 <All_Heil_Lord_Pepe> but font ariel 13 works
08:53:28 <glx[d]> Retry first command without quotes
08:53:51 <glx[d]> Only use quotes around font name itself if it has spaces
08:56:03 <All_Heil_Lord_Pepe> now the problem is, I set it to ariel, I can't change it again.
08:57:45 <Pruple> it seems quite flaky to me whether it lets me change the settings, or whether it just responds as if I'd done "help font" 🤔
08:57:52 <Pruple> I'm not sure what's going on
08:58:14 <glx[d]> If you get help message nothing changed
08:59:18 <glx[d]> It's the usual error indication in openttd commands
08:59:50 <Pruple> it doesn't seem to want to let me change the aa setting 🙂
09:00:41 <Pruple> and type the right thing 🙂
09:01:09 <All_Heil_Lord_Pepe> console is showing me for small: small: "Arial" 10 false ["Futura_Md_BT" 10 false]
09:01:23 <Pruple> "aa" or "noaa" instead of "true" or "false"
09:02:03 <glx[d]> Means it didn't found the required font, or it's missing some glyphs
09:02:20 <petern> Does the font name actually have udnerscores in it?
09:02:58 <All_Heil_Lord_Pepe> no, I typed it in as "Futura Md BT"
09:07:32 <All_Heil_Lord_Pepe> yeah, I can't change it back to default. Is it possible via the config?
09:10:49 <All_Heil_Lord_Pepe> restart fixed it
09:11:18 <glx[d]> Pruple: Maybe the status should also say aa/noaa too
09:11:27 <All_Heil_Lord_Pepe> that futura font is ugly
09:12:41 <glx[d]> Oh maybe futura is missing glyphs for normal font
09:17:38 <All_Heil_Lord_Pepe> Arial bold is probably the only one that fixes my issue without looking like poo on my screen
09:22:46 <nielsm> tahoma is my font of choicce
09:23:14 <petern> Hmm, did I try bilinear scaling...
09:55:51 <petern> Hmm, rain not as heavy as anticipated but wind is windy.
09:56:01 <andythenorth> 2h 53m until fully charged
09:56:04 <andythenorth> my laptop, or me?
10:31:42 <petern> Hmm, I should just bin this old bluetooth keyboard.
10:31:57 <petern> Never worked right, laggy input.
10:33:21 <petern> How do I select MIDI output device for OpenTTD on Windows?
10:38:32 <Samu> wow, you guys are so complete!
10:45:37 <nielsm> petern: musicdriver = win32;port=2
10:45:49 <nielsm> or was it : separating parameters
10:58:39 <Samu> eh Rubidium, i thought the idea of random being reproducible was for single player only, and not multiplayer
10:59:40 <Samu> at least that was the idea transmitted by the comments i've came across
11:00:24 <petern> You were so focused on one task you didn't quite get what he suggested.
11:08:44 <Rubidium> Samu: that's how it's currently implemented because there are only two sources of random available. But what if scripts get their own source of random that they do not need to share with anything else?
11:12:11 <Rubidium> also, if you with #10344 have a reproducible script and add a "random AI" (which only calls Rand()), then the game is not reproducible anymore even though the new AI does not change the actual game state. It's only that the calling of Rand() causes the game state changes. With #10349 those Rand() calls only affect the "internal" state of that script, and the game is reproducible again
11:16:40 <Samu> that's the script_config issue
11:20:06 <petern> Looks good so far Rubidium.
11:26:54 <Rubidium> the "only" conundrum is where to store the random state. The instance does not exist early on, I do not have reasonable access to the config from the script and saving random state in the config seems a bit weird. The script config creation/construction also uses random, so it's not quite there either. Company doesn't exist for script...
11:29:47 <Rubidium> ... so I'm seriously considering just Randomizer _script_random[OWNER_END]; and saving that lot and silently ignoring that it will have 3 spots that will never be used, and just save 19*8 bytes in misc_sl
11:33:18 <petern> That makes access simple, yeah... _script_random[owner]
11:34:12 <petern> Is there a base class that can sit in instead of global namespace?
11:34:30 <Rubidium> ScriptObject would be the place
11:35:22 <petern> Lots of static in there already 🙂
11:42:10 *** sla_ro|master has joined #openttd
11:44:00 <Samu> oh, the company manager face bits stuff, I failed to catch that one
11:59:27 <petern> Someone really hates wide rivers 🙂
12:12:56 <petern> Hmm, I wonder if we should disable aa/noaa as a choice?
12:13:19 <petern> Or is that still a 8bpp -> 32bpp switcher?
12:16:26 <michi_cc[d]> Well, AA doesn't switch anything, it will just be silently ignored for an 8bpp blitter.
12:54:57 <petern> How do people accept this? :/
12:59:40 <Rubidium> under pressure of $MANAGEMENT, after a written note in their personnel file?
13:00:38 <reldred> Don’t look at my commit logs on my own projects….
13:03:10 <petern> I can only hope they squash that on merge...
13:16:27 <TrueBrain> some of my colleagues do that .. and it is why we enforce squash 😛
13:22:59 <glx[d]> There's a reason why we have commit checker for a long time
13:23:15 <glx[d]> (even if some never accepted it)
13:32:10 <TrueBrain> he did a reverse uno
13:33:05 <michi_cc[d]> The good old days of "wrong!" 🙂
13:33:52 <petern> Hmm, oh right, of course, we had the commit title checker back in the svn days, long before all the CI stuff.
13:43:34 <Samu> is there a way to force a language for scripts? station names, etc... have localized strings, and when that's converted to text, it would be better to default it to "having an openttd running in english"
13:45:03 <Samu> instead of whatever language im running openttd atm
13:47:07 <Samu> there are script functions with GetName, and that wouldn't come up with the same name on different systems
13:48:35 <glx[d]> Names are only useful for logging
13:49:07 <Samu> erh, no, some AIs abuse it for decisions
13:51:56 * Rubidium votes for not allowing abuse ;)
13:57:42 <glx[d]> AI gets the exact same info as player, so it should not expect a language
13:58:33 <petern> As a player I can choose my language though.
13:59:20 <glx[d]> but the language is for all the instance
13:59:31 <Rubidium> hmm... I'm wondering. Is there actually a real point in saving the script's random state? After loading a game it's almost guaranteed that the script is not in the same state as it was in when saving; after all, we're not saving the whole situation on the stack but the script starts from Main. So if the script was already building something that would be rudely aborted, and the script would not continue
13:59:37 <Rubidium> the same way. So, it only holds for restarting a newgame with the same seed/configuration and when comparing starting from the same savegame twice. So basing it of the single random seed we save now should be enough, right?
14:00:19 <glx[d]> but if you reload the same save you might want the same decisions
14:00:44 <TrueBrain> Once upon a time we had the idea AI authors could implement save/load routines, such that they could keep state. But that utterly failed 😛
14:01:13 <glx[d]> oh some AI implement empty Save() and no Load()
14:01:24 <andythenorth> doesn't GS have saveload?
14:01:40 <andythenorth> I remember I broke BusyBee because I didn't know that
14:01:58 <andythenorth> managing state....brrr
14:02:39 <Pruple> AI has saveload, the question is how much effort as an AI author you want to put into remembering exactly what it was doing, vs simply abandoning anything complex it was in the middle of and starting over 🙂
14:03:27 <petern> Can we just save state automatically or is that not feasible?
14:03:39 <petern> Version changes etc...
14:03:50 <JGR> The save opcode limit is quite tight, so you can't save much state anyway
14:03:50 <andythenorth> isn't it potentially really large?
14:03:57 <Rubidium> petern: then you need to save the complete heap
14:04:45 <glx[d]> and all c++ objects that may have been created
14:04:49 <Rubidium> and ofcourse the stack, and which command it is waiting for which you might need to resend if it was in transit
14:06:38 <Rubidium> so now I'm doing: new game -> Save(a) -> state X, restart game with same seed etc -> state X, Load(a) -> state Y, Reload(a) -> state Y
14:09:11 <glx[d]> and it's better than nothing I'd say
14:09:44 <glx[d]> and you won't see my can->can't edit
14:33:56 <Brickblock1> I am having a weird issue where odd length vehicles are being offset differently than even numbered ones
14:37:19 <Brickblock1> these two have the same template and centred placement within the png file so there shouln't be a gap
14:41:23 <Pruple> if you're using the same template, short vehicles shouldn't be "centered within the png file". short vehicles have the front in the same place, and are shorter at the back.
14:43:51 <Brickblock1> time to redo the whole thing again
14:53:01 <glx[d]> used to generate the docs (api pages)
14:54:01 <Samu> im finally receiving email notifications on windows 11
14:54:30 <Samu> the mail program was missing when i upgraded from windows 10, stupid microsoft, had to install it manually
14:59:23 <petern> You say that as if there is only one mail program.
14:59:59 <glx[d]> I think I have an idea to somehow test reproducibility with #10349
15:00:51 <glx[d]> I'll make a savegame in master, then use start_ai, reload and redo, and the same with #10349
15:03:49 <glx[d]> and in theory I should get the same AI scripts, with same names/faces with #10349
15:05:05 <Rubidium> restart doesn't quite work yet though :(
15:05:51 <glx[d]> but at least reproducible savegame should be a nice improvement
15:18:01 <petern> Hmm, 10349's task list changed 🙂
15:18:44 *** Wormnest has joined #openttd
15:19:18 <Rubidium> petern: yes it did, less is more ;)
15:21:31 <Rubidium> did we have some savegame diff tool somewhere? I want to compare some savegames, but I moved the viewport accidentally and I don't want to reinvent the wheel if at all possible
15:23:03 <Rubidium> in any case, restart seems to be reproducible based on the financial state of an AI after 1 year
15:36:05 <glx[d]> it's already better, there's still some Random() differences, but that's very minor
15:37:15 <glx[d]> and I don't think colour/face/president will have an effect on how the AI works
15:45:13 <Rubidium> those Random() differences are due to the "Interactive" Random() that you added yourself for timing the start_ai calls
15:46:14 <Rubidium> and that'll throw of the rest of the life of the AIs as well. Though, it chosing the same AI means that it's at least using the same random stream to chose/initialize them
15:54:10 <glx[d]> yeah I just executed `start_ai` without measuring when to press enter 🙂
16:01:42 <Samu> MakeRiverAndSetNearbyDesertNormal
16:03:22 <Samu> i thought RiverModifyDesertZone was sufficiently self-descriptive
16:09:42 <Samu> MakeRiverAndModifyDesertZoneAround
16:17:00 <petern> Hmm, Russian piano music can be a bit crazy.
16:17:23 *** supermop_Home has joined #openttd
16:21:44 <glx[d]> console scripts don't fully work, I tried a script to load then call start_ai, the loading is fine, but that's all
16:22:13 <glx[d]> seems it doesn't wait for loading to finish
16:29:46 <Samu> if I do CircularTileSearch(&tile etc...
16:30:01 <Samu> instead of TileIndex t = tile; CircularTileSearch(&tile
16:30:11 <Samu> instead of TileIndex t = tile; CircularTileSearch(&t
16:38:02 <glx[d]> t will be modified during the call
16:38:29 <Rubidium> though in MakeRiverAndModifyDesertZoneAround it should be fine since tile is passed by value
17:33:29 <supermop_Home> shoot film or draw better shading on train station sprites?
17:40:25 <Samu> i can move it to below, closer to CircularTileSearch
17:44:21 <Samu> lakeCenter shouldn't it be named lake_center or lakecenter?
17:44:33 <Samu> code etiquete or whatever
18:00:04 <petern> That PR title is still terrible.
18:01:14 <petern> It has a massive "but why?" hanging on it.
18:05:53 <Samu> regression failed here on my system, :)
18:06:23 <Samu> I change one thing, boom!
18:07:20 <Samu> i made it smartly not call Random() all the time
18:07:36 <Samu> and that was sufficient to break regression
18:39:15 *** supermop_Home has quit IRC (Ping timeout: 480 seconds)
18:43:32 <DorpsGek> - Update: Translations from eints (by translators)
18:52:31 <Samu> i had an autoreplace test case in the other PR about the groupstatistics issue
18:54:36 <Samu> I'll post it there later for testing
18:58:26 *** Flygon has quit IRC (Remote host closed the connection)
19:03:06 <andythenorth> Horse 88% complete
19:03:10 <andythenorth> 93 trains to draw
19:03:15 <andythenorth> better get on that eh?
19:05:17 <petern> What about subvariants? Should I fix the hierarchy line?
19:19:38 *** gelignite has joined #openttd
19:21:24 <petern> Well the issue is the line doesn't get drawn 🙂
19:21:31 <TonyPixel> Oh that actually looks nice
19:22:06 <petern> 2TE10M-K should be linked back up to 2TE10M 🙂
19:33:40 <michi_cc[d]> Looking at the various variants screenshots, alternative name strings seem like a good idea.
19:34:00 <michi_cc[d]> Though, as far as I can tell, the string space for callback/prop returns is quite limited, isn't it?
19:34:33 <michi_cc[d]> Could of course do some special action 4 hackery, but a callback with context and like variant level would seem the best.
19:50:30 <andythenorth> +1 to some sort of name string shenanigans
19:50:37 <andythenorth> but might be fine to wait a while to see what
20:00:42 <michi_cc[d]> andythenorth: How many variants do you have right now? Just trying to figure out if the CB route would feasible at all without somehow making the Dxxx string range somehow larger.
20:02:56 <andythenorth> I probably have less than garlic_bread42 is showing screenshots for 😛
20:03:01 <andythenorth> in the add on channel
20:03:09 <andythenorth> I will run a counter
20:05:32 <TrueBrain> no worries; seems that squashes the last errors on CodeQL, not? 😄
20:07:18 <andythenorth> michi_cc[d]: currently about 160 variants
20:07:34 <andythenorth> seems like it should be higher than that
20:09:23 <Rubidium> yes, it should. After that there are "only" warnings and notes left. Already solved some other warnings, but haven't made a PR yet as that code currently 3 branches deep
20:10:04 <andythenorth> michi_cc[d]: re-checked, it's about 600
20:11:45 <andythenorth> D0xx strings are 1024? DCxx is 2048?
20:11:54 <TrueBrain> Rubidium: understandable 😄 Well, after this PR, let's merge the CodeQL, and fix the warnings as we go 🙂
20:12:47 <Rubidium> yep, #10299 should get a green checkmark instead of the annoying red cross when #10327 merges and I rebase #10299
20:13:49 <michi_cc[d]> Yeah, D0xx is 1024, and I don't even know what DCxx is supposed to be used for.
20:16:32 <andythenorth> I won't hit that D0xx limit, but I suspect others might, looking at what is being done with variants
20:17:07 <andythenorth> I'd like a more structured name text I think, with base name, variant name, and arbitrary suffix
20:17:14 <andythenorth> but I don't know what the spec would be
20:18:01 <Samu> I'm bad at names and I'm told to rename stuff :(
20:19:26 <michi_cc[d]> I was mostly thinking about a Callback that gets some context info (like purchase list, preview, vehicle info etc, and for purchase list additional context like variant nesting level). Structured text would require the textstack as well I think.
20:20:34 <michi_cc[d]> The super hacky basic way is to have a "fake" action 4 feature to provide an alternative vehicle name to be used if the vehicle is not displayed at the top-level for purchase list just to avoid having to see the actual vehicle name duplicated 20 times.
20:25:15 <petern> There's also the case of having the top-level purchase list name be different from the purchased engine name.
20:26:09 <andythenorth> I don't know what exactly is 'good' but purchase list could be better
20:26:22 <andythenorth> players seem to want to hide / show more UI things
20:26:58 <petern> Are you increasing the scope of changes just to ensure nothing gets implemented?
20:29:47 <andythenorth> not intentionally 😛
20:30:59 <andythenorth> unicode emoji and svg icon support would be a good way to do that 😛
20:35:40 <frosch> michi_cc[d]: the cb string limit is caused entirely by the cb return values. most callbacks use values 0-3ff for strings, and higher bits for special magic. for callbacks with textstack it's possible to work around the limit by returning a string which is essentially "{STRING}" and then using the textstack to pick from a larger range of strings
20:36:01 <frosch> however, not all callbacks support the textstack
20:36:10 <frosch> particulary cargo subtypes do not
20:37:16 <michi_cc[d]> Well, a new callback can support anything it wants. But I do see in the Action 4 processing that generic string ranges are D000-D400 and D800 to E000, which is technically less that the engine limit.
20:37:16 <petern> Have I removed subtypes yet? 😈
20:37:54 <michi_cc[d]> Whereas the feature-specific action 4 allows one string per engine with no limit on its own.
20:39:33 <andythenorth> do we like props or callbacks more? 😛
20:39:52 <frosch> there are only a dozen of original TTD strings, which are exposed by ottd in the 0000-CFFF range, and E000-FFFF is ttdp stuff
20:40:05 <frosch> otherwise all 64k string ids could be grf specific
20:41:31 <petern> Do we expose original strings at all? Seems a bad idea as we don't ensure the IDs don't change...
20:41:48 <petern> Right, there's a mapping...
20:41:48 <frosch> so i guess adding 0x5000-CFFF should be no problem
20:42:00 <frosch> usable in properties and on textstack, but not directly as callback result
20:42:06 <petern> That's annoyingly spread out 😦
20:42:34 <frosch> petern: we can only expose strings without parameters, mostly cargo names and stuff
20:42:50 <petern> Hmm, actually we could probably allow redefining those IDs?
20:42:57 <frosch> ok, fair, contradicting myself, cargo-amount-strings have parameters :p
20:43:18 <petern> If the GRF doesn't override it, but uses it, then it uses the default mapping.
20:43:26 <frosch> true, that could work as well
20:43:27 <petern> If the GRF does override it, it gets its own string for that ID.
20:44:58 <michi_cc[d]> Or to stay at least somewhat compatible, allow D000 up to FFFF, with the callback returning the string id - D000. Still inside the 15-bit result and with 12287 strings somewhat large.
20:45:50 <michi_cc[d]> With how the current callbacks are defined.
20:46:34 <frosch> i would not extend the 0000-03FF callback results
20:47:27 <frosch> allowing redefinition of all strings shifts to problem to NML to decide which strings are kept, so not much of an advantage
20:48:42 <frosch> but considering that the variant names seems to be mostly combinations of strings "engine model + operator + livery", the textstack sounds like a saner option
20:49:04 <frosch> then you can have a single template string in the 0000-3FFF range, and then pick the other components via the stack
20:50:02 <petern> Only problem with that is different GRFs then coming up with their own ways to label things.
20:50:17 <petern> So maybe it should be not quite so flexible.
20:50:21 <frosch> looks like E000-FFFF are ttdp only, so extending the grfstrings to those is no problem
20:50:37 <petern> Of course that requires consensus...
20:50:52 <michi_cc[d]> frosch: What about that strange & ~0x400 modification that string code 81 applies to the text id?
20:52:35 <frosch> michi_cc[d]: that is some ttdp crap, ttdp adds 400 to distinguish whether it already resolved the grf-local id to a global one, and requires D0xx and D4xx strings in different places. ottd solves the mess by saying those ids refer to the same string in all cases
20:52:49 <frosch> so in ottd you can use D123 and D523 in all places, and they will be the same string
20:53:05 <frosch> while in ttdp exactly one of those ids will work in some place, and the other in some other place
20:53:53 <michi_cc[d]> Do basically apply this in the existing D000 and D800 range, but not apply it beyond E000?
20:54:17 <frosch> yes, it is already not applied to the D800-DFFF range
20:54:20 <michi_cc[d]> Oh, actually, just the D000 rantge
20:58:09 <frosch> looking at that... why did noone ever ran out of house names?
20:58:18 <frosch> it feels like grf should have more than 256 houses 🙂
20:58:56 <frosch> funny, andy complained about the 256 objects limit, but not about the 256 stations limit
21:07:39 <andythenorth> frosch: jeez, give me time
21:08:01 <andythenorth> finding all the limits isn't automated yet 😛
21:08:11 <andythenorth> can chatGPT write grf yet?
21:11:21 <glx[d]> writing valig grf is not too hard, but writing working grf is on another level 🙂
21:11:59 <andythenorth> humans manage it 😛
21:14:39 <Rubidium> glx[d]: I've already decided that I'm not going to touch that alert :8
21:30:37 <Samu> what is that error I'm getting?
21:34:00 <Samu> commit checker does not like me for some reason
21:34:35 <glx[d]> rebase failure it seems
21:40:33 <petern> Nice, in that list of old scenarios there are two which are actually savegames
21:45:37 <glx[d]> nice we now have all FIXME in one place
21:48:50 <Samu> i get 404 page not found
21:49:49 <petern> Looks like it's private.
21:51:33 <Rubidium> glx[d]: why would we ignore that one, it's quite easy to solve and doesn't hurt much. But... maybe just before the next release branch is made, not just after
21:52:30 <glx[d]> at least it's no longer used everywhere like in the old time
21:58:13 <frosch> why? it's not related to loading
21:58:31 <frosch> i think with assertions enabled it would already have asserted when changing the grfs
21:58:53 <frosch> and that thing is already disabled by default, hidden away, with big error messagesd
21:59:49 <frosch> maybe you can intercept the display of the assertion message, and add a "probably caused by you changing grfs" to all errors 🙂
22:00:23 <nielsm> sorry, "regarding" was the wrong word to use, I meant to say "after reading this I had a thought that maybe doing this could save some simillar questions in the future"
22:00:57 <petern> Changing NewGRFs doesn't necessarily corrupt it... so.
22:01:28 <nielsm> set a flag while reading the gamelog if there are newgrf changes mid-game, "potentially problematic"
22:02:18 <Rubidium> nielsm: you could check the gamelog whether NewGRFs have been changed and then show the same fat warning as you got when you changed it in the game. Just every time you load the game, to spite you
22:03:38 <glx[d]> if done with extreme care, changing newgrf can be safe
22:04:22 <JGR> Warnings at every load will just lead to alarm fatigue
22:04:40 <JGR> Users will eventually ignore all text in a red box
22:26:16 <petern> JGR: They do anyway, but yes 🙂
22:26:30 <petern> It would be nice if the game didn't crash though...
22:27:40 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:29:46 <petern> Hmm, "Courier New Bold 10" is a different height to "Courier New 10"
22:29:55 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:30:12 *** WormnestAndroid has joined #openttd
22:33:08 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:39:49 *** enick_570 has quit IRC (Quit: Reconnecting)
22:39:54 *** enick_570 has joined #openttd
22:39:57 *** enick_570 is now known as YourOnlyOne
22:42:18 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:42:25 *** WormnestAndroid has joined #openttd
22:43:56 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:56:48 <andythenorth> but I can't be arsed to paint Horse trains
22:58:20 <andythenorth> what do I have to do to get a hilly map?
22:58:25 <andythenorth> I might start a new game
22:58:48 *** supermop_Home has joined #openttd
22:59:59 <petern> Hmm, will an extra layer of indirection hurt NewGRF spec lookups?
23:00:27 <petern> Hilly map with wide rivers for ship variants.
23:00:37 <petern> And lots of locks so that ship power is important.
23:01:18 <petern> How many objects can are allowed per NewGRF?
23:02:35 <petern> How many Object NewGRFs are there?
23:03:22 <petern> Okay, how many NewGRFs can be loaded?
23:04:07 <supermop_Home> idk if a locks should be all that dependent on ship HP?
23:06:14 <andythenorth> ok Horse grfid bumped, official
23:08:10 <petern> supermop_Home: Seems to be 255 now.
23:08:55 <petern> You have to load 250 object NewGRFs, each with 255 objects, to be able to reach the object limi.
23:09:52 <andythenorth> ok lol the 50 attempts to get a map where ports are not in small landlocked lakes 🙂
23:09:56 <andythenorth> such a great game
23:10:35 <petern> Hmm, how big is ObjectSpec
23:12:46 <petern> The game allocates 4MB of memory just in case you want to load any objects.
23:16:20 <petern> I have a patch for that 🙂
23:16:25 <michi_cc[d]> Hmm, I'm assuming GS/AI can use `{ENGINE}` in strings. How to provide context there...
23:19:04 *** Wormnest has joined #openttd
23:22:09 <Rubidium> michi_cc[d]: only GS can use them, I think. With strings created via game_text.cpp
23:23:44 <Rubidium> michi_cc[d]: what do you want to achieve/change?
23:33:55 <andythenorth> finally got a map 🙂
23:34:42 <michi_cc[d]> rubidium42viaGitHub: Engine name callback (mostly for the variant stuff in the build/replace GUI).
23:35:28 *** Samu has quit IRC (Quit: Leaving)
23:39:38 <Rubidium> ah, so ENGINE would be requiring two parameters? Maybe bitshift the variant information into the parameter? After all, the EngineID only needs 16 of the 64 bits
23:40:17 <michi_cc[d]> That's actually not a bad idea, especially as that avoids any change of the (saved) GSText things.
23:40:52 <Rubidium> that might even be a way to expose the variants to AI/GS; don't really show the hierarchy, just a long list of engines with extra bits set for the different variants
23:41:19 <Rubidium> that way AI/GS can also build the variants without having to require actual support for variants
23:41:49 <michi_cc[d]> Variants are already exposed to AI as variants are literally only an UI grouping of different engine IDs.
23:43:04 <michi_cc[d]> But with only the single name string, this leads to a lot of duplicate information on screen in the engine list (as can be seen in screenshots on the non-IRC Discord channel #add-on-development channel).
23:44:34 <petern> Rubidium: I have a patch that allows 1000000 EngineIDs, for when andy creates too many variants...
23:45:15 <michi_cc[d]> Well, still space in an 64-bit int left 🙂
23:46:03 <petern> Hmm, maybe better to return an empty spec rather than a nullptr.
23:46:53 <petern> Hmm, default object initialization seems wrong.
23:47:29 <Rubidium> petern: that must be quite a big patch
23:50:33 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:50:56 *** WormnestAndroid has joined #openttd
23:51:04 <petern> It's actually not. Of course I can't test with anything near the current limit even....
23:51:43 <petern> It was mainly a joke, so I didn't spend much time checking 🙂
23:55:24 <Eddi|zuHause> petern: the limiting factor for engine IDs is usually the articulation callback
23:55:57 <Eddi|zuHause> where only 14 bits are usable
23:56:17 <michi_cc[d]> Rubidium: Can remember the PR number, but there was a "make scrollbar 32-bit" PR.
23:56:19 <petern> That doesn't limit how many engine IDs you can use, only how many engine IDs you can use as articulated parts.
23:56:27 <petern> There was, by LordAro.
23:57:31 <Eddi|zuHause> petern: dunno about andy, but i use a LOOOT of articulated parts
23:58:23 <andythenorth> just use the same ID and cb 36 😛
continue to next day ⏵
