Back to Home / #openttd / 2016 / 09 / Prev Day | Next Day
#openttd IRC Logs for 2016-09-04

---Logopened Sun Sep 04 00:00:54 2016
00:21-!-glx [] has quit [Quit: Bye]
00:38-!-supermop [] has quit [Ping timeout: 480 seconds]
01:09-!-sla_ro|master [slamaster@] has joined #openttd
01:29-!-sla_ro|master [slamaster@] has quit []
02:02-!-Arveen [] has joined #openttd
02:10-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
02:10-!-mode/#openttd [+o Alberth] by ChanServ
02:38-!-sim-al2 [] has quit [Ping timeout: 480 seconds]
02:51-!-keoz [] has joined #openttd
04:06-!-Supercheese [] has quit [Quit: Valete omnes]
04:08-!-andythenorth [] has joined #openttd
04:20-!-trendynick [~trendynic@] has quit [Remote host closed the connection]
04:22-!-Progman [] has joined #openttd
04:36-!-tycoondemon [] has joined #openttd
04:40-!-Mazur [] has quit [Read error: Connection reset by peer]
04:56-!-Mazur [] has joined #openttd
05:05-!-frosch123 [] has joined #openttd
05:12-!-Mazur [] has quit [Read error: Connection reset by peer]
05:47-!-Progman [] has quit [Remote host closed the connection]
06:18<andythenorth>such variations, such few pixels
06:22<frosch123>i would still recommend against generating random pixel pattern and trying to filter them for good vehicle sprites
06:24<andythenorth>generative sprites is a nice idea
06:24<andythenorth>how much time will it save?
06:27<@Alberth>not so sure what unit of time to attach :p
06:27<frosch123>lightyears? :p
06:28<@Alberth>that's a distance :p
06:28<frosch123>but it says years :)
06:28<@Alberth>fair enough :p
06:28<frosch123>it's my favorite time unit :p
06:28<frosch123>well, "time" unit
06:29<@Alberth>you can further configure it by changing the speed you're traveling
06:51<@Alberth>frosch123: I hacked the fios rewrite a bit further
06:51<@Alberth>Compared to the previous time (still available if you remove the "2"), 060 had the commit message typo fixed, 180 was rewritten, and 200 is merged into it, 190 and all other patches are unchanged
07:10-!-HerzogDeXtEr [] has joined #openttd
07:14-!-andythenorth [] has quit [Quit: andythenorth]
07:20-!-andythenorth [] has joined #openttd
07:24<frosch123>one enum less :)
07:27<frosch123>looks fine to me
07:27<@Alberth>thanks for the reviews and useful comments
07:55<andythenorth>think that’s ‘done'
07:56<andythenorth>except for the angles I haven’t drawn on 10 trams :P
08:05-!-mescalito [] has joined #openttd
08:06-!-Wolf01 [] has joined #openttd
08:06-!-Samu [] has joined #openttd
08:07<Wolf01>Good trams are good
08:08<Wolf01>Now need only proper lightrailtypes
08:08<Wolf01>Went to town fair this morning, seen donkeys with 5 legs
08:11<Samu>my next objective is
08:12<Samu>rework this function
08:14<Samu>it is using DistanceManhattan to get the coordinates of the closest ship depot near the ship
08:15<Samu>the problem is when there's obstacles in the way
08:16<Samu>or even when the depot is in another water body, innaccessible by the ship
08:16<Samu>I want to prevent that
08:16<Wolf01>Good luck
08:17<Samu>how am I to do it?
08:19-!-sla_ro|master [slamaster@] has joined #openttd
08:20<Samu>pathfinding would come next
08:20<Samu>i mean, after finding the closest ship depot
08:20<Samu>the pathfinding will try to direct the ship towards those coordinates
08:22<Samu>i'm not sure what to do
08:22<Wolf01>First you use pathfinding to find a path, then the ship follows the path
08:23<Wolf01>It's called "path finding" for a reason
08:23<Samu>the pathfinder needs the coordinates of the destination
08:23<andythenorth>5 legs?
08:24<Samu>but this function is giving it coordinates of possible inaccessible deots
08:24<Samu>i need to pre-pathfind?
08:24<Wolf01>Andy, I let your immagination do the rest
08:24<_dp_>Samu, only pathfinder can check accessibility
08:25-!-gelignite [] has joined #openttd
08:26<andythenorth>Wolf01: I get the picture :P
08:27<Wolf01>Samu, get a brief tour on how A* works
08:27<andythenorth>Wolf01: actually need roadtypes for mining trucks ;)
08:28<andythenorth>I’ve removed them from Road Hog temporarily
08:28<andythenorth>they make no sense without dedicated road
08:28<Samu>for all depots, pre-pathfind and get favourable results? then give the best favourable coordinates to the real pathfinder
08:28<Wolf01>And pathfind it again?
08:29<Wolf01>Once you find the depot you already have a path
08:29<Wolf01>Also, you don't need to have a patfind to get the coordinates, the pathfinder is used to check if the coordinates are accessible
08:30<Wolf01>For coordinates you can just scan a map sector
08:33<Wolf01>If you use a pathfinder to find something which could be inaccessible you might end with an infinite loop
08:33<Wolf01>Or you can limit the iterations
08:44<@DorpsGek>Commit by alberth :: r27633 /trunk/src (3 files) (2016-09-04 14:44:42 +0200 )
08:44<@DorpsGek>-Codechange: Extract _saveload_mode use from BuildFileList
08:45<@DorpsGek>Commit by alberth :: r27634 /trunk/src (fios.cpp fios.h) (2016-09-04 14:45:11 +0200 )
08:45<@DorpsGek>-Codechange: Improve name of the SmallFiosItem struct.
08:45<@DorpsGek>Commit by alberth :: r27635 /trunk/src (6 files in 2 dirs) (2016-09-04 14:45:40 +0200 )
08:45<@DorpsGek>-Codechange: Move FileType and FileToSaveLoad structure definitions.
08:46<@DorpsGek>Commit by alberth :: r27636 /trunk/src (3 files in 2 dirs) (2016-09-04 14:46:07 +0200 )
08:46<@DorpsGek>-Codechange: Rename FileType to AbstractFileType.
08:46<@DorpsGek>Commit by alberth :: r27637 trunk/src/saveload/signs_sl.cpp (2016-09-04 14:46:29 +0200 )
08:46<@DorpsGek>-Codechange: Don't use _saveload_mode for scenario loading detection.
08:47<@DorpsGek>Commit by alberth :: r27638 /trunk/src (7 files in 2 dirs) (2016-09-04 14:47:07 +0200 )
08:47<@DorpsGek>-Codechange: Move FiosType enum, move and rename SetFiosType function.
08:47<@DorpsGek>Commit by alberth :: r27639 /trunk/src (fileio_type.h saveload/saveload.cpp) (2016-09-04 14:47:39 +0200 )
08:47<@DorpsGek>-Codechange: Also always set the abstract FileToSaveLoad::filetype when setting a mode.
08:47<@Alberth>not so nice memories about FileType ?
08:48<Wolf01>No, just *Type hype
08:48<@DorpsGek>Commit by alberth :: r27640 trunk/src/openttd.cpp (2016-09-04 14:48:28 +0200 )
08:48<@DorpsGek>-Codechange: Remove another use of _saveload_mode in the loading code.
08:50<@DorpsGek>Commit by alberth :: r27641 /trunk/src (5 files in 2 dirs) (2016-09-04 14:50:22 +0200 )
08:50<@DorpsGek>-Codechange: Fold the _fios_items file list vector into its own class.
08:54<@DorpsGek>Commit by alberth :: r27642 /trunk/src (4 files) (2016-09-04 14:54:03 +0200 )
08:54<@DorpsGek>-Codechange: FiosGet* file query functions take a destination file list.
08:54<@DorpsGek>Commit by alberth :: r27643 /trunk/src (4 files in 4 dirs) (2016-09-04 14:54:30 +0200 )
08:54<@DorpsGek>-Codechange: FiosGetDrives function also takes a destination file list.
08:54<@DorpsGek>Commit by alberth :: r27644 /trunk/src (4 files) (2016-09-04 14:54:52 +0200 )
08:54<@DorpsGek>-Codechange: Split GetFiosItem into BuildFileList and FindItem, and move both to FileList.
08:55<@DorpsGek>Commit by alberth :: r27645 trunk/src/console_cmds.cpp (2016-09-04 14:55:21 +0200 )
08:55<@DorpsGek>-Add: Give console commands their own file list storage.
08:56<@DorpsGek>Commit by alberth :: r27646 /trunk/src (3 files) (2016-09-04 14:55:54 +0200 )
08:56<@DorpsGek>-Codechange: Move _fios_items variable into the SaveLoadWindow class.
08:56<@DorpsGek>Commit by alberth :: r27647 /trunk/src (6 files) (2016-09-04 14:56:23 +0200 )
08:56<@DorpsGek>-Codechange: Introduce file operations, and use it to replace most of SaveLoadDialogMode
08:57<@DorpsGek>Commit by alberth :: r27648 /trunk/src (5 files in 2 dirs) (2016-09-04 14:56:56 +0200 )
08:57<@DorpsGek>-Codechange: Remove remaining _saveload_mode usage.
08:57<@DorpsGek>Commit by alberth :: r27649 /trunk/src (5 files in 2 dirs) (2016-09-04 14:57:20 +0200 )
08:57<@DorpsGek>-Codechange: Introduce detailed file type enum, rebuild FiosType with it.
08:57<@DorpsGek>Commit by alberth :: r27650 /trunk/src (16 files in 4 dirs) (2016-09-04 14:57:43 +0200 )
08:57<@DorpsGek>-Codechange: Replace SaveOrLoadMode by FileOperation and DetailedFileType.
08:58<@DorpsGek>Commit by alberth :: r27651 /trunk/src (5 files in 2 dirs) (2016-09-04 14:58:04 +0200 )
08:58<@DorpsGek>-Codechange: Introduce methods for setting the name and title of _file_to_saveload.
08:58<@Alberth>right, now try stuff I wanted to do in the first place :p
09:10-!-Gja [] has joined #openttd
09:18*andythenorth has 1 out of 10 trams done :P
09:19<andythenorth>such productivity :P
09:20<Samu>oh, more trunk patches
09:20-!-sim-al2 [] has joined #openttd
09:20<Samu>gonna ruin my patches probably
09:21<@Alberth>10% done already, andy :)
09:22<@Alberth>Samu: unless you change things near file loading/saving handling, not likely
09:24<Samu>I did change something related to saveloads for AI scripts
09:24<Samu>testing my patches
09:24<Samu> brb
09:25<Samu>add start_date parameter for Random AIs on new game v1 r27603 - still works
09:26-!-Flygon_ [] has joined #openttd
09:27<Samu>saveload.cpp, saveload.h have been changed, grrr
09:28<andythenorth>Alberth: I uncovered a bug with 8 more trams :P
09:28<andythenorth>one step forward…one step back...
09:29<Samu>faster server autosaves v5 r27601 - i am getting weird results, it says it patches everything fine, but also 2 failed hunks for every file, tortoisesvn what will it be?
09:31-!-Flygon [] has quit [Ping timeout: 480 seconds]
09:32<Samu>need to look at this more carefully
09:35<Samu>fios.cpp - never touched it
09:38<Samu>toolbar_gui.cpp - i touched it, but then reverted, so i left it back to what it was, that means... im not touching it now
09:38<Samu>dedicated_v.cpp - never touched it
09:38<Samu>fios_gui.cpp - never touched
09:40<Samu>console_cmds.cpp - i touched it but ended up not needing to change anything
09:46-!-supermop [] has joined #openttd
09:49<Samu>openttd.cpp, saveload.h, saveload.cpp, afterload.cpp - only these 4 files that I need to check for conflicts
09:57-!-Mazur [] has joined #openttd
10:03<Samu>openttd.cpp is fine
10:09<Samu>saveload.cpp - Alberth adds about the way it accesses files
10:09<Samu>adds stuff
10:09<Samu>I add stuff about the way it saves the stuff
10:10<Samu>not really conflictuous, but it touches similar areas
10:10<@Alberth>usually, I add stuff, and then remove other stuff :)
10:10<@Alberth>but yeah, could be in somewhat the same area
10:12<Samu>what goes into the savegame, more specifically
10:12<Wolf01>Meh, I should give up programming
10:13<Samu>I've also added some other compression methods
10:13<Wolf01>It looks easy but has 24536435734067293620349632e45346467 problems
10:14<Samu>Alberth didn't touch that part
10:15<@Alberth>I didn't touch content of savegame, only split information of file names into more separate parts
10:16-!-Mazur [] has quit [Read error: Connection reset by peer]
10:16<@Alberth>:o more problems than molecules in the universe?
10:16<andythenorth>Wolf01: try brogramming instead
10:17<andythenorth>of being devloloper
10:17<Samu>you got code at line 270, i got code at line 275, it's really close, and the tortoisesvn patching isn't all that great at putting stuff in the right place
10:17<Wolf01>I would like to take an advanced course but only on what I need
10:17*andythenorth is develoloper
10:18<@Alberth>Samu: it has good reason not to be too good, a developer is much better at deciding the right solution
10:19<Wolf01>For example now I'm just adding a "usercontrol" which contains a scrollviewer with an image, I need to pass a property to it (the image source)... no matter of what I try, I always end up with nullPointerException... and I set up everything right
10:19<Wolf01>And it's 4 lines of code and 2 clicks!
10:20<Wolf01>I even used the same names of the demo
10:20<Wolf01>The demo had also the image caption which I don't need
10:21<Samu>next change for alberth is from 2781 and below
10:21<Samu>the whole bulk of my changes are before that
10:22<Samu>only got a change at 2851
10:22<Samu>must check
10:23<Samu>oh, threaded saves
10:23<Samu>that's right in the middle of a function you make tons of changes
10:24-!-sim-al2 [] has quit [Ping timeout: 480 seconds]
10:24<Samu>this may be the only real conflict
10:24<Samu>original line 2833
10:25<Samu> if (_network_server || !_settings_client.gui.threaded_saves) threaded = false;
10:25-!-Wolf03 [] has joined #openttd
10:25<Samu>i changed it to if (!_settings_client.gui.threaded_saves) threaded = false;
10:25-!-Wolf01 is now known as Guest740
10:25-!-Wolf03 is now known as Wolf01
10:25<Wolf01>Shitty router
10:26-!-Mazur [] has joined #openttd
10:26<Wolf01> see easy, and doesn't work for me
10:26<Samu>but no idea if that would achieve the same expected behaviour with albert changes
10:29<Samu>there should be a 3-way diff viewer
10:29<Samu>or patch viewer
10:29<Samu>revision 27632, my patch and the latest trunk version
10:30-!-Guest740 [] has quit [Ping timeout: 480 seconds]
10:30<Wolf01>I think there is, at least I used it in PHPStorm
10:34<Samu>faster server autosaves - RIP
10:34<andythenorth>Wolf01: make some roads instead? o_O
10:34*andythenorth needs a break from teeny tiny trams
10:35<Wolf01>Not sure on what to do, I would like to be sure instead of redoing the same again and again
10:35<Wolf01>If you want to follow me on the process I might try it
10:36<andythenorth>I am here
10:36<andythenorth>I can also test compile
10:36<Wolf01>Let me just some minutes to finalize the image zoom of my feed reader (without the f*****g usercontrol)
10:37<supermop>andythenorth: draw roads?
10:38<andythenorth>moi? or tu?
10:40<Samu>tortoisesvn patched saveload.cpp correctly, but i wonder if the behaviour about threaded saves is still the same
10:42<Samu>openttd.cpp change is totally unrelated, there will be no conflict
10:43<Samu>my change is about adding a start_date for random ais
10:43<Samu>Alberth change is about save and load stuff
10:44<@Alberth>why do you constantly highlight me, please stop doing that
10:45<LordAro>ooh, Alberth commit queue
10:46<Samu>:o lol
10:46<Samu>i'm thinking out loud saveload.h
10:47<Wolf01>Ok, andythenorth, I'm ready to do something
10:47<andythenorth>4 trams left, none of which I want to do right now :D
10:47<Wolf01>Not sure what, but something must be done
10:48<andythenorth>I think we can do it piece by piece
10:48<Wolf01>Yes, that's a good idea
10:48<andythenorth>first move the storage to m4, but provide a shim
10:48<andythenorth>so that all old function calls keep working
10:49<andythenorth>let’s try and rebuild the bridge while the trains still go over it :P
10:49<andythenorth>patch will be too big to throw everything off the cliff and have a non-compiling game while we make 80 changes to how tile gets roadtype
10:50<Wolf01>Ok, since today is saveload.h day I'll try to break things too
10:52<Wolf01>I'll just move m7 7..6 to m4 1..0?
10:52<Samu>max_no_competitors = 15 v31 r27601 - it appears there is no conflict with this
10:52<Wolf01>Or do you have another suggestion?
10:53<Samu>we touch the same files, but not the same functions
10:53<andythenorth>use m4 0…3 for road and m4 4…7 for light rail
10:53<andythenorth>and assume for both that 0 = default
10:53<Wolf01>0 means no road and no tram
10:54<andythenorth>that will change after newgrf support, but is safe for a long time
10:54<andythenorth>ah I proposed to store an integer there corresponding to type ;)
10:54<Wolf01>0001 0000 = road but no tram, 0000 0001 tram but no road
10:55<andythenorth>so 0 is ‘no [road | light rail] type present’
10:55<Wolf01>And obviously 0001 0001 both
10:55<andythenorth>how do we get 16 types of each if 0 is needed to define ‘none'?
10:55<Wolf01>You get 15 types where 0 is none
10:56<Eddi|zuHause>i don't think you need a "none" type
10:56<andythenorth>or we could use the track bits?
10:56<Eddi|zuHause>you just have no road bits
10:56<Wolf01>Or we don't deprecate the m7 7..6 and get full 16 types
10:57<andythenorth>shouldn’t need them :)
10:57-!-Samu [] has quit [Quit: Page closed]
10:57<andythenorth>use track bits, infer presence of road / light rail
10:57<Eddi|zuHause>if there are no road bits present, the road type is ignored
10:57*andythenorth needs an acronym for light rail
10:57<Eddi|zuHause>and if road bits are present, the road type must be valid
10:57<Wolf01>Or as eddy says, we could do some math involving m3 0..3
10:58<Wolf01>But only if m5 6 = 0
10:58<Eddi|zuHause>if "is not zero" is "math"?
10:59<supermop>andythenorth: me. i still have so melb-ish roads and tramways i rendered while i was living there
10:59<andythenorth>m5 0..3 for road as well as m3 0..3 for tram
10:59<Wolf01>We'll need to change also the level crossing stuff, now it always assume road is present for tram
10:59<Eddi|zuHause>what's the current meaning of m7 7..6?
10:59<Wolf01>m7 7..6 is tram|road
11:00<andythenorth>present road types
11:00<andythenorth>could already be inferred from m5 0..3 and m3 0..3
11:00<andythenorth>maybe there are performance reasons not to
11:00<Eddi|zuHause>that's probably redundant
11:00<Eddi|zuHause>i don't think performance is relevant here
11:00<andythenorth>seems redundant to me
11:01<Wolf01>Ok, so 0 is normal road|tram
11:01<Eddi|zuHause>afair the reason for the crossing limitation was that there are no sprites for trackbeds of tram & rail
11:02<Wolf01>There will be
11:02<andythenorth>ach, so m7 isn’t redundant, because of level crossings
11:02*andythenorth wondered if we could refactor that first to clean house
11:02<Wolf01>You need to have both m3 and m5 bits because you can have different layouts for road and tram in the same tile
11:02-!-Samu [] has joined #openttd
11:02<Wolf01>So not redundant
11:02<Eddi|zuHause>Wolf01: so that breaks existing tram track grfs, which don't provide the additional sprites?
11:03<Samu>Error C2011 'FileOperation': 'enum' type redefinition (compiling source file ..\src\os\windows\win32.cpp) openttd C:\Program Files (x86)\Windows Kits\8.1\Include\um\shobjidl.h 1852
11:03<Wolf01>We should find a workaround or fix the existing tram track grfs
11:03<@Alberth>ieks, I broke it :(
11:03<andythenorth>substitute a sprite
11:03<Samu>visual studio does not like r27651
11:04<Eddi|zuHause>Wolf01: there are some existing workarounds for similar stuff, like a grf providing too few shore sprites
11:05<Eddi|zuHause>particularly, the shore sprites where only one corner has shores, but no edge touches a water sprite
11:05<@Alberth>what's this um\shobjidl.h file? it's not of openttd
11:06<Samu>line says typedef class FileOperation FileOperation;
11:06<Samu>line before says #ifdef __cplusplus
11:06<Wolf01>Samu, don't include default windows libraries, they have classes which conflict with ottd useful ones and also with ottd
11:07<andythenorth>Wolf01: I think I would start by adding something like HasLightRail and HasStreet to the tile functions
11:07<Samu>i just tried to build openttd r27651
11:08<andythenorth>then replace calls in the drawing and construction code to HasBit() that look at m7 0..1
11:08<andythenorth>then we have some abstraction
11:08<Wolf01>Good idea
11:08<andythenorth>then we can move the storage of type to m4 later
11:08<andythenorth>road_cmd.cpp L1106 is an example
11:10<@DorpsGek>Commit by alberth :: r27652 trunk/src/saveload/saveload.cpp (2016-09-04 17:10:41 +0200 )
11:10<@DorpsGek>-Fix(r27650): Use the file operation being performed to set the _sl.action variable.
11:11<Eddi|zuHause>i'm out of ideas how to handle this Baldy's Boss guy. he seems to have a roleplaying approach to the game, but then projects that roleplaying onto game mechanics that don't exist
11:11<Wolf01>Yup, just refactoring, no new features
11:11<andythenorth>Eddi|zuHause I think he can be safely left alone :)
11:11<andythenorth>I think he is happy in his own little world
11:11<andythenorth>the questions aren’t really questions
11:12<@Alberth>it's fun tinkering with his save game :)
11:13<Wolf01>road_map.h is a good place?
11:13<andythenorth>I thought so
11:14<@Alberth>it can always be moved later :)
11:14<V453000>Eddi|zuHause: he is retarded, you can't do much with that
11:14<andythenorth>iirc correctly, you end up having to import road_map.h to places it wasn’t imported before
11:14<Eddi|zuHause>V453000: i don't think that's the right word
11:14<V453000>he might hold the record of opening completely idiotic threads
11:15<Wolf01>Seeking attention
11:15<Wolf01>Just like me :D:D:D:D:D:D
11:17<Eddi|zuHause>V453000: we had a SirXavius.
11:18<V453000>don't remember him luckily
11:19-!-Wormnest [] has joined #openttd
11:20<Samu>who's an expert windows compiler for openttd, :o
11:20<Samu>gonna try compite r27632 again
11:21<@Alberth>V: not remembering the 36 or so pages he once posted about a new kind of openttd game? :p
11:22<Samu>r27632 can compile
11:23<Samu>will try compiling every version from r27632 to r27652 to see where it fails
11:23<Wolf01>andythenorth, we already have HasTileRoadType(TileIndex t, RoadType rt)
11:24<Samu>r27633 compiles
11:24<Samu>r27634 compiles
11:25<andythenorth>Wolf01: that needs splitting imho
11:25<andythenorth> if (HasTileRoadType(ti->tile, ROADTYPE_TRAM)) {
11:25<Wolf01>if (HasBit(rts, rt)) { is just if (HasTileRoadType(tile, rt)) {
11:25<andythenorth>for example
11:26<Samu>r27635 compiles
11:26<andythenorth>ROADTYPE_TRAM corresponds to the m7 bit for tram
11:26<andythenorth>we need another way to know if there is tram on the tile
11:27<Samu>r27636 compiles
11:28<Samu>r27637 compiles
11:29<@Alberth>what visual studio version do you have?
11:29<Samu>r27638 compiles
11:29<Samu>erm, let me see
11:30<Samu>Microsoft Visual Studio 2015 Shell (Integrated)
11:30<@Alberth>ok, should be new enough
11:31<Samu>version 14.0.25420.01 Update 3
11:33<Samu>r27639 compiles
11:33-!-tokai|noir [] has joined #openttd
11:33-!-mode/#openttd [+v tokai|noir] by ChanServ
11:34<Samu>r27640 compiles
11:34<Wolf01>andythenorth, so this?
11:34<andythenorth>I think so
11:35<andythenorth>then we have to track all the uses of that down
11:35<@Alberth>27647 will fail as first revision, I think
11:35<Samu>r27641 compiles
11:36<Samu>r27642 compiles
11:37<Samu>r27643 compiles
11:37<frosch123> <- Alberth: we need a different name for FileOperation
11:37<frosch123>some windows header already uses that name
11:37<@Alberth>what about LoadSaveOperation ?
11:38<Samu>r27644 compiles
11:38<@Alberth>any way to test that without a commit?
11:38<frosch123>oh, you were already on the subject
11:38<Samu>r27645 compiles
11:39<frosch123>i think commit is the easiest option, unless you have a win compile environment
11:39<Wolf01>Pass him the patch and let him do it for you
11:39<Samu>r27646 compiles
11:40<+michi_cc>Samu: You do realise that the compile farm already knows that: ?
11:40-!-tokai [] has quit [Ping timeout: 480 seconds]
11:40<frosch123>Alberth: "SaveLoad" feels more common to me than "LoadSave"
11:41<Samu>r27647 fails :o
11:41<Samu>oh i had no idea u got stuff to test these things
11:41<LordAro>Samu: you should learn how to bisect
11:42<LordAro>absolutely no need to test every single commit
11:42<Wolf01>Binary tree, this long unknown friend
11:42<Samu>the same 2 errors
11:42*LordAro divides Wolf01 into 2 equal parts
11:43<Wolf01>And then checks in which one the stupid is, then divides it again
11:43<Samu>i used vs140, not vs100
11:44<LordAro>things aren't going to change that much
11:44<LordAro>and backwards compatibility is important too
11:48-!-Wormnest [] has quit [Ping timeout: 480 seconds]
11:48<Wolf01>andythenorth, I think this refactoring is pointless, I can't find a place where bits are used, and it just needs to change "HasTileRoadType(TileIndex t, RoadType rt)" or "GetRoadTypes(TileIndex t)"
11:50<@Alberth>Samu: try on 27652
11:51<Wolf01>Personal continuous integration guy
11:51<@Alberth>very good in counting too
11:52<andythenorth>Wolf01: I can’t find bits either
11:52<Samu>Severity Code Description Project File Line Suppression State Error C3861 'SHSaveLoadOperation': identifier not found openttd D:\OpenTTD\trunk\src\ini.cpp 110
11:53<Samu>got this error, 1 error
11:53<Wolf01>Clean and rebuild
11:53<Samu>ok, let me try that
11:54<Samu>rebuilding usually takes more time to build
11:54<LordAro>funny that
11:54<Samu>got the error already, but it's still building the rest
11:55<Samu>finished, 1 error
11:55<Samu>build log
11:56<Samu>5 warnings, but those warnings have been there for years
11:57<Wolf01>andythenorth, what if I start with defining the new entries on the enum but pointing to the old values?
11:57<@Alberth>Samu: interestingly, that file builds for me :)
11:58<@Alberth>change line 110 back to SHFileOperation(&shfopt);
12:00<Samu>it builds! :)
12:00<@Alberth>yay! thanks
12:03<Samu>i built debug x64, let me try the others
12:05<Samu>debug Win32, it builds
12:06<@DorpsGek>Commit by alberth :: r27653 /trunk/src (15 files in 4 dirs) (2016-09-04 18:06:50 +0200 )
12:06<@DorpsGek>-Fix(r27647): Rename FileOperation enum and values to SaveLoadOperation to avoid nameclash with windows compiler toolkit.
12:07<@Alberth>I would hope so :)
12:08<Samu>release x64, it builds
12:10<andythenorth>Wolf01: sounds plausible
12:10<andythenorth>my brain goes ‘bzrt’ when I deal with enums
12:10<Samu>release win32, it builds
12:10<andythenorth>I keep thinking they’re some kind of list :P
12:11<Samu>everything builds
12:11<@Alberth>andy, but they are, a list of constants :)
12:12<Samu>tested with openttd_vs140.vcxproj
12:12<andythenorth>seems more like a lookup table to me
12:12<Samu>i wont test vs100, visual studio always complains about versions
12:12<andythenorth>don’t ask me to explain how my brain works :P
12:13<andythenorth>to me a list is a thing that can have pop, push, etc :P
12:13<@Alberth>ah, it's not that :)
12:13<Wolf01>Enums are just a mean to give names to numbers
12:13<Wolf01>And lists which could be traversed
12:13<andythenorth>why not just use C pre-processor constants?
12:14<@Alberth>compile farm will do vs100, perhaps
12:14<Wolf01>Constants could not be traversed :P
12:15<Wolf01>Look at them like a constant list
12:15<Wolf01>With names
12:16<Wolf01>With enums, if you are writing a switch (MyEnum value) a lot of ides automatically provide all cases for the "MyEnum"
12:22<andythenorth>so we’ll have a new RoadTypes enum?
12:22<Wolf01>Sort of
12:22<andythenorth>and RoadType also
12:25<Wolf01> like this one
12:26<Wolf01>Not sure about the 0x7
12:26<andythenorth>me neither
12:26<andythenorth>I’m sure I didn’t write that patch :)
12:26<andythenorth>someone gave me most of that paste
12:27<andythenorth>FWIW, I think it’s fine to only have 15 each of tram / street
12:27<andythenorth>and use one value for ‘none’
12:27<andythenorth>but also not necessary
12:28<LordAro>those *SubtypeHasCatenary functions are horrible
12:28<Wolf01>The static inline bool HasRoadType(rt) could just check if has m5 3..0
12:28<Wolf01>They are stubs
12:30<LordAro>well that's ok then :)
12:31<andythenorth>3 trams to draw :(
12:31<andythenorth>7 done
12:31<andythenorth>12 bugs fixed :P
12:47<Samu>i'm back to that depot choice problem
12:47<Samu>reading logs
12:52-!-Wormnest [] has joined #openttd
13:02<Samu> - HALP, no idea how to begin
13:05<Wolf01> Something like this?
13:05<@Alberth>Samu: deciding what the desired result is (in the general case), would be a start
13:09<Samu>desired result is any acessible depot
13:11<Wolf01>How did it get the blocked depot service order? If from pathfinding then there's a problem in pathfinding, if by map scn, then you should run a pathfind routine for each found depot to check if accessible
13:11<andythenorth>Wolf01: that’s how I thought it would work
13:11<andythenorth>we’ll need an equivalent setter for construction
13:12<Wolf01>I'm working on it
13:12<andythenorth>cool :)
13:12<@Alberth>simple approach is to find the closest non-examined depot on the map, and try to do a path find operation
13:13<Wolf01>Not really sure on checks, wolves are not really good at math
13:13<@Alberth>if it works, you have a path, if it fails, find the next closest non-examined depot, and try that one
13:13<@Alberth>etc, until you find a depot, or you run out of depots
13:14<@Alberth>smart approach is to run a path find from all depots to the ship
13:14<@Alberth>(at the same time)
13:14<Samu>RIP cpu cycles
13:14<Wolf01>Implement multithreading
13:15<@Alberth>smart approach is not that much worse than from the closest reachable depot
13:15<Samu>how do i "invoke" the pathfinder ? :(
13:16<@Alberth>no idea, never done that
13:16<@Alberth>look for a pathfind routine that looks like it computes a path, then find how it is used
13:20-!-[dpk] [] has joined #openttd
13:24-!-Netsplit <-> quits: Sylf, ccfreak2k, @planetmaker, _dp_, ST2, Clockworker, nilez, dpk
13:24-!-Progman [] has joined #openttd
13:24-!-Netsplit over, joins: nilez
13:26-!-dP [~dP@2600:3c02::f03c:91ff:fe69:152c] has joined #openttd
13:26-!-dP is now known as _dp_
13:26-!-mode/#openttd [+o orudge] by ChanServ
13:27-!-Netsplit over, joins: ST2
13:27-!-mode/#openttd [+o planetmaker] by ChanServ
13:27-!-Netsplit over, joins: planetmaker
13:27-!-Netsplit over, joins: Clockworker
13:27<_dp_>Alberth, that's num_of_depots*shortest_path even in good case, smartly checking from closest to furthest will almost always be better
13:29<@Alberth>_dp_: ... ? You know A* does not expand further-away nodes until needed, right?
13:30<Samu>there are 3 pathfinders for ships t.t
13:30<Wolf01>Use OPF
13:30-!-Netsplit over, joins: Sylf
13:31-!-ccfreak2k [~ccfreak2k@] has joined #openttd
13:31<Samu>i'm trying to compare how openttd computes the nearest road vehicle depot to how it's done for ships
13:32<_dp_>Alberth, ah, forgot how it works, nvm then, checked wiki, it does pretty much the same as what I meant by smartly checking.
13:34<@Alberth>"from depots" is the smart trick here :)
13:35<_dp_>Alberth, nah, important part is having heuristic :p
13:36<_dp_>pretty sure starting from ship is actually better coz of cashing
13:37<@Alberth>yeah, but then you need to go through all depots for the heuristic, on each step
13:38-!-mender27 [] has joined #openttd
13:38<mender27>hello fellow OpenTTD players :)
13:38<@Alberth>I would like to try JPS one day too, I played with it, but the article assumes a normal grid instead of our track-based grid
13:38<mender27>I'm trying to add some files to Fedora Linux and I'm wondering where does OpenTTD normally store its music files?
13:38<@Alberth>mender27: not sure how many that are here, probably only a few at best :p
13:39<mender27>I already tried the "gm" and "data" directories, but no go. The game doesn't recognize the openmsx.obm file when either of those :(.
13:39<@Alberth> <- readme should explain it all
13:42<mender27>Alberth, yes, I wish that was the case, but I've already tried the baseset directory :).
13:43<@Alberth>works for me bin/baseset/orig_win.obm
13:44<mender27>Alberth, however, not it seems I have omitted a key detail in the readme attached to the -sources tarball.
13:44<mender27>now it seems*
13:45<@Alberth>you can try ./openttd -d 9 >& logfile.txt
13:46<mender27>Alberth, thanks for pointing me in the right direction :)
13:46<@Alberth>then wait until intreo screen, en quite again
13:46<@Alberth>that gives a log of all the stuff openttd does
13:46<@Alberth>including files
13:47<@Alberth>for less insane amounts of output, try a lower number :p
13:48<_dp_>Alberth, there should be a heuristics that doesn't need all of them ^^
13:48<_dp_>Alberth, can't think of a good one as we speak though :(
13:48<@Alberth>maybe only the ones that are actually reachable ? :)
13:49<@Alberth>as in not too far away
13:49<@Alberth>no point in finding a depot, if the order is refused :p
13:51<mender27>Alberth, I found the mistake. It turned out that within the -source directory there was a duplicate directory that actually contained the midi files. I was copying from the wrong directory to begin with :P.
13:51<@Alberth>ah, that explains a few things :p
13:56<mender27>Alberth, obviously, now the .rpm created by me works as intended. The music files went into "gm" per readme.
13:56<_dp_>Alberth, oh, I know, closest depot can be pre-computed for every tile
13:56<_dp_>it's a lot of memory though
13:57<mender27>Alberth, now I need to tinker with timidity++, but that's an entirely separate thing
13:57<@Alberth>_dp_: store direction :)
13:57<@Alberth>mender27: alright, nice you solved it.
13:58<mender27>Alberth, thanks a lot for help. Over and out! :)
13:58<@Alberth>88, wasn't it?
14:02<_dp_>Alberth, lol, I was actually thinking about heuristics for A*, didn't notice it solves the problem by itself))
14:03<@Alberth>haha :)
14:03<@Alberth>always nice, software outsmarting humans :p
14:04<_dp_>Alberth, but with direction you'll need to rebuild entire cache with every new depot
14:04<@Alberth>and every change in water tiles
14:05<@Alberth>no idea how you'd do it, tbh
14:05<_dp_>do what exactly?
14:05<@Alberth>maybe with a floodfill algorithm flooding from all depots, or so
14:06<@Alberth>compute direction to nearest depot for the entire map
14:06<_dp_>yeah, just bfs
14:06<@Alberth>I was thinking too much in single origin point :)
14:07<andythenorth>can this not be generalised to ‘all ship pathfinding is hokey’?
14:10<_dp_>fun thing with storing direction is that ship doesn't even need to know which depot it's going to)
14:10-!-mender27 [] has quit [Quit: Leaving]
14:11<@Alberth>the 'any' depot :p
14:17<andythenorth>if there was a DAG for all possible ship routes…
14:17<andythenorth>how big would the DAG be, before recalculating it when landscape changes
14:17<andythenorth>takes longer than ship pathfinding every n ticks?
14:20<@Alberth>there is no 1 dag, you'd get 1 for each destination
14:21<@Alberth>and that runs away quite fast, O**3 or worse
14:22<@Alberth>number of station * all tiles of the map
14:22<@Alberth>latter is quadratic on map size
14:22<Wolf01>Fetch \a n bits from \a x, started at bit \a s. <- why are there all the \a?
14:23<@Alberth>denotes "argument"
14:23<@Alberth>gives nice italic font in the documentation :)
14:23<Wolf01>Pretty unreadable on IDE
14:24<@Alberth>yeah, like xml is any better :p
14:25<Samu>there is no YapfShipFindNearestDepot function :( will try to create it somehow, lol
14:37-!-umgeher [] has quit [Ping timeout: 480 seconds]
14:43-!-umgeher [] has joined #openttd
15:02<Samu>what are typedef
15:06<Samu>okay i dont know how to code this... time to give up
15:11<LordAro>there does come a point where you do need to know the language you're trying to write
15:29<@Alberth>nah :p
15:32<V453000>baking 1M polygons to 8k texture
15:32<V453000>let's see how this ends up XD
15:34<V453000>1% !! XD
15:36<andythenorth>moar computer
15:36<V453000>3% now
15:36<V453000>that's 1% per minute
15:37-!-glx [] has joined #openttd
15:37-!-mode/#openttd [+v glx] by ChanServ
15:39-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
15:45<andythenorth>trams in last release of RH
15:45<andythenorth>trams in forthcoming release
15:51<V453000>10/10 progress worth the soul sacrifice
15:53-!-sla_ro|master [slamaster@] has quit []
15:58-!-sim-al2 [] has joined #openttd
16:01<andythenorth>previous edition was quite lame
16:01<andythenorth>also now haz epic cargo support
16:01*Wolf01 can't see no differences :P
16:04<Wolf01>Yes, they look better now
16:10<@Alberth>much better colours
16:13<andythenorth>is bed
16:13-!-andythenorth [] has quit [Quit: andythenorth]
16:13-!-andythenorth [] has joined #openttd
16:14-!-andythenorth [] has quit []
16:15-!-Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
16:28<Samu>i posted a patch
16:46<Samu>i posted another
16:54<Samu>before my computer dies, i better post everything I've been working with
16:54<Samu>i have a feeling my rig won't last, it came back to life after 5 days refusing to even POST
17:00<Samu>i remember a patch being rejected because it was posted on 1st april i think of last year or 2014, must find it
17:01-!-Progman [] has quit [Remote host closed the connection]
17:04<Samu>ah found it
17:04<Samu>Unstuck Ship when Leaving Depot
17:13-!-Arveen [] has quit [Quit: Nettalk6 -]
17:14-!-Gja [] has quit [Quit: Going offline, see ya! (]
17:25<Samu>last post
17:25<Samu>I don't think i got anything else to post
17:25-!-keoz [] has quit [Ping timeout: 480 seconds]
17:26-!-Lejving [] has quit [Ping timeout: 480 seconds]
17:31<Wolf01> :o interesting fact (the first one)
17:32-!-Wormnest [] has quit [Quit: Leaving]
17:34<debdog> sound is annoying, though
17:34<Wolf01>Also I already knew the last one
17:35<Wolf01>It helps with the atmosphere :P
18:04-!-Lejving [] has joined #openttd
18:15-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:30-!-gelignite [] has quit [Quit:]
18:42-!-Lejving [] has quit [Ping timeout: 480 seconds]
18:43-!-SpComb [] has quit [Ping timeout: 480 seconds]
19:01<Flygon_>Started a game in 1752... I'm not sure Hokkaido was colonized by the Japanese until around the 1880s :U
19:01-!-Flygon_ is now known as Flygon
19:02-!-Defaultti [] has quit [Ping timeout: 480 seconds]
19:03-!-SpComb [] has joined #openttd
19:04<goodger>Flygon: the japanese conquered hokkaido in 1457
19:05<Flygon>Yes, but in terms of
19:05<Flygon>Actual big cities worth noting
19:05<Samu>hmm, dock placement is really restrictive... got to make it easier
19:06<Samu>if there is a buoy in front of the dock, it won't place
19:06<Samu>if there is an aqueduct, dock isn't placed
19:06<Samu>even if its facing the right direction
19:08-!-Defaultti [] has joined #openttd
19:16<Samu>how do I ask if the bridge is an aqueduct?
19:49-!-sim-al2 is now known as Guest810
19:49-!-sim-al2 [] has joined #openttd
19:53-!-Guest810 [] has quit [Ping timeout: 480 seconds]
20:02-!-Lejving [] has joined #openttd
20:06-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
20:17-!-Samu [] has quit [Quit: Page closed]
20:35-!-JezK_ [~jez@2407:7800:400:107f:3db5:daca:8457:e66a] has joined #openttd
20:40-!-Lejving [] has quit [Ping timeout: 480 seconds]
21:10-!-glx [] has quit [Quit: Bye]
21:54-!-strohalm [~smoofi@] has joined #openttd
21:59-!-Lejving [] has joined #openttd
22:12-!-zeknurn` [] has joined #openttd
22:15-!-zeknurn [] has quit [Ping timeout: 480 seconds]
22:15-!-zeknurn` is now known as zeknurn
22:37-!-Lejving [] has quit [Ping timeout: 480 seconds]
22:38-!-Pulec [~pulec@2a01:4f8:110:1463:67::2] has quit [Remote host closed the connection]
22:46-!-strohalm [~smoofi@] has quit [Ping timeout: 480 seconds]
22:54-!-mescalito [] has quit [Remote host closed the connection]
23:07-!-strohalm [~smoofi@] has joined #openttd
23:29-!-supermop [] has quit [Ping timeout: 480 seconds]
23:45-!-Lejving [] has joined #openttd
---Logclosed Mon Sep 05 00:00:55 2016