IRC logs for #openttd.dev on OFTC at 2013-01-12
⏴ go to previous day
00:48:02 *** Alex3 has joined #openttd.dev
01:04:05 *** Alex3 has left #openttd.dev
08:53:14 *** Alberth has joined #openttd.dev
08:53:14 *** ChanServ sets mode: +v Alberth
09:40:12 *** Zuu has joined #openttd.dev
11:14:13 <Zuu> I've tried to investigate if my fix to FS#5419 could have any bad side effects by allowing negative values where they are not expected, but couldn't find any. However, the string parameter system is somewhat complex.:-)
11:15:59 <Zuu> After all, {NUM} and possible more string parameters that take integers, should allow negative values. So allowing GSs to append negative integer parameters to a string doesn't seem to cause any negative side effects.
11:17:40 <Zuu> Do my fix look OK? or do you maybe have a good suggestion for a futher test to perform?
11:19:42 *** fonsinchen has joined #openttd.dev
11:19:42 *** ChanServ sets mode: +v fonsinchen
11:28:07 *** frosch123 has joined #openttd.dev
11:28:07 *** ChanServ sets mode: +v frosch123
11:35:22 <frosch123> Zuu: are you sure the text is also decoded in dec?
11:36:20 <Zuu> Are you refering to this line:
11:36:20 <Zuu> p += seprintf(p, lastofp, "%X", this->string);
11:36:41 <frosch123> yes, it was hex before, now it is dec
11:37:10 <frosch123> at least stringids are decoded using "param = strtol(s, &p, 16);"; i did not find yet the place where in params are decoded
11:38:11 <Zuu> As I understand that function it creates a string with first the string ID, then each parameter is added with a colon before each parameter.
11:38:53 <Zuu> I haven't fully understood the code which then parse that string.
11:39:04 <frosch123> yeah, but it looks like the decoder always assumes hex
11:39:09 <frosch123> param = strtol(s, &p, 16);
11:39:13 <frosch123> sub_args.SetParam(i++, param);
11:39:41 <frosch123> did you test with numbers > 10?
11:40:39 <Zuu> Numbers to {NUM} or StringIDs?
11:41:32 <frosch123> i am not sure how nested texts work
11:41:42 <frosch123> maybe it is best to encode all NUM and STRING as dec
11:42:23 <Zuu> There is some special handling of GS strings in GetStringWithArgs.
11:42:46 <frosch123> ah, i guess the decoder can also distinguish stringid from num
11:42:51 <frosch123> and still treat stringid as hex
11:43:11 <frosch123> param = strtol(s, &p, 16); <- so i would try to replace this with "param = strtol(s, &p, loopup ? 16 : 10);"
11:43:15 <Zuu> I haven't tried with numbers > 10, but will make a such test.
11:48:00 <Zuu> Passing 15 to {NUM} will display 21 with my "fix", but 15 in trunk (r24892)
11:48:44 <frosch123> try changing strings.cpp:870 to "param = strtol(s, &p, loopup ? 16 : 10);" :)
11:51:13 <Zuu> That give correct behaviour for -1, 1 and 15 passed to {NUM} from a GS.
11:52:38 <frosch123> do you have a testcase for stringids > 10 ?
11:52:49 <Zuu> The measurement tooltip for rail etc. uses {NUM} and that one seem to correctly display values > 10 (and below too)
11:53:20 <Zuu> Assuming StringIDs start at 0 in GSs, I could just create 11 strings.
11:54:09 <Zuu> Although I would also guss that STR_MEASURE_LENGTH is > 10. But that is not from GS.
11:55:08 <frosch123> SCC_ENCODED is only stuff from gs :)
11:55:28 <frosch123> hmm... oh... what about savegame compatibility?
11:55:57 <frosch123> saving a town gui text with trunk and then loading with your patch?
11:56:15 *** Maedhros has joined #openttd.dev
11:56:30 <frosch123> i think if that is broken it would be very hard to fix
11:57:39 <Zuu> StringID > 10 from GS appear to work.
11:57:49 <frosch123> also as nested strings?
12:00:02 <Zuu> If I understand it correctly, if you have nested strings, you pass GSText instances as arguments which end up in this->paramt in script_text
12:01:05 <frosch123> siliconvalley has a testcase i believe
12:01:23 <frosch123> the medals are inserted as nested strings
12:01:33 <frosch123> not sure about their stringids
12:08:59 <Zuu> The game was started with r24892 and then loaded into the modified OpenTTD version.
12:09:12 <frosch123> i guess savegame conversion won't work... so maybe there is some way to keep the string encoding compatbilty?
12:09:27 <frosch123> maybe keep it hex and add a "-" in front manually?
12:09:33 <frosch123> (both in encoding and decoding)
12:09:44 <frosch123> hex is also shorter :)
12:10:40 <frosch123> alternatively we can also keep it as hex, and force a uint32 -> int32 conversion on both ends
12:10:50 <frosch123> so -1 is stored as FFFFFFFF in the string
12:11:03 <Zuu> Oh, I see now %X is hex, I read the C++ reference guide to quick and though that it was a int.
12:11:06 <frosch123> what does squirrel use to store variables?
12:11:49 <Zuu> I'm not sure what the internal integer data type is in squirrel.
12:12:48 <frosch123> int parami[SCRIPT_TEXT_MAX_PARAMETERS]; <- hmm... i believe ottd is set up to make "int" a "int32" ?
12:13:57 <frosch123> so, i guess forcing the int32 -> uint32 conversion on both ends might be the easiest
12:14:53 <frosch123> i.e. "param = (int32)strtoul(s, &p, 16);" and "seprintf(p, lastofp,":%X", (uint32)this->parami[i]);"
12:17:03 <Zuu> Keeping the old encoded format is probably a good solution to maintain savegame compatibility.
12:18:08 <frosch123> hmm, so _SQ64 seems to depend how ottd is compiled
12:18:27 <frosch123> so, for network compatibliity between 32bit and 64bit systems we have to assume 32bit
12:18:50 <frosch123> maybe "parami" should also become "int32" for clarity then
12:20:09 <Zuu> <frosch123> i.e. "param = (int32)strtoul(s, &p, 16);" and "seprintf(p, lastofp,":%X", (uint32)this->parami[i]);" <--- this works both with my test GS and with loading the Silicon Valley game.
12:23:08 <frosch123> "uint64 param;" <- hmm, why does that actually work :o
12:23:12 <Zuu> From what I can see, _SQ64 doesn't appear to be used for any type.
12:27:09 <frosch123> "configure" sets it depending on your host machine
12:27:23 <frosch123> so, nothing that may influence savegame format
12:29:29 <Zuu> but yeah, it is a bit strange that it work to force to int32, while param is uint64.
12:30:44 <frosch123> it likely only works on 64bit or only 32bit
12:30:51 <frosch123> depending on what you tested it on :p
12:31:50 <frosch123> hmm, SetDParam also uses uint64
12:32:01 <frosch123> so, every negetive number in ottd uses that conversion
12:32:19 *** Supercheese has joined #openttd.dev
12:32:24 <Zuu> I'm on 64bit windows, but 32 bit build using Visual Studio 2008 Express.
12:32:53 <frosch123> well, if SetDParam also does it, it is probably fine
12:32:56 <frosch123> though i do not see why :)
12:37:38 <Zuu> Will it not cause compiler warnings on some systems to pass (int32) to a uint64 variable?
12:38:13 <frosch123> no, only comparison and such
12:38:36 <frosch123> diff looks fine to me
14:35:09 <frosch123> and remove some implicit bool->int conversion
14:58:58 <Alberth> swap the latvian description too ?
15:00:17 <frosch123> no idea how to word it; the "other" is never mentioned in the descriptions
15:00:25 <Alberth> an alternative could be to swap the values in code
15:00:45 <Alberth> hmm, would be confusing :p
15:00:48 <frosch123> i wouldn't do that without asking some latvian speaker
15:00:53 <frosch123> maybe this order is the "natural" one
15:01:12 <frosch123> and i do not want to invest the work to get hang of some speaker :)
17:03:53 *** fonsinchen has joined #openttd.dev
17:03:53 *** ChanServ sets mode: +v fonsinchen
17:12:56 *** ntoskrnl has joined #openttd.dev
17:21:45 <planetmaker> has anyone actually looked at FS#5440. The poster has a point
17:22:08 <frosch123> it's on my list, but did not look at it
17:27:54 <Alberth> isn't that why you cannot get bankrupt?
17:28:26 <frosch123> it's more like it always asks for a buyer
21:55:34 *** Alberth has left #openttd.dev
21:57:53 *** FLHerne has joined #openttd.dev
continue to next day ⏵
