IRC logs for #openttd on OFTC at 2023-02-02
⏴ go to previous day
01:05:11 *** WormnestAndroid has joined #openttd
02:05:46 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:05:49 *** WormnestAndroid has joined #openttd
03:21:55 *** Wormnest has quit IRC (Quit: Leaving)
03:50:11 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:28:01 *** Etua has quit IRC (Ping timeout: 480 seconds)
05:56:46 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:06:36 *** Etua has quit IRC (Ping timeout: 480 seconds)
06:16:17 *** KiriDore has joined #openttd
06:17:37 *** KiriDore_ has quit IRC (Ping timeout: 480 seconds)
07:14:21 *** MasterOktagon has joined #openttd
07:14:21 <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> (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:54 <Brickblock1> having to check every tile does seam impractical
09:33:40 <MasterOktagon> but I want to try it anyway
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: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: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: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
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
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:24:46 *** gelignite has quit IRC (Quit: Stay safe!)
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: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: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 😄
15:16:42 *** Wormnest has joined #openttd
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: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: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 *** ChanServ sets mode: +v tokai
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 (Quit: A toaster's basically a soldering iron designed to toast bread)
18:18:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
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:21:01 <TallTyler> Next up, changing years...
18:25:15 <TallTyler> "Months" -> "minutes" has already been done too
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:43:30 <LordAro> Samu: approximately 1 in 0x7FFFFFFF
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]> anyway I just wanted to force RandRange return to be max - 1
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: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
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:49:40 <andythenorth[d]> genuine good reddit day
20:07:08 <andythenorth[d]> TonyPixel: did you find a palette?
20:08:22 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:42:44 <TallTyler> Just subsidies, graphs, and then AI/GS and NewGRF API additions to go!
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:25:49 *** Xarick has quit IRC (Quit: User went offline on Discord a while ago)
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 (Ping timeout: 480 seconds)
21:55:43 *** keikoz has quit IRC (Ping timeout: 480 seconds)
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 (Quit: Stay safe!)
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 <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:23:36 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:26:31 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:30:06 *** sla_ro|master has quit IRC ()
22:35:48 *** Samu has quit IRC (Quit: Leaving)
22:35:50 <andythenorth[d]> I thought php was good now?
22:36:00 <andythenorth[d]> flash actionscript?
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:42 <andythenorth[d]> I was thinking of nfo
23:01:43 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:25:08 *** Wormnest has joined #openttd
continue to next day ⏵
