1. This forum is obsolete and read-only. Feel free to contact us at support.keenswh.com

Space Engineers IMySensorBlock LastDetectedEntity

Discussion in 'Programming (In-game)' started by Deepflame, Apr 25, 2016.

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

    Deepflame Apprentice Engineer

    Messages:
    395
    Hi guys,

    As you are all aware, there's an exploit currently possible through the Sensor Blocks API via LastDetectedEntity. Since it returns a direct IMyEntity reference it is possible to do all kinds of fun, which may not be so fun for whoever is on the receiving end of it.

    This means we gotta fix it. So we have a couple of solutions, ranging from easy to do to far too much work. But before we do anything, I'd like to discuss with the community on what we should do to allow you guys to continue writing interesting non-malicious scripts, while disabling the ability to have malicious game breaking scripts.

    Right now, we're leaning towards returning a list of structs instead, which contains some metadata about all the detected entities in range. The struct would contain something like entity id, position, orientation, relationship to the sensor block's owner, and entity type (small grid, large grid, player, meteor, missile, etc).

    For ModAPI we will leave the LastDetectedEntity and probably add a list of DetectedEntities, since if you are installing a mod it's a decision on the server admin's part, and thus your choice, instead of being forced upon you by a malicious player.

    Unfortunately, this change would break vanilla scripts relying on LastDetectedEntity to do things. For some things we are fine with this, since the scripts were allowing things that are 'magic', like guided missiles that can follow a target from 500 kilometers away, but there are other scripts that are really cool that we would like to allow to remain functioning. (Radars for example)

    A more 'perfect' solution is to create proper sandboxed interfaces to entities that check for ownership on actions, check for communications range through antennas, proper memory release when entities get destroyed, etc. But this means a lot of changes we have to make in the interfaces and will take a large amount of time. This time is currently not available. :)

    So before making a decision we would like to gather some information from what you guys think is a good idea, and what kind of data we should consider adding to the struct to allow you guys to continue making awesome scripts.


    *edit*
    Based on the discussions these are the current proposed changes:

    struct MyDetectedEntityInfo:
    - Entity ID
    - Entity name
    - Entity type (small grid, large grid, meteor, asteroid, character)
    - Entity relationship to sensor block owner
    - Position
    - Orientation
    - Size
    - Time since detection (in seconds, compensated for simspeed)

    And IMySensorBlock will receive:
    // Adds all detected entities within sensor range to the list, clearing it out beforehand
    void GetDetectedEntities(List<MyDetectedEntityInfo> detectedEntityList, MyDetectedEntitySortOrder sortOrder = MyDetectedEntitySortOrder.NearestFirst);
    // For when you don't care what it is detecting, just if
    int NumberOfDetectedEntities;
    // Returns the newest detected entity information
    MyDetectedEntityInfo LastDetectedEntityInfo;

    Additionally, MyDetectedEntitySortOrder is an enum with the values:
    enum MyDetectedEntitySortOrder
    {
    NearestFirst = 0, // Distance ascending
    FurthestFirst, // Distance descending
    OldestFirst, // Time since detection descending
    NewestFirst, // Time since detection ascending
    }
     
    Last edited: Apr 26, 2016
    • Agree Agree x 8
    • Like Like x 1
  2. 4o

    4o Apprentice Engineer

    Messages:
    316
    my concern is getting a list of turrets from detected grid. this and object position, orientation and type covers all my current needs.
    make an interface layer for external grid blocks to prepare for upcomming official inter-grid communication? ;)
     
  3. Malware

    Malware Master Engineer

    Messages:
    9,867
    The PB needs to be properly sandboxed. I mean, LastDetectedEntity is not the only problem by far. Every block entity retrieved can be stored and exploited as well. In theory the proxies could be autogenerated, at least to a high degree.
     
    • Agree Agree x 4
  4. Deepflame

    Deepflame Apprentice Engineer

    Messages:
    395
    Right now though, we're dealing with the problem you can get access to remote grids without even connecting to them. Doing a fly-by is enough to mess them up. Especially harmful with longer-range sensor mods. :)

    List of turrets would probably not be added in there, that seems like an awfully specific thing, and sensors don't have a "Detect Turret" feature either.
     
  5. Malware

    Malware Master Engineer

    Messages:
    9,867
    Fair enough :) in which case metadata with type, location, eventual allegiance and even ship name would be good.

    It is my opinion anyway that if a change is needed that causes scripts to break, now is the time, while the game is still in Alpha.
     
    Last edited: Apr 25, 2016
    • Agree Agree x 4
  6. Rdav

    Rdav Apprentice Engineer

    Messages:
    117
    Looks like whatever the scenario I'm going to have to do some reworking of my scripts!
    And I agree with Malware, I'd rather have things break now before I or anyone else gets further down the line,
    I'll try to contribute the best I can with my limited knowledge of c#,
    Any approach would be good I'd think, Ideally I would want something using the RadioAntennae, 50m from the sensor is, even in an ideal world, too small for any purposeful practical application, have you guys considered upping sensor ranges using a volumetric approach for the sensor, rather than distance in every axis?

    For example a sensor maxed out at 50m in every direction currently scans 125000m^3 of space per tick but only 50m away from the ship,
    A sensor on a rotating rotor with a height of 100m, width of 1m and distance of 1250m would (I presume) have exactly the same performance impact (same volume of space scanned), but be able to scan 1250m from the ship, which would have much better practical application for long range detection and guidance without getting ridiculous.

    Really anything is better than nothing, the only other way of getting locations is using GetFreeDestination() which is ludicrously performance intensive, and notably unreliable, anything more than 10 calls a tick will cripple your game, potentially I could go into a server, start a script running it 100 times a tick and instantly reduce sim-speed to 0.01.

    The only reason I personally use a reference to the entity is because there is no performance friendly way I can currently detect an object at range. It doesn't even have to be detected, perhaps a (quick?) solution would be to give us a function that can send out in a vector (Like GFD()) but then return the point at which the vector is stopped or 'collides' with an object, to allow people to programme a radar using the in-game API? anything is better than nothing!
     
    Last edited: Apr 25, 2016
    • Agree Agree x 3
  7. mze9412

    mze9412 Junior Engineer

    Messages:
    791
    I would also prefer that scripts break now instead of breaking them later. As long as the game is early access, break whatever is necessary to properly sandbox the PB.

    @Deepflame
    Also a question: Is it intentional that GetFreeDestination is usable in the PB? It easily messes up sim speed and makes long range detection almost too easy (especially compared with the sensor block, which only does 50m) o_O
     
    • Agree Agree x 2
  8. mexmer

    mexmer Senior Engineer

    Messages:
    1,977
    @Deepflame until proper sandboxing is done struct with all kind of required info should be sufficient

    if we can go furthet, either get for example last 10 detected entities or last X entities in fixed timeframe (5 sec ???)

    we can discuss how much of properties should be sufficient and for what kind of entity for me guess would be following

    Entitity struct
    Type : eg. large grid/small grid/player/rock(asteroid)/stone(meteor)/did i forgot something?
    Relation: friendly/neutral/enemy
    Name:
    Position:
    Direction: eg. direction in which entity is/was moving
    Speed:
    Detection time:
    Detected: eg. flag if entity still in sensor range, or left sensor range (we want to know, that it's still lurking around)

    probly people want more info
     
    • Agree Agree x 2
  9. K4tniss

    K4tniss Trainee Engineer

    Messages:
    20
    Brand new account!

    I agree with the others that the sooner it breaks, the better ^^
    Two things @mexmer:
    A) doesn't velocity also contain direction and speed?
    B) is there any reason to do past entities? It would seem to me that you could argue that list longer infinitely. Currently detected enemies would solve that issue and because you can trigger pbs from the sensor I imagine that covers it.

    The only other thing I'd like to suggest for discussion is a general size of the object? I'm thinking of radar. We have type on that list, but something like the diameter of the widest point might also be useful. It might also help with rudimentary collision avoidance.
    Thoughts?
     
  10. mexmer

    mexmer Senior Engineer

    Messages:
    1,977
    While you have point with sensor trigger actions, problem is, that you can have multiple entities entering sensor range, but they don't necessarily needs to leave in same order.
    Especially for person detection sensor (defensive grid) some history is needed, and you can't unformatunately make realiable history with on/off trigger as it is now. with current implementation detected entity is replaced everytime anything enters/leaves range, but sensor doesn't keep track of what entered/left range so you can easily manipulate sensor to believe, there is nothing in detect range, and even if object leaves detect range after "undetect" action is not triggered. current design doesn't work properly for defense grids, even if you write own logic around ondetect/onleave

    as for velocity, not sure what exactly it contains, since i don't even know, you can obtain it directly.
     
  11. K4tniss

    K4tniss Trainee Engineer

    Messages:
    20
    @mexmer the proposed is a list of all entities currently detected, not just one, so I fail to see how the current situation applies. Run a pb once a second + see how the list has changed, and/or run it when the state changes, although I agree this isn't a perfect solution.

    Velocity is a vector that by definition is the speed and direction of an object

    Edit: my understanding is that direction is just velocity normalized, if that helps you at all
     
    Last edited: Apr 25, 2016
  12. 4o

    4o Apprentice Engineer

    Messages:
    316
    got it. then i want "target weapons" switch along with HasTarget property on a turret:) i'm here for a bargain:)

    that was wining in fact. to be serious, right now we can use GetFreeDestination() on RC to get both position and velocity. i don't see any reason to get any entity info from sensor. after all, sensor just measures distance. i'd say we are good with just IsActive on sensor as long as we have inter-grid communication and GetFreeDestination() will be available forever:)
     
    Last edited: Apr 25, 2016
  13. mze9412

    mze9412 Junior Engineer

    Messages:
    791
    Get rid of "GetFreeDestination". Is is way too powerful for ingame scripting. A replacement with limited range and on a special block, like a radar/sensor block, would be much better than the (in my opionion) broken GetFreeDestination method.
     
    • Agree Agree x 3
  14. mexmer

    mexmer Senior Engineer

    Messages:
    1,977
    PB is not ModAPI, it's level higher.

    as for direction, i meant where entity faces, since it can have 0 speed, not sure if zero velocity still has direction vector - that's why i did split it into 2 fields - speed and direction - tho' now when i think about it, object might move to side, and facing other direction ... so velocity and direction?
     
  15. K4tniss

    K4tniss Trainee Engineer

    Messages:
    20
    @mexmer

    Additionally, how do things in this game point at anything without moving? It's space. We can't determine grid orientation since cockpits cam face any direction, and anything like meteors and missiles will always move in the relevant direction.
     
  16. Innoble

    Innoble Apprentice Engineer

    Messages:
    238
    At a risk of derailing the thread (which was about the sensor, not GFD):

    You're correct in some cases. My GFD scanning technique uses only 3 calls per tick and can scan the whole server and track dozens of objects at once. It only causes much load when there are many objects (because each GFD call will then cause more load, not because there are more calls made). On a busy server, you can simply set it to short range and solve any performance problems. It can easily be abused to crash a server yes, but anyone wanting to crash a server can do it in other ways, with a PB. You don't need GFD for that.

    The real issue with GFD, is that it gives an unfair advantage. I think we just need something that can "see" as well as a player can, not better. GFD should be limited to draw distance. That will help with performance as well. So if you set a server to see up to 10 km. Then do the same for GFD. Another thing that can be done is to limit the number of calls of GFD per sim tick.

    Scripts using Getfreedestination are very hard to adapt for most people unless they are just using an identical copy of someone else's script. Using the sensor is pretty easy. We need an easy to use block as well. So you can't view GFD as an alternative to the sensor.

    Personally I think we need a block that only scans for whole grids and asteroids, not individual blocks and voxels. That would make it far less performance intensive and it could have a much larger range. Call it a "long-range" sensor. That's what GFD does, basically. However, I think GFD is extremely inefficiƫnt at this. The server already has a list of every object. Just make a block that can access it if the objects are within a certain range. That's much better than sending beams everywhere and using computation power.

    I really hope we get an alternative to long distance scanning/tracking before things get removed. For some of us, a lot of the fun is in designing things that work over long distances.
     
  17. Dawnkeeper

    Dawnkeeper Apprentice Engineer

    Messages:
    260
    I also agree with breaking things now instead of later.

    The info I would like to get:

    • Long range info: just position and type of the grid. Bounding sphere or something to estimate the size of the grid would be nice. As well as an ID for tracking.

    • Short range info: additionally info on grid composition( i.e. where on the grid blocks are, not necessarily their type), relation to player. If the blocks are connected via antenna perhaps even more (think Docking Port Alignment indicator for SE)

    As for range I would be happy to get rough info at 1 to 2 km. Getting the short range info at 200 to 300 m would be enough for my scripts.
     
    • Agree Agree x 1
  18. Me 10 Jin

    Me 10 Jin Apprentice Engineer

    Messages:
    463
    A list of structs to hold pertinent data about objects seems appropriate for the sensor block. You could even use that technique for antennas and ore detectors to give scripts access to signals in range and nearby ores, respectively.
     
  19. sepen_

    sepen_ Trainee Engineer

    Messages:
    52
    Thanks for asking.

    I'd like to point out that https://forum.keenswh.com/posts/1286843061 is impossible without keeping a reference alive!

    This is not per se tied into LastDetectedEntity, instead real cross-grid communication is the substitute. Automation and drone-control provide for countless hours of interesting gameplay. Unless removed completely with this 'fix'.

    By all means change the sensor, but we require something to directly control owned grids.

    Cheers.
     
    Last edited: Apr 26, 2016
    • Agree Agree x 5
  20. tyrsis

    tyrsis Junior Engineer

    Messages:
    862
    Cross grid comm should just be data transfer between ships that are connected via antenna (ie send/recv). No references required.
     
    • Agree Agree x 5
    • Disagree Disagree x 1
  21. sepen_

    sepen_ Trainee Engineer

    Messages:
    52
    Why? Why shouldn't I open a door, fire a thruster, toggle a drill, or reprogram the auto-pilot on a drone I own with a clean call?

    Sure, I can write to an LCD that is polled every tick on 50 drones, parsed, and acted on or not by 50 additional PBs - or I'd have a block, let's call it Remote Control, that let's me act on its grid and its behalf.

    I don't want a reference, I want the means!
     
  22. tyrsis

    tyrsis Junior Engineer

    Messages:
    862
    Time. This is all based on time. Something like this would require a lot of time, and basically requires everything to be sandboxed. Once that sandboxing is complete then maybe a clean method of doing remote calls can be looked at.

    This is a means that can be done in the short term that gets what you want. You write code around the fact that a ship can talk to another ship. This method doesn't require space magic to work (ie: references). Suggest something other than that, that doesn't require a complete rewrite of the PB.
     
    Last edited: Apr 26, 2016
  23. sepen_

    sepen_ Trainee Engineer

    Messages:
    52
    I very much doubt that. Fix the sensor, hand me entry points to my grids, done. I'll be interested to see what Keen settles on.

    Oh yes, the Ancient Space Magic of Radio Transmissions. We can fly ships remotely, but BEWARE of the lore-breaking implications of someone switching on the on-board coffee maker.

    I remind you that the references working is status quo.

    Since you, personally, are arguing time: Leave it in. Enhances gameplay by a thousand. If there's time enough to fix: Do it right. Keep the good stuff working.
     
    • Agree Agree x 2
    • Disagree Disagree x 1
    • Funny Funny x 1
  24. longbowrocks

    longbowrocks Trainee Engineer

    Messages:
    15
    While I agree, I think it's more precise to say we're practically banging rocks together with this crippled sonar, when we should have an interface to grids detected by antennas.

    We already have antennas to find ships at long range through the UI, but GFD is a completely different animal. There could be a debris field blocking its view, there could be an asteroid near your target so we skip scanning that area, the target might just be out of range.

    On the flip side, as you mentioned, GFD can detect grids that players can't if someone happens to turn off their antenna. Sure, decrease its range if you like. The caveats so heavily outweigh the advantages that I'd prefer to use it only for its original purpose anyway.

    Antennas on the other hand can see exactly what a player can see. No more, and no less. In fact, the information many of us want is already provided from them via the UI: how many grids can I see, where are they, and who owns them?
     
    • Agree Agree x 2
  25. K4tniss

    K4tniss Trainee Engineer

    Messages:
    20
    We're not here to discuss the reference issue. We're here to discuss sensors, and how the sensor API should change to prevent exploitation. There are at least two other methods of obtaining references if you should desire to continue to exploit that. I'd be interested to hear what information you'd like from the sensor, since you seem to be in favor of the amount of information you can gain from references.
     
  26. Arcturus

    Arcturus Senior Engineer

    Messages:
    1,649
    Is this also the reason why we can't "GetTarget" on a turret?

    People currently seem to use LastDetectedEntity to:
    - Communicate outside antenna range between grids, since small ship antennas have such a short range, and pass back collected data
    - Apparently "mess up" other peoples grids, though I haven't heard of exactly what can be done
    - Sort through the list of functional blocks on the other grid to identify priority targets (turrets) vs decoys/junk, and manually SetTarget your own turrets to shoot more smartly.
    - Get the position of the detected object.
    - Determine the type of detected object, if the sensor had broad criteria.

    There is also heavy use (abuse?) of the autopilot's GetFreeDestination function to scan space like a radar and do radar-guided missile things. This is probably connected to various radar/laser rangefinder suggestions.
     
    • Agree Agree x 1
  27. DrChocolate

    DrChocolate Trainee Engineer

    Messages:
    15
    I have to agree with @tyrsis, @mexmer, and @mze9412 - err to the side of safety, and open more data / references back up later once proper sandboxing is in place. Server admins want to allow people to use PBs, but as long as they're exploitable we can't.
     
  28. 4o

    4o Apprentice Engineer

    Messages:
    316
    i remembered. i want a distance to object. that is my narrow request. had to use 4 sensors to make a ship, that hovers above planet surface. that would be more elegant with 1 sensor if distance was available.
    someone would argue, that a list of entities and their position covers that? don't think so (i do know i might be wrong, but). now if sensor detects planet (or any) voxel, it gives its position... 600 m away. no useful info on collision avoidance, because my ship was 10m from surface.
    so. i need distance. at least to closest entity. a list of distances and object type would be perfect.
     
  29. tyrsis

    tyrsis Junior Engineer

    Messages:
    862
    I'm not the one arguing time, Keen has said time and time again that time is the limiting factor in all this. Sensor references are going away, that is a for sure thing. I merely suggested something that would be safe and very easy to implement in lieu of a long term solution. Anyways, this isn't really what's being discussed here, and what others have said are what I agree with. Short term: list objects a sensor can see wrapped in a struct with values most scripts require. Long term: sandbox entities safely.
     
  30. 4o

    4o Apprentice Engineer

    Messages:
    316
    why are we saying, that scripts will not work without sensor LDE? connect a grid, get reference, detach grid => same result.
     
Thread Status:
This last post in this thread was made more than 31 days old.