DrakeBrimstone

Please add that using Alt+F4 or logging out in order to lock a ship in place is the only way to keep AGG ships from falling out of the sky when the user gets too far away from it. Right now, the AGG just stops working if you get too far from it, and it isn't very far either. I feel it could be as simple as giving a new function to the AGG that locks a ship in place. There should of course be limitations on use, for example a maximum speed and within a range of the base altitude. It should persist until the user Unlocks the AGG.

As has been mentioned many times, ore on planets is currently finite, and quite frankly we are depleting it rapidly on the more populated worlds. Without some method of regenerating the ores on planets we will soon run out. That leaves us with the yet to be implemented space mining as our only hope of acquiring the resources we need. But what if we could have Ore Regeneration on the planets without actually wiping them? Here are a couple ideas that could accomplish this. IDEA 1: Regenerate Unclaimed Hexes Any Unclaimed Hex will regenerate over time. Any dynamic constructs on the hex at the time it regenerates is moved to the new surface which may be different than the old surface but should be meshed with all adjacent hexes as best as the system can. (And static constructs can't be built on unclaimed hexes, so we don't have to worry about those.) On Guarded planets there may need to be additional rules made for how close different players/orgs can claim hexes to each other, but on "normal" worlds where PVP is allowed the players make the rules, by force if necessary. Planetary Wars will be fought over control of hexes to keep them unclaimed so they can regenerate their ores. IDEA 2: Vertical Regeneration Over time holes underground will fill in up to the lowest point on an existing static construct on the hex. In un-mined/filled in portions of the hex there is a chance for ore generation over time. The chances should be based on how far above the "layer" the ore is spawning in has been re-filled and how rare the ore is, and how much ore is nearby. (Optional: players manually back-filling holes speed up the vertical regeneration.)

This has been something I've been concerned about as well. If they want to maintain "realism" with resources then regenerating planets is not going to happen. The best bet in my opinion is mining asteroids. I would like to see both "static" asteroids, ones that are large enough to built a base on/in, and regenerating asteroids that may "collapse" after being mined sufficiently only to re-spawn after a time, probably not in exactly the same place, or with the same resources. I've already mined out all the veins of Iron on my Sanctuary hex, and am getting close with the rest of the T1 ores. I've only mined a few T2 veins, but there are only so many of them and if I tried I could probably mine out an entire Sanctuary Hex in a day or two of all T1 and T2 ores if that is all I concentrate on. The need for resources is huge. It takes almost 1 and a half Veins (Sanctuary veins are usually 4-5k L of ore) of Iron to make 1 large container. I am at the point where I HAVE to leave Sanctuary and I worry about finding a hex elsewhere that has access to a good market and hasn't already had people mining it because of the ability to mine unclaimed hexes. I have some ideas on ways to regenerate on planet, ignoring reality, but that is for it's own thread.

What it is: A Landing Pad Sizes: XS, S, M What size grid it can be placed on: Static or Space grids one or more sizes larger grid than the size of the Landing Pad. What it looks like: A square landing pad, length, width, and height+ of the building grid from a core of the same size as the Landing Pad. The pad itself would not be very tall, but it would have an area where only separate dynamic grids no bigger than the pad may be built. This gives the necessary clearance for ship retrieval. (Also gives a space where ships can be built and allow them to be stored while still in progress.) What it does: Land a ship (Dynamic Core) of it's size or smaller on the pad and activate the pad to open a menu to store the ship within it. User must have permissions for both the Landing Pad and the Ship. The pad's activation menu would also give a list of ships stored within to retrieve. Volume: Subject to Balancing. Should at least hold the equivalent of the full volume of space a core of the landing pad's size. Ship volumes calculated by the sum of it's parts and contents, or on the ships grid size. This would allow a Medium Landing Pad (which must be on a large static or space grid) to hold 8 Small Dynamic Grid ships. Volume of ships that can be stored could be increased with talents. Other ideas to go with it: Link it to a container with fuel to allow refueling stored ships. This would be done by selecting the ship and selecting a fuel tank within the ship from the menu. Allow ship containers that are set as a Linked/Primary container to be accessed while within range of the Landing Pad. Allow access to ship's cargo from the landing pad interface. LUA programming could include reading information on stored ships. Advanced LUA might allow for retrieving ships via alternate input than the landing pad menu. Another new Element to pair with the Landing Pad, a Ship Storage Unit. It would link to Landing Pads and act as a separate storage space for ships. Linked to multiple pads could allow retrieval of ships from any linked Landing Pad or Ship Storage Unit.

It doesn't even need to be moved to an instance. An instance suggests it is still fully loaded in memory somewhere (on the server, but still somewhere.) Instead, just unload the dynamic object and create a link to locally stored ship's inventories at the local market. If the ship's container is the players linked container, make that link still active within range of the "Hanger" and Market.