Log for #openttdcoop.devzone on 30th January 2012:
Times are UTC Toggle Colours
03:08:01  <Brot6> Central European Train Set - Revision 580:740fa6c9ea98: Change: multiply base running cost for st... (oberhuemer) @
03:08:01  <Brot6> Central European Train Set - Revision 581:52bb0a43b37b: Change: use superscript notation everywhere (oberhuemer) @
03:16:27  <Brot6> cets: update from r579 to r581 done (330 warnings) -
06:33:19  *** JVassie has joined #openttdcoop.devzone
07:06:48  *** JVassie has quit IRC
07:49:36  *** andythenorth has joined #openttdcoop.devzone
08:03:12  <Brot6> NewGRF build framework - Feature Request #3627 (New): add *.pyc to the .hgignore by default? (andythenorth) @
09:03:12  <Brot6> OpenGFX BigGUI - Revision 17:ec4a6379d6cb: Fix: Sprites for different directions of maglev tracks... (planetmaker) @
09:08:40  <Brot6> ogfx-biggui: update from r11 to r17 done -
09:08:40  <Brot6> ogfx-biggui: update from  to 2.0 done -
09:09:02  <planetmaker> :-O
09:09:34  <planetmaker> that was... unintended
09:13:46  <Brot6> OpenGFX BigGUI - Revision 18:4aeb1db24d5d: Revert: accidential tag (planetmaker) @
09:21:31  *** andythenorth has quit IRC
09:51:34  *** andythenorth has joined #openttdcoop.devzone
11:03:14  *** ODM has joined #openttdcoop.devzone
11:05:17  *** andythenorth has left #openttdcoop.devzone
11:30:21  <Ammler> :-)
13:06:50  <Brot6> Dutch Trains 2.0 - Feature #3493: NedTrain Vossloh G400B (Voyager1) @
15:39:01  <Ammler> michi_cc: on git repo. is stripping commits (e.g. rebase) a default behavior and possible to remote repo?
15:39:14  <Ammler> or basically edit history
15:40:04  <Ammler> I was very surprised to hear that and yet do not find a good source for it
15:50:23  <Ammler> hmm, seems like edit history is usual behavior of git devs, very silly :-)
16:18:11  *** frosch123 has joined #openttdcoop.devzone
16:49:34  <Brot6> Dutch Trains 2.0 - Feature #3493: NedTrain Vossloh G400B (foobar) @
16:57:02  <Brot6> Dutch Trains 2.0 - Feature #3493: NedTrain Vossloh G400B (Voyager1) @
17:02:24  <Brot6> Dutch Trains 2.0 - Feature #3493: NedTrain Vossloh G400B (Voyager1) @
17:12:38  <Brot6> nml: update from r1800 to r1803 done -
17:21:20  <Brot6> BANDIT - Bug #3629 (New): DevZone compile failed (compiler) @
17:26:10  <Brot6> cets: update from r575 to r581 done (1772 warnings) -
17:27:53  <Brot6> dutchtrains: update from r154 to r158 done (108 warnings) -
17:28:29  <Brot6> ogfx-biggui: update from r17 to r18 done -
17:53:53  <frosch123> Yexo: Hirundo: if a grf uses an undefined va2 variable, it is somewhat said that the va2 will always chain to the first case. however, what to do if there are multiple computations in the va2, which assign temporary storages?
17:54:04  <frosch123> shall they still be executed, or remain unchanged/undefined
17:54:10  <frosch123> resp. is the grf just broken?
17:58:04  <Brot6> opengfx: rebuild of r905 done (Diffsize: 7) (DiffDiffsize: 8) -
18:00:29  <Brot6> bandit: compile of r172 still failed (#3629) -
18:19:28  <Rubidium> frosch123: but then we should (possibly) mark the NewGRF as broken and desyncy
18:20:04  <frosch123> would it make sense to execute the desync cache check once on the server whenever a client joins?
18:20:18  <frosch123> (i.e. also in stable)
18:20:58  <Rubidium> that'd only desync everyone but the last joined, right?
18:21:19  <frosch123> :p
18:21:48  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains (22 warnings), ogfx-industries (Diffsize: 114167), firs (6 warnings), foobarstramtracks (Diffsize: 37132), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 12), rust (14 warnings) (Diffsize: 188), dutchtramset (21 warnings), swisstowns (Diffsize: 43), dutchroadfurniture, spanishtowns (Diffsize: 8), frenchtowns (Diffsize: 21), ogfx-rv,
18:21:48  <Brot6> ogfx-landscape (2 warnings) (Diffsize: 828), swedishrails, german-townnames (Diffsize: 51), dach (12 warnings), belarusiantowns (Diffsize: 64), indonesiantowns (1 warnings) (Diffsize: 29), airportsplus (Diffsize: 441059)
18:21:51  <Rubidium> does the spec state what should happen on missing variables?
18:22:12  <frosch123> at one place it says it will pick the first case
18:22:15  <Rubidium> or should we just stub implement those variables?
18:22:29  <frosch123> i thought nml even uses that effect
18:30:45  <frosch123> Rubidium: adding the variables in this case would not hurt. after all they are defined in ttd
18:33:26  <Rubidium> and otherwise it's just plain and simple a broken NewGRF, but I doubt they'd use the undetermined result would they?
18:46:04  <Brot6> Dutch Trains 2.0 - Revision 159:2f979e799ae0: Feature: livery refit for HS-1 (issue #2951) (foobar) @
18:46:04  <Brot6> Dutch Trains 2.0 - Revision 160:e0e38a77286b: Feature: graphics of G400B, with livery refit (clos... (foobar) @
18:46:04  <Brot6> Dutch Trains 2.0 - Feature #3493 (Closed): NedTrain Vossloh G400B (foobar) @
18:47:00  <Yexo> frosch123 / Rubidium: spec is imo quite clear about what happens: first result will be used
18:47:15  <Yexo> what happens with the rest of the varaction2 is not so clear
18:47:18  <Rubidium> Yexo: and thus desyncs
18:47:25  <Yexo> Rubidium: why?
18:47:45  <Yexo> if a var is missing on one client it should be missing on all clients
18:47:53  <Rubidium> yes
18:48:02  <Rubidium> but... if the value of that var is written to a register
18:48:10  <frosch123> Yexo: nars has such a case. the undefined var causes skippnig of some assignment to temp. storage variables
18:48:18  <Rubidium> then not writing it would mean you're reading from an uninitialised register
18:48:25  <frosch123> because the temp. storag eis then undefined, it desyncs
18:48:36  <Yexo> but temp storage should always be defined
18:48:40  <Yexo> we have code for that
18:49:02  <Yexo> not something a newgrf can count on, but openttd-internal it should be desync-safe
18:49:06  <frosch123> it is defined if the variable would be available
18:49:26  <frosch123> so, what should we assign to the temp. storage?
18:49:31  <Rubidium> Yexo: it's only reset when doing commands
18:49:51  <Yexo> do you have an example how it can desync?
18:50:18  <Rubidium> the value user_def_data differs
18:50:20  <frosch123> nars uses cb36 to set user defined data
18:50:34  <frosch123> and it uses unsupported variables for that
18:51:08  <Rubidium> the other solution would be clearing the temp storage between each callback
18:51:14  <frosch123> (though actually in this case it would desync as well, if the variables were supported; because what nars is doing is just invalid :p)
18:51:54  <Yexo> when exactly is the cb36 for user_def_data called that it leads to different state on clients/server?
18:52:03  <frosch123> when loading a game
18:52:06  <frosch123> i.e. on join
18:52:20  <frosch123> we do store no cb36 results in the save
18:52:23  <Yexo> but can't that lead to desyncs even with valid variables?
18:52:27  <Yexo> current_date or such?
18:52:30  <frosch123> yes
18:52:35  <Rubidium> whenever ConsistChanged is called
18:52:47  <Yexo> so it's a problem of cb36 being called on load, not a problem of undefined variables
18:53:00  <frosch123> Yexo: we implicitly say that those variables may only change in depots and such
18:53:31  <Yexo> that should mean we only call the callback when a vehicle is in a depot
18:53:49  <Yexo> relying on newgrf authors to do something right to prevent desyncs is going to fail hard
18:54:13  <frosch123> "Most properties will only change when the vehicle is bought, serviced (enters a depot), visits a station or on loading of a saved game." <- from cb36 spec
18:54:30  <frosch123> the "loading" part makes it a desyncer
18:54:45  <Yexo> so remove that from the spec (or mark it ttdpatch-only)
18:55:08  <frosch123> that does not exactly help
18:55:30  <frosch123> it is not that the cb is only called then; but that it may not change on plain track
18:55:48  <frosch123> hmm, or do you mean if we store all vehicle caches?
18:55:53  <Yexo> yes
18:56:08  <Yexo> only call a newgrf callback when the value is really allowed to change
18:56:38  <Yexo> however we handle the unknown variable case, we're going to get in trouble as soon as somebody uses a current_date variable
18:56:55  <Yexo> or even something like current_speed
18:57:09  <Yexo> which should always be zero (in a depot), but will not be when the game is loaded
19:00:10  <planetmaker> Yexo, any news with the nml release?
19:00:31  <Yexo> bundle has been created, no news yet
19:01:03  <planetmaker> oh, I didn't see the 0.2.2 release. So there is news from my perspective :-)
19:01:37  <Yexo> I wasn't sure if you were asking about the release or about a news message on the site
19:02:08  <planetmaker> The actual release :-)
19:02:28  <planetmaker> I guess the related issue can be closed?
19:03:16  <Yexo> yep
19:03:19  <Yexo> did you do that already?
19:03:32  <Brot6> NewGRF Meta Language - Feature Request #3614 (Closed): Release 0.2.2 (planetmaker) @
19:11:22  *** JVassie has joined #openttdcoop.devzone
19:16:56  *** andythenorth has joined #openttdcoop.devzone
19:17:29  *** andythenorth has quit IRC
19:17:56  *** andythenorth has joined #openttdcoop.devzone
20:03:54  <Brot6> Dutch Trains 2.0 - Revision 161:ee22e3c57a7a: Feature: livery refit for HS-2 (issue #2951) (foobar) @
20:07:11  <Brot6> Dutch Trains 2.0 - Feature #3630 (New): NMBS Class 11.8 (Voyager1) @
21:07:47  <Brot6> Japanese Stations - Revision 8:c87b37335374: Add Tokyo Station (dandan) @
21:39:27  <Brot6> GRFCodec - Revision 864:6771f1142926: -Codechange: add a grf container version parameter to sever... (Rubidium) @
22:15:39  *** Zuu has joined #openttdcoop.devzone
22:25:44  *** frosch123 has quit IRC
22:32:00  *** Zuu has quit IRC
23:10:40  <Brot6> Central European Train Set - Code Review #3403: Vehicle names (Eddi) @
23:14:08  *** JVassie has quit IRC
23:21:15  *** ODM has quit IRC
23:29:31  <Ammler> andythenorth: is it Chameleon, which made bandit fail?
23:29:43  <andythenorth> let me see
23:30:14  <andythenorth> Ammler: the usual - missing file I think
23:30:28  <andythenorth> probably a forgotten add late last nigh
23:30:37  <Ammler> ImportError: No module named template_globals
23:30:48  <andythenorth> that's just a local .py file I made
23:31:03  <Ammler> which you forgot to add
23:31:03  <andythenorth> don't code ebyond the point you can type accurately :P
23:31:20  <Brot6> Central European Train Set - Code Review #3403: Vehicle names (oberhuemer) @
23:31:48  <Brot6> Central European Train Set - Code Review #3403: Vehicle names (oberhuemer) @
23:32:00  <Ammler> it is easier, if you fix such issues as soon as they arise, the longer you wait, the harder to fix
23:32:35  <Ammler> hmm, no assigne
23:32:42  <andythenorth> Ammler: incoming
23:32:48  <Brot6> BANDIT - Revision 173:a1ea628d559a: Fix: missing file (andythenorth) @
23:32:58  <andythenorth> I should have stopped coding earlier yesterday :P
23:36:02  <Brot6> bandit: update from r154 to r173 done (1 warnings) -
23:52:32  *** andythenorth has quit IRC

Powered by YARRSTE version: svn-trunk