Archangel35757

You can use a ROF file for the speeder path. I can export a ROF file for you if you send me your map file and an origin brush where the speeder bike starts. I have to animate the origin brush in 3ds Max along the path you want and where you want it to end. Also, why can't you script the trooper to do a dismount animation?

It's the required vertex ordering for the triangle. What are the vertex numbers for your tag? Can you edit photo to show the vertex #'s?

I found this in mdx_format.h file (for Ghoul2 tags/bolts): //triangle side-ordering stuff for tags... #define iG2_TRISIDE_MIDDLE 1 #define iG2_TRISIDE_LONGEST 0 #define iG2_TRISIDE_SHORTEST 2 ...but I haven't found yet how it's used. I'm still travelling and only have my cell. My interpretation would be vertex 1 is the right angle corner, 0 defines long edge, and 2 the short edge... Edit: Or it could define the vertex corner number opposite the specified edge. @@Xycaleth, @@eezstreet, @@mrwonko???

well he asked about MD3 tags and GLM bolts. The AT-ST problem he's having is with bolts. @@minilogoguy18 -- would you try flipping the face normal and see what that does?

Did you try rotating the tag 180 degrees about it's Y axis, as I suggested?

@@AshuraDX... maxscript starts at 1... but internally 3dsMax uses 0,1,2.

Compare the axes of the foot/ankle bone to the bolt axes.

the bolts in Modview behave like bones... they use +Z up, +X right, and +Y into screen if IIRC. Basically a 90 degree rotation about the X axis in Softimage. Is the face normal of the bolt triangle flipped the wrong way? Based on your screenshot... I'd try rotating your bolt 180 degrees about Y axis.

Do you have negative scaling on any of your tags? Edit: Is the triangle surface's Normal vector flipped? I'm assuming your bolt matches what you posted here: try putting long edge on red axis and short on green.

Is this a prototype for a Hutt? Looks like a cross between Casper the ghost and a Hutt. But hey, to each his own.

You can read about MD3 tags in the file format description here: https://linux.ucla.edu/~phaethon/q3/formats/md3format.html The red axis of the tag is forward, the blue axis of the tag is up, and the green axis of the tag is left. For example you want the red side of that tag to face front for tag_weapon. This corellates to the right-hand rule:

Does the base AT-ST have this same problem? The bone jitter was an issue with Carcass-- which is now resolved.

good discussion topic... (MD3 = tag_* and GLM = bolt_* ). Could your bolt be mirrored? I'm driving from Vegas to Palm Desert, CA. will post as soon as I can.

Yes, SP.

I'm wondering how difficult would it be to append ragdoll physics to some parts of the skeleton-- rather than have everything done as animations. For example... if we had a new animation to jump and grab a ledge (either a canyon-like gap or higher cliff edge)... the jump would start off as "BOTH" and grabbing the ledge would end up on the "TORSO" group of bones... but it would be nice if ragdoll physics could be applied to the LOWER/LEGS section... and finally dampen to a set LOWER/LEG pose. It would offer variability and not always look the same. Thoughts?

...a walkway, that no one can walk on, with a view no one can appreciate-- except powerful Jedi... My philosophy is that all architecture and structures should have a function/purpose... when stuff like this is out of place/unreachable by the Imperial personnel that built it-- it breaks the immersion experience. Imho.

then how would non-jedi reach the catwalk? If they can't, then the catwalk serves no real functional purpose...

Hmmm... catwalk screams for an access ladder-- you could model a ladder and use the ladder brush and @@eezstreet could incorporate @@DT85's SoF2 ladder code from the DF2 repo... just a thought-- and a new feature!

could you just use an texture image FX runner that would repesent a steel cable for lowering/raising crane magnet? (I don't really know what I'm talking about here-- just an educated guess).

Well, I look forward to your experiment results.

Thanks! If you made it a new keyword option on light entities then folks could choose themselves to use it or not... According to that paper the performance hit is minimal:

@@Xycaleth - did you download that PDF?

@@Xycaleth - how then do you accurately compute the dynamic lighting for a certain type of light? I think light entities should have a editable parameter that would accept an .ies file... which if left blank would do things as you currently do... but given the .ies file I would think it would simplify the computations for a light, no? http://www.cescg.org/CESCG-2013/papers/Krochmal-Real_time_prototyping_of_physical_lighting_based_on_goniometric_light_sources.pdf

Would it not be possible to lock out the player movements but have the joystick movements then drive the crane?

So in your Dynamic lighting calculations can you use the true .ies data file that almost all lighting manufacturers now generate and create for all their lights?