Log for #openttdcoop.devzone on 26th October 2010:
Times are UTC Toggle Colours
00:20:45  *** KenjiE20 has quit IRC
00:43:47  *** Levi1 has quit IRC
08:07:49  *** Brot6 has quit IRC
08:08:26  *** Brot6 has joined #openttdcoop.devzone
08:09:45  *** Brot6 has joined #openttdcoop.devzone
08:16:06  *** Brot6 has quit IRC
08:16:15  *** Hirundo has quit IRC
08:16:15  *** Guest298 has quit IRC
08:16:18  *** Brot6_ has joined #openttdcoop.devzone
08:16:40  *** Hirundo has joined #openttdcoop.devzone
08:17:06  *** Brot6_ is now known as Brot6
08:17:36  *** Brot6 has quit IRC
08:17:41  *** V453000 has joined #openttdcoop.devzone
08:18:02  *** Brot6 has joined #openttdcoop.devzone
09:34:42  *** Webster has joined #openttdcoop.devzone
09:40:00  *** Guest671 has quit IRC
09:41:02  *** ODM has joined #openttdcoop.devzone
09:52:43  *** andythenorth_ has joined #openttdcoop.devzone
09:52:51  * andythenorth_ ponders
09:54:56  *** Webster has joined #openttdcoop.devzone
10:01:05  *** Webster has joined #openttdcoop.devzone
10:01:10  <planetmaker> :-D
10:01:13  <andythenorth_> it's just an exercise for them in repainting trains
10:01:34  <andythenorth_> what would work is a web-based system where they just upload pngs and it compiles
10:01:48  <andythenorth_> no coder needed, apart from setting up basics
10:02:13  <andythenorth_> I think some of them will hate it, because they are very anal trainspotters
10:02:17  <planetmaker> Well. Given NML it really would just need a bit copy & paste, not much understanding
10:02:37  <planetmaker> But I see your point and it probably is valid
10:02:45  <andythenorth_> I think there is an expectation that BROS will enable very precise control over liveries by time etc - basically creating a perfect model of UK rail
10:02:54  <andythenorth_> but *nobody* is going to code that for htem
10:03:01  <planetmaker> of course not
10:03:12  <planetmaker> it needs a freak in order to do so
10:03:33  <andythenorth_> they won't use version control
10:03:35  <planetmaker> someone with dedication and obsession to detail. And enjoyment for coding it
10:03:51  <planetmaker> Dunno. Maybe?
10:04:07  <andythenorth_> any such person would rapidly lose the enjoyment due to the set politics :P
10:04:21  <andythenorth_> although I suppose copying RL exactly is a bit easier than making a playable game
10:04:21  <planetmaker> hehe. *That* is one problem, yes
10:04:37  <planetmaker> copy RL... well
10:05:03  * andythenorth_ wonders how an automated system could work
10:05:11  <planetmaker> But... upload gfx and be done: care to create such web interface?
10:05:35  <andythenorth_> I know approximately how it could be done
10:05:58  <andythenorth_> I don't know how it could be hooked to a CF though
10:06:04  <planetmaker> I guess what could be done, is like an upload interface which allows to specify an id (text only), a name, maybe some stats and upload a template gfx
10:06:09  <planetmaker> And then creates an engine from it
10:06:13  <andythenorth_> yes
10:06:26  <planetmaker> And adds it as a separate NML file to the project repo
10:06:34  <planetmaker> and then it's generated as usual during the nightly runs
10:06:36  *** Guest674 has quit IRC
10:06:39  <andythenorth_> I was thinking: define engines
10:06:40  <planetmaker> maybe possible
10:06:52  <andythenorth_> then allow upload of sprite sheets - one per engine
10:06:59  <andythenorth_> choose which engine a sprite sheet belongs to
10:07:09  <andythenorth_> then run a script which generates the nml
10:07:20  <andythenorth_> hmm, that could commit to a vcs
10:07:37  <planetmaker> Certainly feasible. But not little work to do the web interface right
10:07:42  <planetmaker> yes, it could
10:07:45  <andythenorth_> correction...."sprite sheets - one per livery" (not per engine)
10:08:06  <planetmaker> that's only a 2nd version for the web interface ;-)
10:08:44  <andythenorth_> devzone 'files' doesn't allow a folder hierarchy does it?
10:08:56  <planetmaker> well. *IF* you want to go for that (or someone else), we shall be able to host that
10:09:09  <planetmaker> you mean the 'files' section there?
10:09:12  <andythenorth_> yes
10:09:22  <planetmaker> I don't know really.
10:09:27  <planetmaker> I guess not that much
10:09:32  <andythenorth_> I can't see an option to add folder
10:10:01  <andythenorth_> ach why am I thinking about this?  :P
10:10:04  <andythenorth_> I have enough projects
10:10:25  <andythenorth_> hmm
10:10:37  <andythenorth_> are the fields on tickets customisable per project?
10:10:41  <andythenorth_> they are IIRC
10:11:29  <planetmaker> yes
10:11:55  <andythenorth_> they could use a field to specify which engine a sprite sheet was for, then attach it to a ticket
10:12:07  <andythenorth_> sprite sheets have to all be called same thing
10:12:15  <andythenorth_> then curl / whatever could walk tickets....
10:12:28  <planetmaker> But the web interface you propose would probably really need something new. Dunno, maybe it *could* be integrated, it's all ruby. But... that's even more work
10:12:35  <Yexo> or they could just use one ticker per engine, and add multiple spritesheets as comments
10:12:56  <Yexo> are all there sprite sheets in exactly the same format?
10:13:12  <andythenorth_> if not, they should be excluded
10:13:16  <andythenorth_> coder shouldn't have to deal with that
10:13:42  <planetmaker> That's a problem for the artists then
10:13:46  <Yexo> sounds doable to create a webinterface for that
10:13:51  <andythenorth_> or instead of tickets / forums / custom apps, they could just pm their coder like sensible people....
10:13:57  <planetmaker> it does. It *just* needs doing
10:14:18  <Yexo> which languages are available on the server?
10:14:19  <andythenorth_> :)
10:14:38  <andythenorth_> redmine is ruby
10:14:43  <andythenorth_> python is there?
10:14:48  <planetmaker> at least they need to stop their stupid meta-discussions and on-off-crappy-forum. It seems to be pointless and counter-productive
10:15:03  <andythenorth_> it makes me sad :|
10:15:14  <planetmaker> Yexo, the devzone? Many... as many as redmine supports. Which probably is a lot
10:15:54  <andythenorth_> I could produce the basic system in Zope in about a day with a GUI...but Zope is esoteric
10:16:07  <andythenorth_> django might be more suitable
10:16:21  <planetmaker> oh... those languages ;-)
10:16:26  <Yexo> planetmaker: I was talking about programming languages :)
10:16:33  <planetmaker> just noticed ;-)
10:19:21  *** Webster has joined #openttdcoop.devzone
10:19:24  <planetmaker> in any case you'll have tcl, perl, ruby, python, php
10:19:38  <andythenorth_> give all of BROS one password to login, don't give them individual users?
10:19:54  <Yexo> integrating with the redmine logins would be best
10:20:00  <planetmaker> that'd be nice
10:20:10  <andythenorth_> is this reusable elsewhere?
10:20:17  <andythenorth_> BROS is an edge case in my view
10:20:41  <planetmaker> once such web-grf interface would be done, it'd be picked up in no time, I guess
10:20:43  <andythenorth_> 2CC set was a big collaborative effort?
10:20:48  <planetmaker> not really
10:20:52  <andythenorth_> ah ok
10:20:55  <planetmaker> Just drawing. But coding is DJNekkid
10:21:07  <planetmaker> and drawing mostly Purno
10:21:30  <planetmaker> There were some coders previous to DJNekkid, though. IIRC
10:21:32  <planetmaker> But...
10:21:40  <planetmaker> it's his baby
10:21:43  <andythenorth_> hmm
10:21:44  <Yexo> opengfx is a better example
10:21:54  <planetmaker> that's truely collaborative
10:21:58  <andythenorth_> would the web app push to VCS?
10:22:01  <Yexo> during the actual process of making the final grfs, how many coders were there?
10:22:01  <andythenorth_> that's more complicated
10:22:07  <planetmaker> andythenorth_, it should
10:22:21  <planetmaker> Yexo, in OpenGFX?
10:22:25  <Yexo> yes
10:22:30  <planetmaker> foobar and myself
10:22:38  <Yexo> that's why it worked :)
10:22:50  <planetmaker> Previous, when it was fragmented, there were more, like buttercup and others
10:22:53  <Yexo> you can have many artists on one grf project, but not too many coders
10:23:02  <Yexo> of course you need at least one
10:23:09  <planetmaker> yes. Or you use a VCS and have a good plan
10:23:10  <Yexo> main thing BROS lacks is leadership
10:23:18  <planetmaker> very much so
10:23:35  <planetmaker> and leadership needs to some degree be done by a person taking responsibility by coding
10:23:53  <planetmaker> As that person has to do the job making it alive
10:23:54  <Yexo> not necesarily, but that makes sense
10:24:11  <planetmaker> Ideally it's a collaboration. One lead artist, one lead coder
10:24:15  <planetmaker> my 2ct
10:24:17  <Yexo> one can also do it by writing a plan, create excel sheets with all vehicle properties, etc.
10:24:29  <planetmaker> oh... yes. But...
10:24:34  <planetmaker> often it fails ;-)
10:24:44  <planetmaker> plans need reality-check
10:24:52  *** Guest675 has quit IRC
10:24:56  <planetmaker> that's where you're back to coding
10:25:05  <Yexo> true
10:26:09  <planetmaker> still, it needs not be the main coder
10:27:08  <andythenorth_> I reckon DJ's route is workable....except managing the incoming sprites is a mess
10:27:36  <planetmaker> that's the whole point: it needs *one* person responsible
10:27:42  <planetmaker> and no one wants to
10:28:10  <Yexo> partly that's due to the mess they're already making of their forums
10:28:24  <planetmaker> sure
10:28:43  <planetmaker> audigex is totally right: it needs to become more reliable
10:28:57  <planetmaker> and probably more accessible. I don't understand why tt-forums doesn't suffice
10:29:05  <planetmaker> given the current state of affairs.
10:29:56  <Yexo> either that or the devzone
10:30:00  <andythenorth_> they need to 'organise'
10:30:03  <andythenorth_> apparently
10:30:11  <andythenorth_> that's why they need their own forums
10:30:15  <andythenorth_> to keep track of all the work
10:30:31  <Yexo> with tickets at the devzone they could also keep track of their work
10:31:01  <planetmaker> well. It all has been told and offered to them. Not once but several times.
10:31:44  <andythenorth_> hmm
10:31:54  <andythenorth_> with png the sprites in the repo become web-browsable
10:31:59  <andythenorth_> I knew png was important :)
10:32:04  <andythenorth_> they should just use vcs
10:32:10  <planetmaker> and as it's obscure of what even the graphical side looks like, it's not even inviting to coders to step up and say "I'll do it"
10:33:54  <Brot6> NewGRF Meta Language - Feature #1729 (New): reading patch variables (Hirundo) @
10:34:27  <andythenorth_> with png, they should just vcs
10:34:58  <andythenorth_> they can organise in directories by vehicle
10:35:09  <Yexo> Hirundo: watch out for those variables with "bit switch" as value
10:35:12  <andythenorth_> if they don't want to learn vcs, they pm someone else, or their work is excluded
10:35:25  <Yexo> those probably need to be split in multiple bool variables
10:37:03  <Hirundo> Yexo: I'm only planning to support (for now) what openttd supports
10:37:10  <Yexo> ok :)
10:48:02  <Ammler> [12:14] <Yexo> which languages are available on the server? <-- everything you need/want
10:48:23  <andythenorth_> hmm
10:48:36  <andythenorth_> when I try to view a png like this
10:48:38  <Webster> Title: I HAZ #KittenCamp | Rubber Republic (at
10:48:40  <andythenorth_> hmm wrong link :P
10:48:45  <andythenorth_>
10:48:57  <andythenorth_> ^ my browser downloads that rather than rendering it
10:49:14  <Yexo> same for me
10:49:19  <Ammler> django is setup in 2 mins :-)
10:49:37  <andythenorth_> is that some kind of file header issue?
10:49:50  <Yexo> Content-Disposition: attachment; filename="road_vehicle_templates_3-8.png"
10:52:38  <Ammler> [12:22] <planetmaker> foobar and myself <-- how much need someone to code to be counted?
10:53:35  <planetmaker> good question :-)
10:53:48  <planetmaker> I know that both foobar and myself were not the only ones. And that is good
10:54:18  <Ammler> <-- might say more
10:54:50  * planetmaker hugs Ammler 
10:55:13  <Ammler> still reading backlog... :-P
10:55:40  <planetmaker> Maybe my memory is wrong, but I *thought* that you mostly started contributing after 0.1.x
10:57:35  <planetmaker> I'm wrong :-(
10:58:18  <Ammler> I just meant, that ogfx is coded at least by more than 2, also don't forget the "bulkcoder" Rubi
10:59:46  <planetmaker> Ammler, it was not a comprehensive list. And doesn't reflect current status or overall contributions
10:59:56  <planetmaker> I was referring to the time of the 0.1.x releases
11:00:08  <planetmaker> up to 0.2.0
11:00:50  <planetmaker> Neither foobar initially or myself later as the 'maintainers' could have done all that ourselves.
11:02:17  <planetmaker> but even from r0:273 you had more commits than foobar :-)
11:02:22  <Ammler> also the Redmine does also supply Forums, I told that to Bros already too
11:02:53  <Ammler> as their Forums were down
11:04:35  <Ammler> andythenorth_: I reported that already to redmine, I would like a "preview" beside download in the repository view
11:04:53  <Ammler> but you could use for direct view already
11:05:06  <andythenorth_> ooh
11:05:40  <andythenorth_> shiny
11:05:41  <andythenorth_>
11:07:31  <Ammler> replace the rev hash with tip
11:07:40  <Ammler> if you publish the link
11:08:41  <Ammler> (if you like) :-)
11:09:25  <Ammler> the templates are not really very verbose
11:09:53  <Ammler> I would comment those more, if you like others to use them to contribute
11:10:28  <planetmaker> <-- opengfx stats by author. Some are doubled due to not caring enough about the script
11:11:34  <planetmaker> --> pm: 361, Ammler: 124,  FB: 46, Rb: 17, bilbo: 4, EdorFaus:1
11:11:58  <planetmaker> and one ottdc@mozart which also was Ammler ;-)
11:12:43  <Ammler> amount of changes count :-)
11:13:13  <planetmaker> well, yes and no
11:13:19  <Ammler> indeed :-)
11:13:45  <planetmaker> If I now were to remove all hard-coded sprite numbers I'd immediately have a commit which touches every sprite, but how many changes is that?
11:14:38  <Ammler> like rubis bulk update to png
11:14:48  <planetmaker> yeah
11:15:48  <Ammler> we should rather hardcode every sprite number then remove :-)
11:15:59  <planetmaker> true :-)
11:16:03  <planetmaker> except in extra
11:16:19  <Ammler> at least that is what I do on sprites I change now
11:16:37  <Rubidium> Ammler: bulkcoder?
11:16:57  <Ammler> isn't that a nice job description?
11:16:59  <planetmaker> that's the person who wrote the code for the bulk wagons and trucks, right?
11:17:24  <Rubidium> I doubt that
11:17:29  <Ammler> :-D
11:17:42  <Rubidium> or at least, I doubt I coded them
11:17:56  <planetmaker> ;-)
11:18:17  <Rubidium> I did some boxed houses
11:18:32  <planetmaker> :-)
11:18:51  <planetmaker> I was missing some similies ;-)
11:20:17  <Rubidium> oh, and I removed a load of white pixels
11:20:50  <planetmaker> and replaced every single graphics file by your own version...
11:21:01  <Ammler> all the tedious bulk work :-P
11:21:03  <Rubidium> and a number of translation
11:22:34  <Ammler> you have almost as much changes as pm with a twentieth of commits
11:22:51  <planetmaker> :-)
11:25:39  <Brot6> 2cc train set - Feature #1730 (New): Washington 7000 (Voyager1) @
11:25:40  <Brot6> 2cc train set - Feature #1730: Washington 7000 (Voyager1) @
11:25:58  <Ammler> also a good example for contribution ^
11:27:35  <planetmaker> of course ;-) But we talked about coding back then -.-
11:27:55  <Rubidium> where most was just a simple "find . -iname "*\..nfo" | xargs sed s/pcx/png/g -i"
11:28:12  <Rubidium> and an automated image conversion
11:29:03  <Ammler> isn't grfcodec able to mix pcx and png as source?
11:29:12  <Rubidium> yes
11:29:33  <Ammler> but nml is?
11:29:33  <planetmaker> Ammler, but the repo is nicer to handle now
11:29:37  <Rubidium> only 2 lines of that change were manual
11:29:38  <planetmaker> NML can also do both
11:30:07  <Ammler> well, at least you can now link the sources nicely
11:30:29  <planetmaker> exactly. And also when I just search a sprite I don't need gimp but can use the file system browsers
11:30:37  <Ammler> does it have some palette sanity?
11:30:39  <planetmaker> my previews don't read pxc, but both png
11:31:13  <Ammler> what happens with rgb pngs?
11:31:21  <planetmaker> rejected
11:31:50  <Ammler> so you might still need to convert
11:32:22  <planetmaker> you cannot automatically assume any palette. It's not feasible
11:32:34  <Rubidium> not if the initial template is using the correct palette
11:32:38  <Ammler> yeah, might need a nfo flag
11:33:37  <Ammler> goal is to support 32bpp too?
11:34:17  <Rubidium> not directly
11:34:54  *** V453000 is now known as Guest684
11:35:41  <planetmaker> Ammler, the artists still need to chose the correct palette
11:35:55  <planetmaker> As the conversion rules might differ
11:37:04  <Ammler> what I still wonder is, if it is still worth to support the different palettes (dos and windows)
11:37:41  <Yexo> yes
11:37:52  <Ammler> advantage?
11:38:04  <Rubidium> DOS palette is better
11:38:13  <Yexo> the dos palette has more useable colors, so it's arguable the "best" palette, but windows ttdpatch can only use the windows palette
11:38:19  <Ammler> then why not withdraw windows?
11:38:34  <Ammler> and convert to windows on need
11:38:40  <Yexo> and nobody uses the dos version of ttdpatch anymore, so all ttdpatch users can only use the windows palette
11:38:51  <Rubidium> Yexo: roboboy?
11:38:53  <Yexo> converting dos to windows can't be done without loss of some colors
11:39:16  <Yexo> s/nodoby/almost nobody/ s/all/almost all/
11:39:59  <Ammler> yexo, you think someone is able to determine the lost colors?
11:40:21  <Yexo> probably not :)
11:40:28  <Rubidium> Ammler: point is that most NewGRFs don't set their palette (A14) yet
11:40:41  <Rubidium> and most NewGRFs are Windows paletted
11:40:45  <Yexo> Ammler: still, most newgrf currently use the windows palette
11:40:58  <Ammler> no a14=windows
11:40:58  <planetmaker> even if - for reverse operation grfcodec needs to retain the capability to handle both palettes
11:41:03  <Rubidium> going straight to the DOS palette will make a mess of things, especially in 1.x
11:41:12  <Rubidium> s/x/0.x/
11:41:13  <Yexo> dropping support for it in nml/grfcodec would force a lot of projects to convert their graphics, so it'll only mean they'll keep working with an older grfcodec version instead
11:42:12  <planetmaker> next big change: convert OpenGFX windows -> dos palette ;-)
11:42:17  <Rubidium> having said that, OpenTTD's base graphics are only provided in the DOS palette
11:42:45  <planetmaker> but only for like 4 weeks or so ;-)
11:43:24  * Ammler votes for renaming dos palette to something like default/standard/full palette
11:43:34  <Ammler> and windows to reduced
11:43:43  <Rubidium> planetmaker: more towards 12 weeks
11:43:57  <planetmaker> that long? Time surely flies
11:44:19  <Rubidium> last week I changed the PCX files to the DOS palette though
11:44:23  <Ammler> well, we could already convert to dos
11:44:32  <Ammler> and still release a win grf
11:44:45  <Rubidium> Ammler: that's certainly possible
11:44:52  <Ammler> since our pngs are based on windows, we wouldn't lose something
11:44:59  <planetmaker> indeed
11:45:15  <planetmaker> that makes good sense
11:45:55  <Ammler> Rubidium: it would make the difference and reason why we keep dos more verbose
11:46:21  *** KenjiE20 has joined #openttdcoop.devzone
11:46:23  <Ammler> now, dos sounds like old/worse palette
11:47:56  <planetmaker> at least that's a common misconception, yes
11:48:24  <planetmaker> "I'm on windows, why should I use DOS palette" ;-)
11:48:26  <Rubidium> I don't think it'll get much better to rename stuff in TTDP
11:48:35  <Rubidium> s/TTDP/grfcodec/
11:48:55  <Ammler> you can still alias dos and windows
11:49:10  <planetmaker> they have no name there, but just numbers
11:49:11  <Rubidium> as the specs are still littered with DOS/Windows and then the question is what's the reduced palette? Windows or DOS?
11:49:47  <Ammler> on the other side, openttd doesn't care about palette anymore (or will)
11:49:50  <Rubidium> adding a bit of explanation to -p ? might be okay though
11:50:56  <Rubidium> as that just keeps the current stuff alive and adds a bit of explanation, e.g. DOS TTD (most consistent palette with most unique colours)
11:51:11  <Rubidium> Windows TTD (inconsistent with less unique colours)
11:51:55  <Ammler> at least grfcodec uses dos as default
11:52:23  <planetmaker> sounds quite good, yes
11:52:56  <planetmaker> do we have a DOS TTD palette file for gimp somewhere? It's missing on the devzone docs
11:53:03  <Rubidium> in any case, adding A14 to NewGRFs should be the first step
11:53:27  <Ammler> planetmaker: I made those, could do the dos versions too...
11:54:01  <planetmaker> Ammler, that'd be most appreciated
11:54:03  <Ammler> but we also need the photoshop version
11:54:10  <Rubidium> then, once A14 capable OpenTTDs are common use one could consider changing OpenTTD's default
11:54:12  <planetmaker> that's a task for andy
11:54:24  <Rubidium> although... the default is currently: "whatever the base set uses"
11:54:43  <planetmaker> yeah... that *could* be windows, I guess
11:54:47  <Ammler> Rubidium: that should change to "no a14=windows)
11:56:12  <Rubidium> maybe, but even then that default change will be 1.1.0 material
11:56:18  <Yexo> Ammler: why? most people have a windows base set anyway
11:56:33  <Yexo> and those that have a dos base set have already been collecting dos palette grfs where possible
11:56:34  <Rubidium> Yexo: because they want to change the palette of OpenGFX
11:56:34  <Ammler> yexo, because we plan to convert ogfx to dos
11:56:50  <Yexo> oh, right
11:57:30  <Rubidium> in any case, changing the palette of the 5 base GRFs before say the september 2011 release isn't going to be that nice
11:57:46  <Rubidium> given the amount of "lag" some people seem to have with updating OpenTTD
11:58:25  <Rubidium> and the same holds for the extra GRF, as that needs A14 awareness of OpenTTD (at least if the palette differs)
11:58:29  <Yexo> but those people don't update opengfx either, right?
11:58:35  <Ammler> well, there is no hurry anyway, as we don't have dos contributions
11:59:09  <Rubidium> Yexo: updating opengfx is easier, as it's just pressing upgrade in the content download
11:59:33  <Yexo> true, but you can set the minimum version to 1.1 so 1.0 users won't be able to update that easily
11:59:37  *** Levi has joined #openttdcoop.devzone
11:59:47  <Rubidium> hmm, that's also true
12:00:04  <Yexo> that still breaks things for people with multiple versions, but after 1.1 is released that shouldn't be a problem anymore
12:00:17  <Ammler> openttd needs check for update itself :-)
12:01:10  <Rubidium> so it'd be something for the March 2011 release, i.e. conversion over/just before Christmas (assuming a December release)
12:01:13  <planetmaker> Ammler, it complains, if sprites are missing. So it "just" needs some new gui sprite...
12:01:31  <Ammler> for ogfx, I meant openttd
12:01:49  <Yexo> Rubidium: I'd say after the stable is released, otherwise people test beta1, update opengfx, play multiplayer with 1.0.x and have the wrong colors
12:01:53  <planetmaker> Hell, no, Ammler !
12:02:20  <planetmaker> Then we'll have a legacy game with OpenTTD 1.1.3 for game #300 and all clients complain to be outdated?!
12:02:20  <Brot6> planetmaker: #300 is "FIRS Industry Replacement Set - Bug #300: Unexpected sprites - #openttdcoop Development Zone"
12:03:05  <SmatZ> planetmaker: it could warn only once for each new version
12:03:26  <planetmaker> I've seen here in the lab with software which requires updates. The result was that it turned out to become unusable - jointly with the hardware which we used it for :-(
12:03:37  <Rubidium> Yexo: it'd be more RC3 vs stable
12:04:04  <Rubidium> as the conversion should happen after the December release
12:04:04  <Ammler> well, then a simple button "check for newer version"
12:04:19  <Rubidium> that's called multiplayer :)
12:04:23  <planetmaker> that's more like what would be nice, Ammler
12:04:44  <Rubidium> if (servers_with_your_version < threshold) echo "you need to update!";
12:04:58  <Yexo> Rubidium: but if the conversion happens in december, users will have problems until the servers switch to 1.1, wich won't be until after the stable is released
12:05:08  <Ammler> maybe that button could then also close openttd and start updater to download and install the new version
12:05:13  <planetmaker> Rubidium, indeed it could check the finger page or so
12:05:23  <Rubidium> Yexo: only users that use OGFX nightlies
12:05:50  <Yexo> agreed ;)
12:05:50  <planetmaker> on request
12:06:01  <Rubidium> as, as I said before, the December release should be *before* the conversion
12:06:13  <Yexo> that just means that there should be no upload of ogfx to bananas between the conversion and the openttd stable release
12:06:31  <Ammler> well, if we do a conversion now, we would still make ogfx with -m
12:06:32  <planetmaker> just a version-limited ;-)
12:06:33  <Rubidium> well, besides the late march release
12:07:04  <Yexo> I thought with "the december release" you were talking about openttd 1.1-beta1
12:07:07  <Yexo> now it all makes sense
12:07:21  <Rubidium> say, around 25th of March limited to 1.1 trunk or later
12:08:19  <planetmaker> Yexo, opengfx should use a ~2 week head time to those releases.
12:08:36  <planetmaker> Makes for somewhat better exposure of those updates
12:09:33  * Rubidium is still pondering a release date for GRFCodec 5.1.0
12:09:57  <Ammler> the problem with converting ogfx to dos is that all the sources (gimp/ps) are still based on windows
12:10:05  <Rubidium> and whether to go with quarterly releases from then
12:10:16  <Ammler> not same easy step as pcx->png
12:12:04  <Rubidium> guess 12-01, 03-01, 06-01, 09-01 would make some sense
12:12:49  <Rubidium> so ~2 weeks before OpenGFX, then another ~2 weeks till "major" OpenTTD releases in case of December/March
12:14:00  <Yexo> I was wondering whether grfcodec would need so many updates, but I forgot about nforenum
12:15:24  <Ammler> for nfo is the question, is it still able to handle dat files updates only?
12:15:37  <Ammler> if so, maybe it could automatically download those
12:16:41  <Ammler> else you should drop data dir .nforenum
12:17:54  <Rubidium> it generally can use updated data files, not always though
12:18:15  <Ammler> should be a reason for a release ^
12:18:16  <Rubidium> and adding automatic downloads in such a small package is kinda TMWFTLB
12:19:03  <Rubidium> having said that, making the .nforenum directory is in 99% of the times not needed. So making that "feature" optional might be a good thing
12:20:28  <Ammler> yes, only creating home data, if .nforenum is there
12:21:36  <Ammler> is nforenum able to work without?
12:22:08  <Rubidium> most likely, I'd say
12:26:14  <Yexo> I think currently not, but rewriing it so it doesn't need it is doable
12:38:00  <Brot6> NewGRF Meta Language - Feature #1729 (Closed): reading patch variables (Hirundo) @
12:38:00  <Brot6> NewGRF Meta Language - Revision 916:ca00363fd131: Feature #1729: Support reading various 'patch v... (Hirundo) @
12:38:00  <Brot6> NewGRF Meta Language - Revision 917:caa06e0d733b: Doc #1729: Document the new patch variables. (Hirundo) @
12:38:01  <Brot6> NewGRF Meta Language - Revision 918:d500870cd430: Add: Some special variable accesses to the regr... (Hirundo) @
12:38:05  <Brot6> NewGRF Meta Language - Feature #1729 (Closed): reading patch variables (Hirundo) @
12:47:36  *** Levi has quit IRC
12:55:43  <Yexo> nice work Hirundo :)
13:07:02  *** andythenorth_ has quit IRC
13:21:03  <Brot6> #openttdcoop - ttd-newgrf-dos.gpl (yexo) @
13:34:14  *** andythenorth_ has joined #openttdcoop.devzone
14:25:31  *** Webster has joined #openttdcoop.devzone
14:29:42  *** Guest703 has quit IRC
14:43:10  *** Webster has joined #openttdcoop.devzone
14:47:12  *** Guest704 has quit IRC
15:08:54  *** frosch123 has joined #openttdcoop.devzone
15:29:51  *** Webster has joined #openttdcoop.devzone
15:32:56  *** Guest714 has quit IRC
15:36:26  *** Webster has joined #openttdcoop.devzone
15:39:32  *** Guest716 has quit IRC
15:48:36  *** Webster has joined #openttdcoop.devzone
15:54:06  *** Guest718 has quit IRC
16:12:13  *** Webster has joined #openttdcoop.devzone
16:16:22  *** Guest720 has quit IRC
16:19:42  <Brot6> firs: update from r1481 to r1482 done (1 errors) -
16:20:22  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r635), 32bpp-extra (r39), ai-admiralai (r71), airportsplus (r64), basecosts (r22), belarusiantowns (r7), comic-houses (r71), fish (r404), frenchtowns (r4), grfcodec (r785), heqs (r473), indonesiantowns (r37), manindu (r5), metrotrackset (r56), newgrf_makefile (r220), nml (r918), nutracks (r117), ogfx-trains (r85), ogfx-trees (r41), opengfx (r553), openmsx (r97), opensfx (r97),
16:20:22  <Brot6> smts (r19), snowlinemod (r45), swedishrails (r187), swisstowns (r20), transrapidtrackset (r15), ttdviewer (r26), ttrs (r23), worldairlinersset (ERROR r666)
16:21:47  <Brot6> 2cc train set - Feature #1730: Washington 7000 (DJNekkid) @
16:22:10  <Brot6> indonesiantowns: compile of r37 still failed (#1704) -
16:24:12  <Brot6> swisstowns: compile of r20 still failed (#1705) -
16:24:57  <Brot6> worldairlinersset: compile of r666 still failed (#1725) -
16:24:58  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus, belarusiantowns (3 errors) (Diffsize: 21), frenchtowns (4 errors) (Diffsize: 9), manindu, ogfx-trains (1 errors), swedishrails
17:07:15  *** Webster has joined #openttdcoop.devzone
17:11:50  *** andythenorth_ has joined #openttdcoop.devzone
17:12:02  *** Guest726 has quit IRC
17:17:21  *** DJNekkid has joined #openttdcoop.devzone
17:17:35  <DJNekkid> hi guys!
17:17:58  <Rubidium> ahoy
17:18:22  <planetmaker> holla!
17:21:18  <DJNekkid> andythenorth_: there?
17:27:24  <andythenorth_> hi DJNekkid
17:27:30  <andythenorth_> got a baby in my hands right now
17:27:55  <andythenorth_> j z'/£3
17:28:09  <planetmaker> and it's absolutely right!
17:28:14  <andythenorth_> .k>?/\||||||l}
17:28:20  <andythenorth_> \fqzrçr
17:28:29  <Ammler> indeed :-)
17:28:47  <andythenorth_> if I leave him at the keyboard long enough he'll probably type some valid nfo
17:28:56  <andythenorth_> if disable all but 0-F
17:29:12  <Ammler> you might also let it (she or he?) draw for you some vehicles :-)
17:30:07  <Ammler> oh, him
17:33:48  <andythenorth_> DJNekkid: give me an hour or so
17:34:51  <DJNekkid> hehe, okidoki
17:35:08  <DJNekkid> i've started on a spreadhseet
17:37:00  <andythenorth_> DJNekkid: is the stupid BROS forum backup?
17:37:07  <andythenorth_> I was looking for a tracking table earlier
17:37:50  <DJNekkid> i dont even know the address for it
17:38:15  <DJNekkid> are you british btw?
17:38:46  <DJNekkid> or anyone else ...
17:38:55  <DJNekkid> what is the longest MU in the UK?
17:39:35  <DJNekkid> 20 unit long eurostar?
17:49:45  *** Webster has joined #openttdcoop.devzone
17:49:47  <planetmaker> that is to get the wagon type and properties of the N-5th wagon or so?
17:50:57  <DJNekkid> i didnt know you could, but i know its possible, not tried yet, but i have the code in my head :P
17:51:40  <planetmaker> hm...
17:51:56  <planetmaker> with arbitrary wagons in the train?
17:51:58  <DJNekkid> or did i missunderstand you?
17:52:23  <andythenorth_> pikka does it
17:52:36  <DJNekkid> the code would be rather long tho...
17:52:43  <planetmaker> engine-coal-coal-ore-ore-mail
17:52:52  <planetmaker> mail-ore-ore-coal-coal-engine
17:52:57  <planetmaker> graphicswise after turning
17:53:02  <DJNekkid> gfx wise it is
17:53:30  <planetmaker> I'd write it in NML, but I don't care about the length, but I must have missed so far the how
17:54:02  <DJNekkid> as it needs to have a gfx override for every wagon
17:54:04  <planetmaker> as I need to know the wagon type of the N-x'th vehicle when determining the look of the x'th vehicle
17:54:15  <DJNekkid> not nth, last
17:54:16  <planetmaker> hm... livery override?
17:54:19  <DJNekkid> yes
17:54:30  <planetmaker> feasable, I guess
17:54:41  <DJNekkid> only way as far as i can see
17:54:57  <planetmaker> I override it with the usual graphics...
17:55:06  *** Guest731 has quit IRC
17:55:22  <DJNekkid> and then you need a var2 variable *check*
17:55:24  <planetmaker> but how do I know in the above example, for the 1st coal wagon that it then shall look like an ore one, if turned?
17:55:33  <planetmaker> which var?
17:55:56  <DJNekkid> var2 variable Ff
17:56:22  <Rubidium> andythenorth_: I take it Shinkansens aren't modern then :)
17:56:29  <DJNekkid> in the action3?
17:56:31  <planetmaker> ff?
17:56:51  <planetmaker> Rubidium: Britain ;-)
17:56:57  <DJNekkid> well, vehicle specific (80+x) variable Ff
17:56:59  <planetmaker> Not countries with modern trains
17:57:06  <Rubidium> andythenorth_: those are generally 16 units long, though some "stopper" services are only 8 long
17:58:11  <planetmaker> hm... modflags
17:58:16  <DJNekkid> bit8
17:59:08  <planetmaker> yes, that I know
17:59:21  <planetmaker> But I don't know how to access know which graphics to draw
17:59:42  <DJNekkid> in nfo or nml?
17:59:43  <Yexo> var 40 in combination with var C6 ?
18:00:05  <Yexo> it'll be quite ungly though :(
18:00:13  <planetmaker> I'm now at the 2nd vehicle, reversed. It's a coal wagon.
18:00:31  <planetmaker> Yexo: that's as far as I got. But... I can only access the engine or the wagon itself. Not another wagon
18:00:36  <planetmaker> or?
18:00:37  <DJNekkid> Yexo: no, var FF in combination with with 40 and action3/liver override
18:00:55  <DJNekkid> there you can select what ID to iverride
18:01:01  <DJNekkid> *override
18:01:02  <Yexo> DJNekkid: so how would you reverse ABBCD to DCBBA ?
18:01:14  <Yexo> ABBBB to BBBBA I can see
18:01:21  <DJNekkid> oh, yea ...
18:01:43  <planetmaker> I'm talking about the first example, yes
18:01:52  <DJNekkid> then every wagon need to override everything, basicly :P
18:02:00  <DJNekkid> if turned
18:02:39  <DJNekkid> i was thiking more E-xxxxx-W to W-xxxxx-E
18:02:41  <planetmaker> DJNekkid: I'd not have a problem with that either
18:02:51  <planetmaker> everything overriding everything else
18:03:06  <DJNekkid> but hmmm
18:03:07  <Yexo> I don't see how that helps htough
18:03:08  <planetmaker> But I need a way to know which graphics to chose
18:03:48  <DJNekkid> nfo or nml?
18:03:54  <Yexo> doesn't matter
18:03:55  <andythenorth_> what madness are you perpetrating :P
18:03:57  <andythenorth_> ?
18:03:58  <Yexo> both can be rewritten to eachother
18:04:03  <planetmaker> what I'd basically need is the access to the other wagons like I can for the random bits
18:05:08  <DJNekkid> planetmaker: the EXTRA hard bit is that wagons with different gfx for different loading stages WILL change their gfx to whatever the other wagon have
18:05:21  <planetmaker> hu?
18:05:41  <planetmaker> I need the same amount of loading stages, hm, yes
18:05:50  <planetmaker> can be helped. All get four then
18:05:50  <DJNekkid> lets say: engine-30%-100%-50%
18:05:52  <Yexo> DJNekkid: true, but you can implement the "amount loaded gfx" in varaction2 instead of action3
18:06:04  <planetmaker> or that :-)
18:06:18  <Yexo> same amount of loading stages doesn't help, the engine is always empty (or full?)
18:06:32  <planetmaker> hm, yes
18:06:34  <DJNekkid> but wagon3 might not have the same fullness as wagon2
18:06:35  <Yexo> but also for that you need access to variables from other wagons
18:06:50  <planetmaker> DJNekkid: yes, but that switch can be the last one
18:06:55  <planetmaker> so it applies to the graphics
18:07:06  <planetmaker> and not before the choice for the particular graphics branch is made
18:07:13  <planetmaker> wagon->load amount->graphics
18:09:03  <DJNekkid> hmmmmm
18:09:52  <Yexo> so what you need is type 84 but for varaction2
18:10:01  <planetmaker> we can assume that I can display the right load amount, IF I know the cargo type to display at the n'th position
18:10:05  <Yexo> access the variables of any engine in the consist
18:10:15  <planetmaker> or vehicleID rather than cargo type
18:10:20  <Brot6> 32bpp-ez-patches: update from r21038 to r21040 done -
18:10:31  <planetmaker> basically yes, that's what I'd like :-)
18:11:02  <Yexo> after looking at the specs and code I'm quite sure there is currently no way to do what you want
18:11:02  <planetmaker> I'm still not sure that my conclusion "not yet possible" is right, but I'm somewhat sure.
18:11:30  <planetmaker> so I thought I give a neutral shot for one of the trainset coders ;-)
18:11:56  <planetmaker> anyway, thanks both of you :-)
18:12:53  <DJNekkid> planetmaker: tbh, it _might_ be possible, but MOST likely TMWFTLB
18:13:25  <Yexo> DJNekkid: I'm very interested if you can think of a way how it would be possible, even if it's a lot of work
18:13:32  <planetmaker> ^^
18:13:50  <Yexo> I don't need the actual code, just a global outline of which variables to use
18:14:35  <planetmaker> same here :-)
18:14:39  <planetmaker> concept is all I need
18:16:37  <DJNekkid> hmmmm
18:19:17  <Brot6> clientpatches: update from r21038 to r21040 done -
18:20:40  <Brot6> serverpatches: compile of r21040 still failed (#1658) -
18:22:44  <DJNekkid> how many possible liveries can there be in that bros-set?
18:30:34  <Yexo> do the TTDX/OTTD object classes make any sense at all? (from )
18:33:53  <andythenorth_> DJNekkid: a *lot*....I think that's there main objective
18:34:02  <andythenorth_> there / their /s
18:34:48  <DJNekkid> well, how many is _alot_
18:34:57  <DJNekkid> and how many should one train be able to support?
18:35:26  <andythenorth_> dunno
18:35:30  <planetmaker> Yexo: they don't. And it was already stated during design of the objects that it is absolutely not needed
18:35:34  <andythenorth_> DJNekkid why don't we ask in the thread :)
18:35:38  <planetmaker> someone just missed that ;-)
18:35:43  <Yexo> ok, I thought so
18:35:48  <DJNekkid> andythenorth_: i tried earlier today
18:35:49  <andythenorth_> DJNekkid if their stupid forum was up we could try and look there :P
18:36:00  <Yexo> "someone" = wallyweb
18:37:01  <DJNekkid> but its not :P
18:37:25  <andythenorth_> welshdragon: hi hi
18:37:38  <planetmaker> yes... dunno why he need(s|ed) those
18:38:04  <DJNekkid> andythenorth_: i might have some of them on msn
18:38:18  <andythenorth_> try them :)
18:38:54  * planetmaker wishes you two good luck. And I mean it without irony
18:39:31  <planetmaker> anyway... Irish Pub night. catch you later
18:39:32  <andythenorth_> we'll suffer for this I swear :|
18:40:38  <planetmaker> as long as "results enjoyment factor - needed suffering > 0" everything is ok
18:41:24  <DJNekkid> andythenorth_: we probably will, but either way, as he saied :P
18:41:41  <DJNekkid> but neither of the ones i thought might have been on msn werent bros guys
18:45:43  <DJNekkid> and their darn forum is down, again
18:45:49  *** thgergo has joined #openttdcoop.devzone
18:47:23  <DJNekkid> i'll try startrek online while i wait for an awnser :D
18:58:21  <Hirundo> I'm pretty sure that proper shunting is not possible unless you either a) restrict the wagons that can be attached or b) make changes to OpenTTD/specs
18:59:51  <Yexo> and even in that case the shunting will only work properly if all wagons are from the same newgrf
19:01:58  <Hirundo> Indeed, although enforcing that via CB 1D is not too unreasonable
19:02:30  <Brot6> NewGRF Meta Language - Revision 919:8425b7790882: Doc: finish documenting the properties for objects (yexo) @
19:04:29  <Yexo> how are we going to handle town zones?
19:04:50  <Hirundo> what needs handling there?
19:05:14  <Yexo> currently we have constants TOWNZONE_EDGE etc. which are bit numbers for the house property
19:05:48  <Brot6> NewGRF Meta Language - Feature Request #1555: Explicitly define callbacks (Hirundo) @
19:07:40  <Hirundo> Is there anything that needs to be changed? I know almost 0 about houses / objects and their vars/props
19:07:48  <Yexo> but for the object town_zone variable we need them enumerated from 0, not 8
19:08:15  <Yexo> currenty the values are 8, 9, 0x0A, 0x0B, 0x0C, which is fine for the house property
19:08:30  <Yexo> planetmaker: would changing them to 0 and documenting that for houses be ok with you?
19:09:12  <Yexo> availability_mask = bitmask(TOWNZONE_EDGE, CLIMATE_SNOW); <- that is currently valid, and would have to be changed to:
19:09:39  <Yexo> availability_mask = (bitmask(TOWNZONE_EDGE) << 8) | bitmask(CLIMATE_SNOW);
19:12:03  <Hirundo> hmm
19:13:16  <Yexo> alternatively we could change the town_zone variable for objects and industries (and more?) so we add 8 to it before using it
19:13:48  <Hirundo> Could you remove TOWNZONE_ALL from the docs, as far as I can see it doesn't exist
19:13:51  <Yexo> that way the user won't notice that it's 8..0x0C instead of 0..4 as long as he uses the given constsants
19:14:01  <Yexo> no, it should be added to the code instead
19:14:16  <Hirundo> bitmask (TOWNZONE_ALL) will never work
19:14:29  <Yexo> ok, it depends on what we're going to do with the townzone_ values
19:24:41  <Yexo> make the town zone variables start at 8 instead of 0
19:25:03  <Yexo> with this change I'll leave the TOWNZONE_* constants as they are, and juse remove TOWNZONE_ALL from the documentation
19:25:34  <Yexo> any problems with that?
19:29:06  <Hirundo> no, go ahead
19:30:27  <Yexo> meh, actually the house_availability_mask is fucking already with those values ;(
19:30:52  <Yexo> TOWNZONE_EDGE is actually bit 0 for that property, not bit 8
19:31:06  <Yexo> but in nml it's bit 8 so the "normal" climate bits work
19:31:39  <Yexo> so my proposal is: throw away the code I've just written and change the definition of those townzone constants
19:31:54  <Yexo> drawback is that the documentation for the house availability mask becomes a bit more ugly
19:31:55  <Hirundo> Why wouldn't the aforementioned stuff work?
19:32:05  <Yexo> it does, but it's ugly
19:32:19  <Hirundo> At least the idea of mapping 'fake' town zones to 'real' ones, without showing it to the user
19:32:44  <Yexo> in nfo townzone_edge is always 0 (or bit 0, townzone_outskirt is 1 (or bit 1), townzone_outer_suburb is 2 (or bit 2)
19:32:58  <Yexo> why would we change that in nml so it's 8 (bit 8), 9 (bit 9) etc. ?
19:33:14  <Hirundo> to make the user happy :)
19:33:44  <Yexo> a better solution imo is to make the availability_mask for houses an array with two values, like this:
19:34:07  <Yexo> availability_mask = [bitmask(TOWNZONE_+EDGE< TOWNZONE_OUTSKIRT), bitmask(CLIMATE_TEMPERATE)]
19:34:20  <Hirundo> that might be cleaner for us :)
19:34:42  <Yexo> and it results in cleaner nfo code (not add 8 every time town_zone is used)
19:35:29  <Hirundo> offtopic: given a vector (2D) equation r1 + r2 = c, with the magnitudes of r1 and r2 known. How to solve for r1/r2?
19:39:28  <SmatZ> define /
19:39:54  <Hirundo> >	offtopic: given a vector (2D) equation r1 + r2 = c, with the magnitudes of r1 and r2 known. How to solve for r1 and r2?
19:40:09  <SmatZ> oh sorry :)
19:40:14  <SmatZ> r1 = c - r2 ?
19:40:54  <SmatZ> supposing it's "summing n-th item of r1 with n-th item of r2 gets n-th item of c"
19:40:56  <Yexo> SmatZ: not possible, r2 is not known, only |r2|
19:41:00  <Yexo> at least if I get the question right
19:41:24  <Hirundo> |r1|,|r2| are known, their directions not
19:41:32  <Yexo> and C is also known?
19:41:36  <Hirundo> yes
19:41:47  <SmatZ> ok :)
19:42:00  <SmatZ> I really misunderstood the question
19:42:11  <SmatZ> (I didn't know what "magnitude" is)
19:43:13  <SmatZ> so, you know:
19:43:17  <SmatZ> a + b = c
19:43:19  <SmatZ> where
19:43:29  <SmatZ> a1^2 + a2^2 = |r1|
19:43:34  <SmatZ> b1^2 + b2^2 = |r1|
19:43:36  <SmatZ> *r2
19:43:42  <Hirundo> exactly
19:43:48  <SmatZ> a1 + b1 = c1
19:43:50  <SmatZ> a2 + b2 = c2
19:44:08  <SmatZ> a1 = c1 - b1
19:44:14  <SmatZ> then insert into the first equation
19:44:20  <SmatZ> hmm
19:44:22  <SmatZ> nah
19:44:24  <SmatZ> :)
19:44:43  <SmatZ> or
19:44:44  <SmatZ> yes
19:44:54  <Hirundo> I guess, it needs either radicals or sines/cosines, neither of which is funny or non-laborsome
19:45:12  <SmatZ> (c1 - b1) ^ 2 + (c2 - b2) ^ 2 = |r1|
19:46:11  <Hirundo> b1 = sqrt(|r1|^2 - b2^2) and insert that into the first
19:48:41  <SmatZ> as long as b2 <= r1 :)
19:49:05  <SmatZ> maybe better write that as general solution to quadratic equation
19:49:27  <frosch123> Hirundo: you are dealing with a triangle. so yes get the school geometry book, compute the angle for the triangles given the three lengths, and then apply the angles to c
19:49:43  <Hirundo> law of sines / cosines?
19:51:21  * SmatZ never liked analytic geometry :-x
19:51:24  <SmatZ> or geometry at all :)
19:52:09  <frosch123> Hirundo: yes, law of cosines should do
19:57:57  *** Levi has joined #openttdcoop.devzone
20:01:26  <andythenorth_> DJNekkid: for BROS - I am thinking of organising their sprites strictly into folders by vehicle type
20:01:31  <andythenorth_> does that suit you?
20:16:41  <Yexo> what is the point of object var 60?
20:17:05  <Yexo> either it returns 0xFFFF (no objec tile or part of another object) or it returns the local id
20:17:16  <Yexo> but the local id is already known (after all, you're writing the grf)
20:17:57  <Yexo> basically it's an "is that tile part of this object" check, but you also already know that (because you know the size and current location of the tile)
20:24:22  <frosch123> sounds like there is currently not much point in it :)
20:24:29  <Rubidium> you can check nearby tiles with that so two objects somewhat interact
20:24:33  <frosch123> too many fools sitting around a green table
20:24:56  <Yexo> Rubidium: but it returns 0xFFFF in case the nearby tile is part of another object
20:25:13  <Yexo> if (!IsTileType(tile, MP_OBJECT) || GetObjectIndex(tile) != oid) return 0xFFFF;
20:25:27  <Rubidium> hmm, good point
20:25:32  <Rubidium> no idea then?
20:25:53  <Yexo> the return 0xFFFE; is never reached I think
20:36:03  *** frosch123 has quit IRC
20:46:23  *** Lakie has joined #openttdcoop.devzone
20:52:12  <Brot6> NewGRF Meta Language - Revision 920:c3f2e621421b: Change: house property available_mask is now an... (yexo) @
20:52:12  <Brot6> NewGRF Meta Language - Revision 921:366dc0aacfae: Doc: object 0x60+x variables (yexo) @
20:52:12  <Brot6> NewGRF Meta Language - Revision 922:442bbba2026b: Add: list of tile classes (yexo) @
20:53:15  <Yexo> Lakie: do you already have some objects coded in nml that I could use as regression test?
20:53:38  <Lakie> Only a basic object, which uses base gra[hics
20:54:18  <Yexo> currently we have nothing, so it'd be great if we could use that :)
20:54:22  <Lakie> I could probably write more advanced ones given some time.
20:55:26  <Lakie>
20:56:00  <Lakie> Though the bitmask part may now have changed, heh
20:56:14  <Yexo> I think not
20:57:47  <Lakie> Heh, ok
21:11:32  <Lakie> I think when I finally finish all my samples, stitching them into one nml might provide a reasonablish test covering most things.
21:11:46  <Lakie> (for objects)
21:19:45  <Yexo> ok :)
21:20:00  <Yexo> for now I've just taken your example and expanded it a bit
21:20:03  <andythenorth_> bye
21:20:04  <Yexo> mostly to cover all properties
21:20:09  <Yexo> but now it doesn't work in openttd :(
21:20:12  *** andythenorth_ has quit IRC
21:21:16  <Lakie> :O
21:21:21  <Lakie> Hmmm..
21:21:26  <Lakie> Should work in OpenTTD
21:22:00  <Yexo> yes, so right now I'm debugging why it doesn't
21:22:03  <Yexo> the nfo code looks fine
21:23:58  <Yexo> hmm, bit 31 is set in the sprite numbers, so it's a bug in nml
21:24:39  <Lakie> Yeah
21:32:42  <Yexo> Lakie: I asked just before you came online: is there any point in object var 60?
21:32:46  <Brot6> NewGRF Meta Language - Revision 923:3671b4653798: Fix (r912): bit 31 of the sprite number in acti... (yexo) @
21:32:46  <Brot6> NewGRF Meta Language - Revision 924:e21e7a6046fc: Add: basic object regression test (yexo) @
21:32:46  <Brot6> NewGRF Meta Language - Feature #1346 (Closed): NewObjects support (yexo) @
21:33:19  <Yexo> the way I see it it either returns 0xFFFF (non-object tile or different object) or it returns the local id of the current object (which you already know, because it's the same object as the current tile)
21:33:31  <Lakie> I dunno, 60 is get the object id at offset yx from tile?
21:33:36  <Yexo> yes
21:34:31  <Lakie> I believe some may have wanted to use such things for 'faked' small rivers.
21:34:36  <Yexo> or is the "object tile at offset is part of the same object as the current tile" check openttd only?
21:35:01  <Lakie> No, its at a signed offset from the current tile
21:35:15  <Lakie> thus, useful for cehcking whats next to certain tiles
21:35:34  <Yexo> but if you want to fake a small river, you have to place the same object multiple times
21:35:40  <Lakie> That check is part of var 62 irrc
21:35:42  <Yexo> but the objects are different, it's not one object
21:35:51  <Yexo> so you'll get 0xFFFF as return value
21:36:03  <Lakie> Yes, but it returns object setid if from the same grf
21:36:23  <Yexo> not if the given tile is part of a different object (at least not in openttd)
21:36:32  <Lakie> 0xFFFE = an object from another grf, 0x<id> is object from same grf.
21:37:12  <Lakie> You should only get 0xFFFF if the tile is not an object
21:37:13  <Yexo> if (!IsTileType(tile, MP_OBJECT) || GetObjectIndex(tile) != oid) return 0xFFFF; <- first line of the implementation of that var in openttd
21:37:25  <Yexo> ah, that makes sense
21:37:58  <Lakie> Because of course, objects only have one type oer the whole object, I can see why that code render it useless.
21:38:32  * Lakie admits he didn't notice current industry part when he implemented it
21:38:38  <Yexo> the documentation refers to industry var 60, which says: # FFFFh if the tile isn't an industry tile, or doesn't belong to the current industry
21:38:49  <Yexo> but leaving out that check makes sense
21:39:02  <Yexo> it just needs better documentation in that case
21:39:14  <Lakie> Yeah
21:39:42  <Lakie> Its possible Rubidium intended it to work like industry var 60 exactly, and I misunderstood though
21:40:15  <Yexo> exactly like industry var 60  (=current openttd implementation) renders it useless
21:41:15  <Lakie> Aye, the other way makes more sense
21:42:20  <Yexo> No FFxxh return value?
21:42:33  <Lakie> Not that I know off
21:42:37  <Yexo> ok
21:52:03  <Hirundo> Yexo: You forgot to add the nml file of the object regression test
21:53:30  <Yexo> oops
21:54:12  <Brot6> NewGRF Meta Language - Revision 925:4d02708ea16c: Fix (r924): forgot to add the nml file for the ... (yexo) @
21:57:48  <Yexo> Hirundo: did you make a start with #1695 already?
21:57:48  <Brot6> Yexo: Hirundo: #1695 is "NewGRF Meta Language - Feature Request #1695: sprite block restructuring - #openttdcoop Development Zone"
21:58:15  <Hirundo> I made a start, but I'm not very far yet
21:58:17  <Yexo> imo that one shouuld get a high priority now
21:59:22  <Hirundo> agreed
22:00:01  <Yexo> anything I can help with currently? if not I'll continue writing more documentation
22:00:10  *** ODM has quit IRC
22:00:47  <Hirundo> I think documentation and industry example is the other main prio now
22:00:58  <Yexo> yep
22:01:01  <Yexo> and #1447
22:01:02  <Brot6> Yexo: #1447 is "NewGRF Meta Language - Code Review #1447: revise and unify usage of bitmasks and lists - #openttdcoop Development Zone"
22:01:30  <Yexo> a question about that one: does "everything to bitmask" include the *_CB_* and *_CGF_* constants?
22:01:35  <Yexo> if so, we have a lot of constants to change
22:01:38  <Hirundo> I hope I can find a day to spend on #1695 in the next weekend, but with exams coming up I can't be sure
22:01:38  <Brot6> Hirundo: #1695 is "NewGRF Meta Language - Feature Request #1695: sprite block restructuring - #openttdcoop Development Zone"
22:09:28  <planetmaker> hello
22:12:43  <Hirundo> was "results enjoyment factor - needed suffering > 0" ?
22:13:41  <planetmaker> definitely
22:13:50  <planetmaker> but we didn't make it in the top 3 :-(
22:14:09  <planetmaker> Still much fun as usual :-)
22:14:27  <planetmaker> I see you had here very productive fun, too :-)
22:15:11  <Hirundo> if spending 2-3 hours on a dynamics exercise is 'productive fun', then yes
22:15:27  <planetmaker> :-P
22:15:51  <planetmaker> I guess it depends on whether "results enjoyment factor - needed suffering > 0"  ;-)
22:16:03  <Hirundo> although I definitely learnt something: If they tell you to 'solve graphically', then DO THAT
22:16:33  <Hirundo> since the reason to use a graphical solution is that the vector algebra was damn difficult :P
22:17:46  <Lakie> Heh
22:17:53  <planetmaker> haha :-)
22:18:03  <Lakie> Graphical solution as in vector diagrams?
22:18:03  <planetmaker> Yeah, that's usually said for a reason
22:18:37  <Hirundo> graphical as in 'drawing some arrows and lines in a diagram and measuring them'
22:20:10  <Lakie> Ah, yes, such diagrams can be much easier to solve using..
22:51:38  *** Levi has quit IRC
23:08:06  <welshdragon> DJNekkid, ping
23:09:38  <SmatZ> who needs exact solutions anyway
23:11:06  <welshdragon> DJNekkid, BROS Tracking Table at
23:31:10  *** thgergo has quit IRC
23:33:25  *** Lakie has quit IRC

Powered by YARRSTE version: svn-trunk