IRC logs for #openttd on OFTC at 2025-11-01
⏴ go to previous day
00:12:10 *** keikoz has quit IRC (Ping timeout: 480 seconds)
00:15:28 *** aperezdc has joined #openttd
00:19:01 *** aperezdc has quit IRC (Remote host closed the connection)
00:20:07 *** aperezdc has joined #openttd
01:12:23 *** Wormnest has quit IRC (Quit: Leaving)
02:28:55 <zanooda2000> rito12_51026: Ugh I didn't think about long parameter names. Extra wide menu is a big no-no-no in terms of "left menu on screen to quickly change tracktypes". Seems like parameter name will be a HUGE problem here, especially on other languages, when actual param takes 7 chars, but its name is 20 or so:
02:28:55 <zanooda2000> `максимальная скорость`
02:28:57 <zanooda2000> My thought is to rename parameters so they will represent units of measurement instead of parameter name, so it will be slightly less chear but hugely shorter, something like:
02:29:01 <zanooda2000> So you won't have constatnly repeating measurement in each item, especially if measurement is long and weird like `tiles/day`
02:29:03 <zanooda2000> Btw 3rd column seems useless because max speed is already here.
02:35:50 <zanooda2000> rito12_51026: hmmmmm, behaviour and other extra things (badges?) could be moved to 2nd row, right below `sort by ^` and [sorting type]... Just like cargo filters on vehicles menu, it will save a lot of space and probably will be clearer to use, since it looks like actual filter but not like something to sort by
03:58:54 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:37:21 <DorpsGek> - Update: Translations from eints (by translators)
04:38:04 *** Zathras_4 has joined #openttd
04:38:15 *** Zathras_11 has joined #openttd
04:41:34 *** Zathras_1 has quit IRC (Ping timeout: 480 seconds)
04:41:39 *** Zathras has quit IRC (Ping timeout: 480 seconds)
04:53:01 *** WormnestAndroid has quit IRC (Remote host closed the connection)
04:53:03 *** WormnestAndroid has joined #openttd
06:41:06 <rito12_51026> zanooda2000: Maybe symbols from physics could be used e.g.`v[m/s]` instead of speed or `I[A]` for electric current. I'm not sure what should be used for cost though.
06:47:39 *** reldred has joined #openttd
06:47:39 <reldred> rito12_51026: whatever the current currency's symbol is?
06:53:55 <rito12_51026> So just $ for cost if dollars are choosen
06:54:23 <reldred> Yeah I mean if you're trying to keep it as short as possible
06:54:54 <reldred> But things like current are going to be tricky anyway depending on how the sets in question define those badges.
06:55:04 <reldred> Total crapshoot I daresay
06:55:23 <reldred> you're trying to hardcode a search for a pattern that's user defineable
07:01:30 <rito12_51026> Why not something like `C[$]`?
07:02:30 <rito12_51026> The current was only an example
07:03:21 <reldred> Yeah I dunno. At that point 'Cost' is the same amount of characters.
07:04:50 <rito12_51026> But `Koszt` or `Kosten` are a bit longer
07:05:06 <reldred> Yeah was gonna say translations are where things get skewiff
07:05:59 <reldred> But is C going to make sense in another language either? Language wise you're now going to have to define another new string, the one letter abbreviation of whatever 'cost' is and get that translated too.
07:07:03 <rito12_51026> It could be translatable
07:07:52 <rito12_51026> e.g. `k[$]` for pl
07:10:12 <rito12_51026> Or mayby just a first letter from the full word `S`from speed `C` from cost
07:10:23 <reldred> Might be worth waiting for one of the yellow names to pop online again, they're the only ones you have to worry about pleasing 😄
07:12:34 <reldred> Thinking though in terms of what thosee fields are going to contain; speeds are going to be measured in KPH or MPH, so you only need to hit three digits there to already have a budget of 6 characters for the column title, costs will skyrocket with maglev track sets and some of the more realism orientated track sets, so assuming a single character for currency and a four or five digit cost you're
07:12:34 <reldred> back up to five or six characters again, more if the currency is using commas or periods to denote thousands,
07:13:28 <reldred> And if you add any badge as a column you're up shit creek, probably best to sccale the column automatically to whatever the biggest 'value' is and truncate the badge name.
07:13:37 <rito12_51026> What about game units?
07:16:54 <rito12_51026> reldred: So the behavior could be displayed as b. or beh...
07:18:11 <reldred> Behavior is a badge, so yeah as soon as you start loading badges in as columns your nice well manicured UI is going to go to hell because you have no control over what a grf author does
07:18:46 <reldred> Which is the current problem with the dropdown list you're trying to solve 🤣
07:21:04 <rito12_51026> I do not know if it is worth it as my current code causes segmentation faults
07:29:55 <reldred> Keep at it, you've gotten further than most do 🙂
07:30:07 <rito12_51026> It is only reproducible with Horse and U&ReRMM turned on at the same time
07:31:08 <reldred> Yeah Horse and U&Rermm are the only two that support the behavior badge at the moment. Horse would be the one to define it. Nobody else does high speed rail using that method that I know of. JP+ implement Shinkansen a different way.
07:32:39 <rito12_51026> I mean the segfault does not occur when only one of them is on
07:33:22 <reldred> Ah, now that's a difficult pickle. I dare say though it's still related to that badge. See if Peter has any ideas when he's online next, badges are his baby.
07:34:14 <reldred> only thing I can think of; reading something defined once: OK, reading something defined twice: crash
07:39:13 <rito12_51026> So it occur when U&ReRMM (does not occur with Horse track, but the Horse need to be on) track with high speed behavior is chosen and the user clicks on any other rali type.
07:43:55 <rito12_51026> 0x000055555753652d in Window::SetFocusedWidget (this=0x5555592a6a10, widget_index=7) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/window.cpp:495
07:43:55 <rito12_51026> 495 this->nested_focus->SetDirty(this);
07:43:55 <rito12_51026> #0 0x000055555753652d in Window::SetFocusedWidget (this=0x5555592a6a10, widget_index=7) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/window.cpp:495
07:43:55 <rito12_51026> #1 0x0000555557536bac in DispatchLeftClickEvent (w=0x5555592a6a10, x=456, y=259, click_count=1)
07:43:56 <rito12_51026> at /home/cyprian/openTTD/OpenTTD_SourceCode/src/window.cpp:659
07:43:56 <rito12_51026> #2 0x000055555753dac2 in MouseLoop (click=MC_LEFT, mousewheel=0) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/window.cpp:2918
07:43:58 <rito12_51026> #3 0x000055555753dea9 in HandleMouseEvents () at /home/cyprian/openTTD/OpenTTD_SourceCode/src/window.cpp:3004
07:43:58 <rito12_51026> #4 0x0000555556e8db4a in VideoDriver_SDL_Base::PollEvent (this=0x555558545e80) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/video/sdl2_v.cpp:444
07:44:00 <rito12_51026> #5 0x0000555556e96633 in VideoDriver::Tick (this=0x555558545e80) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/video/video_driver.cpp:137
07:44:00 <rito12_51026> #6 0x0000555556e8e7ad in VideoDriver_SDL_Base::LoopOnce (this=0x555558545e80) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/video/sdl2_v.cpp:661
07:44:02 <rito12_51026> #7 0x0000555556e8e7e4 in VideoDriver_SDL_Base::MainLoop (this=0x555558545e80) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/video/sdl2_v.cpp:679
07:44:02 <rito12_51026> #8 0x00005555571ed7aa in openttd_main (arguments=std::span of length 1 = {...}) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/openttd.cpp:811
07:44:04 <rito12_51026> #9 0x0000555556720f1f in main (argc=1, argv=0x7fffffffdf88) at /home/cyprian/openTTD/OpenTTD_SourceCode/src/os/unix/unix_main.cpp:36
09:59:41 <xarick> what's the opposite of std::next()
09:59:47 <xarick> std::previous doesn't exist
10:03:58 <kaji_kaede> xarick: std::prev.
10:09:31 <Rubidium> though if you would have read the std::next page on cppreference you now would have known at least three ways to iterate backwards...
10:14:59 <michi_cc> Rubidium: Xarick reading is a tall assumption 😛
10:17:24 <xarick> virtual doesn't like auto?
10:19:24 <xarick> ScriptList::ScriptListMap::iterator
10:19:24 <xarick> ScriptList::ScriptListValueSet::iterator
10:19:24 <xarick> there are 2 types of iterators
10:19:51 <xarick> sort by item lists use the ListMap iterator
10:20:01 <xarick> sort by value lists use the ListValueSet iterator
10:22:20 <xarick> `virtual void PostErase(ScriptList::ScriptListMap::iterator post_erase, ScriptList::ScriptListValueSet::iterator value_post_erase) = 0;` trying to replace this
10:22:54 <xarick> only one of the parameters is required for the real PostErase function
10:48:38 <xarick> oopsie, can't do it like that
11:39:47 <mmtunligit> if ive got an identical function in station_cmd.cpp and waypoint_cmd.cpp that uses a function from station_kdtree.h, where should i declare and define that function so i dont have to write it twice
11:54:13 <xarick> I'm confused about PostErase, what is it supposed to do
11:54:53 <xarick> i removed PostErase and regression still passes the test
12:22:24 <xarick> _jgr_: what is PostErase doing? I removed this callback alltogether and regression still passes the tests
12:22:43 <xarick> am I somewhat hurting performance?
12:23:32 <_jgr_> There's a big comment in the method describing what it is for
12:26:33 <xarick> > * This is to the optimise the case where the current item is removed, and the resulting iterator points to the expected next item.
12:26:33 <xarick> > * NB: A positive generation means that the iterator was not the end iterator, and therefore that item_next has a valid value.
12:28:53 <xarick> hmm how am i gonna test this
12:32:59 <_jgr_> The whole reason I did all these changes is to mitigate the performance problems created by badly written scripts, given that the scripts and the (terrible) ScriptList interface are outside of my control. However as you're a script author, you could more easily solve the problem by writing better scripts instead.
12:34:55 <xarick> need to test performance of removing of items from lists, I suppose
12:35:08 <Borg> I wonder what people are using them for anyway. they usage is very limited..
12:35:42 <Borg> I use them in my Industry Town rebuilder.
12:35:51 <Borg> putting index of industry to GSList() to count and check
12:40:12 <Borg> _jgr_: hah! after all it was worth all that code fidling and refactoring.. started new game at tropic.. w/ new buildign style.. using Routing Restrictions..
12:43:41 <Borg> upgraded or-if and and-if logic works nice :)
12:51:17 <andythenorth> _jgr_: what's wrong with the ScriptList interface (or is it not a simple question)? As an author it's weird, but what's the implementation problem?
12:57:01 <_jgr_> It's both a key-value map and value-key map, where you can sort by either. The interface encourages using it in a way that wastes loads of time and memory, because (in vanilla) it's effectively free to do that (as regards the script opcode and memory accounting) but more obvious/efficient code using for loops isn't.
12:57:04 <_glx_> It's not a good solution for storage
12:58:10 <_glx_> Its only valid use is to get a list of vehicles or industries then valuate then filter
12:58:19 <andythenorth> that's the only way I use it
12:58:24 <andythenorth> often without the valuate
12:58:55 <andythenorth> foreach (industry, _ in industry_list) {
12:59:10 <_glx_> But sadly too many authors also use it when an array or a table would be a better choice
12:59:13 <_jgr_> ScriptTileList is a particular problem
12:59:20 <andythenorth> also they're not industry instances, they're industry IDs and I have to then go and look everything up everytime
13:00:50 <Borg> btw.. anyone can give me some insights of Squirell script comparing to Lua? especially in peformance?
13:01:15 <Borg> Lua is annoying to use... Squirell seems to take best of both worlds.. C++ like.. and Lua
13:01:25 <andythenorth> this is entirely logical, but just irritating if you grew up using actual gamescript languages like actionscript...or just python
13:01:25 <andythenorth> ```local industry_town = GSTile.GetClosestTown(GSIndustry.GetLocation(industry));```
13:01:37 <_jgr_> Stuff like putting every tile on the map in a ScriptTileList, then using Valuate to filter, then using Top to pick the first found is absurdly bad for performance, and it's not practical to optimise this pattern away unfortunately
13:02:12 <andythenorth> when I did tile stuff I wanted some way to get a prefiltered list by specifying a predicate as a parameter
13:02:34 <Borg> for such stuff like this. when its expessive to compute. you can use lazy evaluation
13:02:34 <andythenorth> this would surely be better than copying it all into Squirrel in GSList ?
13:03:29 <andythenorth> maybe one day we'll figure out a squirrel replacement
13:03:38 <andythenorth> and take the padlock off multiple GS in one map 🙂
13:04:14 <Borg> andythenorth: got any options for it?
13:04:29 <Borg> Lua is not an option I guess :P
13:09:06 <andythenorth> I have no options
13:09:22 <andythenorth> all discussion recently have led to some 'await WASM solution' iirc
13:09:26 <andythenorth> but I might have forgotten
13:10:02 <andythenorth> truebrain usually has opinion, but also has moved on to other interest I believe 🙂
13:10:43 <kaji_kaede> Borg: I find Squirrel really frustrating. Though I find it hard to think of any explanation as to why I feel that way.
13:11:36 <kaji_kaede> Maybe I'm just used to working with code more directly than Squirrel allows for.
13:14:25 <andythenorth> squirrel *looks* like a modern OO scripting language
13:14:58 <andythenorth> but it also looks like a single-person project (at least Squirrel 2 - seems Electric Imp took over for Squirrel 3)
13:15:38 <andythenorth> it has a *lot* of weird behaviours compared to the limited number of other languages I've used
13:16:48 <andythenorth> "everything is a table slot" kind of makes sense, but then it has all kinds of syntactic sugar around it, and some of it seems weird
13:17:13 <andythenorth> particularly methods and classes and how they're declared
13:17:35 *** Wormnest has joined #openttd
13:17:44 <andythenorth> I fail constantly at the table syntax as well, the declaration of keys etc seems to have multiple syntaxes
13:17:56 <andythenorth> and sometimes `->` operator can be used and sometimes it can't
13:20:58 <Borg> kaji_kaede: too bad you can tell why :) I wasnt big fan of squiress at the begining.. but after while.. I like it
13:21:15 <Borg> and.. in the past I was fan of Lua. but I had long break
13:21:25 <Borg> when I came back to it.. lack of arrays and index at 1
13:21:33 <Borg> pissed me so much I just gave away
13:22:05 <kaji_kaede> andythenorth: I've never really had an issue with it, but... Most scripts I've seen define functions outside of the class itself, which feels weird to me, having come from C# land.
13:22:32 <Borg> andythenorth: I dont mind using single person solutions. as far as they are opensourc.. of even not.. I disassemble software if nicessary
13:22:50 <Borg> andythenorth: if software is solid.. I simply dont care about maintenace.. I can do it myself to the extend
13:23:42 <Borg> andythenorth: yes.. that is bad part in Squirell indeed, that <- table operator to initialize key
13:23:48 <Borg> I dont understand logic behind it..
13:24:01 <Borg> simple t.ble = val is enough for set (new or update)
13:24:08 <andythenorth> it's just the design I guess
13:24:10 <Borg> if you care about key existence.. you can test it
13:24:27 <_glx_> `<-` is new slot, required to create a slot, then you can use `=` on existing slot
13:25:02 <Borg> _glx_: I understand the logic. what im not understand. why creating new slot needs extra syntax
13:25:07 <kaji_kaede> Borg: > too bad you can't tell why
13:25:07 <kaji_kaede> Aye. I could at least experiment with changing the dang thing if I knew. All I can figure out is that I'd rather just write anything I do in C++, in the actual source repository.
13:25:24 <kaji_kaede> Or in my own fork.
13:25:32 <_glx_> I think it prevents unintended slot creation
13:26:05 <andythenorth> for a problem I've never encountered in 20 years of python 🙂
13:26:17 <andythenorth> memory efficiency perhaps?
13:26:41 <Borg> I dont buy that.. its not C64
13:27:09 <_glx_> anyway `<-` can also update an existing slot
13:27:33 <_glx_> so always using `<-` for tables works fine
13:27:45 <Borg> and it defeats the purpose.. = vs <-
13:28:00 <kaji_kaede> Yeah, `<-` is "assign value to slot, no questions." versus `=`, assign value to slot if exists, throw error if not.
13:28:15 <Borg> anyway. this is my only small concern about this language
13:28:18 <kaji_kaede> ...At least it should do that.
13:28:23 <kaji_kaede> No idea what the heck it's doing if not.
13:28:27 <Borg> except that. it loks solid.. but I never used it in anything.. hence the question
13:28:41 <Borg> if I need low memory stuff. I can use MRuby
13:28:54 <Borg> but its good to have options :)
13:31:57 <xarick> iterating squirrel tables is random (not stable?)
13:32:52 <_glx_> it's not "random", it's based on the key hashes
13:34:02 <_glx_> but yeah tables are unordered
13:34:24 <andythenorth> squirrel is "fine", it just seems unfinished, badly documented etc
13:34:42 <Borg> if you need ordering.. slap whatever data you need to tables using int idx.. and put those idx to GSList() vioala
13:34:55 <andythenorth> GS is also "fine", and has adequate docs, but some of it is weird
13:35:02 <_glx_> in some case the doc is even wrong
13:35:09 <andythenorth> put both issues together, and GS authoring is not appealing 🙂
13:36:45 <_glx_> GS is also super slow to react (being event based)
13:37:11 <andythenorth> and it can't hash objects to the savegame (or is that fixed?)
13:37:19 <andythenorth> so everything has to be persisted to a root table
13:37:44 <andythenorth> and the debugging is....painful
13:38:38 <andythenorth> there's no traversal or inspection, just have to write explicit log lines for everything
13:38:39 <andythenorth> `GSLog.Info("found " + GSIndustry.GetName(industry) + " at tile " + GSIndustry.GetLocation(industry));`
13:38:39 <_glx_> it can save objects (at list ScriptList), but any user created object could follow the not documented API I think
13:39:26 <andythenorth> anyway, it's all "fine" 🙂
13:39:35 <Borg> andythenorth: huh. .I think you expect a bit too much from GS.. like storing entire objects? ;)
13:39:56 <Borg> just serialize/deserliaize stuff you need for save/load and vioala
13:40:20 <andythenorth> it means you have to write your own state manager
13:40:27 <andythenorth> for anything that needs to persist
13:41:28 <Borg> or just store that state in tables and resync leftovers
13:41:51 <andythenorth> that's what that class does
13:42:09 <andythenorth> but without a helper, you end up writing migrations with no proper home
13:42:25 <andythenorth> and it means everything else is just writing to storage with no scaffolding
13:43:13 <andythenorth> without migrations developing is implausible, as savegames just die
13:44:52 <andythenorth> unrelated to that, but related to debugging....I also rapidly found the limits of GSStoryBook 😛
13:45:01 <andythenorth> seems it's not a general purpose UI right now 😛
13:45:10 <andythenorth> "nobody said it was"
13:46:10 <locosage> gs is kinda just a byproduct of ai framework, it's not good at controlling gameplay
13:59:26 <peter1138> Bloody hell my fitness is through the floor :(
14:14:48 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
14:29:29 <xarick> PostErase is required for something
14:41:15 <Rubidium> oh noes... what could it be for?
14:45:37 <xarick> don't know, but will find out
15:00:59 <andythenorth> peter1138: I haven't even done any
15:16:34 <peter1138> Can we close that PR yet? It's getting out of hand :o
15:20:04 <xarick> it wasn't a PostErase issue, it was me clearing way too much code
15:20:18 <xarick> PostErase still removed
15:54:23 <xarick> derp, the array insert loop takes a lot of time
15:57:20 <xarick> okay i need another strategy
15:58:01 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
16:17:35 <andythenorth> Probably a vehicle refit property needs resized?
16:17:59 <andythenorth> Cargos on stations also maybe?
16:19:57 <andythenorth> Dunno didn’t read any src, am on phone at the swimming pool 😛
16:20:13 <andythenorth> Waiting to be less wet so I can leave
16:21:12 <andythenorth> What’s the maths for 64 though? it’s not a byte…or a word
16:22:04 * andythenorth me now doing bit maths on calculator
16:25:06 <andythenorth> 6 bits somewhere?
16:28:38 <peter1138> I mean, what are you talking about?
16:43:22 <andythenorth> Number of cargos in game
16:44:44 <andythenorth> Hmm. I waited until I was dry to leave the gymn
16:45:04 <andythenorth> But now it’s pissing it down outside where I am
16:55:29 <_glx_> andythenorth: 64 because bitmap
16:57:08 <peter1138> Yeah, the patch I definitely don't have, honest, has to (I mean would have to) take care of passing lists of cargo types around instead of just a nice uint64_t.
17:02:27 *** kuka_lie has joined #openttd
17:09:43 <andythenorth> such a patch would only be imaginary
17:41:48 <peter1138> Like all my patches.
17:45:38 <andythenorth> peter1138 is it an svn patch? 👀
17:47:41 <xarick> well... safe btree stuff actually doing stuff
18:26:36 <xarick> list to list interactions
18:28:41 <xarick> the add list had the values not inited
18:28:55 <xarick> very interesting phenomenom
18:50:29 <Borg> How I can get Train Number? the very same number I see in game?
18:53:51 <Borg> hmm usure its the same as Vehicle ID? in game list?
18:54:25 <Borg> hmm it evaluated stuff very very late..
18:56:58 <Borg> no ok. if is ok.. sth is borked
18:57:27 <Borg> if cannot carry Pass or empty: deny
18:57:34 <Borg> all good. but doesnt work.. more DEBUG() to the rescue
19:00:55 <rito12_51026> rito12_51026: I've figured it out. When the U&ReRMM track with high speed behavior is chosen the details panel size is too small and the ReInit is called (Without Horse the badge value is not shown as its string is not defined and therefore the details panel is large enough). OnInit the badge filters container is cleared and all widgets it has contained are being deleted. The pointer to focused
19:00:55 <rito12_51026> widget becomes invalid but it is not reseted to nullptr.
19:03:16 <Borg> okey. all works fine. condition obviusly wrong. haha
19:04:21 <Borg> yep. train passes :D false alarm
19:21:07 <Borg> okey :) lets test slot like setup.. but w/o slots
19:24:27 <Borg> hmm sth wrong w/ Check Signal state
19:24:36 <Borg> uint st = GetSignalStates(tile);
19:24:37 <Borg> result = (st == 15) ? false : true;
19:27:58 <_jgr_> Which signal state are you trying to check specifically?
19:31:25 <Borg> Block signal.. but w/ restriction.. and I noticed sth weird
19:31:47 <Borg> _jgr_: did you used some bits out there to for restricted signal info?
19:32:24 <Borg> normally, tile w/o signals means all green, 15.. if there is signal in any direction. thare are bits configuration depending on Trackdir
19:32:41 <Borg> I dont care.. since I can test tile.. so.. == 15 means whatever signals are there and they are green..
19:32:53 <Borg> the its false.. if not 15.. sth is red..
19:33:43 <Borg> condition I added is.. check signal for Red
19:33:59 <Borg> lets remove restriction temporary
19:34:27 <Borg> damn.. Im missing sth then
19:36:11 <Borg> return GB(_m[tile].m4, 4, 4);
19:42:07 <Borg> when it went from green to red.. st=3
19:42:29 <Borg> okey. I do seem to get Signal Trackbits then
19:43:15 <xarick> oopsie oops. array can't have more than about 67 million items
19:43:27 <xarick> script runs out of memory 😐
19:43:32 <andythenorth> peter1138 is your cargo patch against OpenTTD 1.8?
19:43:54 <xarick> and i have not enough ram
19:46:00 <xarick> my ssf is wasting write cycles
19:46:12 <Borg> ahh I can try to use GetPresentSignals()
19:53:40 <Borg> uint sm = GetPresentSignals(tile);
19:53:40 <Borg> uint st = GetSignalStates(tile) & sm;
19:53:40 <Borg> result = (st == sm) ? false : true;
19:53:56 <andythenorth> Xarick could use some of my RAM
19:54:05 <andythenorth> over the internet
19:54:25 <Borg> andythenorth: using 1.8 too? [;
19:55:50 <peter1138> 36GiB, because Apple.
19:56:16 <Borg> but.. its an ocean of ram for me
19:56:38 <cu-kai> it's more the memory pressure, than the usage, which matters on macOS iirc
19:56:44 <Borg> Free Memory: 12.30G (77%)
19:56:51 <Borg> only because VM is running ;)
19:57:23 <peter1138> Memory "pressure" sounds like some Apple-woo too.
19:57:34 <peter1138> andythenorth, pint?
19:58:57 <Borg> okey it works :> create slot like system. w/o slots :D
19:59:21 <andythenorth> peter1138 if I left on my bike now....we could?
20:00:57 <andythenorth> hmm my RAM is triple channel apparently
20:01:43 <rito12_51026> andythenorth: nice
20:03:29 <andythenorth> so the weird 36GB is due to triple channel (3x12GB packages), whereas dual channel goes in powers of 2
20:04:09 <rito12_51026> just realised that I have 33 GB
20:04:29 <xarick> **left**: map + set, **middle**: safe_btree_map + safe_btree_set, **right**: master
20:05:50 <xarick> dont look at the window titles, they are misleading
20:06:30 <rito12_51026> left is the slowest in iterating
20:09:34 <xarick> interesting, master iterates faster
20:10:00 <peter1138> If you're making lists of 10,000,000 items you're doing it wrong.
20:12:14 <andythenorth> I'd have to cycle really fast though
20:12:27 <andythenorth> probably about 90mph
20:16:29 <xarick> the list.Begin() actually calls InitValues which then generates the entire map list
20:17:48 <xarick> so this "iterate" test is kind of flawed
20:19:30 <xarick> gonna separate the Begin test from the Next/IsEnd
20:27:11 <peter1138> I still think 14717 is entirely the wrong direction.
20:27:30 <peter1138> Now we're trying to come up with ways to work around the window being large.
20:30:12 <andythenorth> my original sketch was just a 30 second effort
20:30:24 <andythenorth> the level of thinking applied was "how else do we buy things?"
20:30:35 <andythenorth> and then "not like the station window please"
20:33:28 <rito12_51026> peter1138: I'm thinking on how to make it not crash the game
20:34:21 <rito12_51026> What would be the correct direction in your opinion, Peter?
20:36:39 <rito12_51026> Would you be happier if the window was just small
20:43:52 *** tabytac has joined #openttd
20:43:52 <tabytac> Yeah I don't think using the vehicle purchase window is the move too
20:44:07 <tabytac> Something short and wide seems more apt imo
20:54:50 <rito12_51026> any other ideas?
20:57:25 <brickblock19280> That honey doesn't seem any better than the current ui since it is not as versitile as the vehicle one and also wouldn't work with traditional button behavior
20:57:37 <talltyler> What about a dropdown in the construction toolbar, instead of the main toolbar? Similar to how airports are selected.
21:01:47 <brickblock19280> I don't see any difference compared to the advanced button
21:04:13 <peter1138> So, we should identify what's wrong with the current list first.
21:04:54 <rito12_51026> The lack of sorting / filtering
21:10:50 <rito12_51026> Ufiby — 18.10.2025, 15:07
21:10:50 <rito12_51026> > I tested IH + UReRMM2. Now I understand. It's a bit more complicated than redefining with labels, but still better. No more adding hidden labels. By the way, if a high-speed railway is available, how can I hide the LGVE railway label?
21:10:50 <rito12_51026> andythenorth — 18.10.2025, 15:09
21:10:50 <rito12_51026> > currently you can't, but maybe we can change that
21:10:52 <rito12_51026> > I am hoping OpenTTD solves it with better railtype building UI
21:10:52 <rito12_51026> > or Iron Horse could detect UReRMM2 and disable LGVE
21:21:42 <rito12_51026> reldred: reldred — 26.09.2025, 09:54
21:21:42 <rito12_51026> > So, UI wise, I was thinking... Badges? Problem is it would need to be click to open not click and hold. Vertical list of badge icons up the left hand side of the list, click the badge to filter the list, yadda yadda.
21:21:42 <rito12_51026> peter1138 — 26.09.2025, 09:51
21:21:42 <rito12_51026> > dump_info railtypes is amusing when there's 284 of them defined. A big long meaningless list ;D
21:21:42 <rito12_51026> > (But so is the menu)
21:24:55 <andythenorth> I think we're getting a bit caught up on layout and size
21:25:06 <andythenorth> UI is designed from affordance out
21:25:15 <andythenorth> well...sometimes it is 😛
21:25:21 <andythenorth> other times it's designed by yolo swag
21:25:46 <rito12_51026> #14599 ? (Add: Include build cost in rail/road dropdowns.)
21:28:00 <andythenorth> railtypes have problems
21:28:00 <andythenorth> * exceed the viewport in a hard-to-scroll dropdown
21:28:00 <andythenorth> * difficulty distinguishing between railtypes, as there's obvious way to present metadata (properties) within a dropdown
21:28:00 <andythenorth> railtypes have opportunities
21:28:00 <andythenorth> * display of metadata (properties)
21:28:01 <andythenorth> * display of badges
21:28:01 <andythenorth> * filtering on properties or badges
21:28:03 <andythenorth> * hiding/showing railtypes
21:28:03 <andythenorth> * changing sort order of railtype list
21:28:27 <andythenorth> there is, as usual, a spacebar heating problem
21:28:46 <andythenorth> because we apparently have to preserve the old behaviour
21:29:08 <andythenorth> whilst also not exposing how the old behaviour collapses when there are more than about 9 railtypes
21:29:39 <brickblock19280> rito12_51026: The second alternative here is the correct one imo, changing the way the game works when a solution can be done in grf is unnecessary. That's not to say hiding railtypes is useless + all the benefits Andy added above
21:30:45 <andythenorth> I chose the train list as the starting point because
21:30:45 <andythenorth> * it has filters, sort, property display, badges, so we don't have to imagine those
21:30:45 <andythenorth> * the other obvious alternative is station picker or object picker, and I don't see how categorisation and views for angles helps with railtypes
21:32:15 <andythenorth> if we are going with the pitchfork crowd, then just stick with the dropdown
21:32:25 <andythenorth> and tell grf authors to stop making so many frigging railtypes
21:32:47 <andythenorth> adding lots of non-sortable, non-filterable metadata to the dropdown is only going to make it worse
21:33:18 <andythenorth> obviously it's way easier to just let some people turn up in the PR and demand 'no change'
21:33:31 <andythenorth> or try to accomodate their suggestions, but their main suggestion is 'no change'
21:33:36 <andythenorth> so that won't work
21:33:39 <brickblock19280> I believe the current ui is the absolute fastest especially when there are only a few types. It's one click and moving the mouse versus potentially scrolling and clicking twice.
21:34:54 <andythenorth> I accept that for the simple case
21:35:32 <andythenorth> * minimum number of clicks isn't the measure of good UI
21:35:32 <andythenorth> * the current UI promotes mistakes
21:35:32 <andythenorth> * the current UI requires a lot of cognitive effort
21:35:55 <andythenorth> I once worked out how many hundred million pixels I'd drawn, every one requires a click on the trackpad. The trackpad has not worn out
21:36:00 <brickblock19280> I've not really seen anyone opposed to the idea in its entirety. It's very useful for a set like SETS with over 10 railtypes but will just get in the way for IH or NUTS/PURR
21:36:05 <andythenorth> we don't need to worry about people wearing their mousebutton out
21:36:40 <andythenorth> JP+ has 63 railtypes, and the discord consensu is very clear that it's essential
21:36:46 <andythenorth> go with what's winning
21:37:35 <brickblock19280> I don't believe most players have more than 8 railtypes
21:38:50 <andythenorth> I'm not going to criticise completionist model train sets
21:38:58 <brickblock19280> One idea would be to have the advanced menu allow setting favorites which show up in the drop down
21:39:04 <andythenorth> I've tested JP+ it's clearly for roleplay / world building
21:39:29 <andythenorth> the pitchfork solution would be similar to how the train list used to have both versions available
21:39:55 *** Borg has quit IRC (Quit: leaving)
21:40:00 <andythenorth> it was a setting, or ctrl-click or something
21:40:00 <brickblock19280> Yeah and I don't use most of the types in one game but the 7 or so I do should be easily accessible
21:40:13 <brickblock19280> There was a different ui?
21:40:54 <andythenorth> yeah my copy of 1.9.1 has it
21:41:09 <andythenorth> ctrl-click on the train list in global toolbar
21:41:15 <andythenorth> it got removed or hidden at some point
21:41:31 <andythenorth> because there were players who 'needed' this version
21:41:42 <andythenorth> which is another way of saying "humans fear change"
21:42:00 <andythenorth> and then make up stories about efficiency and stuff, so they don't have to name their emotions about a pixel train game
21:43:10 <brickblock19280> I should use the "new" ui more maybe but I still think it's not really necessary for most players
21:44:01 <brickblock19280> The train list is different since it's not really something all players have to use
21:44:36 <brickblock19280> Or maybe not 🤷♀️
21:46:39 <rito12_51026> From my experience the ability to open the build toolbar for the last used rail type without need to scroll or select from the dropdown is the best feature of the current behavior.
21:47:29 <_glx_> some way to configure which railtypes should be shown/hidden from the menu might be the better option
21:49:07 <brickblock19280> _glx_: Yeah, this would be really good
21:49:08 <_glx_> but it probably has to be done via an extra window, not like vehicle hidding
21:49:42 <brickblock19280> Could it not be the proposed advanced window?
21:52:58 <rito12_51026> andythenorth: andythenorth — 8.09.2025, 09:31
21:52:58 <rito12_51026> > hmm frosch things
21:52:58 <rito12_51026> reldred — 8.09.2025, 09:45
21:53:00 <rito12_51026> > Ground types would certainly let a lot of sets drastically cut back on how many tracks they need, but in the meanwhile eh.
21:53:00 <rito12_51026> > I don’t think mixing rail sets should ever really be supported or encouraged outside of very very specific combinations.
21:54:23 <rito12_51026> maybe the ui is not the main problem here
21:55:04 <brickblock19280> But BGT needs a new ui anyway
21:56:17 <rito12_51026> peter1138: peter1138 — 11.09.2025, 14:17
21:56:17 <rito12_51026> > Well, if all the different xUSSR types could be grouped, for instance, that wouldn't be bad.
21:56:17 <rito12_51026> > But now that the toolbar menus support staying open, a huge railtype list is not so impossible to use. Still a bad UX though.
21:57:36 <brickblock19280> Badge filtering would work for that until / if BGT is implemented imo
21:57:42 <peter1138> When I say "identify what's wrong" I didn't mean listing every time everyone said it could, in some way, be better than it is.
22:04:16 <rito12_51026> You're lucky that's all I could find
22:11:42 <talltyler> In my mind, there are two elements of “what’s wrong”:
22:11:42 <talltyler> 1. Using a dropdown gets slower the more items it holds.
22:11:42 <talltyler> 2. Players have to use the full dropdown every time they select a different railtype.
22:11:42 <talltyler> This means there are at least two solutions:
22:11:42 <talltyler> 1. Reduce the number of items by adding filtering, splitting into several dropdowns to reduce combinatorial load (BGT would fall under this), etc.
22:11:43 <talltyler> 2. Allow players to change railtypes without scrolling the entire dropdown. Filtering could again help here, as would user-selected favorites, most-used or recently-used shortcuts, or switching to something besides a dropdown (I don’t know what this would be).
22:18:14 <peter1138> Things like sort order is explicitly set by the NewGRF. I have no idea why JP+ Tracks decides that there should be two ranges of Narrow Gauge.
22:18:56 <mmtunligit> presumably because japan has two different narrow gauges in regular use?
22:21:49 <Borg> re ;) just dropped in to share
22:22:57 <mmtunligit> ooh i really like "signal is red"
22:23:28 <Borg> yeah I added it.. necessary for slot like.. because I need to detect trains waiting
22:23:56 <Borg> and you need and-if too..
22:38:23 *** Borg has quit IRC (Quit: leaving)
23:10:49 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:28:39 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:45:00 *** kuka_lie has quit IRC (Quit: Lost terminal)
continue to next day ⏵
