Requesting New Recon Droid model and Collison Fix

[411Remnant]

I am currently working on some storm commando units and I really wanted incorporate some commando inspired equipment. I thought it would be a cool idea to get some new probe droid models to work as recon droids. So I tried re-skinning the BF2 auto turret model and  replaced the geometry on the remote probe droid's ord odf. Unfortunately there is a problem with collision with that model, it can move but it cant go through doors and has problems moving over some objects.  My Request if possible  for this is if someone would be willing to fix the collision for this model to work as a recon droid. And if possible get rid of those square things underneath the droid please. I know Republic Commando(the user) released a auto turret model to be used a probe droid, but that has the same problem as the Bf2 version.

Specific Auto turret Model:
http://www.mediafire.com/download/o8c54d491r6mbgb/auto_turret_recon.rar





My second request is for a new model like this to be made and to work as a recon droid replacement for the rebels:



I think this one could have the potential as well to be used by other modders beside myself. Does not necessarily have to be skinned like it, the overall structure is what interests me. If any of these requests can be met, I would be very grateful.

[tirpider]

Unfortunately there is a problem with collision with that model, it can move but it cant go through doors and has problems moving over some objects.  My Request if possible  for this is if someone would be willing to fix the collision for this model to work as a recon droid. And if possible get rid of those square things underneath the droid please.

For the first one, here is a test model. (test_com_weap_inf_dropturret2.rar)
-edit removed, cause RC did it below
Just a test, mind you.
I just removed the collisions from it. The mungers should be able to compensate.
If it's moving through doors correctly, then I'll try to pull the boxes off the bottom.

[RepComm]

I pulled the boxes off for you Tirps
-Since you're doing that, I'll see if I can get a good collision primitive working (an accurate one atleast)
-edit: Added finished link to last post.

[411Remnant]

Trying tirpider's first then moving onto republic commando's thing. I honestly didn't think I would get this fast of a response . Give me 3 more minutes from now, munging.

Edit: Sweet RC, well ill have to remunge now.  may take 10 minutes to test . Thank you both for this!

[RepComm]

Trying tirpider's first then moving onto republic commando's thing. I honestly didn't think I would get this fast of a response . Give me 3 more minutes from now, munging.

