wizardoftrash

For privately owned tiles the system would be the same. If a TU has ownership set to personal instead of to an organization, it would basically be a personal declaration of war, or a declaration of intent to seize or something. I prefer instead making this more about having some kind of cyber-warfare module attacked to the attacking-player's TU that is taking time to crash the defensive properties of the territory unit itself. It would be a lore-friendly way to explain why the attacking player couldn't dig or damage stuff prior to the timer expiring, but could after.

There was something I had in mind here that I guess i managed to omit from the original post. The concept of a TU protecting your constructs from damage here can be interchangeable with the protection bubble for the purposes of this suggestion. My thought is that whatever action a player takes to actually secure a tile, it should require a long enough period of time to negate those defenses that the player has a chance to respond. Allow me to make the case for "timers" here (and by timer, we could easily just say the ammount of time it takes an anti-bubble cyber warfare module to bring down a bubble). Scenario A has a timer, scenaro B has no timer. Scenario A: The attacking player sets up their TU in an adjacent space, sets up their cyber warfare module, and wants to attack the adjacent tile on Saturday at 8AM EST. They input that command on their cyberwarfare module, and with all factors considered in the attack, it comes down to a 24 hour timer (24 hours to disable the bubble, leaving both tiles vulnerable to attack from each other). The defending player gets a warning notification on Friday at 8AM EST that their base is being bombarded with radiation, and that the bubble will fail on Saturday at 8AM EST and will take 3 hours to reboot (the length of the raid window). The attacker still gets to attack when they want, the defender knows when the'll need to be on to defend and has a chance to hire a mercenary if they are stuck at work. If the defender shows up and the attacker doesn't, the defender can now attack the tile with the cyber-warfare module because it collapses both bubbles. Thats right @Vorengard no blue-balling with this suggestion, if an attacker drops defenses with cyber-warfare here, defenses drop for both sides (but only to each other). If both attacker and defender shows up, you get a sweet battle. Scenario B: The attacking player has the supplies needed to set up their TU in an adjacent space, set up their cyber warfare module, and wants to attack the adjacent tile on Saturday at 8AM EST. The attacker can log on at 7AM EST, slap down the TU and cyber warfare module, turn it on to bring down the shields and attack right away. Defender gets a notification but since they aren't on there is no one to defend. Attacker wins, no chance for the defender to protect their tile. No actual battle, just an open invitation to grief or conquer. So the argument is that Timers split up the player base into timezones? If the attacker and defender were in different timezones here, a 24 hour timer actually gives the defender a chance to defend their space from attack or counter-attack, but more importantly it allows enough time to actually create an interesting PVP experience. With no timer, being in a different time zone gurantees that the defender will never be able to stop you from attacking and vise-versa. If the point of having pvp and conquest mechanics for tiles is for players to actually be fighting each other, then some kind of timer is necessary for protected spaces, especially since unmanned weapons or turrets will be limited or nonexistant. Without some kind of time-based shield drop mechanic, it will be 90% AFK raiding (and no actual fighting), or 90% perfectly shielded tiles (and no actual fighting).

So the "declare war" timer, and the "protection bubble" timer would be the same thing here. the idea would be that the TU would not just delegate mining and modification rights, it would physically protect all of the static constructs there from damage (sort of like a soft safe-zone) if you set permissions that way. That window after the "declare war" timer expires would basically disable those functions of the TU on that hex only for the duration of the raid. You could call it a defense bubble unstead of a "declare war" timer, the key factor here is that it would require action on the part of the attacker other than just shooting at something. as far as linked TU's go, it would either treat them all as one large tile with the same "weight" as several adjacent tiles (for the purposes of timer duration) or each tile would be considered seperate for raiding (and just as proposed before, the attacker would start the raid in the designated tile, and get a time extension if they can sack it). EDIT: some more juice - I could also see there being an actual static-construct element, in addition to a TU, that is used in this raid process. Probably some kind of a shield-interferance device that is there to bring down a TU's defenses and make it suceptable to being re-claimed. This opens up the possibility of building more expensive, higher tier versions of the construct element that makes the "declare war/shields down" timer quicker or extends the raid window. Moreover installing such an element and operating it could be tied to a cyberwarfare skill (since this is basically hacking here), therefor requiring raiding parties to use a combination of cyberwarfare and physical force to take claimed tiles.

