douga's Application

[Crispy]

The "change management process" is pretty informal. First you start a thread asking "hey, what do you guys think of this cool feature" and wait for a while to see if anyone hates it. Then you decide whether or not to go ahead based on the responses. Ideally everyone is kept happy (perhaps after some arguing to thrash out details and potential changes). If not, you'll know about it.

[douga]

The "change management process" is pretty informal. First you start a thread asking "hey, what do you guys think of this cool feature" and wait for a while to see if anyone hates it. Then you decide whether or not to go ahead based on the responses. Ideally everyone is kept happy (perhaps after some arguing to thrash out details and potential changes). If not, you'll know about it.

 

 

That sounds fair enough to me. So does that mean that all changes are made by first asking everyone about the impact or can some one just make changes to the code regardless?

 

Also, I've noticed tags like lead programmer, etc, does this indicate that you guys have a structured team with responsibility assignments etc, or its more of a informal thing?

 

This is all non technical stuff, but I figured if if i was going to ever become a team member, I want to know what the best way to integrate, how you guys do things and what the NONOs and good practice, your expectations of me, what your guys looking for in a programmer/team member, etc.

[Ishtvan]

That sounds fair enough to me. So does that mean that all changes are made by first asking everyone about the impact or can some one just make changes to the code regardless?

I'd say it depends on the situation. If it's a change relating to a task you've already claimed (like jumping), go ahead and do it. There's a chance that many will not like the change and complain during playtesting, which means rewriting what you've done. So you can sometimes save time by floating the idea. But if it's very abstract or complicated to explain, it's probably better to just do it and let people try it out.

 

If it's a minor change to other code that you're absolutely sure will fix a bug, go ahead and do it. If it's a major change to someone else's code or if it's a complex system where you're not exactly sure that your change will fix a bug without introducing other bugs, it's probably better to ask around first.

 

Bottom line, we can always revert changes with SVN (our source versioning system) if need be. So I would never let discussion hold you up from doing actual work. It can just save you some time rewriting stuff to talk over designs if it's going to take a long time to code.

 

Also, I've noticed tags like lead programmer, etc, does this indicate that you guys have a structured team with responsibility assignments etc, or its more of a informal thing?

The titles are informal. Although greebo has probably done the majority of the work.

 

We do try to structure individual task assignments to avoid conflicting work on the same thing at the same time (using the forum and bugtracker), but we don't really have overall assignments like "so and so will only work on player movement."

[Crispy]

we don't really have overall assignments like "so and so will only work on player movement."

Right. Because that would be boring. It pays to keep things interesting since nobody's actually getting paid for this...

 

Some people naturally become de-facto resident experts on certain areas of the code simply because they've worked more on those bits than other people, but that doesn't result in them being pigeon-holed at all. Also, t.b.h. greebo is probably an expert on most of the code base by now, just because he's worked so hard on so much of it!

[Springheel]

Also, I've noticed tags like lead programmer, etc, does this indicate that you guys have a structured team with responsibility assignments etc, or its more of a informal thing?

 

The division leads have the responsibility of keeping their division (more or less) organized; keeping track of what tasks need to be done and who is working on what. If there is some kind of deadlock in agreeing on a feature, the leads would also make the final decision. But no one is locked into working only on models, or only on code. In fact, all of us that have been here for years tend to work on half a dozen things at the same time.

[SneaksieDave]

I will chime in with another voice of the obvious, that any type of involuntary movement that takes away control is extremely annoying, ranging from some games' "slippery" feeling, up to that annoying inertial slip in Thief (evidenced in the video). The opposite can also be true, as in Unreal's "sticky", and "jerky" feeling. Requiring a running start or a runway landing would be a bad thing.

[Ishtvan]

Requiring a running start or a runway landing would be a bad thing.

A running start should come naturally from physics. If you're moving forward already and kick up off the ground, you'll keep moving forward, too.

[SneaksieDave]

What I mean specifically is if we were to prevent the player from forward jumping from a standing position, it would be bad.

[douga]

What I mean specifically is if we were to prevent the player from forward jumping from a standing position, it would be bad.

 

 

I've been playing with some movement parameters and it seems to be working good, I'll try making a small video to show the results, if I can get it working

 

I have to rememeber to do my uni assignments too lol

[douga]

Here is the video of the current progress.

 

http://www.mediafire.com/?tlomnglywnd

 

Not sure if I am on the right track but here is what I did:

 

1. Created new CVars for controlling jumping: pm_airaccelerate, pm_runJumpSpeed, pm_walkJumpSpeed, pm_minVelJump

 

