Coming Soon

[Codewalker]

The initial release of the chat software does not natively support any form of scripting.

If you're using openfire as a server, it also does not support scripting languages, but does support plugins written in Java.

If you're using some other server software the options may vary.

For the ski slopes you could always write a standalone program to connect to the metadata channel for Pocket D and monitor player locations. You could have it send tells to players as they passed through the waypoints to let them know that they can proceed to the next one, then keep a record of who has the best time for the course and send it to broadcast upon the record being broken.

You'd have to do some sort of interpolation as the first version of PC only sends updates at most once per second, less often for lower rates of change. So it's unlikely that you'll see a player advertising they're on the exact spot of the marker, but rather on one side then on the other a second later.

[Arcana]

If you're using openfire as a server, it also does not support scripting languages, but does support plugins written in Java.

I noticed.  I'm so not looking forward to doing that.  Java and I don't get along well.

[Victoria Victrix]

I noticed.  I'm so not looking forward to doing that.  Java and I don't get along well.

Does Java actually get along well with anyone?

[FloatingFatMan]

Does Java actually get along well with anyone?

It gets along just fine with James Gosling, the douche.

[Joshex]

The initial release of the chat software does not natively support any form of scripting.

If you're using openfire as a server, it also does not support scripting languages, but does support plugins written in Java.

If you're using some other server software the options may vary.

For the ski slopes you could always write a standalone program to connect to the metadata channel for Pocket D and monitor player locations. You could have it send tells to players as they passed through the waypoints to let them know that they can proceed to the next one, then keep a record of who has the best time for the course and send it to broadcast upon the record being broken.

You'd have to do some sort of interpolation as the first version of PC only sends updates at most once per second, less often for lower rates of change. So it's unlikely that you'll see a player advertising they're on the exact spot of the marker, but rather on one side then on the other a second later.

custom sever, python 2.6.2, intention for scripts to run only in the 'plug-in' program though the plan isn't so much a java plug-in as an external program that merely communicates with ParagonChat's (PC) server. as talked about the message structure can be anything PC needs it to be.

there are a few things I'd need to know to write it, but I'm sure you don't want that info public yet if at all:

1: how to send a tell

2: how player IP addresses, playername, 3D space location and port packets are sent/received.

from what you said about 'once per second', is that with messages going out from the server? or is it also messages going in from the clients?

3: what info does the client need to set the gate marker?

Rather than route the info back through the PC server, it's possible to send it directly from the python program to avoid the one second problem. high scores can be recorded and sent back to the paragon chat server as a one second delay is fine for scores.

point is because I'm using python as the server we can send and receive data in any format so long as I write a simple database to read/convert it (I've been doing a lot of this for project bane so it's really no big deal).

either way November is a long ways away. here's what I'll do, after the tenth of July I'll start work on this and send you a file to show what I'm working with shortly after so there's no confusion..

[Joshex]

Does Java actually get along well with anyone?

java enthusiasts... *shudders*

[FloatingFatMan]

java enthusiasts... *shudders*

They're almost as bad as python fans.

[FloatingFatMan]

2: how player IP addresses, playername, 3D space location and port packets are sent/received.

You don't need IP addresses; all communication between players is via the XMPP server, and all you need there is their XMPP user name.

from what you said about 'once per second', is that with messages going out from the server? or is it also messages going in from the clients?

Try reading what CW said again.

"first version of PC only sends updates at most once per second, less often for lower rates of change."

The PC client only sends updates to the server once a second, or less.  This is nowhere near fine enough timing resolution for accurate race timings.

Rather than route the info back through the PC server, it's possible to send it directly from the python program to avoid the one second problem. high scores can be recorded and sent back to the paragon chat server as a one second delay is fine for scores.

No it isn't. PC only updates positional data once a second or less.

either way November is a long ways away. here's what I'll do, after the tenth of July I'll start work on this and send you a file to show what I'm working with shortly after so there's no confusion..

You're attempting to run before you've even learned to crawl. Perhaps you should consider waiting until they give us some kind of plugin framework, or release their CoH client data to open source, THEN start making plans.

