Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Space Engineers Ingame API Feature Requests

Discussion in 'Programming (In-game)' started by rexxar, Oct 10, 2017.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. rexxar Senior Engineer

    Messages:
    1,530
    I know you guys have a million feature requests for the PB, so give them to me!

    Be aware that the PB is limited by design. You probably won't get access to System classes.
     
  2. Ronin1973 Master Engineer

    Messages:
    4,800
    I have some feature requests for the PB; mostly concerning data available to NPCs/Space Pirates.

    Currently we can access methods like GetNearestPlayer for blocks owned by NPCs.
    I'd like some more features included.

    GetNearestPlayerID gives the ID of the player as text.

    I'd also like to see a general storage string for each player that the NPC controlled PB can set/get that's attached to the information stored about the player. Much like we have a storage variable for each PB. Data could be written to this file however seen fit. This could be global information about the player. For example, the PB could be set up to detect damage in a drone/cargo ship and if a player is within a specific range of the ship, data could be written that other drones could access. This would allow NPCs to store a disposition towards the player. This is just one example of how the storage string could be used.

    Additional storage strings could be available as well if warranted. So the first could be used for one person, the second for another. Maybe have ten generic strings that could be called (PlayerStorage01, PlayerStorage02,etc.)

    A second string could be used to mark a coordinate and timestamp where a player was last seen (as another example). This would allow for drones/ships that are nearby to use those coordinates to join in an attack or avoid a hostile area. Again, just an example of what could be done.

    Care would have to be taken by anyone using the string that every PB accessing it conforms to the same standards. But that's the concern of the person setting up the game world.

    Being able to develop NPCs that have some sort of collective intelligence... awesome.
     
  3. gothosan Junior Engineer

    Messages:
    723
    increase the character limit and ignore newlines, white space and comments.
    There's an OS script I'm working on for ages and the character limit is always the problem.
    I want to practice good, readable code for both myself and others so either an increase or (not likely soon but hope to) complete removal of character limit in code.
    I assume that around 1,000,000 to 10,000,000 characters should be enough for my OS script.
     
  4. Arcturus Senior Engineer

    Messages:
    1,649
    Have IMyOreDetector return struct info giving the same info that the player has access to - an ore type and a location, plus a timestamp.
     
    • Agree Agree x 7
  5. Jon Turpin Apprentice Engineer

    Messages:
    162
    Access to the inertia calculations for a grid. As we dont have access to armor blocks to get any accurate figures, just a simple struct that contains the already calculated MoI and tensor data would be lovely!
     
  6. Ronin1973 Master Engineer

    Messages:
    4,800
    I like the idea, but a time stamp is unnecessary as far as a feature. You can query the host machine already for a time stamp at the same time you query for anything else.

    I'd expand upon the idea that any active antennae, beacon, or ore detector that pops up a coordinate on the GUI can have their GPS coordinates queries as well as the text of the message: the ore being detected, or the broadcast names of the beacon or antennae. This data will be given whether friendly, owned, neutral, or enemy.

    With the advent of RDAV's fleet management, being able to lock on to an active antennae would be a great counter. Beacons could be used as mobile indicators of a mother ship, its orientation, and possibly a pathing guide without extensive communication between two entities. Small ships have a maximum range of 5,000 meters via the antennae. However, the beacon could be used to send out ships to far reaches, out of communication range and allow them to return to wherever the mothership is. They could also work semi-autonomously with some clever manipulations of the names of beacons/antennaes. Example: a remote miner that can work outside of antennae range and still find its way back to the mothership.
     
  7. Arcturus Senior Engineer

    Messages:
    1,649
    I figured, like the sensor's detected entity info, the PB would query the data an unknown amount of time after it was recorded. I thought they wouldn't want to allow the PB to force the ore detector to do an instantaneous check, because like camera raycasts it interacts with the world. Spamming a 150m radius detection sphere might be bad.

    My proposed method saves the normal scan results for PB use, so you are not doing additional ore checks of the world. Because the ore detector triggers on UpdateBeforeSimulation100, the results could be 1.6 seconds old. A PB script could compare the last observed timestamp to the most recent timestamp to see if new data was recorded.
     
  8. Pharap Apprentice Engineer

    Messages:
    175
    The timestamp has a good reason to be on the detected entity info though: ships move.
    Ore veins tend to stay put so a timestamp is of little value if the exact position of the ore vein is available.

    Thank you for suggesting adding the OreDetector API though, I've been wanting that for ages.
    I'll finally be able to start on my long-range prospecting drones.
     
    • Agree Agree x 1
  9. Ronin1973 Master Engineer

    Messages:
    4,800

    Exactly. The marker that pops up on the GUI is a general location and not exact. My thoughts are that anything that pops up on the GUI and is followed around by a flag of some kind (antenna, beacon, etc.) should be available to the PB to read the coordinates, name, and type of marker. In order to get the marker on to the GUI, the GPS coordinates have to be known and available. So just let the PB read those coordinates. It shouldn't be any additional overhead since the game is already pulling this information.
     
    • Agree Agree x 1
  10. Pharap Apprentice Engineer

    Messages:
    175
    Hrm... that sort of makes me think maybe it should be possible to get a bounding sphere containing the entire ore vein.

    Size-wise it would be cheap because all that has to be added is a radius (float or double), but I don't know how expensive it would be to calculate the sphere in the first place (I've never managed to figure out how to use the ore API).
     
  11. Ronin1973 Master Engineer

    Messages:
    4,800

    I think it all depends on each ore type and the proximity to the detector. Depending on your detector's relationship to the vein(s) of ore, the markers will change place. So I don't think there's any way to exactly scan the dimensions of a vein. I would note the coordinates and then send in a miner to excavate the area around the GPS location (like a 20x20x20 meter cube). Once that task is complete, I would rescan the area for a new signal and repeat the process until there's no detectable trace of the ore left.

    Trying to continuously update the location would lead to your miner freaking out. Every time you move the GPS location might change.
     
  12. Pharap Apprentice Engineer

    Messages:
    175
    It depends how it's represented in the code.
    It's quite possible that there would be.

    If you're going to scan once before mining and then once again after mining a vein it won't matter if the markers move during the meantime because you're only scanning twice.

    If the miner ships are unmanned and ore detectors could detect a sphere around the ore vein you might as well fit the miner ships with an ore detector and make them scan after receiving a certain amount of ore. That way you could check you haven't missed any and they wouldn't be freaking out because they'd only be scanning periodically instead of every time they try to mine.
     
  13. Ronin1973 Master Engineer

    Messages:
    4,800

    Well, I'm sticking to how the ore detector currently works and how it locates ore. Being able to draw a bounding box around entire ore veins would be very difficult. The dimensions of that box would all have to be calculated, stored, and available for retrieval by the programmable block. I don't see the change in functionality happening. Being able to access the data that's being given to the HUD would be easier for the developers to pull off and would be enough information to do a reasonably good enough job to automate mining based on ore detector feedback. The fewer changes the devs have to make to the game, the more likely the feature is to be incorporated.
     
  14. GrindyGears Senior Engineer

    Messages:
    1,787
    Im not sure if this is quite the right place, but i would like to see the alt functions of tools opened up to both terminal and PB i suppose. My main one would be to get right click mining be an on/off much the same as the regular mining is. This means parts of mining can be more automated so you dont have to sit around holding right click.
     
    • Agree Agree x 3
  15. hellokeith Apprentice Engineer

    Messages:
    335
    Throwing in requests from a previous thread on this. Some may already be possible

    * gravity detection - from gyroscope for natural gravity, and perhaps from gravity generator for artificial gravity, or just both from gyro

    *** out of bounds detection (limited size map/world) - from flight seat? unsure there is a suitable block, but this is needed

    * target detection - from turret, everything it knows about a target should be available and easily readable

    * ore detection - from ore detector, already mentioned

    * antenna & beacon detection - from antenna, already mentioned

    * universal time - from timer block, gives a universal time, server uptime, and perhaps sim speed

    * celestial body type detection - from camera raycast or from laser antenna raycast, tells you specifically asteroid/earth/moon/mars/etc. by light measurement against atmosphere

    * sun position detection - from camera, if within its view angle

    * power overload detection - from reactor?

    * being targeted by enemy turret detection - from camera?

    * temporal thrust, instead of having to manipulate thruster override - from thrusters
     
  16. Pharap Apprentice Engineer

    Messages:
    175
    You can get both of those from IMyShipController (e.g. a flight seat or a remote control block).

    See:
    Sandbox.ModAPI.Ingame.IMyShipController
    Vector3D GetArtificialGravity();
    Vector3D GetNaturalGravity();
    Vector3D GetTotalGravity();

    Asteroid vs planet I believe is possible, but I think detecting the type of planet might be more difficult.
    I've done the former before in one of my unpublished mods, but the latter I've never seen done (doesn't mean it isn't possible, I've just not seen any evidence to suggest either way).

    That's already technically possible with a script that monitors the power usage of every block, but I guess it could be made easier.


    I agree most with ore detection, antenna/beacon detection, universal time and maybe out of bounds detection. The rest I am pretty ambivalent about.
     
  17. Ronin1973 Master Engineer

    Messages:
    4,800
    @Malware had an interesting quote about the programmable block. It's a philosophy. He basically stated that if the player can do it, then the PB should be able to replicate that behavior (of course within security limits).

    I can fly directly towards a marker in the game: GPS coordinate marker, ore detector markers, antennas and beacons. So allowing the PB to access those coordinates when they are on the screen (basically a bool) will allow the PB more autonomy. A miner that can fly over voxels and detect the coordinates of ore veins, then mine them with a higher degree of success... I'm all for that. Being able to use beacons and antennas that are active and in range as a reference... absolutely.
     
    • Agree Agree x 1
  18. Rdav Apprentice Engineer

    Messages:
    117
    I know it's been said before but:

    Some godamn way of detecting things via antenna, or turrets vs using hacky ways to scan using raycast.
    This is a big one for me, the raycast is painfully slow, and also in the grand scheme of things relatively useless in low sim speed or multiplayer enviroments.
    Proper access to antenna information means we can create more effective, recourse finding techniques, collision avoidance, and general QOL scripts, along with allowing more performance optimization for some more advanced stuff.

    And (for the sake of the hundreds of people that ask me) access to jump drives.

    Lastly if 1) is not an option, a way of retrieving detected grids from turrets.
     
    • Agree Agree x 1
  19. Pharap Apprentice Engineer

    Messages:
    175
    I partially agree, but it depends on the list of things it can detect.
    It would have to have some limitations like only detecting friendly and neutral signals and being unable to detect things that don't send signals (e.g. asteroids, ships without beacons or antennae).

    Also it can't make sensors completely inferior, the two should have different purposes.

    That's because raycasting is expensive.
    If you removed the usage cap you'd have loads of people complaining about lag.

    This one I agree with.
    I've been working on a mod to facilitate it.
     
  20. Rdav Apprentice Engineer

    Messages:
    117
    I meant slow more as in slow on performance, But it is true that scanning with them is slow too.
    To achieve anything useful with raycast scanning/locks requires ten times more performance than retrieving this information via other inbuilt means.
    And the way that raycast works encourages spam of rays(and cameras!), ergo lagging things out more.
    If I'm honest I want to do away with raycasting in favour of antenna-detection altogether. I seriously dislike raycasts, it makes to no real-world parallel so it's existence in the game breaks a lot of immersion for me.

    Source: made a mod retrieving antenna range objects performance was petit and things were super smooth, tried raycasts, lagged the shit out of the world.
     
    • Agree Agree x 1
  21. masterfail #yolo Trainee Engineer

    Messages:
    12
    For me it would definitely be 3 things

    1: a way for a script to detect a grid without the use of cameras. Of course it would require a radar BUT some radar mods already exists and stuff like cheetah radar are really well balanced and offer a lot of gameplay. Alternatively, directly add similar functions to the base antenna.

    2: acess to order detector Data. This one is a no brainier, it already shows out some coordinates of minerals patches,, why not let a script use them as well?

    3:jump drive acess. While I is a bit more complex balance side I think linking it to a focus system like the camera charge system for raycast would balance it well.
     
    Last edited: Oct 18, 2017
    • Agree Agree x 1
  22. Pharap Apprentice Engineer

    Messages:
    175
    Sensors can detect grids too. Just saying.
    They're not suitable for larger distances when they're always on though.
    A variation with a larger range that have a cooldown would be alright though.

    Depends what they're being used for. They're not designed for large scale ship navigation beyond discovering the dimensions of distant asteroids.

    Some real world cameras can do depth detection, like Microsoft's Kinect and similar technologies.
    They produce depth maps like this:

    [​IMG]

    From which 3D shapes can be extrapolated.
     
  23. Rdav Apprentice Engineer

    Messages:
    117
    Agreed, the raycast function as implemented is genuinely only viably used for rangefinding, which in my opinion, all things considered is pretty useless in most applications.
    Distant asteroids that we can see by eye, or by zooming in with the camera, by eye, and size we can gauge pretty easily... by eye.

    And use for anything apart from that induces the terrible terrible lags, but people will always want/need/really like, ways of detecting large grid ships, navigation and general environmental awareness, so people have made do with what they have got, as at the moment they are our only option.

    The depth perception laser scanning is the closest thing to the raycast, but those rays in real life are run on the rates of millions per second for pictures from a usually very small single camera, why in the future would this technology have reverted to a rate a fraction of this?
    I think the point I'm trying to make is, out of all the techologies we bring to space with us, why over a (vastly more useful) radar system, have we chosen a technology primarily used to do rangefinding and large scale geological survey maps to gather 3D data? (which we can't use for anything as 3D LCD display is you guessed it.. laggy as hell)
    It's inclusion over more useful and common technologies is mostly what I find immersion breaking, combined with the amount of information that the single laser ray can return.
     
    • Agree Agree x 1
  24. masterfail #yolo Trainee Engineer

    Messages:
    12
    Yup, short answer: give us radar.

    I mean it would solve so much problems with scrips and detection in general. Just, for the sake of players who dont script, allow the info found to be showed on the UDH the same way ore detector Data can
     
    • Agree Agree x 1
  25. Milord Trainee Engineer

    Messages:
    12
    Support for all of the ideas regarding raycasting, grid & voxel detection and overral ability of pb to "see" the world around them.

    By the way, how do I get my name changed?
     
    • Like Like x 2
  26. Pharap Apprentice Engineer

    Messages:
    175
    It's useless for large scale navigation, but for stuff like automated landing it can be handy.

    Do sensors suddenly not exist?
    I'm really getting the impression nobody here realises sensors can detect ships.

    I agree it's useless if you're attempting to use it to scout an asteroid manually, but if you're planning to send a drone or just log various asteroids then it can be handy.

    I agree its uses are limited but it does have uses so it's worth keeping.

    Real world limitations trump in-world limitations.

    If you're talking about immersion though, I'd be more concerned with why astronauts don't need to eat or why when they die they can magically respawn.

    My answer to that would be displaylists like what the Wiremod mod for Garry's Mod uses.
    So that's sort of fixable but it would mean introducing a new kind of screen and lots of programming, which again I can't see Keen agreeing to. It could be a mod though.

    Depending on the caveats I agree with this.
    Most importantly it can't work like the sensor system, it would have to operate differently.
     
  27. Rdav Apprentice Engineer

    Messages:
    117
    Sensors are fun.. but are very short sighted, 50m is pretty useless for most applications off your own ship, which is mostly what I'm talking about.

    My biggest issue with it is that it breaks the fourth wall by giving information no real-world counterpart could give, but at the same time being less advanced?
    Food and drink are trivial, and are different in that they are something that *isnt* in the game, as opposed to something that is in the game.

    My main point is, raycast can't do anything properly implemented radar could do so, *so* much better, at a fraction of the performance cost. ergo it's a personal pet peeve.
     
    • Agree Agree x 1
  28. masterfail #yolo Trainee Engineer

    Messages:
    12
    Raycast can be very usefull in narrow situations. But the thing is that it is poorly designed at replacing what it replaced, the GFD method.

    Sensors are unable to detect anything above 50m, meaning they are nothing but useless to detect anything other than maybe players inside a ship or an asteroid for a slow moving drone. Sensors and lidar simply avoid the problem. The problem is that scripts (and players!) Lack the ability to see what is beyond 50m from them (and I will never count mods in this, a game should always be self sufficient no matter how talented the playerbase is). Any options we have to see further than that is a turret, which dosen't actually give any target resolution or information about what it has detected, and the lidar, which is useless unless someone actively point at something, which defeat the purpose entirely. This is why a radar is needed. And I know this is not the topic here, but I'll explain how it ties into scripts later

    The radar would be an extremely good compromise between being a long range (perhaps way above 50km), allowing a lot more depth in gameplay, and also be balanced. Let me explain.

    The radar (or antenna in radar mode) would use 4 different types of modes to detect grids and objects.

    The first is the most straight forward, and the most powerful at hunting silent ships, it's the active radar mode. In this mode the radar sends waves of electromagnetic waves and analyse the noise it get back. Ships are analysed based on their block count (including docked grids) and type (large or small, also include docked grids). The maximum block detection at maximum range (around 4000 blocks) stays constant no matter the range, and the detection follows a logarithmic pattern, with detected limit becoming smaller as the object approaches. However, a radar in this mode is also be emmitting a shitload amount of em waves, making it visible across the entire range bubble. Finaly, it is the most power hungry mode of all. And to balance it out, decoys can be used to reduce the distance at which you get detected. Any radar in the area will be able to pinpoint your location so be extremely careful.

    But let's say you want a more sneaky approach, then the system got you covered. The rest of the modes are called "silent", because they do not actively emit energy into space, thus making the radar invisible. However, that does mean you won't see someone that tries to stay silent, at least as long as the other sensors do not detect anything.

    The first sensors is the chemical sensor. It will try to detect the chemical signatures linked to the use of nuclear reactors. And grid with a lot of reactors working actively will be detectable from quite far, with each fully operating large grid large reactor being detected an additional 50km from the radar. But batteries, solar panels, or Inactive reactors do not produce any chemicals, hence being completely invisible to this sensor.

    The gravimetric sensor is the final one on the list. It tires to detect the disturbances in gravity patterns caused by very late objects, gravity generators and mass blocks. This sensor will be primarely used to detect asteroids and planets. However, it can also detect the presence of very heavy grids or grids which use powerfull warp drives. If the ship is VERY heavy, it will be able of detect the grid before any other sensor. However, this sensor is incapable of identification of a grid and a space potato near it. So any grid linked to voxel will be invisible from this sensor.


    But how does all that ties to the scripts. Well this solves the problem of detection while allowing clever engineering to find holes in this system. Active radar is mostly usable to hunt, either to find someone who is hiding or to use as a guidance for drones or projectiles. The chemical sensor is great to detect big stations in operation or ships using a lot of power. Finally, the gravimetric sensor is a very good way of gaining information on asteroids and planets while also allowing the detection of heavy vessels or ones that would use very big warpdrives.

    But unlike a modded sensor you can play agaisnt them. If you bulild a light ship that is reasonably small, with a lot of decoys and mostly powered by batteries then you will be able to sneak past most radar defences. It helps industral scrips, early warning scrips, missiles, drones, and most importantly, it helps players find stuff in deep space.
     
  29. Pharap Apprentice Engineer

    Messages:
    175
    There's a reason for the cap. Set it too high and they can't actually function properly.
    It works fine for 500m but if you set it to 5000m the whole game slows to unbearable speeds because it's trying to detect which objects are in range every few ticks.

    If there's going to be a 'radar' block then it has to function differently to how sensors function.

    What would the specification be of the radar?
    How, in code terms, would it behave?
    Which classes would it use?
     
  30. Rdav Apprentice Engineer

    Messages:
    117
    *shrugs* That's for the devs to decide on the best way, they of all people know their own code the best, although I know for a fact through my own adventures into the world of modding and the mods of others that well built-in radar functionality is barely a smidgem on performance, while at the same time adding reams of functionality.
    My own method comprised of creating a dictionary of entities, with logs to distance, updated relatively infrequently, if called an antenna could lookup all entities in range and get some basic info on them, simple and cheap, yet a million times faster than rayscanning space, or checking every 1m square for an object (like the sensor does).
     
    • Agree Agree x 1
Thread Status:
This last post in this thread was made more than 31 days old.