Times are UTC Toggle Colours
00:18:27 *** frosch123 has quit IRC 00:26:36 *** LordAro has quit IRC 00:55:13 *** FLHerne has quit IRC 03:37:33 *** Knogle has quit IRC 03:38:15 *** Knogle has joined #openttd.dev 07:00:46 *** Supercheese has quit IRC 07:13:36 *** Knogle has quit IRC 08:49:37 *** Alberth has joined #openttd.dev 08:49:37 *** ChanServ sets mode: +v Alberth 08:54:56 *** Eagle_Rainbow has joined #openttd.dev 08:55:32 *** Eagle_Rainbow has quit IRC 10:35:04 *** LordAro has joined #openttd.dev 10:35:04 *** ChanServ sets mode: +v LordAro 13:29:58 *** fonsinchen has joined #openttd.dev 13:29:59 *** ChanServ sets mode: +v fonsinchen 13:30:53 <fonsinchen> Hi, nice to have talk permission here. Thanks 13:33:29 <Alberth> hi :) 13:35:50 <Yexo> hi 13:59:04 *** frosch123 has joined #openttd.dev 13:59:04 *** ChanServ sets mode: +v frosch123 15:05:26 <Belugas> hello 15:15:39 <frosch123> hello belugas :) 15:19:02 <Belugas> hey sir frosch123 :) 15:19:11 <Belugas> and all the others ;) 15:19:21 <Belugas> hoo... i see Yexo have been busy :) 15:19:24 * Belugas checks 15:19:41 <Yexo> it's about as far as I was two weeks ago 15:19:50 <Yexo> basically it should build a libOpenTTD.so 15:20:10 <Yexo> you need another small layer of java code to actually make it work, that part is in the SDL 2 repo 15:20:35 <Yexo> oh, did I already mention the final application will crash in the SDL code directly after starting? :p 15:30:57 <fonsinchen> I've started to leave old versions of cargodist around in the repository, so that you can refer to them when needed. 15:31:20 <fonsinchen> Generally there will be a new branch everytime I rebase. It's called cd<svn version> 15:31:34 <fonsinchen> For example cd24660 for the one I've just pushed. 15:32:09 <fonsinchen> I've also moved those fix commits previously dangling on top of the "cd" branch to their proper places. 15:47:09 <Yexo> so cd24660 contains all your changes? 15:49:20 <fonsinchen> yes 15:49:57 <fonsinchen> cd also does, but cd24660 stays the same forever, while cd gets overwritten whenever I rebase 15:53:03 <planetmaker> hello 15:58:22 <planetmaker> nice to see you here, fonsinchen :-) 15:58:37 <fonsinchen> thanks 16:13:51 <frosch123> wtf... there is a special multiplayer highscore screen :o 16:14:43 <planetmaker> hu, really?! 16:15:35 <frosch123> truth to be told... did anyone know about that one? :p 16:16:02 <frosch123> /* In a network game show the endscores of the custom difficulty 'network' which is the last one 16:16:04 <frosch123> * as well as generate a TOP5 of that game, and not an all-time top5. */ 16:17:05 <planetmaker> uhm... *I* did not know about it 16:17:09 <planetmaker> or not anymore 16:17:33 <frosch123> i thought the highscore wouldn't even be displayed in multiplayer 16:17:43 <frosch123> since it would iterrupt the game or something 16:17:47 <frosch123> but i never played so long :) 16:18:51 <Yexo> highscore for multiplayer? That's new to me too 16:19:28 <fonsinchen> Maybe there's a bug which actually prevents it from being shown. I've also never seen it. 16:35:43 *** LordAro has quit IRC 16:37:10 *** LordAro has joined #openttd.dev 16:37:11 *** ChanServ sets mode: +v LordAro 16:45:28 *** FLHerne has joined #openttd.dev 17:05:28 <Belugas> nope, you did not, Yexo :) but i do have to find how to set everythinp up first ;) 17:06:07 <Yexo> you'll need the android sdk and ndk, documentation for that is on the android developer website 17:06:38 <Yexo> if you have that setup and can compile openttd with my patch+script, I'll make sure to write some documentation on how to do the final steps with sdl 17:11:24 *** fonsinchen has quit IRC 17:46:26 <Belugas> i have both already installed, played a bit, just to get the feeling 17:46:56 <Belugas> i will take the time to try it out, be certain :) 17:49:01 * Alberth feels cery certain 17:50:31 <Alberth> *very 18:14:21 *** LordAro is now known as Guest4211 18:14:22 *** Lord_Aro has joined #openttd.dev 18:14:22 *** ChanServ sets mode: +v Lord_Aro 18:14:22 *** Lord_Aro is now known as LordAro 18:17:13 *** andythenorth has joined #openttd.dev 18:17:14 *** ChanServ sets mode: +v andythenorth 18:45:18 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24661 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:46:30 *** FLHerne has quit IRC 19:23:48 <Belugas> chery berry raisins? 19:25:46 <Alberth> ? you said "be certain" :) 19:52:25 *** Zuu has joined #openttd.dev 19:52:25 *** ChanServ sets mode: +v Zuu 19:55:31 <Yexo> frosch123: what do you think about a new filter for the advanced settings gui that instead of displaying the settings of the current game displays the settings for a new game (and let's you edit those settings) 19:56:01 <frosch123> that's not a "filter" :) 19:56:24 <Yexo> s/filter/option/ :p 19:56:25 <frosch123> i would rather add a new entry to the menu 19:56:31 <frosch123> "current game settings" 19:56:35 <frosch123> "new game settings" 19:56:38 <frosch123> "rcon settings" 19:56:51 <Yexo> might be better indeed 19:57:33 <frosch123> via profiles you would be able to transfer between them 19:57:51 <frosch123> s/rcon settings/rcon newgame settings/ 19:58:36 <Yexo> enough possibilities there :) 19:58:43 <Yexo> time to take a proper look at cargodist 19:59:44 <frosch123> do we have some task for the "community" (as eagle_rainbow called it)? 20:00:01 <frosch123> maybe the basic/advanced/expert categories? 20:00:23 <frosch123> or does that require knowledge what all those settings do, like for the help texts? 20:00:23 <Yexo> we discussed that idea often enough that it can be implemented, so yes 20:00:57 <planetmaker> frosch123, that knowledge can be aquired or asked for in cases of doubt. So anyone with motivation really can do it. The task is clear 20:01:00 <frosch123> though adding stuff to settingsgen for categories is more than some classificaiton in the ned 20:01:08 <planetmaker> and the individual attribution of settings can always be negotiated 20:01:13 <frosch123> also, what about the news settings? 20:01:30 <frosch123> moving them to advanced settings would drop the "set all news type to off/ticker/full" 20:01:32 <Yexo> if remotely possible, should be included in the game gui 20:01:40 <frosch123> but personally i never saw any use in that button 20:01:46 <frosch123> i rather pressed it by mistake :p 20:01:48 <Terkhen> and what about transparency? :P 20:02:01 <Yexo> transparency is different 20:02:32 <frosch123> transparency is a toolbar. at least i keep it open during the game like a construction bar 20:03:14 <Terkhen> ok :) 20:03:17 <planetmaker> I actually make use of that button. But only once after I delete my cfg. And then switch on to full the two or three categories which are interesting to me 20:03:19 <Zuu> So in a remotely future, transparency is added to advanced settings and a posibility to form toolbars out of settings. 20:03:45 <planetmaker> Not sure transparency need be in adv. settings. But... well, maybe 20:04:02 <frosch123> Zuu: needs icons for all settings :p 20:04:21 <Zuu> Yeah, so for now I agree to not include transparency in adv. settings. 20:04:33 <planetmaker> frosch123, we might need a few more for all display settings, yes. But... that should be done with two or three at most 20:04:44 <planetmaker> it's a separate task so far, I think ;-) 20:05:35 <Yexo> so if anyone cares to write an accurate description of how we want the basic/advanced/expert settings filters to work eagle_rainbow could implement that 20:07:02 <frosch123> i see it as: 1) add another field to the settings.ini stuff, 2) add filters to the gui in the same dropdown as the deviation stuff. 3) make some initial classification of the settings 20:07:26 <Yexo> agreed 20:08:50 <frosch123> for 3 I would give examples like: "multiple newgrf engine sets" is expert, "date format of saves" is "advanced", "infrastructure cost" is basic 20:09:35 <Yexo> just go ahead and post that, the details can be worked out when there is a patch, I think on the basics we agree 20:10:33 <frosch123> moving news settings to the adv. settings would mean dropping the old item from the menu 20:10:39 <frosch123> right? 20:10:45 <Yexo> yes 20:11:11 <frosch123> alternatively it could open the settings window with a preset string filter "news" or similar 20:11:22 <frosch123> but that would require translation-specific filtering 20:11:31 <frosch123> and sounds more complicated than actually useful :p 20:11:41 <Yexo> GetString(STR_NEWS_CATEGORY), set filter string to that 20:11:58 <frosch123> plus stripping control chars 20:12:13 <frosch123> maybe we already have that for scripts? 20:12:25 <Yexo> str_validate maybe? 20:12:36 <frosch123> unless it replaces weird stuff with "?" :p 20:13:08 <frosch123> anyway, give that as a task? or is it to vague/unneeded? 20:13:19 <Yexo> no, that's fine 20:13:30 <Yexo> instead of directly giving it as task maybe just add it to the todo list on the wiki? 20:13:34 <Yexo> than we can point to that again 20:13:58 <frosch123> yeah, sounds more useful than in some random thread where it gets lost :) 20:15:46 <Yexo> str_validate can strip control characters and you can set whether it replaces to ? or not 20:15:58 <Yexo> so it seems to be able to do everything required :p 20:16:01 <Yexo> doesn't make it a good feature though 20:16:29 <frosch123> well, at least you won't be able to switch languages while the window is open :p 20:17:03 <Yexo> wasn't the plan to move the language switch dropdown to that window? 20:17:34 *** Eagle_Rainbow has joined #openttd.dev 20:18:54 <Yexo> @voice Eagle_Rainbow 20:18:54 *** DorpsGek sets mode: +v Eagle_Rainbow 20:19:01 <Yexo> welcome 20:19:16 <Eagle_Rainbow> Hi 20:19:26 <Eagle_Rainbow> thanks for speak rights :) 20:19:55 <Eagle_Rainbow> wanted to experience such a session really live ... 20:20:20 <Yexo> you just missed a discussion about new planned features for the advanced settings window 20:20:34 <Yexo> but I think frosch123 is already summarizing it and putting it on the wiki 20:20:35 <Eagle_Rainbow> well, bad luck for me :) I will read it in the logs then... 20:20:48 <Eagle_Rainbow> ok, then I'll focus on that there... 20:21:24 <Eagle_Rainbow> @frosch: if you remember it, I'd be glad to have a short PM via the board when you are finished... 20:21:53 <frosch123> i will just post in the topic 20:22:03 <Eagle_Rainbow> that's even better 20:25:06 *** FLHerne has joined #openttd.dev 20:33:41 <Belugas> [15:24] <+Alberth> ? you said "be certain" :) <-- what??? Certain is not an english word????? 20:33:51 <Belugas> damned... 20:35:00 <Alberth> it's not a verb :) 20:35:59 <Eagle_Rainbow> certainly, it isn't :) 20:37:58 <Belugas> i'll be damned... 20:47:01 <planetmaker> Eagle_Rainbow, development most often is better done in public. may sometimes be more enervating. But results often are better ;-) And often it's quicker, too 20:47:24 <planetmaker> due to input or at least giving other people time to at least think about it and give input when it is appropriate 20:47:37 <planetmaker> (and that's the point of this channel and the forum) 20:48:24 <planetmaker> besides that I'm really happy about the "entry" you made with your patch, Eagle_Rainbow 20:48:57 * Yexo points planetmaker to the fact that there is still an unreviewed patch :p 20:49:20 <planetmaker> :D 20:49:41 <planetmaker> can you point a bit more detailed? 20:49:53 <Yexo> http://www.tt-forums.net/viewtopic.php?f=33&t=59329 20:51:13 <Eagle_Rainbow> Thanks, planetmaker 20:51:31 <Eagle_Rainbow> I see what you mean... 20:51:32 <frosch123> https://secure.openttd.org/wiki/GUI_re-arrangement 20:51:40 <frosch123> expanded on the basic/adv/expert settings thingie 20:51:43 <frosch123> added news settings 20:51:51 <frosch123> and wrote a paragraph about rcon seetings 20:51:53 <Eagle_Rainbow> @Frosch123: thanks, I will have a look at it in a minute 20:52:10 <frosch123> esp,. in the latter i wrote a lot more than we discussed earlier.... 20:52:17 <frosch123> .... turned out there is more to it :p 20:52:31 <Eagle_Rainbow> @planetmaker: I think it's really great that you also make those discussion available to all 20:54:02 <Yexo> dropping difficulty levels for NewGRFs seems a good idea 20:54:30 <Yexo> I think the same could be done for AIs / GSs 20:54:48 <frosch123> Yexo: i have a half finished queue abuot the ai/gs issue 20:54:53 <Yexo> It's really hard to make one AI really behave better or worse depending on a few options 20:55:39 <planetmaker> hm. http://www.tt-forums.net/download/file.php?id=165459 <-- I'm missing the doxygen for the newly introduced functions 20:55:53 <Yexo> I'm just wondering how useful it really is. First you have to set a difficulty level for each AI, but if you're configuring at that level you'll change different settigns per AI anyway 20:55:53 <planetmaker> ^ @ Eagle_Rainbow 20:56:02 <Yexo> which means the difficulty level would be custom again 20:56:06 <frosch123> basically i turn the difficulty stuff into settings profiles for ais 20:56:15 <frosch123> the ai does not have to use all profiles 20:56:22 <Eagle_Rainbow> planetmaker, I will look at it right away 20:56:29 <frosch123> and it does not have to make all settings apply to a profile 20:56:38 <Yexo> that sounds much better :) 20:56:48 <Yexo> I'll hold my opinion for a while about that :) 20:56:49 <frosch123> finally there is a global profile selection for random ais 20:57:03 <planetmaker> or do I miss their doxygen in the .h (if done so)? 20:57:50 <Eagle_Rainbow> planetmaker, must have a look - it has been two days since I did that ;) 20:58:04 <frosch123> Eagle_Rainbow: planetmaker: about the server list filtering: wouldn't it be more useful to put the filter editbox into the window, and instead put the player name into a popup entrywindow? 20:58:06 <planetmaker> k :-) 20:58:20 <frosch123> i mean, how ofter do you change your name, compared to how often you might want to filter :p 20:58:31 <planetmaker> I haven't looked yet so far. But... I agree 20:58:40 <frosch123> i only looked at the screenshot :p 20:58:54 <planetmaker> also it wouldn't hurt to have two input boxes.... but that's a chapter on its own 20:59:02 <planetmaker> I didn't look at the screenshot :-P 20:59:27 <Eagle_Rainbow> frosch123, well, I also wanted to solve that double-edit box thingy, as I think this is a general matter 20:59:40 <Eagle_Rainbow> but yes, we could just swap the name out... 20:59:51 <frosch123> i seem to remember that there was some patch about that somewhere 20:59:54 <planetmaker> hm, screenshot shows me both edit boxes? 21:00:02 <Eagle_Rainbow> Anyway, I was always asking myself why it was at the multiplayer screen and not bunkered in some settings screen 21:00:24 <planetmaker> yes. the player name would make sense to have in the adv. settings (too) 21:00:25 <Eagle_Rainbow> frosch123, yes, in the same topic - but the problem there was, that the filter text was swapped out and not the name 21:00:42 <planetmaker> I'd not opt for removing access to the player name from the network lobby 21:00:51 <Zuu> Say an AI/GS have setting with values from 0 to 100. Peraps allow the script to provide a classification method which takes two parameters. Setting name and setting value. It will return "easy", "medium" or "hard" (possible as an enum). With this, OpenTTD can show the difficulty of the current setting value for each AI/GS setting. 21:01:43 <Eagle_Rainbow> planetmaker, so, instead do what? Have a button with "set player name" or something like this? 21:02:01 <Eagle_Rainbow> do you have something special at your mind already? 21:02:02 <Zuu> In most cases the setting with values from 0 to 100 may have two borders at eg 33 and 67. But the direction of easy/hard is not always the same, and some may not have hard at the far end. etc. so a function is probably needed. 21:02:06 <planetmaker> Not actually sure... does the two input boxes work (I didn't compile yet)? 21:02:16 <Eagle_Rainbow> planetmaker, well, at least for me... yes... 21:02:29 <Eagle_Rainbow> I tried to play around as much as I could, and did not achieve to crash it... 21:02:40 <Yexo> in any case it would be best to split of the changes required to make two edit boxes work from the changes to the network gui 21:02:51 <planetmaker> yup 21:02:55 <Zuu> But the good thing about dropping easy/medium/hard from AIs/GS is that it reduce the amount of data that is mandatory to provide. 21:03:08 <Eagle_Rainbow> Yexo, would be ok with me 21:03:24 <Eagle_Rainbow> planetmaker, concerning the doxygen: it's there for the two - in the header file 21:03:54 <planetmaker> also for those in misc_gui.cpp? 21:04:26 * Eagle_Rainbow is looking 21:05:14 <Eagle_Rainbow> shame on me - at least not for InitEditBoxAndSetCurrent, but for SetCurrentEditBox it's there... 21:05:46 <Eagle_Rainbow> I'll add the doxygen for InitEditBoxAndSetCurrent in a minute 21:05:50 <Yexo> InitEditBoxAndSetCurrent <- without having looked at the patch, that name sounds wrong 21:06:03 <planetmaker> I actually wonder whether the MultiQueryStringWindow class shouldn't be in another file... but don't know yet which :-) 21:06:06 <Eagle_Rainbow> due to the "And" you mean? 21:06:12 <Yexo> yes 21:06:24 <planetmaker> MultipleQueryStringBaseWindow I mean 21:06:26 <frosch123> http://www.tt-forums.net/viewtopic.php?f=32&t=63164&p=1052664#p1052664 <- comments/corrections? 21:06:30 <Eagle_Rainbow> I know what you mean 21:07:21 <Yexo> frosch123: looks fine 21:07:24 <Eagle_Rainbow> However, I didn't find a better place as well. 21:07:49 <Eagle_Rainbow> Yexo, the problem with the function is that you really need to do both at a time 21:08:06 <Zuu> Eagle_Rainbow: My first larger patch was to allow multiple edit boxes on the screen at the time. (but in different windows) Nice to see that you try to bring that one step further and solve the text storage issue so that its possible to have multiple edit boxes in the same window. 21:08:14 <Eagle_Rainbow> you want to do the init, but you should know that it also switches the current edit box 21:08:24 <Eagle_Rainbow> Zuu, thanks :D 21:08:52 <Eagle_Rainbow> I thought of adding a special note comment to the doxygen, but I had the feeling that this was not enough... 21:09:19 <Eagle_Rainbow> when reading the code you wouldn't notice, as you tyically are not reading the comments of the method... 21:09:32 <Eagle_Rainbow> so I thought that this name was "the least problem"... 21:10:17 <Eagle_Rainbow> so I thought that this name was "the smallest problem"... 21:10:37 <Eagle_Rainbow> If you have better ideas, please suggest! 21:12:11 <Eagle_Rainbow> Concerning why i chose misc_gui.cpp: The implementation of the methods for QueryStringBaseWindow is also there... 21:12:45 <Eagle_Rainbow> As MultipleQueryStringBaseWindow is inheriting from QueryStringBaseWindow I thought that would be the best way... 21:14:05 <planetmaker> dunno... maybe even a separate file 21:14:21 <planetmaker> but it'll be a short one. So... well. Just a thought :-) 21:14:24 <Yexo> is there an inherent difference between MultipleQueryStringBaseWindow and QueryStringBaseWindow or can support for multiple edit boxes be added to the latter? 21:15:09 <frosch123> well, in the long run i would prefer if editboxes can just be specified via the widget tree and they just work :) 21:15:27 <planetmaker> ^ :-) 21:15:38 <frosch123> so, i would prefer enablign all windows as well, over a special MultipleQueryStringBaseWindow class 21:15:55 <frosch123> ofc. that is a lot of work, since it would likely need touching all windows with editboxes 21:16:02 <Zuu> If widgets automatically get sufficent enough memory for storing data, then most of the problems are solved :-) 21:16:32 <frosch123> as such, i would prefer a server filter with the playername in a popup, rather than two editboxes for now :) 21:17:10 <frosch123> i think just displaying "player name:", the current name and a button to change it, is not that base 21:17:10 <Eagle_Rainbow> frosch123, I had a thought on that as well, but for an "initial task" for a noob like me, I thought that number was too big -- and to invasive to the comding 21:17:14 <planetmaker> I don't quite get that, frosch123. You think introducing this special window class is not a good move? 21:17:38 <frosch123> planetmaker: exactly :) 21:18:07 <frosch123> i think a special window class heads in the wrong direction 21:18:09 <planetmaker> he.... as it makes "the real solution" less likely to be tackled? 21:18:10 <planetmaker> hm, k 21:18:17 <Zuu> Perhaps Window could get an additioal pointer to an optional data structure that holds text widget buffers? 21:18:19 <planetmaker> the widget approach Zuu mentioned sounds better, yes 21:18:20 <Yexo> I agree with that, in this case it's better to research first if it's doable to solve the general problem 21:18:59 <Zuu> Or if we add some pool that uses window + widget num as key. 21:19:04 <Eagle_Rainbow> and as far as I get frosch123, he's heading more towards the idea to go around the problem, right? 21:19:11 <frosch123> i do not expect Eagle_Rainbow to work on the editbox issue, since it is a huge task; as such i want to point out that a playername via popup is totally fine for me :) 21:19:38 <planetmaker> right. Ok, fine with me 21:19:38 <Yexo> smallmap<widget index, textbuffer> member for each window? 21:19:52 <planetmaker> ^ would build on an existing solution indeed 21:20:04 <frosch123> Yexo: yeah, something like that :) 21:20:05 <Zuu> Yexo: that could work 21:20:11 <frosch123> plus the drawing of the editbox 21:20:31 <frosch123> plus WidgetIndex parameters to all OnXXX functions which deal with editboxes 21:20:39 <frosch123> plus integration of the OSK to deal with that stuff :p 21:20:47 <Zuu> yep :-) 21:21:08 <planetmaker> Actually... the latter might be interesting... how does the OSK look in Chinese? The same as for English? 21:21:12 <Zuu> you forgot intraction with keyboard input 21:21:36 <Eagle_Rainbow> yes, and it was a hard thing to get it running even with MultipleQueryStringBaseWindow 21:22:00 <Eagle_Rainbow> It's totally unaware of multiple edit boxes and digs deep into the Window... :( 21:22:10 <frosch123> STR_OSK_KEYBOARD_LAYOUT :`1234567890-=\qwertyuiop[]asdfghjkl;' zxcvbnm,./ . 21:22:12 <frosch123> STR_OSK_KEYBOARD_LAYOUT_CAPS :~!@#$%^&*()_+|QWERTYUIOP{{}}ASDFGHJKL:" ZXCVBNM<>? . 21:22:13 <frosch123> planetmaker: ^^ 21:22:18 <frosch123> the number of keys is unchanged though 21:22:35 <planetmaker> ah, right 21:22:37 <Eagle_Rainbow> That was also one of the reasons, why I had a second class for it... 21:23:09 <michi_cc> frosch123: "game options" should probably retain language, resolution and fullscreen settings (and gain blitter and font settings). 21:24:18 <planetmaker> michi_cc, and volume settings 21:24:53 <planetmaker> (the special music / sound window imho is not really needed and could be merged) 21:25:22 <Yexo> but it allowed you to create playlists! 21:25:35 <Yexo> quite useless windows indeed ;) 21:26:15 <Zuu> Perhaps allow links to other windows from the adv. settings window if such special cases are needed to be maintained. 21:26:40 <Zuu> Eg down in the tree there is a line which opens the playlist window. 21:27:27 <frosch123> planetmaker: does the "volume" setting actually work? :p 21:27:44 <frosch123> i thought it was some dummy element without function for years :p 21:27:55 <frosch123> or is that only for music and certain platforms? 21:27:57 <planetmaker> yes, I think so 21:28:01 <Eagle_Rainbow> If I may summarize the current state on the multiplayer filter: 1. the MultipleQueryStringBaseWindow is not desired; 2. we should for a larger thing to allow multiple edit boxes natively by the Window class; 3. For the time being move the player name on separate window (with a button or something like this), whilst retaining the filter on the network list window. Right? Did I forget something? 21:28:02 <planetmaker> so = not work 21:28:25 <planetmaker> sounds about what I'd summary discussion to, too, Eagle_Rainbow 21:28:32 <planetmaker> *summarize 21:28:37 <frosch123> Eagle_Rainbow: sounds right 21:28:52 <frosch123> btw. i think there is already some generic entry-window class 21:28:53 <Zuu> Eagle_Rainbow: Sonuds good to me. It would be good if the player name is shown near the button. 21:29:09 <Zuu> Yep, the query string window. 21:29:13 <planetmaker> frosch123, but it's very enerving that you can't switch on and off sound for title game from main menu 21:29:14 <Yexo> please split that in two patches though: 1. Only show player name and add a button to change it. 2) Add new server name filter 21:29:57 <planetmaker> we like atomic patches :-) 21:30:00 <Eagle_Rainbow> Ok, then lemme suggest: I'll summarize this briefly for the topic (with reference to this log here); I would start trying to implement these two separated patches... 21:30:18 <planetmaker> if you wish, yes :-) 21:30:22 <Yexo> sounds good :) 21:30:26 <Eagle_Rainbow> Once finished, I'll pass by here again... 21:30:31 <Eagle_Rainbow> (or via the forum?) 21:30:31 <planetmaker> Eagle_Rainbow, what do you use for creating patches? hg or git? 21:30:39 <Eagle_Rainbow> it's git 21:30:40 <planetmaker> (if not, I suggest to choose on of those) 21:30:43 <planetmaker> ok :-) 21:30:56 <Eagle_Rainbow> that's why I am also about 4h behind the svn commits... 21:31:03 <planetmaker> hu? 21:31:28 <Eagle_Rainbow> yes, the git repository only gets the svn commits after a certain time... 21:31:32 <planetmaker> both, hg and git are synced about every commit nearly instantaneous 21:31:37 <Eagle_Rainbow> nope... 21:31:47 <Eagle_Rainbow> I had lags with around 24h... 21:31:55 <Eagle_Rainbow> sometimes it's 4h... 21:32:03 <Eagle_Rainbow> but they come typically over night for me... 21:32:05 <planetmaker> peculiar. But I never checked git. hg works within the minute or 5 usually 21:32:42 <planetmaker> maybe different cron 21:32:52 <michi_cc> Eagle_Rainbow: I never see any lag using git://git.openttd.org/openttd/trunk.git 21:33:33 <Eagle_Rainbow> I am using that, too, but in the last four days I had lags >4h in almost any case... 21:33:56 <Eagle_Rainbow> So, for example, your commit of my patch Yexo, was available to me only the next morning 21:34:22 <Eagle_Rainbow> (your commit was somewhere like 11pm CET, and I was awake until 1am... the patch was not in git yet) 21:34:28 <Eagle_Rainbow> on next morning, it was there.. 21:34:42 <michi_cc> Both the git and the hg repository are directly updated in a svn post-commit hook, so unless something is hogging the server there should be no lag at all. 21:34:59 <Eagle_Rainbow> then lemme observe this once again and write it down exactly... 21:35:14 <Eagle_Rainbow> I will revert back to you, michi_cc, then? 21:35:17 <planetmaker> sometimes it happens to lag... but I've never seen it that extreme 21:38:41 * Eagle_Rainbow just checked the sync status between svn and git and currently it's ok for him 21:38:59 *** Supercheese has joined #openttd.dev 21:40:10 *** andythenorth has left #openttd.dev 21:40:24 *** Alberth has left #openttd.dev 21:43:02 <frosch123> [22:23] <michi_cc> frosch123: "game options" should probably retain language, resolution and fullscreen settings (and gain blitter and font settings). <- please add such comments to the wiki 21:43:06 <frosch123> here they get lost :) 21:43:32 <frosch123> the wiki is a collection of ideas, no finished plan 21:46:14 * Eagle_Rainbow has updated topic http://www.tt-forums.net/viewtopic.php?f=33&t=59329&p=1052668#p1052668 with the summary. 21:47:09 <michi_cc> frosch123: I'd do it, but the wiki is currently only telling me I have entered a wrong password. Works on flyspray or the main site login, so I think I'm entering the right password :) 21:47:38 <planetmaker> michi_cc, any funny characters in it? 21:47:40 <frosch123> ah, the underscore issue:p 21:47:45 <frosch123> "michi_cc" :p 21:47:49 <planetmaker> :O 21:47:57 <frosch123> well, no wiki for you :p 21:48:00 <planetmaker> underscore is funny for wiki. That's "funny" 21:48:09 <frosch123> planetmaker: underscore means space 21:48:17 <frosch123> and there is no user "michi cc" 21:48:29 <michi_cc> TB fixed it, but maybe it got unfixed by some update. 21:58:10 <planetmaker> good night 22:02:06 <frosch123> updated the section about the game options 22:20:41 *** FLHerne has quit IRC 22:33:32 <Yexo> UpdateLandscapingLimits() is called when the game is paused 22:33:41 <Yexo> but the limits itself are stored in the savegame 22:34:58 <Yexo> can't that lead to desyncs? player A does a lot of terraforming/destroying/tree planting, player B joins the game. Game pauses due to join. In the meantime the server and other players increase the limits for player A, now player A tries to terraform again, succeeds for player B but fails for all others 22:36:57 <frosch123> iirc it uses network frames, not game ticks 22:37:20 <frosch123> they also run in pause mode; but i have no idea how they are synced to clients 22:38:08 <Yexo> it's updated from UpdateLandscapingLimits() which is called from StateGameLoop() 22:38:22 <frosch123> which comes from ClientNetworkGameSocketHandler::GameLoop 22:39:08 <Yexo> I can't find any special syncing to clients, which is required 22:40:01 <frosch123> ClientNetworkGameSocketHandler::Receive_SERVER_FRAME 22:40:11 <frosch123> it sets _sync_frame 22:40:33 <frosch123> which is also compared to _frame_counter 22:40:43 <frosch123> so i can only assume that it is synced in some way 22:42:29 <Yexo> hmm, might work that way 22:42:56 <Yexo> I wasn't aware clients synced on network frames instead of ticks 22:43:05 <Yexo> seems logical now I think about it 22:55:14 *** Zuu has quit IRC 23:12:57 <frosch123> night 23:13:00 *** frosch123 has quit IRC 23:23:14 <Eagle_Rainbow> Still there, Yexo? 23:23:44 <Yexo> yes 23:23:52 <Yexo> but not much longer 23:24:24 <Eagle_Rainbow> (me neither) then I'll be as short as possible; I am trying to swap out the the player's edit box from the network list 23:24:39 <Eagle_Rainbow> I wanted to get rid of WID_NG_CLIENT for this... 23:25:02 <Eagle_Rainbow> when trying to do so, I saw that it's referenced in script/api/script_window.hpp 23:25:23 <Eagle_Rainbow> (WID_NG_CLIENT is the Edit Box on that screen) 23:25:39 <Eagle_Rainbow> It seems that the edit box is fostered quite a lot :-| 23:26:15 <Eagle_Rainbow> As you seem to be familiar with all this AI stuff, what's your idea on this? 23:26:20 * Eagle_Rainbow has no clue... 23:26:50 <Yexo> I have no clue either why that's referenced there. The multiplayer window cannot be opened at any point that a GameScript is running 23:27:19 <Eagle_Rainbow> However, it seems that they have thought about this, as there is entire ENUM for that stuff: /** Widgets of the #NetworkGameWindow class. */ 23:27:19 <Eagle_Rainbow> enum NetworkGameWidgets { 23:28:05 <Eagle_Rainbow> Or is it something for automization? Like automated testing or so? 23:30:40 <Yexo> no idea, it's been there since the the GSWindow class was created 23:30:48 <Yexo> feel free to remove that reference in your patch 23:31:06 <Eagle_Rainbow> ok, will do so 23:31:25 <Eagle_Rainbow> thanks... 23:32:28 <Yexo> bugs.openttd.org/task/5353 as reminder 23:32:30 <Yexo> good night 23:32:58 <Eagle_Rainbow> night! 23:33:30 <Eagle_Rainbow> and me too ;) 23:33:58 *** Eagle_Rainbow has quit IRC