Cornflakes

a script really is just a dynamically compiled/interpreted piece of software that runs inside/as a part of another (bigger) piece of software. It says /nothing/ about the size and/or complexity of the script. A script can be any size and complexity. (I have a buddy who wrote stellar dynamics simulations in python in uni... sooo)

Simple solution: ignore relativistic effects and signal delay. Explaining why some things are affected by it and others not is harder than just dropping the issue altogether. Related to that sensors could have limited time resolution, though. Like a short range targetting sensor gives "real time" data (image frequency = server tick rate) but a long range system scanner gives only one scan every 5 minutes (arbitary number is arbitary, "long"). So the long range awacs ship would maybe be incapable of hitting anything close to it because its scan rate is too low to give usable targetting solutions for moving, maneuvering targets

What prevents you from building a bank? Banking is player-player interaction, it doesnt need explicit mechanics for it. Want a loan? Ask a player.

because mirrors are sooo good at absorbing radiation an ideal sensor is perfectly black in the spectrum it wants to detect in, not mirrored how would it detect radiation if its not by absorbing it? why would an optic sensor glow? its a receiver, not a sender, any emission its creating flow directly back into the readout as noise if at all its new remotes using RF, old ones were wired, IR or ultrasonic. i'd personally just scrap all this "thats infrared! thats radar! thats blah!" stuff and just abstract it to emissions and detection sensibilities (maybe with some abstracted spectrum mechanic to introduce another dimension) sum of all emissions gets distance attenuated and compared to the sensors (spectrum modified) sensitivity. unify all the emissions (and reflections from active scanners, they look the same anyway in this simplified model) instead of saying "thats this very special narrow area of EM and this is this completely different narrow EM band!" ....

*cough cough*

Like a mouse?

Take any adroid device, install droidpad, profit ¯\_(ツ)_/¯

The only development studio that "i" have and i can recall from the top of my head is jowood, and they died half a decade ago (And googling just told me that THQ nordic is an austrian company! Woot! i should go over there and annoy them into giving someone a supreme commander license!) In my opinion as native german speaker its easier to learn english and have all the confort it gives than to annoy people into making translations for me

I'd prefer if theres no explicit ID system but instead something thats built on LUA communication. Like a few standard communication tags with assorted data sectors (like xml or json tags). For example vessel name and affiliation. Security features atop that could be handled by player made LUA code. i'd also make it hard to impossible to intercept such communications. Transport layer security should be hard to circumvent

I'd personally go further and allow (sandboxed) remote code execution. Kinda like html5 programming, you get a "screen", a few processing resources and a link back to the "server" dpu and can execute code on the client DPU. For example for remote interaction interfaces which work on any construct without people having to build complex protocols manually. Say theres a big trade station with automatic dock management. You ping the station and you get a request for remote computing. You allow the station a screen and some computing resources and it opens up the dock interface on the screen in your ship, through which you ask for a dock and the station replies by giving you a waypoint for docking through the interface. Then it closes the link again and the interaction is over. Basically a system to draw GUI elements on cooperating computer systems/screens to allow easy access to automated functions without the community having to build complex communications protocols and software

i'd find it interesting to see a game its not just about blowing up stuff. assuming the other things that /arent/ blowing shit up get proportionally more love. maybe it is boring, maybe it sucks. or maybe its awesome and doesnt need combat. we dont know, so we can as well just sit and wait ¯\_(ツ)_/¯ instead of jumping and screaming "the game will fail without combat!"

I agree with the really cool things being hard to archieve but i certainly dont want it archieved by limiting the tools available to players. The hard thing should be finding out /how/ to do it, not executing it. If building is hard to execute its just frustrating.

thats the intention you shouldnt be able to tell two identical blips apart without extra data. or even if the blip in question is anything at all (think sensor confusing environment conditions). with better and better sensor data you should have an easier time telling what it is, but not magically gain unique identifiers. cause how can your sensor say that the thing its detecting is core unit fb5cdeff883c2 and not fb5cdeff883d2 ? all your system knows is "blip 1" (with emission signature 1) and "blip 2" (with emission signature 2) or however you name them in your code and what other data your system gains through other game ways.

i think a sensor should /never/ just provide the ObjectID. determining an object ID is the job of the computer behind the sensor. a sensor should provide "theres a signal", and the player has to figure out the rest with DPU magic. the sensor doesnt know /what/ it is in first iteration. it could be a single generator generating heat and nothing else, it could be a ship with a generator, it could be a group of ships close together. the "object" the sensor detects is only some generic radiation, the DPU has to make sense of that itself. if you add some ID to that signature its fine, thats your thing. but the sensor just tells you that theres /something/.

Here i outlined some basic ways to define actual detection. i like the idea of just needing the object ID to identify a located target in the computer system, but it also seems slightly limited in what the player can do with software to locate/identify/track targets. maybe replace it with a more generic "point/vector" primitive to which characteristics can be added by the player? the primitive would contain an origin, a direction and optionally a distance. so its denoting "somewhere in that direction" or "exactly there". those primitives can be handed over to other systems (like turrets) and the game engine handles all necessary coordinate transformations. (cause thats a pain) the primitives would be reusable for other purposes other than detection as well, for example for general navigation and communication of directions. (hell, the direction vector could directly be utilised for target designation by the player "the first ship that intersects with my pointing vector", a raycast) so, now to actual gameplay and not programming details. a passive sensor cant determine the distance to an object on its own. it either needs a reference emission strength (it receives x watts/m² object radiates y watts so the distance has to be r away x=y/r²) or a second passive measurement which has to be some distance away to cross the vectors and to determine the distance that way. active sensors provide their own reference emissions and thus can pinpoint targets on their own, but they are very visible over great distances (the square of their detecion range assuming identical ships) again the vector math should be done by the game engine the vector headings shouldnt be perfectly precise but have some imprecision in their heading. so one sensor might have an angular resolution of 0.5° which gives good enough data at short ranges but isnt suitable for long range fire and another sensor might have an angular resolution of 0.025° which is suited for much longer range pinpointing but the sensor also has balance defined drawbacks. this would enable confusion plays with multiple ships flying close to each other. appearing like a bigger target or a different target than whats searched for. player programming skill should come from choosing which vectors to analyse more closely and which vectors to "cross" to determine pinpoint coordinates. the rate at which vectors can be compared could be game mechanics limited ( x comparisons/second per DPU) so that good programmers would have an edge in terms of target detection by smart choice of the vectors to analyse and cross for coordinates. so one could run target identification by brute force and a large amount of DPUs or by smart checking and using the resources they have optimally. with a way to have DPUs communicate even across constructs (linky) would encourage having specialised sensor and processing ships, which weave their com nets through the fleet and supply the less sensor focused ships with targetting data. so for large battles dedicated C4 ships would be highly useful to keep all the targetting data organised, precise and distributed to the combat ships. this also opens the gates for player made countermeasures. have an emitter randomly switch on and off to confuse the distance assesments of active sensors. throw out flares to confuse passive sensors. randomly toggle emitters distributed over the surface of you ship to obfuscate your position and velocity vector. edit: after posting i noticed a small gap in my explanations: sensors on their own dont provide pinpoint coordinates, the player has to process data in DPU's to get pinpoint data. the sensors directly only provide directions and emission strengths