EDIT: To preface this, I'm aware that currently the plan for protecting constructs is with some kind of "bubble". For the purposes of this discussion I referred to a potential function of a TU to be protecting constructs in the space from damage. I consider these to be interchangeable, since we've got no idea what the "bubble" is or how it works, needless to say this suggestion revolves around a method to nullify those defenses that takes hours and notifies the defending player of when they will be vulnerable. The other backbone suggestion here is that both tiles become vulnerable not just the defender, but they become vulnerable only to each-other. This turns the "cyber-warfare module" into a raiding or conquest tool instead of a griefing tool. It has already been hinted by NQ that in order to attack and claim a tile controlled by a TU, that the attacker might need to own an adjacent tile with a TU as well. Since this is a function meant to make taking territories more like a war and less like a raid or grieving run, lets keep that ball rolling. How about also requiring a declaration of war? This would serve as both a warning and a raid timer for the defending player, setting it so that a player must declare their intentions to attack the adjacent tile basically 24 hours in advance, opening a fixed window of time to actually raid and attempt to secure the adjacent tile. That the defender has time to gather a militia or hire mercenaries (since otherwise the attacker could mass a group and attack the defender while they are afk, like rust, which is not really what DU is striving to be). Some factors Each group of controlled adjacent territories would contribute to an overall score that would be a factor in the amount of notice and length of window permitted to attack. If the attacking side is attacking from a single hex, and the defending side is 5 or 6 hexes that are continuously adjacent, then the attacker would have to provide a lot of notice, and would be granted a narrow window to secure their first hex (narrow being a couple of hours or something), and if the attacker is able to successfully secure the hex, their window would be extended for attacking other adjacent hexes until they capture another hex (extending the window further) or the window expires. If the attacker and defender each had roughly the same number of hexes, it could be around 24 hours of notice for something like a 4 hour window. Once you reach a point where the attacker's tiles outnumber the defender's tiles by a wide margin, you might get 12 hours notice for a 6 hour window or something. What would this look like implemented? When a rival org might try to invade a planet, they would be forced to start by claiming an unclaimed hex to use as a "staging area" effectively. Even if for some reason a planet ends up 100% claimed, then the attacker could claim a space-hex (if that end up getting implemented) and launch their attack from orbit. If the attacker starts by claiming a tile that's adjacent to the enemy right away, they risk getting preemptively attacked is high because of the short window for being badly outnumbered. The attacker might instead claim a hex that is 1 or 2 spaces away to construct a base of operations, claim tiles leading to the territory they wish to conquer and go from there. Battles for large territories could take weeks (if the attacker declares war, waits the wait period, then claims only 1 or 2 hexes and repeats), or it could be done in a weekend (if the attacker declares war, waits the wait period, and systematically and successfully claims all of the interconnected hexes 1 by 1 extending their raid window enough to continue, but this would require overwhelming force, organization, and supplies in the part of the attacker. To take hexes from other players in this proposal, you'd have to be really committed to making it happen since it is unlikely that you'd be able to place your TU and also attack all in one play session (due to the wait period). The TU's would then serve their purpose very effectively in protecting structures and ships from random acts of looting. Some of the nitty gritty here, to ensure that you'll actually be online during the attack window as the attacker, when you declare war, you basically schedule a time for that attack window to start and the system would send the warning to the defending player 24 hours in-advance of the window set by the attacker (and of course, it wouldn't let you set a window for sooner than you'd have to wait based on the number of hexes). Some variations to consider -After the declaration of war timer is over and the window starts, it could mean that both the attacking and defending hexes are up for grabs, meaning that if someone attempts to steal a tile from you and you defeat them, you could use the time remaining in the window to launch an attack on their hex, preventing continued harassment and attacks. This is probably the best way to go. -This system could use different timer lengths for TU's owned by individual players vs TU's owned by organizations. Organizations might benefit from shorter or longer attack windows, or it might be that Orgs with at least 10 players get a slight boost (but not beyond 10 to limit dead alts, and not counting trial characters for the same reason). -Players might be able to raise temporary shields to affect the length of that attack window, or prevent the attack from spilling over into more adjacent hexes. That or it would come down to how they physically built the structures on those hexes, its possible for a player to make it very difficult to take more than one hex at a time. -Player count in those hexes might affect the length of the window as well, it would check to see how many players are present on the "smallest" of the two teams and scale the length of the window accordingly, more players means more time. -Raid windows could instead be determined solely by actual static-core elements (such as temporary shields or siege weapons).

