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