Log for #openttdcoop.devzone on 9th December 2010:
Times are UTC Toggle Colours
00:06:55  *** Lakie has joined #openttdcoop.devzone
00:29:41  *** KenjiE20 has quit IRC
01:45:39  *** Lakie has quit IRC
02:08:53  *** thgergo has quit IRC
07:59:38  <planetmaker> moin
08:22:52  <Ammler> hoho
10:25:38  <dih> ello
10:26:00  <Ammler> H
10:26:23  <dih> :-)
10:27:02  * dih needs a java developer ^^
10:28:03  <Ammler> paid job?
10:29:18  <dih> erm....
10:29:35  <dih> what in the openttd world is a paid job? (excluding the hosting providers techies) :-P
10:31:25  <Ammler> ah, you search for joan & co :-)
10:31:46  <dih> more & co :)
10:32:16  <dih> there are 2 things left for joan that i can think of (apart from improvements which will not affect the api)
10:34:06  <dih> i might send a pm out to some guys on the forums
10:35:17  <Ammler> hmm, who was this guy, which made that auto in?
10:41:26  * avdg needs a php developer :p
10:41:44  <avdg> or frontend
10:43:19  <Ammler> dih: is one
10:43:39  <dih> oi o/
10:44:00  <Ammler> hehe, openttdphplib
10:44:36  <Ammler> then there are already 3 :-)
10:46:07  <dih> ?
10:46:50  <dih> mine is OpenTTDLib without php ;)
10:52:43  <avdg> let see :p
10:54:53  <Ammler> dih: yes, but it needs libs to the admin if
10:55:19  <dih> ;-)
10:55:36  <dih> tcp connection? for a single web page...?
10:55:37  <dih> hmmm
10:55:46  <dih> well - you do that for mysql too, dont you :-P
10:58:27  <Rubidium> dih: consulting or grunt work
10:59:00  <dih> whatever someone wants to do :-)
10:59:11  <dih> ideas, hints, code :-P
10:59:39  <dih> i only just realized, i have been with OpenTTD for close to 4 years now
11:01:10  <Rubidium> your poor soul :)
11:01:30  <dih> for command handling in grapes i am considering to force command methods to accept 2 args: CommandContext and CommandArguments
11:01:44  <dih> however, i am not yet so sure how i will define CommandContext ^^
11:02:05  <dih> it has to generically be able to define public chat, private chat, reply methods, etc.
11:02:50  <dih> generically means: workable with various chat systems, e.g. irc, xmpp, openttd, ...
11:03:06  <Rubidium> hmm, so commands aren't OpenTTD commands
11:04:07  <dih> it's a bot, commands should be things like
11:04:08  <dih> @logs
11:04:08  <Webster> Logs:
11:04:41  <dih> they should be able to be defined for openttd, for everything, for everything apart from openttd, and for something specifically - e.g. irc
11:05:19  <dih> i also want Pre and Post extention point extention possibilities
11:05:39  <dih> e.g. Pre(OpenTTDExtention.Chat)
11:05:55  <dih> so that i can force an ignore on certain stuff with a plugin
11:06:17  <dih> logging facility needs to be in place in joan and in grapes
11:08:09  <Rubidium> whether something is a reply or not doesn't really matter as that's stored in the calling context, isn't it?
11:08:38  <Rubidium> i.e. when grapes/joan sends something it's a "reply", when the plugins send something it's a "query"
11:10:30  <Rubidium> interface Command { String endpoint; List<String> arguments; }
11:11:00  <Rubidium> where endpoint can either be the receiving or sending "party", but never joan/grapes
11:11:33  <Rubidium> e.g. for IRC "#<channel>" or "<nick>"
11:11:52  <dih> but then it will be hard to find out if it's a private message, if the nick is an irc nick or an openttd nick
11:12:23  <dih> so the context could define stuff like bool isPrivate;
11:12:34  <dih> string endpoint
11:12:35  <Rubidium> does that matter for joans?
11:12:42  <dih> it matters for grapes
11:12:56  <dih> say you have a connection to openttd, and irc
11:13:12  <Rubidium> interface Command { String endpoint; String nick; List<String> arguments; }
11:13:25  <dih> soneone says 'help' in irc publicly, this 'someone' is also in openttd with the same nick
11:13:50  <dih> so if i have the endpoint as String, i need to grap the 'endpoint's object and have to know the methods to reply
11:14:20  <Rubidium> but if the command comes from IRC, then it shouldn't bother OpenTTD
11:14:42  <dih> and vice versa
11:15:14  <Rubidium> I'm assuming something like void HandleCommand(Plugin p, Command c) to happen
11:15:18  <dih> so if i definde a context class, which had methods like 'reply' or 'publicChat'
11:15:28  <dih> yes
11:15:47  <dih> i would though let the source of the command define the context
11:15:54  <Rubidium> in any case, it replies back to the same plugin that gave the command giving that the endpoint the command originated from
11:16:07  <dih> exactly
11:16:33  <dih> turning 'endpoint' into an object which contains more than just where the thing originated from
11:16:55  <dih> say a command was executed twice at the same time, once from openttd once from irc
11:17:14  <Rubidium> then it's called with two different plugins
11:17:22  <Rubidium> and thus the reply is sent to two different plugins
11:17:28  <dih> exactly
11:17:55  <dih> if i define an interface CommandContext, the way to retrieve information will always be the same, no matter which plugin is the source
11:18:16  <Rubidium> the nick doesn't matter as there isn't a guaranteed 1-on-1 mapping
11:18:34  <dih> the nick matters if e.g. i want to be able to implement an ignore plugin
11:18:40  <dih> ignore <source> <nick>
11:18:44  <dih> for example
11:19:00  <dih> then i need to be able to access the nick
11:19:01  <Rubidium> where source is a plugin
11:19:05  <dih> yes
11:19:18  <Rubidium> but... is there always a nick?
11:19:30  <Rubidium> in all "chat" applications
11:19:43  <dih> if not, i could substitute 'nick' for a constant string
11:19:49  <dih> e.g. 'console'
11:20:19  <dih> then the chat public, chat private, and reply methods would be mapped to the same print function ^^
11:20:20  * Rubidium remembers chatting using talk(d). As far as I remember there were no nicks there
11:20:34  * dih wonders how that worked ^^
11:21:52  <Rubidium> annoyingly :)
11:22:03  <dih> what was used to distinguish between people?
11:22:21  <Rubidium> don't know anymore; it was a messy business
11:22:25  <dih> hehe
11:26:44  <dih> <- something like that is what i was thinking about
11:26:45  <Webster> Title: #1361618 - Pastie (at
11:36:25  *** Webster has joined #openttdcoop.devzone
11:39:08  <dih> Ammler, sulai?
11:45:22  <Ammler> joh, ich glaub
11:46:16  <Ammler> [12:36] <dih> why on earth do you not run webster on the znc host? <-- already prepared
12:05:45  *** KenjiE20 has joined #openttdcoop.devzone
12:16:30  *** DayDreamer has joined #openttdcoop.devzone
12:16:33  *** ODM has joined #openttdcoop.devzone
13:34:38  *** ODM has quit IRC
13:35:39  *** ODM has joined #openttdcoop.devzone
13:38:30  *** ODM has quit IRC
14:09:24  <Brot6> NewGRF Meta Language - Bug #2009 (New): nmlc fails with syntax error on python 2.5.2 (planetmaker) @
14:45:56  *** DayDreamer has quit IRC
15:19:02  *** Doorslammer has joined #openttdcoop.devzone
15:29:31  *** Lakie has joined #openttdcoop.devzone
15:41:56  *** Doorslammer has quit IRC
15:49:48  *** Doorslammer has joined #openttdcoop.devzone
16:59:31  *** KenjiE20 has quit IRC
17:00:32  *** KenjiE20 has joined #openttdcoop.devzone
17:09:48  <Terkhen> we have a competitor :)
17:10:08  <planetmaker> the TTD-mod guy?
17:10:19  <planetmaker> Yeah :-)
17:10:46  <planetmaker> But he just steals the graphics ;-)
17:11:06  <Terkhen> yes... not very nice
17:11:52  <planetmaker> I asked mb to have a look at that newgrf where he said that he had used things from his NewCargo stuff
17:11:53  <planetmaker> :-P
17:12:05  <planetmaker> I guess I'm evil :-(
17:13:03  <planetmaker> Though actually I don't mind those newgrfs. But I'm indeed a bit concerned by the show of total ignorance of licenses
17:14:51  <Terkhen> yes, the use of original graphics is a bit disappointing
17:16:54  *** andythenorth has joined #openttdcoop.devzone
17:17:33  <Terkhen> doesn't it break the terms of use of bananas?
17:18:28  <planetmaker> I asked Rubidium about it with the same question. He's somewhat right that there was for ages the TTO conversion NewGRF. So there's not much point complaining about TTD either.
17:18:41  <Brot6> firs: update from r1578 to r1582 done (1 errors) -
17:19:04  <Terkhen> yes... he's one of the original authors after all
17:19:09  <Brot6> heqs: update from r551 to r553 done -
17:19:19  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r686), 32bpp-extra (r39), ai-admiralai (r75), airportsplus (r70), basecosts (r22), belarusiantowns (r8), bros (r40), comic-houses (r71), fish (r423), frenchtowns (r6), grfcodec (r811), indonesiantowns (r39), manindu (r6), metrotrackset (r56), newgrf_makefile (r237), nml (r1077), nutracks (r120), ogfx-rv (r78), ogfx-trains (r199), ogfx-trees (r41), opengfx (r568), openmsx
17:19:19  <Brot6> (r97), opensfx (r97), smts (r19), snowlinemod (r45), swedishrails (r190), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r26), ttrs (r23), worldairlinersset (r669)
17:19:26  <planetmaker> I'm a bit more concerned that he starts to use the work of (still active) community members - to my impression without asking
17:19:44  <planetmaker> where modification is not allowed though. Like Stolen trees also
17:20:39  <Terkhen> stolen trees too?
17:20:50  <planetmaker> <Terkhen> yes... he's one of the original authors after all <-- do I miss smily (my irony detector might fail)
17:20:58  <Rubidium> technically what bananas does can't be illegal, after all bananas was given a license to do what it does by the original author
17:21:03  <Terkhen> :)
17:21:23  <Rubidium> now if someone misrepresented themselves as original author, then that's something between the real original author and the fake one
17:21:41  <planetmaker> <-- NewTrees
17:21:43  <Webster> Title: Transport Tycoon Forums • View topic - NewTree, NoGridLand & ArcticRemoveSnow (at
17:22:25  <Terkhen> heh
17:23:09  <planetmaker> those things seem to not be on bananas yet, though
17:24:09  <Terkhen> let's see how this ends :)
17:39:40  *** thgergo has joined #openttdcoop.devzone
17:48:02  *** frosch123 has joined #openttdcoop.devzone
18:36:29  *** Lakie has quit IRC
18:48:53  <Yexo> I'm still wondering how someone can write a 1000+ sprite nfo file with all sprites correctly numbered without nforenum / similar tool
18:48:54  <Webster> Title: Transport Tycoon Forums • View topic - grf codec. make it arrange/number ? (at
19:02:55  <Brot6> 32bpp-ez-patches: update from r21439 to r21443 done (2 errors) -
19:05:16  <Brot6> clientpatches: update from r21439 to r21443 done -
19:05:44  <Brot6> serverpatches: compile of r21443 still failed (#1965) -
19:06:37  <Rubidium> someone ought to fix those errors...
19:21:55  *** Doorslammer has quit IRC
21:42:49  <Brot6> Swedish Rails - Revision 191:2d67efb28ced: Change: Add compatible and powered railtypes to the di... (planetmaker) @
21:45:53  <Brot6> Swedish Rails - Revision 192:8ef243fb36c3: Change: Clarify parameter description a bit more (planetmaker) @
21:51:11  <planetmaker> Yexo: do I have in NML the possibility to find out whether my newgrf is before or after another newgrf?
21:51:28  <Yexo> not sure, I'll check
21:53:37  <planetmaker> hm. grf_current_status vs. grf_future_status?
21:53:54  <Yexo> from : only G and gg are available in nml
21:57:00  <planetmaker> hm, yes. Thank you :-)
22:02:50  <planetmaker> I guess if I need something more I can implement that myself easily
22:03:22  <Yexo> thinking of a suitable name is the hardest part
22:03:43  <planetmaker>     grf_(current_status|future_status|order_behind)(grfid[, mask]) builtin function. <-- I thought of that
22:04:23  <planetmaker> but I agree :-)
22:04:26  <Brot6> NewGRF Meta Language - Revision 1078:049982311a0c: Fix: also check arguments for the gender comma... (yexo) @
22:04:26  <Brot6> NewGRF Meta Language - Revision 1079:e8a64dbca52a: Change: allow literal strings in the cargotabl... (yexo) @
22:11:35  <Brot6> NewGRF Meta Language - Revision 1080:aa083d75628b: Add: cargotype/railtype builtin function that ... (yexo) @
22:12:22  <Yexo> since r1080 "3RDR" as a railtype label is supported, just put "3RDR" in your railtype table instead of just 3RDR and reference it with railtype("3RDR") instead of 3RDR
22:14:14  <planetmaker> that's only needed for identifiers with a numeric staring character?
22:14:27  <Yexo> yes
22:14:33  <planetmaker> wow. Nice :-)
22:14:39  <Yexo> and other identifiers that are not allowed as nml identifiers
22:15:28  <planetmaker> Objections agains grf_order_behind as name for the gG test?
22:15:47  <planetmaker> +t
22:16:16  <Yexo> no objections as long as you also write the documentation for it :p
22:16:28  <Yexo> which is what I'm going to do now for my last changes
22:16:32  <planetmaker> hehe :-) Yes. In a separate commit
22:16:44  <planetmaker> which I'm working on already
22:17:58  <Brot6> NewGRF Meta Language - Revision 1081:1a2b6803feaa: Add: 'grf_order_behind' allows to test whether... (planetmaker) @
22:23:57  <Brot6> NewGRF Meta Language - Revision 1082:1cb7713fe846: Doc: cargotype/railtype functions (yexo) @
22:25:30  *** frosch123 has quit IRC
22:31:30  <Brot6> NewGRF Meta Language - Revision 1083:eea1a8e29ac4: Doc: Add 'grf_order_behind' to the list of bui... (planetmaker) @
22:39:58  <Brot6> Swedish Rails - Revision 193:1d4897e3f47a: Add: Disable the NewGRF if it's pointless (i.e. activa... (planetmaker) @
22:40:04  <Yexo> meh, it's hard to come up with a useful newgrf that uses the new string codes
22:40:22  <Yexo> most useful example is industries, but writing an industry newgrf is quite a lot of work
22:40:31  <planetmaker> yes, quite
22:40:40  <planetmaker> though there exists somewhere a wood
22:41:04  <planetmaker> but it's iirc only a re-definition of the existing wood
22:42:54  <planetmaker> does that suffice for you?
22:43:03  *** andythenorth has quit IRC
22:43:11  <Yexo> not really
22:43:25  <Yexo> it's easy to write a dummy newgrf to test the string codes, I've already done that
22:43:53  <Yexo> but I just can't think of newgrf that could make use of them ina meaningful way except an industry newgrf
22:44:13  <planetmaker> cases + gender, yes?
22:44:20  <Yexo> and plurals
22:44:22  <planetmaker> or the numeric arguments? Or both?
22:44:56  <planetmaker> Houses maybe. and NewObjects
22:45:12  <planetmaker> but... just maybe
22:45:33  <Yexo> houses/objects can't have a gender, and even if they had one it wouldn't be referenced anywhere
22:47:51  <Yexo> is the firs nightly compatible with openttd 1.0 ?
22:48:51  <planetmaker> yes
22:59:00  <Brot6> OpenGFX+ Industries - Revision 1:57ef19fc7624: Fix: Update Makefile framework and NML syntax to c... (planetmaker) @
23:08:20  <Terkhen> what are you planning for that? :)
23:14:49  <planetmaker> nothing yet really in detail
23:15:14  <planetmaker> besides the property changes as now, the forest in arctic with snow/non-snow
23:15:30  <planetmaker> Maybe also climate-selection
23:16:00  <planetmaker> Ammler's lumber-mill could be thus integrated here, too in a not-yet-exactly-defined way
23:16:52  <planetmaker> it could have also (parts) of frosch's manual industries accessible via parameter
23:17:40  <planetmaker> Basically I noticed that it doesn't compile and thought to at least fix the repo ;-)
23:17:55  <Terkhen> I see :)
23:18:49  <planetmaker> actually, snowy versions of a number of industries is necessary
23:19:23  <planetmaker> so in that way a similar upgrade like ogfx+airports
23:19:51  <planetmaker> especially the ore mine looks ugly in arctic ;-)
23:21:27  <planetmaker> In any case: if you have any idea in particular - just go ahead ;-)
23:24:50  <Terkhen> nothing in particular, I was just curious :)
23:25:48  <planetmaker> :-)
23:26:37  <planetmaker> I still have here the forest version which this one guy very early in the NML development posted there. I consider adding it. But... I need to ask him about that...
23:28:54  <Brot6> Grapes - Revision 44:58cef927a809: Add: CommandContext - this class still needs further work ;-) (dih) @
23:31:49  <planetmaker> And now a good night :-)
23:32:09  <Terkhen> good night planetmaker

Powered by YARRSTE version: svn-trunk