Log for #openttdcoop.devzone on 28th June 2011:
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) @
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 | Downloads log: | 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 | Downloads log: | 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: <- 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) @
15:50:51  <Brot6> OpenGFX+ Industries - Feature Request #2562: Ground aware "stranger" industries (Ammler) @
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) -
17:20:46  <Brot6> ogfx-industries: compile of r121 still failed (#2792) -
17:21:21  <Brot6> sub-landscape: compile of r66 still failed (#2616) -
17:22:06  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
17:22:39  <Brot6> OpenGFX+ Industries - Bug #2792: DevZone compile failed (Ammler) @
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

Powered by YARRSTE version: svn-trunk