Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 1 of 8      1   2   3   4   Next   »
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #1 
In the course of working to update ArtClientLib to Artemis 2.0, I have begun documenting the protocol. I'm in the process of transferring everything I can glean about the protocol from the code to this document, and correcting it as I discover things that have changed in Artemis 2.0. Though I suspect there will be few, if any, other people who would be willing to contribute to this endeavor, I welcome any contributions to this project.
LawsonThompson

Registered:
Posts: 625
Reply with quote  #2 
You may have already seen this, but there is some Python script kicking around which sends commands to a Processing sketch. 

https://github.com/fridgehead/OSCArtemis

There are some bits in there for handling game events similar to the DMX code. I reverse engineered a bit more of the protocol from this code; my goal was to use a spare PC as special effect light, flashing when hit and changing colors on shield up/down/docking. Never went much farther and decided to just put DMX lighting gear on my Christmas wishlist instead.

__________________
----
Visit us at http://www.ltebridge.com
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #3 
I had not seen that! I'm not sure what insights into the API might be there that aren't already in Daniel Leong's Java API code, and Python isn't a language I'm familiar with, but I'll see if I can glean something. You are welcome to contribute whatever you may know about the protocol to the wiki page; or simply post it here and I'll update it myself.
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #4 
I've transferred everything that I could glean about server-to-client packets from the source code of the 1.7 API project to my documentation. I still have to document the client-to-server packets. If anybody out there is dinking around with reading Artemis packets, this information might be useful to you. Disclaimer: This documentation is by no means complete, and is not yet fully updated to Artemis 2.0.
russjudge

Avatar / Picture

Registered:
Posts: 209
Reply with quote  #5 
REALLY COOL work you have going on there.  That information does expand the possibilities of what can be done to mod Artemis.  I was looking at some of the documentation you've put together--and a lot of ideas have started rolling around in my head.
__________________
Russ
Author of:
Artemis Mod Loader.
The Big Red Button of Death!
ArtemisSBS-Protocol Sharp
DMX Commander
(contact me to become a contributer)
(and all are free)
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #6 
Glad you approve, Russ. Hope people will find this useful.

I just added links for all the client-to-server packet types that are in the ArtClientLib API. I'll start filling in those pages over the next few days. Once I'm done documenting what I can glean from the API, I'll then start experimenting again to see what's broken or missing for Artemis 2.0. It would be nice if we could figure out what a lot of those unknown fields mean, too, but one thing at a time.
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #7 
Every known value in the protocol is now mentioned in the documentation, although some parts need greater elaboration.
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #8 
I've started noodling around with WireShark to see where I can identify differences between the protocol as documented thus far and the actual 2.0 protocol. One thing I noticed right off the bat is that clients are now informed about the availability of all stations, not just HELM, WEAP and COMM. I've updated the documentation and my fork of ArtClientLib to reflect this. I've also discovered some packets that are issued when the game starts that may have replaced some of the documented ones, but I need to investigate further.
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #9 
So after using WireShark to view network traffic, I decided I wanted to have something that is able to separate the data into discrete Artemis packets. So I ended up writing something that takes a "man in the middle" approach. I connect the client to this program instead of the Artemis server. Upon receiving the client connection, the program connects to the server and proceeds to pass through the packets between the two. This allows my program to inspect all the traffic that goes between them, but also neatly separates the data into Artemis packets.

I tried this out today, and it works great. Using it, I have now been able to identify the packets that the client sends to climb/dive, toggle auto beams, and toggle the first-/third-person perspective on the main screen. I've documented these in the wiki, and will be adding them to the code soon. I've also noticed that the engineering station's energy sliders seem to use a different subtype value (the one previously assigned to the jump command). I'll have to experiment some more with this.
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #10 
More changes. Thom merged enemies and friendlies to be handled largely by the same code, and they are now handled by the same packet type instead of separate ones. This brings up a big issue: how to tell friend from foe, since you can't use the packet type for that anymore. Hopefully I can figure out which field contains that info.
FlyMario

Registered:
Posts: 9
Reply with quote  #11 
Very good work here. I have used this information to write a c# program to connect to my server. If I spot anything in the packets not yet defined, I will share it.

Thanks,
FlyMario
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #12 
FlyMario,

Awesome. Let me know if you have any questions. Hopefully we can help each other out.
FlyMario

Registered:
Posts: 9
Reply with quote  #13 
One thing very interesting is that it seems unless some change has happened to a system you really don't get any information.  I get the efficiency of this however its kind of curious.

Let me explain...

I connect to the server,  all variables to the ship object are 0 even if the ship is in red alert, moving, turning... etc...   Unless a change happens you have no information for the player ship and the information you do obtain is really pertaining to the change itself.  So if your Impulse slider is set to full when you connect, it will show zero until someone changes the impulse slider.  Changing another variable will not really populate another variable.

There must be some packet the Client sends to the server to get the initial state of all game objects.

Also, I can confirm that the Warp byte (Warp? in your document) for player ships is definitely warp.

FlyMario
Arkantos

Avatar / Picture

Registered:
Posts: 466
Reply with quote  #14 
FlyMario,

My experience is that the server sends update packets for all the in-game objects when the game starts (or when you send the "ready" packet when connecting to an already-started game). Now that I've got the code updated to the point that it doesn't seem to blow up anymore, I working on creating a debug client to get a better idea of what's coming through the pipe.

You are correct that not every update will contain every available field for that object type; typically, it will only be the fields that changed. If you haven't yet received a value for a field, you can't assume it's zero; it's unknown. For example, enemy shield frequencies are unknown until you double-scan them; they're not zero.
russjudge

Avatar / Picture

Registered:
Posts: 209
Reply with quote  #15 
I started going through your documentation to build a C# API library that can do the work so that a UI of any type can be dropped on top of it.  One thing of note that I found is your list of ship types in the enumerations--those aren't fixed.  The number will match what is defined in the vesselData.xml file, which for one of the Mods, will be different.  The numbers you provide match to the "uniqueID" defined for the vessel in the vesselData.xml file, so when setting up ships based on that ship type, it will need to get the ship by the matching uniqueID for all the detains, including the ship's class.  Technically, the field is not an enumeration, but data-based.  If you drive your ship types based on what is defined in vesselData.xml, then whenever vesselData.xml changes (mods, or new ships added with version updates), then the protocol remains unchanged.

I just have a quick question about "Packet length" though--is the length defined there the total of the common packet structure, including the payload, or just the payload length?  For example, (using decimal-based) if the Payload was a DestroyObjectPacket, would the Packet Length be 29 (for the entire length of the common packet structure), or 5 (for the length of the Payload)?

Thanks.

__________________
Russ
Author of:
Artemis Mod Loader.
The Big Red Button of Death!
ArtemisSBS-Protocol Sharp
DMX Commander
(contact me to become a contributer)
(and all are free)
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.