IRC logs for #openttd on OFTC at 2022-12-30
โด go to previous day
00:01:44 <glx[d]> you can use a switch yes
00:02:13 <supermop_Home> why do we need the actual 'tile types'
00:02:46 <supermop_Home> couldn't i have the switch switch between a sprite group with a roof and a sprite group without a roof?
00:03:20 <glx[d]> when you build a station, depending on how you build it, openttd use default tile types
00:03:48 <glx[d]> like 2x4 builds the glass thing
00:04:15 <petern> Stations don't work like the rest.
00:04:19 <supermop_Home> like if my switch returns " this tile is in the middle of the platform and needs the little house, it is tile type 2", then where do i define the graphics for tile type 2
00:04:40 <glx[d]> but in a newgrf you can ignore this default tile type and tell what you want to use instead
00:04:51 <supermop_Home> i don't know if the house is type_type 2, i am just guessing
00:05:37 <supermop_Home> the documentation mentions 0246 for x and 1357 y, but not which type is the glass roof, which is the bare platform, etc
00:06:47 <supermop_Home> glx[d] can i forgo using tile types at all then?
00:07:41 <glx[d]> if your layout does the position check to determine what to draw yes
00:14:54 <glx[d]> If you want to reproduce default station you can ignore this callback, you just need to define the 8 layouts
00:15:46 <glx[d]> and put them in the right order in sprite_layouts
00:16:11 <supermop_Home> 8 separate spritelayouts, and just define them in order 0 to 7?
00:16:44 <glx[d]> yes to match the 8 default tile types
00:18:06 <glx[d]> 0,1 plain platform X and Y
00:18:18 <glx[d]> 2,3 platform with building X and Y
00:18:44 <glx[d]> 4,5 roof left side X and Y
00:18:57 <glx[d]> 6,7 roof right side X and Y
00:21:16 <supermop_Home> do i have to name the layouts 0,1,2....?
00:21:24 <supermop_Home> or just name them whatever
00:21:29 <glx[d]> you can use any name ๐
00:21:51 <supermop_Home> if i define 9 layouts will it freak out?
00:27:08 <glx[d]> 9 won't work, the number must be even
00:40:33 <supermop_Home> for a basic default-like station i can get away with no groundsprite, right?
00:44:55 <glx[d]> you can use GROUNDSPRITE_RAIL_Y and GROUNDSPRITE_RAIL_X
00:46:55 <supermop_Home> ground { sprite: GROUNDSPRITE_RAIL_Y; }
00:48:45 <supermop_Home> i'll change that later once i get it working
00:48:57 <glx[d]> remember, even layout is X, odd layout is Y
00:49:19 <supermop_Home> assuming it will always put in the baseset sprite regardless of railtype
00:52:39 <glx[d]> yes `GROUNDSPRITE_RAIL_(X|Y)` are the baseset ground, and an railtype-offset is applied as needed
00:53:38 <glx[d]> if you don't define your own ground sprite you want to use these constant
00:55:25 <supermop_Home> ugh i guess it's easier if i put 8 sprites in each png, but keeping it to only 4 makes it easier to work in photoshop
00:55:35 <supermop_Home> hate having to scroll left and right
00:59:00 <supermop_Home> oh better get a new nml that knows what stations are
01:09:01 <glx[d]> I remember myself writing a basic station grf (it used baseset station sprites, just adding a little mark on the platform), but it seems I didn't keep the source
01:09:57 *** reldred has joined #openttd
01:09:57 <reldred> I'll get around to doing some NML stations at some point
01:10:15 <reldred> I have sprites that have been waiting like 10 years or so to be coded
01:10:24 <reldred> the fabled Suburban Stations 2.0
01:10:35 <supermop_Home> nmlc doesn't like my "PLATFORM_SAME_SECTION"
01:10:53 <supermop_Home> not using that switch anyway so can comment it out
01:11:29 <supermop_Home> switch (FEAT_STATIONS, PLATFORM_SAME_SECTION, basic_plat_shelter, platform_position_from_middle) {
01:11:44 <supermop_Home> does that look stupid?
01:13:47 <glx[d]> it's not how it's supposed to be used ๐
01:14:50 <glx[d]> switch (FEAT_STATIONS, basic_plat_shelter, platform_position_from_middle( PLATFORM_SAME_SECTION)) {
01:15:09 *** wallabra_ has joined #openttd
01:16:43 *** wallabra has quit IRC (Ping timeout: 480 seconds)
01:16:43 *** wallabra_ is now known as wallabra
01:24:29 <petern> Can we just extend stations to use the 'normal' tile layout system used by everything else?
01:24:42 <petern> And would that help anything...
01:32:51 <Pruple> afaict you can ignore the "layout" stuff and use var2 / switches for everything. But I haven't gotten too into stations yet. ๐
01:52:17 <petern> Stations are different
02:02:54 <Pruple> the wiki even says "Note that it may be easier to draw different sprite sets using a VarAction2 based on station variable 40, rather than redefining the layout." ๐คฃ
02:08:41 <glx[d]> there are 2 layouts in station terms
02:10:55 <glx[d]> sprite layout (like other features but defined in action 0 and needing workarounds to be dynamic), and station layout (which tile type to use when building)
02:11:41 <glx[d]> when implementing in nml I discarded station layout definition, just use CB24
02:13:34 <petern> Got to love the magic 0x42D...
02:13:56 <glx[d]> yeah at least it's hidden in nml
02:14:33 <petern> static const SpriteID SPR_RAIL_PLATFORM_Y_FRONT = 1069;
02:14:40 <petern> We could at least use this ๐
02:14:58 <glx[d]> but the spec says 0x42D
02:15:55 <petern> Anyway, it's possible to bolt on standard act2 tile layouts instead, which would be a lot easier to use. Although you've done all the hard work in NML already ๐
02:16:15 <glx[d]> extending station is not possible, but using a new feature should work
02:19:32 <petern> At least I thought it was. Distinguishing the action 2s is a problem. Hmm.
02:19:50 <glx[d]> yeah the stupid little/lots action2
02:23:50 <glx[d]> hmm I guess numlittleset bit7 is already used to detect varact2/random from basic action2
02:26:32 <petern> Kind of yes, but it's not actually explicitly that.
02:28:59 <glx[d]> uint8 setid = buf->ReadByte();
02:28:59 <glx[d]> uint8 type = buf->ReadByte();
02:29:45 <glx[d]> it's exactly that, then once it's filtered `byte num_loaded = type;`
02:30:02 <glx[d]> so we could add a type
02:30:03 <petern> It's specifically only the listed values.
02:30:22 *** wallabra_ has joined #openttd
02:31:15 <petern> So 0x88 or 0xC4 is a valid num_loaded. If probably unused...
02:31:48 <reldred> So I think 2.5x interface scaling is my favorite at this rate
02:32:13 <petern> Just missing those half-pixels.
02:32:37 <reldred> Honestly I kinda like the breathing space that it gives in the UI
02:33:31 <petern> glx[d]: You could of course steal a specific value to mean load another byte and carry loading as a tile layout, but then it's not in the same format as a normal one.
02:34:56 <petern> Or you could reserve bits 6 and 7, and steal 0xC0 to 0xFF to mean 0x00-0x3F, but again it's still not the same format, although no extra byte now.
02:35:08 *** wallabra has quit IRC (Ping timeout: 480 seconds)
02:35:08 *** wallabra_ is now known as wallabra
02:35:09 <petern> I'm never sure what range of values have been used for num_loaded...
02:35:19 <petern> Usually it's 0 or 1 ๐
02:36:14 <petern> You might be right about new feature though
02:36:29 <petern> Along the lines of industries and industrytiles being separate features...
02:36:52 <petern> Although all of the stations feature is really only rail stations already.
02:37:42 <glx[d]> for docks you used another feature I guess
02:38:12 <JGR> Is there a branch or PR for that somewhere, incidentally?
02:38:16 <glx[d]> and roadstops also moved away from stations
02:38:37 <petern> There is but it doesn't currently compile ๐
02:39:29 <glx[d]> in svn time you had patches for everything, now you have branches ๐
02:39:42 <petern> I couldn't decide if the dock spec should be multi-tile, or just placed tile-by-tile.
02:40:15 <petern> So I did one, then ripped it half out, and then got lost with other things.
02:40:52 <glx[d]> multi-tile seems better
02:40:54 <petern> But also yes, I used the standard tile layout stuff.
02:41:26 <glx[d]> as you can build a big dock and tell where docking tiles should be
02:42:10 <petern> Yes, but since the default docks can now dock on all tiles I kinda removed that idea anyway.
02:42:12 <glx[d]> and that allows single tile too
02:42:34 <petern> Docking tiles aren't real anyway, so they're not part of a layout.
02:43:56 <reldred> I miss ttdpatch loading at bouys
02:44:04 <reldred> that was always super useful
02:44:15 <petern> I miss sleep, I was meant to go 2 hours ago but got sidetracked again.
02:44:40 <petern> Also newgrf-docks is my currently checked out branch, so I was looking at it still ๐
02:44:49 <JGR> It's the holidays, just sleep in ๐
02:45:13 <petern> I've got an eye-test at 9:50 UTC. 7 hours. Oops.
02:46:58 <glx[d]> anyway with current station spec it's possible to do almost anything, it's just more complicated
02:47:34 <glx[d]> and with nml it's a lot easier
02:51:09 <glx[d]> you can have many sprite_layouts and select which one to use with CB14, you can also have only one (well two because X and Y) sprite_layout and use temp registers to hide/show stuff
02:57:04 <petern> They were my big project, I should know it all but, time... ๐
02:59:12 <glx[d]> the only real limitation is var10 limited range
02:59:35 <glx[d]> 0-7 with 0 and 2 reserved
03:07:48 <glx[d]> but I managed to use 11 different spritesets with only 2 sprite_layouts and 4 different stations in the chips.nml in my gist
03:15:11 <glx[d]> chips nfo was a lot simpler for the same result as it used more sprite layouts (and the same solution is doable in nml too but I wanted to try a very complex one)
03:38:30 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:50:00 <supermop_Home> glx[d] working-ish now, though its just platforms with flashing numbers
03:59:37 <supermop_Home> so i can check if a nearby tile is road.. but it would be interesting to check which side of station nearest town is..
03:59:53 <supermop_Home> so that headhouse gets drawn on the town side
04:16:52 *** TROILUS3 has joined #openttd
04:20:13 *** TROILUS has quit IRC (Read error: No route to host)
04:20:13 *** TROILUS3 is now known as TROILUS
06:40:10 *** supermop_Home has quit IRC (Ping timeout: 480 seconds)
07:02:11 *** nielsm has quit IRC (Ping timeout: 480 seconds)
07:29:05 <andythenorth> dP: yes like that ๐
08:02:01 <dwfreed> satisfactory has path signals; I'm sure how I feel about them
08:02:33 <dwfreed> satisfactory's rail building sucks, though
08:02:48 <dwfreed> it took me a long time to figure out how to build a roundabout
08:04:01 *** WormnestAndroid has quit IRC (Remote host closed the connection)
08:04:23 <dwfreed> (it was easier to build it with "square" corners than to try and reason out how do it proper circular-like)
08:15:33 <Merni> why did you build a roundabout on a railway line though
08:19:42 <dwfreed> because it's easier to deal with on a 2 rail 4 way intersection than a double cross?
08:20:01 <dwfreed> (keep in mind I'm talking about satisfactory, not openttd)
08:22:45 *** sla_ro|master has joined #openttd
08:40:54 <dP> andythenorth: well, that's just cmclient ;)
09:09:39 <petern> andythenorth: Goes it throw out path signals?
09:10:52 <andythenorth> signal an actual junction, then see which is faster ๐
09:11:05 <andythenorth> for throughput, not 0-60 time ๐
09:11:22 <andythenorth> also are your eyes proven working?
09:12:48 <petern> It is pissing down ๐ฆ
09:15:21 <andythenorth> I'm so good at junctions
09:15:26 <MnHebi> petern: Just tell ChatGPT to make them faster
09:15:33 <andythenorth> should probably use combo pre-signals
09:16:04 <petern> andythenorth: Just don't bother with that middle bridge.
09:16:26 <MnHebi> Ah so that is what the little side facility is for
09:16:43 <petern> Or make it one longer to avoid the wiggle.
09:17:52 <MnHebi> If I'm not mistaken the bridge pillar on one side sits in smack middle of track
09:18:20 <andythenorth> longer bridge is longer signal gap though
09:18:24 <andythenorth> and with PBS being so slow
09:18:29 <andythenorth> I have to optimise everything
09:18:46 <andythenorth> ha I didn't even place a signal before the bridge
09:35:02 <petern> And car drivers are angry
09:40:38 *** wallabra has quit IRC (Ping timeout: 480 seconds)
10:22:09 <petern> Now the worst part, choosing frames
10:22:19 <TrueBrain> no no no, wait, the right one
10:23:20 <TrueBrain> so our TURN usages is still ~3GB a day, which isn't that bad
10:23:33 <TrueBrain> about 12% of the connections use TURN
10:24:04 <TrueBrain> 63% of the servers use STUN, but only 29% of the connections .. shows how many people connect to a more public server, which allows for direct connections ๐
10:25:20 <TrueBrain> about 5% of the connections fail establishing. 40% of that due to user request, 40% due to timeout (not pressing the Allow button on the TURN request basically), 10% due to network aborts, and only 10% due to running out of methods to connect client with server. That means we manage to connect 99.5% of the clients to the server they requested
10:25:30 <andythenorth> stats are good ๐
10:25:37 <andythenorth> pls do a PDF report with charts
10:25:42 <andythenorth> I will circulate to higher ups
10:26:02 <TrueBrain> I have pretty pictures for you, no problem ๐
10:26:32 <andythenorth> ok what are we doing today?
10:26:50 <TrueBrain> we handle, on average, 3500 connections a day
10:27:20 <TrueBrain> in peak this month that was over 7500 ๐
10:27:59 <TrueBrain> it is funny how you normally see a very clear: these days are in the weekend. But the last 10 days or so, they are all similar .. like people have days off etc
10:28:30 <TrueBrain> but all-in-all, still very happy with how the network stuff is behaving ๐
10:28:31 <LordAro> 0% IPv6 seems a bit odd
10:28:44 <dP> do you track the average bytes/second or smth like that?
10:29:06 <dP> though it's only available for turn I guess...
10:29:07 <TrueBrain> LordAro: yeah, well, it is not 0%, but it is a really low amount
10:29:10 <TrueBrain> and you are not wrong, that is odd
10:29:25 <LordAro> mm, i expect a low amount, but not (nearly) zero
10:29:31 <TrueBrain> only 1% of the servers support direct IPv6; but that was a lot more at the beginning of the month
10:29:44 <TrueBrain> so I think IPv6 broke ๐
10:30:05 <TrueBrain> from the 2nd this months to the 3rd, we went from 100+ servers on IPv6 to 0
10:30:19 <LordAro> that does sound like something broke
10:30:34 <TrueBrain> the fact that nobody reported that, tells you everything you need to know about IPv6 ๐
10:31:24 <LordAro> TrueBrain: that there are very few IPv6-only users out there? :p
10:31:58 <TrueBrain> that too, but I also see that the drop in IPv6 goes hand-in-hand with an increase in IPv4 STUN servers
10:32:10 <TrueBrain> so I am guessing most connections also have a IPv4, either via CGNAT, or via other means
10:32:28 <TrueBrain> which might be why it stayed unnoticed, as we still don't actually need IPv6 to play together ๐
10:33:16 <TrueBrain> an average TURN session takes about 30 minutes btw ๐
10:33:20 <TrueBrain> now let's find out why IPv6 is failing ..
10:33:45 <LordAro> bananas ipv6 is still working, so it's not a "general" thing
10:33:58 <TrueBrain> that is even more odd, and tnx for checking
10:34:13 <TrueBrain> I also didn't do anything at the beginning of the month related to the infra
10:37:48 <TrueBrain> look at him, having a fancy IPv6 connection ๐
10:38:07 <LordAro> ikr, such parent internet connection privilege
10:38:13 <LordAro> don't normally have such luxuries
10:38:47 <TrueBrain> would you mind changing your host file so it only resolves the IPv6? (and not the IPv4)
10:38:54 <TrueBrain> curious if that changes anything
10:43:03 <LordAro> "Timeout while connecting to coordinator.openttd.org:3976"
10:43:08 <TrueBrain> and the content services does work over IPv6?
10:43:43 <LordAro> i've not stubbed those in hosts, but the debug output showed it was being downloaded from an ipv6 address
10:44:02 <LordAro> dbg: [net] - using [2001:41d0:701:1100::5d16]:80 (IPv6)
10:44:22 <LordAro> although i suppose those are the digital ocean servers - could it be something aws related?
10:44:24 <TrueBrain> ah, yes, but that is the HTTP download; the initial connection to the content service is another IP ๐
10:44:55 <LordAro> you can't expect me to remember such things :p
10:45:12 <TrueBrain> it is not like you wrote the bloody ansible stuff for it ๐
10:45:31 <TrueBrain> but yeah, that gives the suggestion all IPv6 towards the custom protocols we have stopped working
10:45:36 <TrueBrain> let's see .. what could cause that ...
10:45:43 <LordAro> yeah, looks like content.openttd.org is falling back to ipv4 as well
10:47:39 <TrueBrain> meh, I need to enable my own IPv6 to debug this properly ๐
10:48:28 <Rubidium> doesn't work for me with IPv6 either :(
10:49:39 <Rubidium> with either of the v6 IP addresses
10:53:24 <LordAro> nmap suggests it's just not responding on v6 at all
10:53:41 <TrueBrain> yeah, but you will get near-similar results on v4 ๐
10:53:50 <TrueBrain> the firewall is strict here ๐
10:54:05 <LordAro> nah, it knows 80/443 is up on v4
10:54:23 <TrueBrain> if you add the OpenTTD ports to the scan, it will find those too ofc
10:54:41 <TrueBrain> okay, so IPv6 inside AWS is working fine, it is just for two EC2 instances it is not working
10:54:52 <TrueBrain> which take care of the custom routing .. as the NLB didn't support IPv6 "back in my day" ๐
10:55:19 <TrueBrain> lol, those instances no longer have the IPv6 assigned to their interface
10:55:39 <TrueBrain> it does on the AWS web interface, it does when I do `ip a` on the instances themself
10:55:45 <TrueBrain> well, yes, that would explain ๐
10:56:43 <TrueBrain> they do remember, looking at the routing table, they once had an IPv6 ..but also no default gateway anymore. Seems something broke on AWS's side ๐ Let's reboot the instances!
10:58:53 <TrueBrain> well, no, let's spin up two new ones, and kill the old ones .. much better
10:59:31 * LordAro spins up a new TrueBrain
11:00:42 <TrueBrain> never actually sure they manage to boot up .. had a lot of issues with them in the past ๐
11:00:58 <TrueBrain> they report healthy .. let's see if they actually are
11:01:26 <TrueBrain> let's rotate the old ones out
11:03:54 <TrueBrain> right, DNS updates .. try again LordAro / Rubidium ๐
11:04:03 <TrueBrain> (the IPs changed, so do a new lookup please :D)
11:04:41 <TrueBrain> `bbbf` and `aa4d` are the new IPs to look for ๐
11:06:42 <LordAro> looks like it's working :)
11:06:52 <LordAro> content + coordinator, certainly
11:07:13 <LordAro> stun seems to be using both?
11:07:52 <TrueBrain> bit of a weird issue .. it just "lost" its IPv6 .. but on the other hand, normally I provision a new EC2 instance every month or so .. I didn't do that for the last three .. so yeah .. what-ever ๐
11:08:59 <TrueBrain> at least we found it before someone complained ๐
11:09:42 <TrueBrain> what is kinda funny .. this terminated all active servers for a bit, but they reconnect so quickly, you don't actually notice
11:09:47 <TrueBrain> other than your console mentioning it got disconnected
11:10:37 <TrueBrain> owh, I see the spam servers are back .. let's see ... why is that the case ...
11:11:15 <TrueBrain> I guess I never copied the blacklist? As I was hoping they learned how to behave?
11:12:56 <TrueBrain> time to write similar code again, I guess
11:13:33 <LordAro> do we have numbers on how many invite-only servers there are, ooi?
11:13:58 <TrueBrain> we surely do .. well, I do
11:14:18 <TrueBrain> didn't I make an stat-entry for that?! ๐ฎ
11:18:32 <TrueBrain> I cannot believe I do not ๐
11:19:05 <TrueBrain> okay, not all servers came back after the instance update
11:19:12 <TrueBrain> most noticable, the reddit servers didn't ๐
11:19:29 <TrueBrain> which is a bit odd, but if I would guess, that is a DNS issue .. and someone is not actually respecting the TTL
11:20:02 <LordAro> they'll reappear at some point
11:25:56 <TrueBrain> `There are 170 clients, 213 IPv4 servers and 52 IPv6 servers in this list.` <- at least IPv6 is working again ๐
11:38:35 <TrueBrain> ah, I remember why I didn't add stats for game-type. As that is a "moment in time" statistics, and I only track "usage over time" statistics
11:38:58 <TrueBrain> for example, I only see how often servers register; not how many are IPv4 vs IPv6. Just how many registered for IPv4 or for IPv6
11:39:01 <TrueBrain> if that makes sense ๐
11:40:52 *** sla_ro|master has quit IRC ()
11:40:53 <TrueBrain> still cannot believe people still do this .. such a lame move .. but what-ever ..
11:42:16 <TrueBrain> tnx for quick review!
11:53:59 <dP> there were some other ad servers iirc
11:56:04 *** WormnestAndroid has joined #openttd
12:34:25 <LordAro> still needs a load of work
12:36:30 <petern> There's "a few" changes since 12.2
12:38:21 <andythenorth> did we add bugs ๐
12:38:36 <andythenorth> silly comment sorry ๐
12:38:40 <petern> No just features and 'features'.
12:38:43 <LordAro> and removed herobrine
12:40:32 <petern> Is my CPU usage less because I rebooted, or less because I updated the BIOS firmware?
12:42:07 <petern> Microsoft Flight Simulator supports DLSS, but it doesn't improve performance because the sim is CPU limited, not GPU limited. Pom te pom.
12:43:00 <LordAro> should've tried rebooting before updating the bios :p
12:43:34 <andythenorth> either I've set extra_flags wrong
12:43:57 <andythenorth> or constant reloading newgrfs causes the 'new engine' message to be suppressed
12:43:59 <andythenorth> or there's a bug ๐
12:45:32 <LordAro> gist updated, now in proper ordering
12:45:37 <LordAro> still needs reword in a few places
12:46:08 <petern> CPU is 18-20% when compiling OpenTTD.
12:47:48 <andythenorth> it's the constant reloading of newgrfs
12:47:59 <andythenorth> intro dates being reset
12:49:12 <andythenorth> forgot that not every sets 2CC different to 1CC ๐
12:50:00 <andythenorth> goes it I check company colour in Action D or 6 or whatever the sprite skipper is called?
12:50:27 <andythenorth> what was I supposed to be doing?
12:51:14 <LordAro> petern: INSUFFICIENT FEATURE
12:51:31 <TrueBrain> okay, my blacklist actually worked without incident .. nice ๐
12:51:43 * andythenorth wonders if the game should actually do random
12:51:50 <FLHerne> LordAro: I'd put the slope-aware sprites lower down, no-one cares :p
12:51:57 <andythenorth> each vehicle could have a list of random groups it could be a candidate for
12:52:09 <andythenorth> need to improve the UI though
12:52:13 <LordAro> FLHerne: don't care, reverse PR order only
12:52:14 <FLHerne> the stuff users might choose to do should be at the top
12:52:16 <andythenorth> still not happy with that, it's hard to use ^^^
12:52:23 <LordAro> unless you can justify it'd acrually a fix :p
12:52:45 <andythenorth> hmm if there were categories....
12:52:53 <andythenorth> I could put the random vehicles in categories...
12:52:56 <FLHerne> I did change the PR title to "Add" because it's barely a feature
12:53:04 <FLHerne> but it doesn't seem to have made whatever the script uses
12:57:55 <petern> -j doesn't do anything on Windows. No wonder it takes so long to compile.
12:58:42 <petern> But building still used to use lots of CPU.
12:59:41 <petern> Hmm, how do I add `/maxcpucount:` to my cmake settings...
13:01:42 <petern> Somewhat quicker with more cores in use.
13:01:59 <petern> (Lower red line is GPU so not relevant)
13:10:05 <petern> Okay, wtf this BIOS update has hugely improved performance.
13:10:16 <petern> From 40 fps to 65 fps in MSFS.
13:26:43 <Pruple> FLHerne: were you still looking at implementing #10271?
13:27:20 <FLHerne> I was, which was why I asked when RC1 is to see if I should be trying to do it right now
13:29:32 <andythenorth> whether to unify the names?
13:29:47 <andythenorth> currently the cement wagon has different refits
13:29:54 <andythenorth> * default refits
13:30:12 <andythenorth> but that's just for convenience, it's not essential
13:35:01 *** supermop_Home has joined #openttd
13:38:37 <supermop_Home> using the built-in concrete groundtile didn't work as expected
13:38:38 <andythenorth> very good railway network
13:41:51 <supermop_Home> can i access the the rail underlay sprite for the current railtype?
13:45:49 <petern> It's the base rail tile ๐
13:49:08 <supermop_Home> petern i have that for the non-roofed tiles, but i wanted to have no grass under the roofs?
13:49:38 <andythenorth> hmm too much difference visually?
13:49:55 <petern> You could draw over the grass I guess.
13:50:45 <Pruple> petern: I think that's all you can do
13:51:10 <glx[d]> That's how chips does it IIRC
13:51:19 <Pruple> you certainly can't assume that either the rail underlay sprite doesn't have grass on it, or that the rail overlay sprite provides sensible graphics. ๐
13:52:49 <Pruple> the bridge surface sprites might work, but I don't know if you can access those. and of course that requires it to be a newgrf railtype, since the default graphics don't have those sprites at all
13:53:01 <andythenorth> variant grouped a vehicle to itself
13:53:03 <andythenorth> disappeared ๐
13:53:20 <Pruple> up its own circular reference?
13:53:24 <andythenorth> probably correct
13:54:04 <andythenorth> hmm using variants to 'tidy' the buy menu up too much .... doesn't work
13:54:10 <petern> I actually put code in to protect against circular references but actually they are not possible to be included anyway, so...
13:54:35 <petern> Although I think it's sensible, as the GUI conditions are not the same as command conditions.
13:55:04 <andythenorth> this seems fine?
13:55:17 <andythenorth> identical vehicles for gameplay, just different appearance
13:56:09 <petern> What it needs is configurable filters.
13:56:57 <petern> Filter on newgrf, filter on rail type, filter on power source, filter on name...
13:57:12 <petern> In a way that doesn't add a load of buttons eating space.
13:57:37 <petern> Filter on additonal text
14:02:48 <andythenorth> I might have to unify the names or something
14:15:59 <FLHerne> probably need advice from grf people, is 10271 *actually* a good idea?
14:17:38 <FLHerne> it doesn't conflict as with custom roadstops, but it ends up with the slightly weird situation where roadtype action3 override of the baseset station only get access to the roadtype vars
14:18:18 <FLHerne> and then the custom stops from 10144 have a completely different interface
14:19:12 <FLHerne> at least if I implement it in the obvious way
14:22:56 *** nielsm has quit IRC (Ping timeout: 480 seconds)
14:30:32 <FLHerne> might be better if there was a way to set a 10144-style custom stop as the default for a roadtype?
14:30:51 <Pruple> the way I see it, the default is always going to be there, it may as well look nice. it might be possible to extend or replace it with newroadstops in the future, but that's not going to depend on what the base graphics look like.
14:30:54 <FLHerne> same for railway stations, I'm vaguely surprised that doesn't seem to exist
14:31:09 <Pruple> I really don't like that the default rail station is just... there. ๐
14:31:24 <FLHerne> maybe it does and I need to look more closely at the spec
14:31:37 <FLHerne> but I've never seen it in-game
14:31:50 <Pruple> I don't think so. I've looked, and yeah, no-one has ever done it, which you'd think they would if it were possible
14:32:30 *** sla_ro|master has joined #openttd
14:32:43 <FLHerne> I guess ordering is fun
14:34:06 <Pruple> if 10271 is easy to implement it, I'd really appreciate it, and I think other newgrf authors would too. full 10144 roadstops might be better, but I doubt they'll make it into 13. And right now it doesn't address the default stop being blah issue, any more than newstations does. ๐
14:34:49 <JGR> I don't think it's realistic to expect either to make it to the 13 release given the timescales
14:35:06 <FLHerne> well, I don't really want to create some new spec in the expectation that it'll be quickly obsolete
14:35:07 <JGR> I think that 10271 is a good idea, for what it's worth
14:35:14 <FLHerne> NewGRF API is already a mess
14:35:53 <FLHerne> JGR: you don't think that having some "use this as default stop for <roadtypes>" on NewStations would be a better solution?
14:36:15 <FLHerne> then the 'default' stop can take advantage of all the animation, cargo, etc. vars
14:37:07 <Pruple> FLHerne: I think that would be a good solution, when we get newroadstops. and if it could be done for rail stations too, that would be fantastic.
14:38:08 <JGR> I really don't think that randomness quality matters for trees
14:38:24 <JGR> Nobody is using trees for cryptographic purposes
14:38:25 <FLHerne> looks like the kind of customisable desktop patten that old-school MacOS let you draw
14:38:47 <JGR> FLHerne: I suppose that could work, hadn't really thought about that
14:39:15 <FLHerne> JGR: I hadn't until I started writing code to resolve it with roadtype vars and thought "wait this is stupid" :p
14:40:24 <JGR> You'd need to change the new road stops property interface a bit
14:41:18 <JGR> Something simple and foolproof for road set authors to use still seems a reasonable thing to do though
14:43:46 <JGR> Symmetry with road sprites, depots, etc, doesn't require any sort of complexity GRF-side
14:44:06 <FLHerne> sorry, I meant changing the property interface ;-)
14:44:42 <FLHerne> I've still only skim-read 10144
14:44:50 <JGR> At the moment road stop specs are assigned to classes in the same way as with rail stations
14:44:53 <FLHerne> so maybe that'll make sense when I actually look at it
14:45:15 <JGR> Your proposal implies assigning road stop specs somewhere else as well
14:46:06 <JGR> Codewise this is not difficult, but it creates another hurdle for reviewers to trip over
14:47:50 <FLHerne> rail stations have class DFLT but I haven't found out what that does yet :p
14:48:51 <FLHerne> if it does what the name suggests (but OTTD...) then there just needs to be a flag to not use the actual default station from that class?
14:49:00 <glx[d]> DFLT adds to the default category
14:49:06 <FLHerne> I bet it doesn't work that way
14:49:29 <glx[d]> But original station will still be there
14:49:34 <petern> Oh, I was scrolled up ๐
14:50:49 <FLHerne> petern: Pruple wants to replace default roadstop sprites, I thought adding a flag to use a NewRoadStop (and logically also NewStation) in place of the default would be better than the proposed API
14:51:16 <FLHerne> because then it can use station vars/callbacks and not just the minimal set of roadtype vars
14:51:18 <petern> That would mean road types have to define road stops, I guess. Not impossible.
14:51:52 <FLHerne> I don't really see why that would be an issue?
14:52:04 <glx[d]> #10271 is not very hard to do, it's similar to tunnel entrance underlay
14:52:13 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:52:21 *** WormnestAndroid has joined #openttd
14:53:09 <FLHerne> I mean, we could always add NML sugar to make it look like #10271 to devs, if the extra boilerplate of a stop item is an issue
14:53:19 <petern> And DFLT is just a class, you can put custom stations in DFLT no problem.
14:53:19 <FLHerne> that might be a bad idea
14:54:07 <FLHerne> ok, so then to make it the actual default when building a stop there needs to be some flag to hide the original one
14:54:19 <FLHerne> not sure if that should be on the roadtype or the station
14:54:29 <petern> Do newroadstops have roadtype limitations?
14:54:38 <FLHerne> station probably, then you can't be stupid and hide the default without replacing it
14:54:40 <petern> newstations don't have railtype limits, iirc.
14:55:20 <Pruple> petern: interesting... putting stations in there would certainly make them more discoverable for casual players, even if the default-default is still barely newgrfable. ๐
14:55:25 <petern> I think it's better to just override the default road stop graphics for the roadtype, similar to how depots work.
14:56:13 <FLHerne> OK, that's back to the original proposal then
14:56:22 <petern> WAYP is the only special use one.
14:56:30 <FLHerne> but it wouldn't work too well for rail stations
14:56:43 <FLHerne> because they'd be stuck with the original layouts
14:56:52 <glx[d]> Rail station spec is weird anyway
14:56:57 <petern> What do road type graphics have to do with rail stations?
14:57:22 <FLHerne> the problem of "can't override the default station graphics" exists for rail stations as well as road stops
14:57:32 <petern> Okay, tackle one problem at a time?
14:57:35 <FLHerne> unless I missed something
14:58:10 <glx[d]> Overriding default station graphics is not really hard
14:58:11 <petern> rail station graphics do have per-railtype graphics, not sure if the railtype specs allow changing that though.
14:58:30 <FLHerne> I'm trying to avoid the standard NewGRF thing, where problems get tackled one at a time resulting in every feature working slightly differently for no particular reason :p
14:58:58 <FLHerne> it's probably 20 years too late for that but anyway
14:59:50 <glx[d]> I'm quite happy stations are the only ones done that way
15:00:04 <andythenorth> hmm goes it nested wagons?
15:00:16 <glx[d]> Industries/objects are a better design choice
15:00:41 <FLHerne> petern: railtypes can only choose between original rail/monorail/maglev default stations
15:01:31 <FLHerne> unless you know something I haven't discovered yet
15:02:53 <glx[d]> Overrides would be action3 cargo types
15:03:24 <FLHerne> that doesn't exist though
15:03:58 <FLHerne> would be possible like the roadtypes 10271, but not great because you're stuck with the original sprite layout
15:04:04 <glx[d]> With action0 prop12 as fallback
15:04:08 <andythenorth> hmm nested wagons isn't bad
15:04:16 <FLHerne> which is kind of restrictive for rail stations
15:04:47 <FLHerne> for roadtypes it's a bit restrictive but not so bad
15:04:57 <glx[d]> Just need to provide 8 sprites type corresponding to original ones
15:06:01 <FLHerne> would be better than nothing
15:06:07 <glx[d]> Overrides can't do more, they're just less global actionA
15:06:48 <FLHerne> I know, that's why I was proposing a non-override-based spec :p
15:06:59 <andythenorth> "Flat is better than nested."
15:07:04 <andythenorth> but "Sparse is better than dense."
15:07:04 <FLHerne> although I guess they're *still* not mutually exclusive
15:07:18 <FLHerne> andythenorth: nested is dense, surely
15:07:28 <FLHerne> all the vehicles squashed into one space when you fold them
15:08:06 <andythenorth> I think overly nested is harder to discover what wagons exist
15:19:57 <supermop_Home> andythenorth super long list also hard to discover whats there
15:20:28 <andythenorth> put it on 4x zoom ๐
15:20:35 <andythenorth> makes the pixels closer
15:21:28 <supermop_Home> i think its better to be like, "ok i guess i need to buy an open wagon for this cargo. oooh a fancy type of open wagon!"
15:22:32 <andythenorth> it's the multiple levels of nesting that hasn't persuaded me
15:29:24 <andythenorth> no doubt a new episode will premiere soon
15:30:54 <petern> Hidden setting though.
15:36:07 <FLHerne> andythenorth: oh, so that's why they do that
15:36:26 <FLHerne> goes it make it 1 by default so people will stop complaining? :p
15:36:54 *** Smedles has joined #openttd
15:38:12 <dP> somehow they're still slower than blocks even on 1
15:39:48 <petern> Maybe it needs to be 0 ๐
15:43:29 <FLHerne> speculate ticks into the future and then change the signal in advance
15:45:59 <andythenorth> variants means I can simplify Horse wagons
15:46:05 <andythenorth> fewer types, more colours
15:46:56 <FLHerne> I don't see how that follows :p
15:48:23 <andythenorth> currently there are multiple types because basically 'brown hopper' and 'grey hopper
15:48:42 <andythenorth> and I made them look a bit different to stop the buy menu being really repetitive on the shapes
15:48:59 <andythenorth> now I can do hopper > grey, brown, CC etc
15:49:07 <andythenorth> and they can just look more or less the same
15:49:56 <JGR> FLHerne: No, there's no point creating performance penalties for normal players to appease strange OpenTTDCoop styles
15:50:26 <andythenorth> ok so ore hoppers are lower sides
15:50:32 <andythenorth> and rock hoppers are chunkier
16:09:04 *** Wormnest has joined #openttd
16:12:29 <andythenorth> goes it like this?
16:13:18 <FLHerne> JGR: my playing style is about as non-ottdcoop as you can get and I still notice it sometimes
16:13:19 <andythenorth> sub-pixel variants?
16:13:48 <FLHerne> possibly more, because ottdcoop is usually about avoiding trains stopped at red signals ever
16:14:00 <andythenorth> I do think 'build random vehicle' in combination with cargo filter might be a thing
16:14:12 <andythenorth> annoying with different lengths maybe
16:15:55 <andythenorth> hmm will a thing work?
16:16:06 <andythenorth> my compile is usually OK with ... trying new stuff ๐
16:16:09 <andythenorth> except when it's lolz
16:16:24 *** TROILUS3 has joined #openttd
16:16:32 <andythenorth> ok this might be a thing
16:17:44 <andythenorth> I really need to improve that buy menu sprite somehow though
16:18:14 *** TROILUS has quit IRC (Read error: Connection reset by peer)
16:18:14 *** TROILUS3 is now known as TROILUS
16:20:18 <andythenorth> maybe the dots on the dice should represent wagon length ๐
16:29:26 <Samu> there's only one AI in Bananas that uses AIGroup.GetProfitLastYear
16:29:37 <andythenorth> hmm this is weird, but seems to work great
16:29:43 <andythenorth> then I can do a randomised version of them also
16:31:25 <Samu> tt-forums.net doesn't exist?
16:31:35 <Samu> DNS_PROBE_FINISHED_NXDOMAIN
16:34:30 <andythenorth> goes it different names?
16:34:35 <andythenorth> or same-same names?
16:48:08 <dP> oh, god, spaces and tabs are mixed in the regression output...
17:05:11 <dP> hm, I just realized it's actually possible to keep the same behavior in 10018 pretty much perfectly. just save the seed instead of noise and generate noise on load
17:06:48 <dP> oh, lol, and I just remembered that's exactly what I did for other random tree parts in changes I didn't pr yet xD
17:07:29 <petern> [proc] Executing command: "C:\Program Files\CMake\bin\cmake.exe" --build i:/src/OpenTTD/build --config RelWithDebInfo --target openttd -j 12 --
17:07:29 <petern> Okay, where does that -j come from. Cos it doesn't do anything on Windows.
17:08:01 <petern> dP: Save the seed at what point?
17:08:57 <dP> well, depends on how exact of a replica you want
17:09:07 <dP> can just save some seed to make it reproducable
17:09:10 <petern> You need the seed as it was at exactly the point that random was issued
17:09:20 <petern> So you can't really just "save the seed"
17:09:51 <dP> for new saves I can, for old ones it would be a bit of a pain in the ass to get
17:10:05 <dP> and totally not worth the effort
17:10:16 <petern> Am I missing how seeds are working here?
17:11:29 <dP> tree counter noise is done at map generation
17:11:38 <dP> and random is seeded with game seed
17:11:57 <dP> so, in theory, it's totally reproducable
17:13:57 <dP> though, I guess in a long run it can divulge as tiles can change from trees to grass and back
17:14:12 <dP> so on those settings it would need random in game
17:14:36 <dP> well, whatever, it doesn't really matter anyway :P
17:15:17 <dP> it matters more for growth stages because it's more than just simple noise
17:15:27 <dP> so I had to get more creative xD
17:15:46 <JGR> I would contest that it really doesn't matter at all
17:16:20 <petern> Oh my god. Your whole point about trees is that you treat trees as things that are placed on the map at the start of the game and never again....
17:18:48 <dP> huh? all I do allows for manually placed trees to work fine
17:19:11 <dP> and spread should work too
17:19:17 <dP> even though it complicates things a bit
17:22:55 <Samu> erm, GetProfitThisYear actually iterates all vehicles
17:23:45 <LordAro> of the specified group, yes
17:24:21 <Samu> i mean, it doesn't lookup on a cache
17:26:38 <Samu> Ah, yeh, GetProfitThisYear doesn't skip vehicles below minimum age
17:27:01 <Samu> so one would expect GetProfitLastYear to do the same
17:28:07 <Samu> eh, when there's multiple AIs and tons of vehicles, iterating vehicles does indeed slow things over time
17:30:56 <Samu> RailwAI is the only AI that uses AIGroup.GetProfitLastYear and he uses it together with AIGroup.GetProfitThisYear
17:31:06 <Samu> searching for the lowest profitable train group
17:31:17 <Samu> probably to get rid of it or something
17:31:47 <Samu> i don't think RailwAI author knows of this bug
17:32:16 <Samu> the way he coded it, he expects all trains in the group being accounted for
17:32:36 <LordAro> define "slow things down over time"
17:33:54 <LordAro> because even iterating over 15*5000 items is going to take a fairly negligible amount of time
17:34:05 <LordAro> it isn't iterating in squirrel
17:37:48 <Samu> sensible cpu usage spikes, usually noticeable in fast forward
17:38:45 <Samu> or when forcing 250k ops
17:42:51 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:47:08 <Samu> RailwAI actually wants to skip groups where the first vehicle in the group is aged 800 days or lower
17:48:04 <FLHerne> that's just allowing for initial startup to settle down, surely
17:48:18 <Samu> what if the vehicle was renewed
17:49:18 <Samu> anyways... if he's checking for age of the group, i guess it's sensible to assume the first vehicle is the oldest of the group
17:50:22 <Samu> unsure if railwai does autoreplace
17:54:34 <FLHerne> not really a problem if a group isn't considered for removal for a bit
17:55:12 <FLHerne> and the autorenew depot queueing might temporarily disrupt profits anyway
18:04:11 *** D-HUND is now known as debdog
18:14:28 <pickpacket> oh. I just noticed something with my tea tea deluxe newgrf... The custom train carriages I've introduced have a cost of ยฃ0 XD
18:17:59 <Pruple> the cargos are also weightless ๐
18:31:59 <andythenorth> possibly Bananas client is confusing
18:32:20 <andythenorth> hmmm I have enough projects ๐
18:32:45 <andythenorth> "Check Online Content" is a silly button name though
18:32:57 <andythenorth> and the window title is "Content downloading"
18:33:39 <andythenorth> oh there's no filter and stuff
18:33:44 <andythenorth> OpenTTD 14 is when? ๐
18:33:59 <andythenorth> * no filter by type of content
18:34:24 <andythenorth> I never ever use this UI ever hardly except sometimes
18:35:17 *** michi_cc[d] has joined #openttd
18:35:17 <michi_cc[d]> Re the recent variants PR comments, who did predict the "separator vehicles" again?
18:42:50 <DorpsGek> - Update: Translations from eints (by translators)
18:46:47 <andythenorth> hmm about 95 engine liveries to draw ๐
18:46:50 <andythenorth> might be here a while
18:49:43 <andythenorth> 49 done already, so about 33% complete ๐
18:51:06 <petern> "cmake.buildToolArgs": [ "/maxcpucount:12" ],
18:51:14 <andythenorth> some liveries are about 4 mins work, and some are about 4 hours
18:51:18 <petern> `[proc] Executing command: "C:\Program Files\CMake\bin\cmake.exe" --build i:/src/OpenTTD/build --config RelWithDebInfo --target openttd -j 12 -- /maxcpucount:12`
18:51:19 <andythenorth> it's hard to tell when starting ๐
18:51:31 <petern> The `-j 12` is useless but I can't remove it ๐
18:53:01 <andythenorth> oh dear the grf has increase 0.1 MB in size due to adding more train liveries
18:53:15 <petern> Hmm doesn't seem to work anyway. Bums.
18:54:11 <petern> Okay, the -j 12 actually stops /maxcpucount from working :/
18:58:03 <LordAro> petern: you working on the variants crash?
18:58:10 <LordAro> or, can it wait until RC2 ?
18:58:33 <LordAro> and anything else blocking RC1 ?
18:58:39 <LordAro> michi_cc[d]: glx[d]: TallTyler: ^
18:59:42 <petern> I will be in a second.
19:06:43 <TallTyler> I wouldn't mind having #10093 merged
19:07:02 <TallTyler> The setting already existed in Settings, #10093 just removes it from worldgen
19:19:56 <petern> Huh, of course I can't reproduce :/
19:21:46 <TallTyler> Oh, that's why they're orange
19:21:51 <TallTyler> They come from Settings
19:23:23 <glx[d]> maybe they could be recolourable
19:27:57 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
19:29:46 <andythenorth> yup, and they don't match settings text either ๐
19:29:51 *** supermop_Home has quit IRC (Ping timeout: 480 seconds)
19:30:04 *** HerzogDeXtEr has joined #openttd
19:30:26 <michi_cc[d]> LordAro: Nothing from me except the PR target branch ๐
19:31:49 <michi_cc[d]> Oh, should we already ship the new title game or just on the proper 13.0 release?
19:34:19 *** supermop_Home_ has joined #openttd
19:37:34 <petern> We can do custom remaps for it but it probably makes sense to convert it to a font glyph instead.
19:38:06 <petern> Or indeed, draw it as a small square button and not use a sprite at all.
19:41:24 *** wallabra has joined #openttd
19:42:14 <petern> (But perhaps nice alignment)
19:42:31 <petern> We have precedent for such buttons in the network player list.
20:06:16 <andythenorth> Zorg may have found a niche drawing icons
20:06:37 <andythenorth> basically 'drawing' them involves churning out 10s or 100s of variants then picking one ๐
20:06:44 * andythenorth has done it too often for work
20:07:26 <LordAro> i like the shaded circle tbh
20:11:10 <supermop_Home_> andythenorth: any roof advice
20:11:46 <supermop_Home_> sometimes my design process is combinatorially make way too many variants, then get paralyzed about picking one
20:12:57 <supermop_Home_> i can waste time doing the 'churning out 100s' part, but then can't do the 'picking one' part
20:13:58 *** TROILUS3 has joined #openttd
20:14:31 *** TROILUS has quit IRC (Read error: Connection reset by peer)
20:14:32 *** TROILUS3 is now known as TROILUS
20:14:36 <supermop_Home_> few weeks ago, had this problem with little film cards i was making. with 35mm so expensive these days, often end up buying loosies out of a 5 pack at the store instead of an individual box, but then you don't get the box flap to rip off
20:15:45 <supermop_Home_> so no catchy looking card to put in the memo holder on back of the camera. mocked up a fuji-ish graphic design in illustrator to print out instead
20:16:20 <supermop_Home_> then came time to do the same thing for kodak and ended up making loads of options and never settling on one
20:18:09 <andythenorth> LordAro: copy a previous one ๐
20:18:37 <Pruple> gabled roofs are nice for isometric because they give you more wall to draw details on ๐
20:19:09 <Pruple> hipped just gives you a view that's mostly roof
20:54:44 <supermop_Home_> Pruple hipped / dickey roofs look more Hawaiian though...even though most stations in Hawaii seemed not to use them
20:57:40 <glx[d]> I like when a bug is easy to fix ๐
21:07:31 *** HerzogDeXtEr1 has joined #openttd
21:08:29 <pickpacket> Pruple: are they?? I have to check that tomorrowโฆ
21:12:35 *** HerzogDeXtEr has quit IRC (Ping timeout: 480 seconds)
21:14:28 *** wallabra has quit IRC (Ping timeout: 480 seconds)
21:15:46 <andythenorth> is that with variants?
21:15:49 *** wallabra has joined #openttd
21:17:07 <Pruple> the nml spec says "weight in tons from 0-255", but that property is only a byte, and the unit is 16ths of a ton. I suspect an nml bug / documentation error? ๐
21:17:50 <Pruple> ie, it's not a float in tons, but an integer in 16ths of tons, and 12/16 is getting rounded to 0.
21:20:33 <andythenorth> I set ` weight: 6ton;`
21:20:48 <andythenorth> and it works here ๐
21:20:54 <andythenorth> not sure what the callback would do
21:21:39 <dP> weight is two bytes, it has two properties 0x16 and 0x24
21:21:56 <dP> and nml does some magic to use both
21:22:01 <Pruple> cargo weight, not vehicle weight
21:35:14 <andythenorth> FIRS sets `weight: 1.0;`
21:40:36 <petern> Passengers weigh less than a ton, and don't get rounded down.
21:44:02 <Pruple> yes, that's why the base unit is 16ths of a ton. The question is how is nml translating "12/16"?
21:44:41 *** wallabra_ has joined #openttd
21:45:09 <andythenorth> "weight": {"num": 0x0F, "size": 1, "unit_type": "weight", "unit_conversion": 16},
21:47:58 <andythenorth> FIRS sets FMSP as 0.65
21:49:21 *** wallabra has quit IRC (Ping timeout: 480 seconds)
21:49:21 *** wallabra_ is now known as wallabra
21:49:51 <andythenorth> not sure what nml is going to do with 12/16
22:10:53 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:47:52 <supermop_Home_> so i cant use concrete groundsprite, but if i just try to draw in pavement around the rails as part of the platform it might overlap some railtypes..
22:50:39 <Pruple> if a railtype is so weirdly shaped that leaving a gap down the middle for the rails to show through doesn't work, it's probably not worth worrying about
22:50:56 <Pruple> you also have the option of totally redrawing the track for the station tile ๐
22:52:57 <petern> Solution is to draw your own rail types and disable all other NewGRFs to ensure compatibility.
22:53:02 <supermop_Home_> i wish i could composite the groundsprite out of the rail underlay sprite
22:53:10 <supermop_Home_> petern: good idea
22:54:13 <Pruple> the "rail underlay sprite" is the standard rail tile
22:54:33 <supermop_Home_> beige building looks weird with cc, white building blends in with platform too much
22:54:43 <supermop_Home_> roofs - i still can't decide
22:55:26 <Pruple> the "rail overlay sprite" is the one used to compose junctions and for track reservation marking, but if the railtype in question uses fully drawn junctions it may not have meaningful track graphics on it. ๐
22:55:59 <supermop_Home_> cc stripe on building should go away
22:57:25 <glx[d]> hmm something changed in my vscode install, I can't debug nmlc
22:58:45 <glx[d]> looks like is using a different python
22:59:05 <Pruple> yeahh... "Tracks with ballast but without landscape" is merely a serving suggestion, I bet in 99% of cases those end up being full tiles with salad ๐
23:13:43 <petern> The idea of those is they work whatever landscape type is used.
23:14:12 *** Samu has quit IRC (Quit: Leaving)
23:14:12 <petern> But making them fit in nicely in all cases is not easy.
23:17:18 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:22:26 <reldred> andythenorth: Make random the first one ๐
23:22:56 <reldred> Default to random and then select specific variations afterwards ๐
23:23:32 <reldred> I do like that it then removes having this big pile of random wagons in one bunch in the build menu
23:23:38 <supermop_Home_> maybe i should make the roof brown?
23:25:48 *** sla_ro|master has quit IRC ()
23:47:23 <supermop_Home_> off to beers and dinner
23:53:17 <petern> Interesting effect, as I used vector::swap to efficiently 'copy' from one vector to another (it doesn't need to reallocate or iterate doing that), adding the wrong list meant it was still actually there, but not in the right place.
continue to next day โต