[Joshex]

You don't need IP addresses; all communication between players is via the XMPP server, and all you need there is their XMPP user name.

I would need IPs and ports if the program I make is going to send messages to clients directly. (rather than add another 1 second delay through the XMPP server.)

The PC client only sends updates to the server once a second, or less.  This is nowhere near fine enough timing resolution for accurate race timings.

so the one second delay between messages is on both sides, that's what I was asking for clarification on. and you're right, that is no good for race calc.... there's always a way around it.

the once per second message would have to contain all movement keypresses in between with times in ms to update the server side for my system to work. even then there'd be a gate set delay of over a second and a possible time delay for finish of over a second.

No it isn't. PC only updates positional data once a second or less.

You're attempting to run before you've even learned to crawl. Perhaps you should consider waiting until they give us some kind of plugin framework, or release their CoH client data to open source, THEN start making plans.

That's why I'm asking questions. I wouldn't say I'm crawling, I'd say I walked into a store that has yet to release their products and am asking specifics about how it works and assuming things about it that may not be true.. never goes down well, and then am pacing back and forth thinking of the possibilities if it's one way or another..

I'm sure once it's released I'll be able to get more info., the other thing to do would to make another "plug-in" on the client side to send location info to the time server at a more frequent rate but that would probably require interfacing with the client itself which at this point I wont be doing..

[Manga]

Joshex, the XMPP protocol is well documented:  http://xmpp.org/

[FloatingFatMan]

I would need IPs and ports if the program I make is going to send messages to clients directly. (rather than add another 1 second delay through the XMPP server.)

Yeah, good luck with that.

Consider this. Letting the outside world know your IP address and any open ports is inviting trouble. Passing that information from a trusted server to an untrusted third party (ie: your server), would be tantamount to incompetent and I really can't see CodeWalker or Titan Networks allowing you that kind of access to their XMPP server data. You could possibly sort of do something that -might- work on your own private XMPP server, maybe, for people not behind a NAT, but it's pretty unlikely you will on Titans.

And TBH, if Titan start sending that info to untrusted 3rd parties, I will not be using their server.

If this sort of thing is to work at all, it would need to be an extension that the XMPP server is running on Titan's server, and must not send any data outside their network.  That means you're going to have to wait for them to provide a plugin framework for you.

[Joshex]

Yeah, good luck with that.

Consider this. Letting the outside world know your IP address and any open ports is inviting trouble. Passing that information from a trusted server to an untrusted third party (ie: your server), would be tantamount to incompetent and I really can't see CodeWalker or Titan Networks allowing you that kind of access to their XMPP server data. You could possibly sort of do something that -might- work on your own private XMPP server, maybe, for people not behind a NAT, but it's pretty unlikely you will on Titans.

And TBH, if Titan start sending that info to untrusted 3rd parties, I will not be using their server.

If this sort of thing is to work at all, it would need to be an extension that the XMPP server is running on Titan's server, and must not send any data outside their network.  That means you're going to have to wait for them to provide a plugin framework for you.

I thought I was clear this would be a secondary program on the titan server "same machine as the XMPP server" no wonder people got defensive lol. I'm talking of coding it and sending it in source to codewalker/leandro.

[Codewalker]

It wouldn't matter even if you had the IP, because Paragon Chat does not listen for incoming connections. It only establishes an outbound connection to the XMPP server. If you want to send something to it, you have to send it as an XML stanza through the XMPP server. Note that if it isn't a chat message, character presence, or position metadata, PC will ignore it.

The easiest way to do that is to simply connect to the same chatroom using your own account, though if we decide to do something more complex a Java-based serverside plugin could implement a service, which in XMPP is typically done as a subdomain.

The 1 second thing isn't a delay added by the server, it's a rate limit on how often PC will send position updates to avoid flooding the XMPP server.

