orig_artwork's mdlc -convert works for me.
MDLfx and Allegiance behave normal /w the bmp.mdls made with it.
I too experienced MDLEdit CC spacer error....it's a MDLEdit problem not a mdlc problem /tongue.gif" style="vertical-align:middle" emoid=":P" border="0" alt="tongue.gif" />
mdlc -optimize
These bugs haven't been fixed yet because don't have any developers interested in fixing them up. --Tigereye
Imago's stupid-sensor is supersensitive. --RealPandemonium
The art is managing the flow of the drama to achieve the desired results. --Big_Beta_Tester
joeld wrote:But we’ve been amazed at the level to which some of the Allegiance fans have remained hard-core.
I only noticed it didn't work in mdledit because it didn't work in Alleg. That said, perhaps I had some kind of one-off anomaly. Not gonna bother testing it right now, I'll let you know if I run into problems again.
Andon: I have no idea what that means.
Andon: I have no idea what that means.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
To do list:
Test if multiple textures work.
Get red and green doors working.
Test bounds files.
Test if multiple textures work.
Get red and green doors working.
Test bounds files.
Last edited by Compellor on Mon Aug 18, 2008 1:16 am, edited 1 time in total.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Since I'm linking people to this thread, I just thought I should note that I got 1 team servers working. Didn't have to do anything with my router, I just hadn't realized what those check marks next to the team names were for.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
complementary comments concerning lights :
the engine (and so mdlc) accepts the follow name format:
frm-<prefix>SS<postfix>
<prefix> and <postfix> can be anything as long as it's non whitespace or special characters. So "frm-thisismySSfancylight" works too (_ and - are accepted)
However the <prefix> can contain 2 numbers prefixed and separated by '-'s:
<prefix> = "-<number1>-<number2>"
if such a pattern is detected than number1 and number2 are used to define the phase and period of the light (see below)
for instance:
frm--0.2-1.37SSmyfancylight
the engine detects it's a light and:
<prefix> = "-0.2-1.37" is parsed and phase = 0.2, period=1.37
<postfix> = "myfancylight" is ignored
When a light is created, it has default values:
color = set to the diffuse color of the material associated with the frame or white if no material
position = set to 0,0,0 relatively to the transform matrix of the frame
period = 1.25 or <number2> if parsed in <prefix>
phase = 0 or <number1> if parsed in <prefix>
rampUp = 0.1
hold = 0
rampDown = 0.05
(these last 3 are hardcoded and cannot be specified in the .x/.mdl file).
The light is rendered with a 2D sprite using f101bmp.mdl as texture (hardcoded), blended with <color> and scaled like this:
scale goes from : 0% (off) --- rampUp speed ---> 50% (full) --> hold time --> rampDown speed -> 0% (off) --> repeat
<phase> is the initial scale. it allows to have desynchronized lights by using different phase values.
the engine (and so mdlc) accepts the follow name format:
frm-<prefix>SS<postfix>
<prefix> and <postfix> can be anything as long as it's non whitespace or special characters. So "frm-thisismySSfancylight" works too (_ and - are accepted)
However the <prefix> can contain 2 numbers prefixed and separated by '-'s:
<prefix> = "-<number1>-<number2>"
if such a pattern is detected than number1 and number2 are used to define the phase and period of the light (see below)
for instance:
frm--0.2-1.37SSmyfancylight
the engine detects it's a light and:
<prefix> = "-0.2-1.37" is parsed and phase = 0.2, period=1.37
<postfix> = "myfancylight" is ignored
When a light is created, it has default values:
color = set to the diffuse color of the material associated with the frame or white if no material
position = set to 0,0,0 relatively to the transform matrix of the frame
period = 1.25 or <number2> if parsed in <prefix>
phase = 0 or <number1> if parsed in <prefix>
rampUp = 0.1
hold = 0
rampDown = 0.05
(these last 3 are hardcoded and cannot be specified in the .x/.mdl file).
The light is rendered with a 2D sprite using f101bmp.mdl as texture (hardcoded), blended with <color> and scaled like this:
scale goes from : 0% (off) --- rampUp speed ---> 50% (full) --> hold time --> rampDown speed -> 0% (off) --> repeat
<phase> is the initial scale. it allows to have desynchronized lights by using different phase values.
Additional note: If you already have a file named *_static.x, it will not be replaced when you run makegeo.bat. This means that if you run makegeo on *.x, then change *.x and run makegeo.bat, the changes won't matter. You need to remove *_static.x from the directory for makegeo to create an mdl and cvh with your changes. Of course, you could just replace *_static.x yourself, doesn't matter, it's just a copy of *.x.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Anyone know how the loadout screen works? So far every time I convert a ship it's a little too big in the loadout screen, so that parts of it noticeably intersect with the view plane (or whatever that's called), letting you see through the model. For example, if you look at the screenshot above, you'll notice that the rear leg of the Mara is truncated.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
QUOTE 12. Here's the weird part: take all the cubes EXCEPT the guns, and mirror them on the Z axis, so that the thrusters etc are in the front. I don't know why this is necessary, it just is. What's worse is that it isn't always necessary for all of the cubes; for example, sometimes the guns should be mirrored, and sometimes they should not be. You won't know until you get it into the game.[/quote]
I've been trying to figure this one out. I've switched now from Blender to Truespace 7.6, since it imports COBs natively, and its .x export seems to work alright... except for the problem above. Actually, it seems that every mesh's location (but not orientation) is mirrored along what in the .x file is the Z axis and in Truespace is the Y axis. Yes, for some reason the axes are different. Anyway, it means that if I load and save the pattie, the spoiler ends up hanging in air front of the craft. It doesn't particularly bother me that I'd have to flip a sign on a few frame transform matrices, what bothered me was that I couldn't figure out why I would have to flip them in the first place.
I seem to have found a clue: I opened a copy of fig12.x (pattie) in notepad, deleted the supposedly unused animation code, and loaded the file in mdledit. Behold! Everything is mirrored like before. I guess now I need to scrutinize the animation code to figure out what it's doing.
I've been trying to figure this one out. I've switched now from Blender to Truespace 7.6, since it imports COBs natively, and its .x export seems to work alright... except for the problem above. Actually, it seems that every mesh's location (but not orientation) is mirrored along what in the .x file is the Z axis and in Truespace is the Y axis. Yes, for some reason the axes are different. Anyway, it means that if I load and save the pattie, the spoiler ends up hanging in air front of the craft. It doesn't particularly bother me that I'd have to flip a sign on a few frame transform matrices, what bothered me was that I couldn't figure out why I would have to flip them in the first place.
I seem to have found a clue: I opened a copy of fig12.x (pattie) in notepad, deleted the supposedly unused animation code, and loaded the file in mdledit. Behold! Everything is mirrored like before. I guess now I need to scrutinize the animation code to figure out what it's doing.
Any job worth doing with a laser is worth doing with many, many lasers. -Khrima
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players
Beyond a shadow of a doubt if you don't watch them like a hawk they will stack their collective balls off - MrChaos on Alleg players