Feature request
Blitz3D Forums/Blitz3D Programming/Feature request
| ||
| Wouldn't it be nice to have EntityXSpeed(),EntityYSpeed(), and EntityZSpeed() functions? not nessecary, but it would definately make coding a lot of things easier, imho. |
| ||
| No it wouldn't since those functions would always return 0. |
| ||
| They could be implemented similar to the KeyHit function. In other words, EntityXSpeed would return the amount the entity has moved in the X direction since the last time the command was called. Seems rather pointless though. I've never needed anything like this, nor do I see what would be aided by having these commands. Morover, there are a number of sticky implementation issues, like what data is returned if the entity rotates in its motion between calls to the command. |
| ||
| Sounds slightly useful. However, I can't think of a plausible scenario where it would prove useful, though. |
| ||
| I would of thought "the speed" of any entity you move around would be controlled by variables so you'd inherently know their speed anyway. |
| ||
| Cor, not that old chestnut again. Every time somebody suggests a new command for looking at the entity state, somebody else trots out "you already know it because you're using variables." There are a number of problems with that, elaborated many times before, most of which apply just as much here as when they were elaborated. Taking one example, your speed variable wouldn't be known to an included library function, like, say, a physics simulation. This doesn't present an example where EntitySpeed commands would be useful (after all, Tokamak works fine without them) but this example does show that variables don't automatically mean transparent data. |
| ||
| I think in this case entityxspeed = moveentity |
| ||
| heh, I know, and I've always backed peoples requests to have functions to retrieve values that can be set. I just thought this case was a bit different as there aren't commands to set an entities speed so why have commands to retrieve it. Plus, on this occasion, I truly couldn't see the thinking behind having such functions. Of course, I could be wrong. :) |
| ||
| The Storm engine's new entity system monitors this constantly this is for example needed for use in our own 3d sound system. (since we don't use blitz's) |
| ||
| Presumably these proposed functions would be used in conjunction with captureworld? |
| ||
| I sort of do this with all my entities anyway. Every entity that moves in my games has a pivot called physics_pivot. I apply all the forces that are acting on the entity on the physics pivot... The pivot starts at 0,0,0 There is a forward force on the entity rotateentity physicspivot,entitypitch(player),entityyaw(player),entitypitch(player) moveentity physics_pivot,0,0,2gravity translateentity physics_pivot,0,-.98,0wind from the east... translateentity physics_pibot,-.5,0,0etc etc Then the location of the physics pivot is the resultant force on the entity... so you then just... translateentity player,entityx(physics_pivot),entityy(physics_pivot),entityz(physics_pivot)If you want to know the total speed of the player... I have a pivot called middle that always stays at 0,0,0 So to get the speed: speed=entitydistance(physics_pivot,middle)Oh, and with the middle pivot you can dampen all the forces... pointentity physics_pivot,middle moveentity physics_pivot,0,0,speed*.9will reduce all the forces to 90% Anyway, there's Rob 'no math' coding 101 for you! |
| ||
| I can see how this would be a useful function to have access to, for physics libs. Also, for people who move entities by setting their position but not storing it... why store it twice? But if an entity collides with something, would the speed be reduced? The entity didn't move as far. But if an entity does collide with something in a physics simulation, you usually don't want to slow it down... unless you're dealing with verlet physics. You want it to rebound at the same speed it was traveling originally. So you'll still need to remmeber how fast it was going. So it doesn't seem so useful after all. Also keep in mind that though one does not have access to the variables the user stores the velocity in in their physics lib, one does have access to the position, and one can store that position in the physics lib with the entity pointer. So this funciton is not neccessary to be able to calculate that information in a physics lib easily, unless you're trying to make a lib where you have to pass the entity you want updated to it every frame, and that doesn't seem like a good way to do it. Perhaps it doesn't seem that useful to me after all. |
| ||
| I think it would be very useful for doing simple collision physics.... if 2 cars are travelling down a road at 100MPH and one sideswipes the other you need to know its speed going sideways and not forwards so the command would actually be very useful, |
   |