IRC logs for #openttd on OFTC at 2023-11-25
β΄ go to previous day
00:20:10 <_jgr_> The main intention was so that server operators could turn it on to prevent people accidentally creating a mess with implicit orders
00:31:48 <talltyler> _jgr_: Oh, nice. Upstreaming that. π
00:33:06 <_pruple> make it the default π
00:35:11 <_zephyris> ... but seems like building the baseset from source using make doesn't use grf container version 2
00:35:45 <peter1138> It doesn't need to use container version 2.
00:36:57 <_zephyris> Or how do I make container version 1 not ignore 32bpp sprites?
00:37:22 <_zephyris> (I realise these are noob grfcodec questions, never tried 32bpp in nfo before...)
00:37:27 <peter1138> Container version 1 does not support 32bpp.
00:37:37 <_zephyris> So it needs version 2 π
00:37:54 <_zephyris> Or is that not OK for orig_extra.grf for some reason?
00:37:56 <peter1138> Are you talking about the baseset included in OpenTTD?
00:38:01 <peter1138> Because that's always been 8bpp.
00:38:23 <_zephyris> It's also a good fix for #9031
00:39:01 <talltyler> _pruple: Oh yeah, it'll absolutely default to on
00:39:50 <peter1138> How does it fix #9031?
00:41:57 <peter1138> Some of us do actually like to use implicit orders.
00:43:44 <peter1138> So I'm seeing "I don't use it so let's pretend it doesn't exist" is a bit jarring.
00:43:45 <_zephyris> Adding shading to the water slopes, so you can actually see where slopes are...
00:44:20 <peter1138> Do they still animate?
00:44:52 <peter1138> Because... they can't really animate if you have to use non-animated-water pixels.
00:46:25 <_zephyris> It's this solution, but applied to the orig_extra.grf river slopes/rapids
00:51:51 <talltyler> This is the same argument as pre-signals π
00:52:23 <talltyler> If you want them and know how to use them, enable them
00:53:32 <talltyler> But I donβt want to argue about it tonight, thereβs still more work to do on the PR and we can argue then π
01:00:07 <_zephyris> Don't believe me? Try it π You'll get a baseset corrupted file of/c
01:08:08 <Eddi|zuHause> why exactly do we hate on implicit orders today?
01:08:36 <peter1138> andythenorth had some issue with cargodist which was blamed on implicit orders which are apparently just broken so we should just hide them.
01:10:30 <Eddi|zuHause> a) andy has lots of issues with cargodist (and other stuff) and b) why would implicit orders be the primary reason for those, and c) what exactly is "broken"?
01:13:10 <peter1138> _zephyris, so anyway, this feature is... uh... something I added... apparently. Hah.
01:13:26 <peter1138> But it doesn't work with the OpenGL blitter.
01:13:45 <_zephyris> Blitters are _well_ above my understanding...
01:13:49 <peter1138> Not sure if all the SSE blitters handle it either.
01:13:52 <Eddi|zuHause> the only real issue i heard about implicit orders is that sometimes it generates too many, if the trains take erratic routes (like visiting depots)
01:14:50 <peter1138> And I'm not really sure how it even works at all.
01:15:11 <peter1138> (Despite having added it)
01:15:22 <Eddi|zuHause> personally, i've switched to using non-stop orders loooong before implicit orders were introduced
01:17:59 <peter1138> Seems the SSE blitters do support it too.
01:18:21 <Eddi|zuHause> and in my experience, people blaming implicit orders as the cause of an issue aren't realizing that the implicit orders are a symptom, and the real issue is at another level
01:19:39 <_zephyris> peter1138: You'll have to translate for a graphics-first kinda guy... So a 32bpp sprite with an 8bpp mask containing animated palette entries doesn't work (ie. doesn't change the brightness of the 8bpp pixels) for the OpenGL blitter?
01:20:32 <peter1138> That's either a bug in the OpenGL blitter (nobody realised it was meant to do that), or it isn't possible for some reason.
01:22:19 <_zephyris> How do I check my blitter? Windows/default blitter/hardware acceleration on.
01:22:36 <_zephyris> I'd have thought that was OpenGL...
01:22:48 <peter1138> Check for "blitter =" in your openttd.cfg
01:24:06 <Eddi|zuHause> there's probably some "-d blahblub" option for blitters
01:24:45 <peter1138> There is but I'm not sure it works properly depending on the HW acceleration setting.
01:25:31 <peter1138> Anyway, the main reason the OpenGL blitter exists is because it does the palette animation differently so the CPU doesn't have to do anything.
01:25:42 <peter1138> And therefore it is totally different, and I don't know how it works.
01:27:50 <_zephyris> `openttd.exe -h` lists `40bpp-anim: 40bpp Animation Blitter (OpenGL)`... Running with `openttd.exe -b 40bpp-anim` and the shading of animated pixel values works...
01:28:21 <peter1138> Maybe I have one set :D
01:29:36 <_zephyris> (don't judge me for running OpenTTD from Dropbox... I have my reasons.)
01:32:28 <_zephyris> I've only managed to break it with, as expected, `8bpp-simple` and `8bpp-optimized`
01:33:56 <peter1138> My 13.4/master install isn't using the same baseset directory.
01:36:30 <peter1138> 12 years ago, I should've retired.
01:36:43 <peter1138> Anyway, 32bpp in the default baseset. Controversial for some reason.
01:39:56 <_zephyris> Violating the sanctity of the precious pixel bytes
01:40:24 <_zephyris> Well, it addresses the usability issue, so I'll make a PR tomorrow
01:40:54 <_zephyris> Then the debate can truly begin.
01:43:37 <Eddi|zuHause> depends if one of the about 12 violent opponents of 32bpp as a concept notices
01:44:21 <Eddi|zuHause> as for myself, if the art style stays in line with the original, it doesn't matter much
01:46:00 <peter1138> So, er, how to you tell grfcodec to use container v2?
01:46:11 <Eddi|zuHause> maybe it's time to deprecate 8bpp blitters, and convert everything to 32bpp internally
01:46:46 <Rubidium> peter1138: step #1 might be upgrading grfcodec
01:47:15 <Eddi|zuHause> i probably knew that once
01:47:35 <_zephyris> Err, should -g2 I think
01:48:01 <_zephyris> I found where to put it in the cmake script, then promptly forgot!
01:50:06 <_glx_> there's an issue with v2
01:50:12 <peter1138> Rubidium, I would assume the most recent master version is new enough...
01:50:16 <_glx_> md5sum calculation won't work
01:50:55 <Rubidium> (primarily because the -h of grfcodec does tell you how to, so assuming you checked that the most logical reason for asking is that the help doesn't tell and then grfcodec is too old)
01:51:23 <peter1138> No, I'm just blind as useful.
01:52:02 <michi_cc[d]> _glx_: No idea what baseset obg actually checks, but `grfid` was made exactly to cope with the data-section only hash.
01:52:03 <peter1138> And also I wasn't sure if it was something that's set within the nfo.
01:52:23 <peter1138> GRFID 6.0.6-51-g97337da - Copyright (C) 2009 by Peter Nelson
01:52:45 <michi_cc[d]> `grfid -m` for the hash
01:53:47 <_glx_> but baseset.cmake uses `file(MD5 ${BASESET_EXTRAGRF_FILE} ORIG_EXTRA_GRF_MD5)`
01:54:12 <_glx_> because grfcodec is not mandatory
01:54:29 <Eddi|zuHause> i just vaguely remembered it being "-[some letter] 2" but couldn't figure out which letter. my first instinct however would have been "p", but that didn't make much sense
01:55:14 <Eddi|zuHause> and i couldn't be bothered to check
01:55:23 <_glx_> so md5 must be stored in a file next to the grf for obg generation
01:57:06 <Eddi|zuHause> _glx_: that reads like the makefile silently assumes container 1 grf, which is probably wrong
01:57:41 <peter1138> Why is it copyright me? Did I write that?
01:58:00 <_glx_> well we generate the grf so we know it's v1
01:59:32 <Eddi|zuHause> _glx_: but we're having this discussion because we're apparently in the process of switching to v2, and if someone knowledgable hadn't stepped up from the sidelines, we'd maybe never caught this
02:00:40 <peter1138> The original commit (by Rubidium) just displays the grfid. Hmm.
02:01:04 <peter1138> Does not have my name it in.
02:02:39 <peter1138> Okay, there's a grfid.c on my own web server.
02:02:51 <peter1138> But the hashing stuff wasn't me.
02:13:16 <peter1138> execute_process(COMMAND grfid -m ${BASESET_EXTRAGRF_FILE} OUTPUT_VARIABLE ORIG_EXTRA_GRF_MD5)
02:13:27 <peter1138> That works in Baseset.cmake.
02:13:36 <peter1138> But of course means that grfid/grfcodec is required to build.
02:15:09 <Eddi|zuHause> or we make grfid some integral part of the source, like strgen
02:15:43 <_glx_> another option would an extra script to pre-include the md5 in obg
02:16:12 <Eddi|zuHause> that would have been my other suggestion, but i didn't know how to phrase it
02:17:27 <_glx_> like parse the place holder, insert the md5 in it and write it back, so the normal obg script will have it
02:17:29 <Eddi|zuHause> have some kind of "core-obg" that is stored in the repo and updated on building the .grf, then add that into the autogeneration process during building
02:18:33 <Eddi|zuHause> but i think including grfid is a bit cleaner
02:19:28 <Eddi|zuHause> updating the md5 in the file after changing the grf seems too easy to forget
02:19:58 <Eddi|zuHause> i mean, who remembers that in 5 years?
02:20:31 <peter1138> Who even wrote grfid originally...
02:21:45 <Eddi|zuHause> well, it probably got your name on it for a reason?
02:37:16 <_glx_> hmm grfid crashes for me
02:54:51 <_glx_> nice it crashes on fclose
03:03:14 *** Wormnest has quit IRC (Quit: Leaving)
03:09:12 <_glx_> hmm might be the mmap/munmap implementation
03:15:40 *** Zathras has joined #openttd
03:19:04 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:19:09 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:43:43 *** Tirili has quit IRC (Quit: Leaving)
06:50:47 *** ChanServ sets mode: +v tokai
06:57:24 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:01:00 <andythenorth> So did we delete anything and ruin the game? π
07:44:29 *** HerzogDeXtEr has joined #openttd
07:45:55 <andythenorth> So how do I do pax without cdist @pruple?
07:46:43 <andythenorth> We used to before cdist, but I forgot the meta π
07:47:26 <andythenorth> Separate pickup / dropoff stations for transfers was it?
07:49:15 <_pruple> don't do transfers, usually π
07:50:31 <_pruple> just build a network like you usually would, and don't worry too much about the numbers π
07:51:49 <andythenorth> βPax just do one hop, donβt overthink itβ π
07:53:00 <_pruple> if you really want to transfer passengers from the middle of the city to intercity trains / airports you can, just accept that the transfer vehicles will [appear to?] be empty on the return trip.
07:53:26 <andythenorth> Yes but station walking also
07:53:55 <andythenorth> Station grf tile that looks like a bus
08:05:04 <andythenorth> ok goes it throw out cdist for pax and mail
08:05:10 <andythenorth> I'll need to adjust all my trains π
08:06:10 <andythenorth> cdist really is just broken isn't it π
08:06:31 <andythenorth> 260 + 388 does **not** give 1036
08:06:48 <emperorjake> Have you tried turning it off and on again
08:07:08 <andythenorth> and the + icon isn't being drawn here
08:08:12 <emperorjake> That is strange, I've never seen these things happen and I've been playing with cargodist on for many years
08:08:21 <andythenorth> it's never worked well for me
08:08:30 <andythenorth> I think players project what they want to see onto it
08:09:32 <emperorjake> Illusion or not, it works well enough for me π
08:15:42 <locosage> andythenorth: iirc it means the rest come from this station
08:16:30 <emperorjake> but it's set to via first, it should be showing where they want to stop next, not where they came from
08:17:15 <emperorjake> and usually it would show "nnn from this station" in green
08:17:51 <emperorjake> Like I said, I've never seen cargodist bug out like that
08:18:11 <locosage> why does it even say "from" if it via then?
08:21:57 <andythenorth> cdist has been turned off
08:22:05 <andythenorth> none of this makes any sense in that context
08:22:51 <andythenorth> I suspect this bug relates to the station having a dock
08:23:33 <andythenorth> there are 2 stations on the map where this broken behaviour is showing
08:23:44 <andythenorth> both combine rail station + dock
08:24:26 <andythenorth> Ivy Bridge and Zeals
08:24:35 <andythenorth> (grfs were posted in a zip last night)
08:25:16 <andythenorth> can also try turning cdist back on, and observing that it just isn't working, trains are leaving stations without loading cargo that claims to want to go to next hop, or a later hop
08:25:42 <andythenorth> hmm no, no dock here
08:28:58 <merni> andythenorth: Idk this seems to be a "you" problem :p
08:29:28 <merni> Works perfectly fine for me even at stations that combine dock+railway station+tram stop
08:30:44 <merni> Showing "from" in via-dest-source mode like that is really weird though
08:31:07 <merni> worth reporting if reproduceable
08:34:14 <emperorjake> I loaded the save, needed to fire up nightly because it wouldn't load in jgrpp
08:35:45 <emperorjake> it's hard to see what trains go where because the routes aren't drawn on the map
08:36:24 <merni> might have to re-enable it
08:36:49 <emperorjake> I am seeing the 1033 stuck passengers at Ivy Bridge
08:37:42 <peter1138> Uh... I missed my alarm :(
08:38:20 <emperorjake> Those passengers got stuck there because of the implicit orders presumably
08:39:10 <andythenorth> peter1138: Have coffee
08:41:52 <merni> There's no train that I can see that goes directly between Ivy Bridge and Red Lumb, so those pax *should* eventually despawn
08:42:08 <merni> I can't repro the "from" display though
08:42:16 <merni> emperorjake: and link graph shows for me
08:42:17 <andythenorth> 1. Why would there need to be?
08:42:35 <emperorjake> I've been fast forwarding this whole time and they still haven't despawned
08:42:38 <andythenorth> 2. Doesnβt despawn after 6 years ffwd
08:43:09 <peter1138> I was meant to be out on a ride :/
08:43:11 <merni> andythenorth: If pax want to go "via Red Lumb" what that means is they need a train whose next stop is at Red Lumb
08:43:21 <andythenorth> But cdistβ¦.is off
08:43:24 <merni> Despawning does seem to be bugged though
08:43:40 <emperorjake> The thing is, there used to be a train that went directly between Ivy Bridge and Red Lumb, in the old save before implicit orders were removed.
08:43:46 <peter1138> (Riding to coffee stop)
08:44:13 <andythenorth> It didnβt go directly, it had implicit order nodes π
08:44:30 <andythenorth> Those are still nodes in the graph
08:44:52 <merni> Yeah this seems to be something weird where implicit orders (which I don't think anyone uses with cdist as said previously)
08:44:53 <peter1138> So we've broken cdist basically.
08:45:08 <merni> andythenorth: I mean after turning it back on
08:45:26 <andythenorth> merni: Bold claim
08:45:49 <andythenorth> Cdist understands implicit orders as nodes in the graph
08:45:51 <merni> the fact that the pax don't move anywhere even with cdist off is even more weird lmao
08:46:13 <emperorjake> Implicit orders are just a warning that you forgot to enable non-stop. That's all they're good for
08:46:35 <andythenorth> They still create nodes and cdist provides edges
08:46:58 <andythenorth> Thatβs self evidently true just by observation
08:47:37 <emperorjake> True, the link graph looks fine even with implicit orders
08:48:27 <merni> Also I thought "Midhopestones" couldn't possibly be a real name but apparently it is lol
08:48:52 <peter1138> Yeah, it's not helpful to tell people they are playing wrong, just becuase you don't use a particular thing.
08:49:13 <peter1138> That's my trick with openttdcoop games ;)
08:49:30 <andythenorth> _If_ the linkgraph is lying, thatβs a thing we should maybe fixβ¦but Iβm not sure it is
08:51:27 <emperorjake> Strange, I reloaded the game and the passengers are no longer there, but the mail is bugged at the same station
08:51:46 <andythenorth> It seems inconsistent
08:51:50 <peter1138> Mine is loading but is always saying "via any station" and "to any station" in red, without any destinations.
08:51:58 <peter1138> So something seems broke.
08:52:24 <merni> Ah so the "from" display happens with cdist *off*... and one of the +s are hidden? Is that supposed to happen?
08:53:02 <merni> (I can still click on the mail and it displays
08:53:08 <andythenorth> There are two saves posted here btw
08:53:56 <andythenorth> One with cdist & implicit orders, one with implicit orders converted to explicit, but cdist later turned off
08:53:58 <merni> andythenorth: Yeah I can't imagine how that makes sense... wihtout cdist all pax are supposed ot be "from this station to any station"
08:54:34 <emperorjake> I fixed it by removing and rebuilding the station and fixing the orders of the trains
08:58:06 <merni> These orders seem weird, why does it go Huddersfield-Red Lumb in one direction and Red Lumb-Ivy Bridge in the other, without visiting Elstree on that run? It'd make more sense to me if Red Lumb was at the start of this
08:58:16 <merni> (And why Refit to Mail?)
08:59:31 <peter1138> Take 8,192 seconds.
08:59:37 <peter1138> That might be my issue...
09:00:00 <merni> And on fast forward the plus symbol in the station window keeps flashing in and out... even weirder
09:01:10 <andythenorth> merni: Probably just missed one when converting implicit to explicit
09:01:24 <andythenorth> Mail refit was originally the first order
09:02:16 <andythenorth> That order set is broken
09:02:21 <merni> Why are you refitting to mail without subsequently refitting to something else, though?
09:02:39 <andythenorth> The first order should always be a refit
09:03:58 <merni> hm I guess it makes sense when your "mail van" can carry things that aren't mail, but still seems easier to me to just refit when buying :p
09:04:19 <andythenorth> Play style differences
09:04:24 <peter1138> Okay finally after changing those numbers (8192 seconds lol) it's got destinations.
09:05:27 <andythenorth> ok so train 16 orders were borked, but trains 1, 2, and 9 run that route and were ok
09:06:47 <peter1138> Why does a mail man need to refit to mail as an order?
09:07:11 <andythenorth> has to be done for freight trains and for ships
09:07:27 <andythenorth> and if mail vans get replaced with containers at any point
09:07:34 <merni> Yeah even after de-borking the mail trains it doesn't fix itself
09:07:43 <emperorjake> It makes sense, I have repurposed trains in the past and forgot to refit them, this would prevent them from carrying the wrong thing
09:07:54 <emperorjake> but I don't make a habit of it
09:08:05 <andythenorth> I don't understand any other way to play
09:08:12 <merni> does autoreplace not take into account refitting in vanilla?
09:08:17 <andythenorth> do people refit cargo with the livery subtypes button?
09:08:31 <peter1138> People refit with the refit button.
09:08:35 <merni> Yes, it's called the refit cargo button
09:08:43 <peter1138> Or by selecting the cargo in the filter.
09:08:56 <merni> "Refit train to carry a different cargo type"
09:09:05 <andythenorth> peter1138: oh yeah that's the more leet way, I forgot about that one
09:09:40 <peter1138> Changing cargo type by the refit button is the intended purpose. Subtypes where hacked on to that later. It is not a "livery subtypes button"
09:10:29 <emperorjake> I usually use the filter in the purchase list, but sometimes I repurpose an old train to carry something different on another route
09:10:31 <peter1138> Anyway, because there's no other refit orders, I don't think that should be causing an issue.
09:10:52 <peter1138> I imagine auto-refit could cause confusion.
09:10:55 <andythenorth> I think it's unlikely that station refit order is the cause of "you're holding it wrong" π
09:11:09 <andythenorth> refit-any-available is a car crash with cdist
09:11:15 <andythenorth> never do it π
09:11:24 <peter1138> That's basically chicken & egg
09:12:03 <andythenorth> a vehicle arriving at a station with the 'wrong' existing refit can create edges in the linkgraph
09:12:31 <andythenorth> and then cargo gets dead-end transferred into other nodes
09:12:48 <andythenorth> and then that spreads virally π
09:13:13 <andythenorth> it's weird that cdist doesn't appear to look at acceptance, but eh
09:13:33 <peter1138[d]> It's also canon π
09:13:45 <andythenorth> There are no cannon in your cargos
09:13:51 <merni> cdist doesn't look at acceptance because you might want to transfer things at a station that doesn't accept it
09:13:55 <andythenorth> I thought war themes were discouraged?
09:14:21 <_pruple> merni: dist not dest, right? π
09:15:04 <merni> well yes because there is no modern version of openttd with cargodest :P
09:15:53 <merni> I would hope cdist doesn't spawn cargo *via* a dead-end station that doesn't accept it though
09:16:22 <andythenorth> that's a natural consequence of how it works
09:16:40 <merni> I guess those are railfans
09:16:48 <merni> just taking a trip up and down the line
09:18:04 <andythenorth> if there's a station with freight cargos 1, 2, 3 on it
09:18:35 <andythenorth> and a train with 'refit any available' is routed through it, already refitted to cargo 1
09:18:50 <andythenorth> it will load cargo 1, and take it A->B and unload it
09:19:01 <andythenorth> even if cargo 1 has no next hop from B to any destination
09:20:58 <andythenorth> the intent in that case would be more like 'take cargo 2 A->B' and there would be other vehicles routed 'cargo 1 A->C'
09:21:29 <andythenorth> it's user error to allow that case to arise, but eh
09:21:36 <andythenorth> it's easily done
09:21:53 <_jgr_> Refit any available is very literal about what available means
09:23:13 <andythenorth> the suitable cases to use it are very very limited
09:23:16 <_pruple> although it won't initiate service for a cargo that isn't already being transported from the station, which is nice. π
09:23:24 <emperorjake> Always make sure the cargo has been assigned a destination before you let it find its own way on a "refit any available" vehicle
09:23:39 <andythenorth> hmm dunno how you would do that π
09:23:53 <andythenorth> cdist always has to try and make some cargo available to new next hops
09:24:10 <locosage> _pruple: in the only case I used refit to available it would actually be helpful if it did
09:24:35 <emperorjake> I sometimes build a temporary road vehicle to trigger the cargo from spawning and direct it to the correct destination
09:24:43 <andythenorth> 'refit available' is suitable for e.g. farms, where grain + livestock both go to factory
09:24:51 <andythenorth> otherwise best avoided
09:24:55 <locosage> though it would be even simpler if station just had a button to start accepting stuff
09:25:08 <andythenorth> might be nice on JGRPP ships, with 4 holds, refittable pax or mail π
09:25:33 <andythenorth> locosage: sometimes I wonder if routes should be created between stations, not vehicles π
09:25:40 <andythenorth> like .... "the other game"
09:26:19 <locosage> nah, that would've made too much sense :p
09:27:11 <emperorjake> I use it all the time, like this
09:30:00 <andythenorth> how many other routes go through, e.g. Takagi Valley?
09:30:12 <andythenorth> for the cargos originating / transferring there?
09:31:49 <emperorjake> Takagi Valley is a major hub
09:32:08 <emperorjake> I just build trains and let the cargo find its own way
09:32:32 <emperorjake> sometimes it doesn't go the way I want it so I add exclusions to the trains orders (but that's a JGR thing)
09:32:44 <andythenorth> but you play JGRPP?
09:33:15 <andythenorth> I have formed the impression that JGRPP has multiple fixes to cdist that aren't in vanilla
09:33:24 <andythenorth> although I haven't read the changelog recently
09:33:35 <emperorjake> Yes, this is using cargodist with equal distribution, which makes it actually playable with freight
09:34:10 <peter1138> Oops, I missed the 9am ride as well.
09:34:24 <andythenorth> ok so, as sometimes happens, "it just works" coming from JGRPP players, is not very relevant to vanilla π
09:34:54 <andythenorth> although we do learn that one client might be better than the other in some circs
09:36:08 *** nairda00 has quit IRC (Quit: User went offline on Discord a while ago)
09:37:31 <andythenorth> anyone tried compiling YACD recently? π
09:40:05 <andythenorth> I did once attempt to learn how cdist *actually* works from fonso, not how it's thought to work based on people....guessing in chat channels π
09:40:21 <andythenorth> I never updated the wiki though....because TBH I didn't really understand and still don't
10:02:29 <peter1138> Hmm, where do we run strgen...
10:15:03 *** Zathras is now known as debdog
10:25:15 *** azubieta60822666 has quit IRC (Ping timeout: 480 seconds)
10:30:32 *** azubieta60822666 has joined #openttd
10:37:34 *** oftc is now known as Guest8085
10:40:00 *** Osai has quit IRC (Ping timeout: 480 seconds)
10:40:00 *** avdg has quit IRC (Ping timeout: 480 seconds)
10:41:30 *** orudge has quit IRC (Ping timeout: 480 seconds)
10:41:35 *** Westie has quit IRC (Ping timeout: 480 seconds)
10:41:55 *** Guest557 has quit IRC (Ping timeout: 480 seconds)
10:46:14 *** ^Spike^ has joined #openttd
10:46:43 *** ^Spike^ is now known as Guest8089
11:16:06 <locosage> planetmakerviaGitHub: maybe even right-align icons...
11:20:18 <peter1138> Hmm, container v2 openttd.grf / orig_extra.grf are larger than container v1.
11:20:48 <peter1138> 509868 -> 553738 bytes
11:20:57 <peter1138> 329463 -> 352267 bytes
11:22:11 <locosage> hm, that looks more than 8 or smth bytes per sprite coz of id
11:26:17 <peter1138> About 10% overhead.
11:27:05 <locosage> lol openttd.grf: Found 432(18%) duplicate sprites, 80206(17%) bytes total
11:28:44 <peter1138> The monospace font has a few duplicate blanks.
11:29:51 <locosage> hm, idk, I see how 20k overhead can appear but not 45
11:33:21 <peter1138> Okay, so on non-Linux it's looking for grfid in the wrong place.
11:34:17 <peter1138> Okay, grfcodec build-dependency? :p
11:34:36 <peter1138> At least it is green for the target I'm using lol
12:14:12 <locosage> hm, nfo specs says min life of house (prop 1F) is a word but game reads byte
12:14:52 <locosage> well, I guess there is no easy fix for the game anyway...
12:21:23 <_jgr_> NML thinks that it's a byte as well, so I'd be inclined to just take the error in the documentation as a typo
12:24:54 <_jgr_> The error was introduced in the 24 July 2011β re-formatting edit, I'll correct it
12:40:35 <_glx_> peter1138: In grfcodec repo it builds fine, but crashes at run
12:48:03 <_glx_> It's because mmap implementation, function does `fopen`, mmap does `fdopen` on the descriptor from function, mmap does `fclose` on fdopen result, function does `fclose` on fopen result which crashes as already closed
12:49:07 <_glx_> Removing any of the `fclose` delays to crash to the implicit `fcloseall` at exit
12:52:56 <_zephyris> peter1138: Just write the MD5 to a file when building the newgrf? And use that for making the obj when not using grfcodec?
13:13:56 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
14:15:28 *** gelignite has joined #openttd
14:16:42 <_glx_> oh you might want to PR the grfid changes in grfcodec repo too
14:17:04 <peter1138> _glx_, I'll consider it if it compiles and works on the other platforms :-)
14:17:45 <_glx_> anyway I'm not sure vendoring grfid is needed, I think it's possible to make it work without
14:22:37 <locosage> wonder if adding is_reversed property changeable via CB36 is a good idea
14:24:16 <locosage> may be helpful for implementing stuff like push-pull
14:24:25 <locosage> probably won't make it any less kludgy though
14:26:48 <locosage> CB36 is quite bad for initializing values though
14:27:33 <locosage> can actually use some parameter for the context
14:30:42 <brickblock19280> wouldn't it be is flipped tho?
14:31:10 <brickblock19280> reversed is different
14:31:37 <locosage> yeah, I guess flipped is the right word
14:31:41 <emperorjake> Flipped is for ctrl-flipping in depot
14:31:52 <emperorjake> Reversed is for when it turns around at a station
14:32:26 <brickblock19280> or on the line
14:33:00 <locosage> anyway, property naming is nml problem, in grf spec it's all numbers :P
14:34:23 <brickblock19280> I wouldn't mind the option to be able to flip dual ended and articulated engines if the grf allows it
14:35:13 <locosage> yeah, sometimes articulated parts are added simply for technical reasons
14:36:04 <locosage> flipping articulated engine would probably require moving parts around though
14:36:04 <brickblock19280> That seems slightly harder to do tho since you wouldn't easily tell which part you are flipping
14:36:24 <brickblock19280> that isn't what I was thinking but makes more sense
14:36:38 <brickblock19280> would the grf have to know about it tho?
14:36:59 <locosage> I think flipping it whole makes more sense for the used but is probably a technical nightmare
14:43:01 <andythenorth> Flipping articulated has been discussed a few times, but conclusion is usually that it requires complete redesign of ground vehicle
14:46:10 <locosage> well, at least adding a flag to allow flipping articulated parts individually should not be a problem
14:46:53 <locosage> maybe only allow only part to set that flag so any flipping goes to it
14:47:49 <brickblock19280> the problem with that it that it prevents the better option from being implemented in the future
14:49:19 <locosage> dunno, I won't say "prevents" but may complicate stuff a bit
14:50:55 <brickblock19280> fair enough it could use some other setting
15:05:00 *** gelignite has quit IRC (Quit: Stay safe!)
15:07:01 <peter1138> Okay so Linux still works :D
15:13:17 <peter1138> Hmm, seems to have built on MinGW but not run.
15:25:03 <peter1138> Even MacOS is successful, apparently.
15:26:03 <peter1138> Something different about paths on Emscripten and Windows.
15:30:40 *** virtualrandomnumber has joined #openttd
15:48:04 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
15:49:36 <talltyler> Progress update on NotDaylength: I need code reviews. π All the relevant PRs are in the 14.0 milestone, including draft PRs that aren't ready for review just yet because they depend on other things.
15:49:36 <talltyler> Most crucially, everything is waiting on #11468 and #11435, and the latter of those has a redrawing problem I can't figure out.
15:49:36 <talltyler> I don't think a Christmas beta1 release is possible anymore, but a lot of the work is already done, just needing reviewing and fixing and rebasing, so we're not far off. But I can't do it alone. π
15:54:23 <peter1138> Hmm, yeah, the temporary .md5 file is in my source tree, not the build tree. That's not right.
15:56:38 <peter1138> You do realise nobody actually uses the milestone features? :)
15:57:51 <merni> is that better ship pathfinder PR likely to get into 14.0?
16:05:25 <talltyler> All the releases I've been involved in (including back when I was just helping with changelogs and news posts) have used milestones. π
16:07:03 <_jgr_> I've been looking at Andy's save. The mail stuck in the station will never be re-routed because the re-routing should have be done when the associated flow was removed, but the flow is already gone
16:09:03 <_jgr_> The flow only existed temporarily because of the implicit orders, which suggests that one of the special-case flow removal paths is incorrect
16:11:12 <peter1138> talltyler, I'm not saying don't use it... just nobody is paying any attention to it, at least not before someone decides a release might be nice :)
16:12:43 <talltyler> Oh, yes. But as soon as the final PR for NotDaylength is merged, I'll make a beta1 changelog to start the process. π
16:13:41 <talltyler> (and will volunteer for the rest of the beta1 release process too, of course)
16:17:17 <talltyler> I almost put those conversion functions into `timer_game_calendar` or `timer_game_tick` but having either of those include the other introduced some nasty circular dependencies when I've previously done that
16:17:45 <talltyler> Moved them though, just waiting for the build π
16:24:17 <talltyler> merni: It needs stress-testing. Maybe we can do some sort of community multiplayer game to do this and see what happens, plus gather feedback. truebrain proposed this a while back. kuhnovic, what do you think?
16:24:57 <peter1138> I meant to review it but I think I either didn't or got lost.
16:26:35 <peter1138> There is also the thought some of the mechanisms might apply to other transport types (town road grids are quite painful for road vehicles, although we mitigated some of that with path caching.)
16:26:58 <talltyler> Mmm, or complex rail networks
16:27:11 <talltyler> Maybe a follow-up PR though
16:27:30 <peter1138> Depends if a follow-up PR would require it to all bit ripped out again :)
16:28:10 <peter1138> And yeah large rail networks where it is known that the pathfinder gives up trying to find the destination.
16:32:12 <peter1138> So many questions, Richard Scarry.
16:35:19 <talltyler> Apparently cannibalism is a real job that brings value to society
16:35:21 <peter1138> andythenorth, see, it's a bug.
16:35:23 <talltyler> That's not _my_ job though
16:36:06 <andythenorth> hmm mac clipboard is failign
16:36:31 <andythenorth> used to read that book a lot
16:36:38 <merni> Why is a train not on that cover smh
16:36:47 <andythenorth> train inside somewhere probs
16:37:43 <peter1138> Scarry-esque NewGRF?
16:38:44 <talltyler> That book was my childhood
16:38:58 <talltyler> OpenTTD is the closest thing to Richard Scarry's world I've seen in a video game
16:39:14 <talltyler> We have no proof that passengers are human and not pigs and rabbits and large cats
16:39:30 <talltyler> and the Livestock cargo jives nicely with that butcher drawing...
16:41:36 <talltyler> For lunch I have leftover Thanksgiving dinner that I took home, but I forgot to pack gravy π¦
16:42:02 <peter1138> Your gravy is probably different to ours though.
16:43:14 <talltyler> I have no meat drippings π€·
17:11:32 <peter1138> Sometimes I tick things through, sometimes I 'have opinions' :p
17:12:05 <talltyler> All good points, thanks π
17:24:18 *** Wormnest has joined #openttd
17:27:37 <peter1138> Oops, making something constexpr has broken things
17:29:23 <peter1138> Ah, something is uninitialized.
17:43:32 <andythenorth> Hmm some console command to clear specific cargo from a station?
17:45:34 <peter1138> I might have to rip apart my synthesizer set up.
17:45:46 <peter1138> Just because I can't find a power supply :o
17:55:28 <_glx_> and it will be in front of you once done
17:56:52 <peter1138> I found it. It was a black one after all, I'd been looking for a white one.
17:57:10 <peter1138> Now... where can I plug this in.
18:37:29 <DorpsGek> - Update: Translations from eints (by translators)
18:58:21 <peter1138> talltyler, so whether it is late is different depending on where you look?
19:01:13 <talltyler> Yes. In the overview it says how many ticks late the vehicle is, while in the arrival/departure board it shows the date in red if the vehicle is later than a day.
19:01:13 *** Hobbyboy|BNC has quit IRC (Read error: Connection reset by peer)
19:04:33 *** Hobbyboy has joined #openttd
19:07:18 <peter1138> It is a bit weird that whether it is late or not also depends on the units :)
19:07:34 <peter1138> But I guess "0 days late" would be weird.
19:07:45 <talltyler> Yeah, it has to be at least 1 unit
19:18:19 <talltyler> I should probably make that window timer run on ticks instead of seconds, but thatβs separate from the βnumbers are wrongβ issue. It does redraw every secondβ¦
19:31:03 <peter1138> Hmm, annoying, this variadic (or whatever it's called) template stuff doesn't allow me to have constructors with different number of parameters.
19:31:44 <peter1138> Hmm, maybe if I re-order them.
19:35:54 <peter1138> Yeah, that works :D
19:53:50 *** virtualrandomnumber has joined #openttd
19:54:00 *** virtualrandomnumber has quit IRC ()
20:03:52 <peter1138> andythenorth, how long before what you said happens for #11489?
20:05:27 <andythenorth> Less than 1 day? π
20:05:51 <peter1138> Old meta: "Why can't I flip this engine?" "Because it's shorter wagon and the author needs to put loads of work into supporting it"
20:06:06 <peter1138> New meta: "Why can't I flip this engine?" "Because the author knows better than you"
20:06:33 <andythenorth> Isnβt there a no-flip bit already?
20:07:43 <peter1138> Kinda of no, but yes, but I don't want to advertise it :p
20:25:03 <peter1138> Oof, lack of reference :D
21:03:05 <_glx_> added station count in now empty space ?
21:03:20 <peter1138[d]> Yes, but it's wrong.
21:04:18 <peter1138[d]> Ah, there's a break affecting my count π
21:09:03 <peter1138[d]> It's... a lot of info, but having the shaded lines and the count makes it a lot more usable.
21:10:07 <peter1138[d]> Fixed the counts now, the only difference from that screenshot is Mail should be 18 too.
21:10:50 <peter1138[d]> Should I indent the "Empty" line as well to match the cargo lines.
21:11:39 <peter1138[d]> These drop down modules made it very easy to add the count.
21:12:22 <peter1138[d]> It's probably a bit less efficient than the old way, but.
21:12:29 <andythenorth> if I recompile with 11494, will my savegame be fixed π
21:12:42 <peter1138[d]> I don't think it will fix already broken saves.
21:13:07 <_jgr_> You just have to temporarily re-add the edge
21:13:33 <_jgr_> When it disappears again the stuck cargo will be re-routed
21:14:19 <peter1138> Time for some modern music... Enter Sandman
21:17:04 <peter1138> `list.push_back(std::make_unique<DropDownListCargoItem>(HasBit(this->cargo_filter, cs->Index()), count_str, d, cs->GetCargoIcon(), PAL_NONE, cs->name, cs->Index(), false, count == 0));`
21:17:08 <peter1138> So many parameters.
21:17:58 <peter1138[d]> /* Define a custom item consisting of check mark, count string, icon and name string. */
21:17:58 <peter1138[d]> using DropDownListCargoItem = DropDownCheck<DropDownString<DropDownListIconItem, FS_SMALL, true>>;
21:19:21 <peter1138> But `DropDownListIconItem` is already a `DropDownIcon<DropDownString<DropDownListItem>>`, so the full definition is `DropDownCheck<DropDownString<DropDownIcon<DropDownString<DropDownListItem>>, FS_SMALL, true>>`
21:25:32 <andythenorth> hmm think my save might be irretrievable π
21:25:40 <andythenorth> I've turned cdist on and off a few times
21:25:51 <andythenorth> removed and re-added edges
21:30:26 <_jgr_> Turning cargodist on/off won't do anything
21:31:19 <andythenorth> I'm now just deleting each station that shows the issue
21:32:08 <andythenorth> see if if recurs or not π
21:33:42 <andythenorth> peter1138[d]: yes to random reverse of articulated parts π
21:34:32 <peter1138> Cos the authors doing weird stuff like longer-engines can just... not use it.
21:34:49 <peter1138> But also... if the flag is set, we could also allow manual flip as well.
21:34:57 <peter1138> No extra flags to set.
21:35:03 <_jgr_> I added the Huddersfield to Chippenham link back temporarily using a temporary train, and it fixed the stuck mail at Huddersfield when it expired
21:35:06 <andythenorth> per unit, rather than the whole articulated consist?
21:35:23 <andythenorth> _jgr_: interesting π
21:35:33 <peter1138> Per unit, doing the whole thing would require re-ordering vehicles, so no.
21:35:37 <andythenorth> the Ivy Bridge stuck pax I could not find a way to do that
21:35:41 <andythenorth> peter1138[d]: per unit works
21:35:56 <andythenorth> unless we ever want to flip the whole articulated consist?
21:36:00 <peter1138> Of course, NewGRFs can do magic to reverse the chain on build.
21:36:02 <andythenorth> another flag π
21:36:23 <andythenorth> I did consider variants for reversed steam engines, tender first
21:36:27 <peter1138> Reversing an articulated chain is... yeah no.
21:36:35 <andythenorth> but I have way too much varact 2 currently
21:39:12 <_jgr_> andythenorth: Create a train with orders to go direct from Ivy Bridge to Red Lumb, and have it arrive at either of those two stations, that'll create a link
21:39:21 <_jgr_> Train 16 in the save you posted also has wrong orders
21:40:57 <andythenorth> yeah they were out of sequence
21:41:13 <andythenorth> when I converted implicit -> explicit I made an error
21:41:49 <andythenorth> also...are we removing implicit orders?
21:43:08 <peter1138> The affirmation that "cdist doesn't work with implicit orders" and "nobody uses them" was... wrong :)
21:43:22 <peter1138> Huh, strike-through on a link is a bit funky.
21:45:51 <_jgr_> Temporary links which then take a long time to expire are not ideal
21:46:00 <peter1138> It may not be ideal, but then again neither is cdist.
21:46:13 <_jgr_> Though once all that is done implicit orders should work fine at steady state
21:46:18 <peter1138> I was already writing "not ideal"
21:54:44 <peter1138> Might be 32 bit on linux too.
21:55:01 <peter1138> lseek64 exists on Linux.
22:00:15 <peter1138> Could use FILE* again.
22:01:08 <_glx_> the build failure is weird, it's supposed to translate target to the correct exe (it does it for strgen or settingsgen
22:01:38 <peter1138> It might be the path to the .grf input or .md5 output is wrong.
22:02:11 <peter1138> But also they use a different way of calling the command, so I dunno.
22:03:12 <_glx_> oh it's missing working directory I think
22:07:27 <peter1138> So if we don't care about mmap (I don't know WHY I used mmap when I wrote that), then it's easy to be cross-compatible.
22:07:54 <_glx_> hmm no it's not that, "D:\a\OpenTTD\OpenTTD\build\src\grfid\grfid.exe -m D:/a/OpenTTD/OpenTTD/media/baseset/orig_extra.grf > D:/a/OpenTTD/OpenTTD/media/baseset/orig_extra.grf.md5" looks fine
22:08:55 <_glx_> I'll need to compile the PR locally to see how it fails
22:09:06 <peter1138> I've got an update that removes the unix-isms.s
22:09:24 <peter1138> Although it doesn't work yet ;)
22:10:29 <andythenorth> the saturation calculation is odd
22:10:38 <andythenorth> vehicles are mostly running empty
22:10:50 <andythenorth> maybe I need to remove and re-add more edges
22:12:35 <andythenorth> I cleared Chippenham - Scunthorpe (link was removed from graph)
22:12:44 <andythenorth> but re-adding it immediately shows it overloaded
22:13:19 <_glx_> at least it also fails locally, but if I copy the line and run it it seems to work
22:14:10 <_glx_> ha but md5 contains "Unable to get requested information: Unable to open file"
22:16:33 <_glx_> so yeah it fails, and now we know why
22:19:12 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:19:20 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:23:12 <_glx_> ok file_length is 352267 but file_read is 7
22:23:26 <peter1138> Don't worry about this version, I'm rewriting it again :-)
22:24:37 <_glx_> _read returns the number of bytes read, which might be less than buffer_size if there are fewer than buffer_size bytes left in the file, or if the file was opened in text mode
22:24:49 <_glx_> I guess it's in text mode
22:27:27 <_glx_> with O_RDONLY | _O_BINARY it works
22:29:45 <_glx_> but yeah a version using fopen should be simpler
22:43:22 <peter1138> [287/817 -- 21.952] Generating D:/a/OpenTTD/OpenTTD/media/baseset/orig_extra.grf.md5
22:45:48 <peter1138> Uh, I should remove int fd = -1; lols
22:46:33 <_glx_> ah emscripten is using host/target stuff
22:49:08 <peter1138> I think it makes sense to update the proper grfid first, then we can just import that. Might need to undo the fmt changes though.
22:52:47 <_glx_> you forgot to tell cmake to use the already built grfid
22:53:29 <_glx_> windows and macos nightlies would have failed the same way
22:54:54 <peter1138> I'm making it up as I go along, I have no idea how this is meant to look.
22:57:08 <_glx_> oh I just looked how it was for strgen
22:58:10 <_glx_> I don't remember all details (even if I originally wrote that stuff IIRC)
22:59:15 <_glx_> ah yes it was me 3 years ago
23:00:21 <peter1138> I didn't remember writing this tool 12? years ago :D
23:00:41 <peter1138> Emscripten seems okay now.
23:01:20 <peter1138> So, time to port these changes back to the grfcodec repo.
23:02:19 <_glx_> another option could be to put the grfid command inside the GRFCODEC_FOUND block, using grfid from grfcodec, and include the .md5 in vcs
23:11:51 <_glx_> as md5 should not change if grf doesn't
23:47:12 <_glx_> no, the repo still miss release workflow
continue to next day β΅