Thelvyn's Thread

[New Horizon]

I spoke with thelvyn a few weeks ago in regards to helping out with some Dark Mod or Dark Radiant coding. So, lets have our coders step in and see where thelvyn might best be able to contribute.

[thelvyn]

Hello!

Perhaps you need some more information before deciding what you wish to task me with I figure.

I am a self taught C/C++(Prefer C++ though definately) programmer.

I have been programming utilitys and such since Dos 4. I do Windows console/gui programming but im lazy and use mfc for gui normally.(Honestly sometimes its more work making mfc do what you want!)

 

Unfortunately I have no 3d/game programming experience but I have worked coding on two different muds and written some shareware/freeware(None of which I currently have up however) and other stuff I cant talk about really(Confidentiality).

 

 

First I guess I can start with some old code, hasnt been touched since I was using borland C++ 4.5 so not sure if it will even compile anymore.

 

It was a utility I wrote for the game Daggerfall back in 1995.

If you run it wont do much unless you actually have daggerfall installed of course other then search and not find it but I am including the source code of course.

I am also including something I was still working on but its workable as is(Not very polished im afraid), have not had time to finish it sadly.

It is a low level keyboard interception program to disable certain key combos as you choose.

Like Alt-Tab or the Windows key. Hate hitting them by accident in a full screen game to go back to windows, not to mention most multi-player games disconnect you if you do that...

Im not sure if it compiles/runs in its current state(I was changing some stuff around)

I am including a release build that works however.

 

I can give other examples if required.

 

Cant seem to attach the zip. Takes long time but no attachments visible ?

Edited January 1, 2007 by thelvyn

[thelvyn]

trying to post zip again hope it works this time.

[Crispy]

Doesn't look like it. Try posting it on a separate website, I don't think this forum likes zip files.

 

Glad to see another programmer around! I'm looking forward to seeing what you can do.

[thelvyn]

It appears to accept them but no joy.

You should be able to get it here shortly it is uploading to server now Jan 1 12:30pm EST

LINK removed.

[Ishtvan]

If you want to get started on looking at some stuff, you can download the latest version of the Doom3 SDK. We should probably think of some fairly self-contained, smaller tasks that could be done as a good introduction (although it's hard to tell what will be self-contained before starting it).

 

I'm trying to think of some tasks like that, and these are what's come to mind so far. Other programmers have been more active lately, so they may have some additional ideas. Let us know if anything sounds interesting, or if you have other ideas:

 

Ideas for Tasks:

- Scripting of various inventory items (health potion and food add to health when used, etc)

 

- Make AI take damage from falling or otherwise slamming into things, based on their velocity (probably velocity squared dependence for kinetic energy) ("Hint": Maybe a good place for this would be in idAI::Collide?) There should also be a threshold velocity below which they don't take damage.

 

- Mod D3's AI Area Awareness System (AAS) to prevent AI from walking down a slope into water over their head and drowning. We've decided we don't want them to swim, for now. This one is a little more involved, but SophisticatedZombie, one of our team members, has figured out how to alter the AI pathfinding system. The AAS generates a grid of points to help the AI navigate from place to place, and for AI that can drown (i.e., not undead), we basically need to go thru that grid and invalidate points that have water above head-level (there's a function that returns whether a point in space is underwater). As-is, they don't know they're not supposed to walk there, so they'll walk down an incline into water, walk along the bottom, and drown.

 

- Look into handling player profiles for stuff like saving misson stats and overall stats for missions played by a particular profile. I think some very preliminary work was done on this by Sparhawk.

 

One of the remaining major tasks is melee combat, but I think it might be best to work on something smaller to get an introduction to the SDK, first.

[thelvyn]

If you want to get started on looking at some stuff, you can download the latest version of the Doom3 SDK. We should probably think of some fairly self-contained, smaller tasks that could be done as a good introduction (although it's hard to tell what will be self-contained before starting it).

 

I'm trying to think of some tasks like that, and these are what's come to mind so far. Other programmers have been more active lately, so they may have some additional ideas. Let us know if anything sounds interesting, or if you have other ideas:

 

Ideas for Tasks:

- Scripting of various inventory items (health potion and food add to health when used, etc)

 

- Make AI take damage from falling or otherwise slamming into things, based on their velocity (probably velocity squared dependence for kinetic energy) ("Hint": Maybe a good place for this would be in idAI::Collide?) There should also be a threshold velocity below which they don't take damage.

 

- Mod D3's AI Area Awareness System (AAS) to prevent AI from walking down a slope into water over their head and drowning. We've decided we don't want them to swim, for now. This one is a little more involved, but SophisticatedZombie, one of our team members, has figured out how to alter the AI pathfinding system. The AAS generates a grid of points to help the AI navigate from place to place, and for AI that can drown (i.e., not undead), we basically need to go thru that grid and invalidate points that have water above head-level (there's a function that returns whether a point in space is underwater). As-is, they don't know they're not supposed to walk there, so they'll walk down an incline into water, walk along the bottom, and drown.

 