I highly recommend reading the XMPP Core, XMPP-IM, and Multi-User Chat specifications if you're thinking about doing any kind of development against it. Though PC send its own custom XML for game-specific data, it adheres very closely to the specifications so those will give you a good idea of how to send and receive messages to it.

[FloatingFatMan]

I thought I was clear this would be a secondary program on the titan server "same machine as the XMPP server" no wonder people got defensive lol. I'm talking of coding it and sending it in source to codewalker/leandro.

No offence, but it's still an untrusted 3rd party application accessing sensitive data.

As far as I know, the one part of the documentation where it discusses the ability to discover IP addresses, it notes that it's NOT currently implemented and advises strongly NOT to implement it.  See XEP-0279 for further information.

It's also worth noting that's it's part of the XMPP core specification that IP addresses NOT be made public, and sending them to a 3rd party application, is public.

For more info, Click here for the specification.

You're going to have to rethink how your app is going to work, sorry.

[Arcana]

I thought I was clear this would be a secondary program on the titan server "same machine as the XMPP server" no wonder people got defensive lol. I'm talking of coding it and sending it in source to codewalker/leandro.

No offense intended, but there's just no way you're getting software onto the actual Titan XMPP server given where you currently are.  If I were Leandro or Codewalker, I wouldn't trust neither source nor binary from anyone else that didn't understand the fundamentals of the system they are using inside out.  If you have any sort of inkling to do this sort of thing, download a copy of Openfire, load it on your computer, and when Paragon Chat comes out figure out how to point it to your own server, write your own plugins on that experimental platform, and maybe, just maybe, when you are answering questions about the system from your experience doing that, they might entertain the notion of maybe looking at what you've done, maybe.

You're using a long-deprecated version of python that no longer gets security fixes.  You're not sure how XMPP works.  You didn't catch the fact we're all discussing the fact that Openfire only supports java plugins.  This isn't about being defensive, this is about the fact you don't seem to have the requisite knowledge base to do what you are attempting to do.  Why do you think I'm not bombarding Codewalker with a lot of technical implementation questions?  Because 90% of them would be answered by just looking at the client when its released, rather than having him explain it to me.  And if he explains it to me without me seeing the client itself, that could cause me to miss valuable context and misunderstand some fine technical detail.  And many of them I can deduce myself because of my familiarity with the systems involved.

On the subject of IP addresses.  If you were writing your own custom XMPP server itself, you'd get the client IP addresses from the socket connections to your server.  If you are writing a plugin to something like Openfire, you do not need client IP addresses because you are only receiving message data and sender/receiver data from the server itself, through its API.  All you can and *should* do is read message content, sender, receiver lists, process that data, and send data back to the Openfire server for it to then do its thing and send messages to the appropriate targets, which it can do because it knows how to send data to every client connected to it explicitly.  You don't, and are not supposed to, tell the server how to do that as a plugin.

I'm not discouraging you from attempting whatever it is you're attempting.  I'm encouraging you to build the requisite knowledgebase and skill set to make it at least theoretically possible.  Right now, you are not anywhere near.  As I tried to tell you before, its time to start doing the homework.  The day Codewalker said the platform was implemented on Openfire, I didn't start asking him questions about Openfire, I downloaded Openfire.  While I'm familiar with XMPP, its not like I write Openfire plugins every day, or any day.  The authoritative answer to my questions about Openfire isn't Codewalker, its Openfire.  I might ask him a technical question about Openfire, but  only after I actually know what the heck I'm talking about, so he isn't wasting his time giving me an Openfire tutorial.

If you want to write python-based plugins for Openfire, there's something you can do today, without needing any information from anyone else you couldn't get yourself.  You could write a java plugin for Openfire that somehow interfaces with python.  I'm still thinking about whether that's worth doing myself, and if so what's the best way to do that, so when you're finished with that give *that* to the community to play around with.  So I don't have to do it (heck, at that point might as well make an embedded Lua engine as a plugin and allow it to run Lua scripts: I know there are java implementations of Lua floating around out there).

[Leandro]

