Times are UTC Toggle Colours
00:37:16 *** Etua has joined #openttd 01:05:11 *** WormnestAndroid has joined #openttd 02:05:46 *** WormnestAndroid has quit IRC 02:05:50 *** WormnestAndroid has joined #openttd 03:21:55 *** Wormnest has quit IRC 03:46:53 *** debdog has joined #openttd 03:50:11 *** D-HUND has quit IRC 04:28:01 *** Etua has quit IRC 04:36:21 *** Flygon has joined #openttd 04:47:44 *** keikoz has joined #openttd 05:39:05 *** Etua has joined #openttd 05:56:46 *** keikoz has quit IRC 06:06:36 *** Etua has quit IRC 06:16:17 *** KiriDore has joined #openttd 06:17:37 *** KiriDore_ has quit IRC 07:14:21 *** MasterOktagon has joined #openttd 07:14:22 <MasterOktagon> I dont know if this is the right place to ask, but can someone make an nml/openttd variable "rail_continuation" for rails (just like in stations)? This would allow me to make smooth curves (graphically). 07:23:06 *** sla_ro|master has joined #openttd 07:24:04 <Brickblock1> How would it allow you to do that? that variable can only detect if there is a rail there not which direction it has. 07:25:01 <Brickblock1> smooth curves would also look very weird when the trains go around the corner 08:59:22 <MasterOktagon> Yeah but could make calls to more than one tile to check the curvature. And there are some trainsets having extra rotations (PKP set and timberwolfs trains) 09:03:26 <MasterOktagon> And i dont mean rail_present but rail_continuation 09:05:07 <MasterOktagon> https://cdn.discordapp.com/attachments/1008473233844097104/1070630937991315456/sjsnsk.png 09:05:07 <MasterOktagon> (mad paining skills) if you check two tiles you should be able to look if there is a rail link between them 09:12:07 <petern> That looks like more than 2 tiles to me. 09:22:14 <MasterOktagon> One color for each direction (1/2 checks) 09:27:01 <Brickblock1> I think that changing graphics on every rail type would be very demanding and therefore might not be a good idea 09:31:02 <MasterOktagon> Do you mean demanding computer reaources or worktime? 09:32:19 <Brickblock1> yes 09:32:54 <Brickblock1> having to check every tile does seam impractical 09:33:40 <MasterOktagon> but I want to try it anyway 09:34:14 <Brickblock1> make a patch 09:35:12 *** gelignite has joined #openttd 09:35:51 <MasterOktagon> well, I guess I have to if I want that. The problem is that I have to look at the code a bit further (how the classes are named, where everything is and so on). 09:36:38 <osswix> MasterOktagon: This would be cooler for smooth road curves if we can make cars turn like that 09:38:04 <osswix> iirc smoother roads are a rough thing in the game, at least I've heard of people wanting diagonal ones for a long time, and that isn't a thing yet either (functional ones). I wonder if it is impossible? 09:41:04 <MasterOktagon> this should be more easy than my thing, I think. You "only" have to change the animation for the turns (directly diagonal instead of first a bit straight) and recalculate the brake speed. And of course the sprites for turns have to be diagonal 09:42:55 <MasterOktagon> and ui changes 09:44:00 <MasterOktagon> But you have to rework all newgrf road curve graphics 09:46:10 <osswix> Could have it as a setting, i assume it would only be doable as patch. 09:46:20 <osswix> If 09:48:37 <MasterOktagon> I think that's a good idea. I'll have a look at it. 09:57:56 <osswix> I wonder if we could improve the town growth walker. I especially would love one that can build 2/3 tiles away from the road as well 09:59:24 <osswix> I should hey back into programming, surprised myself how well i could read the newgrf code merging two game scripts (p&t and rvg) while rubber duckying to Erato. 10:44:06 <petern> There's more interesting things that could be done to road and rail tiles, but you then have to ask yourself "is this still TTD".... 10:46:39 <osswix> Personally, I'd find diagonal roads or wider 90 degree corners for roads much more openttd than those weird 32 bit or something extra zoom packs. 10:59:14 <petern> Yeah I have "thoughts". I'd like to say plans but it's nothing as concrete as that... 11:13:21 <FLHerne> Brickblock1: smooth cornering vehicles can be done by grf already, with some hacks 11:13:49 *** Samu has joined #openttd 11:13:51 <Brickblock1> Yes but most aren't and most likely won't be 11:15:10 <FLHerne> so use the grfs that look good together :p 12:11:33 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322#issuecomment-1413640236 12:41:24 <DorpsGek> [OpenTTD/OpenTTD] FLHerne commented on pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322#issuecomment-1413683535 13:13:20 *** Yozora has joined #openttd 13:13:20 <Yozora> It would be great if zoom level effected sound effects volume 13:16:54 <TallTyler> Yes, someone just needs to make that change 13:17:26 <TallTyler> It probably wouldn’t be very hard, I just haven’t looked to see how volume is controlled 13:54:56 <pickpacket> ... what? Why? 🤔 14:15:07 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #10407: [Crash]: GS trying to get available railtypes of an invalid company https://github.com/OpenTTD/OpenTTD/issues/10407 14:15:34 <TallTyler> pickpacket: https://github.com/OpenTTD/OpenTTD/issues/8957 14:16:19 <TallTyler> Essentially, you hear sounds for whatever is visible in the window, so the more zoomed out you are, the louder the game becomes. Reducing volume when zoomed out is the most obvious way to solve that 14:16:49 <TallTyler> Try turning on ambient sounds and zooming out in a subtropic game -- the rainforest sounds are so loud and annoying 14:16:52 <LordAro> except that volume doesn't necessarily scale linearly 14:17:04 <LordAro> perceived volume, that is 14:17:30 <TallTyler> Inverse square law? 14:17:32 <TallTyler> Like light? 14:17:36 <LordAro> something like that 14:18:01 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10373: Allow Scripts to convert returned uint32 values to int64 https://github.com/OpenTTD/OpenTTD/pull/10373 14:24:46 *** gelignite has quit IRC 14:27:59 <petern> Yozora: It does 14:32:29 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322#issuecomment-1413838046 14:33:18 <petern> TallTyler: <https://github.com/OpenTTD/OpenTTD/issues/8957> 14:33:39 <LordAro> deja vu 14:33:50 <petern> Meh, didn't see that 😄 14:34:02 <petern> But yes. It is scaled, just people want it scaled more. 14:34:06 <petern> Well, Zorg does ;D 14:34:34 <petern> <back to real work> 14:41:55 <TallTyler> Oh, missed your note that it is already scaled, just not strongly 14:44:37 <petern> Yes, basically there are more zoom levels now, and most people are not playing at 640x480, so there are more things on screen. 14:45:05 <petern> Scale by viewport size? hehe 14:45:45 <LordAro> maybe only play sounds from a 640x480 box in the centre of the window :p 14:47:41 <petern> 😄 14:49:59 <LordAro> actually, why not? 14:50:16 <LordAro> maybe reduce everything outside that to 10% or something 14:51:34 <Yozora> The thing is, after there are 3 trains and 3 busses it starts to sound like polyphony 14:54:14 <Yozora> I'm speaking for myself, but I find impossible playing with vehicles/ambient sounds after 2x zoom in 14:57:21 <petern> With running sounds from older sets it's all beautiful 😄 14:59:33 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick dismissed a review for pull request #10386: Fix: Some Script::IsValidVehicle checks need to be complemented with IsPrimaryVehicle https://github.com/OpenTTD/OpenTTD/pull/10386#pullrequestreview-1276010671 14:59:36 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10386: Fix: Some Script::IsValidVehicle checks need to be complemented with IsPrimaryVehicle https://github.com/OpenTTD/OpenTTD/pull/10386 15:16:42 *** Wormnest has joined #openttd 15:30:00 <supermop_toil> yo 15:45:38 <Pruple> yoyo 16:26:35 *** keikoz has joined #openttd 16:58:28 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322 16:59:45 <Samu> I'm not too happy with https://github.com/OpenTTD/OpenTTD/pull/10373/commits/277b457515e191ffb0d2e8b2e96e1777e247dd1c 17:00:10 <Samu> invalid brigde being 13, that number is way too random 17:00:33 <Samu> ideally it would still return -1, but I don't know how to make that happen 17:05:55 <LordAro> Samu: it was more correct before 17:06:04 <LordAro> especially if we ever want to add newgrf bridges properly 17:11:19 <Samu> i have an idea, but it's gonna touch many places with BridgeID 17:25:15 *** HerzogDeXtEr has joined #openttd 17:29:46 <glx[d]> and all this PR started because printing Random() may display a negative value 🙂 17:31:34 <glx[d]> as I already said, uint32 and int32 are exactly the same values internally, it's just the interpretation 17:32:27 <Samu> ^_^ 17:36:43 <glx[d]> "ScriptTown::GetCargoGoal returns -1 for invalid towns or invalid town effects instead of UINT32_MAX" <-- BTW (uint32)-1 is UINT32_MAX 17:47:37 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322 17:47:38 <Rubidium> well, there is a bit of a bug though... squirrel uses int64 so calling AIBase::RandRange(3_000_000_000) might yield something like -2_000_000_000 instead of 2_294_967_296. If my script uses that result to index something, well... your script breaks when it's actually RandRange that does not return a value in the specified range. So that's definitely unexpected behaviour, even though passing that 17:47:45 <Rubidium> negative number to an API function with uint32 will return it to the right value there. That's not the case in SquirrelLand 17:48:09 <LordAro> yeah, there's definitely bugs 17:48:16 <LordAro> but Samu's solution is not 17:50:14 <glx[d]> RandRange() should check the parameter range indeed 17:51:13 <glx[d]> but Rand() is fine if the documentation is fixed to not say "A random value between 0 and MAX(uint32). " but "32 random bits" 17:52:04 <TrueBrain> hihi, you worked too much with NML / NewGRF 😛 17:52:07 <TrueBrain> I like how you think 😄 17:53:42 <glx[d]> that's the usual way to use Random() in openttd, pick bits from the return value 17:54:26 <glx[d]> and if the number itself matters we use RandomRange() or Chance() 18:03:46 <glx[d]> hmm but with AIBase::RandRange(3_000_000_000) the openttd side of the API won't receive this value, it will be (uint32)3_000_000_000 and the result will still be between 0 and something 18:11:44 *** royills[m] has joined #openttd 18:11:55 *** tokai has joined #openttd 18:11:55 *** ChanServ sets mode: +v tokai 18:13:03 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10373: Allow Scripts to convert returned uint32 values to int64 https://github.com/OpenTTD/OpenTTD/pull/10373 18:13:14 <Samu> BridgeID stuff "fixed" 18:13:19 <Samu> now returns -1 again 18:14:00 <Samu> https://github.com/OpenTTD/OpenTTD/pull/10373/commits/71184ddef56b9122ea56d180711c9802c8a0aa4d 18:14:18 <Samu> need to edit pr message 18:15:46 <Samu> no compatibility required, since it returns -1 again, description needs fixing 18:17:48 <andythenorth[d]> petern: And you may ask yourself, “How do I work this?” 18:17:48 <andythenorth[d]> And you may ask yourself, “Where is that large automobile?” 18:18:54 *** Flygon has quit IRC 18:18:56 *** tokai|noir has quit IRC 18:19:46 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322 18:20:41 <Samu> I'm still bad at describing, but description is updated 18:20:45 <TallTyler> All references to "days" in economy things are now changed to seconds 18:20:46 <Samu> :) 18:21:01 <TallTyler> Next up, changing years... 18:25:15 <TallTyler> "Months" -> "minutes" has already been done too 18:26:37 <DorpsGek> [OpenTTD/OpenTTD] FLHerne commented on pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322#issuecomment-1414181270 18:31:16 <glx[d]> nice I wanted to test something with <https://github.com/OpenTTD/OpenTTD/compare/master...glx22:OpenTTD:temp> and I get a crash when generating the map 18:32:01 <LordAro> well that doesn't seem right 18:33:30 <glx[d]> yup 0xFFFFFFFF seems to be a valid Random() result 18:37:03 <andythenorth[d]> are there 365 seconds in a month? 18:37:12 <andythenorth[d]> or 52 minutes in the year? 🙂 18:39:27 <glx[d]> haha and with 0x7FFFFFFF I trigger an infinite loop 18:42:41 <Samu> what are the odds 18:43:30 <LordAro> Samu: approximately 1 in 0x7FFFFFFF 18:45:03 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/e41af1f2bb78c121f58aa70e157499ff34ff5190 18:45:04 <DorpsGek> - Update: Translations from eints (by translators) 18:47:27 <TonyPixel> Can somebody supply me a DOS palette for the game? 18:47:44 <TonyPixel> Any format goes, but preferably .act 18:47:44 <TallTyler> andythenorth[d]: No, that’s the tricky part. One day is 2 seconds, one month (economy months all have 30 days) is 1 minute, and one year is 12 minutes. Months->minutes is an easy string change, the others have unit conversions 18:47:50 <glx[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1070777583551119520/image.png 18:47:50 <glx[d]> anyway I just wanted to force RandRange return to be max - 1 18:49:15 *** nielsm has joined #openttd 18:53:11 <andythenorth[d]> TallTyler: will you be accounting for planets that have different orbits etc? 18:53:17 <andythenorth[d]> so different conversion factors? 18:53:26 * andythenorth[d] super unhelpful in the guise of lolz :P 18:56:46 <andythenorth[d]> ok let's see what's on reddit today 18:56:57 <andythenorth[d]> nice airport 18:57:51 <andythenorth[d]> a really odd bug with (vehicle?) window 18:58:15 <LordAro> android bug until proved otherwise 18:58:18 <dP> andythenorth[d]: on android 18:59:31 <andythenorth[d]> and some snails 18:59:34 <andythenorth[d]> ok reddit 19:23:43 *** Wolf01 has joined #openttd 19:24:56 *** gelignite has joined #openttd 19:41:42 <TallTyler> NUTS snails, I think 19:42:02 <TallTyler> Or whatever the accompanying ground set to YETI was called 19:42:08 <TallTyler> BRIX? 19:47:02 <dP> rawr 19:49:40 <andythenorth[d]> genuine good reddit day 19:49:48 <andythenorth[d]> enjoyed 20:07:08 <andythenorth[d]> TonyPixel: did you find a palette? 20:08:04 <TonyPixel> Yes 20:08:22 *** HerzogDeXtEr has quit IRC 20:09:28 <andythenorth[d]> \o/ 20:38:49 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322 20:42:44 <TallTyler> Just subsidies, graphs, and then AI/GS and NewGRF API additions to go! 20:56:03 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10411: Expose more functions to game scripts https://github.com/OpenTTD/OpenTTD/pull/10411 21:00:29 <glx[d]> I think something like https://github.com/OpenTTD/OpenTTD/compare/master...glx22:OpenTTD:temp is a cleaner solution 21:02:21 <glx[d]> (regarding script random issues) 21:05:26 <glx[d]> globally casting uint32 to int64 touches too many stuff, doing it only when really needed feels better 21:06:15 <glx[d]> in most case uint32 to int32 global cast is correct 21:09:39 <TrueBrain> Clean, to the point, isolated .. always nice if you can solve problems like that 21:21:55 <LordAro> that is much nicer 21:25:49 *** Xarick has quit IRC 21:26:52 <Rubidium> I wondering why an API that says it returns a uint32 is correctly implemented when it returns it as an int32. Shouldn't the API then return int32 itself, instead of marking it as uint32? 21:30:17 <glx[d]> main issue is squirrel working only with int 21:30:40 <Rubidium> I'm basically saying, if removing the cast to int32 in the helper has an unwanted side effect, shouldn't the API be amended to return int32 itself instead? 21:31:49 <Rubidium> on the other hand, maybe everything should be SQInteger as input and output of the script APIs, though that might require a lot of similar EnforcePreconditions to be added 21:33:24 <glx[d]> I think in many cases the cast to int32 is to handle the 0xFFFFFFFF (typical invalid value in enums) values as -1 21:39:29 <Rubidium> but why do that for unsigned 32 bit ints, but not for 16 and 8 bit ints? VehicleType, CargoType, RailType (all 255), StationID, TownID, EngineID (all 65535), but then TileIndex gets -1 21:44:40 *** Wormnest has quit IRC 21:55:43 *** keikoz has quit IRC 22:07:08 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10322: Feature: Change speed of calendar progress https://github.com/OpenTTD/OpenTTD/pull/10322 22:09:22 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #10443: Fix: [Script] ScriptBase::Rand() return value was between -MIN(int32) and MAX(int32) https://github.com/OpenTTD/OpenTTD/pull/10443 22:09:27 *** Wormnest has joined #openttd 22:11:37 <glx[d]> I agree with rubidium, I think all script functions should use SQInteger only and handle conversions from/to openttd internals themselves 22:12:49 *** gelignite has quit IRC 22:12:59 <andythenorth[d]> would it be lolz to add alternatives to Squirrel 😛 22:13:06 <andythenorth[d]> we could even have a transpiler 😛 22:13:15 <LordAro> yes 22:13:15 <andythenorth[d]> GS, but in Rust 😛 22:13:24 <andythenorth[d]> what would be the most lolz? 22:13:24 *** reldred has joined #openttd 22:13:24 <reldred> GS in powershell 22:13:25 <andythenorth[d]> perl? 22:13:32 <reldred> nah powershell 22:13:36 <glx[d]> lisp 22:13:37 <reldred> just to upset people 22:23:36 *** nielsm has quit IRC 22:23:37 <Eddi|zuHause> php? 22:26:31 *** Wolf01 has quit IRC 22:30:06 *** sla_ro|master has quit IRC 22:35:48 *** Samu has quit IRC 22:35:50 <andythenorth[d]> I thought php was good now? 22:36:00 <andythenorth[d]> flash actionscript? 22:36:54 <dP> Malbolge 22:41:26 <andythenorth[d]> we could keep the script API method names, but change the implementation? 22:41:45 <andythenorth[d]> how about a bytecode language? 😛 22:45:11 <glx[d]> like squirrel ? 22:45:42 <andythenorth[d]> I was thinking of nfo 22:45:44 <andythenorth[d]> for lolz 23:01:43 *** Wormnest has quit IRC 23:25:08 *** Wormnest has joined #openttd 23:29:45 *** bryjen has joined #openttd