- Look into handling player profiles for stuff like saving misson stats and overall stats for missions played by a particular profile. I think some very preliminary work was done on this by Sparhawk.

 

One of the remaining major tasks is melee combat, but I think it might be best to work on something smaller to get an introduction to the SDK, first.

 

Ok 1.3 I take it is the version you are working with right ? I downloaded and installed it. However shouldnt I be looking at what you have already done first so I dont do double work ? I will start familiarizing myself with the sdk in the meantime.

[thelvyn]

Well I met my first hurdle and not sure what to do from here...

Tried to compile with Visual Studio 2005 Professional, Doom3 sdk 1.3

 

------ Rebuild All started: Project: Game-d3xp, Configuration: Debug with inlines and memory log Win32 ------

Deleting intermediate and output files for project 'Game-d3xp', configuration 'Debug with inlines and memory log|Win32'

Performing Pre-Build Event...

The system cannot find the path specified.

Project : error PRJ0019: A tool returned an error code from "Performing Pre-Build Event..."

 

------ Rebuild All started: Project: Game, Configuration: Debug with inlines and memory log Win32 ------

Deleting intermediate and output files for project 'Game', configuration 'Debug with inlines and memory log|Win32'

Performing Pre-Build Event...

The system cannot find the path specified.

Project : error PRJ0019: A tool returned an error code from "Performing Pre-Build Event..."

 

The only pre-build step is this ".\TypeInfo\typeinfo.exe" (Both projects are the same)

I do not have this file anywhere on my system.

Well its late im off to bed hopefully I can at least compile it tommorow night.

[Crispy]

I think I just deleted that pre-build step. It seems to work anyway.

 

I can't think of anything else. We should really have a programming to-do list which is more comphrensive than our current one (which only lists big systems like inventory/soundprop/etc.).

[thelvyn]

Couldnt sleep so came back. I deleted those pre-build steps and now I am failing again on these errors(Seems to definately be related)

 

Compiling...

TypeInfo.cpp

.\game\gamesys\TypeInfo.cpp(14) : fatal error C1083: Cannot open include file: 'GameTypeInfo.h': No such file or directory

Creating browse information file...

Microsoft Browse Information Maintenance Utility Version 8.00.50727

Copyright © Microsoft Corporation. All rights reserved.

BSCMAKE: error BK1506 : cannot open file '.\game\InlineDebugMemoryDLL\TypeInfo.sbr': No such file or directory

 

 

Edit: Found this in NoGameTypeInfo.h

 

/*

========================================

========================================

=

==

 

This file has been generated with the Type Info Generator v1.0 © 2004 id Software

 

========================================

========================================

=

==

*/

 

So off I go to search for this tool. You would think it would be included in the sdk...

[thelvyn]

Here is the problem area in TypeInfo.cpp

#ifdef ID_DEBUG_MEMORY

#include "GameTypeInfo.h" // Make sure this is up to date!

#else

#include "NoGameTypeInfo.h"

#endif

 

First I removed the ID_DEBUG_MEMORY from the builds but that made even more errors.

So I changed it

 

#ifdef ID_DEBUG_MEMORY

#include "NoGameTypeInfo.h" // Make sure this is up to date!

#else

#include "NoGameTypeInfo.h"

#endif

 

And it compiles fine now. Is there any need for this because I have been unable to find that exe file anywhere.

I wonder why no one else has had this problem however.

[Crispy]

Oh, yeah, I remember that now. I don't have ID_DEBUG_MEMORY defined. I don't think that removing it was a problem for me (possibly those errors were fixed in our copy of the SDK before I saw it); or if it was a problem, then I fixed them somehow. I don't remember if I did get any errors so I can't be any more helpful than that, I'm afraid!

 

Setting up the SDK is a pretty messy business, as you've discovered. Once it's set up it's fine though.

[thelvyn]

Oh, yeah, I remember that now. I don't have ID_DEBUG_MEMORY defined. I don't think that removing it was a problem for me (possibly those errors were fixed in our copy of the SDK before I saw it); or if it was a problem, then I fixed them somehow. I don't remember if I did get any errors so I can't be any more helpful than that, I'm afraid!

 

Setting up the SDK is a pretty messy business, as you've discovered. Once it's set up it's fine though.

 

