func_gravity - New Entity for gravity. *updated 24 May*

Dante_uk · **Posted:** Fri Mar 11, 2005 5:43 pm

This adds some new features / abilities to Doom3.

This is not the final version but is close enough for people to have a play with.

Previously this was mentioned and previewed here but my code has gone beyond just allow the player to walk on walls.
http://www.doom3world.org/phpbb2/viewtopic.php?t=9113

The latest file is here. *UPDATED 24/5/2005* Requires Doom3 1.3 Patch
http://homepages.nildram.co.uk/~danteuk/DanteUK.zip
http://danteuk.gotadsl.co.uk/d3/DanteUK.zip

This zip files includes game obj (Windows&Linux)) & gravtest map.

The binaries include my winamp mod and the water mod by inolen / idiom and the bloom mod by SantaClaws. ( required assets included in zip ).
Credits and details are in readme files included in zip.
gravtest test map now includes: centrifuge room and water test room.
( no new code for water yet! ).

I've decided to make source available again now for anyone that's interested.
http://homepages.nildram.co.uk/~danteuk/src.zip** OLD ** New source for 1.3 available soon.

Standing on a wall:

Standing on the ceiling:

My readme for the func_gravity:

Quote:

func_gravity : allow change of gravity strenght and direction.
By dante_uk ( Neil J Martin ).
Version 1.1.10

Changes:
1.1.10 Bug fixes only.
1.1.9-1.1.5 tests only.
1.1.4 New properties.
Now using Physics_Monster::CheckGround after changing gravity for monsters.
Scripting events added for turning on/off a func_gravity.
1.1.3-1.0.0 early versions, can't remember what I changed

Properties:
TYPE NAME DEFAULT / DESCRIPTION
idVec3 gravity; // 0 0 -1066 / new gravity value.
bool playerOnly; // 0 / effect only the player.
bool monstersOnly; // 0 / effect only monsters.
bool triggeredByOnly; // 0 / effect only the entity that touch the func_gravity.
bool playerToo; // 1 / effect the player too.
bool insideOnly; // 0 / effect only entities inside the func_gravity.
bool monsterTrig; // 0 / monsters can trigger the func_gravity.
bool activated; // 1 / if off then event_touched is ignored.
bool stopPlayer; // 0 / stop all player movement b4 changing gravity direction.
bool shiftPlayer; // 1 / shift player away from ground before changing gravity.
bool debug; // 1 / displays lots of info to console.
float changeRate; // 0 / used for smoothing of gravity change. 0 = no smoothing.

Known Issues ( main ones at least )
1. using silly numbers to move player or monster away from ground before switching gravity, should
really be checking the direction of gravity change and move by the right amount depending on width
or height of clipmodel.
2. some gravity changes make the player face the wrong way afterward. This seems to be a problem in the physics code (clipmodel stuff), I'm looking at various ways to solve this, so far I've had some interesting results! but nothing helpful.

Feature Ideas / Suggestions:
* Smooth the transition from current gravity value to the new vale. ( mostly done )
* targetting. target a func_null in the map so gravity sucks/pulls(?) in that direction.
* finding a way to reset gravity back to it's original value for a an object/actor when it leaves the
volume of the func_gravity.
* find a way to make it also effect friction. ( then it would be good as a water like entity. )

A few suggested uses of this mod:
* for creating a trigger to affect worldgravity and activate monsters & physics objects.
* for creating localized areas with their own gravity and effecting all items inside that area.
( ex: you could create a room where if you shoot out the window the room becomes a vacuum and the
gravity is greatly reduced until you get to a gui to close a shutter. )
* Allow walking on walls.

You are free to use this code in any Doom3 mod, just please include my readme files.

New Commands:
setgravity x y z playerToo
eg: setgravity 0 0 1066 1

Test map: gravtest.map

Scripting Events:
becomeActive()
becomeInactive()
setGravity( idVec3 ) ie 0 0 1066 - Not actually tested this yet.

SnoopJeDi · **Posted:** Fri Mar 11, 2005 9:33 pm

Is it really necessary to create a new thread for this?

BloodRayne · **Posted:** Fri Mar 11, 2005 10:24 pm

SnoopJeDi wrote:

Is it really necessary to create a new thread for this?

Yes

Dante_uk · **Posted:** Sat Mar 12, 2005 1:10 am

I figured the func_gravity stuff has a lot more uses than just allowing walking on walls.
I've someone was looking for a way to make room or area with reduced gravity or gravity pulling in a different direction, they may not think to look in a thread about about walking on walls.

I may be wrong, I'm only trying to help

My code is far from perfect but does the basics and I'm happy for anyone to use it and improve/extend it.

iceheart · **Posted:** Sat Mar 12, 2005 1:36 am

It's fine, we like new threads here

.

just1n · **Posted:** Sat Mar 12, 2005 2:46 am

Great stuff, plan to use it with my mod.

Good job, nice work.

