PDA

View Full Version : [MISC] Stuff I'm doing



Dwood
February 6th, 2011, 07:27 PM
So yeah this thread is for the general things I've been doing lately. Here's the first thing, it's the .jms in struct format. Hope someone finds it useful.
<in the file it's coded as a string and separated by regular newline ie: \n separators (hex: [0D] [0A] as well as the single space lines [00]>
Thanks to Bluestreak so I could make sense of it (somewhat)


struct rotationXYZ {
float x, y, z; //these are spaced by the [09], or tab operators
};

struct translationXYZ {
float x, y, z; //these are spaced by the [09], or tab operators
};
struct normalXYZ {
float x, y, z; //these are spaced by the [09], or tab operators
};

struct node {
string name; //these are spaced by the [0D] [0A] , or newline operators
int sibling_index;
int next_sib_index;

};

struct node_array {
unsigned int node_count;
node nodes[node_count];
};

struct material { //these are spaced by the [0D] [0A] , or newline operators
string name;
string none;
};

struct material_array {
unsigned int mat_count;
material materials[mat_count];
};

struct marker { //these are spaced by the [0D] [0A] , or newline operators
string marker_name;
int marker_parent_index;
rotationXYZ myRot;
translationXYZ myTrans;
};

struct marker_array {

unsigned int marker_count;
marker markers[count];
};

struct region{//these are spaced by the [0D] [0A] , or newline operators
string name;
};

struct regions_array{
unsigned int region_count;
region regions[count];
};

struct myVertex {
int ver_node_index;
translationXYZ myTrans;
normalXYZ myNorms;
int vert_node1Index;
int vert_node1Weight;
float tvert_posY;
float tvert_posZ;
};

struct vertex_array {
unsigned int vert_count;
myVertex vert_array[vert_count];
};

struct face {
unsigned int region_index;
unsigned int shader_index;
unsigned int vert_index1;
unsigned int vert_index2;
unsigned int vert_index3;
};

struct face_array{
unsigned int face_count;
face myFaces[face_count];
};

struct JMS {
int version = 8200;
int checksum = 3251;
node_array myNodes;
material_array myMats;
marker_array myMarkers;
regions_array myRegions;
vertex_array myVerts
face_array myFaces;
};

Edit: SO basically anything that's not XYZ or vertex1-3 is separated by the newline operators.

ShadowSpartan
February 6th, 2011, 07:56 PM
As I said on AIM when you asked me to look it over, these are not helpful at all because the jms format is text based. Rather than defining the format in useless struct's, you should either write a text document outlining the format, or write a class that people could actually use for parsing the files. Right now it helps no one, just trying to be honest.

formlesstree4
February 6th, 2011, 08:05 PM
As I said on AIM when you asked me to look it over, these are not helpful at all because the jms format is text based. Rather than defining the format in useless struct's, you should either write a text document outlining the format, or write a class that people could actually use for parsing the files. Right now it helps no one, just trying to be honest.

The only thing I've done is figure out how to pull out the texture paths and names from weapons, maps and model JMS files.

ShadowSpartan
February 6th, 2011, 08:28 PM
The only thing I've done is figure out how to pull out the texture paths and names from weapons, maps and model JMS files.
Disregarding the fact that part of your post does not make sense ("weapons, maps and model JMS files"), what is your point? Sure this may help with figuring out the format yourself, but there are much better ways of describing the format to others. Struct's would be useful if it wasn't text based, but it is, so something else should be used to describe it.

formlesstree4
February 6th, 2011, 08:56 PM
Disregarding the fact that part of your post does not make sense ("weapons, maps and model JMS files"), what is your point? Sure this may help with figuring out the format yourself, but there are much better ways of describing the format to others. Struct's would be useful if it wasn't text based, but it is, so something else should be used to describe it.

