Introduction

Using Drivables

Creating drivables
in the editor

Bot support in maps

Including support
for drivables in
your own MOD

Coding Bot support

Creating your
own vehicle types

Understanding
drivables

Bugs and known issues

Downloads

Contact

History

Since I'm not a crack mathematician, it took me about two weeks to get the 3D calculations right, so I could place a turret on top of something else, etc.
A very simple physics type, float and block, which is basically what Shadow Warrior does, was easily implemented.
I also planned a full-fledged physics type, force calculation, which would, for example, allow a boat to take a ramp.

The force calculation physics proved to be a bit too unknown for me, so I have postponed it, in favor of two simpler methods: orient to floor and terrainfollowing. Both of these will make a vehicle align itself to the floor.

Features

1. A drivable brush can be used to shield you from enemy fire, but will still allow a marksman to hit you, whereas other methods (like USpace, and I assume, Strike Force uses), will shield you always.
2. A drivable can have multiple components, which may be independent. In theory, you can build a battleship bristling with independent turrets. (Oh yeah, that will require quite a heafty 3D card)
3. A drivable brush can be basically any size. I created an oil tanker, however, in order to turn that thing, you need an awful lot of water.
4. For the lazy: there are some ballistics routines in there.

Controlling the machinegun...better be careful: in Unreal 1, the bots are accurate enough to shoot you through this little gap!

Limitations

• In order to get a reasonable network performance, you need to set the server's Net Speed to something faster than 'Modem', otherwise the client will get choppy movement. ISDN/Cable works pretty well - provided you have the necessary bandwidth. It is unlikely that changing this setting will work if all you have is a modem.
• You need a pretty heavy server to get a nice performance, with all the physics calculations going on. You really have to think Pentium-III here, if you're not running a dedicated server.
• In order to support multiple components, there are some arrays that are reasonably big (but they are not replicated, so require no bandwidth). The size of these arrays is just an educated guess, and might prove too small for some mappers. If so, please mail me, so I can increase the size. However, if you hit that limit, chances are that the map will be slow anyway.
• When you create complex brushes, Unreal can occasionally get the BSP wrong, resulting in incorrect behaviour when you try to walk on the drivable. For example, you may sink up to your knees into the drivable, or you may hit an invisible wall outside of the actual brush. If this happens, you will need to simplify the brush, or perhaps, break it up into two brushes.

Even when Unreal gets the BSP right, it sometimes incorrectly thinks that a brush is being obscured by another brush, resulting in the brush being invisible. The brush does work correctly, though.

The Future

I would like to get the full physics model to work... But I'm probably not going to succeed at that without some support, so it's low priority.

Eventually, I'm hoping that Epic will adopt my code and incorporate it into the Unreal engine. I'm positive that technically, that would be a good thing, because the engine might get some small modifications that would make drivables work better (not that I'm knocking my own stuff, they work pretty well). It would also mean that the skills to map drivables in Unreal would be applicable to all Unreal Engine games to come!