Log for on 2nd November 2012:
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
07:00:46  *** Supercheese has quit IRC
07:13:36  *** Knogle has quit IRC
08:49:37  *** Alberth has joined
08:49:37  *** ChanServ sets mode: +v Alberth
08:54:56  *** Eagle_Rainbow has joined
08:55:32  *** Eagle_Rainbow has quit IRC
10:35:04  *** LordAro has joined
10:35:04  *** ChanServ sets mode: +v LordAro
13:29:58  *** fonsinchen has joined
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
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
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
16:37:11  *** ChanServ sets mode: +v LordAro
16:45:28  *** FLHerne has joined
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
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
18:17:14  *** ChanServ sets mode: +v andythenorth
18:45:18  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24661 || Logs: || 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
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
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
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>
20:51:13  <Eagle_Rainbow> Thanks, planetmaker
20:51:31  <Eagle_Rainbow> I see what you mean...
20:51:32  <frosch123>
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. <-- 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> <- 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://
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
21:40:10  *** andythenorth has left
21:40:24  *** Alberth has left
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 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> 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

Powered by YARRSTE version: svn-trunk