I actually can't tell if you are joking here or being serious. you are kind of all over the place with your argument here. Mainly though we have no idea how long it'll take to mine stuff. Part of that boils down to how long it'll take to scan for resources, part of it will boil down to exactly what you get resource-wise per-click of concentrated mining, and part of it will boil down to how efficient the refining process is. Even if every resource is equally easy to find, and are in equal sized nodes, "expensive" resources like platinum might be really lossy in the refining step (10kg ore turning into 2kg of metal instead of 10kg of ore into 7kg metal for iron for example). The reality is that expensive resources will probably be harder to scan for, will have smaller nodes, and will be fewer. This will mean that building a "dumb" component (like a steel wall) would be easier than a "smart" component (like an engine that requires 12 different resources). But how long a material takes to AQUIRE won't be the deciding factor in its "cost" on the in-game market. It might take me a whole play session to get 10KG of unobtainium, however if unobtainium is only used to make a cosmetic toilet item, then there won't be much demand, and it won't be worth very much quanta to other players. It might be super super quick to get 10KG of iron, but if players are using it faster than it can be mined, it might end up being worth quite a bit (an example of something that would "cost" very little time, but "cost" quite a bit of money on the market).

Yeah, except you don't actually drop all of your items on death, you lose a percentage of your inventory, determined somewhat at random, and it might not even be lootable. DU =/= Rust You can't introduce a "loot all" mechanic in a typical mmo like WOW, that kind of mechanic is built for murder-hobo style sanbox games. "re-build civilization together" wouldn't happen if you could take everything from anybody just by shooting them.

A person hit by a ship missile or a discintegration cannon should not need to be double-tapped.

Also, the cost of various resources are going to be in-part at the mercy of the innitial "shop" NPC's, and in-part at the mercy of good ol' fashion supply and demand. Once the shop NPC's are taken down, then it'll all come down to how much material people need to use. However I suspect that actually building things in the game is going to be much much more time and labor intensive than most of us are expecting. As someone who plays a lot of sandbox games of varying difficulty, the game-play pipeline that has been proposed for DU has some interesting hoops that many of those games don't have, but is missing some hoops that I would expect. At a minimum, the starting planet will probably have most if not every kind of resource. Mainly because constructing an atmospheric ship that can also fly in space is supposed to be logistically and resource intensive, you'll likely need a bit of almost every kind of resource to make the parts you need for a ship that can fly anywhere. If the resources were scattered across different planets, then literally everybody would be stuck on the starting planet. There is a good chance though that there would be a few materials that can't be found on the starting planet that are used for upgrades, or higher-tier versions of existing ship parts for faster, tougher, more efficient ships. But leaving the starting planet will probably have to be a group activity. It'll take a very very long time for a solo player to do everything themselves needed to leave the starting planet. Said player will have to scan for each kind of resource, harvest those resources, refine those resources, craft each of the parts needed for their ship, actually build the ship, and do all of that without getting killed too often (so staying in safe areas). Some of those steps might require you to gain levels in specific skills (like refining and engineering), so you might reach a point where you actually have all the raw materials, but are waiting days for your xp to increase enough. That being said, there will be plenty of players who will want to explore, scan, and mine resources and not bother refining or crafting components exactly because of the exp and leveling time. Players will be specializing their skills in one or two areas, and relying on the in-game economy or teammates in an org to fill in where their specialties aren't. I expect resource costs to be reasonable because mining as a job is more exciting than refining or engineering, and therefor it will be more popular. If its popular, then supply will be high, and the choke-point on demand will be either the lack of refining-specialized players or engineering-specialized players. Thus I expect resource costs to be low in-general. However I fully expect to see some resource costs to be high, especially if one becomes a defacto currency for some reason (yes there is an in-game currency in the form of quanta, but players might be trading in a resource that's a backbone of ship building for example instead). Mainly because the resource will be used, but also traded strictly as a currency.

