Thelvyn's Thread

[sparhawk]

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 ------

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

 

This is the problem. There are several configuration which doesn't seem to work. I suppose they used some special tools for these. Just compile plain "Release" or "Debug" and remove the other ones. These ones should work fine. All the "release/debug with ..." don't work.

[thelvyn]

I did not think the damage was done in collide.

As for it being virtual I never looked at the header, but it makes sense. I should have known though.

I will explore this in detail as soon as I have time. Installing a new hdd today (Soon as it arrives waiting for ups) and wont have time today I expect. Changing my motherboard also while im at it.

[Ishtvan]

We may want to rewrite it though so that all the damage is done in collide. idPlayer::CrashLand thing is not exactly what we want, even for the player. It checks for ground contact each frame and tracks the velocity change since last frame. We also want to register collisions with walls, for example if the player gets thrown against a wall by something, but we can't do that with ::CrashLand, but could do it with ::Collide, since we know that's getting called for all collisions. The only useful thing CrashLand does is play the right animations/sounds when the player lands on the ground after jumps/falls, but for damage, I think we could do away with the damage-dealing in idPlayer::Crashland, and do it all in the ::Collide method.

 

I'd say maybe work on doing the damage in the ::Collide method on AI, simply based on velocity normal to collision surface at the time of collision. When that's done, we can see about applying that to the player as well, instead of the vanilla D3 CrashLand damage.

[thelvyn]

As soon as I get my main system back up I will get started on that. Tomorrow night I should be able to work on it. I had to make a sp2 install CD(Slipstream it and make a new cd) as pre-sp1 would not recognize my drive. Too big Anyway its installing now.

 

You only want me to do it for AI for now correct ? You had mentioned for items as well before is why I am asking.

[Ishtvan]

Yeah, I think it might be easiest to just work on AI and items for now. We can worry about fixing it on the player after that's done.

 

I think the code for AI and items will be the same, because both should respond transparently to Damage(). Also, both will have health > 0 if they can be damaged and they're not already dead. You might not have to check health > 0 though, that may be already checked for you in Damage(). Again, the object classes that could conceivably be damaged would be idMoveable and idMoveableItem.

[thelvyn]

Unfortunately I do not see how I can even test anything I am doing without having cvs access.

 

How am I to determine if what I am doing works with just regular doom3 ?

 

By the way I am curious did anyone even look at my source code, I ask because no one made any comments good or bad about it. Since the win32 program uses a low level keyboard hook I thought it was relevant and figured someone would have said something about it but nothing...

 

Always nice to get feedback

 

The reason I chose those is to give you an idea of where my coding was 11 years ago and of course recently as well.

[sparhawk]

we don't give CVS access or the codebase to contributors right from the start. You have to implement your demo in vanilla D3 code and then we can merge it later.

[thelvyn]

Well I do not see how I can test it as it stands.

Where can I go in regular doom3 to make a ai fall and see if it gets hurt ?

Do you want me to post changes here so you can test them ?

Thats going to be extremely tedious if so.

[Crispy]

By the way I am curious did anyone even look at my source code, I ask because no one made any comments good or bad about it. Since the win32 program uses a low level keyboard hook I thought it was relevant and figured someone would have said something about it but nothing...

I can't speak for anyone else, but I did look at the win32 program, and commented to that effect. I didn't elaborate because there's not much to elaborate on. The code looks fine to me. (Didn't test it.)

 

I didn't look at the other one very much because I'm not familiar with the game or its plugin interface.

 

 

As for testing your changes... I understand it's difficult without CVS access. The problem is that the team has been burned before by a "contributor" joining up, gaining access to all of the resources, and then stealing copies, leaving without actually contributing anything, and posting the files on the internet. So now it's a matter of policy that contributors don't get full access until they've submitted something. Nothing personal.

 

This is why I suggested a scripting task to start off with, since you don't need CVS access for that - you can just use the beta mapper's alpha. Doing SDK work without CVS access is a bit of a pain.

 