Well then perhaps I should be using the same copy as you are to make this smoother.

I'm afraid I do not know where to get it at though or even if I am permitted to do so yet.

[Crispy]

Well, setting up the SDK is a bit of an adventure even if you do have the Dark Mod version already. They didn't make it very user-friendly in that regard.

 

You're currently set up as an applicant, which means you don't have permissions for much of anything yet. I'm not actually sure there's a lot of point in you messing around with the SDK without having our version.

 

I've been looking through the source code you posted (didn't get much of a chance earlier), and you seem to know what you're doing.

 

I move that we declare the application process concluded and give thelvyn a task to work on already. All in favour?

 

I'm thinking the health potion scripting might be a good one to start off with. It's not a C++ task (just Doom 3 scripting), but it could be done using just the beta mapper's alpha version, which means no messing around with CVS. Given the state of the CVS server at the moment, I reckon that's a good thing.

 

Making AI take damage is also a good one (and does involve C++), though it requires getting CVS set up.

 

thelvyn, do you have a copy of Doom 3? (Just the original, patched to version 1.3; we're not using the expansion pack.) You may need one.

[New Horizon]

I actually have Thelvyn setup as a contributor, just to speed things up a bit. Basically, a small task would for starters and then have a word with Sparhawk about getting access to our CVS repository so you can get the mod source code.

[thelvyn]

Yes I have doom3, I bought it when you guys started this mod actually Tried playing it but it sucks as a game. Great engine showoff though I suppose. Thats where they make their real money after all I would imagine at what $100k a shot?

 

I will re-install it and patch.

[Ishtvan]

Ok 1.3 I take it is the version you are working with right ? I downloaded and installed it. However shouldnt I be looking at what you have already done first so I dont do double work ? I will start familiarizing myself with the sdk in the meantime.

 

Yeah, 1.3 is the version we're using. Sure, you could look at what's been done already. Not sure if you have access to the "current build" section of the forum, but that, in addition to the milestone documents, should provide a pretty good idea of what's been done. I was just listing some tasks that I know for sure haven't been done, in case you were interested in any of those.

 

@Others: I think we decided that it makes the most sense to give programming contributors CVS access. They can't do too much without it, unless their task is so self-contained that it doesn't require anything in our existing code base. Otherwise, they need CVS access to both source and game modules. Some tasks though are pretty self contained, like having falling damage apply to AI could be done without our code base.

[thelvyn]

Yeah, 1.3 is the version we're using. Sure, you could look at what's been done already. Not sure if you have access to the "current build" section of the forum, but that, in addition to the milestone documents, should provide a pretty good idea of what's been done. I was just listing some tasks that I know for sure haven't been done, in case you were interested in any of those.

 

@Others: I think we decided that it makes the most sense to give programming contributors CVS access. They can't do too much without it, unless their task is so self-contained that it doesn't require anything in our existing code base. Otherwise, they need CVS access to both source and game modules. Some tasks though are pretty self contained, like having falling damage apply to AI could be done without our code base.

 

Ok so far so good, I have found(I think ) where it needs to be changed at

HERE

bool idEntity::Collide( const trace_t &collision, const idVec3 &velocity ) {
// this entity collides with collision.c.entityNum
return false;
}

 

I would actually overide it somewhere if at all possible, should be np. virtual function be ok ? We dont have to maintain binary portability or anything ( as far as I know ) so I suspect its ok but asking to be sure.

 

This is the code from player, im not sure I understand this properly. I have been digging through the code but some stuff still doesnt make sense to me yet

 

bool idPlayer::Collide( const trace_t &collision, const idVec3 &velocity ) {
idEntity *other;

if ( gameLocal.isClient ) {
	return false;
}

other = gameLocal.entities[ collision.c.entityNum ];
if ( other ) {
	other->Signal( SIG_TOUCH );
	if ( !spectating ) {
		if ( other->RespondsTo( EV_Touch ) ) {
			other->ProcessEvent( &EV_Touch, this, &collision );
		}
	} else {
		if ( other->RespondsTo( EV_SpectatorTouch ) ) {
			other->ProcessEvent( &EV_SpectatorTouch, this, &collision );
		}
	}
}
return false;
}

 

It couldnt possibly as easy as copying it over. I dont even see where player takes damage unless its in the other->ProcessEvent( &EV_Touch, this, &collision ); call.

 

Btw how should I interpret the velocity ? I dont have a frame of reference for what velocity equals or the damage that should be inflicted as a result.

 

Well still investigating.

[Crispy]

You don't need to worry about keeping the binary interface the same, unless you suspect that the function is directly called from the engine code (which is hardly ever the case, and I think all the physics stuff is in the SDK somewhere so you should be okay with Collide).

 

Btw how should I interpret the velocity ? I dont have a frame of reference for what velocity equals or the damage that should be inflicted as a result.

Well, I guess making it similar to the damage inflicted on the player would be logical, if you can find where that happens. I'd suggest going along with Ishtvan's proposal velocity-squared dependence, with whatever constant factor seems about right. I realise you can't test it out yet, but constant factors are easily tweaked later.

[thelvyn]

You don't need to worry about keeping the binary interface the same, unless you suspect that the function is directly called from the engine code (which is hardly ever the case, and I think all the physics stuff is in the SDK somewhere so you should be okay with Collide).

Well, I guess making it similar to the damage inflicted on the player would be logical, if you can find where that happens. I'd suggest going along with Ishtvan's proposal velocity-squared dependence, with whatever constant factor seems about right. I realise you can't test it out yet, but constant factors are easily tweaked later.

 

He suggested that this is where it happens although I dont see it, I will keep digging.

 

Btw where is the function that returns if a point in space is underwater ? Ishtvan said there was one but im not sure where to begin looking.

[Ishtvan]

Personally, I would change ::collide on the derived classes rather than idEntity, like idAI, and idMoveable (and idMoveableItem) if you want moveable objects to break. It might be slightly less elegant to put the same code on both idMoveable and idPlayer, but you don't have to worry about extra work being done from ::collide being evaluated on things it doesn't have to evaluate on.

 

Then again, maybe you could put in if(health > 0) in your damage-causing mod in idEntity::Collide, so that entities without health wouldn't do anything, it's up to you.

 

I think Collide is called within the SDK, it's called by CollisionImpulse on the physics objects. (FYI, the physics objects are separate objects contained within entities to store their physics info. So to get the velocity, you would call Ent->GetPhysics()->GetLinearVelocity() , the GetPhysics part returning a pointer to idPhysics * object, although usually it's a derived type like idPhysics_RigidBody).

