id Tech Forums

I usually resort to simply deleting my config file, that usually fixes such issues.

Quote from: VGames on October 06, 2014, 06:44:53 PM
Nice interview. Hit a lot of good questions.

they just better allow god mode and other cheats. Lately games have not included these features. Sometimes I just want to run around and slaughter.

I haven't found a game without a trainer yet.

Just use local source control. Download SVN & and a tortoise client, it's not more than 10 minutes work to set up. Commit changes to the repository after each time you map.

I have all versions of all incarnations of all my maps and all my work in my repository. I could go back to any version of any map (or any other work) because of version control.

Losing work like this is really completely unnecessary.

I love this from begin to end.

I'm not totally convinced of that, Zombie. Or rather, I'm not totally convinced that they count towards the entity limit. I was going to post the same thing as each thing you create from an FX is an entity, but then again, decals are entities also (you can see this by using the g_showentity command) and in my tests they never counted towards the entity limit.

I think the only real options are to check the source or to simply test it (create an FX that spawns more entities than the entitycount and see if it bombs the level).

Quote from: VGames on September 15, 2014, 12:45:51 PM
What about a light source along with the particle effect. I was able to do this using projectiles but it was too tasking on the system is there a better way to add lights to a bone.

It might be better to start an FX on the bone then. You can add lights/particles e.g. to FX files easily.

Here's the complete reference: http://www.iddevnet.com/doom3/fx.php

To start an FX, you have several methods. You can spawn and bind (then trigger) an FX entity to a joint using the BindToJoint() function in script, then remove it after a certain amount of time.

Yes, it's tedious. That's why I often see teams just make one or two general skeletal setups and then model around those, so they can reuse the ragdoll. I cut hundreds of hours of fiddling and (play)testing by simply opting for gibbing creatures in Grimm:Quest for the Gatherer's Key.

Tips:

- Use no spaces in bone names
- Use no upper case letters in bone names
- Always have an origin bone
- All bones must be connected to other bones or the origin.
- Bipeds need specific bones for IK to work right (knee, loleg, foot see the MP model for a good reference). IK uses the ragdoll definition.
- The AF editor crashes quite a lot. I tend to use the AF tool for creating a new AF. Then using notepad for basic setup and then the AF tool for tweaking.
- Setting up a proper ragdoll means you need to weight each bone correctly, otherwise some limbs could be too 'heavy' in comparison with other limbs.
- When learning I found that creating simple ragdolls first (e.g. a flag, a rope etc..etc..) really helped me to understand the underlying principles, or rather. It really helped me learn which buttons to press and which buttons not to while using the AF editor. Starting with simple shapes it's also easier to test the different rotation methods for each bone. These are called the constraints.
- When creating a ragdoll you'll need to add constraints to each limb, constraints tell the engine in what direction the limb may rotate, and how far. This makes it so limbs can't rotate into unnatural movements (e.g. an arm that twists 360 degrees would be impossible and will distort the model so the arms need constraints).

Making ragdolls is basically just a lot of fiddling, testing, dragging the model through your testmaps and seeing how it reacts with the world.

I just realised that you can probably fake this quite convincingly by grabbing the velocity of the object and just add that. It wouldn't be as specific as seeing each limb flying in the right direction, but it might work with some tweaks.

I would advice you to start with a smaller project to learn programming as what you are describing seems impossible for somebody with no programming skills (I have 20+ years of programming experience and I can't even begin to fathom where to start to implementing Brink like improvements on the D3 Engine).

A starting point may be: http://www.learncpp.com/
Then you'll need to learn about DirectX: http://msdn.microsoft.com/en-us/library/windows/apps/jj554502.aspx
Of course you'll want to keep it OpenGL compliant (or not): http://www.glprogramming.com/red/

Good luck with your project!

Animating is a hard, hard, job. Especially hand animation. I've spent 5 years searching for an animator while working on Hexen:Edge of Chaos, planting newsitems all over the web, making trailers and banners but I only found 2 in all those years.

So I had to switch to plan B as well and found this: http://alastaira.wordpress.com/2013/07/24/using-free-mocap-data-for-game-character-animation-in-unity/

What you want is the Carnegy Mellon free animation library. These are mocap files that you can convert to Blender, 3dsMax etc..etc.. It's a bit of a step to export them so you'll need an exporter for Doom3. I don't know where those are these days, but I'm sure another poster will post the links here.

My experience with ragdolls after death anims was somewhat mixed. Sometimes it looked good, but most of the times the transition was weird, they just sort of slumped. What you'll want to do to make it look professional is take the velocity of the limbs and apply that to the ragdoll. You could make an updateRagdollVelocity() command in the SDK, which translates the velocity of the current animation to the ragdoll skeleton. But it might take some trickery, first measuring the velocity of each limb then translate that to the ragdoll.

It's a simple matter of extending the kill() routine function, calling an extra animation.

Here's one taken directly from Hexen:Edge of Chaos.

void monster_base::state_Killed() {

animState( ANIMCHANNEL_TORSO, "Torso_Death", 0 );
animState( ANIMCHANNEL_LEGS, "Legs_Death", 0 );

waitAction("dead");

if ( hasAnim( ANIMCHANNEL_TORSO, "death" ) ) {
restoreMove();
stopRagdoll();

playAnim( ANIMCHANNEL_TORSO, "death" );
while( !animDone( ANIMCHANNEL_TORSO, 0 ) ) {
waitFrame();
}

stopMove();

}

//become ragdoll code here

setState( "state_Dead" );
}

Just got a newspost authorised about id tech forums: http://www.moddb.com/mods/grimm-quest-for-the-gatherers-key/news/doom3world

Quote from: douglas quaid on September 06, 2014, 07:35:16 AM
Thanks for the concern but I had Simulation take a look at it yesterday. The file is corrupt but he was able to salvage some work from it. Yet another frustrating setback in TR's production. Looks like I'll have to go with my memory to replace the corrupt brushes. Feels great 

Quaid.

What you need to do is install a local version of Tortoise and SVN so you can simply version your maps.
I've done this for years and I've never lost work since. It's also very easy to install and use!

First step, install Subversion from here: https://subversion.apache.org/
Second step, install Tortoise SVN client for windows: http://tortoisesvn.net/

Now, after rebooting, you make a 'repository' of your Doom3 folder. Each time after you've worked on your map, you commit the changes. Now you can step back to whatever version you committed earlier to your build.

Version your maps and never lose work again.