FC Forums

This was a topic that came up in the skype chat. I'm making a thread so it can be discussed more.

This is mostly technical, but I'll leave it here. How should vacuum and air be simulated?

- Blocks
- Liquids
- Sort of like a light level, I think?

I was thinking that they could be like the Classic water, with the addition of upwards mobility. Of course, it could also expand through open door blocks (by door blocks I mean like the iron and wooden doors but space quality).

I'd like to see something really FTLey.

We simulate oxygen within the ship by having an environment generator that basically creates a minecraft-classic wateresque block that is bled out when holes are made in the craft's metaworld (because we are using that, right?). This is a blanket solution that doesn't rely on premade schematics or constantly simulating what amounts to thousands of blocks of 'liquid' to see if an intersection can be made with a spaceship's guts.

I don't think it'd be all that hard to designated the 'space' world as something you'll deaded in without a certain type of outfit; it can be done with bukkit plugins.

Vinyl wrote:I was thinking that they could be like the Classic water, with the addition of upwards mobility. Of course, it could also expand through open door blocks (by door blocks I mean like the iron and wooden doors but space quality).

Yes, makes sense. But imagine this; You open airlock for 1 second, the entire ship shouldn't be drained of air. I think something more like the Finite Water mod would work, except, of course, 6 directions. We would have to experiment, though.

Tiel wrote:I'd like to see something really FTLey.

We simulate oxygen within the ship by having an environment generator that basically creates a minecraft-classic wateresque block that is bled out when holes are made in the craft's metaworld (because we are using that, right?). This is a blanket solution that doesn't rely on premade schematics or constantly simulating what amounts to thousands of blocks of 'liquid' to see if an intersection can be made with a spaceship's guts.

I don't think it'd be all that hard to designated the 'space' world as something you'll deaded in without a certain type of outfit; it can be done with bukkit plugins.

I guess I don't see what you mean by thousands of blocks of liquid; won't this be the case with air as well? Or are you referring to having vacuum as the fluid being the problem?

Oh, well in that case, yeah.

Well I pretty much explained the very way it is supposed to be coded. When the ship is created we calculate the exact oxygen volume on the ship and in which sectors. Once a block is removed from the ship, we check if on one side of it e have vacuum while on the other side we have air, if such is the case we move all entities in the area from the direction of the air block to the direction of the vacuum block and start to drain the pre-calculated oxygen level from the specific sector that is effected. Once the hole is fixed start to refill the air levels in the effected sector by a given amount per second.

The part I have trouble with is calculating efficiently if the area is enclosed now. I can easily pre-calculate the sectors when the ship is made but I dont want to do the same calculations each and every time a block is placed in the ship, to figure if some area is sealed, because you know you dont have to seal the very hole that was punched in the hull, you can just seal another area while keeping the rest of the area in vacuum.

Also simulating air as water is even less efficient than you think. Perhaps if you feel lazy you can pre-calculate the sectors using this method but calculating new sectors with it mid combat is a suicide for your CPU.

Iv, this thead is for discussion of differing ideas. I don't think you meant to, but you sounded remarkably "I said we are doing it this way already". We have no decided system yet.

I think it should be handled as a liquid of sorts, except it doesn't fall. and it 'wooshes' out when a hole is breached in the ship. Air should be simulated as a liquid, and vacuum as 'air' is now. and when air comes into contact with vacuum, it should gain a white 'misty' appearance.

Step 1:
VVVV||AAAA||
VVVV||AAAA||
VVVV||AAAA||

Step 2:
VVVV||AAAA||
VVVV AAAA ||
VVVV||AAAA||

Step 3:
VVVV||AAAA||
VVVV AAAAA ||
VVVV||AAAA||

Step 4:
VVVV||AAAA||
VVV AAAAAV ||
VVVV||AAAA||

Step 5
VVVA||AAVV||
VVAA AAAAV||
VVVA||AAVV||

Step 6
VVAA||AAVV||
VAAA AAAVV||
VVAA||AAVV||

Step 7
VAAA||AVVV||
AAAA AAVVV||
VAAA||AVVV||

Step 8
AAAA||vVVV||
AAAA VVVVV ||
AAAA||VVVV||

Step 9
AAAV||vVVV||
AAAV VVVVV ||
AAAV||VVVV||

Step 10
AAVV||VVVV||
AAVV VVVVV ||
AAVV||VVVV||

Step 11
AVVV||VVVV||
AVVV VVVVV ||
AVVV||VVVV||

Step 12
VVVV||VVVV||
VVVV VVVVV ||
VVVV||VVVV||

Air should be simulated as a liquid, but we really shouldn't base it off of water blocks unless they've been miraculously re-coded since the last time I played.

Commander Error wrote:Iv, this thead is for discussion of differing ideas. I don't think you meant to, but you sounded remarkably "I said we are doing it this way already". We have no decided system yet.

Error don’t even start this. I say we must not do it as liquid because the runtime function of such algorithm would be O(5^n), which is just to let you know a very, very VERY bad efficiency, I would prefer to talk about it as a 3D array which means that the runtime function of such algorithm would only be (n^3) , to see the diff try putting n = 5 and see how different the numbers are, and the difference will only grow as n increases, for a small room n = 20, that’s the difference between 8,000 commands executed and 95,367,431,640,625 .

Runtime function: A method of measuring algorithm efficiency. Achieved by calculating how many basic commands are executed per specific input (input being n) that is independent from the code itself. if you have 4 commands executed in a program no matter what the input is your runtime function is O(4), however runtime functions trim off all elements unrelated to the input n, which is why O(4) = O(1).

The runtime function of a program with a loop inside it that passes through the given input is O(n) because there are n inputs and thus the loop is working n times. If the loop contains two commands the runtime function of the loop will be O(2n) = O(n) , yes it is true that this is the difference between 1 million and 2 million commands if n = million however the runtime function is only an indicator to tell us how efficient the algorithm itself is. That means that algorithm-wise O(2n) is the same as O(n), however O(n) is a much better algorithm than O(n^2) .

Iv121 wrote:

Commander Error wrote:Iv, this thead is for discussion of differing ideas. I don't think you meant to, but you sounded remarkably "I said we are doing it this way already". We have no decided system yet.

Error don’t even start this.

Watch yourself, Iv. That looks a whole lot like a moderator asking you to be more polite and you telling him to go away. That's not a good plan.

I was asking you to consider other options. I was not telling you to stop talking, Iv. If you have a good reason for using your system, alrit. But do not dismiss other ideas out of hand, please.

First of all, it's true that we need a good way to simulate air that won't lag everybody out. Why would a liquid sim be O(5^n), though? Also, a 3d array is basically how blocks (and liquids) are simulated, so I don't really know what you mean by the O(n^3) method being different to the O(5^n).