Cornflakes

and ships 8+km in size you only want to be able to detect them when they are just about to collide with you? like /single digit multiples of their size/ as sensor range? hard and static maximum sensor ranges dont work with a game of such large size spreads as DU. especially such small maximum ranges as would be required. we need a dynamic system thats at least inspired by actual physics (maybe something like i already outlined here) where detection ranges are defined by the actual construction of the searching and searched object. if you dont want to be detected build a ship with low emission systems and a lot of radiation dampening material. do you want to detect anything thats moving out there? either build that one, giant, moon filling sensor array or fill space with a bazillion sensor buoys. with some mechanism that includes/emulates angular resolution of sensors you get even more variation. when your sensor can only resolve signals less than 1 degree apart from each other and those two ships are half a degree from each other, you only see one blip. same with ground equipment, your high sensitivity nuke detector can warn you about that there is /a/ nuke /somewhere/ in the city, but cant tell you where because of its limited resolution. (or on a smaller scale it cant tell you who is carrying it around, only that its "somewhere in that crowd" ) so a capital ship early warning system could detect anything larger than a small YT1300 transport from half a system away, but the small stealthed fighter which is landing on the other side of the planet is invisible to it, as are its debarking crew and whatever they carry with them.

Im pretty sure players will sell empty fuselages as well. And if not, buy an already working ship with functional components and modify it.

well, what gustavoultra asked for /was/ a way to restrict what designs people build. and that is definitely out of the jurisdiction of any player.

and aetherios has more argumentative power than you or i... how? i also didnt say that you are /wrong/ i just asked you to stop claiming like its set in stone

aaaaaahaaaaa. linking hard? (i also dont even remember the debate)

hence why "different transition rules" Nothing technical would prevent EVE from giving you a warp-to point to get to the next star and transition you to it when you cross a border

you didnt understand it either then DU is as fragmented as EVE is, just along different borders and with different interaction rules between individual server instances

theres nothing about "gradually", just more frequent your certain area doesnt get old data, it just gets more rarely the current data set. when your shard gets the update "ship x at position y" you dont get the data from 20 minutes ago when it first arrived in the system. you get its current position. thats not how lightspeed works thats not how anything works

you still get the magic 5 light hours detection, just not constantly but only with discrete snapshots every 5 minutes

that is not time delay but reduced update frequency. different things with time delay you can see everything in full fidelity (according to your sensors) but shifted by x depending on your distance. the thing he outlined was that you see a snapshot of the distant object every x seconds/minutes with the frequency depending on the distance. with no data on the object in between those snapshots.

i have yet to see any game that employs any kind of light-delay mechanics unless its specifically built around those mechanics. i deem it very unlikely that DU will employ such mechanics. especially as they are a pain in the ass to keep track off, with lots of memory and processing power needed to generate the effects.

syntax error in line one

Erm... i ment that unigine literally cant run on consoles at the moment bdcause its not written for the different driver environment, and that you would have to rebuild it from the very bottom to make it run on consoles. But your points are very valid, yes.

why shouldnt/wouldnt mining beams work? haaave you met those fancy antigravity units that seem to be widely available. you know, those that made the big ships casually hover over the planets in the videos

and now name me the games that were for (multiple) consoles /and/ PC that were made by an Indie Studio also the engine upon which DU is built is not console capable, so they'd either have to (more or less) start over completely

it takes development resources to no end, it requires a completely different development environment than a PC game, and it would also likely require a pretty deep rebuild of the engine to run on xbüchs at all. then a ton of very specialised optimisation to run well on xbüchs. (heck the xbox one is processing wise in the same ballpark as my ancient six year old PC! and i got a small upgrade recently....) optimisation thats better spent on optimising it for general purpose PCs. im also pretty sure that you have to give a part of your revenue to microsoft to be allowed to sell it for the xbox at all. lots of effort and cost to get a game running on a platform which isnt suited for the complexity of the game and where you even cant use some of the games features without additional tools (scripting, /farking text chat/ )

why should it?

that really depends on what you lock on. maybe we'll get some voxel-exact targetting solution similar to Sword of the Stars' polygon exact target designation. with a simple one-click-lock you just target the center of mass of the ship, then you can further specify where you want your shots to hit with a (maybe zoomed in) view of the ship http://i.imgur.com/MRPCjAC.jpg

so, ignoring the physics talk getting back on topic: to build on the basic premisse of individual shield projector nodes whichs defense ratio depends on the power they get. shield projectors generate a defensive field whichs strenght is dependent on the power they are supplied. (this could be a damge-per-server-tick value or a damage-per-impact value, it doesnt significantly change the rest of the mechanics) when the incoming damage is higher than the defense value for a single point in time, the shield collapses and needs a certain amount of energy (not power) to reinitiate. so to reinitiate the shield it has to be supplied with a certain amount of power x time. it can take long with low power input, it can go fast with a high power input. so, now the interesting part comes when the power allocation to the shield generator gets /changed/. the ratio of power input to hp generated changes with the rate of change of the power input. the higher the rate of (upwards) change, the more hp you get out of the power you supply. so a shield which gets 10 power supplied constantly can stand less damage than a shield which gets 0 constant supply but the 10 power for the moment of impact. all we need now in addition is some way to supply large amounts of pulsed power. for example capacitor banks from which the shield generator nodes pull when they need to stop a large shot. this creates a continuum of always-fed-on-full-power shields with low-med ish per-hit stopping power but infinite HP as long as their treshhold isnt exceeded to "offline" shields which only activate when a shot arrives which can block very very high damage impacts but get depleted quickly as their capacitors drain with every hit. depending on the build of the ship and its shield arrays, the energy distribution choices of the crew and the damage state of the ship (for example the buffer caps getting damaged or some power conduits that power the shield array)

You suck at typing "electron mass" into google https://en.wikipedia.org/wiki/Electron_rest_mass

250 gigabytes? boah that must be cozy that is actually wrong. PCs have much more unused capacities because programs have to work on much more different hardware configurations. a console has only one possible configuration which allows much more optimisation and special case coding for exactly that hardware which allows better usage of the available hardware. a dev has as much access to optimise on a console as on a pc, but on a console its much much easier to deeply optimise because its only one possible hardware configuration. the advantage of a PC is that you can put a lot more powerful hardware in there and that you can do more on it than just game

so you dont want alloys to be a thing? you dont want components to need multiple input resources to be produced? you dont want equipment to need multiple components, materials and alloys to be produced? because that is what you say you want with "single unit requires many elements to function" and also: how does the complexity of the above diagram prevent it from being a grown construct? most of the sub elements produce something you could use in many different locations as well, its not that the whole thing has exactly one input and exactly one output. the whole refinery can start out as an inefficient plant to produce /one/ of the outputs or do one of the paths to the gasoline mixing pool (which, to my knowledge, should already give viable fuel) and expand from there to utilise more of its previous waste products to produce more gasoline/diesel/asphalt/sulphur etc.

well, with a generalised system a train and an elevator are technically the same thing. make rail riders monorail-like wraparounds and just build whatever you want moving along a fixed track on them.

i think a generalised rail system would be a better way to implement this instead of specialised elevator objects. rails, rail riders/motors, junctions, "ramps" to mount/unmount rail riders from rails and some way to supply them with power and you can build anything you could ever need in terms of fixed-track movable objects.

you dont need a phd to play factorio either and that is more confusing when you look at an already established factory factorio is also a good example of how building complex production chains should feel. perfectly fine and logical when you do it yourself. gigantic, confusing and a messy when you look at it as an outsider because of its complexity and size