2. Made changes to Physics_Player.cpp, method idPhysics_Player::CheckJump() lines so that the jump speed is adjusted based on current speed (walking/running)

 

Here is the code:

 

/*
=============
idPhysics_Player::CheckJump
=============
*/
bool idPhysics_Player::CheckJump( void ) {
idVec3 addVelocity;

if ( command.upmove < 10 ) {
	// not holding jump
	return false;
}

// must wait for jump to be released
if ( current.movementFlags & PMF_JUMP_HELD ) {
	return false;
}

// don't jump if we can't stand up
if ( current.movementFlags & PMF_DUCKED ) {
	return false;
}

groundPlane = false;		// jumping away
walking = false;
current.movementFlags |= PMF_JUMP_HELD | PMF_JUMPED;

/** If we have any forward velocity and its greateer than
	than a cap value then use our new jumpvelocity CVar 
 *   
 */

// are we walking?
if ( current.velocity.Length() >= pm_minVelocityJump.GetFloat() 
	&& current.velocity.Length() >= pm_walkspeed.GetFloat() && 
	current.velocity.Length() < pm_runspeed.GetFloat()) 
{
	addVelocity = pm_walkJumpVelocity.GetFloat() * maxJumpHeight * -gravityVector;

	gameLocal.Printf(" current.velocity.Length() %f ", current.velocity.Length());
	gameLocal.Printf(" pm_walkJumpVelocity %f ", pm_walkJumpVelocity.GetFloat());
	gameLocal.Printf(" pm_minVelocityJump %f ", pm_minVelocityJump.GetFloat());
}

// running ?
else if ( current.velocity.Length() >= pm_minVelocityJump.GetFloat()  
	&& current.velocity.Length() >= pm_runspeed.GetFloat())
{
	addVelocity = pm_runJumpVelocity.GetFloat() * maxJumpHeight * -gravityVector;

	gameLocal.Printf(" current.velocity.Length() %f ", current.velocity.Length());
	gameLocal.Printf(" pm_runJumpVelocity %f ", pm_runJumpVelocity.GetFloat());
	gameLocal.Printf(" pm_minVelocityJump %f ", pm_minVelocityJump.GetFloat());
}
// stationary
else
{
	addVelocity = 2.0f * maxJumpHeight * -gravityVector;
}
addVelocity *= idMath::Sqrt( addVelocity.Normalize() );
current.velocity += addVelocity;

return true;
}

[greebo]

Sounds cool. I'll have to check that out. Won't have time for this until the afternoon, though.

[greebo]

Just been watching the video - sounds like there are some variables to tweak now.

 

Two things I noticed, which I have questions about:

 

- The player seems to be able to accelerate in mid-air (like Unreal allows you to do). I don't think that's realistic - is this what pm_airAccelerate does?

- When increasing the cvar values, it seems the player can jump awfully high. Can this be restricted to be more of a "forward" jump? Such that the jump height stays the same, but the player can jump over larger gaps. The height is crucial, because otherwise players can reach supernaturally places just by mantling.

[douga]

Just been watching the video - sounds like there are some variables to tweak now.

 

Two things I noticed, which I have questions about:

 

- The player seems to be able to accelerate in mid-air (like Unreal allows you to do). I don't think that's realistic - is this what pm_airAccelerate does?

- When increasing the cvar values, it seems the player can jump awfully high. Can this be restricted to be more of a "forward" jump? Such that the jump height stays the same, but the player can jump over larger gaps. The height is crucial, because otherwise players can reach supernaturally places just by mantling.

 

 

Yes, I've made const float PM_AIRACCELERATE = 1.0f; a CVar and replaced all instances of where it is used with new pm_accelerate so I could tweak it. It does allow jumping and then move in the air a bit.

 

Hmm, not sure about the second one, I think I should be able to tweak the vector of jumping forward a little. Have to check that out.

[douga]

Hi guys,

 

I am not sure how to proceed with this. Been looking at the code for three days and still no got no idea how to change the jumping distance while keeping the height the same.

 

I thought I could maybe change the direction of the jump, since stationary jump direction is always up, (assuming moving jump direction is up) by "leaning" the jump vector in the direction of moving by some value will make the distance longer while not increasing the actual jump height.

 

help lol

[greebo]

Hm. The code in idPhysics_Player::CheckJump() has a local variable addVelocity, which finally gets added to the player's current velocity. Have you tried adding an arbitrary vector to this addVelocity? Does it work if you add a certain multiple of the forward direction to this value?

[douga]

