Log for on 21st October 2012:
Times are UTC Toggle Colours
00:09:36  *** FLHerne has quit IRC
07:56:16  *** Alberth has joined
07:56:16  *** ChanServ sets mode: +v Alberth
08:24:34  *** frosch123 has joined
08:24:34  *** ChanServ sets mode: +v frosch123
08:28:12  <frosch123> -	p->Send_uint8 (c->quarters_of_bankruptcy);
08:28:13  <frosch123> +	p->Send_uint8 (c->months_of_bankruptcy);
08:28:27  <frosch123> isn't that an incompatible change of the admin port api?
08:28:52  <frosch123> and if, do we change the documentation, or do we make it compatbile?
08:34:10  <Alberth> good point
08:40:14  <Alberth> we still have the three stages, so making it compatible seems a feasible option to me.
08:41:05  <frosch123> i am currently trying to find, what meaning is documented for it :p
08:41:21  <frosch123> but documentation looks very slim
08:42:02  <Alberth> I never realized we spit out the data in binary form, and am now wondering whether a text format would not be much easier :)
08:42:34  <frosch123> yeah, looks like only the gs<>admin stuff is json
08:42:47  <Alberth> when documentation is "use the source, Luke", we're done :p
08:43:25  <frosch123> meh, these endless directory trees of java repositories annoy me
08:44:22  <Alberth> +1  :)
08:46:52  <frosch123> ok, looks like in both ottd and joan there is zero documentation about the meaning of that field :)
08:51:12  <Alberth> nobody knows what it means :)
08:52:42  <frosch123> " Please also note that further improvements to the admin protocol can mean that more packet types will be sent by the server. For forward compatibility it is therefore wise to ignore unknown packets. Future improvements might also add  additional data to packets. This data should be ignored. Data will never be removed from packets in later versions, except the possibility that complete packets are dropped in favour of a new packet.
08:52:43  <frosch123>  This though will be reflected in the protocol version as announced in the ADMIN_PACKET_SERVER_PROTOCOL in section 2.0)."
08:52:49  <frosch123> that's the only policy that is defined there
08:53:41  <Alberth> a quite bold statement :)
08:54:07  <frosch123> so, i guess, we just make it compatible
08:54:18  <frosch123> and if it is really needed in can be changed via some version bump
08:54:54  <Alberth> I fully agree with that solution
08:58:41  <frosch123> <- looks like this is the formula to retrieve the old value
09:01:18  <Alberth> indeed, you need to round up.      perhaps remove the _ ?  there is no quarters_of_bankruptcy variable any more
09:02:19  <frosch123> i tried to make it look like a compatible change
09:03:10  <Alberth> then leeave them in, it is not that important
09:11:44  <Alberth> fyi, I started a new attempt at newgrf scope resolving   10a introduces the new structures (and forces the compiler to fail on things I missed), 10b then reverts some changes to reduce the patch-size.  10ab_combined.txt is the combined result
09:13:01  <Alberth> the other 3 are first conversion steps, where cargo does not even need a scope resolver :)
09:15:58  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24620 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
09:26:53  <frosch123> is there any place that needs the default constructor of the ResolverObject?
09:27:17  <frosch123> or can it be replaced with a ResolverObject(const GRFFile *grffile); one?
09:28:22  <frosch123> or maybe only one "ResolverObject(const GRFFile *grffile. CallbackID callback = CBID_NO_CALLBACK, uint32 callback_param1 = 0, uint32 callback_param2 = 0"
09:30:25  <Alberth> Currently, there are loads of "ResolverObject object;" in the old code which need the default constructor
09:31:12  <frosch123> so, something for later :)
09:31:49  <Alberth> yeah, it's the main reason for not doing "ResolverObject(CallbackID callback = CBID_NO_CALLBACK, uint32 callback_param1 = 0, uint32 callback_param2 = 0)" now
09:32:38  <frosch123> +	ScopeResolver *scope = object->GetScope(this->var_scope); <- misses the tihs->count in RandomizedSpriteGroup::Resolve
09:33:04  <Alberth> but I wonder whether "const GRFFile *grffile" would ever be left out, which would make your non-default constructor feasible now
09:33:33  <frosch123> i would expect it to be set always :)
09:34:18  <Alberth> that'd be better, those 3 parameters are very long
09:37:01  <Alberth> fixed the count parameter
09:44:10  <frosch123> i think the ab version is better
09:44:24  <frosch123> is there any advantage with the SetMethods thingie?
09:47:05  <Alberth> ab is also what gets committed
09:47:05  <Alberth> I just wanted to be sure I caught all uses of the function pointers, so I hacked the struct to break any use that I did not change
09:47:25  <frosch123> ah, makes sense :)
09:49:17  *** Zuu has joined
09:49:17  *** ChanServ sets mode: +v Zuu
10:44:45  <planetmaker> generally speaking: as codechange to move all difficulty settings to adv. settings - acceptable or not?
10:45:42  <planetmaker> adv. settings meanwhile are nicer, have tooltips etc :-)
10:46:17  <planetmaker> thx, frosch123 for 24620 :-)
10:46:30  <Alberth> +1 for removing difficulties :)
10:46:56  <frosch123> yup, also on my agenda
10:47:17  <frosch123> though "all" does not involve "mapgen settings for me"
10:47:32  <frosch123> which would just remain in mapgen wnidow
10:47:38  <planetmaker> yes, they probably should go ^
10:47:53  <frosch123> i wondered about what to do with the diffuclty profiles
10:48:05  <planetmaker> I'd just trash them for now
10:48:07  <frosch123> my last thought was, to remove all highscores, except "custom"
10:48:13  <planetmaker> yes, my thought, too
10:48:21  <frosch123> and add diffculty profiles to individual ai/gs parameter windows
10:48:32  <frosch123> while newgrfs would only get "custom" for now
10:48:38  <planetmaker> what you mean with "profiles"?
10:48:56  <frosch123> ai/gs specify values for their settings for the difficulty profiles
10:49:14  <frosch123> ecs also uses the difficulty setting to deny changing certain parameters in certain diff settings
10:49:38  <planetmaker> yes... stupid imho :-)
10:49:52  <frosch123> wrt. ai/gs i would try to show the profiles in the ai/gs settings windows, if the script provides specific window
10:49:54  <planetmaker> I'd not worry about that too much honestly
10:49:56  <frosch123> *specific values
10:50:11  <frosch123> resp. making it optional for gs/ai to specify values for the diff profiles
10:50:38  <frosch123> planetmaker: some kind of settings profiles are often asked for
10:50:43  <planetmaker> but maybe generally a setting difficulty for XX yes
10:50:47  <frosch123> and for gs/ai there is at least "some method" for them
10:51:09  <planetmaker> my idea for that is to implement rather generic profiles. Maybe three pre-defined and a few user-specified ones
10:51:26  <planetmaker> the three pre-defined could then remain the difficulty (we then could do the same for other settings)
10:51:37  <Alberth> you'd almost make several openttd.cfg files
10:51:45  <planetmaker> something like that, yes
10:52:01  <planetmaker> though the values could just be in the config like now, but just an array of values instead of one
10:52:18  <planetmaker> but yes, could be different configs, too. Maybe more flexible
10:52:31  <frosch123> with the other suggestion to show differences of settings to default values
10:52:40  <planetmaker> But then we basically need to split openttd.cfg into openttd-gui.cfg and openttd-newgame.cfg and openttd-map.cfg
10:52:42  <frosch123> one would also be able to make differential setting profiles
10:52:54  <frosch123> which would only change some settings, but leave the rest at the current values
10:53:03  <planetmaker> yup. I like that idea of yours a lot. Also wrt server join window
10:53:04  <Alberth> array of values feels a bit too fragile
10:53:05  <frosch123> but, that might also be a difficult interface to use
10:53:28  <frosch123> Alberth: we also have that for newgrf profiles
10:53:50  <frosch123> but, yes, separate files for profiles would also allow easy sharing of them
10:53:50  <planetmaker> frosch123, depends on how it's implemented. One could show all settings, but highlight the changed ones. Maybe different colour text in the window or so
10:54:11  <frosch123> we can even add a "settings" directory to content_download :p
10:54:14  <Alberth> a little mark at the left edge
10:54:20  <frosch123> (in the long run)
10:58:54  <planetmaker> hm, maybe we (I) should try to make a list of (sub)projects for this. So that we can discuss what need be done in which order and which could be done in parallel and which is kinda optional
10:59:09  <frosch123> wiki?
10:59:53  <planetmaker> yes
11:00:18  <planetmaker> but first thinking on what to write there :D
11:09:15  <planetmaker> I guess before I finish that, I'm out for some autumn photo shooting though :- )see you later
11:10:12  <frosch123> catch the sun :)
11:26:32  <michi_cc> Unifying advanced and difficulty settings also ties somewhat into a improved "new game" window (as floated a few times on the forum).
11:53:30  *** frosch123 has quit IRC
11:53:56  *** frosch123 has joined
11:53:56  *** ChanServ sets mode: +v frosch123
17:39:06  *** FLHerne has joined
17:45:24  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24621 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:30:03  *** Webster has joined
18:30:03  *** ChanServ sets mode: +v Webster
18:35:45  <planetmaker> but I know for fact that the current behaviour is "by design" to make basecost grfs worthwhile and allow different vehicle sets better next to eachother
18:36:27  <Yexo> there is no question about that, we should just add it to the nfo docs too
18:36:50  <planetmaker> yup, also no question about that :-)
18:38:42  <frosch123> planetmaker: btw. i started adding a textfilter to the adv. settings gui
18:38:54  <frosch123> should be able to be extended to other filters later
18:39:03  <planetmaker> oh, nice :-)
18:39:41  <Yexo> to incorporate the "shows changes from default/local" idea?
18:45:45  <frosch123> and possibly more
18:46:01  <frosch123> like "basic settings", "advanced settings", "expert settings"
18:46:35  <frosch123> Yexo: earlier today we discussed about trashing the difficulty settings, and moving the settings to the adv. settings window, if they are not already in mapgen window
18:47:01  <Yexo> I'll go and read the backlog, but I like that idea
18:47:02  *** Supercheese has joined
18:47:44  <Yexo> and the basic/advanced/expert settings too if that can be incorporated in the filters nicely
18:50:58  <planetmaker> basic/adv./expert is diametral to easy/medium/hard difficulty...
18:51:39  <Yexo> easy/medium/hard difficulty is about the value of the settings, basic/adv/expert was about which settings to display
18:52:00  <planetmaker> yup :-) that's why it's not the same :-)
18:52:20  <Yexo> right, I had to look up "diametral" ;)
18:53:31  <planetmaker> lucky me, it's even an English word :D
19:05:53  <Zuu> For what's worth I also like the idea to scrap the difficulty setting window and the work to give adv. setting window filter capability sounds sound.
19:09:45  <Zuu> I've updated the patch that allows GS to prospect and build industries (without a rich uncle). Now it actually allows GS to prospect using OpenTTD code if they want (version 1 of the patch only alowed GS to use the build API)
19:09:47  <Zuu>
19:20:53  <Alberth> do those multi-line comments work? ie are they not appended to the previous @note on not @game?
19:24:33  <planetmaker> multi-line doxygen works, Alberth
19:24:52  <planetmaker> there are other places where it does work already :-)
19:25:12  <Alberth> regular doxygen sure, but with @game magic?
19:26:24  <planetmaker> hm, that I'm not sure of :-)
19:26:45  <frosch123> Zuu: i guess if CmdBuildIndustry is called by the deity, it should use IACT_RANDOMCREATION in CreateNewIndustryHelper and GetIndustryProbabilityCallback
19:26:58  <planetmaker> honestly, Alberth, I'd risk the test, if we find no example in existing code
19:27:17  *** Knogle has joined
19:28:16  <Alberth> finding out by trying would be the best test I agree :)
19:34:00  <Yexo> it doesn't work
19:34:05  <Yexo> you have to prepend @game to every line
19:34:14  <Zuu> So instead of IACT_USERCREATION and IACT_PROSPECTCREATION, IACT_RANDOMCREATION should be used if _current_company is OWNER_DEITY?
19:34:14  <Yexo> +	 * @game @note If no valid ScriptCompanyMode active in scope, the script can
19:34:18  <Yexo> +	 * @game build as long as the industry type can be built. (a NewGRF can for example
19:34:23  <Yexo> +	 * @game reject construction based on current year)
19:34:26  <Yexo> ^^ like that
19:34:36  <Zuu> Yexo: Thanks for that
19:34:50  <frosch123> Zuu: yes, i think so
19:55:49  <Zuu>
19:56:02  <Zuu> Changes: IACT_... and @game
19:57:13  <frosch123> there is another IACT at line 1895
19:59:59  <Zuu> hmm, I 've also mixed up and used the wrong one for wrong deity state..
20:06:06  *** Alberth has left
20:07:34  <Zuu> fixed:
20:09:01  <frosch123> game_changelog ?
20:09:52  <frosch123> no idea whether it counts as new api function :)
20:12:07  <Zuu> hmm, it should be mentioned there I guess.
20:27:17  <frosch123> night
20:27:20  *** frosch123 has quit IRC
20:27:21  <Zuu> night
20:47:40  *** FLHerne has quit IRC
21:07:42  *** FLHerne has joined
21:10:30  *** FLHerne has left
21:11:08  *** FLHerne has joined
21:15:05  <Zuu> Added notes to game_changelog.hpp about ::BuildIndustry and ::ProspectIndustry. Technically CanBuildIndustry and CanProspectIndustry are also affected by this patch but I think it is implicitly clear that they have changed too.
21:15:06  <Zuu>
21:31:52  <planetmaker> I think that's fine, yes
21:32:19  <planetmaker> though... maybe be explicit about it (doesn't hurt really)
23:01:51  *** Supercheese has quit IRC
23:03:14  *** Zuu has quit IRC
23:07:19  *** planetmaker has quit IRC
23:07:19  *** Hirundo_ has quit IRC
23:07:19  *** DorpsGek has quit IRC
23:07:57  *** planetmaker has joined
23:07:57  *** Hirundo_ has joined
23:07:57  *** DorpsGek has joined
23:07:57  *** sets mode: +vov planetmaker DorpsGek DorpsGek
23:18:06  *** FLHerne has quit IRC

Powered by YARRSTE version: svn-trunk