Dj Dooms Day · **Joined:** Tue Apr 22, 2003 4:47 am **Posts:** 525

Dante, your a champ. Keep us posted on any updates you make.

Dj Dooms Day · **Joined:** Tue Apr 22, 2003 4:47 am **Posts:** 525

Ok, i finally got the right co-ords going in my cylinder, which will allow me to bascily run around in it, changing grav direction accordingly. But there are a few problems.
1. I chucked some boxes and a ragdoll in there and they didn't work properly. They hardly ever change grav direction, even though they pass through several grav trigs. Now one would think i simply don't have it setup right, but sometimes (seems random) a box or ragdoll will change grav direction. Its wierd.

2. I have it setup with 'insideonly=1' and i seem to keep getting knocked back everytime i try to enter a grav trig. I can noclip into them fine and they'll work. Yes i've got the texture on 'common/trigger'.

SyPHer_ · **Posted:** Mon Mar 14, 2005 8:06 am

Is it possible to make wall-jumping (ala, Urban Terror q3 mod) possible? So theres default gravity and stuff, but if i jump at a wall and then jump again while hitting the wall, i can jump off it?

Dj Dooms Day · **Joined:** Tue Apr 22, 2003 4:47 am **Posts:** 525

Thats very possible, i don't think it has much to do with this though, at all.

breakerfall · **Posted:** Mon Mar 14, 2005 3:32 pm

Interesting... so would this give you the ability to make the player able to walk, say, around a loop, like the one in the vehicle test map?

Dante_uk · **Posted:** Mon Mar 14, 2005 3:56 pm

Dj Dooms Day wrote:

Ok, i finally got the right co-ords going in my cylinder, which will allow me to bascily run around in it, changing grav direction accordingly. But there are a few problems.
1. I chucked some boxes and a ragdoll in there and they didn't work properly. They hardly ever change grav direction, even though they pass through several grav trigs. Now one would think i simply don't have it setup right, but sometimes (seems random) a box or ragdoll will change grav direction. Its wierd.

2. I have it setup with 'insideonly=1' and i seem to keep getting knocked back everytime i try to enter a grav trig. I can noclip into them fine and they'll work. Yes i've got the texture on 'common/trigger'.

What should happen when you touch a func_gravity with insideOnly set.
all player movement is stopped in all directions.
the players position is adjusted away from the current gravity value( ie if gravity is downward the player is moved up )
Then the gravity vector is changed and applied to all entity inside the func_gravity, including the player.

One problem I think I had was when two func_gravitys were close to each other, what happens is the player can be triggering the event_touch for both func_gravities at the same time, this WILL cause problems.
See if it's possible to put a space between the func_gravitys that's is wide as the player.
In theoy an item or player moving around will keep it's gravity value when it leaves the func_gravity entity because nothing will change back to the default. So a gap between the func_gravities shouldn't cause a problem.

I think ragdoll entering a func_gravity SHOULD trigger the event_touch code and SHOULD then get the new gravity value. (I've not actually tested this though, I will tonight ).

A movable item being throw/pushed into a func_gravity will NOT trigger an event_touch ( I tested this with a chair ). I'm not sure of a way to handle this.

One option might be to add some code to the movable entity so it checks to see if it's inside a func_gravity every time it's in motion. (possible heavy performance hit).
Another option would be for the func_gravity to have a flag to say whether to continuely check for objects inside.

Dj Dooms Day · **Joined:** Tue Apr 22, 2003 4:47 am **Posts:** 525

Your right, it was the func_grav triggers touching each other that was the problem.
But the current way your doing it, ala litterially moving the player, seems very mundane, and its not nice jerking around when walking through one.
There must be a better way to do this. Has anyone tried contacting the ID fellow from the SDK resource website?

Also, ragrolls don't trigger the event_touch. I had a zombie walking on the roof and as soon as he died he gained the default grav values and hit the ground (He passed through several func_grav triggers too).
Maybe you should take a look at how event_touch works and maybe even create your own event_touch?

Dj Dooms Day · **Joined:** Tue Apr 22, 2003 4:47 am **Posts:** 525

Oh, and another thing. When i activate a func_grav trigger, not only does it jerk you around, but sometimes it flips the direction your facing. That plus the fact i'm doing loop-de-loops in a cylinder makes it all one VERY confusing scene.

Dante_uk · **Posted:** Tue Mar 15, 2005 11:09 am

I'm overridding the code for event_touch, the problem is it's not being triggered by movables or ragdolls.
I'll have to have a look at the code for those to see if there is a way for them to call the trigger. I assume movables & ragdolls don't/won't trigger any other kinds of entities either.
The alternative is for the func_gravity to continuely check for entities inside it and change their gravity. Depending on how many func_gravities you have and how fast your CPU is this may be a better option. ( maybe I can make it only check every alternate game tic or something ).

The player jurking around is because if you make a major change to the gravity value the engine(or properbly the physics code) instantly flips the player/clip model to be correct for the new gravity direction. This means if you are stand on the floor and with gravity at 0 0 -1066 and flip it to 0 1066 0 then you would find yourself half imbedded in the floor, by moving the player away from the floor first and then switching gravity, I avoided the problem.

What can be done to improve this and make it less jurky is if more tests were done first, like testing to see if the player is actually touching the floor, a test to see if the new gravity value is going to flip the player into the wall/floor. Also depending on the amount of change the player needs to be moved further away. eg if gravity is reversed then the player needs to be moved away from the floor by the complete height of the model or his head will be stuck in the ceiling!!
I will try and look and this tonight.

As for the changing direction, that's a problem in the physic code(something I haven't changed), I think it's doing something stupid, in my test map if I face my north wall and flip gravity so I'm walking on it, then I end up looking at the ceiling(correct) if I face the south wall and flip gravtiy so I'm walking on that then I end up facing the floor(wrong).
I think it's rotating the player by 90 degrees anticlockwise and then re-aligning the feet with the 'new' floor. I think I'll have to look at the physics code and see if I can make it a little more freindly and to check(somehow) the old value for gravity so it knows how to keep the player facing the right way.

