IRC logs for #openttd on OFTC at 2020-07-18
⏴ go to previous day
00:18:33 <GT> So, after 13 years, no 32bpp screenshot ever won the Screenshot of the Month competition. Should we remove it?
00:25:59 <GT> Or are the 32bpp .grfs just too ugly?
00:32:13 <_dp_> I'm not following screenshot competitions but I'm yet to see any good 32bpp combo. What I've seen is either straight up shit or is mixed with 8bpp so also looks meh.
00:33:55 *** snail_UES_ has joined #openttd
00:41:19 <GT> :-) absolutely true. I think abase tried to do something about it. Not sure if it was better.
00:42:05 <glx> I'm still using original gfx
00:45:41 <GT> Yes, many people do. And it's everybody's personal choice. But 32 bpp in trunk (or master or whatever it is called these days) . But what is it that people don't like about 32bpp exactly?
00:46:30 <glx> I think the main issue with 32bpp is that most grf are still 8bpp only
00:49:07 <GT> Yes, that is quite disappointing. I have not been around for 8 years or so. At that time many tars were available, and Rubidium ever provided a script to convert from pngcodec'ed tars to grf. But very little tars were actually converted since then.
00:49:20 <glx> and I'm used to original GUI, opengfx sprites don't look bad, but I don't like the GUI
00:51:25 <_dp_> GT, that screenshot is just a mismatched mix imo. toyish buildings with realistic trees and 8bpp landscape
00:55:47 <glx> landscape is definitely 32bpp in the screenshot
00:56:37 <_dp_> idk, mb it is 32bpp but looks low res
00:56:53 <_dp_> empty grass doesn't even match grass under rails
01:06:34 <GT> I agree on most of your remark. Just trying to find the problem spots, so it can be improved. Personally I would add that the rail track are too bland, and that the small houses at the left of the flats of Keningbury are not very nice.
01:28:57 *** Gadg8eer has joined #openttd
01:41:24 *** Gadg8eer has joined #openttd
02:18:02 *** WormnestAndroid has quit IRC
02:41:15 *** WormnestAndroid has joined #openttd
03:17:52 *** WormnestAndroid has quit IRC
03:18:26 *** WormnestAndroid has joined #openttd
07:42:32 *** tokai|noir has joined #openttd
07:42:32 *** ChanServ sets mode: +v tokai|noir
08:53:00 <LordAro> it is a shame that almost none of the 32bpp-ez tars got converted to grfs
08:53:20 <LordAro> there was a lot of really good artwork in there
09:25:55 <_dp_> hm... any way to get opengfx sources except milking devzone with wget?
09:41:05 <_dp_> o_O is it really not possible to add trees with newgrf?
09:42:02 *** Progman has joined #openttd
09:46:42 <nielsm> nope there is no newgrf trees at all
09:46:49 <nielsm> you can just replace the original tree sprites
09:46:59 <nielsm> with the replace baseset sprite action
09:49:58 <_dp_> freaking newgrfs, do all the silly logic but not the job they're made for :/
09:50:48 <_dp_> nielsm, I saw tree shading patch somewhere, was it you who made it?
09:53:07 <nielsm> it's an ugly hack for 32bpp blitter
09:53:36 <_dp_> nielsm, thx, I was curious to try it but couldn't find anywhere
09:53:54 <_dp_> nielsm, color remapping for 32bpp is an ugly hack in general
09:54:27 <nielsm> when you see the code you'll know why I say ugly hack :)
09:54:30 <nielsm> it's FAR worse than that
09:54:51 <Wolf01> _dp_ the grass with night mode enabled looks good for snow transition :P
09:55:39 <nielsm> in particular you will find the global int32 _hack_brightness; ;)
09:56:20 <_dp_> nielsm, yeah, that sounds like a weird way to do shading :p
09:57:37 <_dp_> nielsm, I'd probably just hardcode more palette remaps
09:57:55 <nielsm> I have no idea how those work
09:58:41 <nielsm> also I think it'd be better to drop the 8bpp blitter and let all graphics assume there is a general way of multiply blending or similar available
10:03:16 <_dp_> though I actually forgot to hardcode them for 32bpp
10:03:49 <_dp_> also it's a questionable endevour performance-wise, as working with color correctly isn't partucularly fast
10:04:23 <_dp_> I actually had to change color space for that tint to look good
10:10:05 <TrueBrain> I will be redeploying some instances on on the OpenTTD infra; active connections will drop, but no service downtime is expected :)
10:11:58 *** gelignite has joined #openttd
10:13:21 <TrueBrain> it might or might not be related to a CVE :D
10:20:42 <TrueBrain> it waits till TCP connections are dropped before it reroutes traffic away from an instance (as a good boy it is). Then you notice that someone has an open connection to the BaNaNaS API and doesn't want to give it up .. GRRRRR :D
10:20:59 <TrueBrain> well, it gets forcefully terminated after 5 minutes, but that is a long time!
10:21:43 <Eddi|zuHause> aint nobody got time for that!!
10:22:00 <TrueBrain> I wonder what kind of connection it is .. :)
10:22:37 <TrueBrain> but okay .. time to drop some UDP connections now :)
10:24:06 <TrueBrain> it is still a very well done remix :)
10:32:09 <nielsm> those trees look unhealthy
10:33:09 <TrueBrain> right, maintenance done; we are running the latest updates \o/
10:33:13 <TrueBrain> AWS made this so fucking easy :)
10:34:01 <Eddi|zuHause> maybe they're ectoplasm trees?
10:48:41 <Eddi|zuHause> let me guess: china?
10:50:38 *** HerzogDeXtEr has joined #openttd
10:50:47 <Eddi|zuHause> looks like the route out of the tunnel can go back in... maybe some emergency access road?
10:54:58 <SpComb> real life inspired by cities:skylines
10:55:24 <SpComb> points to whoever finds it on google maps, the captian/comments don't tell
10:56:26 <Wolf01> I was a champion in geoguessr, I could give it a try
11:12:52 <Eddi|zuHause> turns out china is huuuuge
11:13:03 <TrueBrain> really? Super weird
11:13:06 <Wolf01> And road layer is off by like 100m
11:14:46 <Eddi|zuHause> Wolf01: and that's besides the fact that the pictures are probably not too current, and the roads are often still under construction
11:18:04 <Eddi|zuHause> reddit: "where is this?" "i presume china"... very helpful :p
11:19:30 <Wolf01> I'm checking G42, G50, G5515, looks promising, a lot of tunnels
11:20:11 <Wolf01> Or I could just google
11:20:24 <Wolf01> But I like waste time scrolling a map
11:23:37 <SpComb> yeah, it looks recent enough that you wouldn't necessarily find the completed structure on google maps, but maybe some construction
11:23:58 <Wolf01> But the road layer should be there
11:24:54 <Eddi|zuHause> SpComb: i imagine this would have been filmed before opening
11:29:34 <Eddi|zuHause> hm, some kind of race track/road surface testing area?
11:29:51 <Wolf01> Or just an expansion area, you need to lay down roads to do zoning
11:30:21 <Eddi|zuHause> that does not look like zoning
11:31:54 <michi_cc> The secret base from where China's autonomous cars overtake the world :)
11:32:23 <Eddi|zuHause> _dp_: yes, if trees are on, the map totally loses its slope contours
11:34:42 <_dp_> what are tree recolor palletes used for btw? i see some defined in tree_land.h but didn't notice any effect in the game
11:35:01 <_dp_> { { 0x7a2, PALETTE_TO_MAUVE }, { 0x7a2, PALETTE_TO_GREEN },
11:35:13 <_dp_> don't recall any mauve trees %)
11:35:33 <Eddi|zuHause> _dp_: those are colourblind modes for the minimap, i think
11:35:56 <_dp_> Eddi|zuHause, no, I'm pretty sure map colours are defined elsewhere
11:36:15 <_dp_> Eddi|zuHause, these are used for rendering tree sprites
11:36:22 <SpComb> agreed that there's a strong china vibe there. The terrain and style of highway construction is a strong match, and once you get a sense for the scope of those mountain highway projects that kind of u-turn ramp is like nothing
11:37:00 <SpComb> something like the G75 road looks like the right style, but didn't find anything matching yet
11:37:03 <Eddi|zuHause> SpComb: i don't think there was ever any serious doubt that this was china
11:37:33 <SpComb> btw the road layer is way more than just 100m off, in some places it's completely wrong
11:37:57 <Eddi|zuHause> michi_cc: so it is what i thought it was
11:48:47 <Eddi|zuHause> looks more like 300m to me
13:20:49 *** otetede has joined #openttd
13:30:07 *** Progman has joined #openttd
14:42:46 *** ChanServ sets mode: +v tokai
16:11:10 *** tokai|noir has joined #openttd
16:11:10 *** ChanServ sets mode: +v tokai|noir
16:16:53 *** Wormnest has joined #openttd
16:18:46 <Eddi|zuHause> so, i still haven't found it, but i'm pretty sure now that it's a real exit, not just a "loop in the middle of nowhere", and the exit ramps are the two outer tunnels. if we label the tunnel entrances A-B-b-a, and the other open ends c-C, then from A you can reach c straight on and b+a through the loop, from B the same, and from C you can reach only b+a (but not go back to c)
16:21:31 <Eddi|zuHause> you're saving yourself some complicated onramps-in-tunnel, at the cost of some traffic efficiency by having additional mergings
16:36:03 <b_jonas> this metal workshop that I supplied with a lot of steel for over 20 years then I abandonned it will hate me
17:06:38 *** snail_UES_ has joined #openttd
17:11:12 <b_jonas> argh I was missing a signal agin
17:38:45 *** HerzogDeXtEr1 has joined #openttd
17:56:51 <argoneus> hi, can someone please explain how pax works? if I have a bus station with 5000 passengers, will it help anything if I make another station nearby or does it need to be the same exact station
17:57:13 <argoneus> if I understand correctly each house counts as a production building producing pax, but I assume cargodist isn't smart enough to redistribute it to the other station?
17:57:34 <nielsm> assuming it's passengers generated at the station, and not transfers, then yes it will in the long run
17:58:03 <argoneus> ah so the passengers will eventually go to the other station when they see the bus one isn't serviced enough?
17:58:04 <nielsm> passengers or cargo can never move between stations without a vehicle
17:58:37 <nielsm> new passengers generated from the buildings around the stations will distribute among the stations according to the station ratings
17:59:22 <argoneus> and does cargodist determine where people want to go per-station or per-production building?
17:59:27 <nielsm> existing passengers will stay, eventually if there's too many passengers waiting or the rating drops too low, passengers will disappear
17:59:28 <argoneus> ie is it like "people from this house want to go to that station"
17:59:37 <argoneus> or will that give me different cargodist if I change the station
17:59:40 <nielsm> cargodist doesn't have destinations
17:59:52 <nielsm> it pretends they have destinations but they don't
18:00:58 <argoneus> how does it work then
18:01:36 <b_jonas> ah, so one of these newGRFs, probably the OpenGFX+ trains, edits the Asiastar to have zero carrying capacity
18:01:39 <nielsm> when a passenger appears at a station with cdist enabled, the passenger considers all possible destinations accdording to the cargp flow graph, and selects a destination according to the distance (more passengers to nearby stations) and congestion (fewer take congested routes)
18:02:20 <nielsm> after picking the destination it picks one of the possible next hops (adjacent stations) and takes the next vehicle that will visit that station
18:02:20 <b_jonas> nielsm: but how do they boot that up then? how do they start going to a new station?
18:03:03 <nielsm> after the passengers board the vehicle, they lose all information about where they considered going
18:03:56 <nielsm> so when the vehicle stops at the next station, all passengers aboard the vehicle decide whether that station is their destination (if the station accepts passengers), whether they want to change vehicle at the station (unload and become waiting passengers at station), or stay in the vehicle
18:04:09 <nielsm> and after unloading then all passengers waiting at the station get a chance to board
18:04:33 <argoneus> i see.... one more thing
18:04:39 <nielsm> I might have some details wrong, I haven't studied it fully
18:04:42 <argoneus> why does cargodist show lines as green if there's 1000 passengers on each station?
18:04:48 <b_jonas> nielsm: ah, so they use that only to decide what train to board
18:04:49 <argoneus> doesn't it mean it's hella congested
18:04:56 <b_jonas> though that still doesn't explain everything
18:05:20 <nielsm> I'm not sure how the congestion is determined
18:05:41 <nielsm> I think it has to do with the load factor of vehicles traveling that hop
18:10:28 <argoneus> mm, still thank you a lot
18:11:00 <nielsm> and that's why it's "cargo distribution" and not "cargo destinations"
19:39:09 <_dp_> crazy idea of the day: drop minor version
19:39:18 <_dp_> or, well, patch version if you count useless major one
19:40:12 <nielsm> so next is ottd version 11?
19:40:22 <nielsm> or... something higher
19:42:02 <_dp_> like, what's even the point of patch version? it would make sense if there were 2 active branches with backports and stuff
19:42:09 <_dp_> but it's always "latest"
19:42:16 <_dp_> and always network incompatible
19:42:25 <_dp_> savegame compatible, sure, but who cares :p
19:43:01 <glx> there is 2 "active" branches
19:43:06 <nielsm> but having client compatible releases would def. be an advantage at times
19:43:21 <b_jonas> I care about savegame compat with openttd (not about ttd savegame compat)
19:44:07 <_dp_> b_jonas, you sure you understand what I'm talking about? have you ever opened newer saves in older versions?
19:44:35 <b_jonas> only older saves in newer versions
19:44:50 <b_jonas> that's the part I need
19:45:16 <_dp_> b_jonas, nobody's removing that, I'm talking about opening, for example, 1.10.2 save with 1.10.1
19:45:24 <_dp_> you can do that currently but why?
19:45:35 <_dp_> it only stops new features from being available sooner
19:49:23 <_dp_> nielsm, with the current state of openttd I don't think client compatibility is a good idea. Any compatible release will be pretty much poinless.
19:50:29 <nielsm> it's mostly to be able to fix really stupid things like the 1.9.3 station sign thing or the thing with mac builds crashing when loading the server list
19:50:41 <nielsm> without forcing servers to upgrade too
19:51:20 <_dp_> nielsm, well, I guess that pretty much the same idea, do major releases sooner and keep patch stuff network compatible
19:51:39 <nielsm> since that's one of the big blockers I see with releases, the delay until servers upgrade
19:52:30 <_dp_> that's more of a servers trouble than openttd itself
19:53:18 <glx> from a user point of view I think it's easier if server version matches client version
19:56:53 <_dp_> glx, well, they can always match if they want :p
19:58:25 <_dp_> main issue with current release cycle imo is that it's year-long
19:58:42 <_dp_> there are features that I want for servers, like, yesterday, not in April :p
19:59:26 <glx> use a nightly server then :)
19:59:56 <_dp_> glx, if i wanted an empty server I could run it locally :P
20:00:38 <glx> many user also just run the client available on their linux distro
20:00:42 <b_jonas> _dp_: no no, you want the server because you want to test those new features and find bugs that appear only in server game, not local game
20:01:52 <_dp_> b_jonas, local server != singleplayer
20:03:50 <_dp_> besides, features I want aren't even merged yet because it's not march and noone cares about 1.11 :p
20:05:10 <LordAro> oh yes, i was going to go through merged PRs and see about putting a 1.10.3 together
20:05:25 <b_jonas> a local server will reproduce you most of the bugs that a remote server would, except for some lag-related ones, for which you may have to deliberately add fake lag
20:06:48 <_dp_> b_jonas, I don't think I remember any lag-related issue in openttd ever
20:07:08 <_dp_> and most nasty network stuff usually only happens on a full server after 10 hours of game :p
20:07:16 <b_jonas> _dp_: even better than, if you want to use features immediately, you'll test it for us and we'll get nice stable releases with not many bugs
20:07:25 <b_jonas> and we'll thank you for your testing work
20:08:54 <_dp_> b_jonas, I already test features that I care about :p
20:09:17 <_dp_> also it's a bad practice when programmer is the only person testing his own feature :p
20:12:13 *** philip[m] has joined #openttd
20:33:28 <_dp_> meanwhile my 1.9.3 server keeps getting more and more popular...
21:41:33 <Afdal> Quick modding question: why is it in practice trains can't break an apparent max speed of 11,888 km/h? Even if I set an engine's max speed much higher than that?
21:43:14 <Afdal> At least under the Realistic acceleration model
21:43:35 <Afdal> Something to do with air resistance?
21:45:22 <nielsm> good question! I'm not one to try to answer, I never looked into that part of vehicle movement code
21:48:05 <Afdal> I've been trying to fool around with coefficients of tractive effort and air drag but neither seems to affect anything
21:48:21 <Afdal> Not sure if I'm just not editing this code right or what
21:49:23 <_dp_> I think there is a limit to how much vehicle can move in a single tick
21:49:28 <_dp_> no idea what that limit is though
21:49:49 <Afdal> I turned on Original acceleration and it seems to not have this limitation
21:50:14 <Afdal> after several minutes my train managed to reach the maximum specifiable speed limit of 65,918 km/h :)
21:50:39 <Afdal> Of course Original acceleration stinks, so I gotta figure out how this works still
21:50:51 <nielsm> I'm not sure if they're correct but I think they should be
21:57:15 <Afdal> How do all those fancy newgrfs manage to put extra information in the vehicle descriptions
21:57:28 <Afdal> Are those passing variables along or are they plain text
21:57:51 <Afdal> I'd like some sort of indicator that my editing these coefficients is actually doing something...
21:59:50 <nielsm> with one of the important points being this: "Since OpenTTD r23045 the contents of registers 100h..105h are copied onto the text reference stack."
22:00:06 <Afdal> oh it is plain text isn't it
22:00:10 <nielsm> i.e. if you fill those registers with relevant data during the callback resolution you can pull those data in the text formatting
22:00:13 <Afdal> can't use that for testing then
22:07:31 *** Lejving has joined #openttd
23:59:17 *** snail_UES_ has joined #openttd
continue to next day ⏵
