is there any way to make UT collide with polys and not the cylinder around the model? i would REALLY hate to chop my structures into cubes to make them collide right.
Thinking outside the cylinder...
- Thread starter FireSlash
- Start date
-
Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.
A cube would have been better in my case too... Just figure out some way to use multiple cylinders. Why, what do you need to make?
Eater.
Eater.
One idea:
Make a subclass of mover and recode it to make it work the way you want.Now one big problem is that your actors will be map dependant ....unless you find a way to import BSP geometry into a map on the fly .(that might be possible...)
Make a subclass of mover and recode it to make it work the way you want.Now one big problem is that your actors will be map dependant ....unless you find a way to import BSP geometry into a map on the fly .(that might be possible...)
No, it's not. Any geometry needs to be rebuilt (trust me, I've tried... ugly errors). No way to insert geometry on the fly.
As for using a mover, the biggest problem with that is that a mover doesn't collide with level geometry.
Eater.
As for using a mover, the biggest problem with that is that a mover doesn't collide with level geometry.
Eater.
Well, it's not a different object, if that's what you mean. If it's coded anywhere, it would be in the Actor class, but I believe it's somewhere in the native code.
Eater.
Eater.
Me to would like to find out where the heck the cylinder is defined, since I've been looking for it for a long time...
Anyone knows?
Eater1, now you have crushed my hopes and dreams...
I wanted to make a GeoMod-Mutator.
You've seen red fraction, haven't you?
It's based on the "GeoMod" 3D engine, which has the capability for, as the name states, demolish the geometry...
The idea I had was to make weapons that, when doing damage to the level, they should leave a subtraction-brush there in the shape of a more-or-less round shape ((de)intersected ofcourse (whichever's right for sub's))
If the engine had been capaple of that, it would certainly rock your pants...
Imagine that ig you blast the wall with the RL, you carve out a meter-wide hole, spreading the gravel on the floor...
And then Imgaine the redeemer... Whoo!
There's no way you could hide behind a glass-window, or anything incredible like that, when it comes flying...
You make me sad
Well, let's hope you have that possibility in Unreal 2
Since they have dynamic raytracing, then why not have dynamic rebuilds...?
Anyone knows?
Eater1, now you have crushed my hopes and dreams...
I wanted to make a GeoMod-Mutator.
You've seen red fraction, haven't you?
It's based on the "GeoMod" 3D engine, which has the capability for, as the name states, demolish the geometry...
The idea I had was to make weapons that, when doing damage to the level, they should leave a subtraction-brush there in the shape of a more-or-less round shape ((de)intersected ofcourse (whichever's right for sub's))
If the engine had been capaple of that, it would certainly rock your pants...
Imagine that ig you blast the wall with the RL, you carve out a meter-wide hole, spreading the gravel on the floor...
And then Imgaine the redeemer... Whoo!
There's no way you could hide behind a glass-window, or anything incredible like that, when it comes flying...
You make me sad
Well, let's hope you have that possibility in Unreal 2
Since they have dynamic raytracing, then why not have dynamic rebuilds...?
Heh... Keep hoping, although I very strongly doubt it. And yes, I'm completely, 100% sure that it can't be done... Back in the days of Unreal 1, I spent over a month trying, and all I have to show for it is a gun that generates a very pretty error message when fired.
Eater.
Eater.
Lol
BTW I'm not sure that it is impossible to import geometry without rebuilding.Think about it.
When a mover moves it can be calculated in a virtually infinite number of position (depending on the framerate of the computer playing UT).So we can say that the number of positions for a mover can be infinite.So the engine Has to do some kind of interpolation sometime (the mover class uses a function called 'interpolateTo' to make the brush move) .You cannot say that all the positions of the mover are computed once and for all.
Moreover a mover can be 'attached' to another mover or another actor (using uscript) making it impossible to assume with anticipation all its possible positions,so the engine has to compute the Geometry 'on the fly' somehow.And what about semisolids huh?
There is a difference between moving geometry and creating geometry out of thin air. If you have the wall as a mover to begin with, you don't even need to code anything to make it destructable (just make it damage triggered). Even semi-solids needs to be rebuilt.
[EDIT]
Oh, by the way, you are right that movers can have an infinite number of positions, and I have a much better proof for that: I've made a mover that follows several meters behind the player... It's VERY easy to make. A mover is basically a moving brush, so it can move, but that still doesn't mean it can be created or destroyed (well, maybe it can be destroyed... I'm not 100% sure on that one).
Eater.
[EDIT]
Oh, by the way, you are right that movers can have an infinite number of positions, and I have a much better proof for that: I've made a mover that follows several meters behind the player... It's VERY easy to make. A mover is basically a moving brush, so it can move, but that still doesn't mean it can be created or destroyed (well, maybe it can be destroyed... I'm not 100% sure on that one).
Eater.
as for the BSP:
You can, under no condition, move walls. End of discussion. As a matter of fact, it is impossible to access them.
as for movers:
You cannot create them at all. HOWEVER, it is possible to move or rotate them in any direction. Yet you cannot have them break apart of have anims and stuff. (vertex minipulation is not possible).
thank you.
as for meshes with poly by poly collision, forget about doing it in uscript. With luck, you might be able to pull it off in native code, but even when someone wrote skeletal collision code it was quite difficult.
You can, under no condition, move walls. End of discussion. As a matter of fact, it is impossible to access them.
as for movers:
You cannot create them at all. HOWEVER, it is possible to move or rotate them in any direction. Yet you cannot have them break apart of have anims and stuff. (vertex minipulation is not possible).
thank you.
as for meshes with poly by poly collision, forget about doing it in uscript. With luck, you might be able to pull it off in native code, but even when someone wrote skeletal collision code it was quite difficult.
Exactly... Just what I've been saying all this time.
Anyway, as for poly-by-poly collision, correct me if I'm wrong, but aren't They (with a captial T) planning to include it in Unreal 2?
Eater.
Anyway, as for poly-by-poly collision, correct me if I'm wrong, but aren't They (with a captial T) planning to include it in Unreal 2?
Eater.
Couldn't you make stuff out of pieces? For example, a player's torso could be one actor with its own cylinder, its head could be another actor with its own cylinder, etc. and have one part controll all the other parts and would keep track of damage. So when one of the arm actors was hit, it could do however much damage it took to whatever part is keeping track of everything.
It could prove difficult to keep it all pieced togehter correctly.
Althoug you could do a "body"-piece which has a mesh and cylinder, and then add on block-actors as arms, heads where the mesh "exits" the cylinder, which would give more accurate hit-detection...
Again the problem is to hold the pieces in the correct place.
Unless there's some very good way of checking how the mesh moves, it's gonna be hard...
Maybe it'll work with seletal chars, if you get the vectors from the skeleton...
Althoug you could do a "body"-piece which has a mesh and cylinder, and then add on block-actors as arms, heads where the mesh "exits" the cylinder, which would give more accurate hit-detection...
Again the problem is to hold the pieces in the correct place.
Unless there's some very good way of checking how the mesh moves, it's gonna be hard...
Maybe it'll work with seletal chars, if you get the vectors from the skeleton...
Actually it is surprisingly simple. Just set each pieces "base" to another. You will need to take care to ensure that collision is universal, but oh well
Ah... I think I see what you're getting at usaar... You will need to explain it a little more however.
var const Actor Base; // Moving brush actor we're standing on.
This is the Base variable in the actor class. Now, although it says "moving brush" in the comment, the variable is of the type actor. I assume what you mean is that if the player's torso is the actual player and is set as the base of the arms and the head, the arms and the head would follow it, correct? I've never made use of Base before which is why I'm asking. Would they keep their offset from the player's location as the player moved around and even rotated? I'm too lazy to test this out at the moment...
Eater.
var const Actor Base; // Moving brush actor we're standing on.
This is the Base variable in the actor class. Now, although it says "moving brush" in the comment, the variable is of the type actor. I assume what you mean is that if the player's torso is the actual player and is set as the base of the arms and the head, the arms and the head would follow it, correct? I've never made use of Base before which is why I'm asking. Would they keep their offset from the player's location as the player moved around and even rotated? I'm too lazy to test this out at the moment...
Eater.