IRC logs for #openttd on OFTC at 2023-01-31
⏴ go to previous day
00:03:25 *** Wormnest has joined #openttd
00:56:01 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:12:09 *** KiriDore has joined #openttd
01:33:55 *** Wormnest has joined #openttd
02:27:26 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
02:35:25 *** Wormnest has joined #openttd
02:42:47 *** Wormnest has quit IRC (Quit: Leaving)
03:52:53 *** debdog has quit IRC (Ping timeout: 480 seconds)
06:02:01 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:35:51 *** sla_ro|master has joined #openttd
08:59:32 *** TROILUS has joined #openttd
10:18:03 <petern> Hmm, this morning my CI is taking 11 minutes...
13:28:58 *** Alkel_U3 has quit IRC (Quit: maintenance)
13:29:46 *** Alkel_U3 has joined #openttd
13:36:28 *** D-HUND is now known as debdog
14:32:23 <Samu> what happens when a clientid is big enough
14:57:44 <Samu> why isn't template_client.hpp.sq in the source
14:58:08 <Samu> anyway, on that file, on line 15, we have
14:58:17 <Samu> template <> inline int Return<ScriptClient::ClientID>(HSQUIRRELVM vm, ScriptClient::ClientID res) { sq_pushinteger(vm, (int32)res); return 1; }
14:58:41 <Samu> meaning that an enum casted as uint32, is converted to int32
14:59:06 <Samu> 0x80000000 becomes a negative number
14:59:29 <Samu> there are no negative client ids
15:05:40 <Rubidium> realistically I doubt you will be able to join more than two billion times without something crashing
15:08:30 <Rubidium> let's say you are able to join 1 client every second, then you'll still need over 60 years...
15:12:19 <LordAro> Rubidium: you could hack it so that the client id starts with a higher number :p
15:13:37 <Rubidium> and obviously the game is continually pausing. Yes, with some attacks you might increase the client ID faster, but even that's limited
15:15:40 <Samu> this line had no effecthttps://github.com/OpenTTD/OpenTTD/blob/master/src/script/api/script_client.hpp#L27
15:18:22 <dP> without it enum size is undefined
15:19:51 <Samu> i think the bug is in squirrelexport thingy
15:21:08 <Samu> i have no idea how to fix it
15:21:26 <Samu> but in my opinion, it should take the : uint32 into consideration
15:21:39 <Samu> or whatever is after enum xxx :
15:24:38 <Rubidium> true, if you exceed whatever fits in uint32 it fails and for int64 -1 you will get 4294967295 but that's exactly what's expected to happen with casting integers
15:25:58 <Xarick> I got a negative number
15:28:01 <Rubidium> in the end it doesn't matter much. Just pass in 0x11 instead of 0x8 and the numbers won't be the same either
15:30:04 <dP> doesn't that mean uint32 isn't passed correctly to squirrel?
15:30:57 <dP> probably does not matter much for client ids as they're not getting that big but may matter for something else
15:31:48 <dP> oh, lol, new command system still kept the 16 bit client id bug for questions
15:32:31 <dP> that's like the only place in code that actually needed more command bits :p
15:33:20 <LordAro> easier to fix now though :)
15:33:39 <LordAro> ...i assume there's no longer actually any limit
15:34:24 <dP> well, depends on what you consider to be a fix
15:34:57 <dP> sure, you can make it 32 bit or smth but with max clients of 255 it never actually needed to be more than a byte
15:35:31 <dP> it's just that clients are created outside of the command queue that's causing issues
15:36:49 <dP> for example, the game can be processing a command from the client that already left
15:39:23 <Rubidium> dP: I fear it is needed for a client to be able to process a command of a client that already left
15:40:43 <Rubidium> *especially* when joining a game somewhat slowly and your client is still catching up
15:42:57 <Rubidium> though I'm not sure what you mean with the 16 bit client id bug that exists (I can't find any open issue with 16 bit and client)
16:04:36 <Samu> my search for /* Allow enums to be used as Squirrel parameters */ found 34 files
16:05:14 <Samu> let's see if I find issues
16:06:28 <Rubidium> Samu/dP: can you check with #10435? ;)
16:09:42 <Samu> maybe regression can catch something
16:18:45 <Samu> when the enum is undefined
16:20:39 <Samu> looks like it, from my testings
16:21:27 <Samu> some enums are just like enum AirportType {
16:24:53 <Rubidium> Samu: essentially it's undefined, but it's not larger than int unless the value of the enumerators cannot fit in an int
16:29:26 *** HerzogDeXtEr has joined #openttd
16:31:40 <TallTyler> That PR needs some escape characters to avoid using * to make the text bold 😛
16:31:51 <TallTyler> I guess code backticks would work too
16:33:13 <Rubidium> why doesn't it just understand it the way I intended it?
16:41:31 <dP> Rubidium: can't check rn but lgtm
16:52:37 *** gelignite has joined #openttd
16:59:59 <Rubidium> dP: agreed, though another can of worms as changing those might break scripts :(
17:02:41 <Rubidium> though probably only when checking some return values/tiles against -1 or expecting random to be between -2**31 and 2**31-1
17:11:31 <Samu> i have a PR for the squirrel helper
17:16:07 <Rubidium> either I'm not backward/bugward compatible enough, or that PR is way too big
17:17:36 <dP> tbf there could be a better way to do compatibility scripts
17:17:46 <Rubidium> in my option, if you do not fulfill the @pre of a function, why should I then guarantee that the return value remains the same? As long as it's still an invalid value, that should be enough
17:17:57 <dP> most of the stuff goes into all versions anyway
17:22:40 <LordAro> dP: i've thought for a while that you should be able to just chain them all together
17:24:11 <Rubidium> why are Chance and ChanceItem rewritten? Seems pointless as it doesn't use the int64 that gets into the squirrel VM. Similarly RandRange*, if max > 2**31-1, then the function is currently broken. The best the script user could have done is check < 0 and then bitmask themselves, that bit of code won't be used. At worst it ignores it, uses a negative index into an array and boom. Although given no-one
17:24:17 <Rubidium> reported choosing non-existing things means that RandRange* is not used with input values >= 2**31, so adding backward/bugward compatability seems useless to me
17:25:36 <Rubidium> that leaves only Rand and RandItem for which you might want to consider something backwards compatible (at least of script_base)
17:27:45 <Rubidium> the GetMaintenanceCostFactor wrappers seem to be unneeded, as that's uint16 cast to int32 and then to int64, so removing the middleman doesn't change a thing
17:28:46 <Rubidium> having said that, why would ScriptAirport::GetMaintenanceCostFactor return INVALID_TOWN?!? That seems clearly a bug
17:28:59 <Rubidium> probably some sloppy-paste
17:34:32 <LordAro> i imagine no one has ever used the function
17:35:48 <Rubidium> or... scripts always fullfilled the precondition during testing/debugging ;)
17:36:03 <andythenorth[d]> I think for non-zero amount of GS you can assume nobody has ever used the function
17:36:13 <andythenorth[d]> but I am intending to adjust that 😛
17:36:29 <andythenorth[d]> unless TrueBrain has a proposal for replacing GS? 😄
17:42:09 <LordAro> i read about that recently
17:48:34 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
17:50:08 <Samu> ScriptCargoMonitor::GetTownDeliveryAmount, an invalid company can be -1, i wonder if that function is working correctly
17:58:10 <Samu> ScriptCompany::ResolveCompanyID, same question, what will ::Company::IsValidID(company) if company is -1
18:07:23 <Samu> ScriptCompany::SetPrimaryLiveryColour and ScriptCompany::SetSecondaryLiveryColour do not ensure a valid LiveryScheme
18:07:29 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
18:07:51 <Samu> maybe the DoCommand will, didn't check
18:11:29 <Samu> openttd has many enum Colours
18:11:58 *** ChanServ sets mode: +v tokai
18:16:15 <Samu> ewww scriptstorypage is confusing
18:16:45 <Samu> but, i think i can see a way to trigger an assert by using colours outside the allowed range
18:17:10 <Samu> ScriptStoryPage::StoryPageButtonFormatting ScriptStoryPage::MakePushButtonReference
18:18:58 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
18:20:28 <Samu> NUMBER_ALL = 0xFFFFFFFF, ///< Value to select all windows of a class.
18:21:09 <Samu> file script_window.hpp.in
18:21:34 <Samu> if enum is int, then that NUMBER_ALL is -1 i think
18:27:21 <Samu> but with rubidium's fix, it's gonna end up as 4 294 967 295
18:27:30 <Samu> probably, no sure way to test
18:28:02 <Samu> dont know who takes precedence in the conversion
18:28:44 <Samu> maybe I'm wrong, and end up as -1
18:45:37 <DorpsGek> - Update: Translations from eints (by translators)
18:49:31 <Rubidium> Samu: in that case it will be an unsigned int, and it's not returned from the API back to squirrel
18:52:28 <Samu> im trying to find all enums yet, am not done
18:54:09 <LordAro> Samu: any particular reason you keep switching between discord & irc, ooi?
18:54:37 <Samu> i can post images directly, no need to use imgur anymore
18:54:52 <LordAro> but why not just use discord?
18:55:36 <Rubidium> Samu: well... compilers may behave differently, and since int and uint are essentially the same as long as you keep it an enum that's fine. Everything else might get into undefined-ish behaviour
18:56:42 <Rubidium> though for the script API explicitly typing the enums might be useful to prevent different compilers from generating slightly different code/enums
18:58:03 <Rubidium> on the other hand, if is 2**32 in int64 squirrel land and gets converted to int32 or uint32, the end result of the comparison against NUMBER_ALL will still be the same
18:58:22 <Rubidium> and that's essentially all that counts AFAICT
19:10:22 <michi_cc[d]> andythenorth[d]: After you dynamically name all the things 🙂
19:11:24 <Rubidium> Samu: there's only one global Colour enum and an enum in the ScriptCompany class, so there's no conflict
19:12:04 <andythenorth[d]> nml rust port when also? 😛
19:12:34 <Rubidium> I guess you're confused by forward declarations
19:25:48 <andythenorth[d]> ok, so how do I re-init a GS on a savegame? 🙂
19:26:47 <dP> hm, rc2 does weird things when changing resolutions
19:26:59 <dP> also doesn't detect my actual resolution at alll
19:27:58 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
19:28:42 <Rubidium> it can't be much worse than it used to be
19:30:17 <Rubidium> it used to do arguably sillier things like: 22036 x 376383744
19:32:46 <dP> well, they may be slightly more reasonable but now it offers me different resolution choices than it did a few hours ago xD
19:33:31 <Rubidium> oh, that sounds like another issue... pfew
19:34:02 <dP> max is shows now is 1704x1065 and I distincly remember it offering 2000+*smth
19:35:12 <dP> neither is particularly sensible for my 2560x1600
19:35:31 <Rubidium> that's weird; does something like xrandr also give weird values?
19:35:55 <dP> yeah, xrandr gives same nonsense
19:37:36 <Rubidium> "good", then OpenTTD at least doesn't make up the nonsense. No idea how to solve the underlying issue though.
19:39:06 <dP> oh, I know what it may be...
19:40:57 <dP> oh, yeah, I had fractional scaling enabled in ubuntu
19:41:07 <dP> it was messing with resolution for some reason
19:45:00 <dP> what is the actual resolution of the game in that case though
19:45:30 <dP> it doesn'l seem blurred as if it was stretching 1704 into 2560
19:48:11 <dP> if the window is maximised changing resolution only adds black border
19:48:25 <dP> in fullscreen changing resolution does nothing
20:07:01 <andythenorth[d]> hmm re-init GS: round-trip .sav -> .scn -> scenario editor -> .scn -> .sav -> load game?
20:08:06 <osswix> No console command to reapply gs to game?
20:08:51 <Samu> static const GoalTypeID INVALID_GOALTYPE = 0xFFFFFFFF; ///< Invalid/unknown index of GoalType
20:09:05 <Samu> /* Note: these values represent part of the in-game GoalID enum */
20:09:05 <Samu> GOAL_INVALID = ::INVALID_GOALTYPE, ///< An invalid goal id.
20:11:30 <Samu> yeah, i dunno how to make a goal
20:11:35 <Samu> but i wanted to test this
20:12:02 <andythenorth[d]> osswix: not that I am aware of
20:14:35 *** Smedles has quit IRC (Remote host closed the connection)
20:18:46 *** Smedles has joined #openttd
20:19:21 <Xarick> it should become the big value
20:21:47 <Samu> something is wrong, i guess it's the enum
20:24:21 <Samu> typedef uint32 GoalTypeID
20:24:54 <Samu> yeah, the enum should be GoalID : uint32, right?
20:27:24 *** Wormnest has joined #openttd
20:27:49 <Samu> actually GOAL_INVALID is mapping to ::INVALID_GOALTYPE, shouldn't it be ::INVALID_GOAL instead?
20:34:29 <Samu> how many goals can there be?
20:49:47 *** gelignite has quit IRC (Quit: Stay safe!)
20:53:30 <Rubidium> Samu: yes, the enums with 0xFFFFFFFF should probably get a : uint32. But that doesn't solve the issue in Squirrel land yet, as there it'd still be -1
20:59:49 <Rubidium> I know how it got there ;)
21:02:19 <andythenorth[d]> how many free opcodes does GS get on savegame load?
21:02:42 <andythenorth[d]> I did look in src, but I can't figure it out
21:08:50 <andythenorth[d]> "not enough" is the answer
21:09:14 <andythenorth[d]> an init task that takes 0 seconds on map gen
21:09:24 <andythenorth[d]> takes 5 seconds on loading savegame
21:30:04 <nielsm> remember that you, as GS, can force-pause the game in a way the player can't override
21:30:17 <Samu> wow, i missed some uint32's
21:30:21 <Samu> ScriptInfrastructure::GetInfrastructurePieceCount
21:31:03 <andythenorth[d]> hmm where is pause
21:31:16 * andythenorth[d] browses doxygen slowly
21:32:37 <andythenorth[d]> hmm still takes 5 seconds in pause
21:32:47 <andythenorth[d]> what do game ticks do in pause?
21:33:06 <nielsm> "nothing", except force the script to not block the UI thread
21:34:00 <andythenorth[d]> on newgame the tile walk is
21:34:12 <andythenorth[d]> the time is in seconds, realtime in RL
21:34:43 <Rubidium> Samu: do you expect those infrastructure piece counts to ever get at or over 2**31?
21:35:42 <Samu> hmm how many rail pieces on a tile, 6?
21:36:39 <Samu> not even sure if that's how it's counted
21:37:35 <petern> Urgh, I managed to get through map 32 of Eviternity. That was... a thing :/
21:37:55 <petern> 36 rail pieces on a tile? What magic is that?
21:38:13 <Samu> it's how it counts in openttd
21:38:23 <Samu> you place 6 but counts 36
21:39:50 <nielsm> what if you make 6 tiles with one rail piece on each? what if you make two tiles with all six pieces on each?
21:40:00 <petern> Of course, even on a crazy 16kx16k map, you'd need a lot of rail tiles...
21:41:30 <Rubidium> with tunnels and bridges you might be able to get the count per tile up a bit, but you will also lose a lot of tiles at the map boundary
21:42:42 <Rubidium> in any case, in a realistic scenario of filling the whole map you'd be very far from those limits so no need to slow down scripts to fake negative numbers that it might have returned if the numbers were unreasonably high
21:43:57 <Rubidium> and basically you would be making those script buggy by doing that, while the bug would be resolved by the newer version of OpenTTD if only it weren't for someone having written a layer to reintroduce the bug
21:47:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:52:38 <LordAro> does JGR have a 16k version of wentbourne? :p
21:54:57 <Samu> script_news.hpp is funny, it enumerates 7 news types, then it only makes use of 3
21:55:58 <Samu> via preconditions, you are only allowed to create news of 3 types, so why enumerate 7
21:58:58 <TallTyler> andythenorth[d]: What kind of maniac would use real-time in OpenTTD? 😛
21:59:38 <andythenorth[d]> I mean....who would walk the map, copying tiles into a GS table?
22:00:35 <TallTyler> I think figuring out how timetable start dates work might be a tomorrow project 🤔
22:00:59 <JGR> LordAro: I don't do any testing at 16k
22:01:06 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:01:44 <TallTyler> (I plan to upstream automatic vehicle separation after this, so I'm not overly concerned about improving timetabling, just not breaking it)
22:01:45 <JGR> I tend to use saves from the multiplayer servers here as "representative" games for performance testing
22:04:34 <Samu> codeql left a note on my PR
22:04:51 <Samu> Static variable INVALID_GOALTYPE is never read.
22:05:21 <Samu> so, that means it was correct?
22:05:50 <Samu> it only existed for the GS and was even incorrect
22:15:36 <Rubidium> practically INVALID_GOALTYPE can go, but be aware that it's referenced in some documentation
22:17:57 <Rubidium> as far as I can see it makes no sense to ever have INVALID_GOALTYPE there as there is no reasonable path to set it. After all, CmdCreateGoal uses actual type specific ways to check for validity
22:18:08 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:19:03 <Rubidium> oh, and when updating the documentation because INVALID_GOALTYPE goes away, add "story page ID" as that's missing from the comment
22:26:42 <Samu> enum ScriptOrderFlags is too much for me
22:27:01 <Samu> if there is a bug there, I wouldn't even know
22:30:59 <Samu> (OrderConditionVariable)GB(this->dest, 11, 5)
22:31:04 <Samu> how big of a number is this?
22:34:45 <Samu> 7 fits in 5 bits, so it's fine
22:35:35 <Samu> OC_INVALID = -1, this however...
22:35:43 <Samu> oh well, i just hope it's fine
22:36:09 <Samu> "only valid for this API", says the comment
23:06:24 <Samu> ScriptRail::RailTrack could be a byte
23:12:50 <Samu> bed time, cyas goodnight
23:13:00 *** Samu has quit IRC (Quit: Leaving)
23:24:06 *** sla_ro|master has quit IRC ()
continue to next day ⏵