It makes perfect sense. I can load up either a map, model, or weapon JMS file and extract the texture path and correlating texture name. Plain English right there. Granted, describing it for others..it doesn't really help them out, true, but it at least makes some progress on it. Further explanation will come with time since JMS's differ (between, say, a weapon and a map).

ShadowSpartan
February 6th, 2011, 09:07 PM
It makes perfect sense. I can load up either a map, model, or weapon JMS file and extract the texture path and correlating texture name. Plain English right there. Granted, describing it for others..it doesn't really help them out, true, but it at least makes some progress on it. Further explanation will come with time since JMS's differ (between, say, a weapon and a map).
Seriously, you have to be kidding me. The jms format is the same no matter what type of geometry data it is using. There is no difference between a bsp jms file, a vehicle one, or a weapon one.

Also, you said "map, model, or weapon", but anything that is in a JMS file is a model. I don't see what you could be calling a 'model' besides something like scenery. So no, your post did not make sense.

Skyline
February 6th, 2011, 09:26 PM
Further explanation will come with time since JMS's differ (between, say, a weapon and a map).

Pretty sure all JMS files are the same, it's only how tool interprets them, they are just processed differently. You could make a physics model for a vehicle with the same JMS you used for the gbxmodel, except the markers size actually matters for the physics model so it wouldn't work out too well.

formlesstree4
February 6th, 2011, 09:47 PM
Seriously, you have to be kidding me. The jms format is the same no matter what type of geometry data it is using. There is no difference between a bsp jms file, a vehicle one, or a weapon one.

Also, you said "map, model, or weapon", but anything that is in a JMS file is a model. I don't see what you could be calling a 'model' besides something like scenery. So no, your post did not make sense.

Calm down, I'm sorry. I was corrected just now. What I saw that I thought was something else wasn't what I thought it was. I stand corrected.

Dwood
February 6th, 2011, 09:50 PM
As a note, my struct[s] may not have any practical use however they do tell you the layout of the .jms file fairly well.

Patrickssj6
February 6th, 2011, 10:37 PM
Well...no :P

They do not tell anything about the layout besides obvious things like "X,Y,Z" occupy 12 bytes in an array of coordinates.

supersniper
February 8th, 2011, 10:05 PM
lol its a thread of who's got the biggest ego :P

Resinball
February 8th, 2011, 11:33 PM
I thought that was every thread ;)


Good tip about the .JMS Physics Model markers, Skyline. I was not aware of that.

Patrickssj6
February 9th, 2011, 12:57 AM
I thought that was every thread ;)


Good tip about the .JMS Physics Model markers, Skyline. I was not aware of that.

This is not about the biggest ego. Things like what Skyline said were common knowledge :P

Dwood
February 9th, 2011, 01:37 AM
This is not about the biggest ego. Things like what Skyline said were common knowledge :P

To who? It's not exactly published anywhere.

Cortexian
February 9th, 2011, 01:45 AM
Most likely, a select few community members who've had to deal with something related to the information provided by Skyline. I remember hearing reading something about that quite awhile ago on Modacity, or possibly GBX Software Forums when this community was primarily there. Just because something isn't posted in a FAQ/Tutorial doesn't mean it's not fairly common, things get omitted and such by mistake or forgetfulness.

What Skyline posted seems like common knowledge to me at least.

Dwood
February 9th, 2011, 05:11 AM
Yeah, what Skyline said should be common knowledge, but the overall layout of the file is not.

Patrickssj6
February 9th, 2011, 06:47 AM
Yeah, what Skyline said should be common knowledge, but the overall layout of the file is not.

Well I was talking about what Skyline said.

ShadowSpartan
February 9th, 2011, 09:36 AM
Yeah, what Skyline said should be common knowledge, but the overall layout of the file is not.
No one ever stated that the layout of the jms file was common knowledge, just that it has been figured out for years. Anyone could have easily figured it out either by inspecting exported files or taking a look at Bluestreak's code.

