I swear, the overly-quick exploration argument is overused. Do these people realize it's nigh on impossible to actually explore an entire Minecraft world? It procedurally generates to a theoretical infinity. (Actual maximum is somewhere just over 8 times the entire surface area of the Earth.) To see all that would require forever, by any standard. Plus, the further you explore, the greater your world size gets, until it crashes the game, in loading. That encourages players to stay within certain, albeit larger, bounds.
Anyway, I disagree with just about anything related to redstone you bring up. I mean, it's dust, applied to the ground, which reacts to torches. It's not actually electrical, and I see absolutely no way it could fill or empty balloons. But, the main thing I disagree with isn't the sense it doesn't make, but the amount of extra code and processing it represents. Minecraft isn't a complex physics simulator. Things don't happen because the physics makes them. Physics happens because things make it. Computational simulation is backwards of the real world, at least, in generating real-time calculations. So, in a game, an object moves, then the game asks how it would react to the physics, whereas in real life, physics is set, and then an object can move.
In a simple system, an entity moves from no actual power source, but by a set of specifications that controls the constraints by which it can move. This is far easier to process in real time.
In a complex system, an entity may move from working power sources, pushing it, each activated, separately of one another, and the specifications to move it are generated as the game goes. This is more realistic, but it requires far more processing, and limits the simulation to being out-of-real time.
If the redstone only activated animations, and the game simulated the entity via a simple system, it would retain the complexity of construction, and the effect it gives, while also keeping the short processing. I think this ideal compromise between our ideas.
I'm working on a large locomotive suggestion. I'm going to develop it first, then type it in a text document, then post it.
Hey, you didn't need to do all that work dude. Mistify has already talked about how to do it in the customizable boats thread. Airships would be built the exact same way as a boat, but it would have balloons of some sort on it.
Most of that work was coming up with the physics model. The rest of it was done in 5 minutes. I haven't read that entire thread, but I don't think they came up with an applicable physics model.
Like I said, my ideas need refinement, RebCom, but the point is, map a set of buttons to control altitude.
And, for Landing Pads, I see there being options. You could just clear an area and make generic boarding ramps and a mooring post, and that would constitute a functional landing pad. Alternatively, you could build a pad, with some sort of special block set off at certain intervals, that could, as a function, hold the ship in place, and allow for boarding and disembarking, as well as refueling or repairs. This way, you can trade the resource costs for the added function, or function for fewer resources, encouraging player choice.
The simple physics model my system uses doesn't allow for the engines to be pointed down or up, but I was thinking about refinement that allows them to be pointed forward or sideways. I don't have an idea that's simple, yet robust, yet, for converting thrust to lift. Maybe later, yeh?
As far as my idea goes, propellers are part of engines, so, they go together, pretty inseparably.
In that system, altitude is controlled by some pre-defined key (space? Q & Z?) that will allow the player to ascend to his ship's maximum altitude, or descend to 1 block above ground level.
I haven't thought about sail ships, and in the end, that depends on a wind system I don't care to contemplate being implemented.
Finally, a ship will eventually decelerate when it runs out of fuel, and/or control input. When it comes to a stop, it's essentially free pickings for anyone in the area. Depending on aforementioned wind system, it could drift. Same applies to landing. You land by stopping the ship at the minimum altitude, and secure it with something, or hope it doesn't drift away. By its nature, it also means you need some apparatus to board it again, which encourages, but doesn't force players to make landing pads.
Something I failed to mention in my last post: Once the necessary parts are put in; engines, lifters, hull, controls, you can do really whatever with the ship. Pools of water, trees, rocks, whatever. That said, it still adds to the weight stat, so you'll have to compensate by adding thrust and lift. Beauty of the physics model I have in mind: anything built on top of an entity moves with the entity, and anything standing on it, but not bound, moves too.
Well, I got one image done and GIMP died on me. So, bear with me in text, I guess. From creation, to physics, to constraints, here I go.
--Creation--
I imagine, to create an airship, the player will first need to create a physical layout, of stone or cobblestone, 8x16 blocks in size, with a workbench at each corner. The game will process the pattern as an entity forming zone, and allow the player to access a new crafting interface, upon using any of the work benches. In my idea, when the player activates Crafting Mode, the player appears in a 16x16x16 grid, over the Crafting Table, essentially in the real world. From there, the player can place blocks, as normal, with a few constraints as to what can actually be used to make certain types of entity work. (An Airship must be made of wood or iron, I'd imagine) Within the grid, the player can jump up a level by jumping, or go down a level by crouching. Blocks placed in the air only remain if there is a block diagonal to them, and one block in a diagonal chain must be connected directly to the top, bottom, or side of the structure, anchored to the bottom of the grid.
Crafting Table 1:4 scale
Diagonal Constraint:
[] [] [] []
[] [] [] []
[] [] [] []
--Materials--
Certain materials would be necessary to create Airships. The list of existing materials that would go into crafting them, as I see it, is as follows:
Note: I guess glass isn't NECESSARY, but it adds a defense element, I guess.
Iron and Wood can be used to create the hull of the ship, placed, as one would, an aesthetic ship. That's a fairly simple bit. That said, to use Iron would require Iron Blocks, using 9 ingots of Iron, per block of ship. Very damage-resistant, very heavy, very resource-expensive.
Obsidian as a lifting element: I imagine it would have to be crafted with some other element, perhaps, Lightstone or Redstone dust, in a set ratio, creating a lifting block. That block would then have to be placed on the ship, directly under the bottom layer of the hull, or something fixed to that layer, directly, as opposed to diagonally.
Gasbags/Hot Air Balloons: These would require the option to craft cloth into Canvas, and Canvas into Gas Bags or Balloons. A gasbag would require several units of canvas, and a unit of an as-yet, non-existent gas (Which I imagine to be flammable). Multiple gasbags could be crafted together to create larger gasbags, for more lift. They would then be attached to the ship via rope, made of string. (Rigid physics would work for rope in this case) Hot Air Balloons would need to be placed over a heat source (Furnace?) to have effect, and when the heat source ran out, the ship would begin a slow descent.
Furnace as an Engine Component: I imagine the Furnace would be a component for engines in a few capacities. The single engine would use a Furnace, an ingot of Iron, and a pre-fabricated propeller. It would have very limited speed and acceleration, but would suffice in large numbers, or on smaller ships. Larger engines might consist of a large propeller and a boiler, made of several furnaces, iron, and water. Each engine would require the player to manually add fuel to it, and it would run for a set amount of time, per unit of fuel, as a given.* That said, a hopper and chute system could be implemented, allowing the player to fuel one hopper, and have that hopper equally distribute fuel to the engines, eliminating that as a worry for the player.
*I'll cover why in Physics
Those are the only design-necessary components and materials.
--Physics--
The physics of the Airship Entity would require several calculations, at the time of creation, as well as on the fly (pun intended) to operate it in the dynamic world of Minecraft.
Weight
First off, a mass unit would need to be applied. Each block would have a certain mass, and adding all their masses ends up with the total mass. (For this sake, the player can remain weightless)
List of Theoretical Mass
Wood: 2 Units
Iron: 5 Units
Stone: 6 Units
Water: 3 Units
Gold: 7 Units
Et cetera. Note how wood has a smaller weight-per-block (density!) than Water. That means it can float in water, but Iron, at 5 units, can not.
Acceleration Factor
This is a made-up unit, that doesn't exist yet, and corresponds to M/S^2 as a unit. Each type of engine has a different acceleration coefficient, and they add to each other, and divide by the mass of the ship for Acceleration Factor. The maximum acceleration factor for a vessel is 1. For example, the following: [] [] [] [] [] [] []
[] [] [] [] [] []
[] []
Assuming that is the entire ship, and Furnace represents Single Engine, the Total Mass is 20. (8*2 + 4(assumed mass of Single Engine)) The Acceleration Coefficient of a Single Engine is 11, thus the Acceleration Factor is 0.55(M/S^2). (11 / 20 = 0.55) That means the ship can accelerate .55 blocks per second, every second, until it achieves maximum velocity.
0 Seconds: 0 M/S
1 Second: .55 M/S
2 Seconds: 1.1 M/S
3 Seconds: 1.65 M/S
Et Cetera.
Adding an engine would add 4 mass, and 11 AC, making the AF 0.91, if you know physics or are good at math.
Velocity
I see Maximum Velocity as having a set maximum, that can't be passed, and smaller figures, based on Acceleration Factor. In my eyes, the top speed any airship can travel is 11 M/S (1.4 Minecart Speed), and that would be the speed of any ship with an AF of 1. Other ships would abide by the formula 9.81 * AF, where 9.81 is a made up figure (or not, if you know where I got it).
As an example, the ship from above could reach a maximum speed of 5.4 blocks per second. (.55 * 9.81 = 5.3955)
Why, then, is the top speed out of reach, conventionally? Because I like the number 11, and I feel if you're willing to make a ship with a Thrust to Weight ratio equal to 1, you deserve the extra speed. (Plus, the logic for that is, "If AF == 1, MaxSpeed = 11")
Turning Rate
I could bore you with physics, and I will, if you ask, but basically, the more engines you have, off-center, and the farther off-center they are, the greater your turning rate.
Lift
Going back to Mass, each lift type will have a certain amount of mass they can lift. So, a block of Lift Cube (Obsidian-based) would have a capacity of, say, 11 Units. That means, for every 5 wood, you would need 1 Lift Cube just to get your ship to hover one unit off the ground. To lift higher, you need a proportional amount of lift.
(Lift - Mass)/2 = Max Altitude (rounded to no decimal places)
((11 - 5(2)) / 2 = .5 rounds to 1)
So, the more lift devices you have, the more weight you can lift, and the higher you can lift it. Say we had 2 Lift Cubes on that 5-wood structure.
(2(11) - 5(2)) / 2 = 6
Thus, you could ride 6 blocks high. If the terrain dipped, you would remain at the same altitude, however.
The examples I used weren't very well-thought-out, but I'm sure, given more time, I could come up with better figures.
Fuel
Burning fuel for a constant amount of time dictates how long an engine can run, and the time the engine can run dictates how fast the ship can move. And how fast the ship can move dictates how far it can move. Thus eliminating the need for a set of calculations for fuel consumption and allowing now-integral parts of the physics engine to determine distance a ship can move on a set amount of fuel.
That wraps up physics, for now, as my mind is fairly tapped.
--Application--
So, say I want to build the following ship:
Top:
[] [] []
[] []
[]
[]
[] []
[] [] []
It consists of 96 units of wood, 45 Lift Blocks, and 2 Large Engines.
Its mass is therefore 240 (96(2) + 2(6(4)) = 192 + 2(24) = 240)
The 45 Lift Blocks can produce 495 units of lift.
Thus, the craft can fly at a revised upper limit (2 Byte chunk size)*, because its Lift is 127.5 units, and that rounds to 128. ((45(11) - 240) / 2 = 127.5 ~ 128)
Its engines produce a coefficient of 132, thus an acceleration factor of 0.55 B/S^2. (2(66) / 240 = .55)
It can go at a top speed of 5.4 blocks per second. (9.81 * .55 = 5.3955)
If none of that made sense, tell me, and I'll explain the basic physics behind it.
--Additional Notes--
Currently, the primitive data type assigned to Chunk size is a Byte. It has a maximum value of 127, leading to the 63-deep ground and 64-high sky. For something like this to be incredibly successful, I would see the Chunk Size changed to 2-byte storage, one for below sea level, one for above sea level. (Assuming switching to Short or Int would cause too much processor strain, anyway. If they didn't, psh, I'd go right for that Int, with its 2140000000+ value limit)
ALL of this needs refinement, and as it stands, it's just concepts. I'll go into actual application into the game as I know it, next time, but right now, I am tapped.
Right, I looked back over it, and I mis-read the idea. Thinking on it, though, it still leaves the issue of no steering, if you don't have at least 2 thrusters, and even then, to move forward, you'd have to hold A and D simultaneously. Each engine fires on the command of the key mapped to it, moving the ship according to the thrust it creates. That uses a different set of processes than the system I had in mind, and is limiting to the player, and, in any case, requires the creation of an entirely new system to move entities, and control them.
At the very least, my system salvaged the boat's control system, and the processes that make it move.
That said, I guess your idea isn't invalid, it's just overcomplicated. Hmm. Let me finish my set of images, and I'll contemplate this more.
Airships are real, have been used in warfare and for commercial use, and were relatively effective before they were outclassed by airplanes.
Gundam, on the other hand, is about giant 100 foot tall or taller humanoid robots fighting each other with a human pilot sitting in the head. If you ask me, it would be much more realistic and effective to have smaller, more exo-skeleton-ish battle mechs that are about 10 feet tall, and are either remote controlled or have the pilot in the chest area.
anyway, When I was talking about a simple auto pilot, I was talking about making it capable of staying in one spot or maintaining the same altitude with minimal user input.
Also, if these "redstone box" ideas some people are wanting -including me- are added, we could create much more compact computers. This would allow for making an airship capable of landing itself, or automatic takeoff, or even be able to program it to fly between 2 areas over and over again, following the exact same path every time.
slightly off topic, but the reason that someone would want to create these "UAV" airships would be to transport cargo between 2 spots that are too far apart or too rough for minecarts to go over. It wouldn't be able to adapt to something attacking it, or a sudden gust of wind, but it would be a simple, unmanned air freight system.
They also consisted 90% of Hydrogen, and were essentially gas-filled sacs. That is not what we are talking about here.
And mobile suits are all around 60 feet, and the pilot sits in the chest! GRABARAGUODAYIFAHYPUFAIUOY FA
Okay, sorry for my rage, there.
Anyway, I think a simple autopilot is a good idea, but I don't think the processor-heavy redstone system would be a good idea. Already, you're using a processor, then you use a simulated processor, which uses more calculations on the real one, to generate the simulated processes, and you've bogged down your real CPU with your virtual CPU. And, again, using that kind of system bogs down the game with constant collisions between the engines and the frame.
I definitely do not like all the ideas that include making airships so incredibly hard to make. I do understand the need for balance, but with flying mobs (Notch has mentioned including them, and we already have ghasts for the model of how they'd work), much of that need is removed. Beyond that, it's a fairly simple matter of collecting a lot of normal resources, and a small amount of rare resources, if you ask me, and you can craft an airship. Further, what type of airship you build determines how it behaves. If you use iron, it will be heavier, and slower, but incredibly resistant against attack, while being very hard to make, due to the relative scarcity of iron. However, if you use wood, it will be lighter and easier to build, but weak against attacks. (Especially if the ghast, or some other fire-breather is ever introduced) A single fireball would destroy the whole ship. I also like the idea of different types of levitation device. A hot air balloon, a gas bag, a magical levitation device. Each has different requirements and performance. Gas bags and hot air balloons would be flammable and pop when hit by arrows, and the former would explode, if lit on fire, potentially destroying other parts of a ship, but the magic device would be ever-so-incredibly hard to get, while remaining nigh on indestructible (the only such part of the ship).
I'm going to arrange a set of images portraying my ideas.
Hey! I a not a dirty non-nerd! just because I don't like gundam doesn't mean I not a nerd 8|
I just don't like gundam because I find it very unrealistic.
anyway, I prefer the idea of needing a redstone current to tell engines what to do. This would further balance it, because you would need to have redstone, and you would need to design the craft to be able to get the redstone from the control box to the engine. It would also allow multiple pilots to control separate parts of the same entity.
Another advantage to using redstone to send commands to parts is that someone could put a simple computer on their craft, allowing for ships to have a very simple autopilot, or you could create different "modes" for your craft by having a switch to change between "boat mode" and "airship mode", if moving parts are allowed. You could also allow a boat to switch between "cargo mode" and "speed mode" or something similar.
Unrealistic? You're advocating airships, and you don't like Gundams for their lack of realism? That makes so much sense. ¬¬
But, anyway, while I understand the need for balancing Airships, I don't think this is the way to do it. The extra processing and code would make it bad for actual implementation. Further, that computer note makes NO sense. The current computers take up whole CHUNKS and can only do simple math, such as 1+2. I don't see any way to keep a ship flying on a redstone computer. Better to have an autopilot option. (That could be much more easily coded) Also, I don't see entities with moving parts being a possibility. There's no current way to implement them, as there is with a moving entity. I'm sorry, but, I don't think cranes or normal cannons are going to happen.
I could come up with flowcharts for the algorithms that would have to be used to make the two systems work, and it would show why one system is preferable, but I don't have the work ethic right now.
I did have an idea for the system by which airships (or seaships) could be crafted, and, if you're interested, I could break into a tangent about it.
I'd really appreciate it if you'd go back and read the whole thread, then post a practical reason why you think what you do, Calum. I'm sure you've got a good reason, as it stands, but maybe the whole discussion that's gone on could sway that.
Your view on Gundam makes me suddenly like you less. You dirty non-nerd.
It would add more processing, not in the controls, themselves, but in making the propulsion units actually provide propulsion. A good example I can think of is the Ace Combat series of games. There are several different aircraft, and some have more thrusters than others. But, the thrusters do nothing but sit there and look pretty. They only represent a statistic of the aircraft, regarding speed and acceleration. The plane isn't faster because it has more thrusters, but because the game recognizes it has more thrust.
In any case, that solution presents the issue of moving in any direction but forward, in craft with only one engine.
And, that kind of system is in no way required in an entity with physics. Again, in Ace Combat, a game with a very well-built physics model, aircraft don't maneuver because their ailerons move. Rather, they maneuver and their ailerons move. In games, moving parts and systems are correlated to motion of the entity they are part of, but they don't cause that motion. The game processes the plane as being able to move forward at different speeds, and as it moves forward, it animates the engines to make it look like they cause it to move forward.
Applying this kind of system to Minecraft airships, when you perform the finish function on the entity, it checks for a few things. It looks for number and placement of engines, number and placement of lift devices, and the presence of a control system. If there is a control block, the entity can be controlled by the player. If not, it can only be pushed around. As far as moving it, when the game checks for the number and placement of engines, it generates statistics for top speed, acceleration, turning rate, and maybe a thrust stat, all taking into account the size of the entity. Based on those stats, when you control the ship, it "magically" moves. If an engine runs out of fuel, or is destroyed, the statistics change, to reflect the loss of power. The thrust stat would apply, if entities were limited to a set size, and you wanted to use one entity to push another. Thrust would dictate the amount of weight you can push, and the speed you can push different weights, acting as a multiplier against your speed and accel. stats.
In this way, processing can be streamlined, in not having to simultaneously process the collisions between multiple engines and the main body of the craft, which is the way the real world works. Instead, it would just move the ship, like a large version of the boat, which has established statistics and control system.
While I guess that's a good idea for adding a challenge to gaining the reward, to implement it would require a lot more processing, and a lot more code to create it. I really don't like it, thinking of the system.
On an off-topic note, Sting, your name looks familiar. Are you a fan of Gundam?
I dunno, I prefer a system that calculates the position and direction of the propulsion systems to come up with speed, acceleration, and rotation stats, and just lets you have a control box that is linked to the ship, and allows it to move, using the boat controls (hoverboat mod controls?), with the propulsion blocks serving, functionally, as aesthetic pieces, unless broken off, at which point the game would recalculate the ship's stats to reflect the loss of what would be actual power in that segment.
That would simplify processing to have one object being controlled in real time, using stats generated for it, versus x number of propulsion systems in y directions, with z redstone pulses moving it.
That said, I do think some sort of overall fuel hopper, with a feed mechanism you'd have to create to use it, would be a good idea. It makes the ship more resource-intensive, thus harder to make, and would require a system like the redstone paths to connect engines to the main fuel source. In this way, you could either individually and manually distribute fuel to each engine, or use the more resource-intensive system to only have to feed one hopper and let the system fuel the rest of the engines. From a processing perspective, it would be a simple x / y calculation (x fuel divided by y engines) to come up with how much fuel each engine gets, and then, the existing figure for how long a unit of fuel lasts in an engine is multiplied by the number of fuel units, as normal.
Personally, if I'm changing vertical levels, I'll refer to the levels as Zn, because it's the nth level on the Z-axis. If I was showing something with verticality represented, but not one of its horizontal planes, and I'm not showing multiple views, I'll just use Xn as my level nomenclature.
But I see where you'd be going with a 2D game and Z-levels.
The current engine does not simulate friction and it has a very poor collision simulation. The engine would have to be rewritten to calculate theoretical friction, and revise the collision system to take into account the way a block entity would work. Further, an energy transfer system, to determine whether an entity colliding with another entity would damage the first, or the second, based on the speed, size, and materials used. It's a significant amount of code that's not there, and that would require the current engine's features, in a lot of ways, to either be revised, or rewritten, to make it work.
If a segment in the entity is hit with enough force to cause damage equal to or greater than the segment's damage resistance, the segment would be removed from the entity, leaving a hole. If that hole was exposed to water, water would fill the entity, causing defective performance. Players could fall through the hole, and objects could get in. The hole could potentially be patched, depending on implementation of the system.
0
Anyway, I disagree with just about anything related to redstone you bring up. I mean, it's dust, applied to the ground, which reacts to torches. It's not actually electrical, and I see absolutely no way it could fill or empty balloons. But, the main thing I disagree with isn't the sense it doesn't make, but the amount of extra code and processing it represents. Minecraft isn't a complex physics simulator. Things don't happen because the physics makes them. Physics happens because things make it. Computational simulation is backwards of the real world, at least, in generating real-time calculations. So, in a game, an object moves, then the game asks how it would react to the physics, whereas in real life, physics is set, and then an object can move.
In a simple system, an entity moves from no actual power source, but by a set of specifications that controls the constraints by which it can move. This is far easier to process in real time.
In a complex system, an entity may move from working power sources, pushing it, each activated, separately of one another, and the specifications to move it are generated as the game goes. This is more realistic, but it requires far more processing, and limits the simulation to being out-of-real time.
If the redstone only activated animations, and the game simulated the entity via a simple system, it would retain the complexity of construction, and the effect it gives, while also keeping the short processing. I think this ideal compromise between our ideas.
0
Most of that work was coming up with the physics model. The rest of it was done in 5 minutes. I haven't read that entire thread, but I don't think they came up with an applicable physics model.
Like I said, my ideas need refinement, RebCom, but the point is, map a set of buttons to control altitude.
And, for Landing Pads, I see there being options. You could just clear an area and make generic boarding ramps and a mooring post, and that would constitute a functional landing pad. Alternatively, you could build a pad, with some sort of special block set off at certain intervals, that could, as a function, hold the ship in place, and allow for boarding and disembarking, as well as refueling or repairs. This way, you can trade the resource costs for the added function, or function for fewer resources, encouraging player choice.
0
As far as my idea goes, propellers are part of engines, so, they go together, pretty inseparably.
In that system, altitude is controlled by some pre-defined key (space? Q & Z?) that will allow the player to ascend to his ship's maximum altitude, or descend to 1 block above ground level.
I haven't thought about sail ships, and in the end, that depends on a wind system I don't care to contemplate being implemented.
Finally, a ship will eventually decelerate when it runs out of fuel, and/or control input. When it comes to a stop, it's essentially free pickings for anyone in the area. Depending on aforementioned wind system, it could drift. Same applies to landing. You land by stopping the ship at the minimum altitude, and secure it with something, or hope it doesn't drift away. By its nature, it also means you need some apparatus to board it again, which encourages, but doesn't force players to make landing pads.
Something I failed to mention in my last post: Once the necessary parts are put in; engines, lifters, hull, controls, you can do really whatever with the ship. Pools of water, trees, rocks, whatever. That said, it still adds to the weight stat, so you'll have to compensate by adding thrust and lift. Beauty of the physics model I have in mind: anything built on top of an entity moves with the entity, and anything standing on it, but not bound, moves too.
0
--Creation--
I imagine, to create an airship, the player will first need to create a physical layout, of stone or cobblestone, 8x16 blocks in size, with a workbench at each corner. The game will process the pattern as an entity forming zone, and allow the player to access a new crafting interface, upon using any of the work benches. In my idea, when the player activates Crafting Mode, the player appears in a 16x16x16 grid, over the Crafting Table, essentially in the real world. From there, the player can place blocks, as normal, with a few constraints as to what can actually be used to make certain types of entity work. (An Airship must be made of wood or iron, I'd imagine) Within the grid, the player can jump up a level by jumping, or go down a level by crouching. Blocks placed in the air only remain if there is a block diagonal to them, and one block in a diagonal chain must be connected directly to the top, bottom, or side of the structure, anchored to the bottom of the grid.
Crafting Table 1:4 scale
Diagonal Constraint:
[] []
[]
[] []
--Materials--
Certain materials would be necessary to create Airships. The list of existing materials that would go into crafting them, as I see it, is as follows:
Note: I guess glass isn't NECESSARY, but it adds a defense element, I guess.
Iron and Wood can be used to create the hull of the ship, placed, as one would, an aesthetic ship. That's a fairly simple bit. That said, to use Iron would require Iron Blocks, using 9 ingots of Iron, per block of ship. Very damage-resistant, very heavy, very resource-expensive.
Obsidian as a lifting element: I imagine it would have to be crafted with some other element, perhaps, Lightstone or Redstone dust, in a set ratio, creating a lifting block. That block would then have to be placed on the ship, directly under the bottom layer of the hull, or something fixed to that layer, directly, as opposed to diagonally.
[]
[] []
[] []
or
[] []
[]
[] []
but not
[] []
Gasbags/Hot Air Balloons: These would require the option to craft cloth into Canvas, and Canvas into Gas Bags or Balloons. A gasbag would require several units of canvas, and a unit of an as-yet, non-existent gas (Which I imagine to be flammable). Multiple gasbags could be crafted together to create larger gasbags, for more lift. They would then be attached to the ship via rope, made of string. (Rigid physics would work for rope in this case) Hot Air Balloons would need to be placed over a heat source (Furnace?) to have effect, and when the heat source ran out, the ship would begin a slow descent.
Furnace as an Engine Component: I imagine the Furnace would be a component for engines in a few capacities. The single engine would use a Furnace, an ingot of Iron, and a pre-fabricated propeller. It would have very limited speed and acceleration, but would suffice in large numbers, or on smaller ships. Larger engines might consist of a large propeller and a boiler, made of several furnaces, iron, and water. Each engine would require the player to manually add fuel to it, and it would run for a set amount of time, per unit of fuel, as a given.* That said, a hopper and chute system could be implemented, allowing the player to fuel one hopper, and have that hopper equally distribute fuel to the engines, eliminating that as a worry for the player.
*I'll cover why in Physics
Those are the only design-necessary components and materials.
--Physics--
The physics of the Airship Entity would require several calculations, at the time of creation, as well as on the fly (pun intended) to operate it in the dynamic world of Minecraft.
Weight
First off, a mass unit would need to be applied. Each block would have a certain mass, and adding all their masses ends up with the total mass. (For this sake, the player can remain weightless)
List of Theoretical Mass
Wood: 2 Units
Iron: 5 Units
Stone: 6 Units
Water: 3 Units
Gold: 7 Units
Et cetera. Note how wood has a smaller weight-per-block (density!) than Water. That means it can float in water, but Iron, at 5 units, can not.
Acceleration Factor
This is a made-up unit, that doesn't exist yet, and corresponds to M/S^2 as a unit. Each type of engine has a different acceleration coefficient, and they add to each other, and divide by the mass of the ship for Acceleration Factor. The maximum acceleration factor for a vessel is 1. For example, the following:
[]
[] []
Assuming that is the entire ship, and Furnace represents Single Engine, the Total Mass is 20. (8*2 + 4(assumed mass of Single Engine)) The Acceleration Coefficient of a Single Engine is 11, thus the Acceleration Factor is 0.55(M/S^2). (11 / 20 = 0.55) That means the ship can accelerate .55 blocks per second, every second, until it achieves maximum velocity.
0 Seconds: 0 M/S
1 Second: .55 M/S
2 Seconds: 1.1 M/S
3 Seconds: 1.65 M/S
Et Cetera.
Adding an engine would add 4 mass, and 11 AC, making the AF 0.91, if you know physics or are good at math.
Velocity
I see Maximum Velocity as having a set maximum, that can't be passed, and smaller figures, based on Acceleration Factor. In my eyes, the top speed any airship can travel is 11 M/S (1.4 Minecart Speed), and that would be the speed of any ship with an AF of 1. Other ships would abide by the formula 9.81 * AF, where 9.81 is a made up figure (or not, if you know where I got it).
As an example, the ship from above could reach a maximum speed of 5.4 blocks per second. (.55 * 9.81 = 5.3955)
Why, then, is the top speed out of reach, conventionally? Because I like the number 11, and I feel if you're willing to make a ship with a Thrust to Weight ratio equal to 1, you deserve the extra speed. (Plus, the logic for that is, "If AF == 1, MaxSpeed = 11")
Turning Rate
I could bore you with physics, and I will, if you ask, but basically, the more engines you have, off-center, and the farther off-center they are, the greater your turning rate.
Lift
Going back to Mass, each lift type will have a certain amount of mass they can lift. So, a block of Lift Cube (Obsidian-based) would have a capacity of, say, 11 Units. That means, for every 5 wood, you would need 1 Lift Cube just to get your ship to hover one unit off the ground. To lift higher, you need a proportional amount of lift.
(Lift - Mass)/2 = Max Altitude (rounded to no decimal places)
((11 - 5(2)) / 2 = .5 rounds to 1)
So, the more lift devices you have, the more weight you can lift, and the higher you can lift it. Say we had 2 Lift Cubes on that 5-wood structure.
(2(11) - 5(2)) / 2 = 6
Thus, you could ride 6 blocks high. If the terrain dipped, you would remain at the same altitude, however.
The examples I used weren't very well-thought-out, but I'm sure, given more time, I could come up with better figures.
Fuel
Burning fuel for a constant amount of time dictates how long an engine can run, and the time the engine can run dictates how fast the ship can move. And how fast the ship can move dictates how far it can move. Thus eliminating the need for a set of calculations for fuel consumption and allowing now-integral parts of the physics engine to determine distance a ship can move on a set amount of fuel.
That wraps up physics, for now, as my mind is fairly tapped.
--Application--
So, say I want to build the following ship:
Top:
[] [] []
[] []
[]
[]
[] []
[] [] []
Side:
[] [] [] [] [] [] [] [] [] [] [] [] [] []
[]
Rear:
[]
[]
It consists of 96 units of wood, 45 Lift Blocks, and 2 Large Engines.
Its mass is therefore 240 (96(2) + 2(6(4)) = 192 + 2(24) = 240)
The 45 Lift Blocks can produce 495 units of lift.
Thus, the craft can fly at a revised upper limit (2 Byte chunk size)*, because its Lift is 127.5 units, and that rounds to 128. ((45(11) - 240) / 2 = 127.5 ~ 128)
Its engines produce a coefficient of 132, thus an acceleration factor of 0.55 B/S^2. (2(66) / 240 = .55)
It can go at a top speed of 5.4 blocks per second. (9.81 * .55 = 5.3955)
If none of that made sense, tell me, and I'll explain the basic physics behind it.
--Additional Notes--
Currently, the primitive data type assigned to Chunk size is a Byte. It has a maximum value of 127, leading to the 63-deep ground and 64-high sky. For something like this to be incredibly successful, I would see the Chunk Size changed to 2-byte storage, one for below sea level, one for above sea level. (Assuming switching to Short or Int would cause too much processor strain, anyway. If they didn't, psh, I'd go right for that Int, with its 2140000000+ value limit)
ALL of this needs refinement, and as it stands, it's just concepts. I'll go into actual application into the game as I know it, next time, but right now, I am tapped.
0
At the very least, my system salvaged the boat's control system, and the processes that make it move.
That said, I guess your idea isn't invalid, it's just overcomplicated. Hmm. Let me finish my set of images, and I'll contemplate this more.
0
They also consisted 90% of Hydrogen, and were essentially gas-filled sacs. That is not what we are talking about here.
And mobile suits are all around 60 feet, and the pilot sits in the chest! GRABARAGUODAYIFAHYPUFAIUOY FA
Okay, sorry for my rage, there.
Anyway, I think a simple autopilot is a good idea, but I don't think the processor-heavy redstone system would be a good idea. Already, you're using a processor, then you use a simulated processor, which uses more calculations on the real one, to generate the simulated processes, and you've bogged down your real CPU with your virtual CPU. And, again, using that kind of system bogs down the game with constant collisions between the engines and the frame.
I definitely do not like all the ideas that include making airships so incredibly hard to make. I do understand the need for balance, but with flying mobs (Notch has mentioned including them, and we already have ghasts for the model of how they'd work), much of that need is removed. Beyond that, it's a fairly simple matter of collecting a lot of normal resources, and a small amount of rare resources, if you ask me, and you can craft an airship. Further, what type of airship you build determines how it behaves. If you use iron, it will be heavier, and slower, but incredibly resistant against attack, while being very hard to make, due to the relative scarcity of iron. However, if you use wood, it will be lighter and easier to build, but weak against attacks. (Especially if the ghast, or some other fire-breather is ever introduced) A single fireball would destroy the whole ship. I also like the idea of different types of levitation device. A hot air balloon, a gas bag, a magical levitation device. Each has different requirements and performance. Gas bags and hot air balloons would be flammable and pop when hit by arrows, and the former would explode, if lit on fire, potentially destroying other parts of a ship, but the magic device would be ever-so-incredibly hard to get, while remaining nigh on indestructible (the only such part of the ship).
I'm going to arrange a set of images portraying my ideas.
0
Unrealistic? You're advocating airships, and you don't like Gundams for their lack of realism? That makes so much sense. ¬¬
But, anyway, while I understand the need for balancing Airships, I don't think this is the way to do it. The extra processing and code would make it bad for actual implementation. Further, that computer note makes NO sense. The current computers take up whole CHUNKS and can only do simple math, such as 1+2. I don't see any way to keep a ship flying on a redstone computer. Better to have an autopilot option. (That could be much more easily coded) Also, I don't see entities with moving parts being a possibility. There's no current way to implement them, as there is with a moving entity. I'm sorry, but, I don't think cranes or normal cannons are going to happen.
I could come up with flowcharts for the algorithms that would have to be used to make the two systems work, and it would show why one system is preferable, but I don't have the work ethic right now.
I did have an idea for the system by which airships (or seaships) could be crafted, and, if you're interested, I could break into a tangent about it.
0
0
It would add more processing, not in the controls, themselves, but in making the propulsion units actually provide propulsion. A good example I can think of is the Ace Combat series of games. There are several different aircraft, and some have more thrusters than others. But, the thrusters do nothing but sit there and look pretty. They only represent a statistic of the aircraft, regarding speed and acceleration. The plane isn't faster because it has more thrusters, but because the game recognizes it has more thrust.
In any case, that solution presents the issue of moving in any direction but forward, in craft with only one engine.
And, that kind of system is in no way required in an entity with physics. Again, in Ace Combat, a game with a very well-built physics model, aircraft don't maneuver because their ailerons move. Rather, they maneuver and their ailerons move. In games, moving parts and systems are correlated to motion of the entity they are part of, but they don't cause that motion. The game processes the plane as being able to move forward at different speeds, and as it moves forward, it animates the engines to make it look like they cause it to move forward.
Applying this kind of system to Minecraft airships, when you perform the finish function on the entity, it checks for a few things. It looks for number and placement of engines, number and placement of lift devices, and the presence of a control system. If there is a control block, the entity can be controlled by the player. If not, it can only be pushed around. As far as moving it, when the game checks for the number and placement of engines, it generates statistics for top speed, acceleration, turning rate, and maybe a thrust stat, all taking into account the size of the entity. Based on those stats, when you control the ship, it "magically" moves. If an engine runs out of fuel, or is destroyed, the statistics change, to reflect the loss of power. The thrust stat would apply, if entities were limited to a set size, and you wanted to use one entity to push another. Thrust would dictate the amount of weight you can push, and the speed you can push different weights, acting as a multiplier against your speed and accel. stats.
In this way, processing can be streamlined, in not having to simultaneously process the collisions between multiple engines and the main body of the craft, which is the way the real world works. Instead, it would just move the ship, like a large version of the boat, which has established statistics and control system.
0
On an off-topic note, Sting, your name looks familiar. Are you a fan of Gundam?
0
That would simplify processing to have one object being controlled in real time, using stats generated for it, versus x number of propulsion systems in y directions, with z redstone pulses moving it.
That said, I do think some sort of overall fuel hopper, with a feed mechanism you'd have to create to use it, would be a good idea. It makes the ship more resource-intensive, thus harder to make, and would require a system like the redstone paths to connect engines to the main fuel source. In this way, you could either individually and manually distribute fuel to each engine, or use the more resource-intensive system to only have to feed one hopper and let the system fuel the rest of the engines. From a processing perspective, it would be a simple x / y calculation (x fuel divided by y engines) to come up with how much fuel each engine gets, and then, the existing figure for how long a unit of fuel lasts in an engine is multiplied by the number of fuel units, as normal.
0
But I see where you'd be going with a 2D game and Z-levels.
0
0
But it's all possible to add to the engine.
0