I'm familiar with KO mechanics, in-general I'm a fan of them. Something to keep in mind though... In similar games that have a KO mechanic, you drop literally everything on death. When you are KO'ed, attackers tan loot your body, take your weapons, etc. The KO mechanic allows you to disable someone instead of killing them by confiscating anything that can deal damage. The problem is that "full lootable" KO only makes sense in a game where you drop everything on death. So far, its slated that you will lose *some* of your items, but not all if your character dies. This would mean that robbers would KO people, rob them, and then probably kill them anyways (or not to avoid breaking laws and acquiring bounties). Having "full lootable" KO here just doesn't make sense. "but I want the ability to disable them, i should at least be able to take their weapon" yeah if anything that would be the way to go, KO would allow you to take weapons from a downed player, and then by-default if you die, you drop any weapons you were carrying plus some of your resorces. Instead of making weapons lootable by default though, *ammunition* could be lootable by default, or give attackers a "disarm" option that sets a nice fat long cooldown timer on a down'ed players weapons. Another thing to consider here too is that there would need to be "outright kill" situations where there is simply no KO step, and this would probably come from a CVC weapon hitting a player, or a PVC weapon hitting a player. Missiles, very high calibur guns, high intensity lasers, there is a host of things that should go right on ahead and skip the KO step. Allowing a character to force respawn from a KO is also a must, otherwise repeatedly KO-ing a player would become exploitable as a form of griefing. Also, no handcuffs. 90% of the players that want a handcuff style mechanic want to use it to capture and torment innocent players, not to capture criminals alive.

That, or the market NPC's might be set up in such a way where each time they are turned on, they will only buy so much of the same thing before they stop accepting more trades of that type. This is sort of how Starmade works. That way when the bots turn on, they will only buy a certain ammount of DIRT for example before deciding that they are no longer trading for dirt. The value of dirt in the marketplace as a whole would only be affected until the bots have bought as much as they are willing to. The same would go for other materials as well, so if the price of lets say Iron were artificially bumped-up by the bots, it would be a temporary bump.

An interesting side effect of the bots is that they will effectively set pricing standards for certain raw or refined goods. If all the bots are offering 100 Quanta per 12 cubic meters of platinum for example, the price of plat won't be any lower than that (in the local area) since sellers could just sell to a bot and make more than people would be offering to buy. Depending on how much currency is actually floating around, this is going to do some strange things to the supply and demand of goods, and its going to be really difficult to do meaningful trade probably for over a month.

Play Space Engineers, its built for that. DU isn't