[Ishtvan]

Btw, are you saying you'd have to change the arguments of ::Collide? I'm not sure why you'd have to for this application?

[thelvyn]

I would actually overide it somewhere if at all possible, should be np. virtual function be ok ? We dont have to maintain binary portability or anything ( as far as I know ) so I suspect its ok but asking to be sure.

Crispy said that was fine that I did not need to worry about binary compatibility.

So it would go in idAI and the base class would just have it changed to virtual.

Only problem with that is I would have to change it in any other derived classes to virtual as well.

 

The other option being to just hide the base class implementation and NOT make it virtual.

Virtual adds a small overhead to each call.

The base class function would still be accessible either way using a scope declaration of course.

 

There is a problem with this approach though, if its not virtual then the only time it would be called is if the pointer was actually to the correct class which it most likely will not be.

So I believe virtual is the way to go if you dont want it in the base class it will just be trouble otherwise.

 

No not the arguments.

[Ishtvan]

Oh, yeah, that makes sense.

 

Wait a minute though, in my verison, Collide is already declared as virtual:

in idEntity.h

							// called from the physics object when colliding, should return true if the physics simulation should stop
virtual bool			Collide( const trace_t &collision, const idVec3 &velocity );

[Ishtvan]

The damage done to the player on falling is actually a little more complicated than I thought. It's not done in idPlayer::Collide, it's actually done in idPlayer::Move, at the end it calls:

 

CrashLand( oldOrigin, oldVelocity );

 

idPlayer::CrashLand is a bit complicated because they chose to do discrete levels of falling damage: fatal fall, soft fall and hard fall. IMO this is not so good, damage should be continuously varying with velocity, with a cutoff velocity below which it does no damage.

 

Other parts of idPlayer::Crashland are also not good. It intentionally breaks out if the player is not hitting the ground specifically, but we would like it to do damage upon hitting things like walls, too.

 

If you want, you can look into making these changes to idPlayer::Crashland. You'll have to look at ::Damage to see how to do variable damage, but it is possible to scale the damage by passing in an argument.

 

Getting back to falling damage for AI and breakable objects: I don't think they really need anything this complicated. For them, I still think putting something in ::Collide is easiest, and it would just look at their velocity normal to the direction of collision, see if it's above some threshold, and if so, do damage proportional to the velocity squared. You might as well make it general for both idAI and breakable objects, which would be idMoveable and idMoveableItem.

 

You can get the current velocity with GetPhysics()->GetLinearVelocity() , and you can get it normal to the collision direction by accessing the trace struct that's passed into ::Collide. It's something like trace.c.normal is the normal vector, then you just dot that (the * operator for vectors) with the velocity vector to get velocity normal to the surface that was struck.