Config
Log for #openttdcoop.devzone on 19th June 2011:
Times are UTC Toggle Colours
00:10:47  *** Lakie has quit IRC
06:00:11  *** JVassie has joined #openttdcoop.devzone
06:05:35  *** JVassie has quit IRC
06:05:56  *** andythenorth has joined #openttdcoop.devzone
07:07:33  *** ODM has joined #openttdcoop.devzone
08:01:57  *** bodis has quit IRC
08:02:18  *** bodis has joined #openttdcoop.devzone
08:17:55  *** bodis has quit IRC
08:20:13  *** bodis has joined #openttdcoop.devzone
08:45:25  *** andythenorth has quit IRC
08:57:31  *** JVassie has joined #openttdcoop.devzone
09:07:00  <planetmaker> http://paste.openttdcoop.org/show/294/ <-- seems I need another handle on company_colour1...
09:23:09  <planetmaker> http://paste.openttdcoop.org/show/295/ <-- now I'm puzzled... what's wrong with that?
09:24:04  <planetmaker> line 133 is the first line of the case statement     1: return base_sprite_2cc + 5 * 16 + 0;
09:24:37  <Rubidium> remove bits till you find it?
09:25:46  <planetmaker> which bits? the CB should be able to return a number, shouldn't it?
09:26:05  <Rubidium> I've got no clue ;)
09:26:39  <planetmaker> well, it is the (global) variable base_sprite_2cc which it stumbles upon... but...
09:26:54  <planetmaker> this is the most common use I can think about ;-)
10:11:52  *** ODM has quit IRC
10:30:57  <Hirundo> planetmaker: The coder of random action2 (that'd be me) didn't implement action6 for the random choices, so non-constant expressions don't work atm and give a rather cryptic message instead
10:31:43  <planetmaker> he :-)
10:31:45  <Hirundo> Please file a ticket and it'll be looked at in the near future
10:31:49  <planetmaker> Feature request!
10:36:01  <Hirundo> Allowing access to variables (company_colour1) in the return value would be nice and is possible to do, but needs more work
10:36:20  <planetmaker> :-)
10:36:26  <planetmaker> another issue for that?
10:36:52  <planetmaker> does the access to base_sprite_2cc fall in that category? I don't think so, right?
10:38:22  <Hirundo> No, that just needs action6/D
10:40:45  <Brot6> NewGRF Meta Language - Feature Request #2760 (New): Allow non-const expressions in random action2 (planetmaker) @ http://dev.openttdcoop.org/issues/2760
10:42:24  <Brot6> NewGRF Meta Language - Feature Request #2761 (New): Allow direct variable access in return statem... (planetmaker) @ http://dev.openttdcoop.org/issues/2761
10:47:44  <planetmaker> hm... these two issues stop me 'fixing' my container wagons :-)
10:48:03  <planetmaker> I think it's clear what I desire / need for that ;-)
10:48:14  <planetmaker> same... also for vehicles, I think
10:48:21  <planetmaker> they're 2CC vehicles
10:49:06  <Hirundo> I'll give it some extra priority :)
10:49:48  <Hirundo> Yexo: I noticed a change in the way action1s are outputted for industry tiles and such
10:49:58  <Hirundo> See http://pastebin.com/RETaMWxT for example
10:50:18  <Hirundo> Is that intentional or not?
10:52:49  <planetmaker> Don't worry too much... there's enough I can do without that :-)
11:06:43  *** frosch123 has joined #openttdcoop.devzone
11:09:25  <Brot6> OpenGFX+ Trains - Revision 245:37f1226ec8ca: Change: [Makefile] Make it slightly harder that the ... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/37f1226ec8ca
11:15:54  *** andythenorth has joined #openttdcoop.devzone
11:17:59  <Brot6> NewGRF Meta Language - Bug #2649 (Closed): allocation sprites/spritelayouts (yexo) @ http://dev.openttdcoop.org/issues/2649#change-6891
11:21:50  <Ammler> planetmaker: I do not undestand #1869
11:21:50  <Brot6> Ammler: planetmaker: #1869 is http://dev.openttdcoop.org/issues/show/1869 "Example NewGRF Project - Bug #1869: naming of bundle files for releases fails - #openttdcoop Development Zone"
11:25:23  <planetmaker> me neither ;-)
11:35:13  <Yexo> <Hirundo> Yexo: I noticed a change in the way action1s are outputted for industry tiles and such <- yes, that was r1414
11:35:27  <Brot6> Example NewGRF Project - Revision 296:144ba3e7502a: Change: Allow to reference layers in source i... (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/144ba3e7502a
11:37:16  <Yexo> <planetmaker> hm... these two issues stop me 'fixing' my container wagons :-) <- you realize you can emulate a random-switch with a normal switch and var 5F?
11:38:18  <planetmaker> no, I don't
11:38:20  * planetmaker reads
11:39:12  <planetmaker> he, what is var 5F?
11:39:19  <Yexo> contains all random bits
11:40:05  <planetmaker> hm... that gives me the question: why do we want a random_action then in the first place?
11:40:14  <planetmaker> if it can be handled the same?
11:40:20  <frosch123> you need it for rerandomisation
11:40:35  <planetmaker> hm, right
11:41:12  <Yexo> planetmaker: it's called random_bits in nml
11:41:35  <planetmaker> but indeed... what will happen about the re-randomization then?
11:41:48  <Yexo> it won't happen
11:42:08  <planetmaker> hm, ok
11:48:48  <Yexo> Hirundo: I looked at your pastebin with action1 code again, I think the output of nml 0.1.1 is even a bug
11:49:02  <Yexo> since that means you can't create construction stages
11:51:40  <Hirundo> It was intended as a feature, not a bug
11:52:33  <Hirundo> In the current specs you can't do construction stages without adding N construction stages to all of your sprites
11:52:45  <Yexo> granted, that is bad too
11:53:34  <Yexo> however if we want to support the advanced action2 sprite offset we need to have multiple sprites in one set
11:54:00  <Hirundo> Agreed
11:54:23  <Hirundo> It might be best, to push for extended action1 quickly :)
11:54:30  <Yexo> that change was an accidental by-effect though, I didn't realize how it worked before
11:55:02  <Hirundo> I noticed, because adding a third sprite to set1 currently causes a crash (assertion)
11:55:47  <Yexo> how should that be handled?
11:56:18  <Yexo> 1. Fill up set2 with empty sprites until it's size is the same. 2. Raise an error. 3. Fill up set2 by copying the last sprite
11:56:21  <Yexo> I think 2
11:58:44  <Hirundo> Currently 2
11:59:17  <Brot6> FIRS Industry Replacement Set - Revision 2079:8e8bc170a64e: Change: additional work to add snow t... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/8e8bc170a64e
11:59:18  <Brot6> FIRS Industry Replacement Set - Revision 2080:b66d468e87a8: Change: convert groundtiles to png (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/b66d468e87a8
11:59:18  <Brot6> FIRS Industry Replacement Set - Revision 2081:bf7cd7689e44: Change: add snow support to CONCRETE ... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/bf7cd7689e44
11:59:19  <Yexo> I mean "raise a normal error instead of asserting and make the user solve it"
11:59:20  <Hirundo> I don't think pushing a temporary fix is worth it
11:59:39  <Yexo> andythenorth: I think I fixed the string problem in firs btw
11:59:40  <Hirundo> Yes, just a normal error
12:04:38  <andythenorth> Yexo: sounds good :)
12:10:44  <Hirundo> frosch123: w.r.t. extended action1, http://www.tt-forums.net/viewtopic.php?f=19&t=47492&start=31 (and the rest of the topic too) might make for an interesting read
12:10:45  <Webster> Title: Transport Tycoon Forums View topic - eis_os' work on Patch changes (at www.tt-forums.net)
12:11:32  * andythenorth is bored
12:11:33  <Hirundo> "Currently TTDPatch changes the spritelayout pointer and the base sprite" <- basically, action1 is (yet another) hack in TTDPatch
12:11:39  * andythenorth wonders what to do next
12:12:03  <Hirundo> Getting extended action1 in there will probably require a rewrite that I doubt will happen
12:12:34  <frosch123> Hirundo: i learned yesterday that ttdp relies on the feature byte at a specific position, to skip them entirelely when e.g. newtrains are disabled
12:12:48  <frosch123> so misusing it for an flag would totally break ttdp
12:13:51  <Hirundo> Did you discuss a possible TTDPatch implementation, when drafting extended layouts?
12:14:32  <planetmaker> Error:      (AssertionError) .
12:14:34  <planetmaker> Command:    ['/usr/local/bin/nmlc', '--grf', 'ogfx-trains.grf', 'ogfx-trains.nml']
12:14:36  <planetmaker> Location:   File "/Users/ingo/ottd/grfdev/nml/nml/actions/action2.py", line 352, in get_action2
12:14:38  <planetmaker> with http://devs.openttd.org/~planetmaker/patches/pseudorandom.diff
12:14:39  <frosch123> there was a short discussion with lakie, who asked eis_os
12:14:39  <planetmaker> It is triggered by having changed wagon_flatbed:232 from CB_FAILEd to what the patch gives
12:14:43  <planetmaker>  Error:      (AssertionError) .Command:    ['/usr/local/bin/nmlc', '--grf', 'ogfx-trains.grf', 'ogfx-trains.nml']Location:   File "/Users/ingo/ottd/grfdev/nml/nml/actions/action2.py", line 352, in get_action2with http://devs.openttd.org/~planetmaker/patches/pseudorandom.diffIt is triggered by having changed wagon_flatbed:232 from CB_FAILEd to what the patch gives
12:14:47  <frosch123> but usually i navigate patch source myself
12:15:15  <frosch123> i know that ttdp does drawing of spritelayouts with own code for industries and such, but with ttd code for stations
12:15:17  <planetmaker> I wonder whether there will be a ttdp implementation
12:15:42  <Yexo> planetmaker: a switch block pointing to itself?
12:15:49  <frosch123> it is certainly possible to code advsprlayout for ttdp, but i doubt anyone would do the work
12:15:52  <Rubidium> I wonder whether there will be TTDP releases (that includes new nightlies)
12:16:14  <frosch123> ttdp compile farm broken?
12:16:26  <planetmaker> lol, you're right Yexo :-)
12:16:34  <Hirundo> still, it shouldn't assert
12:16:56  <Rubidium> frosch123: not functioning right now, like 95% of the compile farm
12:17:15  <Rubidium> it does openttd nightlies right now, without OSX. Nothing else
12:17:50  <Rubidium> but extrapolate the work from the last 3 months at ttdpatch
12:18:57  <Ammler> isn't it already 5 months without commit?
12:19:41  <frosch123> Ammler: it's not the first time with 5 months without commit
12:21:34  <planetmaker> before NewObjects?
12:21:48  <Brot6> NewGRF Meta Language - Revision 1423:492ce8f99496: Fix: don't assert but just raise an error if a... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/492ce8f99496
12:22:01  <frosch123> 5 months breaks were regular since patchman left
12:22:11  <frosch123> usually it was jgr adding something weird
12:22:47  <frosch123> or dalestan or lately lakie
12:22:49  <Rubidium> since ~jan 2006 I don't see any of such events
12:23:09  <Rubidium> a few months, okay... but this many months, nope
12:23:25  <frosch123> but then also eisos randomly commited some 'rework this or that' commit without any 'public' trigger
12:24:29  <Rubidium> march, june 2009, june 2010, feb-june 2011 are the months without commit since april 2006
12:25:08  <planetmaker> he
12:25:21  <planetmaker> so it is the longest time w/o commit so far
12:26:04  <andythenorth> hmm
12:26:08  <andythenorth> no more TTDP?
12:26:44  <frosch123> Rubidium: ok, looks my subjective memory was quite wrong
12:27:25  <andythenorth> TTDP is useful - provides an alternative voice
12:27:42  <frosch123> but then again, jgr switched to playing ottd (and he always only coded stuff for his own play), eis_os announced he is working on archiving stuff, dalestan is totally gone
12:27:51  <frosch123> which makes only lakie remain
12:28:09  <frosch123> andythenorth: nope, dalestand provided an alternative voice
12:28:28  * andythenorth liked dalestan's modus operandi
12:28:45  <Yexo> and lakie has been playing and looking into coding for openttd too
12:30:00  <Ammler> andythenorth: there are still OTTDPs ;-)
12:30:08  <andythenorth> eh?
12:30:21  <Ammler> like chilipp
12:31:00  <andythenorth> oic
12:32:13  <frosch123> chillpp exists for long already, doesn't it?
12:32:37  <Yexo> over a year already
12:32:45  <frosch123> i mean there was some time, when every one another pp popped up, and vanished after a few weeks
12:33:56  <planetmaker> yup, chill is quite persistant
12:34:02  <Ammler> well, the pps life as long as the patcher behind it
12:34:30  <Rubidium> they'll usually live a few weeks or a few years, but they die under their own success
12:34:32  <Ammler> community packs weren't really successful :-)
12:34:39  <planetmaker> nope :-)
12:34:40  <frosch123> Ammler: but that also depends on the technical knowledge of the patcher
12:34:56  <frosch123> e.g. using mq etc.
12:35:05  <Ammler> chili doesn't
12:35:20  <frosch123> not? :o
12:35:45  <Ammler> no, the single patches in his "sources" are the patches from the time he took it
12:35:51  <Yexo> not sure what he does, but I thought he did update each patch separately
12:36:11  <Rubidium> he said manually merges patches
12:38:10  <Ammler> hmm, then maybe he has different sources...
12:53:08  <Hirundo> frosch123: Actually, the feature byte of action1 is not checked during the global check
12:53:43  <frosch123> what check?
12:53:56  <frosch123> in ottd?
12:54:00  <Hirundo> in ttdp
12:54:49  <Hirundo> docheckfeature (grfact.asm) defines what features need a check, that includes only actions 0, 2, 3 and 13
12:55:16  <Hirundo> For action1 there's a separate check when actually processing the action, but it's pretty easy to mask a bit there
12:56:07  <frosch123> "so far that's actions 0, 2-4 and 13 (not 1 because the sprites need to be skipped always)" <- i see :)
12:57:48  <Hirundo> though curiously, bit 4 is not set
12:59:28  <Hirundo> That doesn't make setting a bit in the feature byte a very nice implementation, though
13:00:18  <frosch123> yeah, we should find some special values for the num-sets and num-ents
13:01:23  <Yexo> I doubt that's possible, unless you want to go for FF FF FF as special value for num-ents or so
13:01:24  <Hirundo> FF for num sets?
13:01:36  <Yexo> Hirundo: there are newgrfs with a lot of sets
13:01:41  <Yexo> not sure if any uses FF
13:01:56  <Hirundo> The FF -> extended byte transition has been done before
13:02:14  <Hirundo> Except this time, it's not changed to make it an extended byte :)
13:02:51  <Hirundo> num-ents FFFF is certainly unused, though because of the sprite limit
13:03:50  <frosch123> well, maybe feature bit 7 is still the nicest :p
13:05:09  <frosch123> and the 'need to skip sprites independent of feature' reason makes it special anyway
13:06:35  <Hirundo> agreed
13:14:14  <Brot6> NewGRF Meta Language - Feature #2746: station support (Hirundo) @ http://dev.openttdcoop.org/issues/2746#change-6911
13:15:54  <planetmaker> Hirundo: why remove ttdsprite?
13:16:08  <planetmaker> what advante is gained?
13:18:04  <frosch123> btw. when you are writing some official documentation, please call it advanved sprite layout. extended sprite layout was already the name for the normal (non-basic) layout
13:18:33  <Hirundo> planetmaker: Currently there are two properties for essentially the same thing
13:18:54  <Hirundo> when implementing ASL, you would get 'ttdpalette' and 'palette' also
13:19:39  <Brot6> NewGRF Meta Language - Feature #2746: station support (yexo) @ http://dev.openttdcoop.org/issues/2746#change-6912
13:19:40  <Yexo> Hirundo: only for stations
13:20:16  <Yexo> I don't see a way around having two distinctive properties for station spritelayouts
13:20:29  <Yexo> I mean sprite/ttdsprite and palette/ttd_palette
13:21:09  <planetmaker> I don't find it particularily bothersome to need to know which is a base set and a normal sprite in advance. One would need to specify that anyway, would one?
13:21:28  <Yexo> planetmaker: "ttdsprite: literal_number;" "sprite: spriteset_name;"
13:21:35  <Yexo> you can see from the type which one it is
13:21:50  <planetmaker> hm... also true
13:21:53  <Hirundo> or "or sprite: some_number" for stations
13:21:58  <Yexo> however that doesn't work for stations
13:22:18  <planetmaker> hm because $$%&" stations are special again...
13:22:39  <Yexo> actually stations aren't so bad
13:22:51  <Yexo> in this case I'd argue they're better than the other features
13:22:58  <planetmaker> :-)
13:23:16  <planetmaker> how do they do it?
13:23:31  <Yexo> see my examples in the task above
13:23:42  <Yexo> it allows for selecting multiple spritesets per spritelayout
13:23:48  <Yexo> which means easy combining of sprites
13:24:45  <planetmaker> spriteset as e.g. construction stages?
13:24:57  <Hirundo> easy, from an NML POV
13:31:24  <frosch123> yay... i could have bet on that... jsignals.grf does not check the callback id and has no callback-failure action2. (which is also undocumented)
13:32:27  <Yexo> that brings me to a related topic: what is the best way to fail a callback?
13:32:56  <Yexo> currently nml does that by pointing to id 00 and making sure there is no action2 with that id
13:33:14  <frosch123> you should chain to a basic action2
13:33:56  <frosch123> either your normal graphics, the production callback, or just some action2 without any sets at all
13:34:00  <Yexo> and if those are not available?
13:35:03  <frosch123> you can always define a dummy action2, except the format is not specified for sounds and signals (which i am currently looking into)
13:35:47  <Yexo> but if you don't have an action1, that means openttd will execute; grfmsg(0, "NewSpriteGroup: No sprite set to work on! Skipping");
13:35:59  <Yexo> which is fine, but makes it looks bad
13:37:24  <frosch123> "Neither num-loadtypes nor num-loadingtypes may be zero, there must be at least one state for each." <- hmm, from action2/vehicles
13:37:39  <frosch123> i remember seeing action1 with 1 set but 0 sprites
13:38:13  <Yexo> ah, didn't think of that
13:41:11  <Brot6> NewGRF Meta Language - Feature #2746: station support (Hirundo) @ http://dev.openttdcoop.org/issues/2746#change-6913
13:43:31  <Yexo> Hirundo: and how should your example be translated to nfo?
13:43:49  <Yexo> where your example reads CB_FAILED it should point to the real action2
13:44:45  <Hirundo> That would be added by NML, in-between the graphics block and the first action2
13:45:21  <Yexo> which means nml would have to copy the complete switch-block tree
13:45:51  <Hirundo> No, it would just have to add one
13:46:00  <Hirundo> Let me write example
13:48:13  <Hirundo> Yexo: http://pastebin.com/Zvny0Eke
13:48:59  <Brot6> NewGRF Meta Language - Feature #2746: station support (Hirundo) @ http://dev.openttdcoop.org/issues/2746#change-6913
13:50:22  <Yexo> ugly, but should work
13:52:18  <Yexo> Hirundo: could you rewrite this example too? http://pastebin.com/tQiUswJy
13:55:12  <Yexo> http://pastebin.com/8wpkcmW8 like this?
13:55:27  <Hirundo> ^yes
13:55:54  <Yexo> that nml code definitely looks better than my examples
13:55:59  <Yexo> planetmaker: any opinion?
13:56:00  <Hirundo> A sprite set for stations is nothing but an offset into the action1 block, so that's actually really easy
13:57:35  <Yexo> this also allows normal use of action3 to chose between cargo types, right?
13:57:48  <planetmaker> that example http://pastebin.com/8wpkcmW8 looks pretty easy and powerful to use
13:58:34  <planetmaker> the sprite layout is a sort-of template for the tile and then I just fill it with different sprites...
13:58:46  <Hirundo> action3'd be possible, it requires N action2s in-between but that should be doable
13:59:41  <Yexo> Hirundo: I'm convinced, let's go for it!
14:00:02  <Hirundo> great :)
14:00:11  <planetmaker> also for other features than stations?
14:00:28  <Hirundo> Allow me to do some work on tomorrow's exam first, though ;)
14:00:40  <planetmaker> :-D
14:00:55  <planetmaker> good luck with that
14:01:43  <Yexo> <planetmaker> also for other features than stations? <- I don't see why not actually
14:01:55  <planetmaker> :-)
14:02:02  <Yexo> it's just require duplicating the action2 (=spritelayout) for each different spriteset argument
14:03:49  <frosch123> how would you use sprites from different sets with that syntax?
14:03:51  <planetmaker> it would also make much sense for airport tiles
14:04:03  <planetmaker> saving IDs
14:04:36  <Hirundo> Yexo: You can also add all sets that are possibly used in the layout to that layout's action1
14:04:42  <Yexo> frosch123: for stations we merge everything in a single action1 set
14:04:54  <Hirundo> hmm nvm
14:05:15  <Hirundo> selecting different sets based on ASL/registers is a no-no
14:05:21  <Yexo> Hirundo: yes, I think it'd be easier to just add all station spritelayouts to the first station action0, then use the copy feature for other stations
14:05:37  <frosch123> Yexo: ok, i ask differently. building { sprite: set(0); } <- is that 0 a constant, or can it link to a switch(){}
14:05:38  <Hirundo> We do need to look at conditional skipping in that case
14:05:51  <Yexo> frosch123: variable, using advanced sprite layout
14:07:06  <Yexo> set1 {A, B} set2 {C, D} in nml is converted to bigset{A,B,C,D} in nfo, set2(1) is converted to bigset(1+offset(set2)) = bigset(3)
14:08:22  <frosch123> so you can write "set(terrain_type == 3 ? 1 : 0)" ?
14:08:29  <Yexo> yes
14:08:42  <frosch123> ok :)
14:08:55  <planetmaker> :-)
14:10:39  <Yexo> planetmaker: it'll not "safe" any ids
14:13:13  <planetmaker> but possibly some thought ;-)
14:15:55  <Yexo> if we manage to pull this station code off it'll be the best abstracting away from nfo so far
14:17:58  <planetmaker> :-)
14:17:59  <frosch123> where does that code snippet specify the values for extra_callback_info1?
14:18:41  <frosch123> hmm, maybe i misinterpreted something
14:19:33  <Yexo> no, the nml code was wrong
14:19:36  <Yexo> this is the correct example: http://pastebin.com/seGJuF92
14:20:52  <frosch123> so, you do everything inside cb14 and hide the graphics resolving, right?
14:20:58  <Yexo> yep
14:22:11  <Yexo> http://pastebin.com/KUxrSjJM this basically
14:24:22  * planetmaker senses an NML version of chips ;-)
14:25:16  <frosch123> so, you also do the "loading stages" completely via asl?
14:26:22  <Yexo> hmm, that is a consequence of this, yes
14:28:31  <frosch123> random note: though there was never a newgrf for cb 144 (ambient sound) releases, there was apparently not even a testgrf for it... ttdp crashes when that cb fails (which seems to be needed for playing no sound for once)
14:28:42  <Yexo> hmm, is cb 14 always called directly before the normal action2 resolving?
14:29:03  <Yexo> ie if we set registers in cb 14, are they still valid during the normal action2 resolving for asl?
14:29:11  <frosch123> Yexo: officially not
14:29:21  <frosch123> and also there might be recolour callbacks between them
14:29:30  <Yexo> crap, that breaks this syntax
14:30:55  <frosch123> how do custom foundations fit into that syntax btw?
14:31:21  <Yexo> how are custom foundations done in nfo?
14:31:35  <frosch123> special value in var10 when resolving sprites
14:31:45  <frosch123> 0 for normal sprites
14:31:52  <frosch123> 1 for the ground when special bit is set
14:32:01  <frosch123> 2 for foundations when they are enabled
14:32:06  <frosch123> other values from asl
14:33:56  <Yexo> I guess not, unless they get special syntax in the spritelayout block
14:37:01  <Yexo> Hirundo: ^^ much as I like the syntax, in it's current form it doesn't work
14:37:36  <Hirundo> what doesn't work?
14:38:23  <Yexo> from cb 14 you want to return the used spriteset and action2 indices in it. However you can't set the advanced sprite layout registers from cb14
14:39:06  <Hirundo> These layout registers are set in CB 0 ?
14:39:11  <Yexo> yes
14:41:35  <frosch123> Yexo: maybe instead of hiding the sprite resolving chain, hide cb14 instead
14:41:49  <frosch123> so you can do the same chain for sprites and cb14
14:41:56  <frosch123> and only branch between them at the very end
14:42:55  <Yexo> hmm, that might work
14:43:29  <Hirundo> There's already an in-between action2 there to perpare the registers, so it doesn't hurt that much
14:43:34  <Yexo> since switch-blocks can be shared between different stations, that means that the spritelayouts need to have the same index in multiple stations, which means we probably will need to put all spritelayouts in all station action0's
14:44:01  <Hirundo> That was already the case
14:44:42  <Yexo> ok, so custom foundations are left
14:48:08  <frosch123> add a "foundation:" to spritelayout {} ?
14:50:24  <Hirundo> How do foundations work for objects and such?
14:50:50  <frosch123> they can only disable default drawing
14:51:00  <frosch123> and then need to do everything in the layout themself
14:52:11  <Hirundo> Which would be quite nasty pre-ASL, I presume
14:52:23  <planetmaker> lengthy
14:52:24  <frosch123> "foundation:" is not exactly feasible to add to non-station spritelayouts :)
14:52:51  <frosch123> Hirundo: yes, there were like 1000+ cases for ecs forrests
14:53:03  <frosch123> iirc planetmaker counted them once :p
14:53:32  <planetmaker> not cases, but sprite count for forests was of that order, yes
14:54:03  <planetmaker> but forest don't draw foundations
14:54:10  <frosch123> well, separate spritelayouts for all slopes, all growing states, gound types, and so on :)
14:54:12  <planetmaker> they just use the slope
14:54:26  <planetmaker> yep. And then like 6(?) industry layouts
14:55:04  <frosch123> planetmaker: in this content it does not matter, whether a foundation or a tree is drawn :p
14:55:22  <planetmaker> :-)
14:55:54  <planetmaker> trees are just unfinished foundations :-P
14:56:06  <Yexo> frosch123: what are the options a newgrf has wrt station foundations: 1. don't draw any and 2. provide a custom sprite ?
14:56:21  <Yexo> in case 2. the grf would have to check the slope itself?
14:56:32  <Yexo> and I hope also option 3. draw default foundations
14:57:55  <frosch123> Yexo: http://newgrf-specs.tt-wiki.net/wiki/Action0/Stations#General_Flags_.2813.29
14:57:56  <Webster> Title: Action0/Stations - GRFSpecs (at newgrf-specs.tt-wiki.net)
14:58:08  <frosch123> there are two possible action1 sets to supply
14:58:23  <frosch123> no idea what happens if the set contains too few sprites :)
15:01:45  <frosch123> Yexo: wrt. "loading stages". i believe you can use a procedure call to convert it into an ordinary variable
15:02:20  <Yexo> how would you do that?
15:02:35  <Yexo> I did think of storing the value in a register
15:03:07  <frosch123> use a var 7E procedure, which chains to a station action2 which has callback results instead of spritesets
15:03:53  <frosch123> you could add some special nml variable "cargo_amount(little_cases, lots_cases)" which would return a number for the little- or lots-amounts
15:05:09  <Yexo> a regular action2 can return a callback result instead of a spriteset?
15:05:16  <frosch123> yes
15:05:45  <frosch123> at least i think so :p
15:06:16  <Hirundo> According to spec, or according to openttd implementation?
15:06:51  <frosch123> i remember a randomaction2 with callback results
15:07:14  <Yexo> yes, but in a randomaction2 it makes more sense
15:07:26  <Yexo> however the openttd code allows it
15:07:55  <frosch123> ttdp code seems to allow it as well
15:07:57  <Yexo> the spec makes no mention of it
15:08:04  <Yexo> "The sets from the most recent action1 to use for this set-ID, for each stage of numlittlesets and numlotssets, i.e. in total numlittlesets+numlotssets entries. "
15:08:10  <Yexo> that reads like it's not allowed
15:08:15  <Yexo> but if both openttd and ttdpatch allow it, why not
15:13:35  <frosch123> hmm, maybe ttdp does not
15:20:00  <frosch123> nah, got confused. it should work in ttdp just fine
15:20:26  <Yexo> if ttdpatch will ever support asl, otherwise the question is mood anyway :)
15:21:47  * planetmaker has some doubts. But I'm in a screw ttdp mood today anyway ;-)
15:42:16  <JVassie> screw ttdp!!
15:49:49  <frosch123> ttdp is fun for exploring :) (not for playing)
15:50:09  <frosch123> so, apparently to make a callback fail, the action2 must reference at least one action1 spriteset
15:50:29  <frosch123> so there must be sound and signal action1 with zero sprites
15:50:35  <frosch123> just to allow callback failiure
15:52:46  <Yexo> and just referencing a non-existing action2?
16:01:17  <frosch123> looks like we could use num-sets = 0 to indicate a new action1 format
16:04:51  <frosch123> refrencing non-existant action2 is invalid
16:05:53  <Yexo> and referencing an action2 from a different feature?
16:06:12  <frosch123> i doubt anyone checks that :)
16:06:21  <frosch123> so it makes no difference
16:06:36  <frosch123> looks like ttdp has a limit of 64k action2 in total
16:06:36  <Yexo> would "action 1 with 1 set, 0 sprites, action2 that references the above action1" be a valid way to create a "callback failed" action2?
16:06:55  <frosch123> Yexo: i would say, the only way
16:07:09  <frosch123> i.e. the way i want to document on the wiki now
16:07:19  <Yexo> frosch123: I meant more in general
16:07:38  <frosch123> how do you mean?
16:07:44  <Yexo> say I do that and give that action1 and action2 both feature 00, could I use that action2 throughout the grf for all features?
16:08:20  <frosch123> not officially, but that feature test is commented out in ttdp as well
16:08:38  <frosch123> for industries you need a different format anyway
16:08:57  <frosch123> well, and for spitelayouts too
16:09:51  <frosch123> (well, only, if you mix features)
16:11:41  <planetmaker> aproprop... "var.Action 2" "VarAction2" Var. Action2" - what is preferred?
16:12:01  <frosch123> i very much prefer no space between Action and number
16:12:24  <Yexo> planetmaker: for page name or link text?
16:12:29  <frosch123> either VarAction2, AdvVarAction2, or VariationalAction2
16:12:50  <frosch123> (AdvVarAction2 is kind of out of context here, though)
16:16:13  <planetmaker> Yexo: in texts
16:16:27  <planetmaker> I prefer VarAction2 as I use it as a fixed word - sort-of
16:16:51  <frosch123> yup, me too
16:16:52  <Yexo> I'd prefer VarAction2 too
16:16:55  <Yexo> short enough, still clear
16:17:45  <frosch123> same for actions, it is either "Action2" (uppercase) as fixed name, or "action 2" (lowercase, and space)
16:18:23  <Yexo> so either "VarAction2" or "variational action 2" would be fine then
16:22:21  <planetmaker> Action2 would fit the same style then
16:25:22  <planetmaker> what about the VarAction2 "type". I find that a bit unfortunate formulation which initially only confused me
16:27:06  <frosch123> do you have a better name?
16:27:49  <Yexo> access-type ?
16:28:26  <planetmaker> hm... maybe it just needs a bit different explaining
16:53:08  <Brot6> NewGRF Meta Language - Revision 1424:0ae671f5d525: Change #2544: use installed nmlc (source bundl... (Ammler) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/0ae671f5d525
16:55:47  <frosch123> http://wiki.openttd.org/Frosch/Extended_Action_1#Suggestion_for_new_Action_1_format <- opinions on format proposal 2?
16:57:12  <Ammler> yexo, if r1424 works, we can close #2544
16:57:27  <Yexo> why not "00 <num-ent> <first-spriteset> <num-sets>" ?
16:57:33  <Yexo> that way only <num-sets> changes position
16:57:58  <Yexo> or if you want it to be more like the current format at least do "00 <num-sets> <num-ent> <first-spriteset>"
16:58:09  <Yexo> what you currently have is a mix of everything
16:59:47  <Yexo> nvm the above
16:59:54  <Yexo> I was comparing with proposal 1 instead of current situation
17:00:03  <Ammler> I assume, that would also find future setup issues like we had in the past which failed every nml project
17:00:39  <frosch123> Yexo: i don't think there is any point in trying to mimic the old format
17:00:50  <frosch123> just find a useful order
17:00:56  <Yexo> yes, agreed
17:01:00  <Yexo> new format looks fine
17:10:18  <Brot6> nml: update from r1417 to r1424 done - http://bundles.openttdcoop.org/nml/nightlies/r1424
17:13:35  <Brot6> NewGRF Meta Language - Feature Request #2761: Allow direct variable access in return statements (yexo) @ http://dev.openttdcoop.org/issues/2761#change-6914
17:18:17  <Brot6> airportsplus: update from r99 to r104 done - http://bundles.openttdcoop.org/airportsplus/nightlies/r104
17:19:42  <Brot6> firs: update from r2070 to r2081 done - http://bundles.openttdcoop.org/firs/nightlies/r2081
17:20:18  <Brot6> newgrf_makefile: update from r294 to r296 done - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/r296
17:20:52  <Brot6> ogfx-trains: update from r244 to r245 done - http://bundles.openttdcoop.org/ogfx-trains/nightlies/r245
17:21:03  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r40), ai-admiralai (r75), ai-aroai (r39), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r143), comic-houses (r71), fish (r653), frenchtowns (r6), german-townnames (r34), grfcodec (r832), grfpack (r279), heqs (r605), indonesiantowns (r41), manindu
17:21:03  <Brot6> (r7), metrotrackset (r56), narvs (r37), nml (r1424), nutracks (r202), ogfx-industries (r119), ogfx-landscape (r69), ogfx-rv (r107), ogfx-trees (r50), opengfx (r678), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r34), ttrs (r36), worldairlinersset (r672)
17:27:36  <Brot6> sub-landscape: compile of r66 still failed (#2616) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r66
17:28:34  <Brot6> sub-opengfx: compile of r666 still failed (#2586) - http://bundles.openttdcoop.org/sub-opengfx/nightlies/ERROR/r666
17:29:50  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: belarusiantowns (Diffsize: 30), frenchtowns, german-townnames, indonesiantowns (1 errors) (Diffsize: 1), manindu (Diffsize: 1), narvs (Diffsize: 3015), ogfx-industries (Diffsize: 32645), ogfx-landscape (Diffsize: 1176), ogfx-rv (Diffsize: 4590), spanishtowns (Diffsize: 1), swedishrails (Diffsize: 3304), swisstowns
18:01:39  <Brot6> NewGRF Meta Language - Feature #2544 (Closed): rpm (Ammler) @ http://dev.openttdcoop.org/issues/2544#change-6915
18:03:46  <Brot6> NewGRF Meta Language - Bug #2155: NML installation on windows (Ammler) @ http://dev.openttdcoop.org/issues/2155#change-6916
18:04:26  <Ammler> Yexo: #1422 is dummy?
18:04:26  <Brot6> Ammler: Yexo: #1422 is http://dev.openttdcoop.org/issues/show/1422 "NewGRF Meta Language - Code Review #1422: Review setup.py - #openttdcoop Development Zone"
18:04:38  *** ODM has joined #openttdcoop.devzone
18:05:06  <Ammler> also you have many open tickets with target 0.1.0, btw. :-)
18:05:14  <Yexo> yes, I know
18:05:24  <Yexo> those are still valid but didn't get done before 0.1.0
18:05:28  <Brot6> NewGRF Meta Language - Code Review #1422 (Closed): Review setup.py (yexo) @ http://dev.openttdcoop.org/issues/1422#change-6917
18:13:01  <frosch123> http://newgrf-specs.tt-wiki.net/wiki/Features <- what do you think, should that page be linked from all actions with a feature-byte, and should the individual tables from the action2 be removed? or should the actions keep a list of supported features (sometimes smaller, currently sometimes just incomplete)
18:13:02  <Webster> Title: Features - GRFSpecs (at newgrf-specs.tt-wiki.net)
18:16:29  <Yexo> frosch123: airports do have feature specific variables
18:16:32  <Yexo> they're just not documented yet
18:17:00  <Yexo> ok, only var 40 and several vars copied from stations :p
18:17:40  <frosch123> sounds like something for the growing TODO list :)
18:18:40  <Yexo> I like the direction links on the Action0 page for example
18:19:05  <frosch123> added todo item for airpots
18:19:07  <Yexo> so I'm in favor of linking to that page but also keeping the original table intact
18:20:05  <planetmaker> vars 0x40, 7c, fa and f0 for airports, right?
18:20:32  <frosch123> looks like
18:20:48  <frosch123> no, also all station variables
18:20:56  <Yexo> and several station vars
18:21:24  <planetmaker> frosch123: I'd like to keep the existing feature bytes in the action2, but of course linked
18:21:47  <Yexo> var 48, 8A, F1,F2,F3,F6,F7, 60..65, 69, 8C..EC
18:21:50  <frosch123> hmm, 7c does not documenting, and why is there special handling for f0 and fa?
18:21:59  <planetmaker> hm, where do I see that in the code?
18:22:20  <Yexo> frosch123: those are in StationGetVariable, not Station::GetNewGRFVariable
18:22:27  <frosch123> planetmaker: return st->GetNewGRFVariable(object, variable, parameter, available);
18:22:41  <frosch123> yeah, so quite a subset :p
18:22:57  <Yexo> those have to be duplicated somewhere
18:23:19  <Yexo> if they're moved from StationGetVariable to Station::GetNewGRFVariable they'd be duplicated in Waypoint::GetNewGRFVariable
18:23:25  <frosch123> i guess the current VariationalAction2/Stations page should be split
18:23:39  <frosch123> in railstation variables, and station variables also applying to airports
18:59:11  <planetmaker> hm... s/VarAction2\/Stations/VarAction2\/RailStations/ ?
18:59:40  <planetmaker> and only keep the general stuff common to all stations (Airports, RailStations) there?
19:02:08  <frosch123> or add something like BaseStation instead
19:02:30  <frosch123> no idea, but "Stations" is so established for rail stations
19:02:57  <frosch123> you would also need to rename action0, randomaction2 and lots of other stuff
19:03:17  <frosch123> so BaseStation or whatever might cause less trouble :)
19:03:39  <frosch123> or Common Station? Shared Station?
19:04:40  <planetmaker> BaseStation
19:04:48  <planetmaker> it's established in ottd source ;-)
19:06:37  <planetmaker> could also then at a later date be shared by ports and RV stations... :-P
19:10:02  <Yexo> planetmaker: BaseStation is the basis of RailwayStation and Waypoint
19:10:14  <planetmaker> yes, I know, still ;-)
19:13:26  <Yexo> I agree on BaseStation, just not with the reasoning ;)
19:17:16  <JVassie> BabeStation? :D
19:17:38  <planetmaker> hm, all those variables are not documented anyway except FA and F0 and 48
19:18:17  <planetmaker> well, 60s are, but...
19:19:18  <Yexo> we should review anyway which 80+ vars to document and which not
19:30:32  <planetmaker> also the Fx variables are all missing
19:31:29  <frosch123> what's that?
19:37:17  <Hirundo> Yexo: Shall I continue with the ttdsprite->sprite change, and implement ALS bits 3-5 ?
19:37:21  <Hirundo> *ASL
19:38:00  <Yexo> sure
19:57:28  <planetmaker> hm, where in the code do I find the variable sizes? newgrf saveload somewhere... but where?
19:59:12  <Yexo> sizes of what?
19:59:33  <Yexo> all variables are 32bit in openttd code
19:59:40  <planetmaker> the grf size
19:59:49  <Yexo> only not all contain 32 meaningful bits
19:59:54  <planetmaker> within the grf B / W / D
20:00:18  <planetmaker> thus where the grf is read OpenTTD knows about it
20:00:36  <Yexo> are you talking about varaction2?
20:00:42  <planetmaker> yep
20:00:52  <Yexo> when reading the grf the variable sizes don't matter yet
20:01:05  <planetmaker> he, you're right...
20:01:13  <Yexo> when the varaction2 chain is used (and as such variables are referenced), they matter a bit
20:01:30  <Yexo> but at that time the grf specifies what size it wants to read (via the 'type' parameter)
20:02:08  <Yexo> openttd then treats every variable as 32bit and just truncates it to the size the grf wants before it uses the value
20:02:24  <Yexo> the latter is done in newgrf_spritegroup.cpp I believe
20:07:05  <Brot6> NewGRF Meta Language - Revision 1425:871d5acb0ea5: Cleanup: remove unused variable (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/871d5acb0ea5
20:07:05  <Brot6> NewGRF Meta Language - Revision 1426:c069de1c7c47: Feature #2760: allow non-const expressions in ... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c069de1c7c47
20:07:46  <Brot6> NewGRF Meta Language - Feature Request #2760 (Closed): Allow non-const expressions in random action2 (planetmaker) @ http://dev.openttdcoop.org/issues/2760
20:07:46  <Brot6> NewGRF Meta Language - Feature Request #2760 (Closed): Allow non-const expressions in random action2 (yexo) @ http://dev.openttdcoop.org/issues/2760#change-6918
20:12:14  <frosch123> planetmaker: for 80+ variables the "original size" is just to offset to the next variable
20:12:42  <Yexo> planetmaker: about #2761: if you want to return variables, should the "SELF" scope be assumed?
20:12:42  <Brot6> Yexo: planetmaker: #2761 is http://dev.openttdcoop.org/issues/show/2761 "NewGRF Meta Language - Feature Request #2761: Allow direct variable access in return statements - #openttdcoop Development Zone"
20:12:57  <frosch123> for 40+ and 60+ variables the size is basically always D (if the size differs it is likely already documented)
20:13:00  <planetmaker> Yexo: yes
20:13:02  <Yexo> what should happen if you do switch(.. , PARENT, ...) { return some_var; } ?
20:13:10  <Yexo> only vars from self scope?
20:13:14  <frosch123> for 00-3f there is no easy way to tell
20:14:02  <planetmaker> Yexo: probably I'll come up with the desire to access parent scope, too. But that's far less common
20:14:16  <Yexo> question is: do we want to allow that at all?
20:14:23  <planetmaker> one could think of something like parent.varname to explicitly chose a scope
20:14:33  <Yexo> you can always create an extra switch-block yourself if you need to access it
20:14:42  <planetmaker> yep
20:15:12  <planetmaker> the question though is also valid the other way around: why not allow it?
20:15:35  <Yexo> because there is no obvious syntax for it
20:15:44  <planetmaker> :-)
20:15:53  <Yexo> if you want to go for something like parent.varname or parent::varname that can always be introduced later
20:15:59  <Yexo> that doesn't break existing syntax
20:16:11  <planetmaker> then I'm happy with no parent scope for now
20:16:33  <Yexo> for now :p
20:23:33  <Brot6> NewGRF Meta Language - Revision 1427:73eb7cf239cc: Fix: using 'return param[x];' in a switch or r... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/73eb7cf239cc
20:40:03  <planetmaker> of course 'for now' ;-)
20:40:22  <planetmaker> We have a small children's book here: "Die kleine Raupe Nimmersatt" ;-)
20:40:57  <planetmaker> http://www.google.com/search?q=kleine+raupe+nimmersatt&hl=en&client=firefox-a&hs=xNk&rls=org.mozilla:de:official&prmd=ivns&tbm=isch&tbo=u&source=univ&sa=X&ei=xV7-TZT0G4jxsgaXwdTyDQ&ved=0CDIQsAQ&biw=1280&bih=648 <-- maybe you know it in Dutch? ;-)
20:40:58  <Webster> Title: kleine raupe nimmersatt - Google Search (at www.google.com)
20:41:47  <Yexo> I know it, although I don't remember the name
20:42:18  <planetmaker> always hungry ;-)
20:42:25  <frosch123> Rupsje Nooitgenoeg
20:42:31  <planetmaker> except when asleep :-P
20:42:44  <planetmaker> ha, sounds like it :-)
20:42:45  <frosch123> wikipedia knows everything :p
20:42:48  <planetmaker> sure
20:42:49  <Yexo> frosch123: yes :)
20:42:53  <Yexo> that was it
20:43:12  <frosch123> planetmaker: moved your page to make it a subpage
20:43:26  <planetmaker> ok :-)
20:43:32  <dihedral> good evening
20:43:59  <Yexo> evening dihedral
20:44:13  <frosch123> btw. shouldn't we just remove 'done' stuff from the todo list?
20:44:17  <planetmaker> frosch123: you mean basestation? I thought it was...
20:44:22  <planetmaker> but well :-)
20:44:23  <frosch123> no, airports
20:44:26  <planetmaker> oh
20:44:34  <planetmaker> thanks
20:44:59  <planetmaker> sounds like a good time to go to bed then ;-)
20:45:01  <dihedral> the Yexo :-)
20:45:12  <Yexo> the one and only :)
20:45:19  <planetmaker> so ... hello dihedral and good night all :-)
20:45:23  * dihedral is in bed too
20:45:26  <Yexo> good night planetmaker
20:45:30  <dihedral> with grapes ^^
20:47:05  <dihedral> sleep well pm
20:52:11  <andythenorth>  /me -> bed
20:52:15  <andythenorth> good night
20:52:18  *** andythenorth has quit IRC
21:03:03  *** bodis has quit IRC
21:22:15  *** frosch123 has quit IRC
21:22:29  *** ODM has quit IRC
23:48:36  *** JVassie has quit IRC

Powered by YARRSTE version: svn-trunk