Times are UTC Toggle Colours
01:01:39 <Brot6> DictatorAI - Revision 53:513bdcdd5e36: - Road stations balancing to push out loading vehicle if a... (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/513bdcdd5e36 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) - http://bundles.openttdcoop.org/serverpatches/releases/hcda7b96d 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: http://dev.openttdcoop.org/projects/openttd-mqs/activity.atom?key=367cb5251575ed9cb23c65f837f64685d3dee6db (in format: devzone) 11:54:31 <Brot6> Administration: http://dev.openttdcoop.org/projects/home/activity.atom?key=367cb5251575ed9cb23c65f837f64685d3dee6db (in format: devzone) 11:54:31 <Brot6> aidev: http://dev.openttdcoop.org/projects/aidev/activity.atom?key=367cb5251575ed9cb23c65f837f64685d3dee6db (in format: devzone) 11:54:31 <Brot6> admintools: http://dev.openttdcoop.org/projects/admintools/activity.atom?key=367cb5251575ed9cb23c65f837f64685d3dee6db (in format: devzone) 11:54:33 <Brot6> grftools: http://dev.openttdcoop.org/projects/grf-tools/activity.atom?key=367cb5251575ed9cb23c65f837f64685d3dee6db (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) @ http://dev.openttdcoop.org/issues/2337 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) @ http://dev.openttdcoop.org/issues/2338 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) @ http://dev.openttdcoop.org/issues/2339 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) @ http://dev.openttdcoop.org/issues/2339 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) @ http://dev.openttdcoop.org/issues/2339 16:13:50 <Brot6> GRFCodec - Bug #2339 (Rejected): Processing of Station Action0 Property 09 (Lakie) @ http://dev.openttdcoop.org/issues/2339#change-5991 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 - http://bundles.openttdcoop.org/firs/nightlies/r1802 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) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/7a8e8131b4e4 18:17:43 *** frosch123 has joined #openttdcoop.devzone 18:35:01 <frosch123> http://devs.openttd.org/~frosch/diffs/issue2339.diff <- 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) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r22094 19:07:01 <Brot6> clientpatches: update from r21488 to r21488 done - http://bundles.openttdcoop.org/clientpatches/testing/r21488 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 - http://bundles.openttdcoop.org/serverpatches/testing/r22094 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 http://dev.openttdcoop.org/issues/show/2338 "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 http://wiki.openttd.org/Frosch/Extended_Sprite_Layout 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) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/e68459e76a35 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) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/d90923fbc7fc 22:45:59 <Brot6> DictatorAI - Revision 56:452db8546b29: - Tags all files GNU (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/452db8546b29 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 - nml-win32-r1223.zip (yexo) @ http://dev.openttdcoop.org/attachments/download/1503/nml-win32-r1223.zip 23:57:32 <Ammler> Yexo: can we build that on the server ^ ?