Times are UTC Toggle Colours
00:09:36 *** FLHerne has quit IRC 07:56:16 *** Alberth has joined #openttd.dev 07:56:16 *** ChanServ sets mode: +v Alberth 08:24:34 *** frosch123 has joined #openttd.dev 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> http://paste.openttdcoop.org/show/1816/ <- 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 http://devs.openttd.org/~alberth/diffs/resolve2/ 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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 #openttd.dev 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 #openttd.dev 11:53:56 *** ChanServ sets mode: +v frosch123 17:39:06 *** FLHerne has joined #openttd.dev 17:45:24 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24621 || 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:30:03 *** Webster has joined #openttd.dev 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 #openttd.dev 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> http://devs.openttd.org/~zuu/gs-industry_v2.patch 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 #openttd.dev 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> http://devs.openttd.org/~zuu/gs-industry_v3.patch 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 #openttd.dev 20:07:34 <Zuu> fixed: http://devs.openttd.org/~zuu/gs-industry_v4.patch 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 #openttd.dev 21:10:30 *** FLHerne has left #openttd.dev 21:11:08 *** FLHerne has joined #openttd.dev 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> http://devs.openttd.org/~zuu/gs-industry_v5_r24621.patch 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 #openttd.dev 23:07:57 *** Hirundo_ has joined #openttd.dev 23:07:57 *** DorpsGek has joined #openttd.dev 23:07:57 *** charon.oftc.net sets mode: +vov planetmaker DorpsGek DorpsGek 23:18:06 *** FLHerne has quit IRC