IRC logs for #openttd.dev on OFTC at 2013-07-20
⏴ go to previous day
07:05:44 *** Zuu has joined #openttd.dev
07:54:42 *** frosch123 has joined #openttd.dev
07:54:42 *** ChanServ sets mode: +v frosch123
09:52:20 *** Ristovski has joined #openttd.dev
10:38:14 *** frosch has joined #openttd.dev
11:30:50 *** Alberth has joined #openttd.dev
11:30:50 *** ChanServ sets mode: +v Alberth
13:00:50 *** LordAro has joined #openttd.dev
13:00:50 *** ChanServ sets mode: +v LordAro
17:22:00 <Rubidium> that's something that needs a savegame bump
17:22:07 <planetmaker> uh... can you increase ^ and fix them there
17:22:08 <Rubidium> and possibly trashing the pages
17:23:00 <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:23:03 <Rubidium> see e.g. the vehicle saveload's unitnumber
17:23:55 <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:24:16 <Rubidium> while checking for the bumped savegame version
17:24:55 *** ChanServ sets mode: +o DorpsGek
17:25:09 *** DorpsGek sets mode: +v frosch
18:27:47 *** frosch is now known as frosch123
18:28:54 <Zuu> Is there a better way of deleting all elements in a pool than using FOR_ALL_...(p) { delete p; }?
18:29:25 <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:29:47 <frosch123> check the cargo monitor thingie?
18:29:52 <frosch123> iirc it has an api function to stop all
18:30:15 <Alberth> frosch123: it's a std::map iirc
18:31:14 <Rubidium> oh, rather something like _storypage_pool.CleanPool()
18:32:50 <Zuu> _story_page_pool.Clean(PT_NORMAL);
18:33:06 <frosch123> to fix above problem you do not have to delete them, do you?
18:34:00 <Zuu> hmm, that Clean(PT_NORMAL) causes the intro game to fail loading :-)
18:34:03 <Rubidium> storing 16 bits of a 32 bit variable could mean the wrong ones are stored (esp. on other endian)
18:34:54 <Zuu> While this good moment is, should I allocate U16 for page element type or use a byte for that?
18:36:18 <planetmaker> will people come back and require more in a months, if it's byte?
18:36:46 <Zuu> Only if we invent more than 255 page element types.
18:37:07 <planetmaker> I guess we have a hand full? Then a byte might suffice
18:37:14 <Rubidium> then a byte is enough. If we ever need more, we can do a savegame bump
18:37:39 <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:38:12 <planetmaker> :-) makes it easy then
19:05:48 <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:06:00 <Zuu> Or is that a "known" limitation?
19:06:33 <Rubidium> then it's not savegame compatible, and it shouldn't be used ;)
19:07:22 <Rubidium> in any case, I'd call it a "known" limitation
19:07:36 <Rubidium> it's an ID just like vehicle IDs
19:07:39 <Zuu> So one should just give up trying to have a sane lang/english.txt and add all new strings to the bottom?
19:08:13 <Rubidium> depends whether you make it savegame compatible or not
19:08:24 <Rubidium> if you do, then appending is your best bet
19:09:06 <frosch123> he? who is saving stringids?
19:09:14 <frosch123> (except the name generators)
19:09:50 <Rubidium> or rather, script strings
19:11:37 <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:47:59 *** Alberth has left #openttd.dev
22:26:38 *** LordAro has joined #openttd.dev
22:26:38 *** ChanServ sets mode: +v LordAro
continue to next day ⏵