HOWTO : Basic vehicle mod

[BigJim]

Excuse me for being thick, I just want to double check something.
I've done a load of simple coding for my singleplayer campaigns in 2K4, but I'm still very confused with UT3..

Ok, so using the Scorpion as an example, because it's pretty simple (kinda like me )..


So, UTVehicle_Scorpion_Content extends from UTVehicle_Scorpion, that means for a basic subclassed Scorp we can just extend from UTVehicle_Scopion_Content.

I understand that suclassing from the "_Content" class would mean that all the sounds, meshes, etc.. from the original scorp would also be loaded into memory, but then again we will need all that anyway, so no harm done.

What I'm confused about is where functions & variables are divvied-up between these two classes.
For example;

From UTVehicle_Scorpion;

defaultproperties
{
	Health=300
	StolenAnnouncementIndex=5

	COMOffset=(x=-40.0,y=0.0,z=-36.0)
	UprightLiftStrength=280.0
	UprightTime=1.25
	UprightTorqueStrength=500.0
	bCanFlip=true
	bSeparateTurretFocus=true
	bHasHandbrake=true
	bStickDeflectionThrottle=true
	GroundSpeed=950

These are pretty important values, and ideally I would like to modify things like health and speed without having to subclass an extra class.

So, if I want to modify say the groundspeed and max health, do I *have* to subclass UT_VehicleScorpion, or, can I override these values in my subclassed UTVehicle_Scorpion_Content?


And if I can override them, can I just declare the new default properties at the bottom of the script, or do I have to use an actual function (like, PostBeginPlay for example) and actually set the new value.

For example
In UTVehicle_Scorpion_Content;

SimulatedFunction PostbeginPlay()
{
 GroundSpeed = Something;
 Health = SomethingElse;
//This is ugly, but if I can't find another suitable function I'm willing to do it
}

Do you see what I mean, or does that make no sense to anyone else?

Same thing with the wheels.
Let's say i want a 4-wheel steered Scorpion.
Do I have to subclass the base Scorpion class, or, can I just add the new wheel declarations to my subclassed UTVehicle_Scorpion_Content class?


Thanks.


*EDIT*
Oh, I'm such an idiot.

Since the _Content class extends from the base class, it inherits all the base class variables & props anyway doesn't it?
Right, so that means that the _Content class *does* have the wheel structs (objects) and all the other values I mentioned, so in theory, all I need to do is extend from the _Content class, and make all my modifications in there, right?

[Xyx]

A subclass inherits all defaultproperties from all base classes. So you can do this:

class 4WDScorpion extends UTVehicle_Scorpion_Content;

defaultproperties
{
    Health=1000000000000
}

[BigJim]

Idd, I was just being thick, it confused me because of the extra distinction between the base class and the "_content" class; Did I read earlier it's so that console developers can scrimp on memory usage for when they want a subclass but without the default meshes, sounds & textures?
That would make sense..


Ok, I've gone in & subclassed me a new scorp straight from UTVehicle_Scorpion_Content just to test everything out, and a new scorp factory, to spawn it in-game.

Compiles fine, and *appears* fine in the Ed (my CombatScorp factory appears in the actor browser, and it can be placed and all that) but I can't get it to appear in-game. :/

Hmms. No compile errors, no warnings, and everything else seems to be fine (no crazy property values in the scorp factory, for example).

When I try to summon it via the command line ("Summon UTGame.UTVehicle_CombatScorp_Content") the game hitches for a second (like it's loading something), but then nothing appears - btw I'm testing in a renamed Torlan, just so I can be double sure that the test-map is configured properly for vehicles.


I've tried rebuilding the reachspecs, to make sure that the custom factories are part of the network, I've gone through all their properties to make sure they're not disabled or doing anything equally silly, I'm a bit stuck tbh, & it's a bit embarrassing really, because while I'm nowhere near Xyx' level of proficiency, I could have done all basic this stuff with my eyes shut under 2K4.. :/

[CaptainSnarf]

Summon UTGame.UTVehicle_CombatScorp_Content

"UTGame" is the package name. There is already an internal package called 'UTGame' so I doubt that's what your package is called.

If this is your source file:

src/VH_CombatScorp/Classes/UTVehicle_CombatScorp_Content.uc

then this is your summon line

Summon VH_CombatScorp.UTVehicle_CombatScorp_Content

Hope this helps.

[Geist]

You should also check the launch.log (in your MyDocuments\...) to see if it spit out anything that could clue you in on the problem.

[Xyx]

There's a shortcut for summoning vehicles... I'm not sure if it only works for Epic's vehicles, but you could try this:

summonv combatscorp

Let me know if it works!

[BigJim]

Thanks!
Yup, one I used the proper summon string, now it will summon into the game ok, so that means it must be the factory that's causing the problem.

Now, since I had the wrong summon string, it's possible tha my factory is using the wrong classname string too;

// current string
VehicleClassPath="UTGameContent.UTVehicle_CombatScorp_Content"

//..change to..
VehicleClassPath="VH_CombatScorp.UTVehicle_CombatScorp_Content"

I think thats the problem. Will update in few minutes.

[D-Hunter]

That would be a big problem, there's no way your classes exist in default packages.

[BigJim]

Yup!
Although in my defence, it was very very late when I compiled, so the miss-type slipped past me..

Ok, compiles fine, and spawns fine via it's factory into the game - cool.
I still can't get the 4-wheel steering to work - When I set;

//Reverse the steer factor for rear wheels, like the Paladin does
Wheels(0).SteerFactor=-1.0
Wheels(1).SteerFactor=-1.0

I get a couple of compile warnings, not errors, but warnings, complaining over a missing "="
It seems like it doesn't like the "=-1.0" line, but then again the Pally uses the same syntax so I need to figure that part out.

Ok, next job is to work on the custom weapon, a kind of modified plasma-caster (like the manta bolts, but smaller, almost like tracer-fire), then custom skins, then I'll try & come back to the steering - hopefully I'll have learned a bit more by then.

[D-Hunter]

Can't you (technically/in theory) have your entire vehicle in one class (like in UT2004) since one class just extends the other? Like extend UTVehicle_Scorpion_Content and have defaultproperties for MyVehicle and MyVehicle_Content in one big class?

[Geist]

...

Ok, compiles fine, and spawns fine via it's factory into the game - cool.
I still can't get the 4-wheel steering to work - When I set;

//Reverse the steer factor for rear wheels, like the Paladin does
Wheels(0).SteerFactor=-1.0
Wheels(1).SteerFactor=-1.0

I get a couple of compile warnings, not errors, but warnings, complaining over a missing "="
It seems like it doesn't like the "=-1.0" line, but then again the Pally uses the same syntax so I need to figure that part out.

...

Nope, you can't override these object attributes in that fashion. Use this format instead (I just tried it and it works... very cool turn radius now!)...

Begin Object Name=RRWheel
    SteerFactor=-0.75
End Object

Begin Object name=LRWheel
    SteerFactor=-0.75
End Object

It appears that as long as you don't specify a Class=XXX in the "Begin Object" block (yet you keep the same Name), you will be overriding attributes instead of specifying a new object.

Can't you (technically/in theory) have your entire vehicle in one class (like in UT2004) since one class just extends the other? Like extend UTVehicle_Scorpion_Content and have defaultproperties for MyVehicle and MyVehicle_Content in one big class?

Yes, you can do this, as mentioned in a previous post. However, I can only guess, but it seems that the non-content and _Content classes were created to separate dependent assets from the functionality. I'm not sure if this is really still beneficial, since the Paladin and Nemesis do not have a _Content class (i.e. whatever required the split of classes may no longer be in the game anymore).

[BigJim]

Nope, you can't override these object attributes in that fashion. Use this format instead

Ah - thanks!

So it seems that if I want to modify a struct, then this is the way to do it. Thank you, I'll make a copy of that post & keep it in me' notes.

I have quite a few custom actors that I'll want to port over after I've figured out all this basic stuff which use custom structs so this is very useful information.

[Geist]

Glad I could help. However, to clarify, this isn't a struct. I'm not sure of the official name for it, but I think it's a template or archetype.

[CaptainSnarf]

http://utforums.epicgames.com/showthread.php?t=596733

[aberghage]

Out of curiosity, did you have to do anything in particular to get the cut 'n' pasted nightshade cloaking to fade in and out, and fade colors on fire and hit? I was fooling around with it and couldn't seem to get that working. Also, I'm running into trouble getting the AI to respect that a vehicle is cloaked - No matter what IsInvisible (I think that was the name of the function) returns, they still see it and shoot it.

~aberghage

[CaptainSnarf]

Out of curiosity, did you have to do anything in particular to get the cut 'n' pasted nightshade cloaking to fade in and out, and fade colors on fire and hit? I was fooling around with it and couldn't seem to get that working. Also, I'm running into trouble getting the AI to respect that a vehicle is cloaked - No matter what IsInvisible (I think that was the name of the function) returns, they still see it and shoot it.

~aberghage

OMG the cloaking. It turns out I had to rework the project to make it work.

Making the vehicle cloak on the client is pretty straight forward. You swap out the skeleton's team material with the cloaked material. To make that work across the network the bIsVehicleCloaked is replicated across the network.

Unfortunately none of that matters for bots. Bots only care about the IsVisible() function. You can define a function IsVisible(), but it won't matter and wont' be used, as far as I can tell. Instead, you must derive your class from UTStealthVehicle, which has the ToggleCloak() and and the native IsVisible() functions that you need.

Deriving from UTStealthVehicle has it's own set of issues, as it derives from UTVehicle_Deployable. You have to disable all the deployable stuff if you want a stealth vehicle that isn't also a deployable vehicle.

I had cloaking sort of working before, but when I changed to UTStealthVehicle it fixed a couple issues I was unsure of, like the invisible skin color changing when you fire or get hit. That magically started working when I switched base types.

Even after all of that, I still have an issue in that UTStealthVehicle PostBeginPlay() assumes the mesh has a skeleton bone named 'deployyaw' or something like that. I get a warning in the log window because of it with no easy way to fix it. It still works, just throws a log warning.

[aberghage]

I love these somewhat critical components which seem to be ALL implemented natively - I was working on a cloaking flyer.

I have cloaking working in multiplayer, but bots ignore it completely. Also, gravity still makes it fall when it by right should be flying. I can get cloaking fixed by changing the base to UTStealthVehicle, or I can get flying working by changing the base to UTAirVehicle. Before this I was writing an extension of UTVehicle with code from UTHoverVehicle, UTStealthVehicle, and UTAirVehicle (oh fun).

To keep this one afloat (no pun intended) I'm thinking I'll have to rework it based on UTStealthVehicle and override the SetInputs to set the Z force equal to GetGravityZ() (I think that was the function, not looking at the source atm) when you're not pressing jump or crouch.

Thanks for the info though, that confirmed my suspicions XD.

~aberghage

[Mr Evil]

Looks like Epic should have made use of the new Interfaces feature available in UScript...

[CaptainSnarf]

Hmm. A flying, cloaked vehicle? You are going to have a tough time between UTAirVehicle and UTStealthVehicle.

When trying to make the flying manta initially I thought all I had to do was swap out the SimObject from the Raptor into the Manta and it would fly like a Raptor. That didn't work though. I had to change the base class type from UTHoverVehicle to UTAirVehicle in addition to changing the SimObject. Then it would fly, and I'm not sure whats different about the two that makes one fly and not the other. Maybe it's the GetGravityZ() thing like you say...

Assume you get a flying cloaked vehicle working by basing it off of UTStealthVehicle and the bots honor the IsVisible() flag.

Don't the bots need it to be a UTAirVehicle for them to know how to fly? It won't matter if they honor the IsVisible() flag if they all fly up into the corner because they don't know what to do with a UTStealthVehicle that can fly, right?

I don't want to discourage you, just playing devils advocate. I would definitely try it out and see if it works.