Z-Kart discussion

[edward850]

Custom controls for players other than player 1 currently aren't programmed, but I know how to go about it. In the case of Z-Kart, controls will most likely be custom-made with ACS anyway so it'd be even easier to implement.

See, I think you are ignoring me, because as I have already explained you only have 4 generic user binary controls, and that's not enough for full directional movement for 3 other players.

[The Zombie Killer]

Custom controls for players other than player 1 currently aren't programmed, but I know how to go about it. In the case of Z-Kart, controls will most likely be custom-made with ACS anyway so it'd be even easier to implement.

See, I think you are ignoring me, because as I have already explained you only have 4 generic user binary controls, and that's not enough for full directional movement for 3 other players.

That'd be easily accomplished by plugging in a couple of USB gamepads and using Joy-To-Key

I'm not ignoring you

[GooberMan]

So here's something else to ignore then.

Unless someone has better kart physics than mine any time soon (unlikely considering the number of attempts made over the years to do such a thing), they're always going to read the bound player inputs.

Splitscreen is just plain unnecessary as I see it. Doom made its name as a networked multiplayer game, so multiplayer focus should be exactly on that.

EDIT:

The only point this is not the case is at the top of a slope, which has the typical "you are on a higher ledge already" problem. I don't want to even try and change that behaviour, as it could very easily get a player or some other mobj stuck in the ledge.

Yeah, I certainly wouldn't want it to be a default option. Just something we could turn on/off with a DECORATE setting in the player class.

The alternative is that I experiment with a zero-radius player in DECORATE and handle collisions some other way - which I was kinda thinking of doing anyway. I don't believe you can dynamically alter a thing's radius though? I'd want support for enter/exit cars in that respect, cache the original radius like I cache values at the moment then set it to zero on enter; and reset it to the cached value on exit.

[The Zombie Killer]

I never said it was necessary, I just felt like fooling around with CamTextures
I agree when you say that networked multiplayer should be the focus

[GooberMan]

Just something we could turn on/off with a DECORATE setting in the player class.

I've thought about it a bit more, and the only sensible solution I can come up with is to not treat slope collisions as a zero-radius thing (if that's what is already happening).

(EDIT: The idea being that it should smoothly transition in to the next sector if it's colliding with its entire radius instead of a single point and taking the highest height value it can. It's a more expensive collision operation, but it's the "correct" solution. END EDIT)

And still have it hidden behind a decorate setting. Radically altering the behaviour like that will be problematic for existing mods.

[edward850]

Yeah, I certainly wouldn't want it to be a default option. Just something we could turn on/off with a DECORATE setting in the player class.

I wouldn't want to even make it an option. The problem is it's not instantly obvious that the sector you're on slopes to the "higher ledge", especially with a larger radius, and this leaves the issue with suddenly falling into a ledge just because a slope happened to be there, or even phasing into one. The only way I see it could be handled is some checks with actor step heights, but that'll be too hit-or-miss to be reliable.

It's a very confusing problem, to be sure. Maybe someone with a different approach can figure it out. This is about the second time I have ever looked at the slope code, so I doubt I can work miracles with it overnight.

The alternative is that I experiment with a zero-radius player in DECORATE and handle collisions some other way - which I was kinda thinking of doing anyway. I don't believe you can dynamically alter a thing's radius though?

I don't think you can, no.

Alright, attaching the latest version of my kart script. Still has the attempted velocity extraction in there, I'll have to remove that. The use key lets you enter and exit the car.

Hmm, this is interesting. Something about the third person camera in this seems to making the turning of remote players hyper sensitive. At first I thought it was just prediction being off but seeing as both players are subject to it (in fact, the arbitrator is usually more subject to it), something else must acting up.

There's the usual problems as well like the car lagging behind the player's movement and all that nonsense (which I plan to resolve with predictive scripts), although I can't do anything about that until I figure out why turning touches the light fantastic.

[GooberMan]

Maybe someone with a different approach can figure it out. This is about the second time I have ever looked at the slope code, so I doubt I can work miracles with it overnight.

At it's core, from a 3D math perspective, the problem is that you want to find the collision point of the player on every floor plane you're overlapping. This would be achieved by projecting an axis-aligned bounding box from the thing's Z position plus its step height, down to the thing's Z position. The Z position would be determined in the same way - as a zero-radius object. The nearest point to the box that you collide with would be considered the correct Z height.

The overlapping sector list would already cover that - the code's already determined you can step up/down/whatever to it. All that is required is a more rigorous test to determine what the correct collision point is. Instead of treating slopes in a special manner, each floor/ceiling the player overlaps will be converted to a plane (which, yeah, means most of them will be pointing in one direction, but slopes will just be handled naturally).

The end result is that the object will always appear be hovering on slopes, but the stepping code will be sidestepped for something that will achieve the same result in all circumstances bar slopes.

[edward850]

The overlapping sector list would already cover that - the code's already determined you can step up/down/whatever to it. All that is required is a more rigorous test to determine what the correct collision point is. Instead of treating slopes in a special manner, each floor/ceiling the player overlaps will be converted to a plane (which, yeah, means most of them will be pointing in one direction, but slopes will just be handled naturally).

You had me lost with the 3D projection, but then this part gave me an idea: If an actor already has a sector list, why can't I just make it "drill down" until it finds a slope, and then test if it's still at a possible step height range for it? Slopes already block an actor from moving up if an actors radius is too big for the next step, so in theory it wont even become a compatibility issue. That's a theory, anyway. But I might be able to pull it off.

[GooberMan]

Well, you've got the right idea by drilling down. But instead of casting a line you're casting a box.

But yeah, it definitely requires some knowledge of collision mathematics to get it working right with minimal effort.

[Jeimuzu73]

EDIT: And I hope the intention is to just base the karts off ordinary Doom sprites. Because I *really* wouldn't be happy with ponies in the mod.
What? They don't need to be in everything.

I think you know who's gonna put ponies into their mod...

[TehRealSalt]

I feel like it's obligatory to mention this: https://www.youtube.com/watch?v=j_zSNSvktZ4

[SuperSomariDX]

I feel like it's obligatory to mention this: https://www.youtube.com/watch?v=j_zSNSvktZ4

Yes, I know of it, but it was all coded under lua, and it's running under Doom Legacy's engine. I'm not exactly too sure how it could help us.

[GooberMan]

Basically not at all.

[Captain J]

would be lovely if someone shows some cases about unknown or dusted kart racing that covered in zdoom-coded chocolate syrup. but i can't think any of them, though.

[TehRealSalt]

Yes, I know of it, but it was all coded under lua, and it's running under Doom Legacy's engine. I'm not exactly too sure how it could help us.

It's not actually Lua, it's C as it uses it's own exe, and even though it was written for a Legacy-based, it's Doom nonetheless. It might have applications to ZDoom.

I just wanted to mention it on the off-chance that it had some value to this project. I'm still probably wrong, though.