Hm. The code in idPhysics_Player::CheckJump() has a local variable addVelocity, which finally gets added to the player's current velocity. Have you tried adding an arbitrary vector to this addVelocity? Does it work if you add a certain multiple of the forward direction to this value?

 

 

Thanks, that did the trick. Added another CVar for controlling that forward vector multiple.

 

So now its a just a matter of playing with CVars until desired speed/distance is achieved.

 

I think the warmup task is done

[Ishtvan]

Cool, sounds good. Since it's a multiple, there should be no forward motion if the player jumps straight up, right?

 

Also, this is kind of a bizzare case, but what if the player is in a moving reference frame (like standing on a crate floating down a river) and jumps straight up. Will they come back down in the same place on the crate, or would the reference frame velocity get the multiplier applied to it such that the player overshoots the crate when they come back down? In other words, we should probably subtract the reference frame velocity before applying the multiplier, if that's not happening already.

[douga]

Cool, sounds good. Since it's a multiple, there should be no forward motion if the player jumps straight up, right?

 

Also, this is kind of a bizzare case, but what if the player is in a moving reference frame (like standing on a crate floating down a river) and jumps straight up. Will they come back down in the same place on the crate, or would the reference frame velocity get the multiplier applied to it such that the player overshoots the crate when they come back down? In other words, we should probably subtract the reference frame velocity before applying the multiplier, if that's not happening already.

 

 

Thanks for the feedback.

 

There is no forward motion if the player is stationary and jumps straight up because I check for player current speed and it needs to be that of walking or running.

 

I haven't thought about the moving reference case, will have to check that.

[Ishtvan]

I haven't thought about the moving reference case, will have to check that.

I think usually that's already subtracted from the velocity when calculating "desired velocity" in player_physics, so it might already be okay. It could probably stand some testing though.

[douga]

I think usually that's already subtracted from the velocity when calculating "desired velocity" in player_physics, so it might already be okay. It could probably stand some testing though.

 

 

I've added this section of code to try and allow for that but not sure if I am on a right track

 

objectBelow = this->GetGroundEntity();
if ( objectBelow && objectBelow->IsType(idMover::Type) )
{
	objSpeed = objectBelow->GetPhysics()->GetLinearVelocity();
	if (objSpeed.Length() > 1.0 && objSpeed.Length() > current.velocity.Length() )
	{
		current.velocity -= objSpeed;
	}
}

[douga]

I've tested this on monorail map and when inside a moving entity such as idMover type, it reports 0 speed relative to the player, while moving.

[Ishtvan]

I think it's the right idea, but I believe it's already tracked with GetPushedLinearVelocity, so you might not have to check the entity and get it from it again. I would try that first and not worry too much about it for now.

 

EDIT: Also, I'm not sure you need those checks for only subtracting when the velocity is over 1 and only when greater than the current velocity. It should always be correct to say:

actual velocity = current velocity - reference frame velocity

right?

[greebo]

Ok, douga, seems like you're on the right track overall. For finishing up this task, I'd suggest we set you up with the darkmod_src repository, so that you can check in these changes to our actual mod code.

 

As a next step, I'd say you send a PM to sparhawk telling him your username, a desired password and your E-Mail address (for SVN commit notifications). As soon as you have heard back from him, please post here and we can take you further.

 

In the meanwhile, maybe review the code changes you did and clean them up if appropriate (make CVAR out of hardcoded values). Btw, our CVARs look something like this:

 

idCVar cv_tdm_push_velocity_min("tdm_push_velocity_min", ....);

 

All our CVARs start with tdm_ as prefix, and the actual cvar objects in the code are starting with "cv_tdm". Provide a short description and a reasonable default value.

[douga]

Ok, douga, seems like you're on the right track overall. For finishing up this task, I'd suggest we set you up with the darkmod_src repository, so that you can check in these changes to our actual mod code.

 

As a next step, I'd say you send a PM to sparhawk telling him your username, a desired password and your E-Mail address (for SVN commit notifications). As soon as you have heard back from him, please post here and we can take you further.

 

In the meanwhile, maybe review the code changes you did and clean them up if appropriate (make CVAR out of hardcoded values). Btw, our CVARs look something like this:

 

idCVar cv_tdm_push_velocity_min("tdm_push_velocity_min", ....);

 

All our CVARs start with tdm_ as prefix, and the actual cvar objects in the code are starting with "cv_tdm". Provide a short description and a reasonable default value.

 

 

Thanks greebo, I'll get that done.

[douga]

ok, I am all good to go with svn access.