Physics...

by Dr_Evil1 on 09/09/2007 14:27, 127 messages, last message: 04/30/2008 03:02, 94898 views, last view: 05/18/2024 21:21

Out of interest, how advanced is the physics in Sauer? The only notable useage I see in-game is the GL rebound of walls, and a slower movement time whilst in water, (both player and grenades).

Increasingly, physics is becoming a parallel with graphics in importance in new gaming titles. Half Life 2 comes instantly to mind.

If the physics are basic, if they were to be improved levels with physobjects could become a reality. New gamemodes, mods and SP missions could become a reality. Graphicly, Sauerbraten is probably the best open source game out there, especialy the water :-).

Personaly as a BIG HL2 and GMOD player, the possible inclusion of a physics engine per-say would increase the quality of gameplay dramaticaly.

Thoughts? -- Dr_evil

   Board Index   

#87: Re: ..

by demosthenes on 04/10/2008 20:43, refers to #86

What about copying over some of the movement code from editmode in no/micro-gravity situations?

reply to this message

#88: Re: ..

by MovingTarget on 04/10/2008 21:48, refers to #87

Yes, that would probably work, but there are two problems:

1) Determining on what levels of gravity the editmode code should be used, and

2) Switching between editmode code and normal movement code when the player is on the ground.

If number 2 could be implemented, 1 would cease to be a problem.

reply to this message

#89: Re: ..

by demosthenes on 04/11/2008 00:11, refers to #88

True. And a simple if modification could solve #2, I hope.

If the existing distinction between edit movement and non-edit movement is simply if (editing), then it could be if (editing||!editing&&midair).

However, I've not looked at the code in a long time, and I imagine that my simple solution wouldn't work, and has too much of playing-with-legos for my taste anyway. :P

reply to this message

#90: ..

by smartalco on 04/11/2008 06:10

unless your implying jetpacks, you can't move when free floating in 0g anyway, heck, you can't even turn to aim :P

aside from that realistic difficulty, at anything above 0g, you wouldn't want to move as in edit mode anyway (although I would limit the gravity to certain increments so someone doesn't set it to .00001 so jumps take 10 minutes)
and once at 0g, you wouldn't want normal movement code at all, since you can't propel yourself forward on the ground without propelling yourself upwards as well, the only thing you would need is to cross the wall collisions from normal with the movement of edit mode (0g GL = RL, lol)

on some of the above mentioned physics, how exactly does the current grenade physics work? they already roll dependent on their direction of travel, fall with gravity, and bounce of objects, all client side? couldn't the same system be applied to any object, just without the rolling? (or maybe just some giant spheres rolling around :P), the only problem I see with this is that grenade physics are calculated client side, which is only allowable because after they are launched, nothing can change their direction, the only way i see to replicate this system in other objects is to prevent any object from being acted upon until the previous action has played out (stop moving), this is where a system mentioned 50 posts or so ago would come in handy, just saying Player X shot a projectile/ran into Object Y at velocity Z (for physics like what is currently implemented, it doesn't really matter where on the object it is, just what direction and how strong the force is, both of which are covered in velocity, hell, you could eliminate the Player X part and just have the initiating client tell the server "Object Y affected by velocity Z", I wouldn't think this would incur any real overhead, your back to making sure the object is synced on every client, maybe "Object X at position Y affected by velocity Z")

wow, longer post then I intended

reply to this message

#91: Re: ..

by MovingTarget on 04/11/2008 19:01, refers to #89

My hopes are not high that a simple hack will do it after a short look into the code.

reply to this message

#92: Re: ..

by demosthenes on 04/11/2008 20:24, refers to #91

Didn't think so. :)

reply to this message

#93: Re: ..

by fhdskdconorsfdhk on 04/12/2008 06:23, refers to #83

I implemented this in my own build. It was very basic, and it could have been used to cheat online.

I implemented the following commands:

/lowgravity

/normalgravity

/highgravity

Then, I put the commands in. I must say, in face-capture, it was soo much more fun in DMSP than with normal gravity.

I don't know how we would implement this without commands. Maybe internally if a certain map is loaded, then it would switch gravity.


If it was in the CFG, then a hacker could just mess with the CFG.

reply to this message

#94: ..

by Acord on 04/12/2008 19:24

For anyone who wants to mess around with this and can figure out how the SVN thing works, it's already existent in Blood Frontier along with double+ jumping that increases in the number of times it can be used as the gravity goes down.

So the lower the gravity, the more mid-air boosts you get.

reply to this message

#95: Re: ..

by fhdskdconorsfdhk on 04/12/2008 19:29, refers to #94

Sweet! I\'ll check out BF. :)

reply to this message

#96: Re: ..

by the W4 (old comp) on 04/13/2008 21:44, refers to #93

Just have a [/gravity "Value"] command in a cfg. In this case, if there is no command, the default would be 100.

With this command:
100 is default gravity
200 is 2x gravity
500 is 5x gravity
50 is 1/2 gravity
25 is 1/4 gravity
and so on...

This command should probably be disabled for everyone except the master in coedit.

reply to this message

#97: ..

by Acord on 04/14/2008 09:12

Just fair warning - none of those variables can get changed outside of edit mode. Makes it kind of obvious if someone tries to cheat :)

reply to this message

#98: Re: ..

by Q009 on 04/14/2008 11:06, refers to #96

But the gravity value should be synchroniosed on all servers because someone can change the it in the map cfg...

reply to this message

#99: oops

by Q009 on 04/14/2008 11:07

Opps... Sorry for that "...the in..."! xD I forget to delete it...

reply to this message

#100: ..

by SheeEttin on 04/19/2008 23:01

Here, I've modified my source so that you can just do /GRAVITY in the console to change the gravity... edit line 399ish in engine/physics.cpp to read "VAR(GRAVITY, 0, 200, 20000);".
It's a lot of fun to run around in reduced gravity.

reply to this message

#101: Re: ..

by MovingTarget on 04/20/2008 00:03, refers to #100

Yeah, but that doesn't fix aforementioned issues. It IS fun, though :-)

reply to this message

#102: Re: ..

by jbuk2k7s cookie has gone on 04/20/2008 12:11, refers to #101

Why not make the minimum gravity 1?

reply to this message

#103: Re: ..

by Megagun_0 on 04/20/2008 13:55, refers to #101

Fixing those issues might be pretty tough, too, as a 6 degrees of freedom movement style (as in Descent 1 and Descent 2) isn't easy to do since it requires a sizeable rewrite of the code (I've tried to do it, but I kept hitting obstacles)..

reply to this message

#104: Re: ..

by MovingTarget on 04/20/2008 14:55, refers to #102

I'm not quite sure how you think that will fix the issues I was talking about...

reply to this message

#105: Re: ..

by Oh No Ghost! on 04/20/2008 19:26, refers to #102

I think the GRAVITY minimum should be a bit higher- at least enough to descend at a noticeable rate.

If we do this to gravity, I think Jumpvel (jump height) should also be adjustable- that's more what people think is changed when "gravity" is lowered.

reply to this message

#106: fjkshdfjk conorhfsf

by jdfhsdconorhsfjd on 04/20/2008 19:35

When someone joins a game, the server would have to have the map CFG's on it. then it would simply send away the gravity. Doesn't cause lag, it is just one number being sent right when someone joins.

reply to this message

   Board Index