Times are UTC Toggle Colours
05:02:03 *** bodis has joined #openttdcoop.devzone 05:29:06 *** bodis has quit IRC 05:40:42 *** andythenorth has joined #openttdcoop.devzone 06:12:19 *** andythenorth has quit IRC 08:29:16 <dihedral> Dear SuSE God Ammler, i understand you are the most powerful and allknowing SuSE God. Eventhough I do not believe in you, though if you do exist, Please consider me poor heathen worthy of your help. Please provide me with ImageMagick :-D 08:52:32 <Ammler> my poor peasant 08:52:33 <Ammler> dihedral: listen to your master and install the holly sdk, do I need to repeat my words from our last audience? 08:58:46 <dihedral> i must install the sdk in the sles server? 09:00:09 <dihedral> i have the link 09:00:13 <dihedral> i need both DVD images? 09:00:53 <Ammler> install by adding the repo, yes 09:01:13 <Ammler> imagemagick is on the sdk 09:01:40 <dihedral> i can leave the DVD as source of any repo? 09:01:40 <dihedral> or do i have to add them somehow in yast 09:02:00 <Ammler> you like to use yast? 09:02:17 * Ammler works with zypper mostly 09:02:21 <dihedral> i think 'like' is the wrong word 09:02:33 <dihedral> i just do not know my way round suse ^^ 09:02:41 <dihedral> consider me a 'newbe' :-D 09:02:48 <Ammler> again, zypper is like aptitude 09:02:56 <Ammler> zypper help 09:03:28 <Ammler> zypper addrepo path-to-sdk 09:03:35 <Ammler> zypper ref 09:03:42 <Ammler> zypper in imagemagick 09:04:32 <Ammler> in a company you mostly have the iso's as http or whatever share in the network 09:05:53 <Ammler> check the pastebin example 09:11:16 <Ammler> also you need somehow a update repo to a remote url, "zypper ar -f url-to-updates" 09:11:35 <Ammler> (no clue how that works on sle) 09:12:38 <Ammler> zypper repos -d 09:14:19 <dihedral> only works once the license is installed 09:14:30 <dihedral> howerver we cannot download the license as that part of the website is down 09:22:11 <Ammler> :-o 09:31:41 <dihedral> Ammler, do you have the ISOs for the SDK? 09:31:51 <dihedral> the download from Novell only goes to about 1M/s 09:32:05 <Ammler> dihedral: I have no sle 09:32:17 <Ammler> I just have some IRC friends with it 09:32:34 <Ammler> #opensuse-de 10:01:45 *** Rubidium has quit IRC 10:01:49 *** Rubidium has joined #openttdcoop.devzone 10:31:06 *** dihedral has quit IRC 10:31:30 *** seberoth has quit IRC 10:31:40 *** dihedral has joined #openttdcoop.devzone 10:32:11 *** seberoth has joined #openttdcoop.devzone 10:32:35 <Brot6> NewGRF Meta Language - Feature Request #1555: Explicitly define callbacks (Hirundo) @ http://dev.openttdcoop.org/issues/1555#change-6978 10:32:56 <Hirundo> Yexo: please comment on ^^ 11:18:34 <Yexo> "- If there is a default defined in the graphics block, it is used for all unhandled callbacks. This to keep backward compatibility and allow manual callback handling. Else all unhandled callbacks chain to CB_FAILED." 11:18:46 <Yexo> ^^the result of chaining to default and to CB_FAILED is exactly the same 11:19:01 <Yexo> OpenTTD will make the result "CALLBACK_FAILED" either way 11:19:29 <Yexo> so it doesn't matter which way we chose. although chaining to default is the more clean option to allow manual handling 11:20:28 <Yexo> cargo type via action3 is nice and well, but the action3 is the graphics block 11:20:41 <Yexo> if you define named callbacks there too, how do you handle a callback which depends on the cargo type? 11:33:59 <Hirundo> switch later on, based on current cargo 11:38:32 <Hirundo> that would work (easily) for stations, but tbh I can't find a valid use case for that 11:39:16 <Yexo> that would not work for stations, only for vehicles 11:39:36 <Yexo> you might be right though that there is no valid use case for stations 11:42:28 <Hirundo> gotta leave now, we'll talk later 12:00:42 *** SmatZ has quit IRC 12:01:06 *** avdg has quit IRC 12:01:21 *** SmatZ has joined #openttdcoop.devzone 12:01:51 *** avdg has joined #openttdcoop.devzone 12:18:42 *** tneo has quit IRC 12:19:21 *** tneo has joined #openttdcoop.devzone 12:50:23 <planetmaker> well... handling callbacks in a manual way will probably continue to be needed 12:51:21 <planetmaker> as it both makes sense to first handle callbacks, and then graphics - separately - or sometimes to first handle some varaction2 stuff - and then a callback depending on their results 12:52:16 <planetmaker> it's not more beta than any other released firs version 12:52:37 <Hirundo> planetmaker: could you elaborate on that? 12:53:27 *** ChanServ changes topic to "Talk about things hosted and developed on http://dev.openttdcoop.org | Downloads log: http://bundles.openttdcoop.org/log.csv | Sandbox passwords are the same as the usernames" 12:53:38 <planetmaker> Hirundo: like switch (cargo) -> switch (callback weith property) / grpahics 12:54:01 <planetmaker> vs. switch (graphics -> switch cargo and switch (callback) -> switch cargo) 12:54:10 <planetmaker> you'd double the cargo switch 12:54:47 <Hirundo> You mean, if CB results depend on the cargo? 12:54:52 <planetmaker> yes 12:55:04 <planetmaker> and graphics of course, too 12:55:12 <planetmaker> then deciding on cargo first makes sense 12:55:42 <planetmaker> like pax / express / cargo or similar 12:55:59 <Hirundo> but a pax / express distinction cannot be made by action3 already 12:56:40 <planetmaker> I guess so... I nearly never did, though ;-) 12:56:53 *** ChanServ changes topic to "Talk about things hosted and developed on http://dev.openttdcoop.org | Downloads log: http://bundles.openttdcoop.org/log.csv | Sandbox passwords are the same as the usernames" 12:56:56 <Hirundo> unless you explicitly define all pax / express cargos in the action3 and pray that none will be added in the future 12:57:24 <Yexo> Hirundo: not in the action3 no, but that distinction can be made in the first linked varaction2 12:57:28 <planetmaker> well... but the CBs would calling then in each graphics branch 12:59:46 <Yexo> Hirundo: http://paste.openttdcoop.org/show/303/ <- this basically 13:04:17 <Hirundo> I couldn't find an existing use of that in ogfx+, but I admit I didn't try very hard 13:05:38 <Yexo> are there any callbacks that are available in both the purchase list and afterwards? 13:05:43 <Hirundo> Many 13:05:51 <Hirundo> speed, power, capacity and such 13:06:01 <Yexo> how do you plan to handle those? 13:06:10 <Yexo> both "speed" and "purchase_speed" callbacks? 13:07:44 <Hirundo> Usually only 'speed', but a separate a purchase_speed may be defined that overrides 'speed' in the purchase list 13:08:08 <Yexo> ok, good :) 13:08:18 <Hirundo> Then later, we could check that no vehicle vars are used in speed (except those that are accessible) 13:09:48 <Hirundo> w.r.t. the 'default', there are actually two defaults, I'm not sure yet how to handle this 13:10:16 <Hirundo> there's "default: XXX" that should define the default graphics (if no cargo matches) 13:11:27 <Hirundo> and also the default if no callback matches, mainly intended for 'advanced' uses as discussed above 13:12:11 <Hirundo> perhaps 'default' and 'purchase' should be 'default_graphics' and 'purchase_graphics' 13:12:35 <Hirundo> and 'default: xxx' an alias of the current 'xxx' that may be placed at the end of the block 13:18:43 <Hirundo> Yexo: ^^ 13:18:54 <Hirundo> And then there's also the wonderful issue of livery overrides.... 13:19:34 <Yexo> I don't see why those two defaults should be separated 13:19:48 <Hirundo> hmm... 13:19:58 <Hirundo> So all unhandled callbacks end up at the default gfx? 13:20:06 <Yexo> does a livery override influence any callbacks or just the real graphics? 13:20:19 <Yexo> I don't see a problem with that 13:20:37 <Hirundo> I suspect the former, checking now 13:21:47 <Hirundo> Yes, all callbacks are handled via the livery override as well 13:22:12 <Yexo> so the livery override block should be a copy of the normal graphics block, with the exception of "purchase_" callbacks 13:22:35 <Hirundo> yes, those make no sense there 13:22:56 <Hirundo> TTDPatch (and OpenTTD to some extent) have some quite demanding rules w.r.t. livery overrides 13:23:52 <Yexo> I'm questioning more and more if we should invest any time at all to keep compatibility with TTDPatch 13:23:54 <Hirundo> action3 and livery overrides must be a continuous list with no other actions in between, except action6. Skipping part of the list with actino7 is not possible 13:24:20 <Yexo> I won't advocate breaking TTDPatch support on purpose, just not invest any extra time in it 13:24:40 <Yexo> since I doubt nml is at this point of time compatible, and I also doubt anyone is actually testing compatibility 13:24:41 <Hirundo> At least the partial skipping is true for OpenTTD as well 13:25:17 <Yexo> the "must be a continuous list", is that true for OpenTTD? 13:25:30 <Hirundo> not as far as I can tell 13:25:36 <Yexo> thought so 13:26:25 <Hirundo> OpenTTD just seems to store the engine/count of the latest action3 and act upon that 13:27:16 <Hirundo> What would happen, if you skip the first action3 of your grf, but not the livery overrides that follow it? 13:28:00 <Yexo> they get ignored 13:28:17 <Yexo> it's not safe though, since if you skip the second action3 all livery overrides that follow it will apply to the previous action3 13:31:04 <Hirundo> Yes they act upon the previous action3, even if the previous action3 is defined by another grf 13:31:20 <Hirundo> As you say, it's $bad_stuff 13:33:53 <Yexo> what about changing the nml syntax for livery overrides? we now have: item(...) { graphics { ...} livery_override { ...} } 13:34:36 <Yexo> if we make it: item(...) { graphics {...; livery_override {...} } } we ensure in the nml syntax already that the override is inside the graphics block 13:34:46 <Yexo> which means nml can ensure it's encoded right after the default action3 13:35:14 <Yexo> it also makes it easy to take everything from the outer graphics block as default value in the livery-override block and only override specific callbacks / graphics 13:36:28 <Hirundo> Taking the outer graphics block as default makes relatively little sense, since it belongs to the engine while the override belongs to the wagon 13:37:43 <Yexo> both belong to the wagon 13:38:13 <Hirundo> no, livery override must be added right after the engine action3 13:39:19 <Yexo> ah, sorry 13:39:23 <Yexo> should've checked the specs first 13:41:58 <Hirundo> That's the confusing part, I really have no clue why they did it that way in TTDP 13:44:35 <Yexo> I think it would be possible to implement it the "logical" way in nml 13:46:23 <Hirundo> I'm thinking about that too 13:46:37 <Hirundo> Problem is that you need to move stuff around in nfo 13:46:52 <Hirundo> which can result in problems with variable IDs and spritegroup refs 13:50:08 <Yexo> true, not sure if that is solvable 13:50:27 <Yexo> got to go, we'll discuss this more later :) 15:01:33 *** michi_cc has quit IRC 15:02:09 *** michi_cc has joined #openttdcoop.devzone 15:03:56 *** michi_cc has quit IRC 15:04:26 *** michi_cc has joined #openttdcoop.devzone 15:47:34 <Brot6> OpenGFX+ Industries - Feature Request #2562: Ground aware "stranger" industries (Terkhen) @ http://dev.openttdcoop.org/issues/2562#change-6979 15:50:51 <Brot6> OpenGFX+ Industries - Feature Request #2562: Ground aware "stranger" industries (Ammler) @ http://dev.openttdcoop.org/issues/2562#change-6980 15:58:52 <dihedral> it works 15:59:12 <dihedral> Ammler: the repositories were added automatically once that stupid licence was added 16:00:23 <Ammler> I guess, the (stupid) novell support assumed you have a valid license 16:38:49 *** bodis has joined #openttdcoop.devzone 16:57:43 *** frosch123 has joined #openttdcoop.devzone 17:01:36 *** andythenorth has joined #openttdcoop.devzone 17:14:38 *** andythenorth has quit IRC 17:18:27 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r40), ai-admiralai (r75), ai-aroai (r39), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r107), basecosts (r25), belarusiantowns (r8), bros (r52), cets (r5), chips (r143), comic-houses (r71), firs (r2095), firs.nml (r2081), fish (r653), frenchtowns (r6), german-townnames (r34), grfcodec 17:18:28 <Brot6> (r832), grfpack (r279), heqs (r605), indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r296), nml (r1486), nutracks (r202), ogfx-industries (r121), ogfx-landscape (r70), ogfx-rv (r107), ogfx-trains (r245), ogfx-trees (ERROR r51), opengfx (r678), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), 17:18:29 <Brot6> swisstowns (r22), transrapidtrackset (r15), ttdviewer (r34), ttrs (r36), worldairlinersset (r672) 17:19:34 <Ammler> wow, what a lazy day! 17:20:22 <Brot6> narvs: compile of r37 still failed (#2789) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r37 17:20:46 <Brot6> ogfx-industries: compile of r121 still failed (#2792) - http://bundles.openttdcoop.org/ogfx-industries/nightlies/ERROR/r121 17:21:21 <Brot6> sub-landscape: compile of r66 still failed (#2616) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r66 17:22:06 <Brot6> sub-opengfx: compile of r666 still failed (#2586) - http://bundles.openttdcoop.org/sub-opengfx/nightlies/ERROR/r666 17:22:39 <Brot6> OpenGFX+ Industries - Bug #2792: DevZone compile failed (Ammler) @ http://dev.openttdcoop.org/issues/2792#change-6981 17:31:56 <Ammler> Yexo: seems was not a nml bug or nml is not fixed 17:33:25 <Yexo> still think it's an nml bug 17:33:27 <Yexo> will think of a fix later 17:33:49 *** andythenorth has joined #openttdcoop.devzone 17:34:03 <Ammler> I still think, it would be good idea to add a kind of minimal required nml version properity 17:34:10 *** andythenorth has quit IRC 17:34:28 *** ODM has joined #openttdcoop.devzone 17:34:33 <Ammler> so you could also trigger a rebuild 18:01:28 *** andythenorth has joined #openttdcoop.devzone 18:20:48 <Ammler> maybe it could be handled by the makefile framewrok 20:27:53 *** andythenorth has quit IRC 21:20:50 *** frosch123 has quit IRC 21:43:19 *** ODM has quit IRC 22:03:15 *** Lakie has joined #openttdcoop.devzone 22:05:26 *** bodis has quit IRC 22:32:56 *** Lakie` has joined #openttdcoop.devzone 22:39:47 *** Lakie has quit IRC 23:45:55 *** Lakie` has quit IRC