Incidentally, it's not that we particularly love Openfire, but it is the only XMPP server that worked properly out of the box and wasn't a major pain in the arse to configure. If someone else tests another server and finds that it works fine with Paragon Chat, yay! We can use that.

[Joshex]

ok let me be clear, when I say "plugin" I thought I made it clear I was using the word loosely cause it wouldn't actually plug-in or connect in any way to the server other than through local network messages. what I was asking is something codewalker should know and should save me time actually skimming through the documentation and learning a different code set.

I really just need to know what information is capable to be sent and received with the client and possibly the message composition in a list form.

Unless XMPP uses some secret proprietary message encoding for which I'd have to develop a reading and writing database, then the info between programs is just data and it really doesn't matter which API or program made it. it's not like python or blender will attach some binary signifier that "this message was created with python 2.6.2 socket module, GPL 2011" that could cause XMPP to say "hey that's not my message, I'm not gonna read it",  it sends what I script it to send, if I script it to mimic the way XMPP or any other software construct their messages then the PC client won't be the wiser, see what I'm getting at?.

message format is what I'm after, and I'm aware there may be multiple variations, but I'll only end up using a handful.

some of my questions have already been answered and I thank you all for your time in answering them, such as the knowledge the XMPP does not send IP or port externally.  or stuff like "you have to send it as an XML stanza,  Note that if it isn't a chat message, character presence, or position metadata, PC will ignore it."

it does make it nigh impossible to do what I'm attempting.

I.E. the gates are there but there's no ability to get the message to them, the timer window and score window are there somewhere but again no way to get the data to them. even if I did an XML stanza it would be ignored if it isn't one of the few data types allowed.

I will not write java, so I guess it ends there. the only other way is to make my own interface program to the CoX client itself, and honestly I haven't even tried so.. yeah, not gonna happen any time soon and would seem a bit redundant seeing as Codewalker and Leandro have already come this far.

Unless,.. Injection,  that might work, but that's another question. assuming I could send a message to PC that it interprets as a chat message, would it process this message by it's own rules?, or would it pass it to the CoX client code for processing?

if so sending a XML stanza with XMPP's position format containing a script in CoX's server message format telling the client how much time is on the timer or which gate is now active could work.

but no, PC probably just does everything itself, probably doesn't actually send any communication data to the CoX client at all just reads it like a book and emulates it.

So in summary, I know enough now to know it won't work. so much for my idea. thankyou for your time. for it to work PC would at least have to be enabled to receive other data types or for CoX's client code to process the message so injection techniques can be used. greatwork anyways, keep up the efforts.

Incidentally, it's not that we particularly love Openfire, but it is the only XMPP server that worked properly out of the box and wasn't a major pain in the arse to configure. If someone else tests another server and finds that it works fine with Paragon Chat, yay! We can use that.

Thats the other side of it, I could make a python XMPP server, but then I really would have to read all the documentation, 4 years is the standard development time for new projects of this caliber with one person, and 4 years is a long time.

XML stanzas.. I'll at least research that to see if I can do anything with it, can definitely make them in python even if I have to program the rules for their composition myself.

edit: ah yes XML stanzas, the standard XMPP format hence why codewalker dropped the documentation on me. too much to read for 11;57 pm. I'll give it a go after the 10th. but it's learning a whole new language.

[ukaserex]

If the slopes at Pocket D work - although I'd love to have some sort of base to compare my time with - just being able to go through the portal to the second part would be very, very cool and a whole lot of fun for me. I always enjoyed the slope.

[Arcana]

Incidentally, it's not that we particularly love Openfire, but it is the only XMPP server that worked properly out of the box and wasn't a major pain in the arse to configure. If someone else tests another server and finds that it works fine with Paragon Chat, yay! We can use that.

I was kinda looking at tigase, but honestly I'm still climbing the learning curve on XMPP servers.  I will probably need to see how it works with the standard software before trying to see if it will work in non-standard environments.

[Paragon Avenger]

Does Java actually get along well with anyone?

For the record, computer programming languages are nice and get along with everybody.
Computer programming language compilers are mean and hate everybody and everything.