IRC logs for #openttd on OFTC at 2024-02-17
โด go to previous day
00:25:07 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
02:10:33 *** _pruple has quit IRC (Quit: User went offline on Discord a while ago)
02:33:32 *** flabanged has joined #openttd
02:47:19 *** Wormnest has quit IRC (Quit: Leaving)
02:56:22 *** flabanged has quit IRC (Quit: Page closed)
03:09:05 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:12:00 *** gnu_jj_ has joined #openttd
03:15:10 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:18:53 *** greeter has quit IRC (resistance.oftc.net synthon.oftc.net)
03:19:46 *** greeter has joined #openttd
03:27:46 *** greeter has quit IRC (resistance.oftc.net synthon.oftc.net)
03:28:29 *** greeter has joined #openttd
04:06:35 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:17:07 *** greeter has quit IRC (coherence.oftc.net synthon.oftc.net)
04:21:21 *** greeter has joined #openttd
05:02:08 *** ChanServ sets mode: +v Rubidium
05:02:08 *** ChanServ sets mode: +o orudge
05:04:21 *** misterbungus has joined #openttd
07:57:04 *** HerzogDeXtEr has joined #openttd
08:34:53 <locosage> O(log(n)) is a kinda weird argument when bitmap is O(n) :p
08:35:44 <locosage> though bitmap can be implemented in O(log(n)) too I guess
08:58:07 <_zephyris> So, anything I need to do for the dev diary?
08:59:09 <truebrain> change to date to today, and let's publish it!
08:59:16 <Rubidium> locosage: it's about the priority queue being penalised for the number of free pool elements. For the bitmap there is no performance hit to push/pop on the number of elements that are free. For the priority queue there is a O(log(size-of-free-elements)) behaviour for push/pop
08:59:24 <truebrain> did you assign who is going to be next _zephyris ? (didn't read your latest)
09:00:30 <locosage> Rubidium: but bitmap is penalized for the number of elements in the queue which is arguably even worse
09:01:21 <_zephyris> truebrain: Yup! "Next week, weโll see how pathfinding has been improved for one of the transport types. And, oh buoy, is it a big improvement"
09:01:32 <truebrain> okay, that is a good one ๐
09:03:14 <_zephyris> Well, it's good in EN-GB ๐
09:08:31 <Rubidium> locosage: it's the penalised for the length of allocated elements, not the complete pool size. And I'm not saying the priority queue is worse there, I've said that the bitmap is significantly better there. It was purely about weighing the options, their strengths and weaknesses. In the end it's more about the actual performance stats than the theoretical "what is this algorithm going to do with a
09:08:37 <Rubidium> quadrillion elements".
09:11:37 <locosage> that's why I said theoretical complexity argument is kinda weird there as it's even worse for bitmap
09:11:48 <locosage> bitmap is a pure technical solution with the same complexity as before
09:12:26 <locosage> also, I do wonder how you measured that performance to realiably see a difference between two ;)
09:21:13 <truebrain> minor nitpick, sorry about that ๐
09:22:21 <Rubidium> another minor? nitpick
09:28:46 *** misterbungus has quit IRC (Quit: Logging off...)
09:29:07 *** misterbungus has joined #openttd
09:43:06 <truebrain> published on website
09:44:38 <andythenorth> so....what's the hardest problem in computer science these days?
09:44:43 <truebrain> done Discord; I leave the other platforms for others
09:44:43 <andythenorth> is it still "naming things"?
09:47:06 <locosage> P ?= NP begs to differ
09:48:27 <andythenorth> it's probably either "naming things" or "organising src directory"
09:48:34 <andythenorth> one being related to the other ๐
09:54:45 <emperorjake> I'm enjoying these dev blogs just as much as the Factorio ones, keep up the good work ๐
10:03:25 <andythenorth> they are great ๐
10:04:50 <andythenorth> "when the docs act as automated tests for the grf"
10:05:00 <andythenorth> _busy busy refactoring Horse compile"
10:05:31 <andythenorth> if the docs are correct, the grf is _probably_ correct
10:16:21 <locosage> as well as one a dozen lines below
10:18:30 <locosage> ah, nvm, it's double case
10:19:37 <locosage> trying to remember c++ again xD
10:29:58 <georgevb> Whom can I ask for more synbols?
10:30:25 <brickblock19280> _zephyris: but I thought they would all have been made
10:42:02 <reldred> OK, so, Iโve mentioned this before in passing, but given two back to back blog posts have gone out showing OpenGFX2 it should probably be made the default base set in new steam installs.
10:42:15 <_zephyris> brickblock19280: They should be,what characters are missing?
10:44:07 <_zephyris> reldred: It needs more beta testing really... I haven't had time to organise a real testing push.
10:44:54 <reldred> _zephyris: Nah itโs fine donโt worry about it ๐
10:45:54 <reldred> (and other things said moments before disaster)
10:53:56 <michi_cc[d]> Made a reddit dev diary post.
11:11:03 <_zephyris> michi_cc[d]: Tt forums done!
11:11:04 <_zephyris> georgevb: I can add more, but I need to know what they are!
11:16:05 <_zephyris> Rubidium: Oh, missed this, thanks!
11:23:30 <andythenorth> I still need to manually manage action 2 IDs for nml?
11:23:38 <andythenorth> we found no way to raise the limit? ๐
11:24:08 <andythenorth> going to run out again soon, 231 / 256 used ๐
11:25:12 <andythenorth> alternately, I could call Horse "done" and stop adding ever more...stuff
11:25:56 <andythenorth> the upside of varact2 procedures is that the compile is much faster; I suspect the downside is that they rapidly consume concurrent action 2 IDs?
11:26:30 <_jgr_> Increasing the limit means changing the bitstream format, which is awkward form a compatibility point of view
12:20:14 <locosage> Precision of conversion to palette depending on number of bits cut off from components (2-8): 0.062 0.063 0.064 0.068 0.082 0.127 0.234
12:20:20 <locosage> unless I screwed my math somewhere xD
12:22:42 <locosage> so, basically, cutting off 4 bits hardly makes any difference
12:33:55 <locosage> how to remove lower 4 bits from every byte of a value in a few operations?
12:34:02 <locosage> i.e 0xf5a0b1 -> 0xfab
12:35:37 <locosage> aside from the obvious way ofc
12:49:53 <_glx_> andythenorth: Yup, they block an ID for their lifetime
12:50:59 <andythenorth> I think it's a sign that Iron Horse grf might be done soon
12:51:18 <andythenorth> only 25 concurrent IDs left
12:51:50 <andythenorth> couple more randomised wagon types, couple more procedures, IDs are all consumed
12:52:16 <jfs> locosage: in native code or in GRF?
12:53:59 <_jgr_> andythenorth: You've got procedures which only contain only a single instruction in your GRFs
12:54:01 <jfs> res = ((tmp >> 4) & 0xff) | ((tmp >> 12) & 0xff00)
12:54:28 <andythenorth> _jgr_: do you have a way to find them?
12:54:30 <Rubidium> though isn't that the obvious way?
12:54:32 <andythenorth> other than reading src? ๐
12:54:40 <jfs> but if you are on native code, SIMD instructions will tend to have ways to shuffle bits around like that in a single instruction
12:56:09 <_jgr_> andythenorth: Not in a systematic way, I just notice these things when looking at GRF performance issues
12:56:43 <locosage> jfs: yeah, already figured that, and I only need 24bit so it's even simpler
12:57:52 <andythenorth> _jgr_: Thereโs probably a reasonโฆor not ๐
12:58:00 <locosage> also found _pext_u32 which is kinda overkill here
12:58:28 <_jgr_> andythenorth: The really obvious one is STORE_PERM_ALT which is all over FIRS
12:58:39 <Rubidium> jfs: godbolt says it doesn't, even with -O3 -march=x86-64-v4
13:02:16 <Rubidium> locosage: it's the fewest instructions, though I would've hoped the compiler would come up with such an optimisation
13:04:47 <_jgr_> Relatively fancy instructions are not necessarily any faster than a short linear sequence of simple instructions
13:23:03 <andythenorth> _jgr_: Ha think that one is possibly just because I donโt like the nml syntax for STORE_PERM ๐
13:35:54 <_jgr_> Nice result, that's an instruction I'd never come across before
13:40:11 <locosage> I tried to arrange them with multiplication but failed to figure out constant
13:41:43 <frosch123> 2 of 10 commenters on steam want to keep the sprite font. i did not expect so many old people on steam
13:42:36 <truebrain> some comments are just hilarious too .. `Make it more SteamDeck friendly` .. we never asked it to be on SteamDeck in the first place!
13:42:44 <Rubidium> though I think the benchmark does not use Zen1/2, as those use 18/19 instructions instead of 1 due to the way they are implemented in which case pext will likely be slower... which might be the reason compilers are not injecting them by default
13:52:16 <locosage> Rubidium: and pext itself is less than 20% of total time
14:28:01 <truebrain> out of the dark, into the light!
14:29:45 <truebrain> and that should fix the CI too ..
14:30:09 <truebrain> going to merge it now, so it is easier for others to improve ๐
14:33:53 <xarick> How do I test all cases of OrderFlags?
14:51:35 *** keikoz has quit IRC (Ping timeout: 480 seconds)
14:53:16 <truebrain> you did misunderstood one sentence, and now made it even weirder; but I can fix that ๐
14:53:49 <truebrain> no, it shows my sentence was already crappy ๐
14:57:08 <truebrain> it is not about Steam etc being installed; it is about whether it is running ๐
14:57:26 <truebrain> (their restrictions btw; not ours)
15:17:01 <locosage> accidentally crashed an industry xD
15:19:03 <andythenorth> Achievement unlocked
15:21:04 <frosch123> new hovercraft upgrade available?
15:22:50 <_glx_> so after more testing, `sq_setparamscheck` with negative nparamscheck doesn't work very well for default params (using a very basic implementation)
15:23:01 <_glx_> guess it should be possible with more work
15:28:04 <andythenorth> frosch123: Hover Industrie?
15:28:31 <_glx_> but too much work, we only have one function using default param
15:30:19 <xarick> redundant code, says visual studio
15:44:55 <kuhnovic> truebrain: Nice blog post, I really enjoyed reading it. Shall I add a teaser to the end of my post?
15:45:06 <kuhnovic> Assuming your post goes next
15:45:10 <truebrain> up to you who you pick next ๐
15:45:36 <kuhnovic> I choose you (not pikachu)
15:48:36 <truebrain> and there is the other post I promised
15:48:57 <truebrain> I am expecting two more, one from michi_cc[d] and one from talltyler
15:49:19 <truebrain> and I think that is all we can expect?
15:49:26 <truebrain> maybe someone surprises us ๐
15:54:00 <xarick> talltyler: did you forgot DA_SERVICE, or was it fixed later?
16:00:45 <_glx_> xarick: it's already fixed
16:03:47 <xarick> I disagree with `ResetDepotUnbunching`in `Vehicle::HandlePathfindingResult`
16:04:05 <xarick> are notorious in triggering ship is lost
16:14:22 <xarick> okay, I got a general feeling about the inyards of unbunch feature
16:14:53 <xarick> those hyper managing AIs might not benefit much from unbunching
16:15:21 <xarick> constantly adding vehicles, removing vehicles, etc...
16:15:46 <xarick> but some less active AIs might do well with it
16:24:55 <_glx_> Unbunch support for AI is not done anyway
16:29:25 <jfs> unbunching is basically just a robot helper for the player that will stop vehicles in depot and start them again after a period, so an AI player could do the same thing on its own too
16:31:47 <frosch123> i guess rondje kind of did ๐
16:35:41 <xarick> I'm gonna try implement the feature
16:37:01 <xarick> oh, right... vehicle status
16:37:08 <xarick> was anything added there?
16:45:17 *** Wormnest has joined #openttd
17:08:51 *** Flygon has quit IRC (Remote host closed the connection)
17:09:38 *** Wormnest has quit IRC (Quit: Leaving)
17:09:46 *** Wormnest has joined #openttd
17:11:36 <_glx_> another translator failed the test
18:06:10 <xarick> I can add both Full load and full load any as an AI
18:08:39 <xarick> oh it's fine in the end, it becomes full load any
18:19:39 <xarick> intermediate orders with shared orders is a mess
18:22:12 <xarick> one bus goes from A, C, the other goes from C, A. An intermediate order is added for first bus at B between A and C, but for the other bus, B is added as D between C and A. The order list displays 2, 3, 4 orders, depending on who last arrived at the intermediate station
18:22:48 <xarick> it's not a fixed list, is what I say, it's constantly changing
18:23:20 <xarick> sometimes it's A C, sometimes A B C, sometimes A C D, sometimes A B C D
18:25:37 <xarick> funny, sometimes the order can spawn before A
18:27:09 <_zephyris> That's when it's after B
18:28:48 <xarick> does unbunch work for implicit orders? gonna check
18:31:22 <xarick> probably works, but it's gonna skew the averages
18:33:02 <xarick> poor thought out feature
18:35:12 <DorpsGek> - Update: Translations from eints (by translators)
18:36:11 <peter1138[d]> xarick: Implicit orders? yes.
18:37:19 <peter1138[d]> Very head wind on the south-bound legs.
18:37:50 <xarick> okay it works, it might as well not work
18:37:54 <peter1138[d]> Felt more than 9.6km/h for sure.
18:38:15 <xarick> deleting implicit order triggers reset unbunching
18:38:35 <peter1138[d]> It isn't intended to work for all possible combinations of orders.
18:40:48 <xarick> I was hoping that it could at least try to get an average, but oh well
18:40:59 <xarick> doesn't even get the chance
18:41:15 <peter1138[d]> An average is no use.
18:43:05 <xarick> just added a fast bus to make it even more broken
18:43:37 <xarick> alright, so this feature only catters a few specific game style
18:44:28 <_jgr_> It caters to players building sensible routes?
18:44:58 <_jgr_> If your vehicles or their orders don't make any sense there is not a lot that the game can do for you
18:45:59 <_glx_> always use "non-stop" for orders
18:46:09 <_glx_> implicit orders are just broken
18:46:28 <peter1138[d]> One potential way to make mix-speed vehicles work is to limit the speed of vehicles to the slowest.
18:47:05 <peter1138[d]> Not ideal, but who knows
18:49:56 <xarick> it implies the route doesn't change
18:50:09 <andythenorth> what shall we change today?
18:50:18 <peter1138[d]> Xarick's routes, apparently.
18:52:13 <frosch123> andythenorth: there are two slots left for the weekly blog. maybe you want to write about the micro transactions?
18:52:16 <peter1138[d]> andythenorth: More cargo icons?
18:58:13 <andythenorth> frosch123: saving myself for the coin miner
19:00:05 <xarick> lol, changing near end of platform, start of platform, triggers unbunch reset
19:12:29 <peter1138[d]> That does, technically, affect the round trip time.
19:12:41 <peter1138[d]> Just not much ๐
19:20:23 <_zephyris> ... cursor support for rail/roadtypes is a nightmare.
19:23:07 <peter1138[d]> "auto cursor composition"
19:23:14 <peter1138[d]> (is not a thing)
19:25:32 <_zephyris> A simple cursor + track/depot/tunnel icon would get you quite a long way there
19:25:44 <_zephyris> eccentric original graphics cursors aside
19:47:00 <kuhnovic> Sorry Tyler, you have to review it again ๐
19:49:06 <xarick> maybe add a debug message
19:49:22 <kuhnovic> Ah no-fix-but-still-made-it-better
19:50:00 <kuhnovic> What would the debug message add?
19:50:35 <xarick> unexpected patch with no water as origin, I think
19:51:08 *** michi_cc has joined #openttd
19:51:08 *** ChanServ sets mode: +v michi_cc
19:51:27 <xarick> or unhandled case of patch with no water
19:51:31 <kuhnovic> That part has been fixed, it will no longer add those as origins. And the neigbor search will bail out when it gets an invalid region.
19:52:04 <kuhnovic> So the part that you wanted fixed is fixed actually. But that particular savegame is still acting strange, but it turns out that the issue is somewhere else.
19:52:42 <kuhnovic> So maybe I did fix the issue ๐ค ? Oh well, details!
19:53:22 <xarick> for me it's that darned DestinationID
19:54:21 <xarick> there would be a solution if we could deduce the type of order that assigned that DestinationID
19:55:01 <kuhnovic> I'm quite certain that it's the conditional order
19:56:06 <xarick> DestinationID should be a std::pair
19:56:45 <xarick> paired with order type, one couldn't live without the other
19:57:45 <xarick> so when the ship processes orders, (OT_LEAVING), and don't update the destination, it is still possible to know which type of order has assigned that destination.
20:01:11 <kuhnovic> Changing that is probably going to be hell. The ship controller code is so convoluted...
20:03:35 <xarick> conditional order, what it did was to point back to order 1
20:04:03 <xarick> it's the OT_LEAVING that's doing the mess
20:04:19 <xarick> it's leaving the dock to return to it again
20:05:02 <kuhnovic> Exactly. And I put back the old YAPF ship pathfinder code (before regions), and it does the exact same thing
20:08:33 <xarick> i actually think the destination was updated, now that I think about it
20:08:42 <xarick> it updated to the same
20:09:23 <xarick> I wonder if it's possible to remove the OT_LEAVING step
20:09:53 <xarick> what comes after it, is hopefully OT_GOTO_STATION
20:12:27 <xarick> A GetEffectiveOrderType for yapf
20:13:11 <_glx_> pathfinder doesn't care about the order
20:13:41 <kuhnovic> The ship pathfinder does actually care
20:13:46 <xarick> it cares, how else would it get docking tiles
20:14:30 <_glx_> docking tiles are infered from destination
20:14:34 <kuhnovic> It's either "go to this single tile" or "add all the docking tiles as potential destinations"
20:15:11 <_glx_> but it's not really the order itself
20:15:35 <_glx_> yeah only current order
20:15:46 <_glx_> not what order can be next
20:17:53 <kuhnovic> But this specific edge case calls the PF with OT_LEAVING as the current order type, but it's destination is actually a dock. So the wrong part of the if is executed.
20:18:18 <debdog> missed it's birthday for three days
20:18:27 <_glx_> blame the controller then ๐
20:19:08 <xarick> well, that's how I use orders on my AI
20:19:16 <xarick> prevents vehicles going empty
20:19:55 <_glx_> controller is responsible for PF calls, and it should not call it here
20:20:11 <_glx_> as it leaves for the same exact location
20:22:12 <xarick> but every vehicle does that, they leave only to return to it
20:22:32 <xarick> maybe except trains, which can reverse at the station and stop immediately
20:23:09 <_jgr_> OT_LEAVESTATION has the ID of the station which is being left, not the next destination
20:23:18 <andythenorth> my macOS zip worked on bananas ๐
20:23:32 <andythenorth> going to switch my makefile from tar to zip
20:24:18 <_jgr_> It's not useful to pathfind to the station which is being left
20:24:35 <andythenorth> seems the Horse makefile already had some zip support from somewhere ๐
20:24:42 <andythenorth> flags are `-9rq`, wonder what that does
20:24:56 <xarick> sounds like JGR found a solution
20:24:58 <andythenorth> zip manual is huge ๐
20:25:32 <kuhnovic> JGR only provided a clue. But he's right.
20:26:01 <andythenorth> GPT says -9rq is max compression, recursive, quiet
20:26:31 <_jgr_> The source suggests otherwise
20:27:06 <wensimehrp> rubidium42viaGitHub: ๐
20:29:29 <peter1138[d]> Now what else did I need to do to fix bankruptcy taking ages...
20:33:08 <_glx_> I guess it's a full map loop
20:33:45 <_glx_> with stat updated for each tile
20:34:21 <_jgr_> I'm guessing it's more the very long delay while each company is offered a chance to buy the company
20:34:35 <_jgr_> Even if the company has no attached client
20:35:03 <_glx_> I think he's talking about stop_ai command (same effect as bankruptcy)
20:35:51 <_glx_> it's the final step of bankruptcy, the actual removal of things
20:36:18 <xarick> it's when removing stations it looks over all vehicles per removed station
20:36:38 <xarick> sometimes I came across when I was working with GroupVehicleList
20:36:48 <_glx_> but vehicles are removed before the stations I hope
20:36:59 <xarick> they are, but 14 other companies exist
20:38:32 <_jgr_> As in RemoveOrderFromAllVehicles?
20:38:38 <_jgr_> That does look expensive
20:40:14 <_glx_> yeah a full vehicle loop per station seems too much
20:40:20 <peter1138[d]> Yes, I've already replaced that with a call to the newer vehiclelist function that lists vehicles by orders ๐
20:40:43 <_glx_> makes more sense to uses orders indeed
20:41:00 <wensimehrp> whoops... openttd just crashed
20:41:27 <_glx_> openttd crashes are bad
20:46:01 <wensimehrp> seems like to be something related to AI
20:48:02 <peter1138[d]> Integer divide byu
20:50:34 <_glx_> crashed inside IME it seems
20:50:45 <_glx_> but can't get any info from the dump
20:53:00 <peter1138[d]> There is no useful information in that screenshot ๐
20:53:42 <wensimehrp> just to show that this is reproducible?๐ค
20:54:07 <peter1138[d]> That doesn't need a screenshot ๐
20:57:08 <xarick> "reason": "EXCEPTION_INT_DIVIDE_BY_ZERO"
20:57:44 <xarick> AAAHog.Ex tried to divide by zero?
20:59:56 <_glx_> dump says the crash was in sogouPY.ime
21:00:20 <_glx_> AIs can't crash the game
21:00:35 <wensimehrp> quite popular Chinese ime
21:01:32 <_glx_> crash screenshot looks weird
21:03:23 <wensimehrp> I was testing the new currency format with Small Man
21:09:54 <Rubidium> I must've messed up in one of the many many refactors :(
21:10:07 <peter1138[d]> You were just testing us ๐
21:10:45 <_glx_> it's a 64x64 map and the AI just started
21:10:46 * Rubidium is happy nobody approved #12101 yet
21:11:23 <peter1138[d]> _glx_: What's your opcode limit?
21:12:20 <xarick> what is the log saying?
21:12:29 <_glx_> mind it's a debug build, but still
21:14:25 <xarick> but does it say what's doing?
21:14:26 <peter1138[d]> Hmm, that's a bit better in Xarick's 4kx4k save.
21:15:48 <xarick> those road veh ticks are great!
21:17:22 <xarick> Used ops means savegame was issued
21:17:35 <xarick> the rest seems normal, i don't think that code is that expensive
21:17:37 <_glx_> my guess is the new list constructors
21:18:00 <peter1138[d]> slow pool bitmap? :p
21:18:45 <_glx_> constructors with optional filters use Pool::Iterate
21:18:45 <xarick> it's searching for towns, then it's comparing tiles in a town to find a spot with best cargo production, and acceptance
21:19:12 <_glx_> but they were using Iterate before too
21:19:31 <peter1138[d]> Yeah, I was joking, sorry ๐
21:19:47 <_glx_> but it's a 64x64 map, it shouldn't be that CPU consuming
21:19:50 <peter1138[d]> Btw, to "fix" Xarick's save I made a single character change.
21:20:01 <peter1138[d]> 10 points if you can guess what.
21:20:39 <peter1138[d]> _glx_: just 1 AI?
21:21:34 <wensimehrp> found an issue with the new number format... Units aren't used correctly.
21:21:34 <wensimehrp> I think I can fix that
21:22:12 <peter1138[d]> `const int HASH_BITS = 7;` to `const int HASH_BITS = 8;`
21:22:35 <xarick> whatever that is, nice
21:22:36 <peter1138[d]> So 128x128 tile hash to 256x256 tile hash. But that means it uses 512KB instead of 128KB.
21:23:06 <peter1138[d]> It's the hash for looking up vehicles on a tile.
21:23:23 <peter1138[d]> With a 4kx4k map there can be a lot of overlaps in the hash.
21:24:15 <xarick> 200 ms to 9 ms, worth it
21:24:20 <peter1138[d]> JGR's strategy of splitting the tile hash by vehicle tile would also help here, because it's about 80 rail vehicles and 5 road vehicles. And we're only looking for road vehicles.
21:24:35 <_glx_> the only time ms goes lower than 10 I think it's when it's issuing commands
21:24:44 <peter1138[d]> I think the 7 was chosen before 4kx4k maps existed.
21:25:17 <peter1138[d]> _glx_: make a release build and compare. debug is not very useful for performance issues.
21:25:18 *** daredemo has quit IRC (Quit: User went offline on Discord a while ago)
21:26:50 <xarick> oh, i have more than 1 sleep it seems
21:27:28 <_glx_> anyway it's not mandatory to do things every tick
21:28:39 <_glx_> some of your sleeps could be longer than 1 tick (depending on what actions were just finished)
21:29:22 <xarick> eh, I find myself limited by opcodes all the time
21:29:40 <_glx_> means you try to do too much ๐
21:29:59 <xarick> with many vehicles, i just can't manage to check them all in 1 year
21:30:12 <peter1138[d]> What needs to be checked?
21:30:40 <xarick> profits, age, expand stations, replace, renew
21:30:59 <xarick> also checking many vehicles, etc...
21:31:02 <peter1138[d]> Hmm, renew is automatic.
21:31:16 <peter1138[d]> Replace only need to work on engine types, not vehicles.
21:31:25 <xarick> checking whether i get too many vehicles in a route, they end up stalling
21:31:44 <_glx_> ok release build is better ๐
21:31:48 <peter1138[d]> Calculate route capacity better :p
21:32:01 <xarick> in terms of optimizations
21:32:22 <peter1138[d]> Somewhat better, yes.
21:32:55 <_glx_> but usually debug builds are "usable"
21:33:26 <_glx_> oh no I know, I had a conditional breakpoint
21:33:36 <_glx_> let's retry debug without it
21:33:53 <xarick> can you check the cpu profile thingy? I wanna see what functions the AI calling
21:34:47 <wensimehrp> > I want to change the language definition (plural form, genders, cases) of a translation.
21:34:47 <wensimehrp> > Please create an issue for this.
21:34:47 <wensimehrp> Shall I create a PR for this?
21:34:50 <_glx_> it was the conditional breakpoint
21:36:57 <_glx_> conditional breakpoints are so expensive
21:37:24 *** rau117 has quit IRC (Quit: User went offline on Discord a while ago)
21:40:49 <wensimehrp> wensimehrp: Nah I'll just go for it
21:45:17 <peter1138[d]> wensimehrp: please don't cross out the checklist items, that's for reviewers to follow.
21:45:49 <wensimehrp> I thought this PR only touches the translation
21:49:35 *** APTX has quit IRC (Remote host closed the connection)
21:51:36 <_glx_> #12105 might be fixed by #12106 (it was a div/0 too with inexploitable trace)
21:52:31 <peter1138[d]> wensimehrp: Doesn't matter what the PR is, the checklist is for us ๐
21:52:59 <wensimehrp> Ah... I messed up everything
21:54:03 <_glx_> wensimehrp: does it still crash easily in new master ?
21:55:56 <wensimehrp> the problem is that I cannot build it on windows, I can only build it on linux for some reasons... and I don't have that sogou thingy installed on linux
21:55:56 <wensimehrp> I guess the only way to check out is to wait until tomorrow for the nightly version
21:56:13 <peter1138[d]> /* When not converting rail <-> el. rail, any vehicle cannot be in tunnel/bridge */
21:56:28 <peter1138[d]> This is CmdConvertRoad() ๐
21:56:49 <_glx_> too much copy paste for NRT ?
21:58:36 <peter1138[d]> Hmm, is there a proper way to convert TransportType to VehicleType...
21:59:10 <peter1138[d]> I see `static_cast<VehicleType>(this->transport_type)` used at least once.
22:03:41 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:04:42 <peter1138[d]> Hmm, splitting the tile hash per vehicle type has the same memory effect as increasing the tile hash size one bit.
22:04:56 <peter1138[d]> Performance wise... not sure, probably not as beneficial.
22:05:22 <peter1138[d]> (hash collisions will still be high for a particular vehicle type)
22:05:52 <frosch123> TransportType is rarely used, maybe it could be replaced with VehicleType
22:06:06 <frosch123> i don't think there is a way to derive enums ๐
22:06:21 <frosch123> `enum VehicleType : TransportType` does not work
22:06:52 <wensimehrp> WenSimEHRPviaGitHub: I'll figure it out
22:13:19 <_glx_> TransportType is mostly used by PF I think
22:14:45 <frosch123> it's used by map accessors and functions
22:15:04 <frosch123> the rest of the game cares more about vehicles
22:15:41 <_glx_> PF, bridge and tunnels it seems
22:16:10 <frosch123> we need depots for ufos
22:16:46 <_glx_> ` if (IsDepotTypeTile(tile, (TransportType)(uint)v->type) && IsTileOwner(tile, _local_company)) {` orders just go lazy ๐
22:17:50 <xarick> _local_company ? wow isn't that cheating
22:18:33 <xarick> is that from yapf or npf?
22:19:23 <peter1138[d]> Hmm, what transport type can an industry be built on...
22:19:35 <peter1138[d]> I'm thinking only water./
22:19:56 <_glx_> it's from the GUI when you use "go to" button
22:20:32 <xarick> not a shortcut to getting the owner of vehicle
22:26:37 <peter1138[d]> Can industries build over rail or road tiles? I wouldn't think so but I'm not sure.
22:28:17 <andythenorth> I've never seen it happen ๐
22:28:35 <andythenorth> I tend to have magic bulldozer enabled a lot also
22:28:53 <andythenorth> so that _probably_ doesn't cause it either
22:29:23 <wensimehrp> This... looks so werid
22:30:03 <peter1138[d]> The sprite, or the number?
22:30:13 <wensimehrp> number format changed in sprite window
22:30:24 <peter1138[d]> number format changed
22:30:30 <frosch123> peter1138[d]: they can probably DC_AUTO remove half roads, why do you ask?
22:31:39 <peter1138[d]> Trying to naively split tile hash by vehicle type, and that means EnsureNoVehicleOnGround requires a vehicle type passing to it.
22:31:55 <peter1138[d]> CheckIfIndustryTilesAreFree() checks for no vehicle on the ground.
22:32:05 <peter1138[d]> Which implies it can clear transport types.
22:32:13 <peter1138[d]> Half-tile roads maybe be feasible here.
22:32:30 <peter1138[d]> I can just check all vehicle types though, just inc ase.
22:33:23 <frosch123> crashed aircraft after running out of fuel due to no airports existing ๐
22:33:38 <peter1138[d]> Is that a thing... ๐ฎ
22:33:57 <frosch123> you can launch aircraft into air, and then remove all airports
22:34:06 <frosch123> watch them fly for a while, and then crash
22:34:32 <frosch123> i guess the submarine diaster also blocks water tiles, but is no ship
22:35:12 <andythenorth> hover submarine?
22:37:18 <xarick> I tried to add a full load order to a vehicle with unbunch in the order list. I'd like the GetLastError to be something more intelligble
22:38:35 <xarick> ERR_UNKNOWN should be... STR_ERROR_UNBUNCHING_NO_FULL_LOAD translated to script api language
22:40:04 <xarick> there's also error category, which I have absolutely no idea it was a thing
22:43:04 <peter1138[d]> Hmm, seems like just increasing the hash size is simpler, less error prone and more effective.
22:43:12 <frosch123> the alternative may be to add disaster vehicles to all vehicle-type hashes
22:43:35 <frosch123> though crashed aircraft remain weird
22:43:56 <peter1138[d]> Can crashed aircraft "land" on rail or road tiles...
22:44:27 <xarick> don't they remain in the virtual tile xy?
22:47:28 <frosch123> hmm, they actually do not fall onto the ground properly
22:48:11 <_glx_> xarick: just look at ScriptOrder::ErrorMessages
22:48:31 <_glx_> the comments format is important
22:50:20 <_glx_> there's space for 256 errors per category
22:50:29 <frosch123> they just hover above the ground
22:50:39 <frosch123> they do not block building/removing rails
22:50:44 <frosch123> and trains can pass through the plane
22:52:13 <_glx_> crashed planes still flying ?
22:53:04 <frosch123> it jumps around a bit in the crash animation
22:53:11 <frosch123> so probably broken for years ๐
22:53:34 <_glx_> guess it would be hard to mark plane presence on the 4 affected tiles (based on the shadow)
22:54:24 <_glx_> most likely never touched since r1
22:55:40 <frosch123> there is even a distinct news message ๐
22:56:21 <frosch123> i wonder how many players know it compared to how many know there is a distinct endgame screen when reaching 1000 points
22:58:09 <xarick> is * @exception required?
22:58:16 <xarick> * @exception ScriptError::ERR_OWNED_BY_ANOTHER_COMPANY
22:58:23 <xarick> in the function description
22:59:54 <xarick> is there actual code running behind that, or is it just a comment
23:00:29 <_glx_> it's just a comment so you now which error you might receive
23:00:29 <peter1138[d]> It's called "documentation"
23:06:30 <frosch123> oh, wow, it's actually not in original TTD?
23:07:38 <_glx_> I guess it all comes from the original crash on the too short airport runway
23:07:57 <_glx_> where aircraft is actually already on ground
23:08:16 <_glx_> but for the fuel crash there's nothing moving it to ground
23:08:49 <frosch123> isn't that at line 930 in the diff?
23:11:00 <peter1138[d]> So I accidentally unearthed an old bug...
23:11:37 <frosch123> the code still exists, no idea why it does not work
23:11:44 <_glx_> ` v->crashed_counter += 3;` and later in the function ` if (v->crashed_counter < 500 && st == nullptr && ((v->crashed_counter % 3) == 0) ) {`
23:12:46 <frosch123> oh, that limits how deep it can fall
23:13:14 <frosch123> if it is flying higher, it won't reach ground
23:13:28 <_glx_> that's not much with the 255 height
23:13:31 <xarick> 1โฌ = 200$482 is all I remember
23:14:01 <frosch123> i guess flying altitude was changed a few times
23:14:12 <frosch123> even for different flying speeds
23:15:04 <_glx_> altitude changes with ground height, but I don't remember the differential
23:16:58 <xarick> how much was 1โฌ in ยฃ in the year the euro was introduced, 2000?
23:17:55 <xarick> dang, I got distracted again
23:18:12 <_glx_> they kept ยฃ so it doesn't matter ๐
23:20:39 <xarick> $00, and $50 was typical at the time
23:21:25 <xarick> openttd doesn't support fractional currency?
23:21:54 <xarick> like 1 dollar 30 cents
23:22:25 <xarick> I thought Money had something about fraction
23:23:26 <_glx_> EURGBP average exchange rates
23:23:59 <_glx_> so 2โฌ for 1ยฃ feels correct due to the game limitations
23:24:21 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:26:28 <peter1138[d]> โฌ1 for ยฃ1 is closer these days ๐ฎ
23:27:57 <xarick> his 400 figure is way off imo but ok
23:33:24 <peter1138[d]> That Game loop total is missing something...
23:34:08 <peter1138[d]> Possibly unaccounted wagon aging.
23:36:07 <peter1138[d]> Oh, it's not aging that's unaccounted. Hmm.
23:38:35 <xarick> does that still have disaster and effect vehicles enabled?
23:39:58 *** jcteotonio has joined #openttd
23:39:58 <jcteotonio> xarick: I picked the value so that the conversion is correct during game-play (when the players enter 2002), not really the pound rate at the time. That was the mindset.
23:41:34 <_glx_> similar to the 2โฌ for 1ยฃ
23:42:45 <_glx_> so 400 for 1ยฃ (200 * 2 for 1ยฃ) feels right
23:43:20 <xarick> how did the other currencies make the conversion?
23:44:13 *** ChanServ sets mode: +v tokai
23:50:05 <xarick> well, the game would transit escudo to euro in 2002, but still... the currency conversion should derive from the pound. Are there guidelines about how to do this conversion?
23:50:13 <xarick> when introducing new currencies?
23:51:05 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:59:24 <peter1138[d]> The usual way is "just use a custom currency" :p
continue to next day โต