The one I uploaded is just the MESH without the boxes (3D object, which doesn't include what it needs to move, have collision, gun points, Shadow volume, or gun rotate axis), So tirpider doesn't have to hex them off, if it worked ingame by itself, I'd be greatly amazed :O

I'm testing the full one now.

[411Remnant]

Interesting, well it doesn't have as much trouble going over objects. When he encounters a door, he seems to go under the map and pops back up kinda like a mole. Its a great start! I can get video of it if you need it.

[tirpider]

heh.. wow.. I had to re-install a program to see the boxes and just got them off.

com_weap_inf_dropturret2(no coll no boxes).rar
-edit removed, cause RC did it below

So we know what's going on, this model:
- has had the collisions removed
- has the boxes removed from the mainmesh ans the lowrez
- has had the goofy geometry removed from dummyroot

Current issues:
- when it comes to a door, it ducks below the map. (this has to be because the collisions were removed.)

thinking.....

-edit
Ok, the normal probedroid does have collisions.

Code Select Expand

com_weap_probedroid.msh collisions:
p_sphere
p_buildingsphere

This one

Code Select Expand

com_weap_inf_dropturret2.msh collisions:
p_-so_sphere
p_-vbt_cube

This is where we look in the docs for collision naming conventions.

I see a few possibilities:
- rename the collisions -> happily ever after
- hack the original probedroid's collisions in (may not be lined up appropriately)
- learn how to actually make collisions (not enough hacking)

Any one of them could work.. going to read the docs now.

-edit
Adding the relevant part of the artguide here for all of us:
[spoiler]
Appendix C
Collision Meshes

Collision meshes are simple low-poly meshes that are used by the game engine to calculate when and how objects collide with each other. There are 2 types of collision meshes used in SW BattleFront: collision meshes and collision primitives.

Collision Mesh
1. This is usually a low-poly yet fairly conforming version of the original mesh. It is most often used for soldier and ordnance collision since those are most obvious ways to see collision mesh correctness. For example, you can see the ordnance collision on an object by shooting at it with any weapon. If the collision is sloppy and covers gaps or is not correctly aligned with the original mesh, then you will see the laser blasts hit empty space or inside the actual geometry of the model. The collision mesh has to be named "collision", or if there are more than one, "collision", "collision1", "collision2", etc. Multiple collision meshes will all get merged into one when munged. This is very important when considering rule #3. Do make the collision mesh a child of the root node or its corresponding node, and make sure its global center is at 0,0,0.

2. Enabling the Collision Mesh: if the vehicle .MSH file has a corresponding .OPTION file, then it might contain the argument "-nocollision". This is to prevent generation of a default collision mesh using the model's full geometry. If you have specified a collision mesh in XSI, you will need to remove this argument from the .OPTION file.

3. Collision meshes can NOT be used on moving parts (turrets, bones etc). When the vehicle is munged, all collision mesh nodes are merged into a single non-articulated collision mesh. If a moving part on a vehicle requires collision, it will have to be specified with a primitive.

4. If a vehicle has a collision mesh, it will automatically be used when colliding with soldiers and ordnance. Collision meshes (on vehicles) are not used for any other type of collision. Primitives must be used when vehicles collide with terrain, buildings, and other vehicles.

Collision Primitives
--- Collision Primitives are a cheaper and faster way of computing collision for the game engine. It is also the only way to have collision on moving parts such as turrets or bones. Collision primitives can be either cubes, cylinders, or spheres. Cubes can be scaled in x,y, and/or z to better fit the geometry they are conforming to. It is best to leave the original size of 8 units as is and scale the cube from there. On the other hand, cylinders and spheres CANNOT be scaled. Instead, use the polygon properties such as radius and length to control the size of those 2 primitives. Also very important, primitive collision pieces CANNOT be frozen or lose their primitive properties. This information is taken directly into the game engine and if it is lost, the engine will most likely ignore the primitive collision. Lastly, DO NOT move the center of primitive collision either or else the proper information will be lost as well.

---There is a limit of 32 collision primitives per model (or 31 primitives + 1 collision mesh).

---Colliding with buildings (including bridges, stairways, etc) is a little tricky with primitives. It is best to use spheres and cylinders on the vehicle for building collision. Boxes just get converted to spheres in the code so long skinny boxes end up colliding as if they were large spheres. ***Note: if you must use boxes for the vehicle, you can instead create primitives for the building msh. In the building's odf file, you can then specify to use these primitives for VehicleCollision***

******** Specifying Collision in ODF file ********
---For any game object (true for vehicles and buildings), you can specify which collision primitives will be used when colliding with another object. For example, the AAT ODF file has the following:

TerrainCollision = "p_base"

VehicleCollision = "p_base"
VehicleCollision = "p_tank"
VehicleCollision = "p_barrell"
VehicleCollision = "p_turrett"

SoldierCollision = "p_base"
SoldierCollision = "p_tank"
SoldierCollision = "p_barrell"
SoldierCollision = "p_turrett"

BuildingCollision = "p_ball1"
BuildingCollision = "p_ball2"
BuildingCollision = "p_ball3"
BuildingCollision = "p_ball4"
BuildingCollision = "p_ball5"
BuildingCollision = "p_ball6"
BuildingCollision = "p_guns"
BuildingCollision = "p_turrett"
BuildingCollision = "p_barrell"
If you wanted to, you could also use OrdnanceCollision = "p_whatever" to specify what primitives to use when ordnance collide with the object.

---Finally, if
1. a vehicle has a collision mesh, AND
2. SoldierCollision and/or OrdnanceCollision is specified in its ODF file,

then the primitives specified in the ODF file will be used (for SoldierCollision and OrdnanceCollision) as well as the collision mesh. In this way, you can create a collision mesh for the non-moving parts of the vehicle, and add collision primitives for the moving parts, and use them both when colliding with soldiers or ordnance.
[/spoiler]

[RepComm]

Actually, I added an accurate collision, and it sort of (not as much as) has that same issue. But it has perfect collisions with people and vehicles.

edit: as the last post says, it still needed a primitive.

[tirpider]

Ok.
If it's colliding with people and such ok, but still dips below the map when going through doors....
Does it's ODF have a BuildingCollision line?
Seems like that would fix it.

[RepComm]

Ok.
If it's colliding with people and such ok, but still dips below the map when going through doors....
Does it's ODF have a BuildingCollision line?
Seems like that would fix it.

Well what do you know! Fixes it, works just fine.
The one collision primitive I created "Collision" is a lower-poly shape of the model itself, when I edit the ODF, I just labeled all the Collisions from what they are to "Collision."  - This replaces all the old funky ones.
-
Is there anything we can do about camera angle, or is this ODF specified?

[tirpider]

Cool!
Camera is all in the ODF. (usually toward the end.)

Now, about that 2nd probe.
I've seen one somewhere, but don't remember if it was a SWBF, SWBF2, TCW, or JK asset...


(btw, I'm comming to you with all my future collision issues, RC )

[411Remnant]

can I get that collision fix line please? 

Also I could have sworn I saw a model like that to but could never find it on gametoast.

[RepComm]

View last post for fixed model.

[tirpider]

After searching through my archive, all I could find in the way of the practice droid is a very low poly one from the Raven_Animation_and_Model_Source_Files (I got them from gamefront)

It's in MD3 format and appears to just be a sphere with a simple skin.

It needs to be scaled and set up with collisions and hard_points and such. (and converted from md3, of course.)

Would probably be easier to build from scratch.. don't know.

-edit.. oh yeah.. the source files include the .xsi
Added them to the rar

And for those interested in source links:
[spoiler]http://jediknight3.filefront.com/file/Raven_Animation_and_Model_Source_Files_Part_1;26624
http://jediknight3.filefront.com/file/Raven_Animation_and_Model_Source_Files_Part_2;26625
http://jediknight3.filefront.com/file/Raven_Animation_and_Model_Source_Files_Part_3;26626[/spoiler]

[411Remnant]

hmm, im still getting some odd stuff. ill go ahead and record some video, this droid must really hate doors