I fail to see why you will not admit that it is not very useful, and could lead to confusion among people by making it look like the format is not text based. It's stupid to display the data the way you are currently. As I said before, you should create a text document outlining the format, or if you really want to help then write a parser that people could use.

Dwood
February 9th, 2011, 12:07 PM
Well I was talking about what Skyline said.

Ah, sorry, there was a disconnect there, heh.

Goldkilla
March 22nd, 2011, 09:10 PM
I thought you were finishing up FireFight Decent...

Dwood
March 22nd, 2011, 10:09 PM
I thought you were finishing up FireFight Decent...

Mooseguy just barely gave me the map+tags yesterday. I suppose I could make this the ff-descent wip thread but I don't really like wip-thread-ing.

bobbysoon
May 7th, 2011, 02:36 AM
In bluestreak, the markers get a -1 for something. I think it's a region index. Gbx model markers can belong to a region. You blow an arm off the flood guy, and he loses his weapon, because the region his hand marker belongs to is destroyed.
Tabs can be used generously in a jms export, which speeds things up for gmax users streaming to the listener window. Since the jms is text based, it's fairly flexible. I made this change to bluestreak to speed up export:
JmsExporter104 (http://www.mediafire.com/?mz3jww7bq3qjcf8) [/spam]
format "%\t%\t%\n" 8200 checksum node_count to:jms
for n = 1 to node_count do
(
format "%\t" node_array[n].name to:jms
format "%\t" (node_first_child_index[n] - 1) to:jms
format "%\t" (node_next_sibling_index[n] - 1) to:jms
format "%\t%\t%\t%\t" node_rotation[n].x node_rotation[n].y node_rotation[n].z node_rotation[n].w to:jms
format "%\t%\t%\n" node_translation[n].x node_translation[n].y node_translation[n].z to:jms
)

mat_count = geom_materials.count
format "%\n" mat_count to:jms
for m = 1 to mat_count do
format "%\t%\n" geom_materials[m].name "<none>" to:jms

marker_count = marker_array.count
format "%\n" marker_count to:jms
for m = 1 to marker_count do
(
format "%\t-1\t" (substring marker_array[m].name 2 -1) to:jms -- -1 = region?
format "%\t" (marker_parent_index[m] - 1) to:jms
format "%\t%\t%\t%\t" marker_rotation[m].x marker_rotation[m].y marker_rotation[m].z marker_rotation[m].w to:jms
format "%\t%\t%\t" marker_translation[m].x marker_translation[m].y marker_translation[m].z to:jms
format "%\n" marker_radius[m] to:jms -- radius working, courtesy of Choking Victem
)

region_count = geom_regions.count
format "%\n" region_count to:jms
for r = 1 to region_count do
format "%\n" geom_regions[r] to:jms

numVerts = vert_pos.count
format "%\n" numVerts to:jms
for v = 1 to numVerts do
(
format "%\t" vert_node0index[v] to:jms
format "%\t%\t%\t" vert_pos[v].x vert_pos[v].y vert_pos[v].z to:jms
format "%\t%\t%\t" vert_normal[v].x vert_normal[v].y vert_normal[v].z to:jms
format "%\t" vert_node1index[v] to:jms
format "%\t" vert_node1weight[v] to:jms
format "%\t" tvert_pos[v].x to:jms
format "%\t0\t" tvert_pos[v].y to:jms -- w in uvw = 0?
)

format "%\n" numFaces to:jms

c = 0
for n = 1 to numFaces do
(
format "%\t" face_region_index[n] to:jms
format "%\t" face_shader_index[n] to:jms
format "%\t%\t%\n" c (c+1) (c+2) to:jms
c += 3
)
I've been wanting to modularize bluestreak with structs, to clean it up and get a better handle on what it does, mainly to re-work the regions aspect so whole-object selection sets are used, which unassigned face selections can default to, and markers can use.
Another possible outcome would be a jms importer.
All in all, I approve of this thread, minus the trolling