I was wondering how long it would be until we got the level editor and the online play options, would it be like build 58.645363 or something? or soon? i hope its soon!

also is there gonna be water? becasue that would be awesome, you could have nuclear Subs and U-boats and normal boats and divers and if a rocket or dropship went in it it could have electricity spark over it and it just dies!

http://dan-ball.jp/en/javagame/mc/

http://ishi.blog2.fc2.com/blog-entry-180.html

http://dan-ball.jp/en/javagame/dust/

Hay. There is a level editor. It's called Scenes.ini.

yeah but what if i screw it up, then i will have a mashed up map and i will have to reinstall CC and lose all my mods!

That's the beauty of .rte independence.

If you make your map in it's own .rte, then it won't affect the game at all.

Also, if you fuk it up, you can just edit it back, or, if it's in base.rte, ask someone to rar it and send or reinstall CC. Reinstalling CC doesn't affect mods in any way.

true, but what about water?

ok i tried it but it came up all red and yellow!

Water in a game that calculates physics for every pixel.

Notrly.

It would be doable if a separate system was made for water, I've played tons of games with pixel physics on water.

well the map i made is all yellow and red how i fix?

You probably did something wrong.

Go read the stickies in "Scene Making."

Links or it didn't happen.

CC could definitely go further on the extent of interaction between particles and water, but just to name a few:

Wings (1999)
Had flowing water made up of thousands of pixels at times, and this was back when Pentium IIs were around.


Gusanos 0.8.1 (2004)
While the water did not directly affect projectiles and their speeds, this could have been done with a bit more code. Still, there were huge levels full of flowing water.


These are probably poor examples. But if a different pixel class were implemented for the water only, to optimize flowing and physics calculation only when necessary, I can see it happening.

The complexity and difficulty of implementation could probably depend on whether physical objects fully displace the water, or are simply drawn in front of it. I could see it being realistic enough just being drawn in front, with drag and buoyancy applied, and this likely be by far the easiest implementation.

It might look odd of a dropship crashed using this simpler method, but perhaps water splashing could make it look realistic enough.

Burning Sand did it. Water, sand, gas, you name it. Even full displacement. Of course, it was dedicated to flowing physics, and didn't have any moving solids like dropships and the like.

Haha, I was waiting for someone to bring up the sandgames.

Let's see here.
1. Sieben will never release his code, so any hopes of seeing how he actually did it are pointless. He refuses to even release the source to a few people so they can compile it on other operating systems.
2. The water and any of the other particles do not properly pile, spread, or balance like true water.
The water in Burning Sand is hideous, it piles outward in chunks, it doesn't move like real water.
3. Burning hits major slowdown if you increase the resolution beyond 400x400 pixels, the default size.
CC has maps 2500 pixels long by 1200 tall. Even if you only have a small river, it'd be at least 1600 pixels, if not more, all reacting with each other, the terrain, actors, weapons, munitions, craft, and ammunition.
4. Imagine making new substances using a FSG style coding in Cortex Command. The codes are vastly different and roughly incompatible.
5. People spend weeks making falling sand games, and you want Data to put the entire system of a falling sand game into AN ENTIRELY DIFFERENT GAME? Like CC doesn't lag enough. The game would have to calculate all the already laggy physics, PLUS do the calculations of large amounts of fluids and liquids.

As I said before, notrly.