Told ya. Those vehicles textures don't have MipMaps for some odd reason. "Auto generate mipmaps"?

#exec? Why not UEd->Import->OK All?
And why won't mipmaps work then? D3Ds complain only about them.

Hmm? I did it with my MM7 textures and it works fine in all UT, U1 and U1(227) versions...

I am surprised it works at all in UT

As I saw you can script native side, there's any chance on making the Vehicle Physics native side?

It's ok if you want to let these only UScript side, I just only see a lot of more potential on these if they are coded native side, that's all 

GreatEmerald wrote on 09/16/08 at 19:12:25:


It depends on how realistic the vehicles would be (collision, environment variables, traction, etc). In this case I just asked if what was scripted UScript side, could be done in native side instead (talking about VehiclePhys here).
I never scripted native C++ for Unreal or UT (but I will try to learn of course), so I can't say exactly what the dificulty of this is, but I imagined that it could be high.

If only Shadow (or someone else) could finish the mesh system work by moonangel, with extended collision and stuff, it would be more easier to script stuff (i guess).

But as the collision isn't extended in any way, all what I ask is that the complex a more resource demanding UScript side functions, could be handled in native side to give better performance and good online support, that's all I ask.

If it can be done, great, if not, that's ok too, then I just have to use the UScript ones instead, with no problems so far (as these vehicles are the greatest ones for Unreal and UT at the moment).

Sorry to revive this thread, but I need to ask something to Dots about his vehicles:

Dots, why didn't you use the vehicle attachments with the Physics=PHYS_Trailer instead of coding SetLocations?

Think about this, it would be a big improvement in your vehicles performance and it would reduce pings everywhere online, it wouldn't be laggy sometimes.

You just have to make the attachments to calculate their PrePivot relative the the Owner rotation (the main vehicle), set the bSameRotation thing to False. The rest of the code would be maintained, and so, the Location update would be handled in native, while the attachment itself would handle the PrePivot values.
I say this because I made this in some projectiles I made for one weapon pack I made.
The trail Prepivot would be correctly updated this way:

Code:

var vector PrePivotRelative;

function Tick( float DeltaTime)
{
	local vector X, Y, Z;

	Owner.GetAxes( Owner.Rotation, X, Y, Z);

	PrePivot = PrePivotRelative.X * X + PrePivotRelative.Y * Y + PrePivotRelative.Z * Z;

}
 

The SetLocation way, very laggy, but the Trailer way, non-laggy at all, and the attachments don't have collision, so everything's cool. You would just set the Prepivot to the Offset from the vehicle and done.  

So, when you have time, tell me something about this way, a flaw or if it's really possible to aplly in your vehicles.

Oh, ok, I'm glad to hear that you are working in native side 

But it would reduce a lot of the lag turrets updates in the UScript side version, but well, I learned something today and I will wait for the release of the native side ones 

So far, very GJ, keep going

Physics updates are working correctly, it all seems fine except for that the vehicles mysteriously lose collision for no apparent reason

Well its more like the vehicles have collision to the client, but on the server they don't..