Times are UTC Toggle Colours
00:26:38 *** Kitrana1 has joined #openttd 00:31:35 *** Kitrana has quit IRC 00:40:46 *** sla_ro|master has quit IRC 01:39:34 *** yoltid[m] has quit IRC 01:39:41 *** yoltid[m] has joined #openttd 01:59:52 *** tokai has joined #openttd 01:59:53 *** ChanServ sets mode: +v tokai 02:02:36 *** WormnestAndroid has joined #openttd 02:06:49 *** tokai|noir has quit IRC 02:17:29 *** WormnestAndroid has quit IRC 02:17:43 *** WormnestAndroid has joined #openttd 03:21:48 *** glx has quit IRC 03:35:06 *** Wormnest has quit IRC 03:36:06 *** jeremy[m] has quit IRC 03:36:09 *** jeremy[m] has joined #openttd 03:36:22 *** leward[m] has quit IRC 03:36:24 *** leward[m] has joined #openttd 03:40:02 *** Flygon has joined #openttd 04:02:54 *** D-HUND has joined #openttd 04:06:14 *** debdog has quit IRC 04:07:37 *** D-HUND is now known as debdog 05:39:34 *** Soni has quit IRC 05:39:35 *** Soni has joined #openttd 06:17:58 *** zzy2357[m] has quit IRC 06:18:00 *** zzy2357[m] has joined #openttd 06:37:26 *** nielsm has joined #openttd 07:13:10 *** natalie[m] has quit IRC 07:13:15 *** natalie[m] has joined #openttd 07:44:03 *** andythenorth has joined #openttd 07:51:37 <andythenorth> is cat? 07:55:47 *** OsteHovel_ has quit IRC 07:56:05 *** OsteHovel_ has joined #openttd 07:56:27 *** OsteHovel_ is now known as OsteHovel 07:56:30 *** sla_ro|master has joined #openttd 07:56:33 *** OsteHovel has quit IRC 07:56:50 *** OsteHovel has joined #openttd 07:58:37 *** gelignite has joined #openttd 07:58:45 *** andythenorth has quit IRC 08:00:26 *** andythenorth has joined #openttd 08:13:58 *** milek7_ has joined #openttd 08:13:58 *** milek7 has quit IRC 08:16:47 <nielsm> https://github.com/OpenTTD/OpenTTD/blob/master/src/order_cmd.cpp#L2083-L2091 08:17:20 <nielsm> wouldn't it make sense to change the return type of this function to an enum actually telling what it means 08:18:05 <nielsm> right now the function name contains zero hint at what true/false returns mean, or rather you'd assume true meant that processing was successful and false that there is some problem with the orders 08:22:08 *** gelignite has quit IRC 08:26:26 *** jottyfan has joined #openttd 08:40:37 <nielsm> but since it actually also calls UpdateOrderDest, maybe it should return (or fill in) a structure about the order updates needed 09:09:58 *** ciet[m] has quit IRC 09:10:10 *** ciet[m] has joined #openttd 09:12:54 *** jeeg[m] has quit IRC 09:13:09 *** jeeg[m] has joined #openttd 10:14:56 <DorpsGek> [OpenTTD/actions] TrueBrain opened pull request #35: Add: support building dockers for other platforms besides linux/amd64 https://github.com/OpenTTD/actions/pull/35 10:15:11 <TrueBrain> hopefully that is not breaking existing workflows, but it shouldn't :P 10:16:06 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #35: Add: [docker-build] support building for other platforms besides linux/amd64 https://github.com/OpenTTD/actions/pull/35 10:21:30 <TrueBrain> now who dares to approve that PR? :P 10:29:08 *** andythenorth has quit IRC 10:36:03 <nielsm> trying to detangle the movement code for ships, which I'd think was about the simplest, and it's already plenty confusing 10:36:05 *** OsteHovel_ has joined #openttd 10:36:36 <nielsm> it seemed like the easiest place to start, since ships have nearly no dependencies on what other vehicles do, only when exiting depots actually 10:40:42 <TrueBrain> :( 10:41:23 <nielsm> and by detangle I mean strictly split the "decdide what to do" from the "actually do it" 10:41:54 <reldred> what are you thinking with boats? 10:42:17 <nielsm> https://github.com/OpenTTD/OpenTTD/blob/master/src/ship_cmd.cpp#L683-L685 10:42:36 <nielsm> like just those three lines: check if an action is possible, decide to take it and modify the current state, and then also update the GUI 10:43:08 *** OsteHovel has quit IRC 10:44:08 <nielsm> and then after that, do some more checks for more possible variations of the action, and maybe jump down to the reversing logic 10:44:40 <nielsm> reldred: I'm exploring an idea for parallelising (multithreading) part of the vehicle movement code 10:45:00 <reldred> Ahh nice 10:45:28 <reldred> so we can yell at people who cry about openttd not being multithreaded? :) 10:45:37 <nielsm> the idea is that if the logic to decide what to do can be split from the logic that actually modifies the game state, then the parts deciding what to do can be run multithreaded, and hopefully that can move most of the heavy calculations to parallel processing 10:46:16 <nielsm> in other words, while all vehicles are deciding what to do, none of them modify the world state 10:50:57 <reldred> Neat 10:55:15 <SpComb^> are boats the only vehicles that can do that while remaining deterministic enough for multiplayer? 10:55:32 <nielsm> no, all vehicles should be able to do that 10:55:47 <nielsm> but ships should be easiest to do it with for the first experiment 10:55:58 <SpComb^> isn't there some kind of ordering dependence if two vehicles conflict on exactly the same tick? 10:56:03 <nielsm> yes 10:57:06 <nielsm> I'm splitting the Vehicle::Tick() function into PrepareTick() and ExecuteTick(), such that PrepareTick() must fill in a "plan", and ExecuteTick() must attempt to execute that plan, if it's still possible to do 10:57:33 <nielsm> if ExecutePlan() can't execute the plan because something conflicts, then it returns a "retry" state, and the vehicle gets put back in queue 10:57:59 <nielsm> the PrepareTick() function is run in parallel, but the ExecuteTick() is run in serial (deterministic order) 10:59:23 <_dp_> Tile loop may be another simple target to multithread as tiles are mostly self-contained 10:59:30 <nielsm> yes 10:59:38 <nielsm> that's an entirely separate project 11:00:37 <nielsm> although a thread pool/work queue of sorts is needed for either, and could probably be shared code 11:03:12 <Rubidium> tiles are mostly selfcontained... until it comes to flooding, where they conflict with vehicles. Though growing trees of "greening" bare land should be self-contained 11:04:03 <nielsm> yeah for tiles you'd need to collect all the tiles that need to be serially processed in a list and do those afterwards, or something 11:04:21 <nielsm> I think town building tiles also produce cargo in their tick function 11:04:34 <Rubidium> yes, they do... NewGRF callback 11:05:04 <nielsm> and growing trees check the surrounding tiles for their land/tree status, iirc 11:05:40 <Rubidium> industry tiles produce cargo as well 11:05:41 <_dp_> Rubidium, isn't vehicle just destroyed when it's flooded? that creates no conflict since there is no need to be concerned about that vehicle 11:06:11 <_dp_> well, I guess it may conflict with pathfinder but not in the tile loop itself 11:06:30 *** christoph[m]12 has quit IRC 11:06:32 *** christoph[m]12 has joined #openttd 11:06:35 <Rubidium> unless one your computer it hasn't left the to-be-flooded tile yet, and on my computer it has left it (vice versa for entering) 11:06:49 <nielsm> the order the tile loop processes tiles in, could that cause tiles "close enough to matter for tree growth" to be processed in the same tick? I think maybe they won't? 11:07:22 <nielsm> Rubidium: in that case you already have a desync before the tile loop 11:08:03 <nielsm> running the tile loop in parallel with anything other than itself would be a recipe for disaster 11:09:25 <Rubidium> the tile loop is pseudo random, so no guarantees about locality 11:10:15 <_dp_> but that pseudo random is like 1 sequence for the entire game, if not for all games 11:10:18 <nielsm> nah, it's not really random, it uses some specific ordering that guarantees each tile is processed exactly one every 256 ticks 11:10:31 <_dp_> may be possible to make sure it doesn't iterate local 11:11:03 <_dp_> also it applies to chunks of tiles so it may be non-local simply because of those chunks 11:11:21 <_dp_> and even if it's not it can be easily changed 11:11:56 <_dp_> just split into 16x16 chunks and only loop one tile per tick 11:12:01 <_dp_> may already work that way 11:14:37 <nielsm> if I go into the scenario editor on a blank, flat map, and clear 32x32 tiles from the north corner of the map, it looks like that regrows to grass one tile per tick 11:16:32 *** frosch123 has joined #openttd 11:17:52 <_dp_> hm, looks like it's different sequence for each chunk rn... 11:18:32 <_dp_> whatever, even if it's totally random can split into like 8x8 and never tick neighbouring chunks at the same time 11:19:38 <nielsm> the tree growth is one of the major reasons you'd want to parallelise tile ticks, so making sure there won't be conflicts in that is central 11:20:22 <_dp_> well, 8 tiles of distance should be enough to isolate tree growth as I understand it 11:20:35 <Rubidium> trees "only" affect the tiles directly around them (just like water) as far as I can see 11:21:24 <_dp_> btw, flooding is also quite time-consuming 11:21:57 <_dp_> empty 4k water map takes like 10ms each frame just doing "flooding" 11:22:13 <nielsm> oh right, I always forget, the other major reason trees are problematic, maybe even bigger reason: they add a ton of noise to the save game data, making it compress poorly 11:22:21 <_dp_> though that should be possible to optimize even without mt xD 11:22:29 <Rubidium> just revert https://github.com/OpenTTD/OpenTTD/commit/6f9668330e198a8100aabdc09f612a48887c5c07 for the tree growth and flooding issue 11:23:30 <Rubidium> and maybe tweak it a bit, so there is some more distance between the tiles in the same tick 11:23:46 <_dp_> Rubidium, with 8x8 chunks no need to revert it, just tweak a little 11:23:50 *** pothyurf[m] has quit IRC 11:23:58 *** pothyurf[m] has joined #openttd 11:24:17 <nielsm> right, if the tile loop uses the same order for every 256x256 chunk of map, then you could also just put each 256x256 chunk into a job queue for threading 11:24:47 <nielsm> so original size or smaller maps would not multithread, though long maps like 64x1024 would 11:25:42 <Rubidium> not necessarily... is the northern, southern, eastern and western point are "randomly" chosen to be in that iterations set of tiles without a chunck, you still have a big problem 11:28:23 <Rubidium> so you need to split it in for example 64x64 chunks and then group them by their location in a 128x128 block. First run all the northern chunks, then all the southern, etc. That way you can prevent any issues between them 11:28:34 <Rubidium> though it complicates your code a bit 11:29:03 <nielsm> hmm... anyone know the pathfinders enough to know if they are idempotent or they may alter the vehicle state in some cases? 11:30:09 <frosch123> is the tileloop really worth optimising? it's resource usage is pretty much constant during a game 11:30:25 <frosch123> so you already know at game start whether your computer can handle it, or whether you should use a more reasonably sized map 11:30:29 <_dp_> why 64? that's exactly what I said with 8x8, 4 8x8 make 16x16, one tile is iterated per chunk, loop 8x8 sub-chunks is same order every tick, 8x8 can have random order inside 11:30:39 <frosch123> vehicle usage otoh grows during a game 11:30:45 <_dp_> that guarantees at lest 8 tiles of distance between every tile in same tick 11:32:46 <_dp_> frosch123, on large maps it kinda is. it may be static but if takes 1/3 of the frame that's 50% less stuff you can add 11:32:54 <frosch123> nielsm: the pathfinders do not directly change the vehicles, but ofc they cause the vehicles to reverse or pick tracks. the other way around: signal states, track reservations and station slot reservations affect the pathfinders 11:32:54 <_dp_> also it's a relatively easy target 11:32:58 <Rubidium> frosch123: tile loop as well... more industries, more houses, more trees 11:34:04 <frosch123> i accept "more houses". industries are suposed to mostly stay constant. trees are meant to be constant, but probably aren't :) 11:34:23 *** WormnestAndroid has quit IRC 11:34:36 *** WormnestAndroid has joined #openttd 11:35:18 <_dp_> hmm... do newgrfs have callbacks that work in a tile loop? 11:35:19 <frosch123> _dp_: i would think tileloop is the hardest thing to change, because there are so many different things in it 11:35:28 <frosch123> vehicles are pretty homogenous ni comparision 11:35:41 <frosch123> _dp_: yes, tons 11:35:43 <_dp_> not that may and they are all very localized 11:35:59 <_dp_> though newgrfs would complicate that a lot 11:36:03 <Rubidium> frosch123: if you don't use industries they'll roughly stay constant, as there are ones that close. If you use the industries they are significantly less likely to close. So only new industries pop up 11:37:02 <frosch123> Rubidium: iirc there is some "desired amount of industries" in the industry code. they do not open unlimited 11:37:22 <_dp_> yeah, code tries to keep industry density the same 11:37:51 <nielsm> frosch123: as long as the pathfinders can be called as much as I want without affecting world state, I'm fine 11:37:53 <Rubidium> then I must have been spawning a lot of oil rigs in my last serious game ;) 11:38:07 <frosch123> _dp_: the tileloop contains all the animation callbacks, which modify animation state and can also read animations state from other tiles 11:38:12 <michi_cc> YAPF does global caching though to get speed. 11:38:23 <_dp_> oil rigs spawn is pretty much broken 11:38:28 <nielsm> oh... so YAPF is troublesome there 11:38:40 <nielsm> gah 11:38:59 <frosch123> yes, i also expect that running pathfinders in parallel does not really work. the caches would need locking, and that would probably kill the performance 11:39:17 <michi_cc> The cache itself it supposed to be idempotent. If a different processing order results in a different cache contents, it's a bug. Still would need locking of course. 11:39:25 <_dp_> frosch123, if it can't read further than 8 tiles it's not a problem 11:40:00 <Rubidium> pathfinders do not seem to change the state of their vehicles; at least it's all const "Vehicle" * in there (except for CountShipProc. I haven't checked for things that get rid of the constness 11:40:25 <frosch123> _dp_: it may be that 4x4 houses affect exactly 9 tiles :p 11:40:29 <frosch123> 9x9 tiles 11:40:38 <nielsm> yeah updating the path cache would need locking 11:40:41 <_dp_> well 9x9 is also doable 11:40:43 <frosch123> and 2x2 houses :/ oof 11:41:06 <michi_cc> Path cache would need some read/write locking. 11:41:17 <_dp_> I'm more worried about related objects, that can easily get into trouble especially with perm storage 11:41:40 <frosch123> nielsm: on the plus side, track reservations and signal states are not part of the pf cache (afaik) 11:41:45 <michi_cc> If you don't cache, you don't need to bother with MT performance either :) 11:42:22 <frosch123> _dp_: good point, the animation callback can change the town storage 11:43:41 <frosch123> so yes, from a newgrf pov: parallel drawing yes, parallel vehicle acceleration yes, parallel tileloop hell no 11:44:23 *** Thedarkb1-T60 has joined #openttd 11:44:25 <michi_cc> Put perm storage writes into a queue to be executed in order afterwards? 11:44:40 *** Thedarkb-T60 has quit IRC 11:44:44 <_dp_> well, hell no in like 1% of cases 11:44:50 <_dp_> if not less 11:44:56 <_dp_> though detecting that would be a pita 11:44:59 <frosch123> michi_cc: newgrf would need memory intrinsics for locking then :p 11:45:05 <michi_cc> With the queue an overlay during the current CB chain to simulate instant writes. 11:45:10 <Rubidium> TileLoop chunking is not going to work... the HOUSE_DESTRUCTION callback is ran from the tile loop, any other house VA can get the nearest house matching some criteria... so the house getting destroyed changes that 11:45:11 <frosch123> imagine a animation callback incrementing a town register 11:46:27 <nielsm> frosch123 good, my idea is that track reservations go into the "plan", and during serial execution of the plans, if a train's planned new reservation will clash with another that was just taken, the train goes back to the "retry" queue 11:46:31 <_dp_> well, there is always an option to lock for callbacks ;) 11:46:41 <Rubidium> town register is still "local"-ish, destroing the last house of a type is global 11:46:59 <michi_cc> Just define NewGRF to have ARM-like memory order, not x86-like order :p 11:47:00 <frosch123> _dp_: locking is not good enough. you also have to sequence them deterministically 11:47:04 <frosch123> otherwise you will desync 11:47:13 <_dp_> goddamit 11:47:22 <_dp_> yeah, well, there is always an option of that... 11:48:12 <_dp_> loop callback tiles separately basically 11:50:31 <michi_cc> nielsm: This would occasionally result in different train routing from the current state if reservations/signals outside the direct next path segment would change the decision. Might result in more blocked trains in high-throughput scenarios (i.e. balancer style things), but as players can't reliably enforce pathfinding order anyway, you can probably just say "eh what" to it. 11:52:23 <_dp_> actually, even without callbacks TileLoop_Town will need some tweaking as it changes town state 11:53:51 <_dp_> if not full rewrite... 11:54:18 <DorpsGek> [OpenTTD/actions] TrueBrain merged pull request #35: Add: [docker-build] support building for other platforms besides linux/amd64 https://github.com/OpenTTD/actions/pull/35 11:55:31 <DorpsGek> [OpenTTD/actions] TrueBrain created new tag: v2.2.0 https://github.com/OpenTTD/actions/releases/tag/v2.2.0 11:57:10 <nielsm> michi_cc: yeah I know it will result in different behaviour for things, that's just a "deal with it" thing 11:57:38 <nielsm> now, can VehicleEnterTileProc implementations alter state... like do any tiles do funny stuff when a vehicle touches them? 11:59:49 <nielsm> VehicleEnter_Track certainly alters the vehicle state 12:00:04 <nielsm> (for trains entering/leaving depot) 12:11:27 <nielsm> and ditto entering bridge tiles 12:11:41 <TrueBrain> owh ... despite smoke-tests working fine .. I forgot that buildx images have to be pushed immediately, as otherwise they are lost in the void .. ugh .. I need to rethink my GitHub Actions workflow :P 12:20:40 <DorpsGek> [OpenTTD/actions] TrueBrain opened pull request #36: Revert: [docker-build] support building for other platforms besides linux/amd64 https://github.com/OpenTTD/actions/pull/36 12:21:43 <DorpsGek> [OpenTTD/actions] TrueBrain merged pull request #36: Revert: [docker-build] support building for other platforms besides linux/amd64 https://github.com/OpenTTD/actions/pull/36 12:59:20 <nielsm> https://github.com/OpenTTD/OpenTTD/commit/0ba58f25a46e3ccf3cba777d922c94f2f73b542b 12:59:45 <nielsm> I wonder if this ugly, ugly workaround is still really needed, now that ships need to arrive at a docking tile belonging to the station. presumably stations without docks won't have docking tiles either 13:14:05 <nielsm> yeah if a station doesn't have dock facility, the orders list will show "(Can't use station)" in red, and the order gets skipped immediately the dock facility goes away 13:19:23 <frosch123> doesn't look like sf issues still exist :) 13:21:30 *** Alkel_U3 has quit IRC 13:22:50 *** Alkel_U3 has joined #openttd 13:24:45 <TrueBrain> and where we did port FlySpray bugs, I do not think we ported sf issues over :P 13:25:25 <frosch123> that diff is weird... had_vehicle_of_type is only used for the first-vehicle-arrives-news 13:25:35 <frosch123> so using it in the order code is super weird 13:27:31 *** andythenorth has joined #openttd 13:28:19 <frosch123> hmm, looks like it was used in the past to distinguish buoys from docks 13:29:45 <frosch123> ah, i have a theory: if a buoy was deleted and turned into a grey sign, a ship would have seen it as "not a buoy" and start unloading 13:29:56 <TrueBrain> lol 13:30:29 <frosch123> nielsm: i think that fix was about arriving at deleted-but-still-grey-sign buoys 13:31:23 *** Gustavo6046 has joined #openttd 13:31:36 <nielsm> https://github.com/OpenTTD/OpenTTD/commit/2ab5eee78b495ec73049c8446a0ed37ab4ff0920 13:33:49 <frosch123> it todays code the deleted-buoy case would hit the OT_GOTO_WAYPOINT case 10 lines up 13:33:52 <nielsm> yeah, buoy orders are now waypoint orders, so you can't have a "go to buoy" order anyway 13:33:59 <frosch123> so i think the FACIL_DOCK thing is no longer needed there 13:34:33 <nielsm> ships do still head for deleted buoys until the sign disappears, but they skip to next order once getting within the 3 tile distance 13:35:11 <frosch123> i assume deleted-buoy/waypoint-signs cannot be turned into real stations :) 13:36:08 <nielsm> looks like no 13:36:12 <andythenorth> hmm who was doing newgrf docks? 13:36:31 <nielsm> if I build a buoy, bomb it, then build a docks where it was, the buoy sign remains and the dock gets its own sign 13:43:25 <_dp_> wonder how well will multithreading work in mp 13:43:41 <_dp_> if server is too good it kinda falls apart once slower clients start dropping 13:43:59 <_dp_> and slower clients probably have less cores 13:44:06 <nielsm> yeah... I'd probably put a client setting for max threads to use 13:44:33 <nielsm> ("client" setting, also applicable to servers, but not a game setting) 13:45:16 <nielsm> also so if you run multiple servers on the same hardware, you can prevent them from all trying to use all the threads 13:48:52 <_dp_> yeah, also I'm kinda afraid of mt support making it less performant per thread 13:49:12 <nielsm> it probably will yes 13:49:13 <_dp_> so with multiple servers it will need better hardware to run the ssame 13:51:52 <_dp_> though maybe ppl will stop spamming those useless servers :p 14:03:08 <_dp_> on the other hand, mt should be better at spreading the load across servers 14:15:03 *** glx has joined #openttd 14:15:03 *** ChanServ sets mode: +v glx 14:21:33 <peter1138> Oops, I did a ride, and then I did a (bit of) cake. 14:27:47 <nielsm> https://github.com/OpenTTD/OpenTTD/blob/master/src/ship_cmd.cpp#L409-L432 14:28:08 <nielsm> am I reading right that the ShipAccelerate function returns false if the ship does not have enough "accumulated movement" to actually move in the world? 14:28:36 <nielsm> or just false if the ship is at zero speed for some reason? 14:28:44 <andythenorth> @peter1138 can't do newgrf docks on a bike :P 14:29:05 <andythenorth> where will these ships dock eh? :P https://media.discordapp.net/attachments/337701432230805505/942000144814051348/unknown.png?width=2592&height=696 14:29:41 <nielsm> Vehicle::progress is the "sub-pixel" movement? 14:32:48 <peter1138> Yeah 14:33:10 <peter1138> andythenorth, nice, all hand drawn or algorithmic? 14:35:17 <andythenorth> hand drawn, but with compositing 14:36:14 *** AlbertSteve[m] has joined #openttd 14:41:57 <frosch123> nielsm: yes, progress is increase every tick. when it wraps around the vehicle moves a world coordinate 14:42:06 <frosch123> however, sometimes "progress" is just reset back to zero 14:42:15 <frosch123> so it's not really monotonous 14:44:56 <nielsm> https://github.com/OpenTTD/OpenTTD/compare/master...nielsmh:parallellvehticks 14:45:18 <nielsm> pushed a WIP code dump here, just if anyone cares to look how I'm trying to structure it 15:25:07 *** andythenorth has quit IRC 15:31:25 *** glx is now known as Guest192 15:31:25 *** glx_ has joined #openttd 15:31:25 *** ChanServ sets mode: +v glx_ 15:31:26 *** glx_ is now known as glx 15:32:49 *** andythenorth has joined #openttd 15:33:33 *** Guest192 has quit IRC 15:36:39 *** Smedles has quit IRC 15:36:49 *** Smedles has joined #openttd 15:37:27 <peter1138> I remember I once split ticks into vehicle types and it was faster for me, but slower for others... 15:48:02 <nielsm> it's probably situational 15:49:48 <nielsm> I've been thinking it might overall be better for performance and memory usage to have separate pools for each vehicle type, doing large block allocations for in-place construction, but that could be troublesome for the VehicleID management 15:57:31 *** jottyfan has quit IRC 16:12:01 <nielsm> hmm, implicit orders are a bit troublesome here, if two vehicles sharing orders arrive at a station at the same tick, and maybe both want to add an implicit order, or maybe one wants to add and the other wants to remove, what happens then 16:18:53 <frosch123> pool item creation must be sequenced deterministically, so can't really parallelise that 16:22:34 <nielsm> how is it handled currently when vehicle A reaches a new station that turns into an implicit order, and vehicle B sharing orders with A is on a later order index, does vehicle A then insert the new implicit order and update the current_implicit_order_index on all vehicles sharing orders? 16:25:50 <nielsm> hmm... I guess maybe the planning part doesn't really need to handle orders, it just needs to figure out what the new destination is, if any 16:26:08 <nielsm> so walk but don't modify (or plan to modify) the orders list 16:36:19 <FLHerne> just remove implicit orders from the game :p 16:36:34 <FLHerne> all they do is confuse newbies and break CargoDist 16:36:58 <nielsm> more like, they were added because cargodist needs them for the capacity planning 16:37:16 <FLHerne> well, I mean remove implicit stops in general 16:37:27 <FLHerne> I'm sure the SRNW people will be sad 16:40:14 <_dp_> remove cargodist while at it :p 17:26:47 <Eddi|zuHause> the only way to sensibly remove implicit stops is to make all orders non-stop 17:29:45 <Eddi|zuHause> there could certainly be improvements in handling implicit orders, but i never really played with them, or my networks were always too "sane" 17:44:20 *** Wormnest has joined #openttd 17:49:47 <andythenorth> cargodist considered harmful? 17:50:07 <TrueBrain> isn't any aspect of OpenTTD considered harmful at some point in time? 17:52:59 *** Flygon has quit IRC 18:09:44 <nielsm> https://github.com/OpenTTD/OpenTTD/blob/master/src/vehicle_base.h#L334-L337 <-- shouldn't it be possible to make this an anonymous union instead, and make access to the two alternate fields read a little better? 18:10:10 <nielsm> union { OrderList *orders; Order *old_orders; }; 18:10:24 <nielsm> afaik they then just appear right in the enclosing namespace (i.e. the class) 18:11:47 <frosch123> is there a reason it's a union? does the savegames do pointer magic that relies on them being on the same address? 18:15:11 <nielsm> I don't think so 18:16:22 <TrueBrain> the conversion code reads really weird because of the union :P 18:16:33 <nielsm> but I suppose saving those 8 bytes of memory per vehicle for something only used by a tiny minority of players, very rarely, for less than a second at a time, makes some sense 18:16:36 <TrueBrain> BuT iT sAvEs A pOiNtEr 18:17:10 <TrueBrain> but, you can always read the old value in a global value, as many other conversions do 18:18:04 <TrueBrain> currently the orders are fixed in an afterload function, which already loaded all vehicles 18:18:08 <nielsm> I think it fills all the vehicle structures and then fixes up the orders, not loads one vehicle then fixes its orders 18:18:15 <TrueBrain> but I guess you can fix it up per vehicle too; we do that on many other places :) 18:18:20 <nielsm> I think all vehicles+orders need to be loaded before it's possible 18:18:42 <nielsm> since it probably has to do with shared orders resolution and such 18:18:50 <TrueBrain> v->AddToShared(v->orders.list->GetFirstSharedVehicle()); 18:18:53 <TrueBrain> that is a nag 18:23:10 <nielsm> orders.old is referenced in total 5 lines 18:31:15 <DorpsGek> [OpenTTD/OpenTTD] nielsmh opened pull request #9816: Codechange: Use anonymous union for vehicle orders/old orders list https://github.com/OpenTTD/OpenTTD/pull/9816 19:28:17 *** jottyfan has joined #openttd 19:59:38 *** andythenorth has quit IRC 20:04:08 *** andythenorth has joined #openttd 20:44:04 *** snail_UES_ has joined #openttd 21:15:42 *** jottyfan has quit IRC 21:50:58 *** snail_UES_ has quit IRC 22:11:07 *** frosch123 has quit IRC 22:35:43 *** sla_ro|master has quit IRC 23:17:48 *** nielsm has quit IRC 23:23:13 *** snail_UES_ has joined #openttd 23:27:44 *** andythenorth has quit IRC