Racing engine script?

[Nash]

The new camera is very smooth but it doesn't behave like GTA's/Skyrim's where you can rotate it around the player, like TZK's camera. Can you (TZK/Gooberman) add that feature and possibly release it an isolated example from which I can learn from?

[The Zombie Killer]

@Nash
I was actually going to add that back in after I posted that small bit of code, but procrastination got the better of me. I'll see what I can do right now

[GooberMan]

@The Zombie Killer: Yeah, I ended up working out the problems myself last night. I foolishly expected UniqueTID to give me three unique TIDs in a row, but that's not at all how that function works. It's all sweet on my end right now. Load up MAP13 if you've got working code on your end and IDFA. It's stupidly fun driving around Arachnotrons and taking them out.

@Nash: Rotating around the player with the way I've got it set up won't quite work. It's designed to snap right behind the player at all times. You can certainly expand the code with minimal effort to track a completely separate rotation value (hint: rather than GetActorAngle( ActivatorTID() ), you'd keep a separate value around) and then bind some keys for camera rotation, but that's not personaly how I'd go about making a third person camera.

The general way the industry does things is that the player's rotation is defined by the forward camera direction and what direction you're pushing on the movement stick/WSAD keys/whatever. That's not at all how Doom's movement is set up, being a first person game to the bitter end.

I am thinking on how to expand it some more, but I'm not going to do the easy wins myself.

[GooberMan]

Actually, here's my latest.

[Enjay]

I really like how this is shaping up. Once someone adds "fluff" like engine sounds, possibly tyre squeals and puffs of dust etc, it will be really quite a convincing vehicle. It's easily the best I've seen in Doom so far.

[GooberMan]

Yeah, and yet I still think what I've got so far is amateur stuff There's plenty I need to do to it before I'm satisfied with it.

By all means, go and play with what's there. But I think I'll launch a thread in the Projects forum when I'm done with Prime Directive with some of my plans.

EDIT: And I'll probably make it a collaborative project too. Plenty of other stuff on my plate is wanting my attention.

[The Zombie Killer]

The only real thing that's bugging me is the fact that you can't reverse, and the fact that the camera seems to constantly get stuck on walls.
I added the vehicle sounds from that "doomkart" mentioned earlier in this thread to my old example shortly after I posted it here. They suit the car voxel pretty well

[GooberMan]

The only real thing that's bugging me is the fact that you can't reverse

Yep. I'll be addressing that later once I get some more of the framework in place. You could fudge it by now by giving a negative accelleration bound to the back key. It's "enough" but in my experience it gives handling artifacts.

and the fact that the camera seems to constantly get stuck on walls.

I haven't worked out a clean way to handle the interpolations between previous and current camera positions yet. I think there'll always be cases where it interpolates through walls, but I don't like that.

[The Zombie Killer]

I think the "stuck on walls" issue could sorta be [temporarily] fixed by trying to spawn an actor at the position and modifying the variable for the interpolation points in accordance, kinda like how the camera I used in my example works.

This is the code I'm talking about:

Code: Select all

While(!Spawn("CameraActor", x-cos(a)*xyr, y-sin(a)*xyr, (z+camViewHeight)+sin(p)*r, cameraTID[playerNum], a >> 8) && r > 0)
{
	r -= camRadiusAdj;
	xyr = cos(p)*r >> 16;
}

[GooberMan]

Indeed. The only reason it gets stuck on walls is because SetActorPosition() fails and I don't handle that. The standard method I've noticed (and that I believe you used) is to start from a minimum distance from the player and push out incrementally from there.

I'd rather requrest a ray cast function get added and exposed to ACS so I can query exactly where I should be pushing out from.

EDIT: posted before you edited in your script.

[The Zombie Killer]

I'd rather requrest a ray cast function get added and exposed to ACS so I can query exactly where I should be pushing out from.

I suppose you could do something like that by abusing [wiki]LineAttack[/wiki]
Edit: It'd be really helpful if LineAttack allowed you to set the tid of the puff it spawns though

[GooberMan]

Eesh. Yeah, I think I can see how you'd abuse that. The main disadvantage, apart from it being ugly, is that it would also hit actors. I don't want to hit actors.

[The Zombie Killer]

I think I know a way to bypass the hitting actors part.
It's EXTREMELY hacky though. Lemme see if I can whip up a quick example

[Gez]

I don't remember if [wiki=Actor_flags#THRUACTORS]THRUACTORS[/wiki] is handled by puffs or not.

[The Zombie Killer]

I don't think it is, sadly. That was what I was going to use to try and get it to work.