I have played this game alot and modded to. But there are some parts of the physics i dont like (this is not gonna be idea that will lack all the way to much). For an example, im not sure but the force(not talking about recoil, but about the amount the guy there is shoot is flying back), the damage and the gibbing amount(how much the unit will lose a arm and such) is based upon "mass * velocity * sharpness". I think it is a very good code for damage scaling, but not for the force of the bullet and the gibbing amount. The force should be rather be defined by this code "mass * velocity / sharpness" and the gibbing amount should be based of this "mass * velocity". This can make things much more realistic course if you cut another with a knife the guy wont fly back but the force will be concentrated at a small point and then i will go through him(damage) without he is push backwards with a baseball bat.

Another idea (maybe laggy but im not sure) could be like when a pixel normaly will disapear it will have a chance(based upon the material) to instead of just disapear it will be "pushed" to the nearest( or maybe the free pixel with least amounts of "StructuralIntegrity" to the spot") free spot and if there is other pixels in the way it will push the pixel in front of it one pixel further and the rest of them two. This idea is a very random idea but it will make like a rocket crash look better course there will be a little layer of dirt in front of it like a crater.

Sorry for my bad english

Okay, the first idea doesn't sound all that bad might be a good one, but the second idea isn't really understandable.

yeah i know. The second idea is a bit hard to explain maybe i can make illustration later.

So you mean instead of deleting pixels when colliding terrain with MOs, the pixels would try to displace first to create craters, make the ground denser, etc?

Yes, and yes. As long as these do not severely change modding and balancing(no wait, everything need rebalance anyway), and NO LAG.

Then these are pretty good suggestions.

I fixed it up for you so that people can understand it easier. I don't get what you mean by "gibbing amount" though, I was thinking you meant gib impulse applied to an object which makes sense, but you say "how much the unit will lose a arm and such" by which I understood this as bleeding/wounds .

yeah, as people have said your first idea sounds good, but your second idea is a little bit off, you say it creates somewhat of a chain reaction where one pixel displaces the next, this would eventually actually destroy the whole map. However ignoring the chain reaction bit it's a good idea, I dislike how the pixels just disappear (there's some physics law which says this is impossible IIRC, which is broken by quantum physics but that's entirely different) and I too think that they should just resettle, and based on their friction they would form a crater or just slop back into a relatively level terrain, it isn't that hard to do and it would actually save a little bit of CPU (think about it normally you have a load of active MOPixels just sitting waiting for some timer to get to 0, compared to them turning back into terrain either upon hitting something or after sliding down for a few milliseconds).

The only problem would be that with all the troops, and stuff you order in they would eventually pile up and there's no way to remove them, that is why a new variable "IsTerrain" is needed and should be applied to all the original terrain pixels when you load a map, this way any debris could be destroyed by diggers and the crushing by other objects. this requires a simple while loop which I could write up and give to data myself, that is depending on how the engine layers stuff, this would create a tiny bit of lag when you start a match but then it would run at normal speed..

Another problem would be that diggers and stuff wouldn't work very well, maybe you could choose a dump point using the pie menu then any pixels the digger hits would be transported there. AI would set their dump point whenever they switch to the digger.

With gibbing amount i mean like when you shoot a guy with a heavy sniper rifle the head or leg is falling of. So i mean basically that it isent the sharpness that make the head goes of but more like the weight of the bullet. So big bullets are the bullets that make a guy fall apart and the sharp and light bullets kills the target less violently, but make the guy just falls and lies on the ground with head and arm unless you just keep firering at the body. The reason i want the possibility that some weapons dont blow up the target but still one or two hit kill the target and the watch the body roll down a hill or something instead of he just become a cloud of blood.


And the problem with digging could be solved by making a variable that determines if it the pixels it destroys still have a chance to be pushed instead. Just a variable 0 or 1.

Yes let's recode the whole terrain destruction system.

While actually a good idea (since it's probably the oldest feature of the engine) data's never going to do it. If he did, we'd be waiting for an extra year past the planned year into the future.

Why do you think it would take so long to put this in. It would take like and hour maybe less to test it and if it dont lag to much and it could make some stuff more interesting, the only time needed is to wait for next build.

Hahahaha okay go ahead and recode data's physics engine in an hour. I'll get the stopwatch.

I dont say i can do it with my current resources. The point is that you can make a small test room and check how it works. You just need the raw engine and put it into the test. Make the small changes and test it. I am not sure but i have worked on tests like this in under an hour but not on a engine so im not sure it would take a hour or a day, but making a test room and such dont take like a month.

It's just a game.
It's fine as it is.


These are not small changes you are talking about, the first one might take a week of recoding, and the other one might take months.

You are either underestimating CC's complexity, or overestimating Data's work force.

Just as a suggestion, never never estimate how hard recoding any sort of program is, especially if you've never looked at it. Ever.
It will make more people mad than impressed.

I think that actors movement across the terrain is a more pressing issue, but your first idea is brilliant.
Also, my translation/interpretation of 'gibbing amount' is how easily it gibs. Gibimpulselimit basically.