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!
Topic for enhancements on RF i made
-
fps
- Posts: 504
- Joined: Mon Sep 26, 2005 9:54 pm
- Location: in a magical land devoid of hope, happiness, and sanity.
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.
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.
1 wrote:
for the internet is a cruel and dark place at times, and there's sex and blood everywhere.
2 wrote:
You say that like it's a bad thing.
1 wrote:
You are a bad thing.
for the internet is a cruel and dark place at times, and there's sex and blood everywhere.
2 wrote:
You say that like it's a bad thing.
1 wrote:
You are a bad thing.
@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.
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.
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
-
benshelmars
- Posts: 26
- Joined: Tue Apr 17, 2007 12:26 pm
- Location: USA Florida
- Contact:
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.
Just curious.
We are all bound by the consequences of our decisions.
http://tfmarciniak.synthasite.com/
http://www.moddb.com/mods/the-otherside
http://tfmarciniak.synthasite.com/
http://www.moddb.com/mods/the-otherside
-
fps
- Posts: 504
- Joined: Mon Sep 26, 2005 9:54 pm
- Location: in a magical land devoid of hope, happiness, and sanity.
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!!!
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!!!
1 wrote:
for the internet is a cruel and dark place at times, and there's sex and blood everywhere.
2 wrote:
You say that like it's a bad thing.
1 wrote:
You are a bad thing.
for the internet is a cruel and dark place at times, and there's sex and blood everywhere.
2 wrote:
You say that like it's a bad thing.
1 wrote:
You are a bad thing.
Yes maybe. You must still script that behaiviour though.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.
@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!)
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
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.
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.
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
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.
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.
-
benshelmars
- Posts: 26
- Joined: Tue Apr 17, 2007 12:26 pm
- Location: USA Florida
- Contact:
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.
We are all bound by the consequences of our decisions.
http://tfmarciniak.synthasite.com/
http://www.moddb.com/mods/the-otherside
http://tfmarciniak.synthasite.com/
http://www.moddb.com/mods/the-otherside
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)
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)
Everyone can see the difficult, but only the wise can see the simple.
-----
-----
