# Airships

*I'm not going to specify how much seriousness this draft was written with vs "lmao we could do this but why would we do this this is insane", but know that all the technical details in here are **fully feasible** within BYOND, with an amount of work no worse than say, doing 3 atmos rewrites.*

## The map
- ~3 zlevels
- Sealed shipmap with airlocks to outside, with cycling if the planet's air is bad. Probably not though, because the whole point is le funny steampunk
- Floating, airborne overmap object. Landable.
- On landing, "sky" turfs are replaced with ground turfs or openspace depending on zlevel.
- Flight power entirely provided by electricity, potentially boostable by gas.
- Vertical maneuvering depends on if the map is thematically using futuristic antigravity repulsors, or if it's an unironic steampunk-like reinforced airship using lighter-than-air gas
- Crashing into the ground if flight is disrupted.

## Travel
- Players can walk around the ground overmaps directly. With an overmap size of 200x200 this gives a virtual size of 6400x6400 of explorable space.
- Falling out of an overmap object lands you in the allocated tile it was on. This, will, obviously hurt a lot unless you have a parachute/glider wings, given that you just fell out of the sky.
- When reaching the edge of a chunk, the player transitions over. The chunks they "left behind" in their 3x3 are deallocated unless there's running machinery (which function as chunkloaders), and chunks infront of them are loaded in and rendered.
- You can fly up and down the z-axis. You can literally fly onto an airship, if you reach its z axis
- Fall damage is based on z-axis
- Each zlevel is considered 15-25 meters.
- Looking up will be possible. Since rendering a hull is actually comically expensive without black magic (which is possible but even more beyond the scope of what is already here), you'll just "see" (printed to chat) the locations of anything around you, say, `"You see the airship-name a good ways off to the northeast (dx/dy 50/30), 459 meters above you."`
- Looking down, while able to be handled with BYOND native stuff, should be skybox-only unless you are within 3 zlevels, for performance
- Certain machinery would be able to look onto the ground from above with clarity, loading chunks as necessary.

## Overmaps
- Everything in the world is either an overmap object (pinpoint object with a square radius for "size", with x/y/z coordinates) or an allocated overmap tile
- Every overmap tile corrosponds to 32x32 of physical space
- Players falling out of an overmap object are deposited onto the tile the object was over.
- Every overmap object has a z-height. Overmap tiles support z-heights. You can fly up and down these.
- To hold all this data,
- Every overmap tile is a /datum/overmap_tile
- Allocations are held with /datum/overmap_allocation
- Objects are held with /datum/overmap_object
- Objects may fly above and below each other. If they're on the same z-height, they'll block each other, or flat out crash into each other.
- The overmap wraps around the edges.

## Allocations
- Non-objects are allocated 32x32 spaces
- Large POIs, as opposed to dynamically-spawned POIs, may be static-loaded with multiples of 32 for their width and height.
- We only care about players and certain equipment. Atmos lines/power cables going through borders will force a load if the other chunk is loaded
- Player built machinery are "chunkloaded"
- Minecraft-like chunkloading
- Each player has a 3x3 of chunks loaded on themselves
- Player-built machinery that require processing will force a load
- Machinery pipes/cables going through edges will force a load.
- Atmos/powernets will require rewriting to have cross-edges work, as you'll see in a few lines
- Every allocated chunk is a 32x32 in dynamic reservation/allocation
- Every chunk is glitzed visually and movement-wise to the surrounding chunks automatically. The z-transitions will be optimized by just getting the allocation datum, to avoid having to varset
- Chunks default to no dynamic lighting - everything can be visible, but lighting is there. A global planet object (or perhaps chunk-based objects) are blended into the /area's lighting plane to provide no-overhead dynamic area lighting. Player-built structures and areas will still have dynamic lighting with a starlight-like system
- Built lights and flashlights should force dynamic lighting within a range, if the area is under a certain light threshold from natural lighting.
- Lighting is deallocated when not necessary
- So lighting has to be refactored too :)
- Deallocations
- Chunks no longer needed are deallocated from dynamic reservation
- We only care about the player experience here
- Modified tiles are saved to a list or savefile
- Objects and simplemobs are saved to a holder object in a single-tile "compressed" space, along with metadata for their locations
- On chunk re-load, tiles are loaded in and everything else are then placed
- To save on dealing with tile data, chunks are generated via deterministic perlin generation. Much like in Minecraft. Only the level seed is saved.

## Required refactors (existing systems)
- Lighting - Most allocations will not require dynamic lighting unless they're below a certain darkness, and a single object is needed per chunk that renders the entire chunk. This is to save memory.
- Pipenets - Pipes need to reach across chunk borders
- Powernets - Power cables need to reach across chunk borders
- ZAS - Most chunks do not require air processing or zones, they should just be treated as static planetary atmos and their air should only be initialized upon a need to modify the air (like say, a flamethrower being used) to save memory.
- Pathfinding - Needs to take chunks into account (should be fast lookup, normal pathfinding if not needed, if it is needed, pathfind to chunk border and then pathfind from other chunk using a rimworld zone-like algorithm)
- Zlevels, Zlevel management, Zlevel access - The Z coordinate no longer means "level" in this context. It's the literal z-axis of an object. Everything on the ground returns 1, anything not on the ground returns the z value of the object.
- Multiz movement - Too complex to explain, see "Overmaps" section
- Baseturfs - Too complex to explain