IRC logs for #openttd on OFTC at 2025-11-25
⏴ go to previous day
00:00:00 *** kuka_lie has quit IRC (Quit: Lost terminal)
00:59:35 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
00:59:36 *** WormnestAndroid has joined #openttd
00:59:38 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:00:50 *** WormnestAndroid has joined #openttd
02:46:34 *** Wormnest has quit IRC (Quit: Leaving)
03:43:37 *** gnu_jj_ has joined #openttd
03:46:55 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:11:54 *** Zathras_4 has joined #openttd
04:15:15 *** Zathras_1 has quit IRC (Ping timeout: 480 seconds)
04:41:43 <DorpsGek> - Update: Translations from eints (by translators)
05:34:45 *** keikoz has quit IRC (Read error: Connection reset by peer)
06:41:04 *** ChanServ sets mode: +v tokai
06:47:50 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
09:03:48 *** Zathras_4 has quit IRC (Quit: Connection reset by beer!)
09:22:26 *** lobster has joined #openttd
09:22:26 *** lobstarooo has quit IRC (Read error: Connection reset by peer)
09:43:06 *** lobstarooo has joined #openttd
09:43:06 *** lobster has quit IRC (Read error: Connection reset by peer)
09:58:08 *** lobster has joined #openttd
09:58:08 *** lobstarooo has quit IRC (Read error: Connection reset by peer)
10:14:38 *** rightnut has quit IRC (Read error: Connection reset by peer)
10:14:39 *** izhirahider has quit IRC (Read error: Connection reset by peer)
10:15:20 *** rightnut has joined #openttd
10:15:28 *** izhirahider has joined #openttd
10:19:08 *** lobstarooo has joined #openttd
10:19:08 *** lobster has quit IRC (Read error: Connection reset by peer)
10:28:12 *** lobster has joined #openttd
10:28:12 *** lobstarooo has quit IRC (Read error: Connection reset by peer)
10:45:24 *** lobstarooo has joined #openttd
10:45:24 *** lobster has quit IRC (Read error: Connection reset by peer)
10:48:55 *** lobstarooo has quit IRC (Read error: Connection reset by peer)
10:49:31 *** lobster has joined #openttd
11:14:27 *** lobstarooo has joined #openttd
11:14:27 *** lobster has quit IRC (Read error: Connection reset by peer)
11:16:20 <peter1138> Heh, setting the size to 0 is actually the modern way...
11:16:52 <peter1138> Well, modern lazy way.
11:39:53 <peter1138> Well, specifically in horizontal or vertical containers, setting size to 0 is supported so that inter-widget spacing does the correct thing. Of course there is no inter-widget spacing in that container :)
11:40:06 <peter1138> But yeah, a selection widget is better there.
11:42:25 <talltyler> The selection widget is definitely more readable 🙂
11:43:54 <peter1138> It does make it more obvious.
11:46:15 <peter1138> WID_SCL_SEC_COL_DROPDOWN, WID_N_SHOW_GROUP, WID_SV_CLOSE_AIRPORT, WID_VV_FORCE_PROCEED all cheat...
11:46:51 <peter1138> WWT_DEBUGBOX is also cheated internally.
11:50:06 <peter1138> Maybe mmtunligit wants to do more :-)
11:51:09 <mmtunligit> i could go through and do a cleanup sometime when i want an easy win sure
11:57:27 *** lobster has joined #openttd
11:57:27 *** lobstarooo has quit IRC (Read error: Connection reset by peer)
11:57:28 <peter1138> If you do, one commit per window :)
12:05:49 <xarick> is there a difference between:
12:05:49 <xarick> `ScriptList *tmp = new ScriptList();`
12:08:06 <LordAro> i think you know the answer to that
12:13:19 <xarick> I'm trying to optimize KeepList
12:24:47 <xarick> okay ScriptList tmp it is
12:27:09 <xarick> tmp.AddList is possibly building values uneccessarily
12:27:35 <xarick> tmp is discarded at the end
14:01:42 <talltyler> Trying something, got a crash I don't understand. I'm trying to spawn lighthouses near towns instead of randomly across the map, which doesn't work well on large maps.
14:01:42 <talltyler> I'm getting a pool assert.
14:01:42 <talltyler> Is the town pool not ready for use during object generation, maybe?
14:02:54 <LordAro> lighthouses spawn near towns? *gestures broadly at Scotland*
14:03:03 <LordAro> (sorry, that's not entirely helpful)
14:04:16 <talltyler> I just want more lighthouses in places they actually matter. Near towns and industries are more visible to the player, also towns are often near water in OpenTTD because they look for water.
14:04:28 <talltyler> Other search pattern ideas welcome!
14:07:39 <peter1138> talltyler, it means you didn't check that you could allocate a pool item before allocating it.
14:09:57 <talltyler> Is `Town::Iterate()` the problem? I don't see what I'm allocating that wasn't already there (like the lighthouse itself)
14:09:57 <peter1138> You took the call to TryBuildLightHouse() outside of the loop that calls Object::CanAllocateItem().
14:10:30 <_zephyris> Two main types, on rocks/headlands/isolated bits, and near ports/towns. So two search criteria - one looking for lots of water around the tile, one near towns?
14:13:09 <xarick> objects belong to towns
14:13:36 <peter1138> And there are two main types of players... those who want to place lighthouses by hand, and those who don't want any of them because they're just an annoying obstacle that gets in the way... (guess what, that's the point.)
14:14:51 <talltyler> I've also thought about placing transmitters near industries, just to get in the way 😛
14:15:04 <talltyler> "the way I play is correct" 😛
14:15:29 <peter1138> The lighthouse on the old intro game is the best :)
14:15:39 <xarick> how important is to have this->modifications to match between optimization changes?
14:17:34 <xarick> I reworked KeepList to avoid going into AddList, dual RemoveList, this touches "modifications" quite a lot. and went into some changes which uses less "modification" steps.
14:24:02 <talltyler> Hmm, what about building a random island if the lighthouse search finds a sea tile? 😄
14:25:18 <LordAro> might be fun to see what that results in
14:25:31 <LordAro> probably a very fragmented coastline :D
14:26:04 <rito12_51026> talltyler: Use the north corner and make foundations?
14:28:08 <talltyler> I wonder how hard it would be to add rocky coast tiles...
14:29:50 <talltyler> `Feature: Ships can be dashed upon the rocks`
14:30:23 <peter1138> We have (unused) overlay rocks which might help.
14:30:38 <peter1138> Okay, looks like _zephyris has used them :p
14:30:38 <_zephyris> I'm trying to remember... there are non-snowy overlay rocks, right?
14:30:47 <peter1138> Yes, I added them "just in case"
14:31:17 <_zephyris> I'd already done the overlays for OpenGFX2 objects, which is why I had them ready for snowy rock so quickly
14:31:22 <peter1138> Coast tiles are actually water tiles though.
14:32:11 <talltyler> New water class/type/something, usable both on open sea tiles and coasts?
14:32:36 <peter1138> Well, `WaterClass::Rocks` is a bit... "huh?!"
14:33:22 <peter1138> WaterClass is stored in 2 bits though, so would need shuffling to 3 bits.
14:33:46 <peter1138> Also in some cases WaterClass is preserved, which would be undesirable for rocks.
14:34:15 <talltyler> If we're moving bits around, would be a good time to add WaterClass:Swamp perhaps
14:35:04 <peter1138> Depends. These might be `WaterTileType`s instead.
14:38:31 <rito12_51026> Wasn't it possible to get diagonal rivers?
14:44:25 <talltyler> Diagonal like rails? No. But OpenGFX+ Landscape sprites are drawn in a way that they appear diagonal if placed in a zig-zag diagonal direction.
14:44:25 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:47:27 <rito12_51026> Thanks, I thought it was vanilla
14:53:37 <talltyler> Wow, old screenshot 😄
14:54:15 <peter1138> Those coast tiles.... hmm :hmm:
15:00:10 *** funderscore is now known as f_
15:01:59 <talltyler> Speaking of coasts, has _zephyris ever drawn snowy coast tiles?
15:04:10 <_zephyris> OGFX2 just overlays the shore water/sand onto the ground tile, so pretty trivial to do
15:04:19 <_zephyris> You might make landscape NewGRF authors sad 😉
15:04:27 <_zephyris> Hard to tell sometimes!
15:05:06 <_zephyris> (I don't think it generates the transition tiles as shores, but pretty easy to do)
15:05:36 <LordAro> is there a combination of pixels that _zephyris hasn't drawn yet? :p
15:06:19 <_zephyris> 256^(width*height) scales pretty fast...
15:07:00 <xarick> right: KeepList optimized
15:07:27 <xarick> 10 seconds -> 4 seconds
15:07:40 <xarick> and doesn't require a temporary list
15:08:17 <talltyler> 6 seconds saved with 18 million items?
15:08:55 <xarick> 18 millions on each, so, 36 millions
15:09:21 <talltyler> That's not really a measurable improvement 🙂
15:11:36 <peter1138> Not sure, it does seem like an unrealistic test.
15:11:44 *** WormnestAndroid has joined #openttd
15:14:28 <xarick> I iterate both lists at the same time, and erase items from the main list that don't belong on the other
15:19:06 <xarick> oh, master is different... eh, it would require deconstruction RemoveItem into more functions
15:21:35 <talltyler> `if (Object::CanAllocateItem()) break;`
15:21:35 <talltyler> No wonder my code wasn't building any lighthouses 😛
15:22:40 <peter1138> talltyler, "optimized".
15:23:02 <talltyler> Okay, negating this now gives me the assert again 🤔
15:24:03 *** Wormnest has joined #openttd
15:25:29 <xarick> if you don't have a town you can't place objects
15:33:50 <_glx_> I think a basic improvement for `ScriptList::KeepList` could be to replace `tmp.AddList(this);` with `tmp.CopyList(this);`
15:35:33 <_glx_> oh `AddList()` is the same as `CopyList()` it target is empty
15:36:35 <talltyler> Search pattern works great 😄
15:37:30 <xarick> could it be further optimized, peter?
15:46:03 <audigex> talltyler: I support whatever this feature is
15:46:34 <talltyler> Lighthouses near towns 🙂
15:46:40 <LordAro> i think i once designed a scenario like that...
15:48:58 <kuhnovic> Looks like my walled off AoE2 towns
15:56:15 <_zephyris> New solution for too much city growth
15:59:30 *** alfagamma7 has joined #openttd
15:59:30 <alfagamma7> Looks like Kowloon but worse lmao
16:11:39 <xarick> the same, but for master
16:12:13 <xarick> i split RemoveItem into RemoveItem and RemoveIter
16:14:06 <peter1138> talltyler, "Annoying obstacle" :)
16:16:21 <talltyler> Preview build compiling for anyone who wants to try it out
16:17:12 <xarick> current master, unmodified
16:17:30 <belajalilija> TallTylerviaGitHub: hope this enters the main game so you cant make intercity trains or busses anymore without a checkpoint charlie style station near the border
16:17:35 <kaji_kaede> talltyler: Ah yes, the great lighthouse walls.
16:17:45 <rito12_51026> I can't play openTTD while compiling 🙁
16:18:16 <talltyler> peter1138: I have half a mind to spawn transmitters similarly around towns and industries, although those have no trouble spawning unlike lighthouses currently 🙂
16:18:35 <xarick> master deals with 2 containers at the same time :/
16:18:56 <belajalilija> it should be lighthouses for towns and transmitters for industries
16:19:17 <xarick> actually, one of the containers contains containers
16:20:56 <xarick> i like jgr approach, don't initialize the 2nd container until it's necessary
16:21:09 <xarick> that's why times are almost halfed
16:21:18 <belajalilija> something like this
16:21:30 <belajalilija> in austin, texas
16:27:20 <talltyler> Moonlight towers were a historical blip, but would be a fun GRF.
16:32:13 <belajalilija> it's that video where i learned about them xd
16:33:38 <talltyler> Preview build is live for anyone who wants to try
16:36:19 <peter1138> int SpecialTagInfo::*numtags
16:36:28 <peter1138> Hmm, that's a syntax that looks weird to me.
16:36:49 <peter1138> Used like `for(int i = 0; i < info.*numtags; ++i)`
16:36:55 <peter1138> Which is also weird :)
16:38:29 <_jgr_> It's pointer to member, so it's just dereferencing to produce an int in that loop bound
16:45:16 *** kuka_lie has joined #openttd
16:56:51 <peter1138> Right, it's like a projection, just not a syntax I've seen.
16:57:46 <LordAro> to me it says "are you _sure_ this is the right way to be doing this?"
17:04:41 * peter1138 ponders station triggers and the reasons for storing them for later...
17:19:00 <xarick> they will be initialized if a Begin call is ... called
17:25:54 *** toktik has quit IRC (Remote host closed the connection)
17:38:28 *** Zathras_7 has joined #openttd
17:38:41 <xarick> also, for the 2nd one, couldn't `next_iter = iter; next_iter++;` be used instead?
17:38:45 *** Zathras_7 is now known as debdog
17:38:45 *** debdog has quit IRC (autokilled: This host violated network policy. Mail support@oftc.net if you think this is in error. (2025-11-25 17:38:45))
17:41:04 <_jgr_> This is probably because that's the vanilla code, and I didn't go out of my way to look at those functions
17:41:21 <_jgr_> You're right that it could be made more efficient though
17:44:49 <_jgr_> I doubt that any of those remove by value functions are used very often, if at all
17:48:18 <xarick> as for the RemoveBottom / RemoveTop, I have an idea... probably bad idea
17:48:42 <xarick> I wanna avoid calling this->InitValues();
17:51:42 <xarick> Basically I want this->InitValues relegated only to Begin()
17:52:41 <xarick> yeah... i doubt i can do it
18:05:58 *** zanooda2000 has quit IRC (Quit: User went offline on Discord a while ago)
18:10:33 <xarick> I question these steps here in AddList
18:12:01 <xarick> questioning if there's a possibility to list->values being done twice
18:13:50 <xarick> if the main list is empty and initialized
18:15:44 <_jgr_> If the list is empty there is no work to do, so doing it "twice" does not seem like a problem?
18:16:26 <xarick> sorry, I'm thinking out loud
18:19:24 <xarick> let me imagine list->values has 30 million items
18:21:00 <xarick> this->values = list->values, will be copying 30 million items over
18:21:00 <xarick> if (this->InitValues) path is taken, this->values will be cleared of 30 million items, and then recreated from this->items 30 more millions
18:21:41 <xarick> i just want to make sure that path isn't taken
18:23:25 <_jgr_> The path to call `this->InitValues()` will not be taken if `list->values` is non-empty, because that would require `list->values_inited` to be true, in which case `this->values_inited` will be true by means of assignement the line before the `if` statement
18:42:16 *** Flygon has quit IRC (Remote host closed the connection)
18:44:26 <xarick> values_inited can never be flipped to off once it's on
18:45:09 <xarick> oh, actually it can, via Clear, but then values is empty
19:04:58 *** lobster has quit IRC (Read error: Connection reset by peer)
19:05:34 *** lobster has joined #openttd
19:36:49 <xarick> oh, i still don't get it why you don't prefer `next_iter = iter; next_iter++;` method
19:37:15 <xarick> is it slower? is iterator gonna be in an invalid state
19:42:15 <_jgr_> It would result in an extra lookup to reinitialise the iterator, yes
19:42:35 <_jgr_> In any case using the iterator which is output from erase is tidier
20:04:22 <peter1138> It is arguably the correct way as it makes no assumptions about iteration (in)validation.
20:28:36 <xarick> i'll change ScriptListMap::iterator to auto for my stuff
20:42:53 <michi_cc[d]> Did anyone by chance try #14826 and has any comments on UX/usability?
20:51:57 *** gelignite has joined #openttd
21:07:44 <xarick> I'm going with this->items.contains(item)
21:10:38 <xarick> copilot really likes the word Refactor
21:23:37 *** SigHunter has joined #openttd
21:40:25 <xarick> i just optimized RemoveList, doing the dual iteration approach
21:40:46 <xarick> need to test if there's a gain now
21:48:02 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
22:18:00 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:56:59 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:00:47 <xarick> auto item_iter_boundary2 = this->items.lower_bound(list->items.lower_bound(this->items.rbegin()->first)->first);
23:28:14 <_jgr_> xarick: What on earth are you trying to do with this?
23:31:03 <xarick> on KeepList, I wanna skip the interval which the items exist on both lists, and begin removing past that interval.
23:31:23 <xarick> but i think i'm missing something
23:32:21 <xarick> i don't think there's an interval without gaps
23:33:56 <xarick> imagine i have items 3 4 6 7, and items 3 4 5 6 7...
23:34:15 <xarick> should keep 3 4 6 7... hmm yeah I think I'm dumb
23:34:41 <xarick> can't skip from 3 to 7
23:35:40 <xarick> thanks for asking. I was going dumb with this
23:45:14 <xarick> i have a feeling im still doing something wrong
23:54:16 <xarick> i think i can omit the empty list check...
23:56:09 <xarick> `auto item_iter_boundary1 = this->items.lower_bound(item_iter2->first);` this would assert on `item_iter2->first`
23:56:26 <xarick> well cyas good night, I'll take a better look tomorrow
continue to next day ⏵