The beta mapper's alpha is here if you're interested, though it won't help you with the SDK since it contains no code apart from scripts: http://forums.thedarkmod.com/index.php?act=a...p;f=31&id=7 (I think you should be able to access that forum?)

 

 

Still, you should be able to test this in vanilla D3. Make a simple room in the Doom 3 editor (there are a bunch of tutorials around on the internet - doom3world.org is a good place to start) with a really high roof. Start it up, press Ctrl-Alt-~ to display the console, type noclip, and toggle the console off again. Then fly up to the ceiling. Spawn a zombie (using the console, see http://au.gamespot.com/pc/action/doom3/hints.html for instructions) so that he falls down to the ground below. In vanilla D3, he will land there without taking damage. Your task is then to modify the SDK so that he dies if he falls from a great height.

 

BTW, as for using your compiling SDK: I find that the easiest way is to take your compiled gamex86.dll file (should be in the releasedll or debugdll folder) and copy it to the root D3 directory (where DOOM3.EXE is). That way it overrides the DLL for *all* mods you have installed, so be sure to delete it if you install a mod - the Dark Mod, or any other mod.

[thelvyn]

Sorry Crispy I forgot yes you did.

There was no plugin interface for The Elder Scrolls II Daggerfall (Maybe now you recognize it ? Might be too young. No offence )

They only gave you 5 save slots, they just dumped a myriad of files there as well.

My program took them and combined them into a container(Loosely based on the premise behind .wad files from doom1 etc).

I also did individual file compression(Individual so you could restore just 1 save game for example if desired without unpacking the whole container)

Thereby saving tons of disk space (Depended on your cluster size but a average space saving was 20 to 1 ) and well as increasing the number of save games you could have from 5 to 100(in shareware version, registered was unlimited except by disk space)

 

 

As far as AI goes the first instance of Collide is here

idEntity::Collide

This just returns false no processing at all.

Then there is

bool idAFEntity_Base::Collide( const trace_t &collision, const idVec3 &velocity ) {
float v, f;

if ( af.IsActive() ) {
	v = -( velocity * collision.c.normal );
	if ( v > BOUNCE_SOUND_MIN_VELOCITY && gameLocal.time > nextSoundTime ) {
		f = v > BOUNCE_SOUND_MAX_VELOCITY ? 1.0f : idMath::Sqrt( v - BOUNCE_SOUND_MIN_VELOCITY ) * ( 1.0f / idMath::Sqrt( BOUNCE_SOUND_MAX_VELOCITY - BOUNCE_SOUND_MIN_VELOCITY ) );
		if ( StartSound( "snd_bounce", SND_CHANNEL_ANY, 0, false, NULL ) ) {
			// don't set the volume unless there is a bounce sound as it overrides the entire channel
			// which causes footsteps on ai's to not honor their shader parms
			SetSoundVolume( f );
		}
		nextSoundTime = gameLocal.time + 500;
	}
}

return false;
}

 

We are in essence replacing this so unless someone can give me a reason not to I will be calling the base class function first before anything else like so

idAFEntity_Base::Collide( collision, velocity );

So now I have collide in idAI and I am working on determining what factors to use for the amount of damage to inflict based on velocity.

 

I already know WHAT they are impacting it is

collision.c.entityNum

You want them to take damage any way they are thrown or fall whether it be up down or sideways as long as the velocity is high enough correct ?

 

In class idAI

 

// physics

idPhysics_Monster physicsObj;

 

Now in class idPhysics_Monster their is a variable called noImpact which is false by default implying that AI do take damage. There are functions to enable or disable this as well.

 

/*
================
idPhysics_Monster::EnableImpact
================
*/
void idPhysics_Monster::EnableImpact( void ) {
noImpact = false;
}

/*
================
idPhysics_Monster::DisableImpact
================
*/
void idPhysics_Monster::DisableImpact( void ) {
noImpact = true;
}

 

So my question is this. Are you sure they do NOT take damage ? It seems like they should.

What I am saying is perhaps this is just a bug and there is no need to reinvent the wheel.

Well back to tracing things down.

[thelvyn]

Why don't we make a tool to simplify this ?

Automatically copy the dll into the pak file for us ?

Or is there already such a tool ?

[thelvyn]

There is no definition of waterlevel except for in Doom3_SDK\src\game\physics\Physics_Player.h

They use idPhysics_Monster for idAI and you cant simply switch them either.

I will have to recreate or move a nice chunk of idPhysics_Player possibly into idPhysics_Monster.

I am not sure how much yet.

 

This is also going to affect the path finding into water problem as well. I was looking into both and turns out they are related after all. Since there is not even a definition of water in idAI or idPhysics_Monster.

 

Well I don't think I can continue working on this with so many changes being necessary it will be tough to then move them into your code base so I will look into the script issue and stop working on this for now.

 

Changes to the following at the least. Adding new functions, making structs available to more then just player etc.

 

Doom3_SDK\src\game\Player.cpp

Doom3_SDK\src\game\ai\AI.h

Doom3_SDK\src\game\ai\AI.cpp

Doom3_SDK\src\game\physics\Physics_Monster.cpp

Doom3_SDK\src\game\physics\Physics_Monster.cpp

 

 

I hate doing scripts with a passion too. Give me C++ or give me death yea ok anyway big waste of time.

[thelvyn]

My solution to this would actually be slightly different.

Move the relevant code from idPhysics_Player into its base class idPhysics_Actor.

The only classes that derive from that are idPhysics_Player and idPhysics_Monster anyway.

That would solve that part of it at least. two variables and two functions for sure possibly more I haven't traced it all out. Lot to look at.

 

Also are AI going to be affected by water like players are ? Theres quite a bit of code for friction based on the water level. Reduces speed, makes jumping impossible if the water is deep enough(Slides instead) etc.

 

Well I am off of this anyway.

[Ishtvan]

I already know WHAT they are impacting it is

collision.c.entityNum

You want them to take damage any way they are thrown or fall whether it be up down or sideways as long as the velocity is high enough correct ?

Correct, but the velocity should be resolved into the direction normal to the collision. For example, if they just graze something on the way down, most of their velocity would not be parallel to the collision normal vector, so this would do less damage. If they splat directly against something (like falling vertically onto the ground, or being thrown horizontally against a wall), their velocity is mostly parallel to the collision normal, so it does a lot of damage.

 

I'd suggest doing this in the following way:

You can get the collision normal vector by

collision.c.normal (or something along those lines, it's in that struct)

Then just take the dot product with their velocity to get velocity resolved along the normal vector:

float CollisionVelocity = collision.c.normal * GetPhysics()->GetLinearVelocity();
// damage = function of CollisionVelocity^2

 

So my question is this. Are you sure they do NOT take damage ? It seems like they should.

What I am saying is perhaps this is just a bug and there is no need to reinvent the wheel.

Well back to tracing things down.

That could well be the case, and if it is, all the better, just fix that setting. I'm fairly positive that the AI do not currently take damage from falls.

 

The way I test it is, turn on g_dragentity 1 in the console. This lets you pick things up by clicking attack on them. turn on noclip. Grab an AI, drag it up in the air, and drop it a long distance. See if it takes damage (right now it doesn't).

[Ishtvan]

Also are AI going to be affected by water like players are ? Theres quite a bit of code for friction based on the water level. Reduces speed, makes jumping impossible if the water is deep enough(Slides instead) etc.

Don't worry about the water for now. There's actually a separate water physics mod by LLoyd that we incorporated into our codebase, so you can't do much without that. I think it's publicly available for download if you want to look, but again I wouldn't worry about it for now.

 

Well I am off of this anyway.

Were some of your posts moved from somewhere else by any chance? I can't quite follow the last few posts or understand why you don't want to do this part anymore.

 

It's fairly easy to test it using only the D3 SDK with the g_dragentity method. Just go to a map with a long drop or a high ceiling, make sure it does not have a brush that automatically kills anything at the bottom (some of the D3 maps have this to fake falling damage, but it's really just a kill-brush at the bottom). noclip and drag the AI up, drop it down, and see what happens.

[Crispy]

There was no plugin interface for The Elder Scrolls II Daggerfall (Maybe now you recognize it ? Might be too young. No offence )

None taken, but I did recognise the game as soon as you mentioned it (I've played Morrowind); I just don't know anything about its internal workings, so I figured looking at the code wouldn't tell me much.

 

Why don't we make a tool to simplify this ?

Automatically copy the dll into the pak file for us ?

Or is there already such a tool ?

You don't need to copy the DLL into the PK4 file to test it... just dump it in the Doom 3 directory and it'll override all other game DLLs.

 

If you do want to put it in the PK4 file, it's a simple matter of opening the PK4 in WinRAR (or whatever, pick your favourite .zip application - pk4s are just zip files) and drag the DLL into it. You only need to do this for distribution though.

[Ishtvan]

I think we should give thelvyn CVS access. His posts clearly indicate that he's working on stuff in good faith, and has the right ideas about what code to add. We've said in the past that it doesn't make much sense for a coding contributor to work without the codebase, and it would make more sense to do everything now, including the water calculations, rather than work inefficiently without the codebase.

[thelvyn]

Its come down to this. To do this is going to mean making changes to at least 5 different files, 7 for water(I believe from what I have found so far anyway).

 

If this was just one or even two files I would have no problem with moving the code over later to your version of the sdk. But 7 ? Even if its only 5 still I ask is it worth it to just have to move it all over afterwards.

 

What if you have changed any of the relevant code ? I do not like to do things twice. Rather do it right the first time.

 

So I will try downloading and doing your script stuff in the meantime. And when I have cvs access I will do the falling damage then if you still want me to do so at that time. I believe the other suggestion about pathing requires cvs access also since it is about water and ai drowning, apparently you have other code that deals with water also that I do not have access to at this time.

 

Never been asked to do scripts before, they usually give that to people who do not know how to code their way out of a wet paper bag.

[Crispy]

I think we should give thelvyn CVS access.

Heartily seconded. SDK coders simply can't work effectively without it.

 

Never been asked to do scripts before, they usually give that to people who do not know how to code their way out of a wet paper bag.

You seem to have an irrational hatred of scripting. Don't underestimate it. Doom 3 scripting is very powerful. I'm a good C++ programmer (IMO), and yet most of my modifications (especially relating to the AI) have been done using scripting. This is how game development works these days; as a rule, SDK changes are more expensive than script changes, so as much functionality as possible gets pushed into scripts.

[New Horizon]

Never been asked to do scripts before, they usually give that to people who do not know how to code their way out of a wet paper bag.

 

Please take into consideration that I 'personally' bumped you through the application process 'directly' to contributor status because you seemed like a level head. That doesn't happen all the time. All we ask for a first time contribution is to complete a task. Once that task is done, and we see that the contributor is able to follow direction from Team Leads and is serious about doing some work for the mod, we will then move on to bigger things like CVS source code access. As someone has already said, we've been burned before and these steps are in place for a reason. Personally, your attitude towards the type of task required worries me.

 

Now, if Sparhawk so chooses...he could decide to give you CVS access. He hosts the mod for us on his own personal server, so he makes the final call over who gets to access it.

 

Normally, we just want to see a single task completed 'before' access is granted. It's a good gesture.

[Ishtvan]

There is some precedent for having CVS access for contributor programming tasks though. I thought we just gave it to AluminumHaste less than a month ago?

 

@Thelvyn:

As for whether scripting is "below" you, first of all, what Crispy said. People working on scripting right now are all very talented, and have been known to modify the script interpreter and add new script functions in the SDK whenever scripting does not do something they want done. Second of all, no one's asking you to work on a task that doesn't interest you. You're welcome to say you'd rather not work on that and propose something that's more interesting to you, but keep in mind we have to go back and forth a bit in order to try and match "high priority" tasks to people.

[thelvyn]

Why would anyone want to steal your code anyway ? What possible use could they have for it ?

Are they going to compete with you ? I do not understand.

 

And WHO was it ? Someone from TTLG ? I hope not. I don't remember hearing about that at any rate. Not until this conversation anyway. I had no idea that had happened. It seems we are always paying for what assholes do in one way or another it seems.

 

As far as I go I have been playing thief ever since I received my pcgamer mag with the demo of thief when it first came out. I couldn't play for shit at first as I was trying to play it like a FPS

I have Thief TDP, Thief Gold, Thief2 and TDS of course. I want this project to succeed.

 

AI falling damage may have seemed like a self contained project but I don't think it is. I could see if I only had to add 1 function and that was it. There are too many changes to make I believe. I think I need cvs access to do that properly. Some of you do not agree with that and some do.

 

If I must prove myself then give me a project that is self contained that I do not need cvs access for. AI pathing was also suggested but that also requires CVS access, I hear you have another solution for water which you have integrated into your code base hence the need.

 

As far as scripting goes I am sure you have very talented people working on that but I would prefer to not be one of them. I would rather write code, thats what I do. Scripting is so limited in what you can do. I usually just go write code to do it rather then bother trying to make a script do what I want. Its quicker 99% of the time.

 

I think we are getting off to a bad start here and I do not know what I can do to change that at this point.

I have spent many hours working on this, learning the sdk is not something you can do in a single night or even a couple of weeks but I have been trying. I guess the real point is I feel like you do not trust me and that bothers me which is how we came to this point after all.

Perhaps I am just not a good fit here I guess you will have to decide that. So I am here to help, I don't know what else to say about it.

[OrbWeaver]

As far as scripting goes I am sure you have very talented people working on that but I would prefer to not be one of them. I would rather write code, thats what I do. Scripting is so limited in what you can do. I usually just go write code to do it rather then bother trying to make a script do what I want. Its quicker 99% of the time.

 

I assume you are referring specifically to Doom 3 scripting versus SDK coding? It would make no sense to talk of "scripting" and "coding" as distinct general concepts outside of some specific environment like this, because they are not.

 

The idea behind doing things with scripts in Doom 3 is to expose functionality that can be modified by the mapper. If it is hardcoded in the SDK you have an inflexible design which is not so amenable to customisation in this way (I have heard it said that Half-Life 2 was a culprit at this). The ideal design has a series of self-contained, atomic functions coded in the SDK which necessarily require code-level support (such as "create entity" or "translate object"), while all of the control logic is written in customisable scripts which can be overridden or modified by mappers on an individual basis.

 

It is certainly not a question of "hard" versus "soft" programming or anything; they are two different tools for two different problems.

[greebo]

I can't say anything about whether some things should be put into D3 scripting or into the C++ code, but - by all means - give this guy a chance.

[New Horizon]

I think we are getting off to a bad start here and I do not know what I can do to change that at this point.

I have spent many hours working on this, learning the sdk is not something you can do in a single night or even a couple of weeks but I have been trying. I guess the real point is I feel like you do not trust me and that bothers me which is how we came to this point after all.

Perhaps I am just not a good fit here I guess you will have to decide that. So I am here to help, I don't know what else to say about it.

 

I don't think we're off to a bad start, but you are misunderstanding the reason why we do things the way we do.

 

As I was saying earlier, this is just our process. It has nothing to do with not trusting you as a person, it's simply what we have had to do in order to figure out if members are serious about sticking around. In the beginning, we had many people sign up and we thought, "yay, we have a new member", only to never hear from them after they agreed to take on a fairly important task. As you might guess, this ends up wasting weeks of our time...when we could have assigned the task to an established member.

 

I pointed out that I've already skipped the interview process for you and placed you into contributor status. This is a sign of trust on our part. Many can't even be bothered to make it through the interview process.

 

Since you appear extremely eager to do some serious work...we will make an exception and open up the source code to you. Were you able to access the threads in the link I sent you by PM? If so, just follow those directions and contact sparhawk with the information he needs to set up your CVS account so that you can access the code. You can either use wincvs or tortoise cvs. I personally use tortoise since it integrates with the windows shell.

 

We do not distrust you, as you've given us no reason to...but we do have a system that we usually follow for our membership system.

 

At any rate, contact Sparhawk when you have gotten the software setup and you should then be good to go.