As much as I'd like to see compound modules like this, its not only a pain to implement, its a paint to balance. Similar games where the components of weapons or other systems are highly modular usually devolve to two or three different dominant configurations being viable, and that's it (Starmade for example) with some choices being so bad that they might as well not exist. With a group of fully-designed turrets that can't be customized, they can be individually balanced by the devs on-the-fly, buffing or nerfing actual weapons as needed. Besides, between turret type, size, and room for specialized ammunition, I'm sure there will be plenty of variability. Another thing to consider here is what aspects of building and customization the devs want to favor. If there is a deep system for customizing weapons, then weapon configuration might become more important than how you built your ship (your ship would just be a cosmetic accessory to your gun at that point). If the devs want us to care more about the ships and structures we build, then the option on how much customization our weapons provide will have to be restricted. I think there will be plenty to do with actual ship or structure customization on the macro-level, that having micro-level customization would be unneeded and possibly cumbersome.

but ramming implements would also be a nightmare to balance, moreso if ship mass and speed are determining factors in damage. And yes, you do have a local point of impact, because this isn't going to be a game where each ship just has a health bar. Damage will occur in spheres, voxels get deformed and individual ship elements in a given sphere receive damage. Sure, DU doesn't have projectile tracking, but it *will* have randomized point of impact for successful hits with ranged weapons. That means that a ramming implement could be more precise than a lazer simply because you are physically steering your ship instead of relying on character and element metrics to hit. In addition, there would be some complexity to making the implement behave correctly, rather than just checking for a collision it has to check *where* it collided which might be technically challenging. If you simply have a "melee weapon" element instead of a ramming implement element, then again, it can use the same character and element metrics to determine hit, damage, and where the damage sphere goes. It would be comparatively easy to balance against other weapons mainly because it would have a fixed damage value (instead of having speed and mass both be additional values), it could miss due to character metrics instead of solely relying on pilot error to miss, and for balance purposes it would just be a very very short ranged gun.

Here's the thing though. What a ramming "weapon" boils down to is a melee weapon, but with damage based on mass and speed, and with a local point of impact. It would be simpler to instead implement a melee weapon if the goal is to have a close range way to deal a lot of damage, and a melee weapon would be easier to tie into character skills since it could be calculated in the same way as other weapons. My concern is that a ramming implement would be challenging to balance against other weapons, it wouldn't tie into character skill trees well, and it would be hard to use. The payoff would be that a person could intentionally build a ramming ship, but that wouldn't satesfy the "ram stuff with garbage to grief" players, and it might not even satesfy the players that would use the implement. It would be a risky thing to burn dev time and energy developing, when instead they could make melee weapons that behave exactly like other weapons, which would take less time and energy and be effectively similar to ramming implements. They would be effective at the same range

At that point, wouldn't we just call it a "melee weapon" for a ship, rather than a ramming weapon? Because if the damage is based on mass/speed/point of impact, then it will end up using a totally different set of calculations from any other ship-mounted weapon. As soon as ramming "requires" a ramming "weapon" to be effective, you might as well just have a class of melee weapons for ships (like beam cutters, pile drivers, drills, etc).

One of the reasons NQ stated that there would be no CVC collision damage was that it would make it too easy for a "cheap" construct to destroy an expensive one. A player could spend 10 minutes building a ramming ship and ruin a construct that a player spent hours or days on all in a moment. Ramming with a ship does not require any skills (where as other aspects of PVP such as operating guns would). The other aspect is that servers and connections aren't perfect. If there is CVC collision damage, than anyone operating a dynamic construct in or around friendly ships would accidentally ram if there was a connection or server hickup, ruining their own work and the work of others entirely due to technical issues. This happens *all the time* in games like space engineers, it it is simply too frustrating for someone to go in for a safe docking, hit a small ammount of lag, and crash their freighter into the station, absolutely wrecking both constructs in the process. It exposes all players to an unnecessary amount of risk just so a few people can get jollies out of using trash ships to greif players.

I understand people's hesitation with this, NMS really burned people hard, and with how buggy games like Space Engineers are, people look at DU and just roll their eyes at yet another over-selling sandbox space game. We know better, but we are a wise few.

I could see Cybrex and his alts running around at 0:58

