My feelings on the Star Wars mod.

However, I was using the collision hull for the custom reactor object. Perhaps the LOD determination is based upon the player distance to collision hull (instead of avatar). Which makes sense; the engine already pulls info out of the CH file.

I am still willing to bet this is true. Mostly because very long objects drop to high level of detail when I get near one end. And they would not do that unless it was using collision hull. (Since I might still be 2km from center).

If it is a mass calculation problem, then you need a collision hull that is a very thin shell. A sphere has largest possible volume to surface area. What you want is minimum possible volume, maximum surface area. A sheet of paper. In this case, curved into a death star.

Which brings up an interesting question. Does a collision hull need to "surround" and object? I mean, normally, that is what you want. But in a case like this, it is good enough that the collision hull covers one side, and acts more like a shield. So the question arises, what happens when the model is outside of the collision hull?

Nothing I expect. Except if the player finds a gap, he can get inside it. Oh, wait, maybe I want that to happen....


-Gtrout

First, the work part:

If we break the DS down into pieces it won't show in the HUD Target window as a single object but only as a piece of the whole thing. The hud target marker (parenthesis around contacts) will show a whole bunch of objects piled up together and not the whole DS.

To explain this;
The shots below show the same station with different collision hulls.
note the size of the station in the "Target lock" window and the size of the target marker around the object in the hud view.

the station with a STC collision hull, fits in the window just fine
the same station with a cargo pod as the collision hull only shows part of an enlarged view
now the avatar with no collision hull at all. it's tiny ain't it?

