Reality Factory

Interesting. It will be no problem to implement those because i made a new function for adding projectiles with custom damage to the world in the the CWeapon.h and CWeapon.cpp.

I will just have to change this line:
CCD->Weapons()->Add_Projectile(Pos, Pos, Orient, param4, DamageAttr, DamageAttr);
to
CCD->Weapons()->Add_Projectile(Pos, Pos, Orient, param4, DamageAttr, DamageAttr, arguments[8].floatValue(), arguments[8].floatValue());
and all is done.

I can already see that when we finally combine my soulutions + your physics release + Quests d3d9driver then it will be a release we can be proud of. That would just blast RFs current boundaries away!

should we post an announcement that all essential personel get to cover.
im atleast going to have a helmet and vest fitted with a gasmask before all this goes down.
i wouldent want to become conjoined with bits of flying boundaries.

Seriously though, if this pans out... i dont even know what to compare it to.
this would definatly give a real cutting edge to what was already sharp to begin with.

@fps : lol.

Just adding projectiles with custom damage wasn't enough for me. And so, i am working on a new feature:

I call it the 'ScriptedProjectile'. That is, when the projectile makes an impact on an actor, a script order is executed!
That opens up totally new possibilities! I can finally implement my magic spells with different types of damage, resistances, better effects, auto-casting (when one has reached its destination, cast again), moving poison, and all other kind of stuff!

You will be able to get the entityname of the last hit actor with a command, so you can do custom damage or apply effects to it.

I am not a programmer, but this scripted projectile "magic" could it be mutated so that within different parts of a level or environment it could behave differently or randomly?

Just curious.

whoa!!! scripted projectiles.
does this mean that we may possibly be able to apply physics to grenades and such.
i have been looking into defining seperate projectiles for a scripted weapon so to have different impact sounds and riccoshays (spl) and such.
this will make that a lot easier.
will there be an order that can be executed when the projectile is spawned? for things like homing missiles.
i think it would be cool to do a proper hand grenade that spawns seperate projectiles when it explodes.

it all sounds extreamly cool.
i cant wait!!!

benshelmars wrote:I am not a programmer, but this scripted projectile "magic" could it be mutated so that within different parts of a level or environment it could behave differently or randomly?

Just curious.

Yes maybe. You must still script that behaiviour though.

@fps: Different impact sounds are definitely possible. But i still have to test this feature if it works. If it does, you can do anything that you could do in a normal script order (but the script order has to be lowlevel!)

cool.

Ok. Next addition:

The AttachCamera() lowlevel function can now have 6 additional parameters that define the offsets of the camera. This way it will be much simpler to make ingame cutscenens, because you can make views from behind, left, right, top-down view, or even a view from the bottom. I will post some screens once i have tested it.

You can now use the AttachCamera() function in two ways:
AttachCamera() - like before;
AttachCamera(float offx, float offy, float offz, float rotX, float rotY, float rotZ) - defines camera offsets (in relation to the actor) and camera rotations also.

EDIT: The feature seems to have some problems. I am going to tfind the bug.

how many more things are you planning on adding???

Well, i don't know. I am adding whatever i need for my game project or what comes to my mind. At the moment i am just waiting for the pysics release source code.

i thought that was already done?
or is he still working on that time scale issue?

sorry, I'm quite ready. My PhD access exam was interfering with the release. So:

1) time slicing is done...
2) ..while the trick to avoid the time paradox is not that effective. Basically the timeslicing is limited if the time value is too high (that is: the engine had a slowdown), so it runs in real time mode. This means that if that limit is not reached, the physics is updated using a variable timestep that makes the physics simulation framerate independent. While the limit is reached the simulation enters in fixed step mode, that is framerate dependent (slower the machine, slower the simulation and vice versa). This trick makes the engine recover most of the situations that would be affected by the time paradox, but sometimes the simulation remains slowed down. I tried several solutions and I finished my knowledge on the topic, I tried everything I could. I simply have to release the code and let the other developpers deal with it. They probably know how to solve it if they can look at it.
3) I will not add any physicsScript entity. Instead I will add new pawn script commands to control the physics entities.
4) I tried to implement the standard newton vehicle container. The implementation was correct but the result was poor and unsatisfying, so I removed it. I gave up with vehicles: too complex for me.

This week I will release thee source, I promise.

I hope you did well on your exams. All I can say to you guys is that your work is fantastic reading, not that I understand all of it but it is great none the less. Thank you for all you have done and continue to do.

Ok there is one last thing that i still have to implement from my side:

It's called QuadMesh - similar to federicos TriMesh (but i don't know that much about it...)

It is specifically optimized for terrains, but you can use it for any other mesh too - if you export several floors of a building/a cave seperately it will be just fast as it would be with a terrain.

It works similar like an octtree, just that it slices the mesh into 4 parts instead of 8, and it's also a bit simpler. This is what it does:



I think you now get the idea: a QuadMesh Level 1 slices the mesh into 4 parts, the QuadMesh Level 2 slices those 4 parts agin in 4 parts each (=>16parts) and the QuadMesh Level 3 slices them up again 4 times (=>64parts).
Then it is just tested in which part you are and then the collsion is just done for this single part of the mesh. This will help alot when the new 3d9 driver comes out, because then the models will quickly gain polygon numbers (since we are not that limited then).

Right now i only implemented level 1-3. The Quadmesh should automaticly create the best one that is best fitted for the mesh - keeping a limit of 256 polys in one single part. So right now rf's collision detection should be able to deal ok with up to 8-16k poly-actors, then the collsion detection gets slower. (and this is with just 3 levels! 4 levels will make this number 4 times as high!!!)

If this works, we can have large terrains much simpler - no need to to slice your actors anymore. When i have the source code of the physics release, i can then look what is faster - Tri-or-QuadMesh (right now i think that QuadMesh will be faster, but i don't know)

for the scripted projectiles, can you apply forces to the projectiles for innacuraccy, or is it only for when it hits something?