IRC logs for #openttd on OFTC at 2024-03-26
β΄ go to previous day
00:30:18 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
00:43:59 *** Wormnest_ has joined #openttd
01:19:09 <johnfranklin> Just found easter collapes with openttd release...
01:34:50 *** Wormnest_ has quit IRC (Quit: Leaving)
01:48:19 *** ChanServ sets mode: +v tokai
01:55:11 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:20:44 <rau117> kamnet: Well, happy birthday ππ
03:24:04 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:29:33 <silent_tempest> I've been playing around with adding some settings for selecting fonts and being able to resize in the Game Options GUI. I'm still working at it but any thoughts on this UI design? "Primary" is just what I'm calling FS_MEDIUM for now. I need to add the others onto the dialog but for one just concentrating on getting this one completely working first.
04:40:42 <DorpsGek> - Update: Translations from eints (by translators)
06:12:22 <rau117> hmm... there's a super-small but also super-helpful idea
06:12:22 <rau117> Move these buttons to the center to make it harder to missclick. Moving will not require any βcomplexβ operations, just replace a couple of parameters.
06:12:22 <rau117> Now it is VERY easy to hit one of the tiny buttons when you try to, for example, resize the window. And even more, it's difficult to at least realize that you just launched/stopped **all** the trains.
06:12:24 <rau117> *(if necessary, Iβll create suggestion topic on Github)*
06:26:48 <jfs> actually, there are a bunch of places where we would really prefer a control (typically a button) to always be square, rather than occasionally tall or wide
06:26:48 <jfs> so maybe that should be a flag controls can have, to affect the layout code
06:27:02 <jfs> that would at least be able to fix the sizing issue there
06:52:49 <rau117> Well, the main problem here is the location. Increasing the size of the button will only⦠increase the likelihood of a missclick if left in the same place.
06:53:06 *** nielsm has quit IRC (Ping timeout: 480 seconds)
06:54:22 <LordAro> rau117: i'm not opposed to a "button is too small" issue
06:54:58 <LordAro> just be careful to frame it in terms of the actual problem, rather than a suggestion/solution
07:35:01 <truebrain> kamnet: Happy birthday old <word I cannot say> π π₯³
07:46:35 <dwfreed> in the US, it's common to call someone an "old fart" when wishing them a happy birthday
07:58:43 <andythenorth> did something change in GS? π
08:31:35 <reldred> truebrain: On the other hand we can say βold fuckβ π
08:32:04 <reldred> (Hippy bath day kamnet)
08:35:33 <kamnet> Birthday is Sunday. I'll probably be around
09:06:05 <peter1138> Variable interface scale is there for a reason...
09:06:49 <peter1138> Using 1x and then claiming it's too small is kinda special.
09:11:37 <peter1138> jfs: I already started on something for that though π
09:12:09 <peter1138> Although rather than a flag, my preference is an aspect ratio.
09:34:28 *** gelignite has joined #openttd
09:47:35 <sparknf> Hello, lets say i want to change the game GUI, where do i start ?
09:52:34 <peter1138> Depends what you want to change.
09:52:56 <sparknf> I would like the GUI layout, Like how it looks.
09:52:58 <peter1138> GUI stuff is mainly in *_gui files.
09:53:56 <peter1138> Rendering of common things is mostly in `widget.cpp` and it calls 'primitives' that live in `gfx.cpp`
09:54:45 <peter1138> Window layouts are spread out in the *_gui files.
09:55:08 <peter1138> Lists of `WidgetPart`.
10:18:39 <peter1138> MS Teams wanted me to sign in again. While in a call.
10:54:19 *** gelignite has quit IRC (Quit: Stay safe!)
11:40:54 <peter1138> Holy shit that bridge in Baltimore.
11:53:47 *** Leopold___ has joined #openttd
11:56:14 *** Leopold has quit IRC (Ping timeout: 480 seconds)
11:56:27 <aperezdc> so that's why there was work on bridge/boat height stuff for openttd ^_^
11:59:12 *** Leopold___ has quit IRC (Remote host closed the connection)
11:59:19 *** Leopold has joined #openttd
12:09:59 <xarick> bridges collapse that easily?
12:10:29 <LordAro> ship really hard to stop
12:10:42 <dwfreed> ship big, and nailing the primary support tends to do that
12:12:45 <xarick> singaporean ship, with a greek owner
12:13:01 <xarick> who's gonna pay for it
12:13:19 <dwfreed> the insurance company
12:16:12 <talltyler> Itβs Sunshine Skyway all over again π¦
12:18:38 <talltyler> Baltimore didnβt seems to have the dolphins to keep the bridge from being struck
12:36:22 <andythenorth> early speculation suggests that they not required by the safety standard, based on assessed risk
12:40:33 <lucafiorini> Context: I am trying to add order Improt/export functionality
12:40:33 <lucafiorini> I am still working away at the problem and I am happy to say I can now import basic order data!
12:40:33 <lucafiorini> Now I need to import _all the other stuff..._
12:40:33 <lucafiorini> And this is where I once again hit a brick wall
12:40:33 <lucafiorini> This is the order import function
12:40:33 <lucafiorini> void Order::FromJSONString(const Vehicle * v,std::string jsonSTR)
12:40:37 <lucafiorini> all of this is packed (thank god)
12:40:37 <lucafiorini> this->type = (OrderType)GB(packed, 0, 8); //done
12:40:39 <lucafiorini> this->flags = GB(packed, 8, 16); // done
12:40:39 <lucafiorini> this->dest = GB(packed, 24, 16); // done
12:40:41 <lucafiorini> None of this can be set easily
12:40:41 <lucafiorini> this->extra = nullptr;
12:40:43 <lucafiorini> this->next = nullptr;
12:40:43 <lucafiorini> this->refit_cargo = CARGO_NO_REFIT;
12:40:45 <lucafiorini> this->occupancy = 0;
12:40:45 <lucafiorini> this->wait_time = 0;
12:40:47 <lucafiorini> this->travel_time = 0;
12:40:47 <lucafiorini> this->max_speed = UINT16_MAX;
12:40:49 <lucafiorini> nlohmann::json json = nlohmann::json::parse(jsonSTR);
12:40:51 <lucafiorini> uint64_t order_pack = json.at("packed-data").get<uint64_t>();
12:40:51 <lucafiorini> uint64_t extra = json.at("packed-data").get<uint64_t>();
12:40:53 <lucafiorini> DoCommandPEx(v->tile, v->index, 0, order_pack, CMD_INSERT_ORDER | CMD_MSG(STR_ERROR_CAN_T_INSERT_NEW_ORDER), nullptr, nullptr, 0);
12:40:53 <lucafiorini> //Import all the other stuff
12:40:55 <lucafiorini> to imoprt all the rest of the data, I would need to use CMD_MODIFY_ORDER but that seems extremely convulted considering I already have all the raw data available, what would you guys suggest as a possible solution to import everything easily?
12:41:45 <peter1138> Is it possible to load in a running game?
12:42:34 <peter1138> If yes, and you want to be able to save/load orders while connected to a multiplayer server, you will absolutely need to issue commands to the server.
12:43:29 <peter1138> Also, vanilla's command system is different from JGRPP. If you're targeting JGRPP only, that's okay of course.
12:46:01 <lucafiorini> peter1138: I am only targeting JGRPP
12:46:24 <lucafiorini> I was considering implementing a new commamd
12:48:13 <peter1138> You will need to implement your own command.
12:49:30 <peter1138> Otherwise the operation will not be atomic, and you might end up with half an imported order list.
12:50:04 <peter1138> You should however prefer to use the existing commands where possible, even in your own command.
12:50:30 <peter1138> So you have a command to bulk send the whole order list, and that command itself can then use the normal order commands internally to set the orders.
12:50:50 <peter1138> That way you can rely on the existing order validation to occur.
14:07:06 <andythenorth> oof had a horrible idea about moving stations
14:07:13 <andythenorth> let's see where that came from
14:07:21 <andythenorth> concrete mixer trucks
14:08:01 <andythenorth> FIRS has concrete products, which go from concrete plant (secondary industry) to builders yard (tertiary industry, 1 per town)
14:08:33 <andythenorth> the product can include ready mix concrete, in a spinny-drum truck
14:08:42 <andythenorth> but those go to building sites, not builders yards
14:09:17 <andythenorth> so ideally towns would have 'building site' buildings or industries, which would move around the town every year or so
14:09:23 <andythenorth> and include a station tile
14:09:32 *** SigHunter has joined #openttd
14:09:47 <andythenorth> repeat for: fishing grounds, dredging sites, logging camps
14:10:38 <andythenorth> there would be a parent industry of some type, but it could place and remove satellite industries or buildings, with stations
14:20:35 <lucafiorini> peter1138: I suppose simply using AssignOrder would not work would it
14:21:00 <lucafiorini> coz that is just used during saveload
14:21:26 <peter1138> That does not send it over the network.
14:24:06 <lucafiorini> Quite unfortunate that.
14:24:18 <lucafiorini> I guess I will need to make an overly complex parser then
14:25:17 <lucafiorini> Or just set up a whole new command to set the extra data in a less painful way
14:25:30 <lucafiorini> Which is probs way more maintainable
14:25:56 <lucafiorini> Time to trigger out how that whole system works I guess
14:26:23 <peter1138> Vanilla's command system provides automatic (ds)serialization, but I think with JGRPP you might have to do that yourself.
14:27:40 <lucafiorini> peter1138: What do you mean by (ds) serialization?
14:27:57 <peter1138> Sorry, (de)serialization.
14:29:05 <lucafiorini> I will have a look at that just to find out whether it is implemented
14:31:45 <peter1138> Obviously I am biased, but IMHO it's better to target vanilla than jgrpp. If a feature is merged to vanilla then it will get ported to jgrpp anyway. But the other way around doesn't often happen, leading to the perpetual "why is x not in vanilla?"
14:59:28 <lucafiorini> I've always thought the reason why JGRPP I'd a thing is that it is the fork that has more settings and advanced features for those that seek that more tuneable and realistic transport management system, and that the main branch tries to distance itself from adding too many extra features.
14:59:28 <lucafiorini> I thought and was told that order import/export as JSON is too advanced to fit into the main branch, would you say that that is not the case?
15:00:44 <lucafiorini> Also, the main reason I am doing this is to help with timetable and slots management, and it 's been a long time since I played vanilla but I don't think that's been implemented as thoroughly in the main branch
15:04:46 <LordAro> i'd go with "experimental" over "advanced" generally speaking
15:12:01 <Eddi|zuHause> i'd rather go with "niche"
15:14:05 *** gelignite has joined #openttd
15:34:01 <_jgr_> lucafiorini: If you choose to submit it to my branch I can take care of making sure that multiplayer is bulletproof as and when it is merged
15:37:09 <xarick> there are no timetables for AIs
15:37:20 <xarick> it's a feature I never tried to understand
15:37:34 <xarick> doesn't spark much interest in me for implementing it
15:37:44 <lucafiorini> _jgr_: So could you help me deal with last few import bits & proper UI implementation?
15:41:24 <lucafiorini> what would you say the best approach for jgr would be? new custom command that just takes the raw extra data and slams it in?
15:41:51 <_jgr_> I haven't had a chance to look much at your code at all yet
15:43:11 <_jgr_> But in general adding commands is no big deal, and sounds reasonable here
15:46:47 <lucafiorini> (it is a massive mess I know)
15:47:08 <lucafiorini> the jsonstring is just passed in as a string there for testing
15:48:33 <lucafiorini> I couldn't get the UI to work reliably so it's mothballed for now
15:54:57 <lucafiorini> OH wow I just looked at the vanilla Openttd InsertOrder function
15:55:03 <lucafiorini> it would make this so much easier
15:59:14 <_jgr_> Maybe focus on the more straightforward stuff to start with?
15:59:44 <_jgr_> Scheduled dispatch and the more exotic order flags can always be done later once you're happy with the core functionality
16:02:25 *** Wormnest_ has joined #openttd
16:03:35 <lucafiorini> CommandCost CmdInsertOrderIntl(DoCommandFlag flags, Vehicle *v, VehicleOrderID sel_ord, const Order &new_order, bool allow_load_by_cargo_type)
16:03:35 <lucafiorini> I just found this good lad
16:03:48 <lucafiorini> I originally thought it just changed the reference
16:03:51 <lucafiorini> oh how wrong I was
16:04:25 <lucafiorini> this sholdm make it quite straightforward
16:06:14 <peter1138> As long as you are issuing a command, not just calling a Cmd function.
16:06:24 <lucafiorini> Sho should I map a new CMD_INSERT_ORDER_INTO_LIST, and map it to use that
16:06:38 <lucafiorini> seems quite straightforward
16:08:47 <lucafiorini> oh no I just remembered that the cmd interface doesn't take objects
16:09:11 <lucafiorini> CommandProcEx does take strings though
16:10:41 <lucafiorini> unless I can somehow use CommandAuxiliaryBase
16:10:58 <lucafiorini> oh well I will dig myself out of this hole
16:18:54 <_jgr_> It's probably worth thinking about what you're going to do with this JSON
16:19:35 <_jgr_> Directly serialising the various flags fields does work but doesn't really help whoever is going to actually read these files
16:20:47 <_jgr_> Flag fields are also subject to change as features are added/removed/extended/etc
16:21:22 <lucafiorini> for the sake of redundancy, the main parser will use the raw data, but I will also add support for optional extras which will overwrite the existing stuff
16:21:39 <lucafiorini> to prevent people from having to change the json parser all the time
16:22:49 <lucafiorini> so, for example I don't think you will be able to change conditional info in the file, but you will be able to set the travel time, destination and some extra fields as needed
16:23:42 <lucafiorini> I think it makes it a bit more redundant
16:24:10 <_jgr_> Yes, but it also adds more failure paths
16:27:08 <lucafiorini> the parser will outpuy an error when the raw data is wrong, and it will refuse to add the order and it will put out a warning when it can't parse one of the optional fields
16:29:13 <lucafiorini> errors will be displayed as normal warnings to the user, and the parser will parse all it can. When it hits an error, it will either create an error label over the order it failed to load, and when one of the optional fields fails to parse it will output a warning label after the affected order
16:29:38 <lucafiorini> if one of the mandatory orderlist
16:30:50 <lucafiorini> same for warnings, but it will actually apply the mandatory data
16:31:45 <lucafiorini> I actually don't think there are any mandatory "head" parameters though so it should be ok
16:32:40 <_jgr_> I am thinking about consistency with respect to the rest of the game state, I'm not really concerned about JSON parsing issues
16:33:47 <lucafiorini> I will try to use the existing commands wherever possible to make the game interpret what's happening as someone adding orders via the GUI
16:34:04 <lucafiorini> but I think being able to just pass in raw data is really important
16:34:33 <lucafiorini> is there a way of validating an order's data?
16:37:22 <_jgr_> To a first approximation, no
16:39:54 <_jgr_> Mostly nonsense order data is harmless, checks can be added for things that are actually a problem
16:41:01 <_jgr_> On the whole it is quite a large surface area to load untrusted data into
16:41:50 <lucafiorini> so it should be alright?
16:42:19 <lucafiorini> I may separate editable and non-editable data
16:42:31 <lucafiorini> but that will come after I can fully import an orderlist
16:43:41 <lucafiorini> I am also thinking of adding a top-level key for the formatversion
16:44:12 <lucafiorini> just in case we need to change it sometimes (even though it is not meant to be used for long-term order storage)
16:45:05 <_jgr_> It may not be meant for that, but users will still do it
16:46:21 <_jgr_> I am keen to avoid receiving crash reports due to orders in an invalid state
16:48:09 <lucafiorini> as long as invalid data within the order's flags and extras won't cause a crash it should be alright then
16:48:53 <lucafiorini> and even then, I will make it abbundantly clear in the file which part you should touch and which part you should stay away from
16:50:10 *** gelignite has quit IRC (Quit: Stay safe!)
17:03:58 <lucafiorini> is CommandAuxiliary used anywhere?
17:22:07 <_jgr_> Thinking about it, it'd probably be better to serialise the flags and other things according to the corresponding MOF_* modification to re-insert it
17:22:37 <_jgr_> That is likely to be more future-proof, and reduce the need to write loads of extra validation code
17:25:18 <_jgr_> In the meantime perhaps a draft PR would be a better place to keep track of these sorts of issues
17:42:03 *** matusguy has joined #openttd
17:45:43 *** Flygon has quit IRC (Remote host closed the connection)
17:46:19 <lucafiorini> _jgr_: I am currently in the process of understanding how the serialisation functions work, because I think using CmdInsertOrderIntl would be hella nice
17:46:41 <lucafiorini> litterally 0 parsing needed and it validates everything for you
17:50:34 *** HerzogDeXtEr has joined #openttd
18:41:45 <peter1138> That reminds me, I need to get some squash.
18:46:38 <xarick> oh, AM4 got extended support till 2025
18:47:44 <xarick> let's hope for a Ryzen 9 5950XT3D to exist
19:17:32 <andythenorth> ok so there was an idea about grf industry having subsidiary layouts
19:17:40 <andythenorth> and then the game composes a layout from those, in combination
19:18:00 <andythenorth> do we fancy that, or should I just pre-compose hundreds of variations in grf? π
19:26:28 <andythenorth> layouts in grf are probably fine, I'm just not very good at writing transforms π
19:26:50 <andythenorth> and I want to rotate the subsidiary layouts 90 / 180 / 270 degrees
19:28:48 <locosage> sounds like a very firs problem
19:29:20 <peter1138> Do it how Minecraft does it.
19:30:12 <andythenorth> I'm pretty happy to do it in grf
19:30:19 <andythenorth> how does Minecraft do it?
19:34:34 <peter1138> I don't know, I'm not Mumbo Jumbo.
19:48:30 <peter1138> Kinda extreme, but then, setting weird font sizes...
19:50:53 <frosch123> ottd still has no gridlayout
19:51:24 <peter1138> Nope, every time I look at implementing it I get sidetracked π
19:58:15 <andythenorth> use Bootstrap π
20:09:09 *** Leopold has quit IRC (Remote host closed the connection)
20:10:02 <_zephyris> peter1138: Looks good
20:10:20 <_zephyris> Surprised me when i did some original graphics stuff that they weren't square
20:11:19 <peter1138> Well it's awkward because a bottom row of buttons is taller than the width of a vertical scrollbar.
20:11:43 <peter1138> And depending on the widget layout you get a tall resize button, or a wide scrollbar.
20:11:45 <frosch123> i think rectangular looks better, than squares of different size in every window
20:14:22 *** Leopold_ has joined #openttd
20:14:24 <_zephyris> Mmm, I didn't notice the mismatched resize handle button sizes...
20:35:29 <peter1138> Hmm, maybe this widget aspect ratio thing is too much then.
20:38:46 <_zephyris> Some is, some isn't, the resize handle should probably be scrollbar width, arguably square for other buttons on the bottom bar.
21:00:10 *** gelignite has joined #openttd
21:00:29 <LordAro> peter1138: definite improvement
21:03:41 <_zephyris> peter1138: thanks for the ogfx2 bug report
21:04:42 <peter1138> It's minor and not that important, but I noticed it for a while now π
21:05:49 <__karma> Hey, one question, one of the tests fails and says that some strings might be unused. Tho they are used, but not directly, I access them by `sd->str + 1` for ex, is that a problem?
21:06:38 <peter1138> That's not ideal, but there is a way to tell the system that some strings are used indirectly.
21:06:58 <peter1138> Look for `###length`
21:09:10 <peter1138> Hmm, doing the aspect ratio of the dropdown button is a pain, because it's not really a button.
21:09:31 <peter1138> The whole thing, including the label part, is one widget.
21:10:26 <peter1138> See, always sidetracked...
21:12:14 <__karma> peter1138: Alright thx
21:18:20 <__karma> Also it says here that this function is unused, tho it is but through its pointer. Any problem with this?
21:36:09 <__karma> Glx I don't how to answer your comment regarding GUI callback π
21:36:09 <__karma> Would you like me to implement it?
21:57:18 <__karma> Well its broken I will amend the commit
22:36:41 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:52:02 <peter1138> Hmm, I kinda what CRTP-type stuff for widgets. What a rabbit hole.
23:13:10 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:31:35 *** matusguy has quit IRC (Remote host closed the connection)
23:48:03 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day β΅