Log for #openttdcoop.devzone on 26th May 2015:
Times are UTC Toggle Colours
08:18:35  <DevZone> Project FIRS Industry Replacement Set build #672-push: SUCCESS in 3 min 28 sec:
15:16:17  *** Alberth has joined #openttdcoop.devzone
16:53:03  <DevZone> Project xussrset - Trains from Russia build #960-push: SUCCESS in 5 min 20 sec:
16:56:01  <DevZone> Project 2ccts build #479-push: SUCCESS in 2 min 57 sec:
16:57:52  <DevZone> Project Finnish Trainset build #176-push: SUCCESS in 10 min:
17:01:05  *** frosch123 has joined #openttdcoop.devzone
19:59:27  <DevZone> Project eints build #30-push: SUCCESS in 16 sec:
20:00:38  <Alberth> frosch123:  ^ fix for the 'outdated' problem
20:01:47  <frosch123> :)
20:03:47  <frosch123> we still have no solution for the language definition
20:03:48  <frosch123> do we?
20:04:38  <frosch123> like, accept uploading any file to openttd projects and use their header as the very defintion for the language
20:06:47  <frosch123> all the weird ##decimalsep fields etc need to be perserved, instead of beign taken from the skeletion
20:07:39  <Alberth> no, we don't
20:08:13  <frosch123> i also wonder whether we should throw out
20:08:25  <frosch123> and instead use tail -n 12 of the ottd lang files as input
20:08:32  <frosch123> s/tail/head/
20:09:15  <frosch123> maybe it's smarter to feed the language definitions in a different way, than with the language upload
20:09:58  <Alberth> so essentially, there is no skeleton with openttd?
20:10:12  <frosch123> there is
20:10:15  <Alberth> or there is, but it has more ## thingies?
20:10:21  <frosch123> strings and ##id need to stay in order
20:10:42  <frosch123> all the ##id can be considered comments
20:10:57  <frosch123> but there are more header fields which are different in the languages
20:11:09  <frosch123> eints actually has them all in
20:11:12  <frosch123> but it does not write them
20:11:21  <Alberth> but comments only exist in the skeleton, not in the translations
20:11:31  <frosch123> and actually it should rather not modify them, because ottd is *the* definition for them
20:11:56  <frosch123> comments are duplicated to all translations
20:12:11  <frosch123> (eints does that, though it would also not harm if it would not)
20:12:19  <frosch123> but it is normal to do so
20:12:36  <Alberth> ##id are consistent across languages thus?
20:12:39  <Alberth> ok
20:12:51  <frosch123> technically ##id only matters in the base lang
20:13:04  <frosch123> but they are duplicated to the translations nevertheless
20:13:33  <frosch123> problem are the things from
20:13:43  <Alberth> maybe update from the file? and use that again for writing it out?
20:14:32  <frosch123> or have a script that generates from ottd sources
20:14:40  <frosch123> and refuse the download if the stuff would change
20:15:12  <frosch123> though generating python sources is silly, it should rather read the ottd sources from some checkout
20:16:15  <Alberth> refusing download implies you have two sets to compare, which is also a bit silly in this case
20:16:33  <Alberth> ie what do you gain?
20:16:40  <frosch123> well, not refusing download, but the commit script could block if the header changes
20:16:49  <frosch123> to enforce updating eints
20:17:17  <Alberth> ah, outside eints, and just before committing
20:17:33  <Alberth> well, it would keep eints up-to-date :p
20:18:12  <frosch123> ok, what do you think of removing all the lang defintions from and instead parse them from a ottd checkout?
20:18:39  <frosch123> i.e. eints update would be: stop eints, update checkout, restart eitns
20:18:47  <frosch123> hope that lang files are converted or something
20:18:50  <Alberth> you want to do that at too?
20:18:58  <frosch123> why not?
20:19:16  <frosch123> could even be a subrepo :p
20:19:30  <Alberth> ha :p
20:19:48  <frosch123> or eints could run a "svn up" on start or something
20:19:57  <frosch123> so, it would just be stop+start
20:20:27  <frosch123> subrepo is not that useful, since we do not want to tie the revisions
20:20:37  <Alberth> I would like to keep an option to have them in a file, tbh, easier for eg development
20:20:40  <frosch123> so, maybe eints should indeed just checkout ottd itself
20:22:06  <frosch123> why is it harder when reading them from a .txt header instead of plain python?
20:22:25  <frosch123> the checkout+update part could be external/optional
20:22:40  <frosch123> but i do not see any advantage in having to manually redefine languages in
20:22:54  <Alberth> ah, ok. In that case, fine
20:23:17  <Alberth> I didn't want to tie it too hard to openttd checkouts
20:24:37  <frosch123> i see, you want to port it to freerct :)
20:26:25  <Alberth> hehe :)
20:28:41  <frosch123> abuot the ### comments
20:28:55  <frosch123> should we copy the strgen behaviour of only considering ## as pragma?
20:29:14  <frosch123> or do we want to change ottd to only use # comments? :p
20:33:02  <Alberth> I assume they are also consistent over all languages files?
20:33:17  <frosch123> yes, wt3 copies skeletons as well
20:33:33  <frosch123> though it likely has a different name for that
20:33:46  <Alberth> being compliant with strgen seems like a good idea to me
20:35:24  <frosch123> ok, i recall some gs or newgrf also used the ###
20:35:33  <frosch123> i think i fixed them in some eints project before
20:38:04  <Alberth> that sounds likely, didn't realize that
20:38:49  <Alberth> time to go to bed for me
20:39:00  <frosch123> night
20:39:08  <Rubidium> the ### comments in OpenTTD seem to be fairly clear markers for range starts/ends
20:39:09  *** Alberth has left #openttdcoop.devzone
20:39:22  <frosch123> except in one case :p
20:40:54  <frosch123> but yes, mostly about things that need to have specific ids or order
20:41:54  <Rubidium> what's the exception, if I may ask?
20:42:07  <frosch123> ############ WARNING, using range 0x6000 for strings that are stored in the savegame
20:42:33  <frosch123> also some ranges only have "### start" markers, while some also have end
20:42:41  <frosch123> one only uses 3 ### while others use 10
20:43:12  <Rubidium> the one with 3 definitely needs an end as well
20:43:43  <Rubidium> and the warning is on the line before the next one with 10 #-es
20:44:12  <Rubidium> so in my opinion it's more like a two-line start of a range ;)
20:44:18  <frosch123> ############ start of measuring units region <- that's also a useful range
20:44:29  <Rubidium> yeah ;)
20:44:48  <Rubidium> we are forbidden to have units ;)
20:52:19  <frosch123> <- something like that?
21:00:13  <Rubidium> looks okay to me, although... if/when you're in a pedantic mode, the style of all the text for ranges/lists could be made more uniform. But I definitely reckon you have better things to do
21:18:36  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk