IRC logs for #openttd on OFTC at 2019-01-17
⏴ go to previous day
00:13:14 *** Thedarkb-T60 has joined #openttd
00:23:38 *** D-HUND is now known as debdog
00:25:23 *** techmagus has joined #openttd
01:13:12 *** Thedarkb-X40 has joined #openttd
01:43:46 *** Speedy` has joined #openttd
02:03:12 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas opened pull request #7067: Fix typo in code comment: Unitializes -> Uninitializes https://git.io/fh8vS
02:26:16 *** snail_UES_ has joined #openttd
04:24:13 *** Thedarkb1-X40 has joined #openttd
05:22:19 *** HerzogDeXtEr has joined #openttd
06:28:32 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7067: Fix typo in code comment: Unitializes -> Uninitializes https://git.io/fh8vS
08:16:43 *** andythenorth has joined #openttd
08:50:23 <peter1138> Hmm, saving a stack might be awkard.
09:21:40 <peter1138> It's okay, it stopped.
10:09:19 <LordAro> i'm tempted to leave #7067 until it's a bit bigger than a couple of characters
10:20:31 <andythenorth> I see other coment typos
10:20:38 <andythenorth> but then eh, why queue it up? :)
10:20:43 <andythenorth> just ship it, no cost
10:21:33 <peter1138> Hmm, so I think a std::stack is going to be impossible to save.
10:33:55 *** D-HUND is now known as debdog
10:41:25 <crem1> Because its interface doesn't allow accessing middle of stack!
10:41:51 <crem1> But why does someone use std::stack?..
10:44:05 *** andythenorth is now known as andythenorth99
10:50:21 <Eddi|zuHause> but why would you need to access the middle? in the save-thread can't you just unroll the stack?
10:56:54 <crem> I have no context about the issue at all, but if you need to keep std::stack in old state after saving, you have to unroll it to some temporary structure and then roll back into the stack.
11:02:52 <Eddi|zuHause> well, we fork() so i thought that would take care of that, but surely there's also a way to duplicate a stack without needing any internals
11:03:58 <crem> Maybe I need some context. :) Is it about openttd? Is about saving a game? Do you fork() on save? How does it work on windows?
11:07:22 <Eddi|zuHause> yes, yes, yes, no clue
11:07:35 <Eddi|zuHause> also no clue how it works when threading is disabled
11:08:12 <peter1138> Well anyway, our saveload system is a bit static...
11:08:29 <peter1138> I didn't figure how to save a std::bitset either :)
11:08:40 <crem> forking for save is smart! :) But I'm curious how it would work on windows..
11:09:21 <Eddi|zuHause> peter1138: i'd maybe look at how cargodist data is stored?
11:09:45 <Eddi|zuHause> peter1138: the file format surely supports more "dynamic" stuff
11:10:09 <peter1138> Are you sure it's a fork? I thought it was a thread.
11:10:49 *** andythenorth99 has quit IRC
11:10:52 <Eddi|zuHause> i was pretty sure it's a fork until you said that
11:11:33 <Eddi|zuHause> i'm not going to check right now, i should be going
11:17:33 <peter1138> The threading part is only used to compress the savegame which has already been made in memory.
11:17:44 <peter1138> We don't duplicate game state for saving.
11:18:21 <Eddi|zuHause> weird, how did i get that idea then?
11:44:30 <peter1138> So yeah, unrolling a stack is not impossible but still effort. If I use a fixed array with a position, it's simpler.
11:45:48 <peter1138> I suppose an alternative is to invalidate the cache when saving (in multiplayer (if a client is joining))
11:47:17 <peter1138> Or that may be a start.
11:47:36 <peter1138> Of course, we can't saveload std::vectors either at the moment.
11:48:23 <Eddi|zuHause> so, how does cargodist save all its weird datastructures
12:03:49 <LordAro> peter1138: just save it in reverse order? (copy and pop everything)
12:03:56 <LordAro> makes it easier to load as well
12:04:02 <peter1138> linkgraph is stored in a pool, not a std::anything.
12:04:17 <peter1138> LordAro, the more I think on it the more I feel this is just a workaround and a sloppy 'solution'
12:05:14 <peter1138> I'm wondering if an order-based solution is better, but then conditional orders confuse that too.
12:05:37 <LordAro> peter1138: sorry, which bit is the workaround?
12:05:41 *** andythenorth has joined #openttd
12:06:20 <peter1138> And it's only possible because ships don't collide with either other.
12:08:03 <LordAro> could do it for aircraft as well :p
12:12:17 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 updated pull request #7047: Add #6887: Highlight tiles within local authority of towns https://git.io/fhn44
12:15:10 <andythenorth> I have no memory of that
12:19:48 *** Mahjong1 has joined #openttd
12:45:10 <Eddi|zuHause> i'm not sure if this "get going" stuff is working
12:48:37 <peter1138> 10:11 < Eddi|zuHause> i'm not going to check right now, i should be going
12:48:50 <peter1138> Unless you mean something else.
13:40:40 <AKTheKnight> Hmm, peter1138, are you in the south east then? I'm trying to narrow down where you are based on the snow. We had none where I am
13:41:20 <LordAro> just had the tiniest amount of snow up in york
13:46:24 *** snail_UES_ has joined #openttd
13:55:48 <DorpsGek_II> [OpenTTD/OpenTTD] michicc updated pull request #6980: GDI engine for font glyph rendering as a replacement for FreeType https://git.io/fpEtn
13:56:33 <peter1138> michi_cc, just a rebase right?
13:57:19 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #6980: GDI engine for font glyph rendering as a replacement for FreeType https://git.io/fh81V
13:58:20 <michi_cc> peter1138: Yes, just to get the CI changes in.
14:01:24 <LordAro> that'd be nice to have, i think
14:02:11 <LordAro> presumably it'd work with mingw?
14:02:53 <peter1138> "This is a semi-serious PR" Hmm!
14:03:13 <peter1138> LordAro, should do, it only removes dependencies, no new ones.
14:09:37 <michi_cc> peter1138: It still is, in the sense that I don't expect it to be merged unconditionally. The contents itself is definitely serious.
14:10:05 <peter1138> Hmm, that's not what "semi-serious" means to me.
14:10:39 <michi_cc> But it fixes a bug now, unless somebody is inclined to dig into freetype.
14:10:45 <peter1138> The PR system is designed for things not to be merged unconditionally :-)
14:13:20 <michi_cc> The PR was a case of removing generic code in favour of platform-specific code without any benefit (it has one now).
14:14:15 <michi_cc> Not something that makes really sense unless there are advantages.
14:18:31 <peter1138> True, removing a dependency at the expense of platform specific code is maybe not a good idea.
14:20:04 <Eddi|zuHause> that happens when your robot has no safety features
14:23:37 <CZTR> Please, can someone help us with CZTR bridges? I have problem with m4nfo. Ends with 'Insufficient meta-data' but sprite looks good: /home/vasatko/_data/bridges/output/sprites/PLACEHOLDER.png 8bpp 0 0 32 32 0 0 normal
14:24:06 <planetmaker> not sure anyone here speaks m4nfo
14:24:18 <peter1138> Nope, never seen it.
14:24:47 <CZTR> ok, but its normal NFO and error is from grfcodec
14:33:31 <peter1138> If that's the complete line, then it's missing the 'sprite' number.
14:33:59 <peter1138> The one at the beginning which is normally just -1 these days.
14:36:33 <Eddi|zuHause> CZTR: some more context might help
14:37:24 <Gabda> the map cache is getting close to its first final form :)
14:37:50 <Eddi|zuHause> is it over 9000 yet?
14:38:54 <Gabda> not yet ready to beat a saiyan
14:43:52 <CZTR> peter1138: yes, only sprite number miss (its not depend on sprite number), prefix of this line is '16 ' and complete line is: 16 /home/vasatko/_data/bridges/output/sprites/PLACEHOLDER.png 8bpp 0 0 32 32 0 0 normal
14:44:09 <CZTR> peter1138: but i see TABulators before sprite number, is it problem (this NFO is generated by m4nfo and in m4nfo i havent tabulators in this line)?
14:49:11 <Eddi|zuHause> that should not be a problem
14:54:49 *** sla_ro|master has joined #openttd
14:58:18 <peter1138> Probably need to show (use a paste site!) more of the code for some context, as Eddi|zuHause said.
15:10:54 <CZTR> ok, but how can i send file?
15:14:21 <Eddi|zuHause> "A portion of sprite 15 could not be processed."
15:14:34 <Eddi|zuHause> so the error is in the line above
15:15:32 <Eddi|zuHause> "//!!Error (68): An action 8 must precede action 4."
15:17:41 <Eddi|zuHause> CZTR: try to run nforenum
15:20:24 <Eddi|zuHause> "//!!Could not read ypos from apparent real sprite."
15:21:55 <Eddi|zuHause> CZTR: the "8bpp" seems to be wrong there
15:23:02 <Eddi|zuHause> CZTR: you're trying to compile as "Info version 7" when the syntax you use is version 32
15:24:27 <Eddi|zuHause> (2nd line of the file header)
15:25:44 <CZTR> <Eddi|zuHause>: run nfornum: super thank you i see errors now, thanks thanks thanks || and about version 7 vs 32, its autofilled from m4nfo, but ok, i will try all and again thank you!!!
15:26:16 <CZTR> i muset end now (i have sicked children)
15:26:20 <Eddi|zuHause> CZTR: you should talk to the author about a version of m4nfo that generates version 32
15:27:37 <CZTR> author (Michael Blunck) not comunicate until december. I dont know why (before comunicating normally)
15:28:17 <CZTR> Realy thank you, i will try fix all erorrs from nforenum
15:29:25 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7067: Fix: typo in code comment: Unitializes -> Uninitializes https://git.io/fh8vS
15:32:53 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #6928: Fix #5713: Use pathfinder to find closest ship depot https://git.io/fhZzm
15:33:06 *** heffer_ has joined #openttd
15:33:22 <nnyby> hehe, i updated that typo PR based on thoughts here :P
15:33:38 <LordAro> ah, you are the same person
15:33:45 <LordAro> i suspected, but wasn't certain
15:35:07 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7060: NPF refuses to pathfind when the destination tile is the same as where the vehicle currently is https://git.io/fh85f
15:56:34 *** HerzogDeXtEr has joined #openttd
15:59:37 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas commented on issue #7059: Town name language choice affects number of towns / world population https://git.io/fh8bW
16:56:13 *** Wormnest has joined #openttd
17:03:14 *** WWacko1976-work has quit IRC
17:16:10 *** Thedarkb-T60 has joined #openttd
17:45:40 <Samu> there is a do while, but I need the opposite, while, do? does it exist?
17:51:50 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 opened pull request #7069: Fix #7032: use the same mode to load and render glyphs https://git.io/fh4IB
17:58:12 <Taede> samu: afaik its just 'while (condition) { code }'
18:09:12 <Samu> must find a way to convert/combine a DiagDirection and a Track into a Trackdir
18:10:07 *** andythenorth has left #openttd
18:12:03 <Samu> static inline Trackdir TrackExitdirToTrackdir(Track track, DiagDirection diagdir)
18:12:12 <Samu> static inline Trackdir TrackEnterdirToTrackdir(Track track, DiagDirection diagdir)
18:12:19 <Samu> it's one of these, must think
18:14:52 <Samu> actually, I don't have a track, i'm doomed
18:25:59 <Samu> aha, this is what I want DiagDirToDiagTrackdir(dir);
18:26:44 *** Thedarkb-T60 has joined #openttd
18:30:31 <Samu> attempting to make forbid 90 deg work on opf
18:44:44 <DorpsGek_II> [OpenTTD/OpenTTD] Gabda87 commented on pull request #7047: Add #6887: Highlight tiles within local authority of towns https://git.io/fh4Oy
18:48:27 <Gabda> I'll split it tomorrow then
18:49:57 <Gabda> force push will work the same way, or I have to do assign the 2 new commits to the PR manually?
18:52:08 <LordAro> force push will work fine
18:57:52 *** Thedarkb1-T60 has joined #openttd
19:13:02 *** Thedarkb1-T60 has joined #openttd
19:20:43 *** Progman has joined #openttd
19:22:20 *** andythenorth has joined #openttd
19:22:25 <nielsm> okay tried using a different opl3 emulator, sound quality is approximately the same as with the other, so def. something very wrong with my code
19:35:32 <peter1138> Samu, PR it then :p
19:41:23 <peter1138> Hmm, even a 32 tile path cache helps massively.
19:42:20 <glx> any cache should help if it prevents recalculation on each tile
19:46:24 *** Thedarkb1-T60 has joined #openttd
19:46:28 *** Lejving has joined #openttd
19:46:39 <peter1138> So any ideas how to saveload a std::stack? :D
19:47:00 <peter1138> Or should I convert it to a fixed array with a position reference?
19:51:52 <glx> use a std:deque like a std::stack
19:55:02 *** gelignite has joined #openttd
19:58:10 <nielsm> peter1138, a fixed size array is probably much easier
19:58:33 <nielsm> otherwise I think adding a new top-level structure to the savegame, containing cached paths, sounds like the way to go
19:59:37 <michi_cc> peter1138: Have you already tried the most simple possible cache, i.e. just trackdir + number of tiles to follow?
20:00:38 <andythenorth> 'go NW for 6 tiles, checking next tile each time in case it's not water'
20:00:55 <andythenorth> that's how I used to code flash games when making the alien baddies move was a CPU hog
20:01:15 <andythenorth> you end up with Roomba style bump-steer navigation :P
20:01:38 <andythenorth> some ships do actually navigate by coast following
20:02:16 *** frosch123 has joined #openttd
20:20:19 <peter1138> michi_cc, i'll give it a go
20:21:53 <peter1138> and trackdir will be implicit anyway, i reckon
20:48:33 <peter1138> michi_cc, it's faster.
20:48:42 <peter1138> michi_cc, and simpler...
20:56:26 <peter1138> Hmm, is there a TrackdirToDirection function I'm missing?
20:56:28 <LordAro> peter1138: i'm imagining a ship just slowly moving across the land
20:57:52 <frosch123> TrackdirToExitdir ?
20:58:25 <frosch123> no matching enterdir though
20:58:31 <glx> LordAro: should be possible for hovercraft
21:06:47 <peter1138> frosch123, I want Direction, not DiagDirection.
21:14:16 <nielsm> hmm, I suppose the difference between "bytevalue" and "(bytevalue * 127) >> 7" can be significant, when the result is going to be bittwiddled
21:17:03 <nielsm> now the percussion is starting to sound somewhat right...
21:22:04 <peter1138> michi_cc, okay, got it working. It's barely faster than not doing it :-(
21:22:49 <peter1138> vs 66ms down to 21ms
21:24:37 <peter1138> This savegame has some weird situations where routes are blocked by depots.
21:27:28 <nielsm> side-by-side debugging
21:32:24 <nielsm> I may just have found the last bug
21:32:40 <nielsm> an "xor al,1" instruction I missed
21:48:57 <nielsm> made a little mistake when converting from raw dumped samples
21:49:04 <nielsm> it's centered in game :P
21:49:19 <LordAro> chrome thinks otherwise :p
21:49:59 <LordAro> also, the first track seems like it cuts off at about 1:05?
21:50:39 <nielsm> okay wth, this emulator code is stupid slow?
21:50:49 <nielsm> even in the release build it can barely keep up
21:52:31 <nielsm> let's try that with ken silverman's again
21:53:36 <nielsm> yeah that's literally 10x faster
21:56:44 <nielsm> pushed some code to my branch
21:56:47 <nielsm> if anyone else wants to try it
21:57:36 <nielsm> there's still one thing broken, that's dual-tracking (notes played on one track being auto-played on another too, for chorus'y effects and such)
21:59:47 <LordAro> i'm fairly certain no one else has a copy of the relevant files :p
22:00:26 <nielsm> adlib.cat is easy to retrieve from a dos version of tto or ttd :(
22:01:12 <peter1138> So the stack is clearly faster.
22:01:51 <peter1138> How did we live without this frame rate window? :p
22:05:23 <peter1138> Storing just the number of tiles to move is a bit faster than without, some times.
22:48:01 <milek7> nielsm: for what purpose it is? alternative to midi?
22:55:20 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro merged pull request #7057: Fix: A few minor compile warnings under MinGW https://git.io/fhn6E
22:55:29 <LordAro> mwhaha, merged my own PR
22:55:57 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #7069: Fix #7032: use the same mode to load and render glyphs https://git.io/fh4rp
22:56:15 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro merged pull request #7069: Fix #7032: use the same mode to load and render glyphs https://git.io/fh4IB
22:58:03 <nielsm> ahh now it looks good again :)
22:58:30 <LordAro> i just play with the default font :p
23:00:41 <nielsm> by the way I'm having an issue here where no music is playing on the title screen when starting the game, but changing music set in game options causes it to start, and returning to title screen plays the title track... is that a bug in my adlib branch or also in master?
23:00:52 <nielsm> (can't be bothered to switch back to master right now)
23:05:45 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro requested changes for pull request #7003: Feature #6918: Add option to adjust font size separately from GUI size. https://git.io/fh4oP
23:06:25 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #6988: Change: AI/GS ScriptBridge::GetName takes one extra parameter to refer the vehicle type https://git.io/fh4oD
23:07:44 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro commented on pull request #6988: Change: AI/GS ScriptBridge::GetName takes one extra parameter to refer the vehicle type https://git.io/fh4o7
23:11:07 <LordAro> nielsm: #6956 thoughts? i'm tempted to close :>
23:14:16 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh closed pull request #6956: Fix #6145: Prevent ships without valid orders from moving https://git.io/fxNMB
23:14:17 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #6956: Fix #6145: Prevent ships without valid orders from moving https://git.io/fh4Kr
23:15:39 <nielsm> but I still think it's dumb to have ships just sail at random when they have no orders
23:16:17 <LordAro> no different to trains or road vehicles
23:16:29 <LordAro> just that ships are less constrained :)
23:17:34 <nielsm> but airplanes refuse to start if they have no orders
23:17:47 <nielsm> though of course don't stop mid-air if you delete their orders
23:25:26 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on issue #7060: NPF refuses to pathfind when the destination tile is the same as where the vehicle currently is https://git.io/fh46o
23:28:17 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7060: NPF refuses to pathfind when the destination tile is the same as where the vehicle currently is https://git.io/fh46b
23:29:23 *** Thedarkb2-T60 has joined #openttd
23:34:59 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on issue #7060: NPF refuses to pathfind when the destination tile is the same as where the vehicle currently is https://git.io/fh4io
23:36:14 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #7056: Change #6060: Allow drawing dropdown lists with scrollbars above and fix scrolling movement https://git.io/fh4iy
23:38:56 <DorpsGek_II> [OpenTTD/OpenTTD] LordAro approved pull request #6990: Fix: Correct display of industry requires/produces in Build Industry window https://git.io/fh4ij
continue to next day ⏵
