Times are UTC Toggle Colours
01:12:29 *** FLHerne has quit IRC 01:32:19 *** Zuu has quit IRC 04:53:48 *** Supercheese has joined #openttd.dev 06:07:06 <planetmaker> michi_cc: wrt patch 0001: can't we detect incomplete initialization? Wouldn't it be better to return a default value for 4C before complete intialization? 08:30:31 *** Zuu has joined #openttd.dev 08:30:31 *** ChanServ sets mode: +v Zuu 08:42:09 *** Zuu has quit IRC 09:26:46 *** FLHerne has joined #openttd.dev 09:46:30 *** FLHerne has quit IRC 11:07:48 <michi_cc> planetmaker: It does return a "default" value without the assert (0, what the memory is initialized to). As this is identical to the behaviour var 98 (max speed) always had, which no NewGRF seems to have a problem with, I don't think we need any other special value. 12:30:54 *** Supercheese has quit IRC 12:31:24 *** Supercheese has joined #openttd.dev 13:07:27 <planetmaker> ah, right. Ok, then I agree. Btw, and for what it's worth: the other patch, 0002, looks good to me 13:41:28 *** welshdragon has quit IRC 13:59:06 *** ntoskrnl has joined #openttd.dev 14:17:43 <Belugas> hello 14:41:03 <michi_cc> And http://www.icosahedron.de/openttd/patches/0003-Fix-FS-5396-The-autorefit-dropdown-in-the-order-GUI-.patch 14:41:28 <michi_cc> There's some chance I missed usage of one of the magic numbers somewhere though. 14:45:47 <planetmaker> that's the fix for pikka's recent bug report? 14:48:57 <michi_cc> For the last one (well first one :), yes. You've seen my ideas for the other two reports already. 14:49:56 <michi_cc> If we want more commits, that one could be split into a codechange and a fix. 14:51:01 <planetmaker> I don't really mind either way. Might be nicer, but... 14:51:37 <planetmaker> ... it's still small enough to understand without split 17:13:24 *** michi_cc has quit IRC 17:15:23 *** michi_cc has joined #openttd.dev 17:15:24 *** ChanServ sets mode: +v michi_cc 17:28:20 *** frosch123 has joined #openttd.dev 17:28:20 *** ChanServ sets mode: +v frosch123 17:28:56 *** Zuu has joined #openttd.dev 17:28:56 *** ChanServ sets mode: +v Zuu 17:31:37 <michi_cc> frosch123: http://webster.openttdcoop.org/?channel=openttd.dev&date=1355875200#1355957567 and http://webster.openttdcoop.org/?channel=openttd.dev&date=1355961600#1356014463 17:37:07 <frosch123> what part of 5396 is a codechange, what the fix? 17:38:55 <frosch123> ChangeVehicleWindow is called for a lot of different windows 17:39:03 <frosch123> can you replace -666 with -4 in all cases? 17:39:10 *** FLHerne has joined #openttd.dev 17:41:54 <frosch123> 5398: how long is the value invalid? 17:42:15 <frosch123> only for a tick, or till the vehicle is started ? 17:46:35 <frosch123> ah, ConsistChanged sets the max speed 17:47:16 <frosch123> then it should be fine, though i wonder whether there is a clever place to add a comment about it 17:50:03 <frosch123> 5397 looks nice :) i hope all speedlimits are now in one place :p 18:07:03 <Zuu> Perhaps http://devs.openttd.org/~zuu/goal-gui/05-goal-gui-refactor.patch is useful in trunk no matter if my other goal GUI patch is committed. 18:07:19 *** Alberth has joined #openttd.dev 18:07:19 *** ChanServ sets mode: +v Alberth 18:07:25 <Zuu> It reduce code duplication. 18:08:39 <Zuu> The other patch add complete state to goals and a progress column with progress info + visualzation of complete goals. 18:09:18 <frosch123> "int& pos" -> "int &pos" 18:09:47 <Zuu> oh yeah 18:10:12 <Alberth> moin 18:10:21 <Zuu> hello Alberth 18:11:20 <Alberth> is there anybody working on the regions currently? 18:12:03 <frosch123> i am not, and i don't consider the specs finished :) 18:12:31 <frosch123> it needs some clever way to define complex region shapes unter a single id 18:12:37 <frosch123> *under 18:12:44 *** ntoskrnl has quit IRC 18:13:21 <frosch123> Zuu: i would have used ? : instead of (global_section ...) || (!global_section ...) 18:13:27 <frosch123> diff loks fine though 18:20:09 <Alberth> hmm, real and imaginary region shape parts eh? 18:20:40 <Alberth> who defines these regions? ie what kind of expressions can you reasonably expect to be available? 18:21:02 <Alberth> could we eg have Region1 || Region2 or so? 18:21:35 <frosch123> basic shapes should be rectangles and euclidian circles 18:21:56 <frosch123> || and ! are most likely needed 18:22:05 <frosch123> so one might as wel add && 18:22:41 <frosch123> || is needed for any complex shape which you can build from multiple rectangles 18:22:49 <frosch123> ! is needed to apply something for everything but a specific region 18:23:49 <Alberth> ! and && together are sufficient, together with the DeMorgan rule, theoretically, I think 18:23:56 <frosch123> so, do we need all of ! || and &&, or does it suffice to have || and maybe a single ! at the very front 18:24:13 <frosch123> ! and || are also sufficient :p 18:24:24 <Alberth> yep :) 18:24:52 <frosch123> but yeah, i meant allowing ! only in front, so only (a || b || ...) and !(a || b || ,..) 18:24:58 <Alberth> but for simplicity, I'd just allow all 3 operators in anyway you like 18:25:08 <Alberth> s/any/any / 18:25:18 <frosch123> i have no idea how to represent those internally :) 18:25:47 <Alberth> simplest would be an expression tree 18:25:54 <frosch123> i.e. whether to make the script construct a parser tree, or whether they are combined from other regions 18:26:26 <frosch123> maybe there is also some clever way to do it with nested squirrel structures 18:26:37 <frosch123> instead of some weird api functions 18:26:55 <Alberth> and you can flatten them to normal form if you like to reduce height 18:27:48 <frosch123> hmm, yeah, storing them in normal form might be the best for savegame representation 18:27:51 <frosch123> just some array :) 18:28:05 <Alberth> other regions could be a starting point, so you can stack them nicely 18:28:24 <frosch123> so, maybe it can also be an array/table representation in squirrel 18:28:31 <Alberth> can you remove regions? 18:28:34 <frosch123> with some general bool functions 18:29:09 <frosch123> i would think that regions are only stored if they have some restriction assigned 18:29:19 <frosch123> in whcih case they can be addressed via an id 18:29:46 <Alberth> so you have to create a restriction and a region at the same time then? 18:29:46 <frosch123> currenlty i wonder whether one can separate the shape construction from the ottd gamestate 18:30:35 <frosch123> i meant constructing a shape purely in squirrel (not in ottd gamestate), then a speical api function to store a shape, which returns an ID 18:30:44 <frosch123> and then various methods to assign restrictions to a region ID 18:31:09 <frosch123> resp, the reverse case: setting the region id in something else 18:31:16 <frosch123> like passing a region id to a goal or newsitem 18:31:25 * Belugas fetches some popcorn and watches 18:34:02 <Alberth> "regions are only stored if they have some restriction assigned" clashes with "constructing a shape purely in .. then a speical api function to store a shape ... and then various methods to assign restrictions", doesn't it? 18:34:21 * Alberth takes some popcorn from sir B 18:34:32 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24829 || 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:35:07 <frosch123> Alberth: i mean storing them in the ottd gamestate 18:35:19 <frosch123> we do not store squirrel variables in the gamestate 18:35:46 <Zuu> Thanks for the review frosch123 :-) 18:36:26 <Alberth> ah, the api function to store a shape is not still squirrel? 18:36:44 <Alberth> *still in squirrel 18:36:50 <frosch123> Alberth: you could construct a shape completely in squirrel by nesting tables: { add1 = circle1, add2=rect1, sub3={add1=circle, add2=rect} } 18:37:11 * Alberth nods 18:37:17 <frosch123> then call some api function : GSRegion::Create( above struct ) -> regionID 18:37:41 <Alberth> is it in ottd gamestate after the call? 18:37:51 <frosch123> in the savegame, yes 18:38:07 <frosch123> the call would have to send it over the network to all clients 18:38:11 <Alberth> so, what restriction has it assigned then at that point? 18:38:18 <frosch123> since the region checks also needs perfoming on the clients 18:38:39 <frosch123> the "empty" restriction? :p 18:39:13 <frosch123> but yeah, if you meant that above, then you are right about the clash :) 18:39:52 <Alberth> I did :) 18:41:14 <Alberth> so it's two separate processes I think; defining regions, and setting restrictions 18:41:53 <frosch123> yup, i think that is settled 18:42:03 <michi_cc> frosch123: http://www.icosahedron.de/openttd/patches/0003-Codechange-Replace-magic-numbers-for-invalidating-ve.patch and http://www.icosahedron.de/openttd/patches/0004-Fix-FS-5396-The-autorefit-dropdown-in-the-order-GUI-.patch 18:42:11 <frosch123> i just do not know how many restrictions of which type one could set per region 18:42:41 <michi_cc> And there's exactly one other, totally unrelated use of -666 in the code (SQ_SUSPEND_FLAG in sqvm.h) 18:43:01 <frosch123> must also be a troublesome flag then :) 18:43:51 <Alberth> how is "per region" important? I'd save the regions next to the type 18:44:26 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24830 || 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:20 <Alberth> michi_cc: are negative numbers allowed in an enum? 18:47:06 <frosch123> Alberth: i mean, if you save region a and set it to not allow terraforming for company a, and then you want to disallow company b to build rail in the same shape: do you need a new region id or can you add different restrictions for different companies to the same id? 18:47:49 <michi_cc> Alberth: "The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration." No exclusion of signed types. 18:48:24 <Alberth> I would allow re-use of region IDs, it makes specifying what you mean/want easier. 18:48:49 <frosch123> Alberth: but it makes for a very complicated api 18:49:00 <frosch123> you would have to pass everything to the same function 18:49:14 <frosch123> you cannot add different function for setting the restrictiontype and for setting a companyfilter 18:49:21 <frosch123> and another one for the text to display 18:49:38 <Zuu> Perhaps make it so that restrictions can be altered after the region have been created? 18:49:48 <Zuu> Then you only need to specify one restriction in each call 18:50:06 <frosch123> and it is even harder to read them back 18:50:09 <Zuu> Eg. GSRegion.SetRestriction(region_id, company_id, restriction_enum) 18:51:03 <frosch123> so it would guess it is a lot easier to use, if the api would just provide a bunch of get/set functions which each set a single property 18:51:15 <frosch123> which are combined to a single restriction 18:51:28 <frosch123> similiar like orders :) 18:51:47 <frosch123> if you want to refit to grain and livestock you also need two orders 18:54:03 <frosch123> michi_cc: looks nice, we should have started with using enums for such stuff earlier :) 18:56:18 <frosch123> Zuu: your rtl screenshot looks correct 18:56:35 <frosch123> arabic numbers look the same in arabic as in the west :) 18:57:10 <frosch123> just that they are little endian in arabic, and big endian in the west 18:57:13 <Zuu> I was about to write "western numbers" but realized that we probably didn't invent them. :-) 18:57:19 <Alberth> I don't understand how enabling re-use of a region id makes life more difficult, api-wise. you have to specify a region-id somehow, why does it matter that the same id is used already for something else? 18:57:41 <frosch123> Alberth: how do you access the restrictions? 18:57:48 <frosch123> or do you also want to add a restriction id? 18:58:11 <Alberth> access to do what? 18:58:24 <frosch123> change it, remove it, extend it 18:58:36 <frosch123> or even "read it" 18:59:14 <Alberth> doesn't it make sense to state what region id you want to change/remove/extend/read? 18:59:31 <frosch123> i mean functions like ScriptOrder::IsGotoStationOrder, GetOrderRefit, SetOrderJumpTo 19:00:02 <frosch123> they all modify a specific order 19:00:03 <Alberth> oh wait a second, restrictionIDs. That's new for me 19:00:28 <frosch123> Alberth: imo it does not need restriction ids :) 19:00:45 <frosch123> but it would need them if you can assign different restritions to the same region 19:01:50 <frosch123> but ofc one can also see restrictions just like goals or news entries 19:02:06 <frosch123> give them a separate id, and then assign a region id to them just like one might assign a regionid to news or goals 19:02:12 <frosch123> maybe that is the cleaner approach :) 19:02:35 <frosch123> since it separate the shapes (which could also be useful for other things than restrictions) from the actual restrictions 19:06:10 <Alberth> it starts to feel java-ish :p 19:09:14 <Alberth> but yeah, it is a cleaner solution than using region ids directly 19:30:38 <michi_cc> frosch123: I'm going to commit the stuff now unless you have some clever comment idea for 5398. 19:31:13 <frosch123> i havent :) 19:43:14 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24831 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:43:17 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24832 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:43:21 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24833 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:43:26 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r24834 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:52:55 <Zuu> What is the opinion on my change to allow GSs to specify a progress text for each goal? The same patch also adds a boolean property 'complete' for each goal. If this property is true, the progress text change from orange to green. 19:53:17 <Zuu> Should I perhaps move the 'complete' stuff to a later patch or is it fine as is? 19:53:51 <Zuu> More importantly, is this a change that is an improvement over the current situation? 19:54:25 <frosch123> i would still prefer to make the progress a GSText instead of a always a percentage 19:54:37 <Zuu> It is a GSText 19:54:54 <frosch123> that changeD? 19:55:42 <Zuu> + static bool SetProgress(GoalID goal_id, Text* progress); 19:55:44 <Zuu> 19:56:03 <frosch123> if (g->progress != NULL) free(g->progress); <- just free(g->progress) 19:56:05 <frosch123> no if needed 19:57:47 <frosch123> did you use the script to generate script_window.hpp ? 19:58:00 <frosch123> it surprises me that the whitespace changes 19:58:01 <Zuu> Your point to allow "3/8" strings for progress made more sense than the AI benefits for a numerical progress as making the goal system to be undestandable by AIs is quite hard anyways. 19:58:38 <frosch123> Checks if a given goal have been marked as completed. <- has been 19:59:42 <frosch123> + * @pre goal != NULL && len(goal) != 0. <- what does that mean? 19:59:55 <frosch123> i guess it should say IsValidGoal(goal_id). 20:00:37 <Zuu> goal is the goal text 20:00:59 <Zuu> It means that the goal text shouldn't be NULL and have a non-zero length. 20:01:14 <Zuu> s/and/or/ 20:01:39 <frosch123> ah, it is from the SetText fucntion 20:01:46 <frosch123> remove it from the SetCompleted then :) 20:02:05 <frosch123> also "Text* goal" -> "Text *goal" :) 20:02:31 <frosch123> + * \li GSWindow::WID_GL_GOAL <- we do not add those to the changelog 20:02:54 <frosch123> GSWindow doc says so 20:03:39 <Alberth> Zuu to handle "3/8" for AIs, also have a percentage parameter? 20:03:48 <frosch123> + SLE_VAR(Goal, progress, SLE_UINT8), <- if you add a new item to a saveload struct you have to specify a savegame version when it was added 20:03:54 <frosch123> and bump the savegame version 20:04:20 <frosch123> Alberth: isn't "completed" enough? 20:05:05 <Alberth> (09:10:06 PM) Zuu: Your point to allow "3/8" strings for progress made more sense than the AI benefits for a numerical progress as making the goal system to be undestandable by AIs is quite hard anyways. <-- my remark was about this point 20:05:57 <Zuu> Alberth: You also need to tell AIs what the goal is about. Unless the AI know what to do to accomplish a goal, it will not have any help of a progress counter. 20:06:59 <Alberth> ooh, right. I read it wrong. Sorry 20:07:35 <frosch123> DrawString(x, right, y + pos * FONT_HEIGHT_NORMAL, s->completed ? STR_GOALS_PROGRESS_COMPLETE : STR_GOALS_PROGRESS, TC_FROMSTRING, rtl ? SA_LEFT : SA_RIGHT) <- use SA_RIGHT | SA_FORCE 20:07:42 <Zuu> Regarding script_window.hpp I might have done those changes manually or using the script. However, it is probably 1-2 months since I wrote the patch so the white space mismatch may be due to that. 20:09:19 <Zuu> <frosch123> + * \li GSWindow::WID_GL_GOAL <- we do not add those to the changelog <---- so also remove the note in the changelog about removals? 20:09:28 <frosch123> yes 20:09:59 <frosch123> they are completely version specific, we would already have 50 boring entries for 1.3 otherwise :) 20:10:09 <frosch123> (all the settings windows) 20:10:55 <frosch123> + g->progress = 0; <- s/0/NULL/ 20:12:03 <frosch123> + if (StrEmpty(text)) return CMD_ERROR; <- CmdSetGoalProgress seems to disallow empty strings, but the api says different 20:12:50 <frosch123> oh, CmdSetGoalText actually sets the progress, not the text 20:13:29 <Zuu> Regarding SLE_VAR, should the version comment be at that line or somewhere else? 20:14:10 <frosch123> no comment, you need SLE_CONDVAR 20:14:24 <frosch123> you have to code that the var is not present in old savegames 20:14:30 <frosch123> else ottd will reject the save as broken 20:16:31 <frosch123> you are not saving "completed", are you? 20:16:52 <frosch123> if it shall be saved, you have to use uint8 instead of bool 20:17:01 <frosch123> bool cannot be saved in an endian-safe way 20:17:58 <frosch123> +typedef uint8 GoalProgress; ///< Percentage completed (0..100). <- i guess that is no longer used 20:20:43 <frosch123> the other places which use Text in the api seem to have a CCountedPtr<Text> thingie at the begin of the function 20:24:28 *** andythenorth has joined #openttd.dev 20:24:28 *** ChanServ sets mode: +v andythenorth 20:24:29 <Zuu> * @pre goal != NULL && len(goal) != 0. <--- this is how the API specify that goal text cannot be empty for GSGoal::Create. I've used the same in the API doc for SetGoalText 20:24:53 <Zuu> <frosch123> no comment, you need SLE_CONDVAR <--- fixed 20:25:40 <Zuu> Hmm completed should be saved 20:25:46 <Zuu> That needs fixing 20:26:12 <Zuu> <frosch123> oh, CmdSetGoalText actually sets the progress, not the text <--- good spot => now fixed 20:26:54 <frosch123> + return g != NULL && g->completed; <- GOAL::Get will never return NULL, it will assert instead :) 20:27:45 <frosch123> you seem to have the same work disease as me with all those & and * at the left side :) 20:28:08 <frosch123> [21:25] <Zuu> * @pre goal != NULL && len(goal) != 0. <--- this is how the API specify that goal text cannot be empty for GSGoal::Create. I've used the same in the API doc for SetGoalText <- it is also c&p to SetCompleted, which has no text 20:28:49 <Zuu> Yep, I fixed the SetCompleted c&p error 20:28:55 <frosch123> also ScriptCompanyMode is mentioned in the docs for Set/IsCompelted, but not in the code 20:29:47 <Zuu> But it was a comment to your comment that the Cmd rejects empty strings but that the API docs does't suggest that. My point was that the API does specify that empty strings are rejected using the same way of saying it as GSGoal::Create 20:30:39 <frosch123> "To clear the progress string you can pass NULL or an empty string." <- how do you mean? 20:31:36 <Zuu> If you have previously set a progress text and want to clear it away. 20:31:52 <frosch123> yes, but the command rejects it, that's what i meant :) 20:33:50 <Zuu> Ah.. I changed the command now to accept empty strings and NULL the progress variable (after free) if the string is empty instead of rejecting it. 20:34:49 <frosch123> just say when you have a new diff :) 20:36:37 <Zuu> Regarding ScriptCompanyMode, that is enforced using: 20:36:38 <Zuu> EnforcePrecondition(false, ScriptObject::GetCompany() == OWNER_DEITY); 20:36:45 <Zuu> But yes, this is getting out of hand. :-) 20:39:56 <Zuu> <frosch123> if it shall be saved, you have to use uint8 instead of bool 20:39:56 <Zuu> <frosch123> bool cannot be saved in an endian-safe way <--- do I need to make bool/int conversion manually in Load_GOAL/Save_GOAL or does it magically work? 20:40:17 <frosch123> you have to declare the var as uint8 20:40:20 <frosch123> in the struct 20:40:50 <frosch123> ottd accesses it just via its pointer, so it expects the "bool value" to be stored in the first byte 20:40:55 <frosch123> which is not the case on big endian 20:46:38 <Zuu> I've declared it as a SLE_UINT8 now 20:53:41 <Zuu> Updated patch: http://devs.openttd.org/~zuu/goal-gui/10-goal-gui-completed-column.patch (same URL as before) 20:57:37 <Zuu> Hmm, saving with the current patch cause an assert to be triggered :-) 20:59:15 <frosch123> + * Update progress text of a goal. <- c&p on CmdSetGoalCompleted 20:59:42 <frosch123> + bool completed; ///< Is the goal completed or not? <- it has to be uint8 20:59:52 <frosch123> the size of bool is compiler specific 21:01:28 <frosch123> actually the indenting policy in _sl files is to use one tab at the front, and then spaces to align the ( 21:01:37 <frosch123> very uncommon in ottd, but very common in saveload :) 21:01:39 <Alberth> I wonder whether the goal progress should be updated when the completed flag is set 21:01:54 <frosch123> the colour chanes 21:02:36 <Alberth> progress: 25% in 'completed' colour :p 21:02:46 <frosch123> + SLE_CONDVAR(Goal, progress, SLE_UINT8, 180, SL_MAX_VERSION), <- Zuu: that's where it crashes 21:02:52 <frosch123> a string is no uint8 :) 21:03:08 <frosch123> Alberth: why not? if the goal is to transport 25% of stuff 21:03:14 <Zuu> A future patch could introduce a symbol that is drawn somewhere with a checkmark or something to give more visual feedback than simply changing the colour of the text. 21:03:22 <Alberth> the empty string is uint8 :p 21:04:02 <Zuu> <frosch123> a string is no uint8 :) <--- right, that I should have got right from the beginning :-) 21:05:05 <Zuu> <frosch123> + bool completed; ///< Is the goal completed or not? <- it has to be uint8 <----- so also the in-memory structure need to have fixed size on all platforms? 21:05:17 <frosch123> yes 21:05:31 <frosch123> the saveload code accesses it as uint8 via a reinterpret cast 21:05:47 <Alberth> otherwise you break automagic getting/setting of the value 21:06:09 <frosch123> Zuu: please check the usage of "CCountedPtr<Text> counter(goal);" in the api functions which take a text parameter 21:06:18 <frosch123> i suppose it is for freeing the text upon return 21:07:09 <Alberth> struct Goal : GoalPool::PoolItem<&_goal_pool> { <-- why does the ///< comments shift in that struct, there does not seem to be a need 21:08:10 <Zuu> When we use uint8 as a bool variable, do we use any special structure for setting/getting it? Or just use 1 for true and 0 for false? 21:08:38 <frosch123> i think just 0 and 1 21:10:08 <Zuu> In the Cmd, should I then verify that the parameter is exactly 0 or 1 and not eg 2 or 3? 21:10:11 <frosch123> Zuu: oh wait, i learned something new, apparently we have SLE_BOOL nowadays 21:10:23 <frosch123> replace_protection uses that :) 21:11:47 <Zuu> hmm, It looks like users of SLE_BOOL use bool as in-memory variable type. 21:12:13 <frosch123> yes, i guess that's what it is about :) 21:12:28 <frosch123> it was all wrong what i said earlier about using uint8 :p 21:13:02 *** Alberth has left #openttd.dev 21:13:13 <frosch123> diff has still several "*" in the wrong spot 21:13:40 <Zuu> Ok, I'll look through that. 21:24:36 <Zuu> Hmm "[a-zA-Z0-9]\*" only gave one hit 21:30:08 <frosch123> hmm, yeah, looks like i exagerated :o 21:31:10 <Zuu> I've updated the patch regarding SLE_BOOL and that "*". However the game still crashes upon save. 21:31:55 <Zuu> Also fixed the tab indention of SLE_* stuff. Or at least I've made it now so that things should align up well even if someone got tab-width 8 or 3 or whatever :-) 21:33:53 <frosch123> just check how the other saveload code does it .) 21:34:48 <frosch123> did you check the CCountedPtr thingie? 21:35:29 <Zuu> Right, I got one tab too much. :-) 21:35:46 <Zuu> Nope, the CCountedPtr haven't been checked yet. 21:40:14 <Zuu> It does indeed look like all APIs use it for string parameters. So I guess my patch should use it. Although it would be even better to understand why. :-) 21:40:51 <frosch123> i suspect it does a free of the text no matter how the command returns 21:40:57 <frosch123> (normal or via exception) 21:50:12 <Zuu> I've now figured out why it keep asserting at save. So a fixed patch have been uploaded. 21:50:31 <Zuu> I was using SLE_(COND)VAR instead of SLE_(COND)STR. 21:50:43 <Zuu> for strings 21:54:57 *** andythenorth has quit IRC 21:59:11 *** welshdragon has joined #openttd.dev 22:10:23 *** andythenorth has joined #openttd.dev 22:10:23 *** ChanServ sets mode: +v andythenorth 22:21:09 *** frosch123 has quit IRC 23:13:44 *** andythenorth has quit IRC 23:36:02 *** FLHerne has quit IRC