IRC logs for #openttd on OFTC at 2010-06-24
⏴ go to previous day
00:32:14 *** Chris_Booth has joined #openttd
02:00:50 *** JVassie_ has joined #openttd
02:20:14 *** fjb is now known as Guest974
02:26:44 *** rhaeder1 has joined #openttd
04:18:10 <ccfreak2k> Is there a setting to cause trucks to move up in a roro stop if the truck ahead pulls out and it's still loading?
04:53:26 *** SirSquidness has joined #openttd
04:56:22 *** Eddi|zuHause has joined #openttd
05:21:11 *** Kurimus has joined #openttd
05:29:39 <planetmaker> there isn't, ccfreak2k
05:30:05 <planetmaker> I also wouldn't like, if the bus moved just to the front of the bus stop during the time I try to climb into it ;-)
05:31:19 <ccfreak2k> Even if there were ten other buses queued behind it?
05:31:40 *** HerzogDeXtEr has joined #openttd
05:34:45 <planetmaker> you're up early :-)
05:51:29 *** HerzogDeXtEr1 has joined #openttd
05:53:07 *** HerzogDeXtEr2 has joined #openttd
05:53:08 <ccfreak2k> Modern Motion is a weird song.
06:36:42 *** ^Spike^ has joined #openttd
07:11:16 *** Progman has joined #openttd
07:15:56 *** Grelouk has joined #openttd
07:17:03 <ccfreak2k> Finally got around to using timetables.
07:25:10 *** andythenorth has joined #openttd
07:27:27 <kamil> Ammler: ok I install expect, but this same problem... maybe any lib to add $PATH ?
07:31:18 *** einKarl has joined #openttd
07:32:41 <kamil> but i can't running this in screen ?:)
07:33:35 <Rubidium> I see no reason why something that runs on a normal console can't run in screen
07:34:31 <ccfreak2k> If it uses X, it will need a few env vars set to use the screen.
07:35:20 <Rubidium> as if X is used on many servers
07:36:18 <ccfreak2k> The program doesn't care if it's a server.
07:38:30 <Rubidium> ap+ (as far as I know) only works correctly on a dedicated server, which implies a server without the need for X so *why* would they think: heh, lets add a dependency on X for ap+?
07:43:45 <kamil> ok how to running ap+ to console and quit console, but program still runing?
07:44:05 <planetmaker> kamil: we run ap+ always in screen
07:44:06 <planetmaker> use screen for that :-)
07:45:05 <kamil> ahhh... i push ctrl+d... but only ctrl+a, ctrl+d ;)
07:45:10 <ccfreak2k> Rubidium, I don't pretend to understand what programmers are thinking when they include dependencies.
07:56:12 <kamil> ok how get any log from irc module? i see: '[::mod_irc::network] IRC connection established' - but can't see session in my channel :)
07:57:06 <planetmaker> the channel it joins is configured in the cfg
07:57:06 <planetmaker> if it doesn't exist...
07:57:15 <planetmaker> ap+ has also a debug mode somewhere
07:59:04 <kamil> planetmaker: i configure to use irc module... ok i see: [::irc] IRC connection closed unexpected, reconnecting... but what is wrong... debug mode set to 1
07:59:39 <planetmaker> channel inexisting? Other network than oftc?
08:01:13 <kamil> channel exist... network: quakenet... before avignon is connecting and work :)
08:02:05 <planetmaker> well. other client other limits. avignon working doens't mean ap+ or vice versa
08:05:54 <kamil> i try to other server :)
08:06:51 <ccfreak2k> "start date" in the timetable doesn't work as I expect.
08:20:32 *** openttd has joined #openttd
08:20:32 <openttd> Starting new game: 'OpenTTD.Orchia.Pl'
08:20:57 <kamil> var client_name not be set;)
08:32:01 *** Eddi|zuHause2 has joined #openttd
09:04:22 *** Vikthor has joined #openttd
09:06:32 *** Eddi|zuHause2 is now known as Eddi|zuHause
09:07:25 <Eddi|zuHause> [24.06.2010 10:06] <ccfreak2k> "start date" in the timetable doesn't work as I expect. <-- depends on what you expect...
09:07:52 <Eddi|zuHause> e.g. if you expect it's the time that the train starts at the first station, you're wrong
09:08:04 <Eddi|zuHause> if you expect it's the time that the train _arrives_ at the first station, you're right
09:26:45 *** josef_1950 has joined #openttd
09:26:59 *** josef_1950 has left #openttd
09:37:02 *** lasershock has joined #openttd
09:43:44 *** roboboy has joined #openttd
09:45:40 *** KenjiE20 has joined #openttd
10:08:58 *** Devroush has joined #openttd
10:11:39 *** Illegal_Alien has joined #openttd
10:11:59 <dihedral> congratulations kamil on setting up ap+ ;-)
10:14:04 *** Grelouk_ has joined #openttd
10:14:05 <kamil> thx... i must write manual: advanced install ap+ :))
10:14:32 <dihedral> kamil: other networks might require other line endings ;-)
10:14:39 <dihedral> there is a setting for that in the config
10:15:31 <kamil> you know... step by step: download openttd, configure openttd, download lib for ap+ and install, download ap+, configure ap+...
10:16:03 <dihedral> it harldy makes sense to try to use ap+ if you do not know how to use openttd ;-)
10:16:52 <kamil> dihedral: yyy... where write is nick irc in ap+ == clientname?
10:17:19 <dihedral> openttd config section [nerwork] iirc
10:17:39 <dihedral> must be a valid irc nick name
10:17:48 <kamil> i'm not set because openttd -D not req this var
10:18:00 <dihedral> but ap+ requires this var ;-)
10:18:58 <kamil> dihedral: yes, but why nothing to do in manual?
10:20:09 <dihedral> you mean that manual?
10:22:17 <dihedral> hmm... might have forgotton :-P
10:22:44 <kamil> dihedral: you know... docs ap+ is very poooooor
10:24:02 <dihedral> might be one of the reasons why it's not used as much
10:25:37 <kamil> any way... thx for help for all... ok i go to work;p
10:25:52 <dihedral> but quite frankly i dont feel like writing docs for that anymore ;-)
10:26:01 *** Chris_Booth has joined #openttd
10:38:41 <planetmaker> <kamil> thx... i must write manual: advanced install ap+ :)) <-- that'd indeed be very welcome
10:39:39 <planetmaker> or provide a manual.txt in order to add it to the svn
10:40:06 <planetmaker> or best do both: add to the wiki and add to the manual
10:53:34 *** Progman has joined #openttd
11:10:50 *** theholyduck has joined #openttd
11:17:33 *** Keyboard_Warrior has joined #openttd
11:42:17 <TrueBrain> Rubidium: can you add a DNS entry? hu.binaries.openttd.org, pointing to 195.70.38.80
11:43:32 *** ChanServ sets mode: +v tokai
11:46:36 <Rubidium> TrueBrain: I guess I can
11:47:28 *** SirSquid1ess has joined #openttd
11:47:29 <ccfreak2k> Eddi|zuHause, so how exactly do I time it so that the train leaves for -any point- on the schedule at a specific date?
11:47:30 <peter1138> seems to already be there
11:47:51 <TrueBrain> when did that happen? :p
11:48:54 <Eddi|zuHause> ccfreak2k: start date is the arrival time at the first station, the rest of the times are derived from the schedule. i.e. start from first station is start date + wait time
11:49:04 <Rubidium> TrueBrain: the 20 seconds between both lines?
11:49:39 <TrueBrain> not that it helps, as the ssh is not responding correctly ...
11:50:21 <ccfreak2k> Eddi|zuHause, can vehicles that share orders have differing start dates?
11:50:28 <devilsadvocate> the entry would have a finite TTL
11:50:33 <Eddi|zuHause> that's the entire point :p
11:55:06 <ccfreak2k> Eddi|zuHause, so if I set the start date, set them to go to the first station and they arrive before the start date, will they wait at the station until the start date + wait time at station THEN proceed?
11:55:52 <Eddi|zuHause> (i believe so, but might need testing)
11:57:30 *** Coco-Banana-Man has joined #openttd
12:00:14 <ccfreak2k> Does openttd think there's 31 days in February?
12:00:33 <ccfreak2k> Or does the date gui just not fix for months?
12:01:42 <peter1138> it rolls over from 28th Feb to 1st Mar... as you'd expect
12:01:54 <peter1138> probably leap years too, heh
12:02:40 <Eddi|zuHause> ccfreak2k: it just doesn't dynamically change the dropdown entries
12:02:50 <ccfreak2k> Ok, got the dates in.
12:02:53 <ccfreak2k> Let's see what happens.
12:03:48 *** devilsadvocate has quit IRC
12:04:32 <ccfreak2k> Eddi|zuHause, seems to work.
12:04:38 <ccfreak2k> At least now that I know how to use it.
12:09:16 <ccfreak2k> Like a well-oiled machine.
12:39:29 *** DrRetro has joined #openttd
12:49:51 *** Chruker has joined #openttd
12:54:29 <TrueBrain> Rubidium: expect bandwidth spikes, mirroring new mirror ;)
13:03:43 <Rubidium> why is that soccer game tonight instead of late afternoon? Now the shops will be closed instead of really silent :(
13:05:27 *** devilsadvocate has joined #openttd
13:07:39 <planetmaker> hehe. You like shopping during football matches, too? It's awesome how efficient it can be...
13:11:09 <ccfreak2k> I need some kind of calendar calculator.
13:16:12 *** Devroush|2 has joined #openttd
13:17:06 <planetmaker> fjb, very much indeed
13:17:22 <ccfreak2k> Scheduled trains have caused the passenger rating for my stations to jump up to 97%.
13:17:39 <planetmaker> I once drove from BS to Magdeburg during the last world championship when Germany played
13:17:39 <planetmaker> Never before and never after the highway was that empty
13:17:41 *** Devroush has joined #openttd
13:21:24 *** Dreamxtreme has joined #openttd
13:24:06 <Eddi|zuHause> <Rubidium> why is that soccer game tonight instead of late afternoon? Now the shops will be closed instead of really silent :( <-- by my experience, shops are really silent while they are closed :p
13:24:40 <Rubidium> yeah, but I don't want to have a "free" night in a state sponsored hotel
13:25:06 <planetmaker> and shopping in the after hours is even less expensive? :-P
13:26:26 <Eddi|zuHause> we have a 24h shop (except sundays) in the city
13:26:56 <Eddi|zuHause> from monday 7:00 to saturday 22:00 i believe
13:28:55 *** HerzogDeXtEr has joined #openttd
13:44:37 <fjb> What does the "scheduled" / "expected" switch in the timetable do?
13:46:31 <Eddi|zuHause> it takes the current delay into account
13:50:58 *** DrRetro has joined #openttd
13:54:21 *** Cornholio has joined #openttd
14:02:46 *** TheMask96 has joined #openttd
14:02:49 *** Keyboard_Warrior has quit IRC
14:04:42 *** theholyduck has joined #openttd
14:38:01 *** DrRetro has joined #openttd
14:59:01 *** devilsadvocate has quit IRC
15:01:56 <TrueBrain> should hit rotation soon
15:03:41 <peter1138> how many have we got now?
15:04:03 <TrueBrain> of which one is IPv6
15:04:23 <TrueBrain> I won't be accepting any more mirrors in EU; only US, Japan, Australia, or ones that have IPv6
15:24:47 <orudge> hm, may have IPv6 available on my US mirror in the near future, TrueBrain
15:24:52 <orudge> shall let you know if and when that happens :)
15:52:44 *** devilsadvocate has joined #openttd
16:38:44 *** DrRetro has joined #openttd
16:47:15 *** |Jeroen| has joined #openttd
17:04:17 *** Polygon has joined #openttd
17:11:36 *** Dreamxtreme has joined #openttd
17:16:18 *** Devroush has joined #openttd
17:19:00 *** frosch123 has joined #openttd
17:21:31 *** Alberth has joined #openttd
17:34:24 *** fonsinchen has joined #openttd
17:41:35 *** Dreamxtreme has joined #openttd
17:45:32 <CIA-9> OpenTTD: translators * r20017 /trunk/src/lang/ (korean.txt unfinished/chuvash.txt):
17:45:32 <CIA-9> OpenTTD: -Update from WebTranslator v3.0:
17:45:32 <CIA-9> OpenTTD: chuvash - 37 changes by mefisteron
17:45:32 <CIA-9> OpenTTD: korean - 1 changes by junho2813
18:05:13 <andythenorth> should I code something
18:11:16 *** Wizzleby has joined #openttd
18:11:33 * Alberth gives andythenorth a dice
18:23:44 <Zuu> Or code a "shall I code tonight" decision support tool :-p
18:26:14 <Alberth> perhaps he was considering coding that :)
18:31:14 <Zuu> Im concidering if I will code something tonight or just being lazy.
18:32:23 <Zuu> The next question is what to code.
18:34:03 * Alberth hands the many-sided dice to Zuu
18:34:24 <Zuu> What does the sides read out?
18:35:10 <planetmaker> Zuu: I do have here such decision making die: sleep, eat, make love, take a bath, party and work are the choices ;-)
18:35:56 <Zuu> I'm concidering taking a second look at the break on string feature for the AI debug window and make it more clean plus possible adding AIController.BreakAI().
18:36:09 *** ajmiles has joined #openttd
18:38:00 <Zuu> planetmaker: btw if you still maintain your set of client patches, there is a new sign list patch yesterday or the day before (v37)
18:38:12 <planetmaker> well... I don't really
18:38:26 <planetmaker> too many newgrf projects... :-)
18:38:47 <planetmaker> and some fiddling with the settings / options / ... unification
18:38:57 <Zuu> Yea you've become the chef NewGRF coder
18:39:42 *** Eoin__ is now known as Eoin
18:41:22 * Zuu waits on SmatZ and michi_cc picking up the 'free' commit :-) (I very well know that patch-reviewing isn't really free, but it was just a joke at the party)
18:41:38 <planetmaker> there's a number of people who do the real work
18:42:03 <planetmaker> I add pieces here and there, maintain the makefiles...
18:42:20 <planetmaker> my first real maor newgrf is actually the Swedish rails
18:44:02 <planetmaker> and I consider opengfx partially my baby :-)
18:44:08 <Zuu> Talking of rail, I got the idea that you could possible create a tracks + rail set combination where you could have a rail-type which only allow cargo-engines and another that only allow pax-engines and one or more track types that allows both pax and cargo trains. Then you could use this pax/cargo-only track types for train separation.
18:44:39 <Zuu> My guess is though that it is not possible to create a such track set without having a special train set as well.
18:44:42 <planetmaker> he. interesting idea
18:45:02 <planetmaker> yes, it would need custom tayloring.
18:45:05 <Zuu> Unless it is possible to do a eg UKRS add-on for that.
18:45:16 <planetmaker> But DJN is ust the type of guy who'd do that with 2cctrainset and nutracks
18:48:43 <peter1138> "heavy" and "light" rail
18:51:10 <SmatZ> Zuu: I don't remember that joke :)
18:51:34 <SmatZ> and thanks for the patch, done so quickly :)
18:52:04 <Zuu> SmatZ: The joke was that you get a free commit if you commit the sign list patch you get a free commit. :-)
18:52:56 <SmatZ> the patch looks suspiciously simple :)
18:53:21 <Zuu> the new town window patch?
18:53:40 <SmatZ> FS#3891 - Remove autofocus of the edit box in the new town window
18:53:53 <Zuu> Yep, it's fairly simple :-)
18:54:08 <planetmaker> the title sound good
18:54:17 <Zuu> Still I've compiled the code and tested it briefly.
18:54:17 <planetmaker> it's something which bug(s/ed) me sometimes
18:55:30 <Zuu> Yet first time I've heard about that issue was at the party.
18:56:23 * planetmaker missed that joke, too ;-)
18:56:46 <SmatZ> Zuu: so the party was good for something :)
18:58:24 <SmatZ> hmm, clicking "NO" in the "Do you really want to quit OTTD?" window closes the OSK GUI
18:59:00 <SmatZ> Zuu: it still seems to be stealing Ctrl+Q :-/
18:59:33 <SmatZ> all global hotkeys, it seems
18:59:46 <Zuu> When the edit box is focused yes
18:59:59 <Zuu> What the patch makes is to make the edit box non-focused by default.
19:00:13 <SmatZ> just open the "Found new town window", and then click Ctrl+Q, nothing happens
19:00:16 <Zuu> To unfocus it click on some other widget in the window (apart from the title bar)
19:03:05 <Alberth> is there a good consistent idea of how keys + focus should behave?
19:03:36 <Zuu> If edit box is focused, then all input goes to it. Otherwise hotkeys should work as usual.
19:03:48 <Alberth> it would be useful to write that down in the gui style guide
19:04:46 <Zuu> SmatZ: I click on the toolbar button to open the build new town window. Then click Ctrl + Q and get the "do you want to quit?" window.
19:05:00 <SmatZ> Zuu: start openttd ; start SE ; click "Found new town" icon ; press Ctrl+Q (or F3, or whatever else), nothing happens
19:05:40 <Zuu> SmatZ: When you open found new town, is there a flashing cursor in the edit box?
19:05:48 * Eddi|zuHause imagine it just got loud at some people's towns :p
19:06:23 <SmatZ> nope, rebuilding openttd didn't help
19:06:51 <SmatZ> and svn diff shows your patch is applied
19:08:02 <SmatZ> Zuu: are you using unix+SDL ?
19:08:12 <Zuu> Perhaps you could put a break point in the function that handle key presses?
19:08:30 <Zuu> It should bail out if there is no selection.
19:10:07 <Zuu> hmm, however, the bail out that is of interest is probably not in the windows, but in the main gui code. Let me find the place. (probably in DispatchLeftClick or the function that call that function)
19:12:15 <Zuu> There it checks if an edit box has global focus.
19:13:16 <Zuu> That is if _focused_window->nested_focus is an edit box.
19:14:51 <Zuu> For that window or in a central place?
19:14:56 <SmatZ> also, silly passing by reference...
19:15:13 <SmatZ> Zuu: sorry, FoundTownWindow::OnKeyPress()
19:16:57 <Zuu> So the solution is probably to for that window initialize state as ES_NOT_HANDLED
19:17:45 <SmatZ> maybe it should be done in QueryString::HandleEditBoxKey()
19:18:00 <SmatZ> so we prevent that problem reocurring somewhere else :)
19:18:24 <Zuu> Maybe, but that depends on if there is somewhere where it relys on it sometimes not being set by that function.
19:19:02 <Zuu> If you set it to ES_NOT_HANDLED in the function, then you will be forced to check the edit box first. Hmm but that is what is sensible to do, so that is probably a good idea.
19:20:16 <Zuu> I would do that on line 1152 in misc_gui.cpp.
19:21:03 <Zuu> Still I'm not sure if it is clean for the function to do that given the current name/function of it.
19:29:30 <andythenorth> should I code something?
19:30:22 <andythenorth> [not the Mac port]
19:41:50 * andythenorth is feeling an absence of feedback
19:42:06 <andythenorth> bananas gets me a *lot* more downloads of grfs, but less player responses :P
19:42:16 * planetmaker hugs andythenorth
19:42:25 <planetmaker> and says hello :-)
19:42:48 * andythenorth is on a bricklink.com rampage
19:44:07 <planetmaker> andythenorth: some new special scenario modes / economies maybe?
19:45:49 <planetmaker> or a nice easter egg, some vehicle animation in one industry?
19:46:16 <Eddi|zuHause> i'm thinking an economy mode where you remove some primary industries and provide the cargos from ports instead could be useful
19:47:18 <Eddi|zuHause> where the effectivity of ports depends somehow on cargos other than *supplies
19:48:41 <Zuu> Might have went to much towards implementation.
19:50:19 <Alberth> it should describe what happens when you press a key from a user point of view
19:51:14 <Alberth> how it is implemented is not a gui style problem
19:51:52 <Alberth> probably for the case that a edit box is at the screen, and when it is not at the screen
19:52:10 <Alberth> and perhaps also how to switch between edit boxes
19:53:31 <Wolf01> andythenorth: I proposed a transparent/invisible roads/rails feature, to be able to see if under the road there is a slope, I also suggested how to do it (when in transparent mode you draw an overlay of terrain tile of the same type of the one without the road)
19:53:33 <Alberth> the idea of the guide is to have a fixed description without implementation details, so it can be decided what is the correct behaviour
19:53:44 <Wolf01> if you want you can do it for me :D
19:54:20 <Alberth> and hopefully openttd becomes more consistent in time :)
19:54:22 <andythenorth> Eddi|zuHause: how about food -> port, goods production (perhaps with delay)
19:54:30 <andythenorth> makes food vaguely useful
19:54:38 <andythenorth> agricultural export economy
19:55:15 <Eddi|zuHause> it shouldn't be a direct translation like secondary industries
19:55:24 <Eddi|zuHause> it should have something unique to it...
19:55:40 <Eddi|zuHause> yes, exporting food is one scenario for ports
19:55:45 <andythenorth> well have a think and suggest something then :)
19:55:58 <Eddi|zuHause> i did a while back
19:56:08 <Eddi|zuHause> one scenario was: no secondary industries on the map
19:56:28 <Eddi|zuHause> ports export primary goods and import (low ratio of) secondary goods/supplies
19:56:45 <Eddi|zuHause> and player must build secondary economy
20:03:52 <Zuu> Alberth: hmm, the guide should have a guideline that most windows should not give focus by default to edit boxes? Or is that to much of an implementation issue?
20:04:16 <planetmaker> that's abstract from the code.
20:04:17 <Zuu> Regarding edit boxes I'm not really sure what guides there are otherwise.
20:04:26 <Alberth> no, that's a user concept, so it should be in there
20:05:50 <andythenorth> Eddi|zuHause: sounds like Australia :P
20:06:19 <Eddi|zuHause> andythenorth: well, it could apply to any colonial territory
20:07:00 <Alberth> Zuu: ok. Leave it further then. If there are holes, they will pop up some time.
20:17:32 <Alberth> The fact that we have a editbox, and its purpose could be part of the style guide imho (just like I explain there is something called a 'resizebox' and what it does, and where to find it).
20:19:29 *** Dreamxtreme has joined #openttd
20:26:52 <Zuu> Now there is a FS#3902 containing a fix to "town window eating hotkeys even when edit box is not focused" :-)
20:45:32 <Zuu> Depending on how fast the politics regarding on if the quick fix should be done or the more permanent solution that you proposed should be used, you could then have two 'free' commits ;-)
20:54:21 <Zuu> Hmm, the more permanent solution is probably better as this problem exist at other places too.
20:55:52 <SmatZ> it would be nice if you could do an overview of use of that function and upload the better patch :)
20:56:16 <SmatZ> with making sure it doesn't break something
20:56:31 <SmatZ> I would like to do that, but I lack time :(
20:57:03 <Zuu> I'm already coding it :-)
20:59:36 *** Dreamxtreme has joined #openttd
21:07:00 <Zuu> A problem conceptually is that HandleEditBoxKey would not like to set the state to ES_NOT_HANDELED if the state was set to ES_HANDELED before. This never happens in OpenTTD but it makes the function a bit ugly conceptually. But it could be worth the reduced risk of this bug occuring again.
21:08:32 <SmatZ> I was thinking about returning some bitmasked HandleEditBoxResult and EventState
21:08:47 <SmatZ> to get rid of that EventState reference
21:10:03 <Zuu> Hmm, another possibility is to not include state in the function at all. Instead the caller has to do that based on the return value.
21:11:04 <SmatZ> sounds like a good idea :)
21:11:41 <Zuu> Though, checking the code further, the return value and state is not completely redundant.
21:11:45 <SmatZ> except misc_gui.cpp:1188
21:23:08 <Zuu> :1188 can be handeled by adding a new return value. Then this new return value or HEBR_NOT_FOCUSED will mean that the key press was not handeled.
21:28:15 <SmatZ> "hebr > 2" would need the same amount of ALU operations
21:28:47 <SmatZ> "Handeled" should be "Handled" (I think)
21:29:30 <SmatZ> 0xF1, 0xF2 looks magic with no reason to me
21:29:39 <SmatZ> but I haven't looked at the other code, so...
21:30:18 <Zuu> It's possible even more magic..
21:31:14 <SmatZ> "magic" hidden in accessor functions isn't a problem
21:36:33 <Zuu> Then we get something like this in the Window code:
21:36:34 <Zuu> EventState state = ES_NOT_HANDLED;
21:36:34 <Zuu> if(HasKeyBeenHandled(this->HandleEditBoxKey(GLAND_RANDOM_EDITBOX, key, keycode)))
21:36:55 <Zuu> (apart from my coding style error in the if statement)
21:37:47 <SmatZ> that could cause code duplication
21:39:08 <Zuu> In more complicated windows the call to HandleEditBoxKey is the second or third test in an if-statent which would become more complicated.
21:39:09 <SmatZ> how many times is QueryString::HandleEditBoxKey() called?
21:39:35 <Zuu> Once for every edit box that exist in the game
21:40:16 <SmatZ> code a patch, and post it to FS#3902, I think it should be fine :)
21:41:22 <Zuu> The problem is to change things like this:
21:41:23 <Zuu> EventState state = ES_NOT_HANDLED;
21:41:23 <Zuu> if ((_saveload_mode == SLD_SAVE_GAME || _saveload_mode == SLD_SAVE_SCENARIO) &&
21:41:23 <Zuu> this->HandleEditBoxKey(SLWW_SAVE_OSK_TITLE, key, keycode, state) == HEBR_CONFIRM) {
21:41:23 <Zuu> this->HandleButtonClick(SLWW_SAVE_GAME);
21:42:02 <SmatZ> maybe all those cases can be simplified/unified
21:42:29 <SmatZ> like, some windows steal the focus when opened, and others don't
21:42:46 <SmatZ> so there could be just 2 classes of windows with QueryString in them
21:42:59 <Rubidium> some windows close on "esc", some don't
21:43:14 <Rubidium> oh... did I talk about unifying the window behaviour before? :)
21:43:17 <SmatZ> (maybe you could even overload QueryString::HandleEditBoxKey() for them ... but that's just - not very nice)
21:45:41 <Zuu> All comes down to that sending state by reference to HandleEditBoxKey is not really correct. On the other hand any try to pull it out would complicate the code where the function is called.
21:46:37 <Zuu> A simple codewise fix wolud be to keep state in the function and make it set to ES_NOT_HANDELED at the beginning of the function and document that.
21:48:50 <SmatZ> there could be a solution to pass pointer instead of reference
21:49:01 <SmatZ> and set *event only when event!=NULL
21:49:18 <SmatZ> maybe it would simplify some cases
21:49:32 <Zuu> to more clearly force initialization?
21:49:36 <SmatZ> where "event" is not read when HandleEditBoxKey() returns certain value
21:50:18 <SmatZ> it still doesn't implicitly say where it should be initialized :)
21:50:24 <SmatZ> it should be commented though
21:50:33 <Zuu> A completely different way of handeling it would be to from Window.cpp check if an edit box is focused. If so, call HandleEditBoxKey() transparently (if the widget is enabled). In case the edit box handles the key, a new OnXXXX function is called, otherwise the current OnKeyPress is called.
21:50:50 <SmatZ> ...I had a plan to nicely comment one file a day...
21:54:13 <Rubidium> hmm... Yexo, did you move or something?
21:54:18 <Zuu> hmm, I don't think there is a case when you don't want to pass a non-null 'status' pointer.
21:54:30 <Yexo> sort-of, I'm at my parents house now
21:55:10 <Rubidium> ah, that explains the non-ftth dns name :)
21:56:45 <planetmaker> oh, a yexo. good evening :-)
21:58:26 <Zuu> I think I'll make a solution that keeps the state var, but documents it, still as a reference. Later some more experiments could be made which move some logic to Window.cpp, but that would require some way to do the checkings that currently are done before the Handle-function is called in some windows.
22:05:55 <Zuu> Shall I in the users of HandleEditBoxKey remove initialization of the state var in simple cases or shall I add it to all places where it is missing?
22:07:09 <Zuu> It might be good to add it everywhere as it would not hurt more than one write operation, but would be easier to remember to do the initialization in the more complicated cases if it is always done.
22:25:30 <ccfreak2k> Modern Motion is a weird song.
22:29:21 <Zuu> Patch uploaded to FS#3902
22:32:18 <SmatZ> Zuu: sorry, I am not here :-x
22:34:47 <SmatZ> I am not here enough to understand what you are saying :)
22:35:32 <Zuu> Ah, you've got some beers :-)
22:39:17 <SmatZ> but that's not the main issue
22:39:25 <SmatZ> I just can't do many things at once
22:39:36 <SmatZ> also, I am not GUI-expert :-/
22:42:25 <Rubidium> SmatZ: then become a GUI expert :)
22:42:54 <SmatZ> Rubidium: I thought you and Alberth are :)
22:44:16 <Rubidium> I'm hardly an expert in GUI design
22:44:23 <Rubidium> see the order GUI mess
23:04:53 *** lasershock has joined #openttd
23:13:39 <Zuu> FS#3901 is more of a code fix than a GUI design patch. The bug exist mainly in the found new town window and the AI debug window. It also exist for the genworld GUI, but the only problem is that you might not be able to open the console when the gen world gui is open if you are unlycky with the value of the uninitialized state variable.
23:14:55 <Zuu> The bug only manifests if the uninitilazed state variable contains a value that is intrepreted as that input has been handeled.
23:22:29 *** ajmiles has joined #openttd
23:22:57 *** Coco-Banana-Man has quit IRC
23:23:26 *** HerzogDeXtEr has joined #openttd
23:33:53 *** lasershock has joined #openttd
continue to next day ⏵