Times are UTC Toggle Colours
00:05:01 <Yexo> not sure again, I tried a few days ago 00:05:04 <Yexo> will try again tomorrow 00:05:22 * Yexo is gone for the rest of the evening/night 01:17:28 *** KenjiE20 has quit IRC 01:29:18 *** Lakie has quit IRC 01:43:31 *** thgergo has quit IRC 01:49:57 <Brot6> OpenGFX - Feature #885: Toyland House and Industry Ground tile (2006TTD) @ http://dev.openttdcoop.org/issues/885#change-5909 05:33:09 <Brot6> Bundles Update: g24b8cc44 2011-02-13 cargodist (http://bundles.openttdcoop.org/cargodist) 06:37:14 *** andythenorth has joined #openttdcoop.devzone 06:37:39 *** andythenorth has joined #openttdcoop.devzone 06:42:16 <Brot6> FIRS Industry Replacement Set - Feature #2318 (New): Parameter to prevent industry opening during... (andythenorth) @ http://dev.openttdcoop.org/issues/2318 06:56:41 <Brot6> FIRS Industry Replacement Set - Revision 1794:8ac726912e18: Fix: missing cargo amount string for ... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/8ac726912e18 07:03:49 <andythenorth> DJNekkid: you here? Or just bouncing? 07:08:16 <Brot6> FIRS Industry Replacement Set - Feature #2318: Parameter to prevent industry opening during game (planetmaker) @ http://dev.openttdcoop.org/issues/2318#change-5910 07:13:56 <Brot6> FIRS Industry Replacement Set - Feature #2318: Parameter to prevent industry opening during game (andythenorth) @ http://dev.openttdcoop.org/issues/2318#change-5911 07:16:46 <Brot6> FIRS Industry Replacement Set - Feature #2318: Parameter to prevent industry opening during game (planetmaker) @ http://dev.openttdcoop.org/issues/2318#change-5912 07:17:07 <andythenorth> planetmaker: 'open' isn't finished yet ;) 07:17:15 <planetmaker> ok :-) 07:17:29 <andythenorth> I might look at it soon 07:17:36 <andythenorth> also...I wanted to refactor more cargo strings 07:17:49 <andythenorth> but I don't want to cause more translation headaches 07:17:58 <planetmaker> don't worry about translations 07:18:12 <planetmaker> refactor strings which need to be refactored 07:18:42 <planetmaker> The only time where you don't want to do that is between 0.9 and 1.0 07:19:03 <planetmaker> or x.9 and (x+1).0 07:19:46 <planetmaker> if you want, you could also not refactor them between 0.x.y and 0.x.(y+1) - but then you'd need to branch 07:19:53 <planetmaker> not sure it's worth it 07:19:56 <andythenorth> I should just not do that then :) 07:33:36 <Brot6> FIRS Industry Replacement Set - Revision 1795:4555be3c8af8: Change: (translations) refactor strin... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/4555be3c8af8 07:33:44 <andythenorth> planetmaker: I can't figure this one out: http://dev.openttdcoop.org/issues/2088 07:33:49 <andythenorth> at least, for plantation 07:37:01 <andythenorth> maybe I just try setting prop 1A to 0 07:37:05 <andythenorth> currently it's unset 07:37:13 <planetmaker> use a proper substitute / override type ;-) 07:37:37 <andythenorth> nah 07:37:43 <planetmaker> honestly, yes 07:38:27 <andythenorth> actually, why are we using 00 for INDUSTRY_NULL in prop 08? 07:38:29 <andythenorth> it should be FF 07:38:38 <planetmaker> and setting explicitly the prop 1A helps, too 07:39:07 <andythenorth> I think many FIRS industries are setup wrong 07:39:22 <planetmaker> :-) 07:40:53 <planetmaker> hm, what about flag 0x02 for the sawmill? ;-) 07:42:10 <andythenorth> it is requested every now and then, and I ignore it :) 07:42:11 <Brot6> FIRS Industry Replacement Set - Bug #2319 (New): INDUSTRY_NULL value for prop 08 incorrect (andythenorth) @ http://dev.openttdcoop.org/issues/2319 07:43:17 <Brot6> FIRS Industry Replacement Set - Bug #2319 (New): INDUSTRY_NULL value for prop 08 incorrect (andythenorth) @ http://dev.openttdcoop.org/issues/2319 07:44:22 <Brot6> FIRS Industry Replacement Set - Revision 1796:6c1318745787: Fix: (untested) reported that Plantat... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/6c1318745787 07:45:23 <Brot6> FIRS Industry Replacement Set - Revision 1797:fc9185755b1d: Fix: (untested) reported that Oil Wel... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/fc9185755b1d 07:45:46 <planetmaker> hehe 07:46:21 <Brot6> FIRS Industry Replacement Set - Bug #2088 (Feedback): Oil wells and plantations cause subsidence ... (andythenorth) @ http://dev.openttdcoop.org/issues/2088#change-5913 07:53:27 <Brot6> DictatorAI - Revision 21:307510b476ca: - Some cleanup for release (soon) (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/307510b476ca 07:53:27 <Brot6> DictatorAI - Revision 22:d1179eaec1cc: - Separate road pathfinding & road construction, so we cou... (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/d1179eaec1cc 07:53:27 <Brot6> DictatorAI - Revision 23:7accbde76f18: - More road vehicle build after route creating (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/7accbde76f18 07:55:53 <Brot6> FIRS Industry Replacement Set - Revision 1798:df2e550198d6: Fix: [Makefile] Rebuild when needed. ... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/df2e550198d6 07:56:15 <andythenorth> nearly r1800 :) 08:00:23 <planetmaker> I think I understood now the fence magic :-) 08:00:37 <Brot6> FISH - Revision 570:f6119125a87f: Change: work in progress on graphics for Klyazma hydrofoil (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/f6119125a87f 08:00:48 <andythenorth> planetmaker: I don't :D 08:00:52 <andythenorth> I do understand pixels :P 08:00:54 <planetmaker> it's easy :-P 08:01:33 <andythenorth> care to explain the general approach? 08:01:42 <Brot6> FISH - Revision 571:a6048d97b4c1: Change: work in progress on graphics for 818 hydrofoil (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/a6048d97b4c1 08:02:07 <planetmaker> :-) 08:05:11 <planetmaker> I can try 08:05:27 <planetmaker> basically you define for each tile what fences it may use in principle 08:05:46 <planetmaker> and then you just use the fence template to have it generate all needed action2s 08:06:06 <planetmaker> it receives the other building sprites for that action2 as a sort-of parameter 08:06:29 <planetmaker> *the other part of that action2 with the other building sprite references 08:06:33 <planetmaker> to be more exact 08:07:49 <andythenorth> so it's like inserting a block of code into a fence template? 08:08:41 <planetmaker> somewhat, yes. The template-magic automatically determines the number of choices which need to be generated in that action2 08:08:51 <planetmaker> so you don't have to bother with the possible options 08:10:05 <planetmaker> http://paste.openttdcoop.org/show/107/ 08:10:46 <planetmaker> ^ that's how then the ...tiles_layout.pnfo looks like for the building sprites 08:11:16 <planetmaker> each current setID for a tile is modified to look like that 08:11:55 <planetmaker> define setID. define (normal) building sprite part. Define possible fences. include fences template 08:11:58 <planetmaker> repeat for each setID 08:13:20 <planetmaker> the templates then work this way: 08:13:47 <planetmaker> they call a fence proc to see what needs drawing. And that is then branched to the differently fenced action2s 08:15:08 <planetmaker> the possible action2s were defined by the fences you defined. Each fence is guarded ifdef... 08:19:10 <andythenorth> ok that much makes sense then 08:19:45 <planetmaker> FENCE_SW basically means to draw a fence, if only the SW tile is a non-industry tile 08:20:08 <andythenorth> so it also takes care of neighbouring tile checks already? 08:20:10 <andythenorth> I missed that 08:21:12 <planetmaker> what does not seem to work is to only draw a fence in the SE direction when the SE and SW direction are non-industry tiles. Or I didn't quite figure it out yet 08:21:49 <andythenorth> I can't figure why the building sprite is drawn over the fence in one case for cement plant 08:22:03 <andythenorth> it should be due simply to order of sprites 08:22:10 <andythenorth> maybe it is :P 08:22:21 <andythenorth> CPP can't do basic maths can it? 08:25:20 <planetmaker> it can't do that, right 08:26:25 * andythenorth wonders if an external script could 08:27:11 <planetmaker> yes. But that'd mean to implant a separate language on top 08:27:42 <planetmaker> in a way Yexo implemented some simple adding algorith to it which can add +1 up to a value of 15 08:27:56 <planetmaker> see count.pnfo 08:28:45 <andythenorth> oops, I was thinking in connection to a FISH problem :) 08:28:50 <andythenorth> but I forgot to mention that 08:29:02 <andythenorth> I'll just do it explicitly with defines 08:29:16 <planetmaker> what do you need? 08:31:15 <andythenorth> I have hydrofoils which lift above water to a height depending on speed 08:31:28 <andythenorth> changing the offsets in the source graphics is a maintenance headache 08:31:38 <andythenorth> and I have templated the action 1s to death :P 08:31:46 <andythenorth> but it's fine, I just create more defines 08:32:10 <andythenorth> I wondered about doing maths on the y offset for action 1 08:32:18 <andythenorth> but defines are more robust and less work :) 08:32:44 <planetmaker> math on offsets is not really possible 08:32:53 <andythenorth> indeed 08:33:02 <andythenorth> unless it was scripted with python or something 08:33:04 <planetmaker> and the reason why I introduced nml to opengfx. Because I can do that there ;-) 08:34:00 <planetmaker> that's probably the one thing I miss most in nfo 08:34:44 <andythenorth> 'magic' :P 08:34:46 <planetmaker> one could probably write a small python script which replaces a special character sequence by the result of the enclosed math operation, though 08:34:47 <andythenorth> heh 08:35:05 <andythenorth> ach, it's often safer and easier just to write it out long hand 08:35:17 <andythenorth> trying to figure out what some helper is doing is less explicity 08:36:37 <planetmaker> well... yes 08:37:28 <planetmaker> but like realsprite(filename, x,y, width, height, xoffset, yoffset) with the 6 numeric parameters being a readable formula is not difficult ;-) 08:37:38 <andythenorth> indeed 08:37:38 <planetmaker> and makes it easy 08:37:53 <andythenorth> -1 sprites/graphics/THIS_PCX_FILE 20 10 01 THIS_Y_X_CROP_1 THIS_SPEED_0_OFFS_X_Y_1 08:37:58 <andythenorth> is what I have already 08:38:08 <andythenorth> anyway, this problem is considered solved :) 08:38:12 <planetmaker> and as good as it gets without further pre-processing :-) 08:39:10 <planetmaker> so basically what the fence routine now does is: 08:40:26 <planetmaker> "draw fences around all open sides, if (definable) sides are free" 08:40:48 <andythenorth> makes sense 08:41:15 <planetmaker> it also would make sense to have "draw fences on (selected) sides if they are free" 08:42:14 <andythenorth> that would actually make more sense 08:42:42 <andythenorth> my main concern is actually about writing and maintaining action 2s 08:42:54 <planetmaker> well, that is solved nicely :-) 08:43:01 <andythenorth> because they're generated, adding new industry, and debugging could be harder 08:43:07 <andythenorth> or maybe I just haven't grokked it yet 08:43:11 <planetmaker> I wonder if the condition can be changed 08:43:33 <andythenorth> I also worry about what happens if anyone ever needs to take over the set...the more complex it is, the more likely to die 08:43:37 <planetmaker> the action2 sequence in (pre-processed) nfo is rather length and not well readable 08:43:52 <andythenorth> maybe it's just a question of formatting etc 08:44:18 <planetmaker> the cpp pre-processor kind of writes it in chunks... : 08:44:59 <planetmaker> http://paste.openttdcoop.org/show/108/ 08:46:44 <planetmaker> hm, this recent makefile fix was urgently needed... 08:47:32 <planetmaker> so much more convenient if I can just call 'make install' ;-) 08:49:15 <andythenorth> hmm 08:49:26 <andythenorth> I have grown attached to 'make clean && make install' 08:49:33 <andythenorth> and the extra delay is....thinking time :P 08:50:48 <planetmaker> is the fences diff somewhere attached to a ticket? 08:53:02 <andythenorth> no 08:53:18 <planetmaker> well, I'll create one 08:53:26 <planetmaker> and toy around with it a bit more 08:53:33 <andythenorth> thanks 08:53:46 <andythenorth> at the moment I wouldn't ship it because I don't understand it 08:53:47 <planetmaker> maybe I'll get it to "draw fence in that direction when free" 08:53:49 <andythenorth> and that's a bad pattern :) 08:53:53 <planetmaker> yeah 08:53:57 <planetmaker> I'd ship it :-P 08:54:23 <andythenorth> he 08:54:24 <planetmaker> But it took me well an hour to completely follow it in all parts ;-) 09:00:14 <Brot6> FIRS Industry Replacement Set - Feature #2320 (New): Fences for industries (planetmaker) @ http://dev.openttdcoop.org/issues/2320 09:24:31 <Brot6> FISH - Revision 572:460474019404: Change: work in progress on Hydrofoils - now correctly shows el... (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/460474019404 09:25:07 <Brot6> FISH - Revision 573:ba1b3490363d: Add: source file for cars (to use in Ferries) - cars by colossa... (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/ba1b3490363d 10:30:10 <Yexo> planetmaker: disabling fences in a single direction can't be done indeed with the current patch 10:32:18 <planetmaker> Yexo: rather enabling them is what I'd fancy (when the adjacent tile is free) - but, yes, I think it can be modified to fit that, too :-) 10:32:29 <planetmaker> by the same method 10:33:04 <Yexo> is there a difference? explicitly enabling fences or explicitly disabling them results in the same ;) 10:33:15 <planetmaker> :-) quite true 10:33:58 <planetmaker> however I fancy the way you wrote that patch a lot :-) 10:34:22 <Yexo> I think explicitly enabling fences an be done by masking the result of the procedure call 10:34:39 <Yexo> did anyone make any changes or is the version I upload still the last version? 10:35:41 <planetmaker> I added yours and mine to the ticket. But mine is not really different except a comment on the FENCES_XYZ defines and applying it to the furniture factory (which I did only to follow how it works) 10:36:18 <planetmaker> so yes, yours is the last version 10:40:16 <Yexo> http://devs.openttd.org/~yexo/firs_fences.diff Added a define to enable fences in some directions. Search for ENABLED_FENCES to see the changes 10:44:35 <Brot6> FISH - Revision 574:efe5bfef5dd4: Feature: 818 Hydrofoil with complete set of speed-sensitive spr... (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/efe5bfef5dd4 10:45:02 <Brot6> FISH - Bug #2321 (New): Broken down hydrofoil doesn't use 'not moving' graphics (andythenorth) @ http://dev.openttdcoop.org/issues/2321 10:47:35 <planetmaker> so... ENABLED_FENCES_XYZ would just need a few more defined constants and each industry tile would then not only define FENCES but also - if desired ENABLED_FENCES? 10:49:54 <Yexo> I'm reworking it slightly now 10:57:55 <Yexo> updated diff 10:58:44 <Yexo> I changed the tile with ID 06 to never print a fence at the SW border 10:58:57 <planetmaker> of the cement plant? 10:59:01 <Yexo> yes 10:59:36 <Yexo> you probably didn't want to change that one, but it serves as an example of how to do it 11:00:28 <planetmaker> indeed, the actual assignment of what fence goes where and when is quite secondary :-) 11:08:21 <Yexo> andythenorth: if you let me know which parts of the diff you don't understand I can try to explain those 11:09:13 <andythenorth> ok 11:09:21 <andythenorth> I should probably try and apply it to a new industry 11:09:27 <andythenorth> then I'll figure it out 11:09:30 <andythenorth> "learn by doing" 11:09:31 <planetmaker> yep. That helped me :-) 11:10:05 <andythenorth> I'm doing some FISHing at the moment 11:10:09 <andythenorth> but that will be done soon 11:11:55 <Yexo> http://pastebin.com/GkpVkdBw example of how to convert a single tile 11:14:59 <planetmaker> that doesn't include the ENABLE_FENCES :-) 11:15:39 <planetmaker> hm... given that FENCES... adds fences everywhere - shouldn't the optional "parameter" be DISABLE_FENCES? 11:15:45 <planetmaker> instead of ENABLE_FENCES? 11:15:55 <planetmaker> or did I not quite follow what you added? 11:16:29 <Yexo> that is what I proposed, but you wanted "enable_fences" instead of "disable_fences" 11:16:58 <Yexo> fortunately it's easy to change :) 11:17:12 <planetmaker> :-) I thought of it as replacing the FENCES 11:17:27 <Yexo> I'm not sure how that could work 11:17:33 <Brot6> FISH - Revision 575:099ef8f4234e: Feature: Klyazma Hydrofoil with complete set of speed-sensitive... (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/099ef8f4234e 11:17:47 <Yexo> or did you want to hardcode which fences are enabled? 11:17:48 <planetmaker> I didn't quite dwell on how to change it - so I might be quite wrong there 11:18:08 <planetmaker> but my idea was to tell each tile "you may draw a fence in the SE (if there's free)" 11:18:20 <planetmaker> "you may draw a fence in the NW (if there's free)" etc 11:18:55 <Yexo> that is what "enable_fences" currently does 11:19:05 <Yexo> "fences" is just there to limit the total amount of action2's 11:19:10 <Brot6> FISH - Revision 576:450c85e45953: Change: cleanup PSD file a bit for 818 Hydrofoil (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/450c85e45953 11:19:35 <Yexo> #define FENCES 0x3FFF <- you could just use that for every tile and it'd still work 11:19:58 <Yexo> so you could add that to tile_fences.pnfo as default and never define it 11:20:23 <Yexo> but that would result in 15 action2's for every tile, instead of only X action2's, where X = the number of different layouts needed 11:20:38 <Yexo> max(X) = 15, avg(X) = 3 or 4 11:21:17 <planetmaker> but now I have to enable all possible fences for all possible combinations of free adjacent tiles - and then disable drawing the fence in a certain direction when I want a 3-sided fenced tile 11:21:36 <planetmaker> possibly 3-sided fenced tile 11:21:46 <planetmaker> like a building whose door shall not be fenced 11:21:59 <planetmaker> but which could be anywhere in the layout 11:22:06 <Yexo> so for example fences on all free sides except the SE? 11:22:25 <planetmaker> yeah 11:23:04 <planetmaker> the syntax I'd prefer would be to call FENCES_NE | FENCES_SW | FENCES_NW and that's it 11:23:22 <planetmaker> and that's what I initially meant with enable fences :-) 11:23:49 <Yexo> #define FENCES FENCES_NE + FENCES_SW + FENCES_NE_SW + FENCES_SE_SW + FENCES_NW + FENCES_NE_NW + FENCES_SW_NW + FENCES_NE_SW_NW 11:23:49 <Yexo> #define ENABLED_FENCES ENABLED_FENCES_NE + ENABLED_FENCES_SW + ENABLED_FENCES_NW 11:24:21 <Yexo> alternatively #define FENCES 0x3FFF 11:24:21 <Yexo> #define ENABLED_FENCES ENABLED_FENCES_NE + ENABLED_FENCES_SW + ENABLED_FENCES_NW 11:24:45 <planetmaker> hm... what happens when I don't define ENABLED_FENCES with the current diff? 11:25:04 <Yexo> it defaults to 0x0F, which is enable all directions 11:25:40 <Yexo> planetmaker: I understand what you want, but that will result in a huge amount of action2's that are never used 11:26:05 <planetmaker> :-) - also true if the default is FENCES 0x3FFF ? 11:26:18 <Yexo> the building with a door at the SE of the above example. Say that tile always has another industry tile to the SW of it, than you can leave out all constants with SW from FENCES 11:27:10 <Yexo> planetmaker: yes, FENCES doesn't currently have a default value, but if it would be 0x3FFF than you wouldn't need to define either FENCES or ENABLED_FENCES for any tiles to have fences on all possible sides 11:27:17 <Yexo> just with the drawback of a lot of useless action2's 11:27:36 <planetmaker> ok. Then this is the better solution :-) 11:28:45 <Brot6> FISH - Feature #1144 (Closed): Hydrofoil (kometa) (andythenorth) @ http://dev.openttdcoop.org/issues/1144#change-5915 11:28:57 <planetmaker> Then my only issue is the naming which is difficult... FENCES -> draw fences if free and ENABLE_FENCES -> draw only these 11:29:11 <Yexo> I fully agree with that ;) 11:29:14 <planetmaker> no idea how to call that properly and concise :-) 11:29:24 * andythenorth does ponder 11:29:25 <Brot6> FISH - Feature #2226 (Closed): Hydrofoil 818 (andythenorth) @ http://dev.openttdcoop.org/issues/2226#change-5916 11:32:23 <planetmaker> however the naming - thanks for your nice fences patch, Yexo :-) 11:32:36 <andythenorth> indeed 11:34:07 <Yexo> it'd be a lot easier if nfo allowed computing of values, but it was a nice challenge to write it 11:34:21 <planetmaker> :-) 11:35:43 <Brot6> FISH - Feature #2064 (Closed): Does Log Raft handle Tropic Wood? (andythenorth) @ http://dev.openttdcoop.org/issues/2064#change-5917 11:43:47 *** yorick has joined #openttdcoop.devzone 11:46:25 *** KenjiE20 has joined #openttdcoop.devzone 12:10:19 *** thgergo has joined #openttdcoop.devzone 12:52:23 <Brot6> FISH - Revision 577:30cc8f6cbf9d: Feature: Fiumelatte Paddle Steamer (medium size) (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/30cc8f6cbf9d 12:52:33 <planetmaker> fish fish fish :-) 12:53:16 <planetmaker> it's a bit sad that ships are so easily abused by newbies 12:53:27 <andythenorth> how? 12:54:08 <planetmaker> ships without buoys kill the game easily in sense of unplayable due to cpu 12:54:27 <planetmaker> look at the savegame e.g. from RAMMAR from the title game competition. It's aweful 12:54:37 <andythenorth> it is a downside 12:54:53 <andythenorth> I've seen ship pathfinder discussed n times :| 12:54:58 <andythenorth> but never a solution 12:55:06 <andythenorth> I use bouys 12:55:23 <andythenorth> didn't the default game have a hard-coded limit on tile distance to next bouy? 12:55:56 <Hirundo> yes 13:09:11 <Brot6> FISH - Revision 578:1d6fc3560ba7: Change: reduce loading speeds for Hydrofoils (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/1d6fc3560ba7 13:10:10 <Brot6> FISH - Feature #1142 (Closed): Medium Paddle Steamer (andythenorth) @ http://dev.openttdcoop.org/issues/1142#change-5918 13:11:47 <Brot6> HEQS "Heavy Equipment" Set - Feature #2322 (New): Adjust tram weights by refit (andythenorth) @ http://dev.openttdcoop.org/issues/2322 13:36:19 <yorick> andythenorth: some guy made a region-based yapf for ships, but he stopped development 14:05:26 <andythenorth> planetmaker: can't bouys just be enforced more strictly? 14:05:41 <planetmaker> not sure... 14:05:47 <planetmaker> rather a better PF, I think 14:05:51 <andythenorth> 'add a setting' :P 14:05:55 <planetmaker> or something else... 14:06:04 <andythenorth> is performance why ships are often disabled on coop games? 14:06:15 <planetmaker> yes 14:06:29 <planetmaker> or rather the performance with the average guy's usage of ships 14:06:50 <planetmaker> one ship is then as good as 30 trains or so 14:06:57 <planetmaker> cpu-wise 14:07:24 <andythenorth> :( 14:07:48 <planetmaker> this number is just a guestimate, but... that's how it 'feels' 14:09:51 <andythenorth> has it been profiled in any way? 14:11:07 <Ammler> planetmaker: why is next ogfx 0.4.0 and not 0.3.3? 14:12:56 <planetmaker> next is 0.3.3 14:13:38 <Ammler> you should also remove the version, if you reject a ticket 14:14:18 <Ammler> then I create the version and assign the tickets there I work on, ok? 14:15:16 <Ammler> hmm, theoretically you also have a release date already for it, right? 14:15:35 <Ammler> around middle march? 14:17:41 <Ammler> if you like something done, please assign it to the version else I pick what I like :-) 14:18:39 <planetmaker> yes, about that 14:18:57 <planetmaker> and pick what you like :-) 14:19:05 <planetmaker> If you're undecided: update the helicopters :-P 14:19:35 <planetmaker> or fix the maglev alignment ;-) 14:26:29 <Ammler> IMO, the maglev tracks need complete replacement, not just fixing 14:28:57 <planetmaker> :-) That, too. But alignment of trains is unharmed by that 14:30:48 <Ammler> ah, you mean maglev trains alignment 14:32:31 <planetmaker> yep 14:34:34 <Brot6> FISH - Revision 579:5ee39964eeec: Change: set speed for Tow Boat (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/5ee39964eeec 14:34:34 <Brot6> FISH - Revision 580:36072520bb8b: Change: update changelog preparatory to 0.9 release (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/36072520bb8b 14:40:29 <andythenorth> just a few boring tickets left for 0.9 :| 14:42:41 * Hirundo re-ponders #2304 14:42:41 <Brot6> Hirundo: #2304 is http://dev.openttdcoop.org/issues/show/2304 "NewGRF Meta Language - Bug #2304: Prepending a switch block before produce/random_switch fails - #openttdcoop Development Zone" 14:49:03 <Brot6> FISH - Feature #2323 (New): Hydrofoil bounding boxes need tweaks (andythenorth) @ http://dev.openttdcoop.org/issues/2323 14:57:13 <Brot6> FISH - Revision 581:6e329dcea4dc: Change: correct buy menu position for Hydrofoils and Traders (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/6e329dcea4dc 15:07:59 <Brot6> OpenGFX - Bug #2301 (Closed): misalignment with house (planetmaker) @ http://dev.openttdcoop.org/issues/2301 15:07:59 <Brot6> OpenGFX - Revision 609:476930a9cea1: Fix #2301: misalignment 1px (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/476930a9cea1 15:07:59 <Brot6> OpenGFX - Bug #2301 (Closed): misalignment with house (Ammler) @ http://dev.openttdcoop.org/issues/2301#change-5924 15:10:26 <Brot6> OpenGFX - Bug #2164: inconsistent invisibility for industries (Ammler) @ http://dev.openttdcoop.org/issues/2164#change-5925 15:11:38 <Brot6> OpenGFX - Bug #2153: tubular brigde (Ammler) @ http://dev.openttdcoop.org/issues/2153#change-5926 15:14:20 <Brot6> OpenGFX - Bug #2164: inconsistent invisibility for industries (planetmaker) @ http://dev.openttdcoop.org/issues/2164#change-5927 15:15:24 <Brot6> OpenGFX - Bug #2137: weird coast tiles (Ammler) @ http://dev.openttdcoop.org/issues/2137#change-5928 15:18:46 <Brot6> OpenGFX - Code Review #2119: New Sprites for Guru X2 Helicopter (Ammler) @ http://dev.openttdcoop.org/issues/2119#change-5929 15:21:28 <planetmaker> Ammler: try? 15:25:22 <Ammler> try?? 15:26:14 <Brot6> FISH - Revision 582:0095c3742135: Change: adjust Log Raft capacities to fit with permutations of ... (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/0095c3742135 15:27:11 <planetmaker> try to convert to full (or no-action) palette and see whether CC remains 15:28:29 <Ammler> planetmaker: I don't need to convert, I see the blue line 15:28:46 <Brot6> OpenGFX - Bug #2137: weird coast tiles (planetmaker) @ http://dev.openttdcoop.org/issues/2137#change-5931 15:28:54 <Ammler> maybe it should be opposite, blue heli with white line 15:29:16 <planetmaker> I doubt. If it looks ok - go for it. 15:29:28 <Ammler> I already said, it isn't ok for me 15:29:43 <Ammler> so I need someone who tells me, I am wrong to code it :-) 15:31:59 <planetmaker> well, if the colours are not ok... then skip them for now. I think I convinced DMK meanwhile to use palettes and revise his sprites ;-) 15:32:10 <Brot6> OpenGFX - Bug #2137: weird coast tiles (Ammler) @ http://dev.openttdcoop.org/issues/2137#change-5932 15:33:40 <Ammler> planetmaker: you got me wrong, it is nothing about wrong colors 15:34:18 <Ammler> the specific heli just has too less company color for my taste 15:35:00 <planetmaker> hm, ah 15:35:17 <planetmaker> that didn't get clear from your comment there :-P 15:38:24 <Brot6> OpenGFX - Code Review #2119: New Sprites for Guru X2 Helicopter (Ammler) @ http://dev.openttdcoop.org/issues/2119#change-5929 15:38:52 <Brot6> FISH - Revision 583:b86b30940987: Change: refactor Log Raft to use templating for action 1 sprites (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/b86b30940987 15:44:19 <Brot6> OpenGFX - Bug #2116: wind direction (Ammler) @ http://dev.openttdcoop.org/issues/2116#change-5933 15:46:50 <Brot6> OpenGFX - Bug #2112: Houses' foundation sprites (Ammler) @ http://dev.openttdcoop.org/issues/2112#change-5934 15:47:49 <Ammler> looks like company color is a generic issue of DanMacKs redraws? 15:48:07 <dihedral> hello 15:48:22 <Ammler> Saletti dih 15:48:27 <dihedral> :-) 15:53:41 <planetmaker> salut dihedral 15:53:45 <planetmaker> Ammler: yes, it sadly is 15:54:07 <dihedral> :-) 16:03:53 <Ammler> hmm, also those helicopters need complete new coding, right? 16:04:03 <Ammler> or is there some template around? 16:06:30 <planetmaker> you could look at av8. But otherwise: new 16:07:11 <planetmaker> planes are hardly template-able 16:12:42 <andythenorth> template everything! 16:12:45 * andythenorth back to work 16:13:47 <Ammler> the rotors are broken in ogfx because of bad code 16:14:00 <Ammler> the sprites look fine 16:26:08 <Ammler> hmm, current opengfx aircraft is broken completely? 16:28:24 <Ammler> I miss the progress bar of grfcodec 16:33:27 <Ammler> http://susepaste.org/75179469 16:33:28 <Webster> Title: SUSE Paste (at susepaste.org) 16:36:39 <planetmaker> looks strange 16:36:44 <Ammler> planetmaker: you broke it with r607 16:37:14 <planetmaker> but it looks fine here 16:37:36 <Ammler> the diff of 607 changes the whole file 16:37:39 <planetmaker> and I use r607M 16:38:36 <planetmaker> yes, I changed the whole file, that's true 16:39:07 <planetmaker> so... what do you do different from me? 16:41:19 <planetmaker> dunno, Ammler, are you missing a file? I don't see any which I could have missed... 16:43:26 <Ammler> well, just check the diff or r607 16:43:34 <Ammler> you really don't see, how you broke it? 16:43:39 <Ammler> of* 16:43:52 <Ammler> it is quite obvious here 16:44:49 <Ammler> oh maybe it is earlier 16:46:59 <Ammler> did you use some sed to number the sprites? 16:47:58 <Ammler> maybe I broke it? :-o 16:48:24 <Brot6> FISH - Revision 584:92d8b3e06c89: Change: work in progress refactoring Log Raft offsets etc (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/92d8b3e06c89 16:49:26 <Ammler> no, you! 16:50:09 <Ammler> and why do you add the escape header to a partial file, does that work? 16:50:24 <planetmaker> Ammler: there's an associated NML file... 16:50:36 <planetmaker> http://dev.openttdcoop.org/projects/opengfx/repository/revisions/b23d5337a67c 16:50:40 <planetmaker> it's a generated pnfo file 16:50:48 <Ammler> how do I know that? 16:51:05 <planetmaker> you quoted the commit. So I assumed you looked at it :-) 16:51:17 <planetmaker> and from the commit message 16:51:26 <planetmaker> Add #2107 #2109: New sprites for the Darwin300 and the Bakewell Luckett aircraft 16:51:26 <Brot6> planetmaker: #2107 is http://dev.openttdcoop.org/issues/show/2107 "OpenGFX - Code Review #2107: New Darwin 300 Sprites - #openttdcoop Development Zone" 16:51:28 <planetmaker> Change: Add the a NML file for the aircraft 16:51:59 <Ammler> we should move such pnfo to a subdir 16:52:12 <Ammler> or another extension 16:52:22 <planetmaker> other extension 16:52:24 <planetmaker> easier 16:52:35 <planetmaker> gnfo - like generated nfo 16:58:42 <andythenorth> yup 17:02:10 * andythenorth causes epic log raft breakage 17:02:21 <andythenorth> refactoring is like tooth extraction :P 17:02:26 <andythenorth> necessary due to earlier mistakes 17:02:30 <andythenorth> and better when it's done 17:02:42 <planetmaker> andythenorth: guess what half the coding work on OpenTTD is - if not WAY more ;-) 17:02:53 <andythenorth> I read the vcs log :) 17:03:38 <planetmaker> and it's actually not that bad. But it produces not necessarily quick visible results 17:03:41 <Ammler> make: *** No rule to make target `sprites/nfo/base/base-3741-aircraft.pnfo', needed by `ogfx1_base.cnfo'. Stop. 17:04:01 <Ammler> how again do I trigger to build the nfo again? 17:08:59 <Brot6> nml: update from r1202 to r1203 done - http://bundles.openttdcoop.org/nml/nightlies/r1203 17:09:24 <planetmaker> why or how did you remove it? 17:09:33 <planetmaker> make nml2nfo 17:10:07 <Ammler> planetmaker: to force a rebuild 17:11:53 <Ammler> hmm, there is more broken 17:11:56 <andythenorth> bbl 17:11:57 *** andythenorth has left #openttdcoop.devzone 17:12:03 <planetmaker> what is broken? 17:12:06 <Ammler> shall I commit only the rotor fix? 17:12:26 *** michi_cc has quit IRC 17:12:29 <Ammler> http://paste.openttdcoop.org/show/109/ 17:12:29 *** michi_cc has joined #openttdcoop.devzone 17:13:30 <planetmaker> that cannot be correct, Ammler 17:13:37 <planetmaker> the width of the rotos is larger than 1px 17:14:04 <Ammler> that is compression 17:14:29 <planetmaker> look at what you do in the bnml file 17:15:12 <Ammler> then nml is broken? 17:15:18 <Ammler> hmm, maybe I need to update that 17:15:20 <Ammler> mom 17:15:34 <Ammler> but you see, what the nfo in the repo is broken? 17:16:34 <planetmaker> yes, but the nml is already broken with an initial height of 1px for the rotos - which is also wrong 17:16:55 <planetmaker> *rotors 17:18:51 <Brot6> firs: update from r1791 to r1798 done - http://bundles.openttdcoop.org/firs/nightlies/r1798 17:19:03 <Ammler> well, where does that "1" come from? 17:19:11 <Ammler> it isn't in the nml 17:19:30 <Brot6> fish: update from r569 to r584 done (1 errors) - http://bundles.openttdcoop.org/fish/nightlies/r584 17:20:41 <Brot6> North American Road Vehicle Set (NARVS) - Bug #2324 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2324 17:21:00 <Brot6> opengfx: update from r608 to r609 done - http://bundles.openttdcoop.org/opengfx/nightlies/r609 17:21:01 <planetmaker> it is the nml. 30, 14, -14, -5] instead of 14, 01, 30, -14] *should* do the trick (untested) 17:21:31 <planetmaker> and there's the 1 17:21:34 <Ammler> and where do define the nocrop flag? 17:21:43 <Brot6> ttrs: update from r31 to r33 done (7 errors) - http://bundles.openttdcoop.org/ttrs/nightlies/r33 17:21:44 <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 (r45), comic-houses (r71), frenchtowns (r6), grfcodec (r821), heqs (r572), indonesiantowns (r41), manindu (r6), metrotrackset (r56), newgrf_makefile 17:21:44 <Brot6> (r255), nml (r1203), nutracks (r176), ogfx-industries (r3), ogfx-landscape (r34), ogfx-rv (r78), ogfx-trains (r210), ogfx-trees (r42), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r45), spanishtowns (r10), swedishrails (r194), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r26), worldairlinersset (r671) 17:21:45 <planetmaker> does it have to? 17:21:56 <Ammler> does nml decide that self? 17:21:59 <planetmaker> no 17:22:53 <planetmaker> http://hg.openttdcoop.org/nml/raw-file/tip/docs/nml-language.html#real_sprites <-- compression is an optional 7th entry 17:23:09 <Brot6> narvs: compile of r6 still failed (#2324) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r6 17:23:16 <Ammler> hmm, nml uses another order? 17:23:31 <planetmaker> yes 17:23:43 <planetmaker> x,y, width, height, xoffset, yoffset, compression 17:24:16 <planetmaker> you can skip compression 17:24:44 <Ammler> okidoki 17:24:47 <Ammler> that explains 17:25:31 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus, belarusiantowns, frenchtowns, indonesiantowns (1 errors), manindu (Diffsize: 1), newgrf_makefile, ogfx-industries, ogfx-landscape, ogfx-rv (1 errors) (Diffsize: 7), ogfx-trains (39 errors), spanishtowns, swedishrails, swisstowns 17:26:09 <planetmaker> obviously my one-time awk conversion failed at that point ;-) 17:34:17 <Ammler> will you fix that before I do something 17:34:28 <Ammler> maybe might be easier 17:35:29 <Ammler> reassigned :-P 17:36:21 <Ammler> is there something else then aircraft? 17:38:46 <planetmaker> maglev trains? ;-) 17:38:51 <planetmaker> that also works w/o nml 17:39:19 <Brot6> OpenGFX - Revision 610:3022e7c6f9a8: Fix (r607): Helicopter sprite sizes were converted wrongly (planetmaker) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/3022e7c6f9a8 17:40:45 <Ammler> trains is also something you are quite experienced with 17:46:32 <planetmaker> then... enjoy the bubble generator ;-) 17:46:54 <planetmaker> something I've been putting off too long - dreading the difficulty 17:46:55 <Ammler> hmm, is it possible to include a image to FS? 17:47:18 <planetmaker> to what? 17:47:32 <Ammler> FlySpray 17:48:01 <planetmaker> "include an image to FS" means then what? Link directly to? 17:48:17 <planetmaker> yes... Open the task and get the link 17:50:49 <Brot6> OpenGFX - Bug #2052: New Icon in Transparency Options (Ammler) @ http://dev.openttdcoop.org/issues/2052#change-5939 17:52:03 *** andythenorth has joined #openttdcoop.devzone 17:52:13 <Brot6> OpenGFX - Bug #2052 (Confirmed): New Icon in Transparency Options (Ammler) @ http://dev.openttdcoop.org/issues/2052#change-5940 17:52:15 <planetmaker> oh, damn you. Now I really have to rework that window, Ammler :-P 17:53:14 <Ammler> ok, page 1 done :-) 17:55:26 <Ammler> made a new OpenGFX version: http://dev.openttdcoop.org/projects/opengfx/versions/149 17:55:35 <Brot6> OpenGFX - Code Review #1875 (Rejected): Renumber the sprites (Ammler) @ http://dev.openttdcoop.org/issues/1875#change-5941 17:58:40 <Brot6> OpenGFX - Feature #1302: alternative maglev sprites? (Ammler) @ http://dev.openttdcoop.org/issues/1302#change-5943 17:59:10 <Brot6> 2cc train set - Feature #2325 (New): Gautrain Electrostar (Voyager1) @ http://dev.openttdcoop.org/issues/2325 18:00:29 <planetmaker> http://bugs.openttd.org/task/4507 <-- Ammler the bridge sprite reduction would work 18:01:46 <Brot6> OpenGFX - Feature #1200: NoGFX for dedicated (Ammler) @ http://dev.openttdcoop.org/issues/1200#change-5944 18:05:24 <Ammler> planetmaker: without change in OpenTTD? 18:05:44 <planetmaker> yes 18:06:17 <Ammler> ok, then I miss something 18:07:10 <planetmaker> At least I'm quite confident. Did you try with a smaller sprite there? 18:09:31 <Brot6> North American Road Vehicle Set (NARVS) - Revision 7:a4251628d7a0: fixed typo, configured to buil... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/a4251628d7a0 18:09:57 <Ammler> planetmaker: I assumed there isn't a sprite to resize :-) 18:10:12 <planetmaker> he? 18:10:20 <planetmaker> the whole gui adopts to sprite sizes 18:10:24 <Brot6> narvs: compile of r7 still failed (#2324) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r7 18:10:30 <planetmaker> except a few cases like the fonts 18:12:07 *** oberhuemer has joined #openttdcoop.devzone 18:15:03 <Ammler> planetmaker: so you would like to change the bridge sprite everywhere 18:15:09 <Ammler> hmm, might make sense 18:15:24 <planetmaker> actually I'm not sure _I_ want to do that 18:15:28 <planetmaker> actually rather not ;-) 18:16:06 <Brot6> North American Road Vehicle Set (NARVS) - Revision 8:a2c22da667ab: really fixed it... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/a2c22da667ab 18:16:09 <Ammler> you were the guy, who would like to have same size for the buttons ;-) 18:16:12 <Brot6> narvs: compile of r8 still failed (#2324) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r8 18:16:20 *** oberhuemer has quit IRC 18:17:30 <Ammler> it would make sense, imo 18:21:35 <Brot6> North American Road Vehicle Set (NARVS) - Revision 9:03121cb7aa65: doh... missed one the first time (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/03121cb7aa65 18:22:44 <Brot6> narvs: compile of r9 still failed (#2324) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r9 18:26:33 <planetmaker> Ammler: might be that it might either need cutting all bridge sprites - or alternatively introducing a separate one for that task bar 18:27:11 <planetmaker> let's say - my main concern with the suggested square icon is how that looks like: that image by no means looks like a bridge - so it's a very unintuitive button then 18:27:19 <planetmaker> So for square buttons it needs a re-draw 18:27:54 <Brot6> OpenGFX - Bug #2052: New Icon in Transparency Options (Ammler) @ http://dev.openttdcoop.org/issues/2052#change-5946 18:28:41 <Brot6> FISH - Bug #2204 (Closed): Log raft is drawn incorrectly under some cases (andythenorth) @ http://dev.openttdcoop.org/issues/2204#change-5947 18:29:38 <Brot6> North American Road Vehicle Set (NARVS) - Revision 10:8215b3972e8a: sound file wasn't recognized (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/8215b3972e8a 18:30:13 <Brot6> narvs: update from r5 to r10 done (9 errors) - http://bundles.openttdcoop.org/narvs/nightlies/r10 18:34:59 <Brot6> North American Road Vehicle Set (NARVS) - Bug #2324: DevZone compile failed (Ammler) @ http://dev.openttdcoop.org/issues/2324#change-5948 18:35:47 <Brot6> 2cc train set - Feature #2300: NS Plan U DE-III (Voyager1) @ http://dev.openttdcoop.org/issues/2300#change-5949 18:40:58 <Brot6> North American Road Vehicle Set (NARVS) - Revision 11:94d3e054f5d6: some sprites were not in the ... (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/94d3e054f5d6 18:51:15 <Brot6> North American Road Vehicle Set (NARVS) - Bug #2324 (Closed): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2324 18:51:15 <Brot6> North American Road Vehicle Set (NARVS) - Bug #2324 (Closed): DevZone compile failed (oberhuemer) @ http://dev.openttdcoop.org/issues/2324#change-5950 18:54:24 <V453000> - Change: [NewGRF] Disable the flipping of train engines/wagons in the depot by default for NewGRFs [FS#4462] (r21966) planetmaker: does this make opengfx+ trains, for example the Lev3 unable to reverse? 18:54:28 <V453000> it breaks the EMU look :( 18:55:14 <V453000> mainly ... is there a way how to turn the "anti-reversing" off locally, or is it the newgrf that needs to be adjusted? 18:55:28 <Yexo> it is the newgrf 18:56:08 <V453000> ah, so the newgrf needs to say "yes, I allow to reverse engines", right? ... does any newgrf do that actually? 18:56:29 <Yexo> in fact is needs to say that for every engine separately 18:56:45 <V453000> the same for me ;) 18:56:52 <Yexo> and since that can only be done since around r21966 I think no engine currently does it 18:56:53 <V453000> not for coders I believe :) 18:57:12 <V453000> so basically with 21966 and higher I am not able to reverse any engine 18:57:39 <V453000> ? 18:58:47 <Brot6> FIRS Industry Replacement Set - Revision 1799:ffbc83baf705: Change: Update Spanish translation. (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ffbc83baf705 18:59:08 <Terkhen> andythenorth: ^ 18:59:50 <Yexo> V453000: I'm actually not sure. I thought so, but reversing of default and ogfx-trains vehicles works fine 19:00:17 <V453000> well, default, but all other newgrfs are disabled? 19:00:30 <V453000> unless the newgrf has it allowed, which is none atm 19:02:25 <Yexo> looks like the change was incorrectly done, so currently reversing still works for newgrfs 19:03:42 <Brot6> 32bpp-ez-patches: update from r22066 to r22070 done (2 errors) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r22070 19:04:28 <planetmaker> V453000: if you play vanilla you can. IIRC. But I didn't try 19:04:43 <planetmaker> oh, you noticed. yes 19:05:08 <planetmaker> yes, the default engines have the 'allow reversal' bit set 19:05:35 <planetmaker> at least that's what I figured from reading the diff 19:06:52 <Brot6> clientpatches: update from r21488 to r21488 done - http://bundles.openttdcoop.org/clientpatches/testing/r21488 19:08:25 <Brot6> serverpatches: compile of r22070 still failed (#2080) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r22070 19:09:26 <Brot6> FIRS Industry Replacement Set - Revision 1800:81705ad0b306: Change: (translations) update Dutch t... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/81705ad0b306 19:17:28 <Brot6> FISH - Revision 585:bc12ec6af3fa: Change: add basic towboat components from DanMacK (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/bc12ec6af3fa 19:19:27 <Brot6> 2cc train set - Feature #2326 (New): GWR AEC Railcar (Voyager1) @ http://dev.openttdcoop.org/issues/2326 19:27:23 *** michi_cc has quit IRC 19:29:05 *** michi_cc has joined #openttdcoop.devzone 19:42:24 <Brot6> FISH - Revision 586:ec9f7459e281: Change: rename and reorganise towboats psd source (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/ec9f7459e281 19:43:39 <Brot6> FISH - Revision 587:89b73b759185: Change: refactor log rafts (will break current graphics until c... (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/89b73b759185 19:44:35 <Ammler> shouldn't it be allowed per default and disableable as option? 19:46:30 <Ammler> I don't see the use of such a feature anyway, if someone doesn't like to reverse it, he doesn't need to use ctrl 20:05:56 <Brot6> North American Road Vehicle Set (NARVS) - Revision 12:eccb7f4c5ac1: sprite misalignment (oberhuemer) @ http://dev.openttdcoop.org/projects/narvs/repository/revisions/eccb7f4c5ac1 20:15:18 *** michi_cc has left #openttdcoop.devzone 20:15:18 *** michi_cc has joined #openttdcoop.devzone 21:06:37 <Brot6> OpenGFX - Feature #1200: NoGFX for dedicated (foobar) @ http://dev.openttdcoop.org/issues/1200#change-5951 21:11:23 <V453000> Ammler: me neither :| 21:12:53 <V453000> and I also think it should be vice versa :( 21:16:43 <Ammler> yet another bad feature thanks to Eddi :-) 21:18:06 <Ammler> well, I am not sure, when exactly it is disallowed 21:18:55 <Ammler> do you have an example for a engine you can't flip anymore but you should? 21:18:56 <V453000> so far I have tried UKRS and opengfx+ trains 21:19:13 <V453000> both GEC93 and Lev3 when 2headed SHOULD be reversible 21:19:30 <V453000> Lev3 in opengfx+ trains especially, with the EMU wagons feature 21:19:38 <Ammler> you can't anymore? 21:19:38 <V453000> and GEC93 ... that just asks for it :) 21:19:45 <V453000> yea :( 21:19:52 <Ammler> well, that is definitly a bug 21:20:47 <V453000> I think so :( ... the original engines work 21:28:02 <Ammler> V453000: request a reopen and mention what doesn't work anymore 21:28:24 <V453000> you know what is the result when I request something... :| 21:28:40 <Ammler> same with me :-D 21:28:56 <Ammler> we need to kill Edii 21:29:29 <V453000> evil schemings 21:30:51 <planetmaker> Ammler: the reason is simple: Default trains allow it. NewGRFs up to now had no means to disable it, thus they can be broken. So the fix for _all_ cases is only to allow newgrfs to enable it. 21:31:39 <Ammler> planetmaker: sorry, that is wrong, could also be seen oposite, they had no means to allow it, thus they can be broken 21:31:46 <planetmaker> thus no newgrf engine can be flipped anymore 21:32:10 <planetmaker> No newgrf is broken when an engine cannot be reversed 21:32:12 <Ammler> why the hell don't you introduce switches for such questionable things? 21:32:20 <planetmaker> that's what was done ;-) 21:32:24 <planetmaker> for the newgrfs 21:32:39 *** andythenorth has quit IRC 21:33:18 <Ammler> planetmaker: sorry, this is so wrong 21:33:36 <Ammler> it is less worse as the pbs bug, but still 21:33:40 <V453000> why could not there be a openttd switch? 21:34:01 *** andythenorth has joined #openttdcoop.devzone 21:34:21 <planetmaker> every newgrf which is maintained will support that in the next version for those engines which need it... 21:34:31 <planetmaker> and reversing the switch - that's utterly stupid 21:34:44 <Ammler> please stop using that as reason 21:34:50 <planetmaker> as it will keep producing broken grfs 21:34:56 <V453000> question: how many newGRFs will be re-done just because this setting 21:35:09 <planetmaker> now it has to be explicitly allowed, such the newgrf author checked for it to work 21:35:20 <planetmaker> V453000: every important one 21:35:27 <Ammler> why the hell do you introduce such questionable features in <10 days? 21:35:39 <planetmaker> it's a bug fix? 21:35:47 <Hirundo> for what bug exactly? 21:35:50 <Ammler> it isn't DAMN 21:35:59 <V453000> bugfix for someone who used some wagons wrongly I assume :| 21:36:16 <planetmaker> the commit message tells. Basically glitches with NewGRFs 21:36:26 <Brot6> FIRS Industry Replacement Set - Revision 1801:52b89c3c4613: Change: (translations) further update... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/52b89c3c4613 21:36:37 <Ammler> yeah, just because someone can't use openttd, devs introduce such misfeature 21:36:41 <planetmaker> No, all vehicles which are shorter than 8/8 and not specifically checking the reverse flag fail 21:36:54 <Ammler> planetmaker: but only if you use ctrl 21:37:04 <planetmaker> oh... bloody hell. Now you start to use the mb word 'misfeature', too... 21:37:16 <Ammler> of course, this is for sure 21:37:20 <planetmaker> good night 21:37:22 <Ammler> the pbs is a bug 21:38:45 <Ammler> you really should learn to talk with players before you introduce such things 21:39:20 <andythenorth> bye planetmaker 21:39:45 <V453000> Ammler: or adding the switches ;) 21:39:59 <Rubidium> Ammler: yes, we should talk to players before disabling anything... oh... *if* I were to do that I'd be able to crash your servers at will 21:40:19 <V453000> ? 21:41:29 <Rubidium> luukland et al. say that quite a few security fixes (crash prevention fixes) are misfeatures 21:41:58 <Hirundo> Wasn't it more or less the responsibility of the grf author already? IIRC Pikka's grfs show some sort of arrow instead of a vehicle when reversed in the depot, to indicate 'please reverse me back, you stupid user' 21:42:35 <Rubidium> Hirundo: "more or less", yes... but some claimed it were our (= OpenTTD developer's) responsibility 21:42:49 <Rubidium> as we can't fix the graphics there's only one thing we can do 21:42:52 <Hirundo> some = MB? 21:43:02 <V453000> now the other some claim that your responsibility that nothing works :P 21:43:13 <andythenorth> if I've understood this correctly... 21:43:16 <V453000> nothing but original engines .. :) 21:43:21 <andythenorth> disabling flipping is the right thing to do 21:44:39 <Rubidium> V453000: yes, we "broke" them 21:44:59 <Ammler> andythenorth: I don't thing you understood 21:45:02 <Rubidium> likewise that we will break some more NewGRFs "soon" 21:45:06 <Ammler> it just happens, when you use ctrl 21:46:07 <V453000> Rubidium: lets get back to the root of it ... is it changed because some player reversed some engine or wagon that should not be reversed? 21:46:15 <V453000> it is a wagon from what I see in the FS 21:46:41 <V453000> I think a proper change would be to either kill this person or change is ill brain 21:46:54 <andythenorth> if I've read the commit correctly, flipping is disabled unless prop 27 is set 21:46:58 <andythenorth> which is correct 21:47:12 <andythenorth> what's the problem here? 21:47:14 <Rubidium> V453000: yeah, start killing everyone that reports bugs ;) 21:47:35 <V453000> well, for example I have never had any problems with reversing at all 21:47:43 <Ammler> Rubidium: so if openttd alows someone to do something wrong, it is a bug 21:47:46 <V453000> why someone else does 21:48:11 <Ammler> the biggest bug of openttd is that it allows someone to play it :-P 21:48:36 <V453000> Rubidium: I am sorry but I fear you cannot make openttd idiot proof ;) nothing can be 21:48:37 <andythenorth> allowing flipping by default *is* a misfeature 21:48:53 <andythenorth> forcing newgrf authors to explicitly disable flip is a misfeature 21:49:12 <Ammler> andythenorth: you don't flip by default 21:49:12 <andythenorth> allowing newgrf authors to enable flip is simple 21:49:22 <Ammler> you need ctrl 21:49:23 <andythenorth> have I misread the commit? 21:49:27 <andythenorth> I don't see the drama 21:49:34 <Rubidium> V453000: but keeping a "broken" feature because a TTDPatch developer didn't bother about the repurcussions seems equally, if not more, wrong 21:49:40 <Ammler> yes, the commit is so stupid 21:49:46 <andythenorth> this is the right thing to do - it's about as controversial as reminding me to keep the FIRS error count to 0 21:50:18 <Ammler> it does again change common playstyle 21:50:31 <Ammler> it is :'-( 21:51:15 <andythenorth> what sets will break for you? 21:51:16 <Ammler> why should it be allowd by default trains, but not by newgrfs? 21:51:23 <Ammler> every set will break 21:51:28 <Yexo> it is allowed by newgrfs if they enable it 21:51:30 <andythenorth> wrt to what? 21:51:34 <Rubidium> in any case, disabling allowance of flipping means old NewGRFs are broken 21:51:41 <Yexo> and it is allowed for the default trains because they're known good 21:51:54 <Rubidium> it also means that *new* NewGRFs will be broken as it will be forgotten 21:52:01 <Yexo> a random newgrf with trains cannot be seen as "known good" unless it explicitly sets the "can reverse" flag 21:52:05 <Ammler> but why not allow newgrfs to mark known bad? 21:52:14 <andythenorth> because it's the wrong thing to do 21:52:19 <Rubidium> Ammler: because then future NewGRFs will be broken as well 21:52:29 <Rubidium> as well as old NewGRFs 21:52:30 <andythenorth> I don't always like the 'right thing to do' argument 21:52:30 <Yexo> because there are already a lot of broken newgrfs out there and future newgrfs won't bother to set that flag 21:52:41 <andythenorth> doing the right thing can kill software projects 21:52:48 <andythenorth> if PHP did the right thing, it wouldn't have won 21:52:57 <andythenorth> but this is right 21:53:00 <Ammler> Rubidium: easy, check if the flag is set, if not use "allow" as default, but why break newgrfs backwards? 21:53:23 <andythenorth> because making authors disable flipping is the wrong way round 21:53:34 <andythenorth> flipping is not known to be safe, so should be prevented by default 21:53:45 <Ammler> andythenorth: you didn't need to set it because it was allowed 21:53:53 <andythenorth> which is wrong 21:54:08 <Yexo> it was allowed even though the newgrfs did not support it 21:54:11 <Yexo> which was wrong 21:54:24 <Yexo> you could argue nearly all old train newgrfs were broken 21:54:29 <Ammler> so we can say, this misfeature is also against the newgrf spec? 21:54:32 <Rubidium> Ammler: allowing it by default => it's never going to be used as it "works" just like before 21:55:09 <Rubidium> i.e. why set that bit if you can't be bothered? 21:55:13 <Ammler> Yexo: not the newgrfs are broken, openttd breaks them 21:55:17 <Rubidium> (the bit to disable it) 21:55:32 <Ammler> that is IMO a big difference 21:55:42 <Yexo> Ammler: no, the newgrfs are broken by not providing proper graphics when they are reversed 21:56:01 <Yexo> openttd now disables reversing unless the newgrf indicates it has fixed that 21:56:04 <Ammler> just because some don't you set all as broken? 21:56:48 <andythenorth> Ammler: it's the equivalent in concept (if not risk) to shipping a box with open ports 21:56:53 <Ammler> Yexo: but a simple question, why not allow the player to take that decision? 21:56:54 <Yexo> yes. This way newgrfs _will_ be fixed (either by setting the bit for non-broken vehicles or by adding proper graphics) 21:56:59 <andythenorth> you don't know it's safe 21:57:06 <andythenorth> this way reduces the bug count 21:57:08 <andythenorth> plain and simple 21:57:23 <Ammler> andythenorth: for who? 21:57:27 <andythenorth> players 21:57:29 <V453000> as Ammler says, why cannot there be a switch ... maybe without a gui? 21:57:40 <andythenorth> there can - patch it 21:57:58 <Ammler> andythenorth: you can't patch that 21:58:03 <andythenorth> I could 21:58:05 <andythenorth> I can see the commit 21:58:08 <Ammler> you can, we can't 21:58:11 <andythenorth> I can remove that code 21:58:16 <andythenorth> hmm 21:58:18 <andythenorth> MP 21:58:22 <Ammler> yep :-) 21:58:22 <andythenorth> :| 21:58:45 <andythenorth> has this been announced in newgrf technical forum? 21:58:56 <Ammler> no, it was decided in one week 21:59:11 <Yexo> adding a setting would help only for people reading the forums (most other people won't find it), which are the only people who can actually complain to newgrf authors to get it fixed. Furthermore it'll only result in newgrf developers pointing to that setting as a "fix", instead of actually fixing their newgrfs 22:00:13 <andythenorth> it ought to be announced in technical forum - it's unfair to assume newgrf authors are reading vcs log 22:00:22 <Ammler> yexo, it doesn't need default 22:00:58 <Yexo> that doesn't matter 22:01:42 <Yexo> think about not being able to change newgrfs in-game. While there is a setting for that, most of the players (those who don't read the forums) will not be aware of that and simply not change newgrfs anymore 22:01:54 <Yexo> that means a lot less bug reports due to changed newgrfs 22:01:59 <Ammler> also yexo, the fix from newgrf authors could be to disallow flip 22:02:29 <Yexo> Ammler: yes, but newgrf authors WILL NOT BE BOTHERED TO SET THAT BIT UNLESS THEY HAVE TO 22:03:00 <V453000> Yexo is right, although I am really wondering how many authors will let you to bother them 22:03:17 <Ammler> omg, so you enjoy annoying players so they annoy authors to fix the newgrfs? Can that really not be made nicer? 22:03:21 <V453000> and the feature still sucks :( 22:03:32 <Yexo> yes, the feature sucks for now 22:03:39 <V453000> when will it improve? :) 22:03:50 <Yexo> Ammler: can you think of a better way to get newgrf authors to fix something like this? 22:04:02 <Ammler> Yexo: yes, like I said 22:04:03 <andythenorth> the only problem here is that no-one is telling newgrf authors :| 22:04:09 <Yexo> and don't include anyone in this channel please ;) 22:04:23 <andythenorth> shall I announce it in newgrf technical forum? 22:04:34 <Yexo> sure, go ahead 22:04:47 <Ammler> andythenorth: I would wait, maybe the devs do change their mind? 22:05:22 <andythenorth> I don't think they should 22:05:23 <andythenorth> or will 22:05:27 <Ammler> anyway, authors could set the flag 22:06:44 <Ammler> I just hate the "default" behavior the devs, if someone complains about something, devs simply disallow it to shut down the voice :'-( 22:07:10 <Rubidium> yes, it definitely was done "simply" without any thought 22:07:14 <Ammler> why did that need to fixed so fast? 22:07:26 <andythenorth> it's this one yes? http://vcs.openttd.org/svn/changeset/22072/ 22:07:43 <Ammler> Rubidium: exactly, just the most easy way for you 22:07:59 <Rubidium> andythenorth: actually r21966 22:08:41 <Ammler> and the time it is decided, you didn't think much about 22:08:49 <Rubidium> Ammler: give me a solution that: a) won't cause breakage in the future without the NewGRF author explicitly saying it's okay, b) won't show broken old NewGRFs 22:11:38 <Rubidium> oh, and for what it's worth: NewGRF authors could already disallow flipping, they just didn't use it 22:11:39 <Ammler> a) if bit is not set, use "allow" as default - b) old newgrfs need fixing with "your" solution anyway 22:11:46 <andythenorth> anything I should edit here? http://www.tt-forums.net/viewtopic.php?f=68&t=52911 22:11:47 <Webster> Title: Transport Tycoon Forums View topic - OTTD r21966 corrects flip behaviour for trains (at www.tt-forums.net) 22:11:52 <andythenorth> I'm going to sleep in a few minutes 22:12:34 <Ammler> you seriously think, mb or pikka will fix their old newgrfs? 22:12:50 <Rubidium> Ammler: given they already could pre r21966, and they didn't it's not really a viable solution 22:13:15 <Rubidium> Ammler: no, they won't. But isn't acceleration of some trains broken in mb's NewGRF in any case? 22:13:32 <Rubidium> so we already broke that NewGRF when we implemented realistic acceleration 22:13:51 <andythenorth> go to bed 22:13:57 <Ammler> well, you broke all newgrfs now 22:14:00 <andythenorth> this argument isn't going anywhere 22:14:09 <Yexo> and it's not like you won't be able to play with those newgrfs without being able to reverse the engines 22:14:11 <andythenorth> it's silly 22:14:39 <andythenorth> can anyone correct my posting? 22:14:45 <andythenorth> I was winging it 22:14:47 <Ammler> Yexo: it's not like you weren't before you introduced this misfeature 22:15:16 <Ammler> it was a "special" feature not many people used anyway 22:15:28 <Ammler> so it hurts the more, those people can't use it anymore 22:15:45 <Ammler> I can't belive, Eddi prefers it this way 22:15:57 <Yexo> not many people didn't use it -> not many people were hurt by the change -> not a big problem 22:16:09 <Ammler> well, it were for you 22:16:26 <Yexo> the behavior was buggy -> we fixed it 22:16:26 <V453000> http://wiki.openttdcoop.org/images/a/a6/PSG197.png <- how would you make these trains without reversing :| 22:16:32 <Yexo> every bug is big enough to fix 22:16:32 <Ammler> you broke all newgrfs just because a special player found a special glitch 22:16:58 <Ammler> this is not a bug, sorry, that is just someone who misused it 22:17:01 <V453000> as Ammler said, plus that he could just have learned and not use it anymore on that wagon :) 22:17:13 <Rubidium> yep, likewise that I break all competitive servers because a special player found a special glitch 22:18:03 <Rubidium> s/break/broke/ 22:18:20 <V453000> ? 22:18:44 <Ammler> Rubidium: do you compare security leaks with this very rarly special glitch? 22:19:01 <Rubidium> it's a special glitch as well, isn't it? 22:19:13 <Ammler> a security leak can be seen as bug 22:19:31 <Rubidium> it's actually *more* special, as that special glitch could only happen with modified OpenTTDs 22:19:39 <Ammler> but for sure, FS#4462 isn't a bug 22:19:39 <andythenorth> V453000: decompile the newgrf, set prop 27 bit 3, recompile 22:19:44 <andythenorth> and don't distribute :P 22:19:59 <Ammler> andythenorth: again MP 22:20:09 <andythenorth> use a different newgrf set 22:20:17 <Ammler> andythenorth: but I see now, why you don't care much about such things ;-) 22:20:41 <Rubidium> V453000: use http://wiki.ttdpatch.net/tiki-index.php?page=Action0GeneralVariables#GRF_ID_overrides_for_engines_11_ to set bit 3 when needed? 22:20:44 <Ammler> also Eddi can now patch the newgrfs 22:20:56 <Ammler> another win for the SP players 22:21:03 <andythenorth> hmm 22:21:09 <Rubidium> oh yes... you can change properties of another NewGRF's engines 22:21:18 <andythenorth> can a generic template be made for that? 22:21:22 <andythenorth> and a makefile 22:21:41 <andythenorth> basically - "put some ids in a text file, hit make" ? 22:21:47 <Ammler> Rubidium: I thought, that doesn't work 22:21:54 <Ammler> because of VarAction2 22:22:06 <andythenorth> Ammler: it's just setting an action 0 prop 22:22:08 <Yexo> Ammler: varaction2 has nothing to do with this 22:22:30 <andythenorth> bed time for me 22:22:32 <andythenorth> good night 22:22:43 <Rubidium> good night andythenorth 22:23:07 *** andythenorth has left #openttdcoop.devzone 22:25:03 <Rubidium> you *could* probably even make a single NewGRF that fixes most commonly used train sets, as long as only one of them is loaded 22:26:17 <Yexo> Rubidium: no, that's not possible 22:26:20 <V453000> you mean a "special newgrf" that would enable reversing for certain engines? 22:26:41 <Ammler> they "share" same id 22:26:41 <Rubidium> Yexo: why can't you action7/9 jump based on the NewGRF that is going to be loaded? 22:26:43 <Yexo> you can't override properties of train 2 from set A and also override properties of train 2 from set B 22:27:03 <Yexo> you can fix either of them, but not both when they're both used in the same game 22:27:21 <Rubidium> Yexo: that's why I said it works as long as only one is loaded 22:27:31 <Yexo> ah :) 22:27:57 <V453000> so there would be loaded either the newgrf OR the newgrf that "fixes" it? 22:28:08 <Ammler> both 22:28:22 <Ammler> the fix does just override this bit 22:28:37 <Ammler> is that really possible? 22:28:49 <Yexo> you can only override property 27 completely 22:28:54 <Ammler> don't you need to set the whole properity? 22:28:56 <V453000> oh :) so theoretically *someone* could make "fixing" newgfrs to allow all other sets reverse 22:28:59 <Yexo> but dbset for example doesn't use property 27 22:29:08 <Ammler> ok 22:29:20 <Yexo> so in that case just set prop 27 with only the "allow reverse" bit set 22:29:50 <Yexo> before you do that, please test all engines and see if they support reversing correctly and don't set the bit for vehicles that cause glitches 22:30:16 <Ammler> Yexo: as you say, glitch, not bug :-) 22:30:37 <Yexo> does that matter? 22:30:46 <Yexo> a glitch is caused by a bug 22:31:16 <Ammler> well, for me it is something, the player should care of 22:31:20 <Ammler> not the dev 22:32:10 <Ammler> but ok, we are at least aware of a workaround 22:33:37 <Ammler> it might be easy done with some decompiling and seding 22:33:45 <Ammler> and then removing the bad ids 22:37:27 <Ammler> Yexo: in any case, it would have been easier to make fix_dbset.grf which disalbed flip for that short waggon :-P 22:38:02 <Ammler> I would guess, flipping is fine for around 98% 22:39:07 <Ammler> it needed 7 years for Eddi to find that bug 22:39:16 <Ammler> and he is one playing with dbset quite a lot 22:41:24 <Yexo> fix_dbset.grf <- nobody would bother to use it so it'd still be broken 22:42:45 <Ammler> only broken for one dumb user 22:43:14 <Yexo> no, broken for everyone just not noticed that often, or noticed but not reported 22:44:00 <Ammler> well, most do agree, that it is their fault and not the fault of openttd or the newgrf 22:44:20 <Ammler> and so whould be quite ashamed to report that as a bug 22:45:25 <Rubidium> do most really agree? I guess they do, after all people never reported bugs caused due to changing NewGRFs, removing NewGRFs, etc. 22:45:50 <Ammler> :-) 22:45:51 <Rubidium> arguably most don't even know about the flip "feature" 22:46:09 <Rubidium> like only a few percent was using NewGRFs until bananas came around 22:46:29 <Ammler> Rubidium: that is the sadest, you broke a feature for advanaced users only 22:47:01 <Ammler> but well, if override works, it is handleable 22:47:18 <Ammler> then it is like a advanced setting :-P 22:47:23 <Yexo> Ammler: see it in another way: now it is fixed a gui option can be made to reverse engines, so more people become aware of it 22:48:23 <Rubidium> though eventually those features will becomes more widespread, after all reversing makes most sense with NewGRFs enabled and they starting to "penetrate" the OpenTTD realm 22:48:25 <Ammler> Rubidium: the same with pbs bug, usual players never got aware about that 22:48:46 <Rubidium> which one? 22:49:03 <Rubidium> as basically every behaviour of pbs seems to be marked as buggy by some 22:49:12 <Ammler> the one trains "park" in back of a oneway pbs signal 22:50:57 <Rubidium> oh, you mean the one where trains are allowed to enter a platform from the "wrong side" when there's a one way path signal at the entrance ;) 22:51:35 <Ammler> which is not needed, you could there still make 2 singals :-P 22:51:53 <Rubidium> even then, it would *only* "park" there when it was utterly lost 22:52:01 <Rubidium> and even that got changed 22:52:43 <Rubidium> as now it needs to be really utterly lost; basically there being no other "way out" 22:53:28 <Rubidium> ofcourse using 2 way signals that say "dead end" means that that is no "way out", but you can disable that 22:54:24 <Ammler> hmm, I have no clue :-) 22:56:25 <V453000> http://wiki.openttdcoop.org/File:PSG180.png I do not understand why this does not work though :( 22:56:57 <V453000> hm ... maybe ... lets try something 22:58:02 <V453000> ok, I have no clue why it does not work :( all the paths outside are there 22:58:23 <V453000> no terminus stations, no dead ends 22:58:29 <Ammler> V453000: is that related to current discussion? 22:58:41 <Ammler> or something new? 22:58:54 <V453000> it is the bug with trains bouncing into the 1way PBS 22:59:00 <V453000> I suppose it is related :) 22:59:25 <Ammler> what rev was psg180 played with? 23:00:13 <V453000> archive says 19523 was the final one but I think it was played mostly with 19443 23:03:11 <V453000> from what I remember I think it got updated halfway through the game, which broke it 23:03:46 <Ammler> and nobody complained at that time? 23:04:23 <V453000> I believe Vitus did 23:07:16 <V453000> r19894 is the last one working 23:09:02 <V453000> hmm 23:09:22 <V453000> two months later, so obviously my memory fails :) the game worked at the time it was archived 23:16:55 <Ammler> well maybe it does work again 23:18:21 <V453000> no :) 23:18:50 <V453000> that is why I do not understand why it doesnt, according to <Rubidium> [23:52:43] as now it needs to be really utterly lost; basically there being no other "way out" 23:19:13 <V453000> the way out is there 23:19:21 <V453000> lost trains, yes, but why no way out :)) 23:20:42 <Ammler> well, the pathfinder cache could still be wrong, but I am not really exprienced there 23:21:28 <Ammler> do those trains have order at all? 23:22:12 <V453000> none 23:22:38 <Ammler> maybe that is meant with "utterly lost" :-) 23:23:00 <V453000> :P 23:23:42 <Rubidium> remember what I said about "dead ends"? 23:24:00 <Rubidium> the back of a PBS signal is, like two way signals with some settings, a dead end 23:24:13 <V453000> it would make good sense to me, if they would also "bump" into the 1way block signals 23:25:15 <V453000> yes, but if there is any other way out, the dead end should be really dead :) 23:27:46 <Rubidium> but there isn't, at least with the setting that two way signals are dead ends 23:28:04 <Rubidium> they are equally dead, considering there's a train waiting to pass the signal at the other side 23:28:06 <V453000> yes, but I do not have 2way signals there :) 23:28:13 <Rubidium> you do 23:28:54 <Rubidium> it's filled with: one two way signal + three path signals stretches 23:29:23 <Rubidium> as the two way signal is the safe waiting point, that will be considered for "dead end" determiniation 23:29:41 <V453000> wait, those branches are just the tracks where trains are supposed to go 23:29:45 <V453000> they do go there 23:29:53 <V453000> but they also go to the 1way tracks 23:29:57 <V453000> which is the problem 23:30:12 <Rubidium> yes, but when a train is waiting there, the two way signal is red and thus that track is a "dead end" 23:30:15 <V453000> even though the trains at the 1way signals can not see any firstred 2way eol 23:30:30 <V453000> how could it be red when it isnt the first signal? 23:30:34 <V453000> there are 3 in front of it 23:30:47 <V453000> and it isnt red either :) 23:30:55 <Rubidium> those are facing the wrong way for finding the "safe waiting position", i.e. they are ignored 23:31:13 <V453000> they still are green :) 23:31:18 <Brot6> Berries - Feature Request #1778 (Closed): Password should be alternatively available per http (dih) @ http://dev.openttdcoop.org/issues/1778#change-5952 23:32:22 <V453000> every single path there is equal 23:32:30 <Ammler> good night all :-9 23:32:31 <V453000> or at least, every single path is able to reach any exit 23:32:37 <V453000> all are connected with each other 23:32:57 <V453000> and there are no red 2way signals at the time of the choice on 1way PBS signal 23:33:24 <V453000> oh wait, that one :) 23:33:29 <V453000> I see what you mean now 23:33:33 <V453000> lets try something 23:35:26 <V453000> no, even if I make all these signals 1way, it breaks 23:36:15 <Rubidium> then all other exits must've been deemed dead ends as well, or I don't understand YAPF (which is quite likely as well) 23:36:35 <Rubidium> feel free to fix YAPF without breaking the other use cases 23:36:41 <V453000> they cannot be, because every exit is connected with each other 23:36:54 <V453000> so all of them are equal 23:36:59 <V453000> or, the path exists 23:37:23 <Brot6> Berries - Bug #2327 (New): Read passwords file only from own plugins jar (dih) @ http://dev.openttdcoop.org/issues/2327 23:39:24 <V453000> it definitely does behave better than it used to when the bug was reported, that is for sure 23:39:37 <V453000> but trains still bump into ends of signals when they have other way out 23:39:52 <V453000> and no eol 23:40:15 <Brot6> Grapes - Feature Request #1999 (Closed): Separate Command Handling (dih) @ http://dev.openttdcoop.org/issues/1999#change-5953 23:41:05 <Brot6> Grapes - Code Review #1777 (Closed): type case of a possible void return value (dih) @ http://dev.openttdcoop.org/issues/1777#change-5954 23:45:09 <Rubidium> well, sadly enough there are two competing "evils" w.r.t. safe waiting points. So I fear not much can be done about it, unless you really grasp YAPF 23:47:40 <V453000> which I obviously dont :p 23:48:29 <V453000> anyway, good night 23:50:24 <Brot6> Grapes - Feature Request #2328 (New): Generic message handling (dih) @ http://dev.openttdcoop.org/issues/2328