I would especially love to see these features appear in a future patch, and on especially rich undiscovered planets. That would be a great time to introduce some new ores or elements that can only be found on hostile planets (perhaps those ores and elements would be essential to the construction of equipment and parts to survive those phenomena). Possibly the ores and materials found on those planets would allow you to weaponize those effects, for example a planet with highly radioactive areas might have an ore specced to allow craft and players to resist radiation, and an ore used to make irradiated ammunition or a static construct element that allows you to conceal a hex in a radiation cloud, or a bomb that irradiates a wide area for a period of time. An area with tons of Volcanic Activity might have an ore that is very useful for mitigating heat damage and atmospheric entry damage, in addition to a powder used to make incendiary ammunition or furnaces that raise the temperature of a hex higher than normal characters can survive (or the reverse, increase the temperature of a very cold hex so that characters can be comfortable there).

There could certainly be room for an element like that, I think though that it would need to be tied in some way to the scanning skill, as that's clearly a type of scanner (just as a different kind of gun would be tied to the gunnery skill).

I recognized as much, but I wanted to make it clear to them as well that I wasn't referring to EVE. EVE is honestly a terrible reference point for DU because it has really only 3 points of similarity, and far too many differences. From what we know subscriptions are similar, training skills will be similar, and its a sci-fi game. The rest of this game is wildly different from eve. The economy will not only function differently, it will be based on a very different gameplay backbone and production pipeline. Combat (when its implemented) will be wildly different, as there is simply no way a sandbox game can have the same level of complexity and variation in terms of actual guns and equipment, but might have far more variation in combat scenarios and contributing factors (the things that actually matter will be way way different). The only reasons I can bring up Space Engineers and Starmade as indicators on what things might look like in DU is because SE and Starmade both have very limited actual equipment options for pvp in terms of weapons, but a tremendous amount of variation in terms of actual ship design and how those components are selected and lain out.

Besides, JC's example might have also been assuming that people are doing nothing but removing voxels at the fastest rate possible (basically picking up dirt). Mining for resources however will be much more involved than clicking on funky colored dirt for hours. Scanning will eat some of that time, travelling to where the resources are will take some time, tunneling to those resources, or shaping a mine in such a way that you can fit, or that your cargo vehicle can fit will take time. Transporting those resources when your inventory is full will take time, having them refined will take time. The accessory activities involved in mining will have a huge impact on how long the starting planet remains a viable place to gather resources. The trick I think will be trying to collect resources outside the safe zone, and navigating around the claims where mining is not permitted due to TU's.

