Jump to content


Alpha Team Vanguard
  • Posts

  • Joined

  • Last visited

Everything posted by Cornflakes

  1. 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)
  2. 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
  3. 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.
  4. 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!" ....
  5. Take any adroid device, install droidpad, profit ¯\_(ツ)_/¯
  6. 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
  7. 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
  8. 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
  9. 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!"
  10. 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.
  11. Cornflakes

    Sensors 2.0

    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.
  12. Cornflakes

    Sensors 2.0

    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/.
  13. Cornflakes

    Sensors 2.0

    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
  14. ich bin doch kein preuße! (im no prussian!) daheim im großartigen Kaiserreich Österreich! (im at home in the great Austrian Empire!) 'd surely be fun having a few people to talk in a language thats a bit easier on the tongue
  15. practicality, fuel consumption, terrible TWR, "putting all your eggs in one basket" .....
  16. still.... why use a weird ruleset around "power cores" and "200% power" instead of just "this generator produces 15megawatt" and "this cannon needs 5 megawatt"? KISS
  17. but it matters a whole lot if you want the city to float in the atmosphere
  18. I havent yet seen anyone else using that joke, only myself a couple of times thats fine, that doesnt make it the only playstyle that should even be considered valid I never said "everyone". What im thinking about is that small-ish groups at least get a chance to react when something happens. Like 10-20 people that build a small ish something out in the wild. They shouldnt be casually curbstompable without them having time to even try to fight back. I dont say that the protection should enable to prevent the impending doom, it should just delay it long enough that they can get back to their computers and do something about the apocalypse.
  19. you just failed the turing test. who said everyone? who said that it could work without setup time in a moving object? you could /read/ what other people write for a start. hard limits on where and when the protection is usable at all. setup times, recharge times, whatever. but the point is to level the playing ground between people in different time zones. being concentrated in a specific region of the real life world shouldnt produce an inherent disadvantage against groups who are localised in other areas. if theres a bunch of eurodudes they shouldnt lose against a bunch of murika dudes just because the US dudes are awake (and can organise /something/) during the euro play time and the US can play when all the euro gamers are asleep. and what do reinforcement timers have to do with system transition queues?
  20. absolutely, hence why i'd say its hard limited as to how and when you can use that invulnerability to prevent the aforementioned exploits. time limits, traversal limits, other drawbacks you have to take for using the system.
  21. sooooo... its their fault for having a life besides the game? (or for making a corp with only RL friends, or similar craziness....) sounds like fair game design
  22. so you say you explicitly dont want to play fair game by outsmarting them or anything but by abusing their real-life limitations and attack them when they cant fight back?
  • Create New...