IRC logs for #openttd on OFTC at 2025-01-16
⏴ go to previous day
03:05:05 *** Wormnest has quit IRC (Quit: Leaving)
03:34:25 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:55:34 *** gnu_jj_ has joined #openttd
03:58:59 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:41:58 <DorpsGek> - Update: Translations from eints (by translators)
06:08:02 *** goingsolo has joined #openttd
06:08:02 <goingsolo> os there way changing how the stones look on gfx+?
06:11:36 *** D-HUND is now known as debdog
07:05:43 *** keikoz has quit IRC (Ping timeout: 480 seconds)
08:30:59 <andythenorth> still confused 😛
08:31:11 <andythenorth> just give the cab cars power
08:31:16 <andythenorth> then they can go at the front
08:33:44 <reldred> that's why I like zeph's proposal
08:33:57 <reldred> if a grf author doesn't care, they don't have to
08:34:03 <reldred> if a player doesn't care, they don't have to
08:34:19 <andythenorth> I haven't read frosch's patch to see if it introduces Consist or not
08:34:25 <reldred> defaults that 'just work', lots of extra fluff in there for grf authors who want to go down the rabbithole or not
08:34:41 <andythenorth> I'm quite -1 to everything I've read in English words, but I haven't read the C++
08:35:13 <reldred> given we're not talking about shunting I think it's just take the whole train and flip the order of all the carriages.
09:11:06 *** APTX_ has quit IRC (Remote host closed the connection)
09:24:03 <frosch123> Reordering the vehicles is a terrible idea. It will end up with trains, which are invalid for wagon-attach or start-stop callback. And it complicates things referencing the train via the front vehicle Id. That's why both my old patch and felix's do not touch the depot vehicle order, and instead add a separate driving order
09:27:10 *** mindlesstux has joined #openttd
09:36:13 <kuhnovic> This is turning into one of those it-looks-so-easy-on-paper features 😛
09:51:03 <peter1138> It's one of those "but it's so simple why haven't they done it" along with "i want all these restrictions and changes that others might not" jobs.
09:54:22 <peter1138> Meanwhile the Goddess of technical tech rears her head on both sides.
09:59:53 *** SigHunter has joined #openttd
10:15:48 <johnfranklin> This needs the game to read start_stop and wagon_attach information on non-leading engines, yes.
10:17:09 <johnfranklin> Which could be a good thing for China Set (we have such non-solvable issues), but a disaster for JP+ MU (no strange loco+kiha consist as seen in Japan now)
10:30:36 <pickpacket> johnfranklin: I don't know enough about the code to understand this. How does it help the china set, and how does it break the japan set?
10:38:18 <xarick> what is a `IterateCurvedCircularTileArea`
10:38:45 <xarick> why making lake needs sin and cos
10:41:50 <xarick> what is _current_estuary used for?
10:43:54 <peter1138> Generally, it's like Las Vegas. What happens in JGRPP stays in JGRPP.
10:48:25 *** emperorjake has joined #openttd
10:48:25 <emperorjake> pickpacket: Only the leading engine gets to control what is allowed to attach behind it. This means you can bypass coupling restrictions in NewGRFs by placing a non-restrictive engine infront of the restrictive one. If any such change were to happen, we could fix the JP+ code easily; but using the invisible leading engine to combine otherwise incompatible trainsets would become impossible.
10:50:45 <pickpacket> emperorjake: why would trainsets be incompatible? Meant to simulate different track widths?
10:52:11 <xarick> rivermakewider in jgrpp seems ... different
10:52:29 <xarick> i don't see any terraform
10:52:38 <xarick> unless it's hidden in some other file source
10:52:50 <emperorjake> pickpacket: Some trainsets have somewhat arbitrary coupling restrictions, e.g. they don't allow passenger engines to pull freight or they only allow attaching wagons from the same set. Korean Trainset is one of the worst offenders, I wanted to use Korean locomotives with Iron Horse wagons and it wouldn't let me so I had to use the invisible leading engine.
10:54:13 <peter1138> I don't really get why changing the driving order while maintaining the normal vehicle ordering would break anything.
10:55:13 <pickpacket> peter1138: by "driving order" do you mean direction?
10:55:21 <pickpacket> ie forward or reverse
10:57:11 <emperorjake> Regarding the push-pull thing; I think adding new settings shouldn't be necessary, all we need is a flag for wagons that allows the train to be driven from that end. Then a train can go backwards if the last vehicle is either an engine or a wagon with the flag. Stuff like allowing all trains to reverse or adding an order for when to reverse should be a separate PR, imo
10:58:39 <pickpacket> LordAro: yeeeessss
10:59:44 <_glx_> The first step will still be full decoupling of consist properties from train head
11:00:32 <emperorjake> Tilting trains have been possible for a long time, there are a few GRFs that use the curve variable to provide actual tilted sprites (old NARS, Serbian set)
11:00:54 <peter1138> `const Consist &consist = v->GetConsist();`
11:01:06 <peter1138> Hmm, I seem to have a branch for that. Not JUST a stash.
11:01:17 <peter1138> But I also know someone else did it years ago.
11:03:22 <_glx_> Then some kind of iteration of train parts from begin or from end when drawing
11:09:56 <peter1138> That's... not really how drawing them works :-)
11:16:51 <_jgr_> xarick: This is so that lakes can be rotated ellipses instead of rectangles. This generally looks better for larger lakes.
11:20:42 <_jgr_> xarick: This is so that desert removal is circular instead of rectangular, because this also looks better
11:22:39 <xarick> where is IterateCurvedCircularTileArea defined?
11:23:12 <LordAro> i feel like you should have the capability of searching for something with a specific name
11:26:54 <xarick> does it look kinda like...
11:27:04 <xarick> sec, let me find my own stuff
11:52:59 <xarick> testing IterateCurvedCircularTileArea live
13:25:46 <kuhnovic> Are we going to have this discussion all over again?
13:26:22 <pickpacket> kuhnovic: all discussions must be reiterated, regurgitated, revisited
13:26:38 <pickpacket> lest we forget the horrors!
13:26:52 <pickpacket> (I don't actually know which discussion you're referring to)
13:27:30 <xarick> sorry, I stumbled upon jgr
13:31:14 <xarick> I am disappointed in jgr 😛
13:38:41 *** benjaminv has quit IRC (Ping timeout: 480 seconds)
13:49:53 *** jinks has quit IRC (Remote host closed the connection)
13:49:53 *** jinks_ is now known as jinks
14:10:05 <peter1138> The branch I did was actually about reducing the size of vehicle objects by putting all the stuff that only appears in the lead engine in separate struct. Storage of that is via a unique_ptr (so it can be moved easily enough) but doesn't have a separate ID.
14:10:15 <peter1138> But it's a possible stepping stone to whatever.
14:14:29 *** nielsm has quit IRC (Ping timeout: 480 seconds)
14:32:09 <_jgr_> xarick: If by ordering you mean the spiral behaviour, that is not something of any use to me, so I did not implement it
14:45:28 <peter1138> So now there's 3 partial implementations?
14:50:29 <johnfranklin> pickpacket: We let players to consist somehow arbitary length of multiple units (i.e. by purchasing heads and MU cars individually). Some multiple units require a head car both on the head and the tail. And current problem is, the tail one cannot know if it is really on the tail, due to no can_attach_wagon nor start_stop check.
14:51:18 <johnfranklin> And no double_headed - they are all articulated with length 12
14:54:06 <johnfranklin> So we have to have this
14:55:25 <_glx_> That reminds me of "MORE" in dbset
14:55:56 <emperorjake> Why not just use position_in_consist_from_end to detect if it's on the end?
14:56:41 <johnfranklin> hmm, there are other reasons
15:00:39 *** akimoto has joined #openttd
15:00:48 <johnfranklin> emperorjake: hmm, seems this can be used
15:02:20 <peter1138> Authors come up with weird ways to get stuck.
15:02:41 <johnfranklin> Oh, it is because the tail one is optional
15:04:52 <johnfranklin> But anyway, it can still be used
15:04:52 <johnfranklin> Currently we use bitmask(0) to indicate "wrong consist" to influence start_stop
15:05:45 <peter1138> `bitmask(0)` just means `1`
15:15:07 *** akimoto has quit IRC (Remote host closed the connection)
15:16:04 <johnfranklin> we have already had this
15:16:59 <johnfranklin> And the "ERROR" wagon is now just a reminder for unable-to-start consists
15:18:45 <johnfranklin> well, seems a lot of historical problems...
15:22:07 <johnfranklin> XOR is a thing in NML? 😮
15:23:27 <peter1138> The GRF spec has it.
15:26:44 *** Wormnest has joined #openttd
15:31:04 *** kuka_lie has joined #openttd
15:36:45 *** Flygon has quit IRC (Read error: Connection reset by peer)
15:57:29 <xarick> multimap becomes kinda big 😦
15:59:26 <peter1138> You sure pick... choices.
16:01:32 <peter1138> You could just scan the map, skipping tiles that can't be the height you want.
16:06:09 <xarick> I'm unimpressed with the results 😦
16:08:12 <xarick> about 1 GB for the multimap 😦 why so inneficient
16:09:39 <peter1138> Because you're storing the index of every tile in it.
16:16:32 <xarick> that erase(it) is slowing this down too much 😐
16:17:05 <peter1138> Nothing to do with building a 1GB map of tile indexes.
16:25:18 <xarick> looks like i need a different approach
16:25:29 <xarick> i expected more rivers
17:02:19 *** k-man has quit IRC (Ping timeout: 480 seconds)
17:17:26 <xarick> hmm, findspring isn't that expensive
17:32:34 *** aquila3129 has joined #openttd
17:34:14 *** bohaska has joined #openttd
17:35:36 *** ladylex has joined #openttd
17:35:36 <ladylex> probably, earlier a friend of mine send a message saying that discord email got hacked and user was receiving emails to get hacked by that, but idk if is true
17:35:52 <bohaska> they have a message history here
17:36:02 <bohaska> 280 messages befoe that
17:36:45 *** olionkey has joined #openttd
17:36:45 <olionkey> Yea compromised account
17:36:55 <olionkey> We just kick them and letting them know compromised account
17:37:14 <olionkey> They get sent a message from what server and the reason
17:37:28 <olionkey> If they ever get account back
17:41:46 <peter1138> Urgh. SQL query that works in test but completely blows up with (test) production data...
17:43:06 <Rubidium> oh... the fun of the query optimizer messing up? :(
17:45:14 <peter1138> No, just combinatorial fun with multiple joins.
17:45:33 <peter1138> What is ~ 10 rows in the test data became 180,000.
17:46:02 <peter1138> Just throw a few DISTINCTs in there ;-)
17:46:10 <peter1138> (I did not, in fact, do that.)
17:49:45 <Rubidium> just let Bobby in ;)
18:08:05 <xarick> there aren't many available springs compared to number of tiles in map
18:08:40 <xarick> i brute forced FindSpring on the entire map
18:11:27 <xarick> histogram = { size=24513 } available springs out of 4096*4096 tiles
18:13:11 <peter1138> 4kx4k just isn't interesting to me.
18:13:22 <peter1138> (Not without a TGP-replacement)
18:13:22 <xarick> ok, let me try 512x512
18:14:05 <xarick> histogram = { size=357 }
18:15:41 <peter1138> Proportionally that is "about the same"
18:16:50 <DorpsGek> LordAro: 734.296918767507
18:17:06 <LordAro> @calc 4096*4096 / 24513
18:17:06 <DorpsGek> LordAro: 684.4211642801779
18:21:05 <xarick> best proportion i got was 2500 something
18:23:41 <xarick> smooth setting yields 2700
18:25:02 <xarick> the rougher the terrain, the more spring points, but that doens't necessarily mean more rivers
18:27:15 <peter1138> Pick a random tile and MAKE it suitable for a spring...
18:32:08 <xarick> sub-tropical excluse like 50% of the map due to desert
18:47:23 *** tokai|noir has joined #openttd
18:47:23 *** ChanServ sets mode: +v tokai|noir
18:47:23 <xarick> interesting, it can run out of springs
18:51:54 *** wensimehrp has joined #openttd
18:54:23 *** tokai has quit IRC (Ping timeout: 480 seconds)
19:00:00 <xarick> collecting all springs first at the bottom vs master at the top
19:35:00 <peter1138> "But it used to work"
20:08:31 <truebrain> Be like Windows, binary patch broken stuff for backwards compatibility! 😄
20:23:31 <peter1138> How dare ths line go 1 character past 132 characters.
20:27:12 <peter1138> I broke the NML CI I guess.
20:28:20 <truebrain> are you playing a bad boy? 😛
20:29:04 <peter1138> > fatal: No tags can describe '300c852dd465c3dd34e4f7419f029c26b6af195f'.
20:30:49 <peter1138> Well, I should update regression results but that message is weird.
20:33:20 <peter1138> Oh I see. Wrong repo, yes.
20:33:47 <peter1138> I should make my remote names consistent.
20:35:30 <truebrain> okay, using the arm64 runners means testing builds go from 3m30s to 1m30s
20:35:35 <truebrain> running code natively is faster; weird
20:35:57 <peter1138> Still stuck on the best way to self-describe property sizes.
20:36:25 <truebrain> only a lot of "unexpected error" shows up on the arm64 runners .. but it just continues fine
20:36:30 <truebrain> so not really an "error"
20:49:03 <peter1138> Hmm, does FIRS still works...
20:53:12 <peter1138> Do I assume Action 6 offsets again?
20:58:05 <xarick> I removed the `tries` variable, now that I'm certain of all spring locations
21:00:08 <peter1138> Can we re-implement action 6 in a way that doesn't require overwriting the actions...
21:00:49 *** kuka_lie has quit IRC (Quit: Lost terminal)
21:01:33 <peter1138> Self-modifying code is a mad thing to have implemented.
21:03:11 <xarick> 15.7 seconds down to 3.7 seconds
21:03:39 <xarick> I had no idea those tries were costing so much
21:05:08 <michi_cc> That's why god gave us profilers.
21:07:47 <Rubidium> peter1138: can't you just remove action6 from GRFv9?
21:09:55 <_jgr_> To be replaced with what?
21:15:17 <peter1138> Okay, FIRS works again.
21:15:27 <peter1138> Little bit carried away with byte to word :p
21:25:38 <peter1138> Oh right, didn't update regression again. Sigh.
21:26:35 <xarick> I need to make this a standalone PR, it's so worth it
21:27:45 <xarick> well, Optimizise CreateRivers still not merged, cool
22:06:39 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:07:48 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:10:09 <_glx_> 14 is mostly a kind of xml/ini/...
22:10:17 <peter1138> I'm fixing it first.
22:27:38 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:43:17 <peter1138> Sometimes the `id` is used as a value, for GRFParameters. This is annoying but nothing I can do about that...
22:56:36 <xarick> getting bad results for flat maps 😦
22:57:46 <_glx_> flat maps with all tiles at same height ?
22:59:31 <xarick> oh, Very Flat actually
23:01:13 <xarick> I see nothing abnormal
23:06:29 <xarick> must count number of river tiles, something's strange
23:09:08 <xarick> seems that master does have more rivers indeed
23:23:00 <xarick> guess I underestimated the importance of `tries`
23:25:34 <peter1138> But it's so much faster when you only have to create... less rivers.
23:25:43 <xarick> must think what I can do.
23:26:19 <xarick> there is the issue with starting with long rivers first
23:27:02 <xarick> it can dry the number of springs, then it wouldn't even create short rivers if it happens
23:27:16 <xarick> I thought of solving that with doing 1 long every 10
23:29:10 <xarick> I need to allocate something like 10% of the available springs for long rivers and the other 90% for the short rivers
continue to next day ⏵