I wasn't trying to refer to Eve there, more using Starmade and Space Engineers as examples because there are no pre-defined ship classes, and no real difference in what classes of weapon you can fit to them. Starmade has no ship classes whatsoever, only ones loosely outlined based on block-count and mass, and there are well defined combat roles, but it is entirely modular so there are no real cuts as to when a fighter starts to become a bomber, or when a shield-tank starts to become a support ship. In Starmade especially, most things scale linearly, but some have diminishing returns at high counts, meaning the bigger your ship is, the less efficient per-block or per mass it is. A 1mil block ship will 9 times out of 10 get STOMPED by 2 500k block ships in part because of diminishing returns. It has nothing to do with price (since block count = block count here), its a simple matter of those blocks being more efficient across 2 ships than on 1. This is made possible but not dependant on having a 2nd player since starmade has an extensive AI mechanic for entire fleets. An AI ship is sometimes straight-up more effective than a manned ship at aiming. Since DU won't have anything like that, then simply having a 2nd player would be what grants you that kind of advantage. In Space Engineers on the other-hand, there are effectively 2 classes of ship because there are 2 classes of ship-grid: Small and Large. The strangeness is that you can build a fairly small ship out of a large grid, but you can build a really huge ship out of a small grid. The trick is that small grids are the most efficient way to build small ships because of how little mass and resources the "minimum systems" take to build on that grid, but that large grids become instantly more efficient than any small ship that takes roughly the same footprint, just with way less redundancy with systems. For example, I could build a "Frigate" with both grid sizes (small and large), the large frigate would be more efficient, as each battery, generator, thruster, gyroscope, weapon, etc would be giving me much more output for its mass. The small-grid frigate however would be much more resilient to system-based damage because destroying 1 reactor doesn't totally cut power, it only *reduces* power. That being said, once you pass a certain ship size, large grid is the only way to go (because you'll be way more efficient, have more hp worth of mass, and still have some redundancy). Even with the way Space Engineer's ships work though, there is still only 3 kinds of ship-based weapon, 1 of which is a stationary warhead that is only viable for ships that literally are missiles, or for sabotage. There are only 2 ways that the remaining 2 weapons can be mounted (hull-mounted single direction, and turret mounted with auto-targetting). Again though, if you have a 1million block ship, up against 2 500k block ships, the 2 ships will again always totally stomp the 1-million block ship because of the way weapon systems have to be mounted, and because of the loss of maneuvering associated with being high-mass. If half of your weapons systems are turret-mounted, odds are that only 2/3rds of them are firing at any given time if your target is smaller than you, this is because of simple angle-based firing restrictions on the turrets (unless 100% of your turrets are mounted on one face of your ship in a sloped-shape, in which case all they have to do is orbit you faster than you can turn, and you cannot fight back). Turrets cannot track objects moving at near-max speed, which is terribly easy to do in Space Engineers, meaning most of those shots will miss unless the target is changing direction (in which case they still might miss because the turrets are trying to anticipate movement). Hull-mounted weapons will only hit if you are physically facing the target, and you are aiming those manually (no lock-on, and the game tracks projectiles so no hitscan either). They are notoriously difficult to aim at long distances, and you will only be able to shoot at 1 target at a time. If the 2 500k ships are even half-awake, they attack in a tight formation (so that the automated turrets are splitting fire), and will have a combined firepower that is more than double the 1mill block ship due to the difference in size for turret-mounted weapons. Add that to the fact that the 1mill ship can only aim their hull mounted-weapon at 1 of the 2 attacking ships, and that those ships will have roughly double the maneuvering power vs whatever the turning factor is on the 1mil ship and you have yourself one huge flaming derilect and 2 slightly damaged battleships. These 2 games heavily favor fanning-out resources across multiple constructs. If skill/level is a limiting factor for equipment, then the more skilled player will need to mitigate being outnumbered to have any advantage whatsoever. Moreover, an under-skilled player just needs to team up with a couple of buddies to do just fine against 1 uber-player.

That still seems like a function that player scanning would serve, but if not, it would be a useful implement then. The way I see it, player scanning would be broken down into 3 stages: Planetary scanning, regional scanning, and local scanning. At the Planetary level, a player would be using a ship-based long-range scanner or a station/moon/planetary long-range mega-scanner to either detect planets and asteroids in-general, or to detect planets and asteroids with a specific combination of elements. They would be scanning sectors of space for these bodies possibly in a systematic way, or in a more haphazard way while traveling to some specific destination. Space is huge, and with 12 planets in the "starting" galaxy and who knows what in the maner of asteroid clusters, there could be a lot of space to scan. At the Regional level, you would be scanning groups of hexes for elements. Maybe not quite scanning entire continents at a time, but a systematic survey could give you the composition of a continent. You would do this form orbit also using a ship-board scanner. At the local level, you would be scanning for resources on whatever hex you are on, and that would give you info on specific location, composition, and potential hazards such as magma pockets. All 3 of those stages would depend on the scanning skillset over-all, and they might each have a skill tree where you can specialize further (for example you could just go down the road and invest in Scanning 1, Scanning 2, and Scanning 3 which would give you some bonuses and proficiencies at every level. However you could instead go for Scanning 1, and Long-range scanning 1, 2, and 3 instead, especially if there are other surveyors in your org that focus on regional and local scanning).