Silly DB limits
by Max Robinson · in Torque Game Engine · 01/31/2003 (5:44 pm) · 7 replies
I have a question, I guess mostly for the people who made the engine in the first place, and also for anyone who has worked with it.
I mostly ran into this while modding T2, and now that I can remove it on my own project, I see no reason not to.
What I'm talking about are the limits, such as possible gravity mod, etc, on projectiles.
There is absolutely no reason to limit gravity on a projectile. At all. Why are they there? It is really silly to bother limiting something that really doesn't need to be limited. What if a modder, or developer, wants to make a rising projectile, or one that falls unnaturally fast? (yet you can make one fall unnaturally slow) They need to remove this check if they want to do this!
Another one is a negative ejectionOffset. Particles arent really rendered the instant they are created, so if you want to make sure an effect like a muzzle flash is far back enough, this wouldn't be a bad idea. Removing this restriction would make creating an emitter where the particles gather together (instead of flying out) a trivial thing to make.
There are a few others that seem silly. I think elasticity is limited 0-1 also. While > 1 would make a thing that bounces higher and higher, what if someone wants this? If a modder wants to do something wierd, let them.
I want someone to change this on the CVS version, since it'd help out everyone who is making content.
I mostly ran into this while modding T2, and now that I can remove it on my own project, I see no reason not to.
What I'm talking about are the limits, such as possible gravity mod, etc, on projectiles.
There is absolutely no reason to limit gravity on a projectile. At all. Why are they there? It is really silly to bother limiting something that really doesn't need to be limited. What if a modder, or developer, wants to make a rising projectile, or one that falls unnaturally fast? (yet you can make one fall unnaturally slow) They need to remove this check if they want to do this!
Another one is a negative ejectionOffset. Particles arent really rendered the instant they are created, so if you want to make sure an effect like a muzzle flash is far back enough, this wouldn't be a bad idea. Removing this restriction would make creating an emitter where the particles gather together (instead of flying out) a trivial thing to make.
There are a few others that seem silly. I think elasticity is limited 0-1 also. While > 1 would make a thing that bounces higher and higher, what if someone wants this? If a modder wants to do something wierd, let them.
I want someone to change this on the CVS version, since it'd help out everyone who is making content.
#2
01/31/2003 (6:04 pm)
Most of these limits are for practical reasons. In certain situations it would make sense to remove these restrictions, but for the majority of the people that download Torque it makes sense to have them in place. So, go ahead and change it for yourself (although things like EjectionOffset being negative would be useful to others as well probably), but I wouldn't expect it all to get into the HEAD anytime soon.
#3
But it would be interesting to see what you come up with, giving physics the finger like that ;)
(though the ejection offset thing sounds interesting, too)
01/31/2003 (7:39 pm)
I agree; most validation of the sort is there as a sanity check. :)But it would be interesting to see what you come up with, giving physics the finger like that ;)
(though the ejection offset thing sounds interesting, too)
#4
01/31/2003 (8:03 pm)
You could just write up a resource detailing how this is done (not that its very hard ;) ). Then if anyone else wanted to do it they could just find the resource. I had to turn off the gravity thing for one of the weapons I was working on in my current game.
#5
02/01/2003 (10:52 am)
Yeah I know, I already have done it, but I think it would be a courtesy to remove it from the HEAD, since the checks really don't serve a purpose. If you want real physics, just don't go outside those limits yourself. It wastes a few processor cycles, even.
#6
02/01/2003 (12:20 pm)
OK and then the other 50% of developers who DO want the limits will then be forced to go in and change it back.
#7
Now you've broken no existing users, the script designer can choose which type of projectile they would rather use, and "if half the people want it," it can be put into head without breaking anyone's code.
Touching the root cc files is a "last resort" if you can't achieve the change in a non-invasive way; by having parallel files, you avoid merging conflicts and you maintain a model you can test against on bugs to be able to determine if you have caused the bug, or if the bug existed before you touched anything.
At any rate, incorporating the functionality to remove the limits would not require any script author to touch their code if it was done the right way (via a separate class, or exposed properties from the exsting class).
02/06/2003 (11:47 am)
Why couldn't you simply write a ProjectileUnlimited class (or whatever name you want to pick), derive it from the existing Projectile class, and remove the limits?Now you've broken no existing users, the script designer can choose which type of projectile they would rather use, and "if half the people want it," it can be put into head without breaking anyone's code.
Touching the root cc files is a "last resort" if you can't achieve the change in a non-invasive way; by having parallel files, you avoid merging conflicts and you maintain a model you can test against on bugs to be able to determine if you have caused the bug, or if the bug existed before you touched anything.
At any rate, incorporating the functionality to remove the limits would not require any script author to touch their code if it was done the right way (via a separate class, or exposed properties from the exsting class).
Torque Owner Nate "Nateholio" Watson
Default Studio Name