Is it possible for you to mail me your map so I can see exactly where the problems are. Then I test my changes to see if they actually fix the problem for you too.

Dj Dooms Day · **Joined:** Tue Apr 22, 2003 4:47 am **Posts:** 525

Ahuh. Yeah i think making it do a check every alternate game tic (how long is that btw?) would be a good idea. We have the option to activate and deactivate the func_gravs so if there are a lot in a lvl then some simple management would fix any performance issues.

One thing i don't quite understand (or missed), is why you have to reposition the player in the first place. I know there is some issue with the player instantly aligning with the new floor, but why can't he just gradulary reposition instead of teleporting? That way if he encounters a brush he'll bounce/move off it, instead of THROUGH it.

I've sent a link to where you can download my map to your email addy. Thanks for your support.

idiom · **Posted:** Tue Mar 15, 2005 1:10 pm

This is awesome

Could you have the gravity vector changed dynamically, like from a gui or something, similar to what happens in one of the new Ue3 videos?

Dj Dooms Day · **Joined:** Tue Apr 22, 2003 4:47 am **Posts:** 525

idiom wrote:

Could you have the gravity vector changed dynamically, like from a gui or something, similar to what happens in one of the new Ue3 videos?

That could be done in about 2 seconds (minus the GUI work).
The plate in the middle of Dante_UK's map basicly does that. You walk over it and it flips the room upside down.

Dante_uk · **Posted:** Tue Mar 15, 2005 1:34 pm

Dj Dooms Day wrote:

idiom wrote:

Could you have the gravity vector changed dynamically, like from a gui or something, similar to what happens in one of the new Ue3 videos?

That could be done in about 2 seconds (minus the GUI work).
The plate in the middle of Dante_UK's map basicly does that. You walk over it and it flips the room upside down.

Not quite Dj Dooms Day, to dynamically change the vector from a gui or script is something I've looked into. I create a couple of simple functions for becomeActive/becomeInactive and set them up as events. I used the code for On/Off in the Light.cpp as a basis, because you can call light_1.On() from a script/gui.
Unfortunately I've not got it to work yet. If I do a script with myfunc_grav1.becomeInactive() it complain that becomeInactive is an invalid value.

My Code.

Code:

const idEventDef EV_becomeActive( "becomeActive", NULL );
const idEventDef EV_becomeInactive( "becomeInactive", NULL );

CLASS_DECLARATION( idEntity, idGravity )
   EVENT( EV_Touch, idGravity::Event_Touch )
   EVENT( EV_becomeActive, idGravity::Event_becomeActive )
   EVENT( EV_becomeInactive, idGravity::Event_becomeInactive )
END_CLASS

Light Code.

Code:

...
const idEventDef EV_Light_On( "On", NULL );
const idEventDef EV_Light_Off( "Off", NULL );
...
CLASS_DECLARATION( idEntity, idLight )
...
   EVENT( EV_Light_On,      idLight::Event_On )
   EVENT( EV_Light_Off,       idLight::Event_Off )

If I get this to work, then I can look at allowing the gravtiy vector to change dynamically ( ie from a gui/script ).

Dj Dooms Day: The player doesn't teleport when you change gravity, I nudge the player away from the ground, if I didn't the players origin would remain the same just the model would be rotated, leaving it half imbedded in the nearest surfaces. It maybe that it is rotated around the center of the model, but I think it's rotating around origin of the model and that for players and monster is the base of the model( ie feet ). You notice on my test map with that center trigger that flips gravity, you do fall to the ground ( well ceiling actually

). That's why I placed cusions there.

zl1corvette · **Posted:** Tue Mar 15, 2005 6:03 pm

Events need to be added to scripts/doom_events.script ( or some other script file ), did you do that?

Doom3world

func_gravity - New Entity for gravity. updated 24 May

Who is online