Config
Log for #openttd.dev on 20th July 2013:
Times are UTC Toggle Colours
00:18:48  *** Zuu has quit IRC
07:01:51  *** Zuu has joined #openttd.dev
07:01:51  *** ChanServ sets mode: +v Zuu
07:50:49  *** frosch123 has joined #openttd.dev
07:50:49  *** ChanServ sets mode: +v frosch123
07:55:32  *** Supercheese has quit IRC
09:48:26  *** Ristovski has joined #openttd.dev
10:34:21  *** frosch has joined #openttd.dev
10:39:03  *** frosch123 has quit IRC
11:26:57  *** Alberth has joined #openttd.dev
11:26:57  *** ChanServ sets mode: +v Alberth
12:56:56  *** LordAro has joined #openttd.dev
12:56:56  *** ChanServ sets mode: +v LordAro
17:17:31  <Zuu> I found a bug in StoryBook save/load which corupts the story book. From what I understand, my fix will cause saves with at least one story book page to not load due to invalid chunk size: http://devs.openttd.org/~zuu/story-sl-fix.patch
17:18:06  <Rubidium> that's something that needs a savegame bump
17:18:13  <planetmaker> uh... can you increase ^ and fix them there
17:18:14  <Rubidium> and possibly trashing the pages
17:19:06  <Zuu> Should I look into trashing the pages of the affected saves so that they can be loaded instead of getting the invalid chunk size error?
17:19:09  <Rubidium> see e.g. the vehicle saveload's unitnumber
17:20:01  <Rubidium> Zuu: just load them using the SLE_FILE_xxx | SLE_VAR_xxx + savegame bump trick, and trash them in afterloadgame (or in the story load code)
17:20:22  <Rubidium> while checking for the bumped savegame version
17:21:01  *** ChanServ sets mode: +o DorpsGek
17:21:15  *** DorpsGek sets mode: +v frosch
17:41:17  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25619 || 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:23:54  *** frosch is now known as frosch123
18:25:00  <Zuu> Is there a better way of deleting all elements in a pool than using FOR_ALL_...(p) { delete p; }?
18:25:31  <Zuu> I fear that the FOR_ALL solution could cut off the branch while sitting at it depending on how that macro is implemented.
18:25:53  <frosch123> check the cargo monitor thingie?
18:25:58  <frosch123> iirc it has an api function to stop all
18:26:12  <Rubidium> XYZ::CleanAll() ?
18:26:21  <Alberth> frosch123: it's a std::map iirc
18:26:38  <frosch123> ok :)
18:27:20  <Rubidium> oh, rather something like _storypage_pool.CleanPool()
18:28:56  <Zuu> _story_page_pool.Clean(PT_NORMAL);
18:29:12  <frosch123> to fix above problem you do not have to delete them, do you?
18:30:06  <Zuu> hmm, that Clean(PT_NORMAL) causes the intro game to fail loading :-)
18:30:09  <Rubidium> storing 16 bits of a 32 bit variable could mean the wrong ones are stored (esp. on other endian)
18:30:24  <Rubidium> Zuu: try CleanPool
18:30:30  <frosch123> ah, endian :)
18:31:01  <Zuu> While this good moment is, should I allocate U16 for page element type or use a byte for that?
18:32:24  <planetmaker> will people come back and require more in a months, if it's byte?
18:32:52  <Zuu> Only if we invent more than 255 page element types.
18:33:13  <planetmaker> I guess we have a hand full? Then a byte might suffice
18:33:20  <Rubidium> then a byte is enough. If we ever need more, we can do a savegame bump
18:33:46  <Zuu> I could think of eg. a reference to towns, stations, vehicles and a few other game objects if we want to have a special icon for that. But I can't think of 255 different element types.
18:34:18  <planetmaker> :-) makes it easy then
19:01:55  <Zuu> Is it a bug that inserting a new string before a goal string in lang/english.txt (of a GS), the goal string used in the goal window will now use a different string?
19:02:06  <Zuu> Or is that a "known" limitation?
19:02:39  <Rubidium> then it's not savegame compatible, and it shouldn't be used ;)
19:03:28  <Rubidium> in any case, I'd call it a "known" limitation
19:03:42  <Rubidium> it's an ID just like vehicle IDs
19:03:45  <Zuu> So one should just give up trying to have a sane lang/english.txt and add all new strings to the bottom?
19:04:19  <Rubidium> depends whether you make it savegame compatible or not
19:04:30  <Rubidium> if you do, then appending is your best bet
19:05:12  <frosch123> he? who is saving stringids?
19:05:20  <frosch123> (except the name generators)
19:05:44  <frosch123> oh, in goalscripts
19:05:46  <Rubidium> script translations
19:05:56  <Rubidium> or rather, script strings
19:07:43  <Zuu> For MP to work, script translations are stored in the save game. So I was hoping that included the ID it got assigned and that loading a game with a new language file will not just overwrite the string IDs in the save file.
20:44:05  *** Alberth has left #openttd.dev
22:03:59  *** LordAro has quit IRC
22:22:44  *** LordAro has joined #openttd.dev
22:22:44  *** ChanServ sets mode: +v LordAro
22:30:48  *** frosch123 has quit IRC
22:33:04  *** LordAro has quit IRC
23:02:45  *** Ristovski has quit IRC

Powered by YARRSTE version: svn-trunk