IRC logs for #openttd on OFTC at 2018-06-19
⏴ go to previous day
00:43:09 *** ToffeeYogurtPots has quit IRC
00:43:29 *** ToffeeYogurtPots has joined #openttd
02:27:05 *** snail_UES_ has joined #openttd
02:50:02 *** tokai|noir has joined #openttd
02:50:02 *** ChanServ sets mode: +v tokai|noir
03:46:22 <ANIKHTOS> i worte some code it compiled but the exe is not workign i get an error no available language packs
04:05:30 <glx> you must be in /bin to run it
04:09:04 *** rocky1138 has joined #openttd
04:10:52 *** Supercheese has joined #openttd
04:12:05 *** supermop has joined #openttd
04:19:54 <ANIKHTOS> the code is goign back forth change files its hard to follow it
04:22:00 <ANIKHTOS> i am looking the code in status bar to see how it format the date from there i went to english.txt the language form there i went to strings.cpp
04:22:22 <ANIKHTOS> its in there that the game format the date to be displayed right??
04:36:40 *** supermop has joined #openttd
04:38:05 *** Supercheese has joined #openttd
04:39:18 *** muffindrake3 has joined #openttd
05:02:14 *** ToffeeYogurtPots has quit IRC
05:02:43 *** ToffeeYogurtPots has joined #openttd
05:19:51 *** Supercheese has joined #openttd
08:06:48 *** andythenorth has joined #openttd
08:07:11 <ANIKHTOS> hello andy how are you??
08:13:01 *** Arveen2 has joined #openttd
08:13:04 *** supermop has joined #openttd
08:17:30 *** Arveen3 has joined #openttd
08:26:02 *** andythenorth has joined #openttd
08:29:50 *** WWacko1976-work has joined #openttd
10:13:05 *** supermop has joined #openttd
10:18:33 *** andythenorth has joined #openttd
10:41:28 <ANIKHTOS> andy i mange to change teh status bar to show the nomral days as time :-)
10:41:48 <ANIKHTOS> the only problem is that change all the dates to look like this !?!?!?
11:01:27 *** andythenorth has joined #openttd
11:08:46 *** andythenorth has left #openttd
12:23:50 *** ANIKHTOS has joined #openttd
14:54:36 *** sim-al2 has joined #openttd
15:00:09 *** snail_UES_ has joined #openttd
15:07:00 <planetmaker> well... the date format is universal to a language. So yes, you change it once, you change it whereever it's used
15:07:17 <planetmaker> maybe there's one or two different date formats per language, I don't recall
15:07:18 *** supermop has joined #openttd
15:37:12 *** Mahjong has joined #openttd
16:00:17 <peter1138> Why do I find terminals and vim much easier to develop OpenTTD in than VS 2017?
16:00:53 <peter1138> Maybe it's because it doesn't need a mouse.
16:01:02 <LordAro> because it is the best?
16:06:04 *** Alberth has joined #openttd
16:06:04 *** ChanServ sets mode: +o Alberth
16:08:22 <nielsm> OpenTTD has been running at 32.25 fps on windows the whole time
16:09:03 <nielsm> I tried changing win32_v.cpp to use timeGetTime() and timeBeginPeriod(MILLISECONDS_PER_TICK) and now my fps display is showing 33.33
16:11:10 <nielsm> juuuust gonna add a little additional change to my fps-meter branch
16:15:41 <LordAro> sounds like my branches :p
16:24:35 <peter1138> What happens with SDL on Windows?
16:24:42 <peter1138> Not that anybody uses it.
16:24:43 <nielsm> I don't have SDL handy
16:25:14 <peter1138> I did compile with it not that long ago when I was testing the mouse cursor glitching. Didn't make any difference to that so I dropped it.
16:25:48 <peter1138> Might try SDL in my VM, however since the last big Windows up that runs horribly slowly now :(
16:30:03 <LordAro> i could try sdl on my msys install later
16:30:12 <LordAro> actually, no, i'm going to the pub
16:45:48 *** sla_ro|master has joined #openttd
16:48:49 <peter1138> Those worst figures are suspiciously whole numbers...
16:51:28 <nielsm> well yes those are single measurements, they don't come more accurate than ms (atm)
16:53:17 <LordAro> but "current" is sub-ms ?
17:01:43 <nielsm> current is actually average of 8 measurements
17:02:24 <nielsm> I think I'll change the values to be averages over time instead of number of data points
17:02:52 <nielsm> so "current" is average over 0.2 s, "average" is over 10 sec
17:03:14 <nielsm> (and instead adding a peak highlight to the graphs)
17:21:34 <peter1138> Use an HR timer :-)
17:22:16 <nielsm> I am actually using the QPC timer on windows now, but all the code already assumed milliseconds by the time I switched
17:23:33 <LordAro> std::chrono::high_resolution_clock
17:23:45 <nielsm> yeah maybe that'd be the better choice
17:24:00 <nielsm> and just hope everyone implements it :P
17:24:01 <LordAro> does mean actual c++11 tho :)
17:24:16 <LordAro> but it's about time someone made the leap
17:24:34 <Eddi|zuHause> no way, we never use modern language features... what would the world come to?!?
17:24:44 <LordAro> my msys fun has revealed just how much crap is left in to support ancient compilers
17:24:49 <planetmaker> our c++11 advocate hath spoken ;)
17:24:49 <Eddi|zuHause> where does it END???
17:26:21 <Eddi|zuHause> LordAro: what fun it was when we still supported GGC 2.ancient :p
17:26:49 *** Progman has joined #openttd
17:27:08 <nielsm> I am using "auto" types and anonymous functions in this code, in fact :3
17:27:17 <planetmaker> lol :D That was even before my time @ Eddi|zuHause :)
17:27:34 <planetmaker> and even then the hacks around gcc 3.x were ... scoleded upon
17:27:38 <Eddi|zuHause> when people insisted that MorophOS was some vivid community :p
17:29:08 <Eddi|zuHause> back when we dropped that, there were talks about *maybe* a new update for MorphOS that contains GCC4
17:29:23 <Eddi|zuHause> no idea whether that happened
17:31:01 <peter1138> Seems to be on 6.4.0 now.
17:31:19 <Eddi|zuHause> "(svn r4691) - Codechange: don't use unnamed unions as GCC 2.95.ancient won't compile it. Needed for our MorphOS user ;)"
17:31:21 <peter1138> Incidentally in September in 2013, they passed 2000 MorphOS registrations.
17:33:00 <Eddi|zuHause> i thought "that's something peter1138 would say", and then i looked at the other commit data :p
17:35:31 <Eddi|zuHause> "(svn r16492) -Remove: support for gcc2. It hasn't been able to compile OTTD for months. All attempts to do another workaround failed."
17:35:38 <nielsm> (it's a debug build so performance is atrocious, intentional to show that the scaling actually works)
17:51:49 *** ANIKHTOS has joined #openttd
17:53:13 *** chomwitt has joined #openttd
17:55:09 *** TheMask96 has joined #openttd
17:59:29 <ANIKHTOS> alberth when you load ottd and you start a new game?? i have some new variable made the game will run the code and initialize them right??
18:00:43 <ANIKHTOS> i am experience this behavior
18:02:53 <ANIKHTOS> when i load the game the game runs wronguntil it manage topass to the slow day. then if i start another game or load a game the game works okey the odd behavior is that it autosave every nomrla day until the first slwo day pass
18:03:06 <ANIKHTOS> do you have any idea why it behaves like this???
18:08:21 <ANIKHTOS> i would apreciate if you try the patch and tell me if i break game meachanics thats what i am interest for in this stage of developemnt
18:08:56 <ANIKHTOS> showing information will be corrected in phace 2 but most important is not to break the game
18:09:20 <Alberth> if you coded initialization, it will initialize
18:09:50 <ANIKHTOS> well i declare them and then i assign a value later on
18:10:16 <Alberth> hmm, there was some function for that, have to find that
18:15:43 <ANIKHTOS> oh well i am happy i dive in the code of ottd i went from statubar-gui.cpp >english.txt>strings.cpp back to english.cpp then to another 2 files but i made the changes to display the date with time indicator now you can see the normal days pass as time
18:16:11 <ANIKHTOS> you can change the factor of how slow it is inside the game seems to work with no problems!?!?!?
18:18:08 <Alberth> try it in a multi-player game :)
18:18:16 <Alberth> hmm, can't really find it
18:19:02 <Alberth> did you look what comes up if you look for startgame or newgame (with any case) ?
18:19:54 <Alberth> although there are only 4 likely options, StartGame Startgame NewGame Newgame
18:21:43 <Alberth> hmm, simple path is to check all places where the original date gets set??
18:22:28 <ANIKHTOS> in the window where yo create the game
18:22:37 <ANIKHTOS> how is this windows called??
18:23:16 <Alberth> find a string that is used in the window, in src/lang/english.lng
18:23:32 <Alberth> then look in the code for that string name
18:24:08 <Alberth> I don't think we have windows with a name that ends in .cpp :p
18:24:48 <Alberth> nor any dashes in a filename
18:25:22 <ANIKHTOS> there is this file is that when you start a new game??
18:25:48 <Alberth> but the gui is just a layer on top of the core simulation
18:27:03 <Alberth> it's just a load of code so you can tell the simulation what you want to happen
18:27:26 <Alberth> actually doing anything is not in gui, it's in *_cmd.cpp
18:28:07 <Alberth> but starting a new game is not in the simulation, since by definition you're not running one when you activate it
18:29:53 <ANIKHTOS> int x():if i write the code liek this one tutorial say it will give default value 0 is it correct??
18:31:33 <Alberth> I'd say that is a declaration of a function named x without parameters, returning an int
18:31:56 <Alberth> it does need a semicolon at the end though
18:33:36 <Alberth> simpler solution is to just initialize explicitly, ie int x=0;
18:34:51 <ANIKHTOS> line 35 declare the variable line 74 asign a value
18:36:14 *** HerzogDeXtEr has joined #openttd
18:44:46 <Alberth> there are around 300 lines 35 in openttd
18:45:02 <ANIKHTOS> in date.cpp i declare the varialbe in line 74 of the same file i asign the value 0
18:46:16 <Alberth> oh, you're speaking of modified files even, I don't have those
18:46:23 <ANIKHTOS> line 35 uint16 _dayn; line 74 _dayn=0;
18:46:41 <ANIKHTOS> that count as intitilization right??
18:46:54 <ANIKHTOS> or you mean intitilize at declaration??
18:47:04 <Alberth> the latter does, the former I am not sure, I assume not
18:47:17 <ANIKHTOS> and amke line 35 uint16 _dayn=0;
18:48:26 <Alberth> no idea what happens at lines 36 to 73 btw
18:48:45 <ANIKHTOS> line 36 more variables declared
18:48:52 <Rubidium> 73 is in the middle of an enumeration (at least for me ;))
18:48:56 <ANIKHTOS> and line 75 i asign a value to a variable
18:49:13 <SpComb> sounds like this discussion should be happening on github
18:49:43 <Alberth> paste the relevant code part in a pastebin
18:50:02 <Alberth> you have a chat at github?
18:50:19 <SpComb> pull request review comments
18:51:21 <Alberth> that assumes I have an interest in longer game-play :p
18:51:36 <Alberth> I don't even manage to play the 150 years of the original :)
18:51:57 <Alberth> less devastated today?
18:52:25 <Wolf01> Yes, a bit, still too much hot to be comfortable
18:52:32 <SpComb> Alberth: not dedicated enough to put 100h+ into a single game of openttd? :)
18:53:04 <Alberth> nope, 40 game years is enough :)
18:53:49 <ANIKHTOS> 32c is not bad wolfi at least for my country
18:54:08 <Alberth> oh, code is not even executed together
18:54:53 <Wolf01> ANIKHTOS, yeah, but you are about 900km below me
18:55:33 <ANIKHTOS> so you are north around gemany location??
18:55:39 <SpComb> I see global variables with single-letter suffixes, so I'll just look away
18:56:11 <ANIKHTOS> i was in berlin and they had heat wave with 20c lol
18:57:37 *** rocky1138 has joined #openttd
18:59:07 <ANIKHTOS> wolf01 will you test the code to see if i break game mechanics??
18:59:37 *** Wormnest has joined #openttd
19:00:32 <Wolf01> Maybe, if I'll find time to play
19:01:14 <ANIKHTOS> and hell wolf01 is when ti goes above 40c then everythign you touch is warm going its liek lviign in a sauna
19:02:07 <ANIKHTOS> a few years back we have 7 days at 45c and a fire in the outkirt of the town to make thigns a bit worse :-) that was awfull
19:03:37 <peter1138> Hmm, even with std::chrono::high_resolution_timer I'm still seeing more than 30ms per tick.
19:05:37 <nielsm> peter1138, using it for the main loop timing?
19:05:42 <peter1138> Oh. On the other hand, my FPS is showing as 33.33.
19:06:34 <peter1138> Forgot I was editing in my PR branch of your fps patch, so I can just open the fps window :p
19:06:40 *** Thedarkb has joined #openttd
19:07:33 <peter1138> 18:03 < peter1138> Hmm, even with std::chrono::high_resolution_timer I'm still seeing more than 30ms per tick.
19:07:39 <peter1138> Well I take that back, it appears to work.
19:08:09 <peter1138> Although with that as the timing loop, maybe the drivers can be reorganised so the main game loop isn't actually in the drivers...
19:10:09 <nielsm> I think the system window interface would have to become more complicated then
19:10:13 <peter1138> 8.4 fps with that big Wentbourne save.
19:10:32 <nielsm> since it still needs to hook into a bunch of system things
19:22:23 *** synchris has joined #openttd
19:22:47 <nielsm> slightly more fps-meter changes pushed... needless to say (?) I intend it all to be squashed before a merge ;)
19:23:01 <nielsm> except perhaps a change to main loop timing behavior
19:28:44 <LordAro> nielsm: there are some here who would prefer it not to be squashed into a single commit
19:29:20 <peter1138> Depends what it is.
19:29:26 <LANJesus> so link back to a branch that has the history?
19:29:31 <LANJesus> in the commit message
19:29:39 <peter1138> Sometimes all the history is not useful.
19:30:17 <LANJesus> indeed. a bunch of "whoops forgot X" "fix formatting" "center widget" "asdfasd"
19:30:55 <nielsm> yeah in this case most of the history is just experimenting with what is actually useful
19:31:17 <LANJesus> i need to get in the habbit of commiting to my personal private repos and squashing significant updates there
19:31:50 <LANJesus> i develop across multiple machines. committing and pushing frequently is a thing : |
19:36:49 *** gelignite has joined #openttd
19:46:42 *** planetmaker_ has joined #openttd
19:50:27 *** frosch123 has joined #openttd
20:08:45 <nielsm> working on making framerate_gui use microsecond precision
20:36:02 <LANJesus> nielsm: any reason you don't use https links? for some reason your mp4 links don't work in standard http
20:36:26 <nielsm> because it's what the program I use to capture and upload with returns...
20:36:30 <nielsm> I'll check if I can reconfigure it
20:40:33 <peter1138> Did you reuse any of the existing graph code?
20:40:54 <nielsm> I tried reading it and just got confused, was faster to write my own
20:41:14 <Eddi|zuHause> i don't think the existing graphs are actually any good
20:49:45 <nielsm> funny thing is that I can't get the fps meter to show 33.33 any longer, after changing to microsecond precision
20:53:32 <nielsm> also :puke: at the coding style of the STL included with MSVC, but that's another story
20:53:53 <LANJesus> stepping through their code?
20:54:05 <nielsm> to check what it actually does
21:03:59 <Wolf01> Nice, I always wondered how fast was the FF on my systems
21:04:44 <LANJesus> yes nielsm. i like it
21:04:56 <LANJesus> some of these would be neat additions to the status bar
21:05:03 *** Supercheese has joined #openttd
21:06:37 <nielsm> maybe the window should instead collapse to just a title bar showing gameloop fps and speed factor?
21:08:36 *** Wacko1976 has joined #openttd
21:11:13 <LANJesus> nielsm: or more, if there's width?
21:21:02 <Alberth> it's a game, not a "see how fast my computer is" display :p
21:29:23 <LANJesus> i would be using it more for profiling bad (ill-performing) code
21:30:30 <nielsm> hmm, how does the GUI system respond to adding multiple controls with the same ID in a window?
21:38:15 <peter1138> Pretty sure you can't.
21:43:07 <nielsm> I think I know what the mistake is
21:43:57 <peter1138> git definitely doesn't work right on my Windows install :S
21:44:16 <peter1138> git stash; git checkout master complains of changed files...
21:46:12 <Eddi|zuHause> peter1138: nonnative eol? filename case mismatch?
21:47:25 <LordAro> at what point does the graph rendering take most of the cpu time?
21:47:53 <nielsm> when your CPU has a really bad FPU
21:48:32 <nielsm> or is bad at handling 64 bit integers
21:48:52 <peter1138> graph rendering drops my FPS from around 850 to 500
21:48:56 <peter1138> So there is quite a hit :p
21:48:59 <Eddi|zuHause> i imagine it needs to have really not much to do else
21:49:31 <peter1138> Hmm, not enough measurements in FFWD :)
21:50:13 <nielsm> yeah 512 data points can become too little for 2 seconds of graphing
21:51:08 *** Montana has joined #openttd
21:54:27 <peter1138> So 33.33 exact was another rounding product? :D
21:57:56 <nielsm> question is if you want to add some kind of time compensation into the main loop to adjust for the slight falling behind, but somehow only when there's spare time
21:58:16 <ANIKHTOS> does anyone have any idea when i start ottd with my patch code the first game i play for the N days i have chosen to slow down i will get also autosave!!!! but that behavior happens only at the first game an donly for the first N factos days
21:58:28 <ANIKHTOS> if i start or load another game after that all works fine
21:59:09 <peter1138> Yeah, I can get it to 33.3x by just making it catch up.
22:00:06 <peter1138> next_tick = next_tick + MILLISECONDS_PER_TICK instead of next_tick = cur_ticks + MILLISECONDS_PER_TICK
22:00:31 <peter1138> Needs fixing FFWD :)
22:00:53 <nielsm> but if tick processing takes too long you need to adjust for that
22:01:09 <nielsm> I think that will break when the cpu can't keep up
22:02:34 <peter1138> Yes it needs tweaking for that, I wasn't suggesting it as a full solution.
22:02:53 <peter1138> Just a quick test to show that that is what stops 33.33 from being attained.
22:04:16 <nielsm> ahh, got the sizing of the micro-window fps display right now
22:04:27 <nielsm> was passing the wrong string id to GetStringBoundingBox
22:05:40 <nielsm> now if there was a neat way to get it sized the same as the status bar height, but still be draggable like a caption...
22:06:45 <peter1138> I think if you end up in the else condition of the timer loop, then it's fair to say you can play catch up.
22:07:07 <peter1138> If you don't hit the else, then there's no spare time.
22:07:32 <nielsm> and conversely, if cur_ticks > next_tick + MILLISECONDS_PER_TICK then you're definitely behind
22:07:59 <peter1138> that may be an easier test
22:09:13 <peter1138> next_tick = _fast_forward ? cur_ticks : (cur_ticks > next_tick ? cur_ticks : next_tick) + MILLISECONDS_PER_TICK;
22:10:06 <peter1138> Oh, that doesn't wokr. Hm.
22:11:04 <peter1138> next_tick = _fast_forward ? cur_ticks : (next_tick + MILLISECONDS_PER_TICK);
22:11:05 <peter1138> if (cur_ticks > next_tick) next_tick = cur_ticks + MILLISECONDS_PER_TICK;
22:14:22 <peter1138> Hmm, the _fast_forward bit isn't right.
22:15:27 <nielsm> in ffwd it should basically disregard next_tick entirely, right?
22:15:43 <nielsm> and just process a step every chance it gets
22:16:29 <peter1138> Best to keep the existing algorithm for it.
22:16:39 <peter1138> next_tick = (_fast_forward ? cur_ticks : next_tick) + MILLISECONDS_PER_TICK; should do the trick
22:18:22 <peter1138> The main timer if condition already ignores the ticks, no need to change that.
22:26:39 <nielsm> I'd also be interested in how that plays together with the PR #6780 changes (Refactor window ticks into game ticks and realtime events)
22:26:59 *** sim-al2 has joined #openttd
22:27:00 <nielsm> would it let simulation run faster than graphics output i.e. skip frames?
22:29:11 <peter1138> I still find the frames/s display takes longer than necessary to settle.
22:35:45 <nielsm> framerate_gui.cpp:94: if (now - _framerate_timestamps[elem][point] >= TIMESTAMP_PRECISION) break;
22:35:54 <nielsm> try changing to TIMESTAMP_PRECISON/5
22:36:02 <nielsm> so it bases on just 0.2 sec
22:42:07 <peter1138> Yeah that's far better.
22:42:21 <peter1138> Of course it fluctuates a little more.
22:45:42 <peter1138> Also, actually looking at the code rather than testing it's functionality...
22:47:06 <peter1138> 5 global arrays instead of structs is a bit weird.
22:47:28 <nielsm> it started out with fewer ;)
22:47:38 <nielsm> yeah could take some cleanup
22:48:25 <peter1138> _framerate_durations[elem][_framerate_next_measurement_point[elem]] = end_time - start_time;
22:48:43 <peter1138> this->durations[this->next_point] = end_time - start_time;
22:49:13 <peter1138> It's not very C++ as it is :-)
22:54:20 *** testuser123 has joined #openttd
22:55:15 <testuser123> Note that the depot on the left side is empty
22:55:51 <Eddi|zuHause> missing electrification?
22:57:25 <glx> you made transparent too many things
22:58:09 <testuser123> @Eddi|zuHause If I force it to pass the signal, it reaches Fahrberg (its next station)
22:58:47 <Eddi|zuHause> i think it's not actually a path signal
22:59:44 <glx> with the train it's hard to see the signal pole ;)
22:59:47 <testuser123> The question mark says it's a one-side path signal
23:00:10 <Eddi|zuHause> then turn on showing path reservations
23:00:27 <Eddi|zuHause> also, press Ctrl+X, make the houses invisible, and everything else visible
23:00:36 <glx> maybe a ghost reservation yes
23:00:45 <testuser123> oh, how do I show them?
23:01:02 <glx> it's somewhere in the settings
23:01:07 <Eddi|zuHause> i think it's in one of the advanced setting categories
23:01:35 <LANJesus> i tend to apply rules of three to ... things. three globals? shove those in a struct/class/state instance. three parallel arrays? put them in a struct or make an array of structs... bla bla bla
23:03:12 <testuser123> "highlight reserved tracks"?
23:03:40 <Eddi|zuHause> exact wording might differ between languages
23:04:07 <Eddi|zuHause> __ln__: i think as long as it doesn't break anything, keep both as options?
23:06:55 <Eddi|zuHause> testuser123: difficult to see, but i still think it's missing electrification
23:07:00 <testuser123> reserved tracks are highlighted
23:07:41 <ANIKHTOS> change th e right singla to sstation to 1 way
23:07:42 <Eddi|zuHause> testuser123: there's a pylon on the right track after the first tile of the station, but none on the left track
23:07:59 <Eddi|zuHause> testuser123: so one of those seems to be missing electrification
23:11:51 <testuser123> I rebuilt all tracks that were suspicious of non electrified, but it did not help. I tried running another electriefied train there, it's all fine
23:12:23 <testuser123> Either I'm misunderstanding how you need to place path signals, or it's a bug
23:13:26 <Eddi|zuHause> open the "electrified rail" toolbar, press "convert", and drag&drop over the whole screen
23:14:49 <Eddi|zuHause> next issue might be the signal at the other end of the platform. the path reservation might not recognize it as safe waiting spot
23:15:25 <ANIKHTOS> do one of the changes in the signals
23:15:47 <Eddi|zuHause> the regular pathfinder ends its search at the station, but the path reservation wants to go on until it finds a signal to end on
23:15:53 <ANIKHTOS> either reverse the signla on top of the station or make the entry singla 1 way
23:16:26 <nielsm> peter1138: I'll look at code cleanup tomorrow
23:16:29 <glx> usually one-way signals should face the station
23:16:30 <nielsm> for now, good night :)
23:16:33 <__ln__> Eddi|zuHause: that's a reasonable solution for Windows, but the other option would be useless on at least OS X.
23:17:04 <Eddi|zuHause> __ln__: well, hide the "useless" options on systems that don't support it, or are not implemented there
23:17:54 <Eddi|zuHause> ANIKHTOS: that forum post could use an explanation text for people who don't see this conversation
23:18:04 <__ln__> i also have my doubts how useful a "real" fullscreen is on linux... does it have an advantage?
23:18:07 <testuser123> Eddi|zuHause: it says no suited tracks for the whole map
23:18:21 <Eddi|zuHause> testuser123: then look at ANIKHTOS' picture
23:18:34 <Eddi|zuHause> testuser123: that signal that he circled is what i'm talking about
23:19:15 <ANIKHTOS> the path signals and stations are tricky to use
23:19:23 <ANIKHTOS> or else traisn will nto enter or leave the station
23:19:44 <ANIKHTOS> either reverse the gignla show to be reversed or make the other signal 1 way
23:19:59 <Eddi|zuHause> imho, the back of such a one way signal should be treated like end of line, but the discussion about that went nowhere last time
23:20:38 <testuser123> ANIKHTOS: both of your suggestions let the train drive
23:20:57 <ANIKHTOS> i know i had problems in my stations
23:21:06 <ANIKHTOS> playcign path singal a specific way station works
23:21:10 <ANIKHTOS> othe rway not accessible
23:21:30 <peter1138> __ln__, yes, you can have the game at a different resolution to your desktop resolution.
23:21:31 <testuser123> Both is not what I wanted, but turning the right circled signal into a one-way path signal solves it
23:21:54 <peter1138> Not everyone cares about pixels being a 1:1 match
23:22:02 <ANIKHTOS> well change the top then
23:22:05 <testuser123> It looks like you always need enough one way path signals around stations
23:22:08 <Eddi|zuHause> testuser123: it really should be a path signal at the other end
23:22:15 <ANIKHTOS> the tracks will be the same in fucntionality
23:22:27 <__ln__> peter1138: that's assuming there are other possible resolutions configured to the X server, which quite often isn't the case, i would say.
23:22:29 <peter1138> And many people seem to find proper fullscreen mode is faster. Maybe it's a low-end GPU thing. It probably affects compositing.
23:22:43 <Eddi|zuHause> testuser123: mixing path and block signals can have nasty side effects
23:22:54 <peter1138> No, pretty much all the standard old resolutions are autoconfigured in X anyway.
23:23:18 <testuser123> Eddi|zuHause: That works. I usually thought the rule of thumb was: any area of tracks where you can drive in with one path signal must be only accessible through path signals.
23:23:23 <peter1138> And also they are there in Windows too.
23:23:33 <testuser123> But this does not suffice here
23:23:54 <Eddi|zuHause> testuser123: yes, and that applies here. train can come from one side into the station through path signal, but from other side through block signal
23:24:33 <__ln__> peter1138: yes, and switching to a low resolution on Windows messes up the taskbar, so it's not really a good idea.
23:24:47 <testuser123> Now that you say it...
23:24:53 <Eddi|zuHause> __ln__: on linux it messes your window positions
23:26:01 <__ln__> Eddi|zuHause: should we aim for a portable mess, where all the same things are messed on all platforms
23:26:12 <peter1138> Doesn't mess up my taskbar.
23:26:41 <Eddi|zuHause> __ln__: that seems like a total trump thing to do
23:27:14 <peter1138> SDL 1.2 is messed up anyway.
23:27:25 <peter1138> Wasn't there an SDL 2 patch somewhere?
23:28:20 <ANIKHTOS> eddi i need your expertise i am havign a strange bug with my code
23:28:31 <ANIKHTOS> and i do not know why i have this behavior
23:28:55 <Eddi|zuHause> how have i become the expert on terrible code?
23:29:11 <__ln__> peter1138: as you suggested "switching from fullscreen toggle to a tristate", can you elaborate what are the fullscreen mode state transitions when pressing Alt-Enter a few times?
23:29:48 <Eddi|zuHause> __ln__: windowed and <whichever fullscreen flavour was last used>
23:29:51 <peter1138> Depends what modes the backend supports.
23:30:12 <ANIKHTOS> when i start the pached ottd it does nto matter if i load a game or start a new game, for the first N ftimes where n it th eslow tiem factor the game will autosave every day !?!?!??! after that it works normally, if i load another game or start a new one there is no problem
23:30:32 <ANIKHTOS> its only when is tart the game and only for the first n days of the game
23:31:00 <ANIKHTOS> i can not grasp what is so special iin the first n days to amke game behave like this
23:31:07 <peter1138> __ln__, not really, I don't care about it enough to bother answering your passive-aggressive tone of questioning.
23:31:41 <peter1138> Seems to be a common feature of anything you say here.
23:31:50 <peter1138> Are you sure you are not Tron?
23:32:08 <Eddi|zuHause> now THAT would be a plot twist
23:35:45 <__ln__> well, see what happens when i get derailed to on-topic discussions.
23:36:02 <__ln__> should definitely avoid that again.
continue to next day ⏵