The avatar mesh of the model is scaled (sized) into the target window in relation to the hull size.
As you see, the hud target marker (parathenesis around targets) is also determined by the size of the hull. (It's either the collision avoidence radius or the collision detection radius.) These are always round and don't conform to the shape of the Hull itself.
(Apparantly, in the case above with no collision hull some kind of default is being used to determine the detection and avoidence radius)

The huge DS may not be showing because the player is already inside the detection radius? (or whatever radius.) It could just as well be that the scaling function to fit the target in the window is rolling over and thats why the Hud shows the "1.$" (which may or may not be the reason the object doesn't show at all.) But this isn't the real problem!

Obviously, since you would never be able to target the split up DS as a whole you could fake a target (shown in the Target window) by making each piece of the DS with a round avatar and a round collision hull.

Collision hulls will overlap when docked via pog so that isn't a problem, Also, when a sim is docked (or child attached) the docked sim isn't shown as part of the parent sims mesh in the Hud target window. therefore the issue with multiple contacts for each piece (and each with it's own marker paranthesis on the hud) is resolved too once the sims are docked together. (Like on a freighter: you can't see the cargo pods in the target window representation of the freighter, but you can see the pods visually if you get close)

Key for the whole thing would be: Each piece needs to have a round avatar where only a part of it is really visable (via the channel switching function or LOD switch). That way the avatar wouldn't have to be the size of the whole DS either. It would only need a diameter as large as the part of the (curved) surface area it represents-
!! assuming you can put the visable textures of an avatar in the middle of a round avatar!! (or make the surface of the avatar transparent like the green house covers on Haven station)

Shane, SecondChance, do you moddeler guys think that's possible?

Sure, that would be a whole lot of sims to tile together to make a DS but since they are practically "hidden" when docked and the channel not visable until the LOD (or channel switch) kicks in, it shouldn't load down the engine too much or not?
I can try that out and see what the effects of several hundred docked sims have on the engine. I'll get back to you on this later.


Now, to the fun part:

Originally posted by GrandpaTrout


I am still willing to bet this is true. ......

no use in betting at this stage.
The game could just as well use the collision avoidance radius or collision detection radius to calculate visual functions like LOD.

Which brings up an interesting question. Does a collision hull need to "surround" and object? I mean, normally, that is what you want. But in a case like this, it is good enough that the collision hull covers one side, and acts more like a shield. So the question arises, what happens when the model is outside of the collision hull?
....

-Gtrout

This is kind of paradoxial isn't it. It's based on lack of knowledge and not on useable knowledge. Thats a paradoxial situation:
(i.e it's imposible to prove that something doesn't exist because logicaly (and scientifically) you can only prove existance)
This kind of post could lead others to feel they are being challenged to go out and validate your ideas. (which takes up others time)
If you want to contribute it would be usefull if you provide either factual information or validate some basis for your ideas first.
You could write a test code package to dock several hundered sims together if you'ld like?









Iwar2 Multiplayer Fan Site

Originally posted by Second Chance
I'm not sure if it will help in this particular case, but Steve Robertson told me that the dimension data in the INI's works with the collision detection and collision warning. What length, width and height did you make the Death Star in it's INI?

I set the values to equal the rough size of the collsion hull, and a couple of times tried setting them lower. I never saw that they made any difference.

Originally posted by GrandpaTrout
Which brings up an interesting question. Does a collision hull need to "surround" and object? I mean, normally, that is what you want. But in a case like this, it is good enough that the collision hull covers one side, and acts more like a shield.

The Puffin tug collsion hull features single polys which make up the ends of the 'wings'. These do not enclose an area, but are solid in the game.

I'd thought of using a 'shield' collision hull also when the parts get broken down into sections.

But I'll make the changes needed to the model, then dice it up into sections and we'll see where we stand.

Man, I love modding EoC, but I seriously hate this 'black box' crap. We all should have written our own engine.

<font size="1"><font face="Book Antiqua"><font color="black">"Never before in the history of the world had such a mass of human beings moved and suffered together. This was no disciplined march; it was a stampede-- without order and without a goal, six million people unarmed and unprovisioned, driving headlong. It was the beginning of the rout of Civilisation... of the massacre of Mankind."
--H. G. Wells The War Of The Worlds</font id="black"></font id="Book Antiqua"> </font id="size1">

Why not just make it so that the core sphere we are docking everything to is the only object visible to sensors. You can kill the sensor visibility of everything else using pog. Assuming the core is only a little bit smaller than the overall spherical shape of the ds, the parenthesis type box should end up close enough to the right size.

(It's either the collision avoidence radius or the collision detection radius.) These are always round and don't conform to the shape of the Hull itself.

I don't think that's correct. If that were the case, then the length, height and width entries in the INI would be irrelevant. But since these entries supposedly affect the collision detection and collision warning systems then they must use a bounding box instead of a bounding sphere. Certainly there are plenty of 3D engines that even give you a choice of using bounding sphere, bounding box or per polygon collision detection (sometimes even changing on the fly). So they're not always round.

That way the avatar wouldn't have to be the size of the whole DS either. It would only need a diameter as large as the part of the (curved) surface area it represents-
Shane, SecondChance, do you moddeler guys think that's possible?

I'm not entirely sure I follow what you're saying. But if each piece was a full sphere, then each sphere would have to be the entire size of the Death Star in order for it to have the proper curvature and fit with the other pieces.

*edit*
I just understood what MajorTom was getting at above (you're talking about the size of the piece, I thought you were talking about the curvature of the piece), and yes, I think that would work fine. See below.
*edit*

I definitely do think, though, that Shane should build one huge detailed Death Star and then just simply chop it up into something like 20-40 seperate models (each with it's own appropriate CH). Then have all those pieces simply docked to an invisible central structure that would serve as the hud target (a la MajorTom's idea).

I set the values to equal the rough size of the collsion hull, and a couple of times tried setting them lower. I never saw that they made any difference.

Oh well, it was an idea. Maybe the Death Star is too big. After your discovery of the short int issue I asked Steve Robertson if there were more. Here's his answer straight from the email:

I really don't know what other short ints are in the game. I presume quite a few of the ship properties would use them simply because it's more efficient that way.

Could the short int issue be what's causing the problems?

mailto:second_chance@cox.net
The Ultimate Guide To Modding: I-War 2 - Edge Of Chaos (on hold during SW MP mod)
cartoons.sev.com.au/index.php?catid=4
.

Originally posted by SecondChance
Could the short int issue be what's causing the problems?

I believe so. As Steve said, it wouldn't make sense to have a long int which, in the common use of the game, will top out at a value of 2300. It's a waste to do it that way; the bits start adding up, and games have to be more optimized than any other program.

I'd imagine the size of the Death Star is rolling some poor, innocent short int into the negative (to the dark side ) and Flux goes banannas.

<font size="1"><font face="Book Antiqua"><font color="black">"Never before in the history of the world had such a mass of human beings moved and suffered together. This was no disciplined march; it was a stampede-- without order and without a goal, six million people unarmed and unprovisioned, driving headlong. It was the beginning of the rout of Civilisation... of the massacre of Mankind."
--H. G. Wells The War Of The Worlds</font id="black"></font id="Book Antiqua"> </font id="size1">