Log for #openttdcoop.devzone on 18th February 2011:
Times are UTC Toggle Colours
01:01:39  <Brot6> DictatorAI - Revision 53:513bdcdd5e36: - Road stations balancing to push out loading vehicle if a... (krinn) @
01:17:42  *** KenjiE20 has quit IRC
01:30:58  *** thgergo has quit IRC
03:20:20  *** Lakie has quit IRC
07:34:00  *** andythenorth has joined #openttdcoop.devzone
07:35:18  *** andythenorth has quit IRC
07:41:07  *** andythenorth has joined #openttdcoop.devzone
07:45:46  *** andythenorth has quit IRC
08:29:22  *** ODM has joined #openttdcoop.devzone
09:17:42  *** andythenorth has joined #openttdcoop.devzone
09:19:07  *** andythenorth has quit IRC
09:34:04  *** DayDreamer has joined #openttdcoop.devzone
10:00:50  *** andythenorth has joined #openttdcoop.devzone
10:01:16  *** andythenorth has left #openttdcoop.devzone
11:00:59  *** _xabo has quit IRC
11:33:58  *** KenjiE20 has joined #openttdcoop.devzone
11:50:28  <Brot6> serverpatches: update from r20690 to hcda7b96d done (2 errors) -
11:50:53  <Ammler> hmm
11:54:12  <Ammler> !rss watch
11:54:20  <Ammler> Brot6: rss watch
11:54:20  <Brot6> Ammler: incorrect usage, ask for help using 'Brot6: help rss'
11:54:30  <Ammler> Brot6: rss watched
11:54:31  <Brot6> Ammler: Patches: (in format: devzone)
11:54:31  <Brot6> Administration: (in format: devzone)
11:54:31  <Brot6> aidev: (in format: devzone)
11:54:31  <Brot6> admintools: (in format: devzone)
11:54:33  <Brot6> grftools: (in format: devzone)...
11:55:00  <Ammler> mäh, key public now :-P
12:12:10  *** DayDreamer has quit IRC
12:17:53  *** DanMacK has joined #openttdcoop.devzone
12:23:15  <Ammler> Brot6: rss show patches
12:23:15  <Brot6> Ammler: lemme fetch it...
12:35:02  *** Lakie has joined #openttdcoop.devzone
13:25:20  <Brot6> OpenGFX+ Trains - Bug #2337 (New): Bulk wagons (V453000) @
13:29:59  <Ammler> Brot6: rss watch mqs
13:29:59  <Brot6> sure, Ammler
13:31:13  <Brot6> FIRS Industry Replacement Set - Bug #2338 (New): Unexpected production changes (V453000) @
13:49:27  *** ODM has quit IRC
13:54:24  * Lakie kicks renum
13:56:11  <Lakie> Seems it doesn't work with escapes in Action0 Stations property 09 properly
13:56:28  <Lakie> by not work, it completely comments the majority of the property out
14:09:51  <V453000> pm: some stuff to read here ^ :P
14:11:01  <planetmaker> :-)
14:15:40  <Lakie> 'tis only a minor inconvience, but surely it should work... :x
14:23:27  <Ammler> Lakie: try nforenum then ;-)
14:23:38  <Lakie> Well, that yes
14:23:43  <Lakie> 'tis 5.1
14:24:46  * Lakie shall try the latest nightly in case its been since fixed
14:25:19  <Lakie> Answer, not
14:27:08  * Lakie puts up a bug report.
14:39:59  * Lakie waits for flames... :/
14:40:04  <Brot6> GRFCodec - Bug #2339 (New): nforenum : station Actio0 property 09 (Lakie) @
14:40:24  <Lakie> Although I forgot the title should be changed as it affects both grfcodec and nforenum
14:42:22  <Ammler> Lakie: you are dev, you should have that permission
14:43:03  <Ammler> update -> change properities (more)
14:43:51  <Lakie> Oh, thanks
14:44:29  <Brot6> GRFCodec - Bug #2339 (New): Processing of Station Action0 Property 09 (Lakie) @
15:07:06  * Lakie sighs and tries to realign all the sprites. :(
15:10:30  <Ammler> I thought, you code with nml? :-P
15:11:06  <Lakie> Both. :)
15:11:36  <Lakie> This is already in nfo so I figured I'd just adjust values, turns out all the sprites need major realignment, cry
15:13:45  <Lakie> planetmaker: with the openttd sprite aligning tool, I don't suppose it could tell which sprite number in the grf file it is (unless I missed it somewhere? :) )?
15:17:28  <Ammler> yes, it does
15:17:41  <Ammler> well, sorry for answering, you didn't ask me
15:18:06  <Ammler> what you think is the number there?
15:20:52  <Lakie> I see 8,368?
15:21:10  <Lakie> Which is likely what it is in openttd, but its sprite 34 of the grf
15:21:27  <Ammler> he, you have multiple numbers there
15:21:55  <Ammler> 8368 looks quite high
15:22:11  <Ammler> baseset doesn't have so many sprites
15:22:38  <Lakie> I have a few grfs, so it'll be slightly higher?
15:23:19  <Ammler> it should not be the overall number, it should be the spritenumber of the grf
15:23:49  <Lakie> Doesn't appear that way, I'll try updating my trunk build tough
15:24:40  <Ammler> well, maybe I am wrong, I used it for opengfx only
15:25:27  <Lakie> Well, isn't opengfx the base set so it'll always line up?
15:29:46  <Ammler> Lakie: well, the numbers don't make sense, if they aren't the newgrf sprite numbers,
15:31:48  * Lakie is guessing they are the real numbers of where they are stored?
16:13:27  * Lakie sighs, old nfo is old...
16:13:50  <Brot6> GRFCodec - Bug #2339 (Rejected): Processing of Station Action0 Property 09 (Lakie) @
16:13:50  <Brot6> GRFCodec - Bug #2339 (Rejected): Processing of Station Action0 Property 09 (Lakie) @
16:23:11  <Lakie> On the bright side I see some stuff about the rpn system which I might test...
16:28:12  *** Lakie has quit IRC
16:31:16  *** Lakie has joined #openttdcoop.devzone
17:19:18  <Brot6> firs: update from r1801 to r1802 done -
17:19:33  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r743), 32bpp-extra (r39), ai-admiralai (r75), ai-aroai (r11), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r73), basecosts (r22), belarusiantowns (r8), bros (r51), comic-houses (r71), fish (r588), frenchtowns (r6), grfcodec (r821), heqs (r572), indonesiantowns (r41), manindu (r6), metrotrackset (r56), narvs
17:19:33  <Brot6> (r18), newgrf_makefile (r255), nml (r1223), nutracks (r176), ogfx-industries (r3), ogfx-landscape (r34), ogfx-rv (r78), ogfx-trains (r210), ogfx-trees (r42), opengfx (r610), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r45), spanishtowns (r10), swedishrails (r198), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r26), ttrs (r33), worldairlinersset (r671)
17:23:26  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus, belarusiantowns, frenchtowns, indonesiantowns (1 errors), manindu (Diffsize: 1), narvs, newgrf_makefile, ogfx-industries, ogfx-landscape (Diffsize: 6), ogfx-rv (1 errors) (Diffsize: 7), ogfx-trains (39 errors) (Diffsize: 7585), spanishtowns, swedishrails, swisstowns
18:10:49  <Brot6> DictatorAI - Revision 54:7a8e8131b4e4: - Add a flag to routes for route damage/health status (krinn) @
18:17:43  *** frosch123 has joined #openttdcoop.devzone
18:35:01  <frosch123> <- Lakie: does that solve the wrong warning?
18:35:41  * Lakie shall give it a go
18:35:55  <Lakie> I found renum's code too complex to workout how it all fits together.. :(
18:36:41  <frosch123> well, it is not a real fix, rather a hack to hide it
18:36:51  <Lakie> Hehe
18:40:26  <Lakie> Well, putting a //WARNING DISABLE 209 works for it too?
18:40:39  <Lakie> (in the nfo above the sprite(s)?
18:41:15  <frosch123> doesn't that disable the warning for all times?
18:41:39  <Lakie> Um, until it encounters a WARNING ENABLE 209, I think
18:41:49  <Lakie> I believe FIRS has a few cases where it does such
18:49:39  <Lakie> Could have been ECS though
18:51:00  <frosch123> yes, george complained several times about that warning
18:51:32  <frosch123> he usually encodes sprites as two words to separate the sprite from the recolouring
18:51:50  <Lakie> Makes sense
18:58:31  <Lakie> Though not quite the same as a dword being classed as too big to fit in a dword...
19:04:09  <Brot6> 32bpp-ez-patches: update from r22090 to r22094 done (2 errors) -
19:07:01  <Brot6> clientpatches: update from r21488 to r21488 done -
19:07:17  <frosch123> Lakie: the problem is the special case 00 00 00 00 for using the original sprite layouit.
19:07:26  <frosch123> renum expects 4 bytes for that
19:08:21  <frosch123> maybe a better fix would be to extent the data format to specify a length for "RAW()"-stuff
19:08:53  <frosch123> though the real fix would be to only warn after renum has decided which "|"-alternative matches
19:10:52  <Brot6> serverpatches: update from r21649 to r22094 done -
19:12:24  <Lakie>  Well, isn't that \d0?
19:12:39  <Lakie> Similar to how you can drop the building or ground sprite on action2layouits?
19:13:41  <frosch123> renum checks for \b0 \b0 \b0 \b0, i.e. for bytes. so a dword does not fit the "alignment"
19:14:45  <Lakie> Ah right, why doesn't it check it similar to how it would on action2layouts for ground sprite?
19:15:30  <frosch123> it does not any test for action2layout groundsprites, does it?
19:19:42  <Lakie> I dunno, one presumes it should error if there is no ground sprite with the extended format
19:28:26  <Lakie> basic format, sorry
19:28:32  <Lakie> Error 84
20:01:43  *** andythenorth has joined #openttdcoop.devzone
20:32:32  *** thgergo has joined #openttdcoop.devzone
21:11:35  <andythenorth> #2338
21:11:36  <Brot6> andythenorth: #2338 is "FIRS Industry Replacement Set - Bug #2338: Unexpected production changes - #openttdcoop Development Zone"
21:11:37  <andythenorth> brrr
21:11:43  <andythenorth> ^ this is why parameters are bad :(
21:15:31  <planetmaker> g'evening
21:15:33  <planetmaker> Lakie: no, you don't see the grf-internal sprite number. Only for the base grf
21:15:36  <planetmaker> if you only have one grf and you look up the other base sprites, you might possibly infer it - but much work
21:19:56  *** Lakie has quit IRC
21:20:18  *** Lakie has joined #openttdcoop.devzone
21:37:40  *** thgergo has quit IRC
21:49:59  <Lakie> So its not really practical to do then planetmaker?
21:51:25  <planetmaker> I never tried to ge the in-grf sprite number for anything but the base grf. As sprites are comewhat consecutively numbered... it's short of impossible really for more than one newgrf and not fun for newgrf even if it's only one.
21:51:41  <planetmaker> But... don't you know where you encoded a certain sprite?
21:52:00  <Lakie> Well, I do after having to hunt through the sprite sheet. :)
21:52:35  <planetmaker> or asked differently: what problem do you try to solve where it'd be needed?
21:53:01  <planetmaker> Hm... well, yes. Though you usually know that it is a sprite from... industry A - and then know where to look. Or house B. Or vehicle type C etc
21:53:11  <planetmaker> unless you only have a de-compiled grf. Then it sucks
21:53:16  <planetmaker> But then that sucks anyway.
21:53:30  <Lakie> Yeah, but when industry A has a large number of sprites it becomes more unmanagable...
21:53:47  <planetmaker> hm... how many would an industry have?
21:54:00  <planetmaker> 50?
21:54:07  <Lakie> Unsure, probably not a huge number due to it being industry tiles?
21:54:26  <Lakie> ie. it should be possible to get lower, stations is more fun for me...
21:54:42  <planetmaker> nah... Number of tiles * 2 or *3 I'd expect. With construction maybe *4 or *5
21:54:56  <planetmaker> and that's the upper boundary
21:55:06  <planetmaker> tiles could be (re-)used by other industries
21:55:12  <Lakie> True
21:56:47  <Lakie> Ah well, its not a major thing.
21:57:59  <planetmaker> I understand fully: would be nice :-)
22:00:26  * Lakie wonders how many sprites he's going to have to realign for this 'update' of the glass station
22:01:16  * Lakie thinks ~42 for the major sprite block...
22:01:44  <Lakie> Its hard to know if objects are easier or worse than stations...
22:02:49  <Yexo> frosch123: there is probably no chance to get your extended sprite layout also for stations?
22:03:21  <frosch123> not planned so far
22:03:32  <frosch123> stations work very different, no idea what would be the impact
22:04:25  <frosch123> stations already have something similiar, but only for the groundsprite
22:04:32  <frosch123> and it needs an addtional sprite resolving
22:05:18  <Yexo> and they probably need it less often since sloped stations are impossible anyway
22:05:41  <Lakie> Aye
22:05:58  <Lakie> Ah, you mean using registers as the sprite values?
22:06:11  <Yexo> yes, see if you haven't already
22:06:20  <Lakie> Or something different, I vaguely remember something on the forums
22:06:35  <Yexo> it's from yesterday
22:06:49  <Yexo> or at least, that's when the wiki page was created / discussed
22:07:01  <Lakie> Hehe
22:07:05  <frosch123> all is from yesterday
22:07:15  <frosch123> written before sports, published after sports :p
22:14:07  <Lakie> Sounds messy in the changes needed.
22:16:11  <frosch123> most tricky might be that the registers might be changed by other callbacks called after resolving the spritegroup and before actual drawing
22:16:46  <frosch123> i am not sure whether i can move the callbacks, esp. when drawing water-class-specific ground.
22:17:15  <Yexo> I think you'll have to resolve the registers at the time of resolving rather than when drawing
22:17:16  <andythenorth> frosch123: is there a pathological case?
22:17:22  <frosch123> so i'll more likely try to evaluate the register values just after the resolving the spriteset, far before actual drawing
22:17:41  <andythenorth> they only check register values, not in any way a varaction 2 id?
22:18:19  <frosch123> andythenorth: but spritesets can trigger a canal-groundsprite to be drawn, which resolves a canal action123 chain
22:18:26  <Lakie> I'm unsure, I don't think I'd be able to stop a callback between fetching and drawing
22:18:32  <frosch123> so you have to evaluate the registers before using them for the canal
22:18:50  <andythenorth> frosch123: I was just wondering if there was a potential for self-referencing loop
22:18:57  <frosch123> and the canal needs to be drawn before drawing the spritelayout as groundsprites need to be drawn in order
22:18:57  <andythenorth> I guess you already prevented that
22:19:51  <frosch123> Lakie: the callback does not draw itself
22:20:09  <Lakie> Aye
22:20:19  <frosch123> for ttdp i would try to allocate the spritelayout in the usual format, and just put the register values in it before drawing
22:20:26  <Lakie> But, I know houses does, fetch graphics, do various cbs, draw
22:20:45  <frosch123> though afaik houses/industries/object-tile-drawing is 100% patch code anyway
22:20:51  <frosch123> (while station drawing is ttd code)
22:21:07  <Lakie> The drawing is yeah
22:21:17  <frosch123> which is also why station drawing is so cumbersome :p
22:21:37  <Lakie> Hehe
22:22:33  <Lakie> I'm just going to throw a small spanner in, whilst it'd likely end up drawing bad stuff, couldn't x or y offsets be 0x80 or above?
22:22:48  <Yexo> x and y offsets are signed
22:23:03  <Yexo> so 0x80 is -127, which theoretically can happen but it's very unlikely
22:23:07  <Yexo> -128 even
22:23:39  <Lakie> I know, but it is possible (despite likely doing nothing practical as it'd get clipped drawing drawing).
22:24:36  <frosch123> ttd uses 0x80 for xpos to terminate lists
22:24:46  <frosch123> so at least for stations it would break stuff
22:24:50  <Lakie> For stations it does
22:25:09  <frosch123> but yes, xpos = 0x80 has no use at all :)
22:25:47  <frosch123> i would consider values -16..32 to make sense in some cases
22:26:19  <Lakie> yeah
22:26:29  <Lakie> With 0x10, you say add both x and y?
22:26:55  <Lakie> I assume it expects 2 bytes in the reigster, but only 1 for the x pos manip?
22:27:07  <frosch123> yes, 0x10 requires two registers
22:27:32  <frosch123> do you think we should better start with 16 flags?
22:27:47  <frosch123> instead of merging bits which are likely used together anyway?
22:28:03  <Lakie> I dunno
22:28:22  <Lakie> Depends on how messy it'll make the implementation and various speed impacts
22:28:49  * Lakie has no idea how to do 8
22:29:07  <frosch123> the same as bit 31 of the usual sprite?
22:29:27  <Lakie> For a recolour map?
22:29:49  * Lakie knows not how they are handled.
22:29:55  <frosch123> there is no difference between a real sprite and  a recolour sprite at that scope, is there?
22:30:21  <Lakie> I dunno, I'd have to ask Oskar
22:30:23  *** DanMacK has quit IRC
22:30:33  <frosch123> i would expect ttdp to resolve those bits at activation stage, i.e. not during drawing
22:30:56  <Brot6> FISH - Revision 589:e68459e76a35: Change: corrected a few log raft offsets (work in progress) (andythenorth) @
22:30:56  <Lakie> Well, its resolved just before calling addgroundsprite etc
22:31:18  <frosch123> basically it needs to add the number of the first sprite of the spriteset from the last action1
22:31:38  <frosch123> [23:30] <Lakie> Well, its resolved just before calling addgroundsprite etc <- really?
22:31:58  <frosch123> i am surprised you know the numbers of action1 sprites at that point
22:32:11  <Lakie> I looks them up iirc
22:32:26  <frosch123> but maybe it is due to ttdp's magic paging of sprites from different grfs
22:32:54  <Lakie> I couldn't tell you off hand. :(
22:33:37  <Lakie> I think its given a index based off 'bucket'
22:33:54  <Lakie> But Oskar knows more since he designed the current system
22:34:12  <frosch123> yeah, that's what i mean with "paging". it maps a certain range of spritenumbers to the active grf
22:34:41  <Lakie> Thats the system he's currently working on yes,
22:34:54  <frosch123> that part is a lot easier for ottd, it just uses 28 bits for sprites instead of 14 :p
22:35:02  <Lakie> Heh
22:35:22  <Lakie> Well, Oskar plans to allow the full 14 bits to be used for the grf
22:35:26  <frosch123> took peter quite some time nevertheless iirc
22:35:46  <Lakie> Don't ask me how though, way beyond my understanding...
22:37:41  <Lakie> Ah well, I'll ask Oskar about it all to see if its possible
22:37:57  <Lakie> I presume the recolour sprites is for like mb's custom recolouring?
22:38:28  <frosch123> if you want to use custom recolour stuff currently, you have to reserve sprites via grm
22:38:56  <Yexo> or (like mb) just overwrite some toyland sprites, which will fail as soon as 2 grfs overwrite the same sprites
22:39:07  <frosch123> using action1 is a lot easier if you have some special recolourings for a limited scope of sprites
22:39:50  <frosch123> if you want to use them throughout the whole file, you will likely still use grm
22:40:20  <frosch123> that bit was only added, because it was missed several times in the past, and now there was some space to put it in :p
22:40:38  <frosch123> it has nothing todo with the actual register stuff
22:40:45  <Lakie> Heh
22:41:01  <Lakie> In which case it likely means reworking internals...
22:41:23  <frosch123> i would consider that bit easier than the register stuff
22:41:53  <Lakie> Possibly
22:42:04  <Lakie> I don't know how much of these internals are patched or how
22:42:59  *** andythenorth has left #openttdcoop.devzone
22:43:13  <Lakie> So only Oskar would be able to say how fessible it is
22:45:59  <Brot6> DictatorAI - Revision 55:d90923fbc7fc: - Fix the blacklist function (krinn) @
22:45:59  <Brot6> DictatorAI - Revision 56:452db8546b29: - Tags all files GNU (krinn) @
23:10:24  <Lakie> Ah well, night
23:14:23  *** Lakie has quit IRC
23:24:36  *** frosch123 has quit IRC
23:29:09  <Brot6> NewGRF Meta Language - (yexo) @
23:57:32  <Ammler> Yexo: can we build that on the server ^ ?

Powered by YARRSTE version: svn-trunk