Log for #openttdcoop.devzone on 22nd May 2011:
Times are UTC Toggle Colours
01:58:41  *** KenjiE20 has quit IRC
05:53:56  *** Ruudjah has left #openttdcoop.devzone
06:43:12  *** andythenorth has joined #openttdcoop.devzone
06:51:17  <Brot6> FISH - Bug #2644 (New): Lighting wrong on small vehicle ferry (andythenorth) @
06:56:41  *** andythenorth has quit IRC
07:35:25  *** ODM has joined #openttdcoop.devzone
07:40:07  *** andythenorth has joined #openttdcoop.devzone
07:41:17  <Brot6> FISH - Feature #1140 (Rejected): Convert Utility Vessels to cpp offsets (andythenorth) @
07:42:27  <Brot6> FISH - Feature #1138 (Rejected): Show some cargos in graphics? (andythenorth) @
07:43:33  <Brot6> FISH - Feature #2360 (Closed): Add variety to fishing boats (andythenorth) @
07:43:33  <Brot6> FISH - Feature #1411 (Rejected): Lumber and Wood graphics for Coasters, Traders (andythenorth) @
07:45:37  <Brot6> FISH - Feature #2645 (New): Graphics for 12t utility vessel (andythenorth) @
07:45:37  <Brot6> FISH - Feature #2646 (New): Graphics for 52t utility vessel (andythenorth) @
07:46:47  <Brot6> FISH - Feature #2647 (New): Medium utility tug (fast) (andythenorth) @
07:49:50  <Brot6> FISH - Feature #2648 (New): Tweak shading on puffer graphics (andythenorth) @
07:55:06  *** frosch123 has joined #openttdcoop.devzone
09:25:50  <planetmaker> hm, so no cargo sprites for ships, andythenorth ?
09:27:11  *** andythenorth has quit IRC
09:27:11  *** andythenorth_ has joined #openttdcoop.devzone
09:38:47  *** andythenorth_ has quit IRC
09:38:47  *** andythenorth has joined #openttdcoop.devzone
09:39:51  *** andythenorth_ has joined #openttdcoop.devzone
09:42:09  <andythenorth_> I think not
09:42:28  <andythenorth_> too many other things I could do instead
09:45:42  <planetmaker> hm... cargo sprites add a lot to a set's beauty
09:49:37  *** KenjiE20 has joined #openttdcoop.devzone
11:56:28  *** andythenorth_ is now known as anybody
11:57:05  *** anybody is now known as andythenorth
13:00:19  <Brot6> FISH - Revision 644:5ebf8518d36b: Change: work in progress to improve lighting of coasters (andythenorth) @
13:29:17  *** LordAro has joined #openttdcoop.devzone
14:27:38  *** andythenorth_ has joined #openttdcoop.devzone
14:33:52  *** andythenorth has quit IRC
15:23:46  *** andythenorth_ has quit IRC
16:25:29  <Brot6> nutracks.clone: update from  to 1.1.0 done -
16:27:37  <Brot6> nutracks.clone: update from  to r195 done -
16:27:45  <Brot6> nutracks.clone: compile of r195 failed -
16:27:56  <Ammler> hmm
16:29:00  *** andythenorth has joined #openttdcoop.devzone
16:29:27  <planetmaker> "interesting"
16:33:19  <Brot6> nutracks.clone: update from r195 to r196 done -
16:33:29  <Brot6> nutracks.clone: compile of r196 failed -
16:36:52  <Brot6> nutracks.clone: update from r196 to r197 done -
16:37:02  <Brot6> nutracks.clone: compile of r197 failed -
16:38:24  <planetmaker> what is this "unknown revision r197"?
16:41:16  *** LordAro has quit IRC
16:45:20  <Ammler> ?
16:46:09  <planetmaker> in the error log
16:46:17  <Ammler> it does compile default as release but I wasn't able to reproduce it with test
16:46:25  <Ammler> so I play with a nutracks clone
17:02:29  *** andythenorth has quit IRC
17:18:28  <Brot6> fish: update from r638 to r644 done -
17:18:43  <Brot6> german-townnames: update from r33 to r34 done -
17:19:18  <Brot6> nutracks: update from r190 to r193 done -
17:19:46  <Brot6> nutracks.clone: update from r92 to r197 done -
17:19:54  <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), airportsplus (r75), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r141), comic-houses (r71), firs (r1994), frenchtowns (r6), grfcodec (r829), grfpack (r279), heqs (r605), indonesiantowns (r41), manindu
17:19:54  <Brot6> (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r289), nml (r1349), ogfx-industries (r105), ogfx-landscape (r68), ogfx-rv (r107), ogfx-rv.clone (r103), ogfx-trains (r241), ogfx-trees (r44), opengfx (r669), 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
17:19:56  <Brot6> (r36), worldairlinersset (r671)
17:20:35  <Brot6> sub-landscape: compile of r66 still failed (#2616) -
17:21:21  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
17:37:56  <Terkhen> ... this town is too small for having {STRING} industries of this type (there can be only one of these industries for every 10 houses) <--- it is possible to set a parameter that receives an integer? (nml)
17:47:22  <Terkhen> hmm... the newgrf specs hint that it is not possible to return error strings with numerical parameters
17:47:44  *** andythenorth has joined #openttdcoop.devzone
17:48:25  <Terkhen> will it work if I set 0x100 to STR_JUST_INT and 0x101 to the numerical value I want to show?
17:49:53  <Yexo> why not just set 0x100 to the numerical value and use {DWORD_S} instead of {STRING} ?
17:52:08  <Terkhen> Yexo: thanks, that shows a number :)
17:52:27  <Terkhen> it's showing -1, but that's probably because my code is wrong :P
18:04:30  <Terkhen> <-- what could be causing the "always show -1" issue?
18:25:04  <Terkhen> hmm... no matter what I put inside 0x100 I get the same result
18:44:31  <Yexo> Terkhen: sorry, got a phone call
18:44:35  <Yexo> do you have a small test case?
18:45:05  <Terkhen> no problem :)
18:45:07  <Terkhen> I'll code one
18:45:45  <Brot6> OpenGFX+ Industries - Bug #2578 (Closed): Power plants can close even if serviced (Terkhen) @
18:45:45  <Brot6> OpenGFX+ Industries - Revision 106:c581b908bae1: Fix #2578: Banks now close after a random interv... (Terkhen) @
19:09:25  <Terkhen> heh, in my test case the parameter actually works
19:09:37  <Terkhen> so I managed to create some working code to compare :P
19:10:50  <Terkhen> <--- this is the working code, 210 has the "broken" one
19:11:07  <Terkhen> TEMP variables are not preserved between different switches called on the same callback?
19:18:09  <Terkhen> hmm... they are conserved, otherwise the other store would not work
19:20:34  <Terkhen> ok, I got it :)
19:20:39  <Terkhen> <--- this works, 210 does not
19:20:52  <Terkhen> I need to set the parameters inside 0x100 in the same switch that uses them :)
19:29:47  <Terkhen> planetmaker: <--- IMO 50 houses is too small... at least for really big towns
19:35:09  <planetmaker> @calc sqrt(50)
19:35:09  <Webster> planetmaker: 7.07106781187
19:35:19  <planetmaker> that's also not a big area ;-)
19:36:28  <planetmaker> and yes, I do agree, 50 seems too small
19:36:42  <planetmaker> a random start town of 2500k people already had 60
19:37:37  <planetmaker> maybe 100 or 150
19:38:06  <planetmaker> make it an easy define in header.pnml ;-)
19:49:01  <Terkhen> planetmaker: diff updated, it is IMO looking good for big towns with 150 :)
19:54:03  <Yexo> <Terkhen> I need to set the parameters inside 0x100 in the same switch that uses them :) <- that shouldn't be necessary
19:54:25  <Hirundo> Yexo: wrt. your earlier comment, changing the sorting order doesn't really help I think, as sorting matters little if you try to allocate 300 action2 ids in one go
19:55:10  <Yexo> Hirundo: suppose we have action2's A, B, C and D. C refers to A and B. Both C and D are referred to from the same action3
19:55:21  <planetmaker> looks nice
19:55:46  <Yexo> we can assign A=1, B=2, C=1 (reuse id from A), D=2 (reuse from B, since it's not referenced after here)
19:55:48  <Terkhen> Yexo: I can create a small example that reproduces the issue if necessary
19:55:54  <Hirundo> Are you aware, that only action1 and real action2s are involved there ( ?
19:56:01  <Yexo> if the order was A, B, D, C it's impossible to assign 2 to D
19:56:03  <Terkhen> but once I moved the store_temp to the switch using the string, it started working
19:56:31  <Yexo> Hirundo: no, but that makes sense :)
19:58:05  <Hirundo> I think parsing of any action1/2 should be deferred to the latest possible moment
19:58:06  <Yexo> Terkhen: I'll test myself with the diffs you already uploaded and if I can find the problem
19:58:28  <Yexo> Hirundo: isn't that done already?
19:58:33  <Hirundo> i.e. only start parsing stuff upon encountering an action3 and work backwards from there
19:58:35  <Yexo> if not, how would that help in this case?
19:58:50  <Terkhen> planetmaker: ok, I'll commit :)
19:58:50  <Hirundo> Currently action1/real2 is done upon hitting the first spriteset
19:59:00  <planetmaker> sweet :-)
19:59:06  <Yexo> hmm, ok
19:59:06  <Hirundo> And produce/switch/random is done wherever they're declared by the user
19:59:07  <Terkhen> note that this changes the requirement to 1.1.1-RC1 or greater :)
19:59:23  <Yexo> problem with the current language is that we cannot move the switch blocks around
19:59:46  <Yexo> since you can use param[x] in switch blocks, and the value of that can change between switch blocks, so it's invalid to move them around
19:59:47  <planetmaker> Our placement control? What'll happen, in 1.1.0?
19:59:52  <Hirundo> hmmm indeed
19:59:56  <Hirundo> didn't think of that
20:00:19  <Hirundo> perhaps, we should change that :)
20:00:37  <Yexo> not being able to use param[x] in switch-blocks is _very_ inconvenient
20:00:51  <planetmaker> quite. Then I rather have the current situation
20:01:08  <Hirundo> of course, but we could let param[x] refer to the 'final' value instead (using var 7F)
20:01:20  <planetmaker> it'd break most if not all of my grfs
20:01:49  <Yexo> that is a possible solution, but imo that is very counter-intuitive
20:02:02  <Hirundo> That depends on your intuition :)
20:02:42  <Yexo> param[x]=0; switch (..., param[x]) {...} param[x]=3; <- I'd definitely think param[x] is 0 inside the switch
20:03:31  <Hirundo> Global variables tend to work the other way round
20:03:52  <Hirundo> Stuff like lambda functions in python work like you describe
20:03:59  <Yexo> good point
20:06:31  <Hirundo> Even without moving switch blocks, I think there's a lot to gain by handling everything (including real action2) as late as possible
20:07:51  <Yexo> I agree
20:08:28  <Hirundo> 'everything' being spritesets/groups/layouts
20:09:20  <Yexo> handling the action1/real action2 at the location where it's now is no problem, as long as the action2's are only prepared and not directly written to the output
20:12:24  <Brot6> OpenGFX+ Industries - Revision 107:df53a952da30: Feature #2622: Limit the number of certain types... (Terkhen) @
20:12:37  <Terkhen> Yexo: <--- this diff file over OpenGFX+ Industries allows to reproduce the string parameter issue
20:16:57  <Yexo> Terkhen: how to reproduce the problem in-game?
20:17:42  <Terkhen> build water towers in a small town, when you build the second one it will display an error message
20:18:02  <Yexo> ok, thanks
20:18:04  <Terkhen> without the diff, the parameters will be correct, with the diff the number of industries will be -1 and the number of houses 256
20:24:05  <Yexo> Terkhen: the nfo code generated with your patch applied is totally bogus
20:24:11  <Yexo> so that's definitely a bug in nml
20:25:20  <Terkhen> ok, should I open a proper bug report?
20:25:38  <Yexo> doesn't really matter, I'm trying to fix it now
20:25:43  <Terkhen> ok :)
20:26:42  <Yexo> oh, it's not something nml can fix
20:26:50  <Yexo> industry_town_count uses register 0x100 and 0x101
20:27:47  <Yexo> so we'll need some extra documentation and you'll have to fix ogfx-industries yourself
20:29:33  <planetmaker> hm... sounds interesting... Still I'm dead tired and wish you a good night.
20:29:58  <Hirundo> Yexo: spritelayouts are a) capable of accessing parameters to set sprite numbers and b) they need to be moved around to comply with action1/action2 restrictions
20:30:01  <Yexo> night planetmaker
20:30:08  <Hirundo> ergo, we are in trouble already even without moving switches
20:30:12  <Hirundo> goodnight pm
20:30:24  <Terkhen> oh, true :/
20:30:30  <Terkhen> I forgot about that
20:30:43  <Yexo> Hirundo: indeed, that's bad :(
20:30:57  <Yexo> it's starting to look like your suggestion of using var 7F for parameters is the best option
20:31:05  <Hirundo> That won't fix layouts, though
20:31:48  <Yexo> oh, right, it's impossible to move layouts around :(
20:32:58  <Hirundo> If you don't re-use parameters all will be fine due to the various grf loading stages
20:33:35  <Yexo> but not re-using parameters is a lot to ask
20:33:41  <Yexo> and almost impossible to track automatically
20:34:10  <Hirundo> whoever made the design decision about action1/2 relationship...
20:34:17  <Hirundo> :S
20:35:47  <Yexo> so currently we have spritelayouts (=real action2's) which can't be moved around at all (but currently are), switch-blocks which depending on a design decision whether to use var 7F or action6 can or cannot be moved around, and action1's which can be duplicated/moved at will
20:36:16  <Hirundo> duplicating action1s means duplicating real sprites
20:36:26  <Yexo> yes, but that's sometimes the only option
20:36:44  <Hirundo> Perhaps, we should just do away with action1 for layouts entirely and resort to GRM
20:37:10  <Yexo> imagine spritelayouts A, B and C where B is a different feature from A and C. A and C both use the same realsprite. All of them use at least one param[x] as sprite so they can't be moved
20:37:29  <Yexo> C can't refer to the same action1 as A because B is in the middle, and you can't use a single action1 for multiple features
20:38:02  <Yexo> using GRM for everything is a bad idea
20:38:03  <Hirundo> currently that just throws an error, but we can fix that
20:38:10  <Hirundo> bad idea because?
20:38:23  <Yexo> there is a limit to the number of sprites that can be allocated via GRM
20:38:40  <Hirundo> also in OpenTTD or only in TTDP?
20:38:44  <Yexo> the limit is IIRC 65535-baseset  sprites for all grf's together
20:38:49  <Yexo> also in openttd
20:39:00  <Yexo> actually the limit might be 2**14
20:39:03  <Hirundo> are action1 sprites exempt from that limit?
20:39:05  <Yexo> yes
20:39:12  <Yexo> in OpenTTD, not in TTDPatch
20:40:05  <Yexo> spritelayouts refer to the sprite number with 14 bits, grm allocated sprite are global for all grfs, so there is a limit of 2**14 of those
20:40:48  <Yexo> internally openttd uses 32 bits to identify sprites
20:41:22  <Hirundo> 16k sprites...
20:41:57  <Hirundo> newgrf.cpp:5811 if (_cur_spriteid + count >= 16384) {
20:42:01  <Hirundo> indeed
20:42:52  <Hirundo> Alternatively, just dump all sprites in one action1
20:43:05  <Hirundo> And only allocate the action2s later as needed
20:43:17  <Hirundo> but that might break horribly when using more than one feature
20:43:19  <Yexo> each action1 can only use sprites for a single feature
20:45:50  <Brot6> NewGRF Meta Language - Revision 1350:0e8b479f5e99: Doc: using some industry variables trashes the... (yexo) @
20:47:06  <Hirundo> I have no clue on how to fix this in a nice way in all (edge) cases
20:48:54  <Brot6> FISH - Revision 645:554033be3851: Add: graphics for canal boat 1 (andythenorth) @
20:49:54  <Brot6> NewGRF Meta Language - Revision 1351:354bfd7221f5: Codechange: Split parse_sprite_set() into mult... (Hirundo) @
20:49:54  <Brot6> NewGRF Meta Language - Revision 1352:f1d27249f42b: Fix: Always call prepare_output for sprite sets. (Hirundo) @
20:53:47  <Brot6> FISH - Revision 646:e15fcdb73121: Cleanup: remove unneeded file (andythenorth) @
20:53:47  <Brot6> FISH - Revision 647:ebc42f0f0014: Change: work in progress on new utility vessel (andythenorth) @
20:53:47  <Brot6> FISH - Revision 648:7f4db9cca985: Change: work in progress on canal boat 1 (andythenorth) @
20:55:45  <Yexo> Hirundo:
20:57:33  <Hirundo> TTDP is 64k total, 16k for general (including GRM), right?
20:57:59  <Yexo> yes
20:59:45  <Hirundo> I think 3) should work, with the added comment that all GRM'ed sprites should go in one block (else we run out of params really fast)
21:00:04  <Yexo> I did think of that, just didn't write it down :)
21:00:07  <Yexo> so yes, indeed
21:03:49  <Brot6> NewGRF Meta Language - Bug #2649 (New): allocation sprites/spritelayouts (yexo) @
21:03:59  <Yexo> ^^ for reference of the problem
21:04:24  <Hirundo> 'adding parameters to values' has various problems of its own
21:04:56  <Hirundo> since the adding is done repeatedly for each activation, at least in TTDP
21:04:57  <Yexo> it might not be necesary, but it'll save a lot of actions
21:05:11  <Yexo> that can be worked around easily
21:05:32  <Yexo> see the example on this page:
21:05:38  <Yexo> which I've also implemented in CHIPS
21:06:54  <frosch123> just disable putting different features in one grf :) monolithic grfs are bad anyway :)
21:07:08  <Yexo> cargos + industries
21:07:23  <frosch123> do cargos have more than one icon sprite?
21:07:24  <Hirundo> airports + tiles
21:07:38  <Yexo> Hirundo: bad example, airports don't have real graphics (so no action1, hence no problem)
21:07:44  <Yexo> frosch123: no
21:07:53  <Hirundo> the airport icon in the build menu? or was that changed?
21:08:02  <Yexo> ah, indeed
21:08:14  <Yexo> it's only for the baseset that that's done via action5
21:08:24  <Hirundo> andy's HEQS contains a rail vehicle
21:08:27  <frosch123> anyway, i guess it is quite unlikely that different features use the same sprites, so those few can either be duplicated or use grm
21:08:35  <Hirundo> agreed
21:08:46  <Yexo> currently we require that the users duplicates those manually
21:09:00  <Yexo> which is imo fine, since the chance is so small that you want to reuse the same sprite for different features
21:09:14  <frosch123> <- wrt. adding offsets
21:09:31  <frosch123> should commit that in the next days, unless i find some big trouble
21:11:03  <Yexo> +		grfmsg(1, "ReadSpriteLayoutSprite: Spritelayout specifies var10 value for non-action-1 sprite"); <- so no variable baseset sprites?
21:11:32  <Hirundo> too long to read for me now
21:11:50  <frosch123> Yexo: "!(flags & TLF_SPRITE_REG_FLAGS)" <- if that is not the case, specifying an var10 value makes no sense
21:11:57  <Hirundo> I should get some sleep, goodnight folks
21:12:02  <Yexo> gn Hirundo
21:13:40  <Yexo> frosch123: allocate a bunch of sprites via GRM, pick one via varaction2->register instead of having to create 16 real action2's
21:13:57  <Yexo> no special var10 value required, no action1 sprite either
21:14:13  <frosch123> yes, should work as well
21:15:45  <Yexo> ah, I finally got it :)
21:24:05  *** andythenorth has left #openttdcoop.devzone
21:29:06  *** ODM has quit IRC
21:30:36  <Yexo> frosch123: it looks good :)
21:30:52  <Yexo> I'll try to create a test grf for it sometime soon
21:35:00  <frosch123> the wiki page is up to date
21:40:13  <frosch123> night
21:40:17  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk