Config
Log for #openttd.dev on 6th January 2014:
Times are UTC Toggle Colours
00:52:18  *** frosch123 has quit IRC
08:12:14  *** adf88 has joined #openttd.dev
08:12:14  *** ChanServ sets mode: +v adf88
09:37:29  *** orudge has quit IRC
10:57:24  *** adf88 has quit IRC
12:22:23  *** frosch123 has joined #openttd.dev
12:22:23  *** ChanServ sets mode: +v frosch123
12:31:09  *** Supercheese is now known as Guest2752
12:31:11  *** Supercheese has joined #openttd.dev
12:31:11  *** ChanServ sets mode: +v Supercheese
12:37:23  *** Guest2752 has quit IRC
13:21:23  *** adf88 has joined #openttd.dev
13:21:23  *** ChanServ sets mode: +v adf88
13:44:31  *** Belugas has quit IRC
14:12:14  *** adf88 has quit IRC
16:17:44  *** adf88 has joined #openttd.dev
16:17:44  *** ChanServ sets mode: +v adf88
17:22:21  *** Zuu has joined #openttd.dev
17:22:21  *** ChanServ sets mode: +v Zuu
17:32:13  *** Belugas has joined #openttd.dev
17:32:13  *** ChanServ sets mode: +v Belugas
19:20:42  *** Supercheese has quit IRC
19:51:37  <Zuu> To address the various requests to use Story Book in non-linear mode, I've made a patch queue which adds GSStoryPageList() GSStoryPageElementList(), GSStoryPage::GetCompany(), GSStoryPage::GetDate(), GSStoryPage::SetDate(), GSStoryPage::RemoveElement() and GSStoryPage::MoveElement(): http://devs.openttd.org/~zuu/story-more-apis/
19:59:27  <frosch123> hmm, i would think that ScriptStoryPageList should not include the global pages for each company, should it?
20:00:03  <frosch123> does the order matter somehow?
20:00:18  <Zuu> I did this to make a 1:1 to what is displayed in the story book views.
20:00:18  <frosch123> or are scriptlists always sorted anyway?
20:00:58  <Zuu> IIRC they are always sorted. But a script can assign values and sort it if it wish.
20:02:23  <Zuu> Though with that said, maybe the sort order value should be exposed too via an API so that the script can sort the list as displayed rather than by index.
20:02:38  <frosch123> isn't it sorted by date?
20:03:01  <Zuu> Not technically.
20:03:26  <Zuu> It will use chronological order (as in the order the pages/elements are added)
20:03:44  <frosch123> so the gs cannot insert pages without deleting some first?
20:03:47  <Zuu> It uses an internal sort value that is incremented for each added page/element.
20:03:57  <Zuu> Exactly
20:04:16  <Zuu> But that could of course also be questioned if it must be like that.
20:04:34  <Zuu> Something similar to the new MoveElement for pages could be added.
20:05:13  <frosch123> how does the "No ScriptCompanyMode may be in scope" matter for the Get* functions?
20:06:36  <frosch123> +	 * @param story_page_id The story page to update. <- c&p for GetCompany, GetDate, SetData
20:07:53  <Zuu> <frosch123> how does the "No ScriptCompanyMode may be in scope" matter for the Get* functions? <--- I don't know. It is probably just a habit.
20:08:18  <frosch123> i would remove that condition for the Get* functions
20:08:23  <frosch123> no reason for it
20:10:18  <frosch123> ScriptDate::Date could get some doxygen
20:10:22  <frosch123> for the enum, and the value
20:11:48  <frosch123> if you are using the Date type in ScriptStoryPage, it should probably also be used in all the other places which return a date
20:11:58  <frosch123> like ScriptDate functions, or vehicle intro dates and such
20:14:15  <frosch123> +	 * @pre element_to_move != inset_at <- +r
20:14:26  <frosch123> +	 * @pre Both element_to_move and inset_at belong to the same story page. <- same
20:19:40  <frosch123> RemoveStoryPageElement does not reassign the "sort_value", so it leaves a gap. is that an issue?
20:21:55  <Zuu> It is not an issue if there is gaps. The sort_value has more than enough bits and when creating new elements the gap value(s) will not be used.
20:23:18  <Zuu> Though yes, as ->index in the pool is recycled but sot sort_value you cound in theroy run out of sort_values.
20:24:46  <Zuu> But that could also happen if you give a company *lots* of pages, it goes bankrupt and then those sort values will not be recycled.
20:24:50  <frosch123> i was just wondering because CmdMoveStoryPageElement does it for moving stuff to the end
20:25:58  <Zuu> I forgot to think about that when moving to end I could just leave a gap.
20:26:32  <frosch123> btw. the move command results in items on different pages having the same sort value
20:26:48  <frosch123> you are decrementing/incrementing the sortvalue
20:27:04  <frosch123> but the next/previous sortvalue is not necessarily on the same page, but could be on a different one
20:27:09  <Zuu> Btw, sort_value is 32bit. page_id is 16 bit. So in practice it is probably not a problem of running out of sort_values.
20:27:19  <frosch123> so it's no real shifting of the numbers within the page
20:27:53  <frosch123> no idea whether the sort_values are meant to be unique across all elements
20:28:00  <frosch123> or only within a page
20:28:09  <Zuu> They only need to be unique within a page.
20:28:44  <Zuu> Though I did not think about that problem when constructing that method.
20:29:44  <Zuu> I guess a more elegant solution would retain the same sort order values within a page.
21:29:49  <frosch123> Zuu: btw. is there any reason wrt. ai to not delete company signs when they bankrupt/restart?
21:31:06  <frosch123> refering to fs#5837: currently on bankrupt signs are moved to the "none" company like roads
21:31:17  <frosch123> i wonder whether they should be deleted instead
21:48:57  *** frosch123 has quit IRC
23:07:36  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk