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.

PB Sensor Feature Suggestions

Discussion in 'Programming (In-game)' started by rexxar, Dec 11, 2016.

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

    Messages:
    1,713
    CustomData synced every time it changed, that's why.
    Rexxar wanted to make better storage for PB.(Which also will be allowed to change from one PB to another, but only PB can use it, so....no sync)
     
  2. Malware Master Engineer

    Messages:
    9,602
    I am aware of all this, but my point stands. And that storage isn't here yet.
     
  3. haximodor92 Trainee Engineer

    Messages:
    39
    I’m barely know anything about PB. But I hope this is great for automatic production:

    Use PB to send command to assembly to product components.
     
    • Agree Agree x 2
  4. Malware Master Engineer

    Messages:
    9,602
    This thread is about sensoring features only.
     
  5. Wicorel Senior Engineer

    Messages:
    1,242
    Antenna
    Info about detected antennas in range (the info that is shown to user in hud)

    world coords
    Name
    (friendly, enemy, etc)
    Antenna/Beacon
    TimeStamp?



    Maybe 'fuzz' the exact coords with range. +/- 10000 at max range. 'Close' <2000m would be 'exact' coords.


    Welder/Grinder
    MyDetectedEntityInfo for grid(s?) in range (ignore self) Only detects grid entities


    Drill
    MyDetectedEntityInfo for voxel(s?) in range. Only detects Voxel entities


    Turrets
    Mode: Automatic Player controlled (IsOccupied?), and add: Manual


    LastDetectedEntity

    Limit 'scan' range to the firing range of the turret


    Add RayCast. Maybe limit range to targeting range (setting or max?). Frustrum would be larger than camera.


    Add: Manual mode:

    CanAim(Vector3D) // can the turret at at the given point with the aiming frustrum

    Aim(Vector3D) // aim at the given point

    Existing: ShootOnce()


    Rotors/Pistons

    Connected grid (like connector)

    The only way to know the connected grid is through some grid-walking magic. And it's not 100% reliable.


    Landing gear

    MyDetectedEntityInfo for entity in range

    IsAbleToLock() (something in range) This is a state, but not exposed as property


    Solar Panel/Oxygen Farm

    Vector (position) to Sun (this info is already available in the code; it's displayed in debug draw).


    Air Vent

    IsPressurizationEnabled() So we don't have to determine the world setting by reading detailed info and check hard-coded string


    Ore Detector

    (you're already working on)

    list of detected ores in range. Ore Name and world coordinates. Maybe add TimeStamp.


    Laser Antenna

    Add RayCast capability

    frustrum should be larger than camera (maybe 300 degrees?)


    Cockpits/Cryo Chamber/Medical Room

    Add IsPressurized()

    For enclosed cockpits, this is eas(ier). Maybe only add for enclosed?


    Control Panel
    Limited use now. Really needs something to make it useful, but I can't think of anything..


    Gatling Gun/Rocket launcher

    Add RayCast with 0 degree frustrum (only forward)
     
  6. Wellstat Apprentice Engineer

    Messages:
    212
    This is with lead, without target leading is preferred.
     
  7. Animal 22 Trainee Engineer

    Messages:
    25

    Then what you want is NOT based on aim but on the vector to the actual target, which i doubt they will give you.
     
  8. XCanG Trainee Engineer

    Messages:
    31
    Personally I just want to change blueprints in Projector block via Programmable block to make some automated things.
     
  9. Ronin1973 Master Engineer

    Messages:
    4,801
    I'd like the ore detector to be able to sniff out active nuclear reactors. The more reactors and the bigger the reactor, the further its signature will travel.

    This would add some balance to reactors. Batteries and solar panels tend to be starter technology until you can just build reactors at will. If building more reactors meant a danger of being discovered then you might either opt to try and to run "silent" by using batteries and solar panels, or try to use reactors sparingly or with caution.

    Of course this feature should have the option of being turned on or off for server usage. This would also be great for pirate scripts sniffing out which grid(s) to attack. One signature per grid and a return of all grids and grid strength when in range.
     
  10. Wellstat Apprentice Engineer

    Messages:
    212
    Aim is the direction vector, thats why i called it aimed direction in my list.

    * edit * The current behavior is the turret will aim at a point in front of the target as it is attempting to lead the target. If a raycast it beamed in the same direction as the turret aimed direction vector, it will hit nothing.
     
    Last edited: Dec 13, 2016
  11. Wicorel Senior Engineer

    Messages:
    1,242
    Why not? the Raycast gives this information . ..
     
  12. hellokeith Apprentice Engineer

    Messages:
    335
    * 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?
     
  13. Malware Master Engineer

    Messages:
    9,602
    @hellokeith Gravity is already detectable via IMyShipController.

    Out of bounds detection is out of world information. Out of world information does not belong in the PB which is an in-world device.

    Same with the universal time stuff. That is out-of-world information.

    A universal time is technically available though, through DateTime.Now. However that is real-time. I've been wanting to replace that with a game-time one.

    To attempt to avoid an argument, the out-of-world thing is not just my invention. I'm sure @rexxar will confirm this for me.
     
  14. hellokeith Apprentice Engineer

    Messages:
    335
    Another way is to just allow others to brainstorm, since
     
  15. Malware Master Engineer

    Messages:
    9,602
    @hellokeith Aah, but the caveat to that statement is
    Discussion includes counterpoints, yes? Isn't it better if you're told immediately when one of the suggestions break the rules? Helps save time. And informs those who does not know of said rules. :)
     
  16. Maddo Trainee Engineer

    Messages:
    41
    Ore Detector / Antenna
    - Info that shows on the HUD. Position, type (ore/hostile/friendly/owned/neutral) and name

    Turret's
    - A bool if they are currently shooting at/tracking something.
    - A MyDetectedEntityInfo for whatever they are shooting at/tracking.
    - I don't know, this is pretty powerful (0 chance of sneaking something small past 800m), but I suspect camera ray casting could come pretty close anyways.
    - Long term I'd prefer if turrets stopped magically targeting stuff, and required a radar block or something. So if something like that is in the works this would be redundant eventually.

    Not sure why we can't trigger the jump drive from the PB. Would be really handy for scripting drones.
     
    • Agree Agree x 1
  17. Malware Master Engineer

    Messages:
    9,602
    It's there to prevent accidental loss of ships since you won't go with the ship unless seated. I'll try not to go into a rant about this, because I want it too, but it's off-topic for this thread :p
     
  18. Wicorel Senior Engineer

    Messages:
    1,242
    I don't fully understand why that reason prevents access.

    I don't need jump drive to have a script move an unpiloted drone out of antenna range (or just lose power and have no antenna).

    So it's just that you could be 'in' the ship and not in a seat when the script jumped the ship? So you are separated from the sip and don't know where it is.
    Same thing can happen with any script-controlled ship and just having it move. Especially when in MP.

    It could be solved by the game itself; don't jump if there is a player (not in seat) within the bounding box of the ship.
     
  19. Malware Master Engineer

    Messages:
    9,602
    @Wicorel I'm just parroting. I want this as much as you do. But, as I've said already, off-topic
     
  20. sgt_jupiter Trainee Engineer

    Messages:
    17
    Like 4/5 people here have suggested these, but they get my vote for being the most wanted:
    - Inter-grid communication - with simple messaging protocol and getting information like, as suggested, a enemy/friendly grid (with an active antenna) is coming into range...
    + I was thinking that a sensor block could be used as an upgrade for antennas; that is required to sort friendly/enemy/neutral - Other wise they would just show up as "unidentified" until they came much closer. but that sounds like a mod.

    - I'm assuming that at some point there will be a more robust hacking system (like with an interface, encryption, a little node-based puzzle game, and the infamous "hacking gun"). I just hope that this system will have an interesting API for the PB from the start (detecting-what-is-happening wise).

    - Would like to see more interaction with the soundblock, like detecting if a sound is playing, which sound, and how long it is. And maybe in the future, detecting voices from players - for all your clap-on/clap-off needs.
    + Sorry this is unrelated, but all I want for Christmas is to be able to change the sounds on soundblocks through the PB.
     
  21. Sinbad Senior Engineer

    Messages:
    2,788
    I would like to see the welder and grinder be able to identify what blocks they are effecting. Not as a specific block, just a list of types in the effect range: like 3 heavy armor, large gattling turret.

    I would also like to see a similar functionality for drills, like a very short range ore detector. Maybe returned as an array? (oretype, %of effect area),(oretype,%of effect area)

    One more? If we get a list of detected ores for the ore detector with no additional information(like range or location), maybe a Variable range or some directionality for the detector? That would make drone guidance much better than strip mining.
     
    Last edited: Dec 16, 2016
  22. Cadde Trainee Engineer

    Messages:
    99
    I must admit, i only really skimmed the first post. Even less so the rest of the thread. (at most, paying attention to Malwares existence of entries, i respect him)
    But with a general direction in mind, i will do my best to contribute to the question... "What to do with sensors, ore detectors and antennas etc"
    So here goes...

    Antennas
    I will start with these because in my mind, these are the "dumbest" units available. Their purpose is simple... Broadcast and receive electrical waves.
    There are two types of antennas, omnidirectional (antenna in game) and directional (laser antenna ingame) and the ways they operate are similar but still different.

    Omnidirectional antennas sends and receives in ALL directions. They are not as efficient at broadcasting in a general direction. Their range should be limited compared to it's directional counterpart.
    On the flipside, omnidirectional antennas can receive ANY signal coming their way from any direction. Hence they are VERY useful for getting a signal... Any signal... from any direction.

    So, what does an omnidirectional antenna look like?

    [​IMG]

    The semitransparent sphere represents the effective transmission range of the antenna.
    To anyone even remotely familiar with how sounds work, the way this operates is clear.

    [​IMG]

    It sends "sounds", or rather, a very high frequency "whine" inaudible to humans, in every direction.
    And when it listens...

    [​IMG]

    It listens in all directions.

    So basically, it has no ideal who receives a transmission and it has no idea where that transmission is coming from. All it knows is that a transmission has been made or that a transmission has been received from any direction.
    Thus, i conclude that the interface for such an antenna should be:

    Code:
    public interface IMyOmniDirectionalTransmission {
        // message could be made with a PB, or it could just be the "standard" message that antennas make every so often for other game purposes.
        string Message;
      
        // This changes with signal quality as per below. That is, time of reception can be +- a few milliseconds off.
        // And the time is directly proportional to the distance between the sender and the receiver. That is, an antenna that is 1 km away will get the
        // message ten times sooner than an antenna that is 100 km away.
        // Time of reception is actually used to determine who will recieve the message when in their transmission buffers.
        TimeStamp TimeOfReception;
      
        // Just how strong the signal was. Could basically be used to determine distance.
        // Even if the signal quality is < 0.00001, the message was "heard" perfectly clear.
        // However, the SignalQuality should have some random deviation that depends on the tyoe of antenna that broadcasted it.
        // So, for instance. A sender with a range of 100 km could have a deviation of +- 0.05 at max distance. Or +- 5 km at 100 km's.
        // Recievers at 1 km will get 100% (1.0) signal quality (with little to no deviation) where recievers at max distance will get max deviation.
        double SignalQuality;
      
        // The "frequency" the message was received on. This is nothing complicated... Each antenna type has a certain frequency.
        // This would be used to determine what type of antenna sent the message to work with TimeOfReception and SignalQuality if necessary.
        // And no, you don't need to tune any antenna to a specific frequency to get transmissions. They send on a fixed frequency and they receive on all frequencies.
        int Channel;
    
        // Same as the block ID of the antenna making the transmission. For identification purposes.
        // NOTE: I am split on this one. It's up to the sender and receiver to trust the contents of a transmission.
      // Identification verification should technically be the job of the receiver. There's nothing stopping PB block users from
    // using cryptology to protect their message contents as well as their systems that rely on messages to do stuff remotely.
        long TransmitterID;
    }
    
    public interface IMyOmniDirectionalAntenna {
        // Empties the buffer of recently received transmissions.
        List<IMyOmniDirectionalTransmission> GetLatestTransmissions();
      
        // Makes the antenna transmit an IMyOmniDirectionalTransmission. Plain and simple.
        void Broadcast(string message);
    }
    Now, the question becomes... Will terrain or objects block transmissions?
    I'd say NO because of performance concerns. But if you are willing to ray trace for long distances between antennas then that could be a thing. But no further than that.

    So, how can these be used to effectively locate other antennas in the universe?
    Triangulation of course!

    [​IMG]

    ... Triangulation math is something left to the PB scripters.
    But IMHO, this leaves antennas at their core... Very useful for two purposes.

    1) Remote messaging between off grid PB's. Even after a server restart. (And to be honest, off grid references has to go... Every block function call should at set intervals check if the block is part of the same grid as the PB and if not, just flip the finger at the PB trying to use it.)

    2) Triangulation of antennas at huge distances.

    Directional Antennas

    As much as i would love to keep making illustrative images for directional antennas... I will keep it simple now...
    There's actually TWO types of directional antennas.

    Cone...

    [​IMG]

    Err, i mean parabola...

    [​IMG]

    And an axis antenna.

    [​IMG]

    The parabolic antenna is excellent to point your transmission in a general direction. (thus avoiding transmitting to errywan, pirates epspecilay)
    Hence, i proclaim that directional antennas have ten times the range of omnidirectional antennas or more. And as a downside, their signal quality (see interface in code above) is damn well near perfect all the way. (and thus timing accuracy as well)
    And of course, they can be used to pinpoint the actual source vector of a transmission to a high degree of certainty. (Add a direction vector to the interface for it and an angular offset field)

    And the axis antenna... Well... I don't think we need one to be honest. It's basically the midrange between the two i've discussed so far. Only difference is it transmits in a 360 degree angle around it along a plane. and it receives in that same plane. It just complicates matters both for the game and the PB scripters. I merely brought it up because it does exist and is notable.

    ... I don't know what else to say about antennas really...

    Sensors... Y U NO RADAR?

    Sensors are actually radars. (Or cameras, same shit... different frequency)
    And radars are just glorified antennas... Or very loud speakers...

    [​IMG]
    (Missed opportunity for NASA there... Should have had text on it that read "Jiggle jiggle jiggle" with a slight shake to it)

    That's all there is to it really. You shoot a "EHRMAGHERD" strong signal in a certain direction and wait for whatever it hits to "respond" by vibrating (reflecting) that signal back at you.
    Radars then triangulate this return signal by the delta time and direction of the radar dish. Or you can think of it as a radar gun if you'd like...

    [​IMG]

    So radars FORCE a ship to make a transmission when hit by the signal. So see antennas above for the rest of that implementation. We might even get away with using antennas for this and skip the whole "sensor" block altogether.

    Oh and let's not implement stealth technology just yet... Or at least not in the physically accurate sense.
    But there is an opportunity to make rubber paneling a thing. Basically a huge mass of rubber that (depending on the ratio of rubber vs steel) makes you less responsive to radar. Rubber is not a good armor plating material though and it adds massive dead weight to your ships and stations.
    Perhaps rubber plating should spread fire too? Basically, as they burn (because they got hit duh) they damage every block around them.
    ... Yes, due to game limitations, technically you can put all that rubber at the center of mass of your ship. But let's pretend it reduces the vibrations of the entire ship because... reasons.

    Ore Detector

    Ore detectors... Again... Are really just a different type of radar gun. It just sends it's "sound" through a different type of material.

    To be honest, i would very much like it if ore detectors returned a volumetric grid. This grid could be displayed inside the cockpit or with a holo projector. And of course, it could be read by a PB.
    Each voxel is stored in a single array X*Y*Z in dimensions and it's up to the PB scripter to use this information appropriately.

    Depending on the distance from the center of that voxel volume, the accuracy of readings diminish.
    And each reading as a float representing the density of the material found. So there are some materials that are practically indistinguishable from stone (like platinum) and we could also do some meta gaming here and not use real values for other ores. Or at least make them harder to detect.

    Ok, this presents a problem if a voxel is 0.5^3 meters. (or whatever dimensions it has) as the current ore detectors detect ores at ranges up to 200 meters... As that would be a sphere with 268,082,573 voxels in it.
    Perhaps this can be solved by changing the granularity (spacing between detected voxels) so it becomes something like 32^3 (32768) voxels instead? Still a significant amount of voxels but manageable. And most ore deposits are bigger than 6.25 m³ anyways. In fact, they are much bigger so you are bound to find them IF you check the data properly.

    ... I have gone on long enough. Enjoy!

    EDIT:
    Of course it is. But i too think the gyroscope should logically have this same functionality. Or can you tell me a reason as to why it should not beyond "A already has it so B should not".
    Think of the CHILDREN!... Err, i mean... Cockpit/RC-less drones.
     
    Last edited: Dec 17, 2016
  23. theCalcaholic Trainee Engineer

    Messages:
    38
    A property for reading and a method for setting the selected font in an LCD panel. More parameters for my UI Framework (YAY). :p

    Another wish of mine would be access to the secondary selling mode of ship drills (it's not directly sensor related, but this in combination with the ore detector readout access would allow for much not efficient automated mining).
     
  24. 1wsx10 Trainee Engineer

    Messages:
    24
    how about thruster damage? a PB could see if a thruster will break something infront of it?

    also, thrusters should be able to 'sense' their max effective thrust. or, you know, have the thrust override in force units instead of % :D
    --- Automerge ---

    while im normally one for realism, making things in such detail would mean that scripts have to reinvent the wheel and require gps clusters for basic information that players can get with the in-game GUI. this increase in overhead means scripts come closer to the performance limit, so they can do less.

    as others have said, turrets giving MyDetectedEntityInfo would be nice

    also rotors should be able to get rotor head position
     
    Last edited: Dec 18, 2016
  25. nmdanny Trainee Engineer

    Messages:
    23
    I think long ranged volumetric scanning would be useful, might work as a new block('Radar' for example)
    You could specify the range + the angle of the cone (via the API or the block settings), of course, the higher the range or the higher the angle, the more space is scanned, so to balance this (both gameplay-wise and performance-wise),
    the power requirements and the scans available per tick would scale accordingly, similarly to the current limitations on the camera raycast. (scanning wide areas at even medium ranges would be much more demanding than sending a long ranged raycast).
     
  26. 1wsx10 Trainee Engineer

    Messages:
    24
    i think the raycast is good. performance limits how detailed you can get the raycast at long range, this means to scan a volume at long range there is a good chance a small ship wont be picked up. but a bigger ship is easy to spot at long distance.

    a volumetric scan would pick up everything in the area no matter how small it is.

    IRL a radar doesn't pick up small objects at long range well either so it makes sense
     
  27. Cadde Trainee Engineer

    Messages:
    99
    Care to explain what you mean further?

    Triangulation math is WAY less expensive than sending thousands of raycasts in various directions.
    EDIT: This under the premise that the GAME does ONE calculation PER transmission where PB's would (with raycasting) to everything themselves million times a second.

    The idea here is that you simply iterate over all grids on the server (They could be a few thousand of those at most) and check if their distance between broadcaster and grid is < the antenna/radar range. And in the case of directional antennas / radar, also checks if their angle is in the frustum of that antenna/radar.
    Ray casting on the other hand will waste a lot of resources (and is very computationally intensive, especially without GPU support like on a server) simply shooting in every random direction players feel like until they hit something.

    A single ray cast might be as computationally expensive as a simple distance/angle check on each grid on the server. And we are tasked with sending THOUSANDS of them to detect something a few km's away...

    Even so, antennas can be limited just in the same way raycasters can. And it's a helluva lot easier to optimize a system that checks distances (you can precompute which grids could even potentially be reached by certain transmissions on a < than per frame basis) where you can't really do that with ray tracing as ray tracing is handled by Havok Physics and just iteratively checks if any collider exists along a line in iterative steps up to the distance of the ray.

    But hey, if you prove me wrong about this then i will happily accept your arguments for all eternity...

    EDIT: Oh and did you just skim over the other benefits of having antennas in the first place? Inter grid communication and actually being able to detect when someone is scanning you when they are in range?
    Heck, you can even have the ability to detect if someone has shot a missile at you and it's locked on so you can fire countermeasures.
     
    • Agree Agree x 1
  28. nmdanny Trainee Engineer

    Messages:
    23

    The problem is that raycasts are only viable for spotting relatively big entities in a very small range.
    Let's take 1.5km for example. At 1.5km it is possible to visually spot a ship pretty easily. But to do so automatically via raycasts is impractical, because there's so much space to cover, and raycasts have an infinitesimally small width. You'd need to send a massive amount of raycasts, something that only GPUs and low-level graphics libraries are designed to do(even then it's extremely computationally demanding, especially doing it realtime as one might use, say for implementing a scripted radar), but not the PB scripting engine(especially with the restriction of 1 raycast of 2km every 1 second)

    So, the only use I found for the camera raytracers so far, is using it to manually paint targets that you can already see(by physically moving the camera) in order to obtain their GPS coordinates. Otherwise I don't see a viable way to perform long range (automatic) scanning with it.

    Which is why there should be more ingame ways of long range scanning.
    For one, the IMyRadioAntenna should provide a method that gives a list of all detected entities whose transmissions are picked by the antenna. It would be perfectly balanced since it's nothing you can't see via the game's GUI, and ships that aren't broadcasting wouldn't show up.
    Additinoally , there should be ways to perform active scanning, picking up entities that aren't necessarily broadcasting themselves. Similarly to what Cadde has suggested.
     
    • Agree Agree x 1
  29. Velenka Trainee Engineer

    Messages:
    25
    Yes to using Ore Detectors as sensors for ore veins.
    Yes to having raycasts for turrets.
    Yes to having antennas be able to detect grids which are broadcasting and in range. The information you get would be things like position and velocity but not size.

    In my opinion, for long range automatic scanning which the previous doesn't cover, I think the raycasts as they are are good enough. I think that's kind of gameplay-breaking to get information on grids which you otherwise couldn't get information normally. The raycasts are an exception to this because they are (or at least have the capacity to be) balanced. You a) have to be pointing a camera DIRECTLY at an object to get information, which is unlikely to happen casting at long ranges in random directions and b) need time to build up a charge, and therefore needs time to actively scan space to any kind of usable degree of resolution. Asking for raycasts to change to volume scanning cones would indeed speed up the process, and in doing so, break the balance with regards to time involved.

    Unrelated:
    Yes to being able to script jump drives.
    Absolutely yes to inter-grid communication.
     
  30. d4rky1989 Apprentice Engineer

    Messages:
    332
    Yes, I'm definitely pro antenna for PB. But for gods sake I'm not for that low level communication. There was already a huge discussion about that in another thread.
    The reality is that computer science will always abstract things using different abstraction layers. And the most realistic scenario is, that the computer technology of the future times of SE will have implemented a highly abstract network layer that should allow a PB to directly interact with other blocks of other grids as soon as they are connected via any kind of antennas.

    Here a example why this is realistic:
    To allow a PB to interact with other blocks on the grid there has to be a network on the grid. The player can't interact nor influence that network. It's the same as the power supply on the grids. It is there but the player can't do anything with it. The antenna is also part of this local network.
    Now there is another grid in range of the local antenna. Lets call it remote grid. The remote grid has also an antenna.
    As soon as both antennas gets in communication range to each other they automatically connect and further act as a network bridge. As long as the bridge is online PBs on both grids can communicate with all blocks of both grids.

    The technological background of this example is neither magic nor unrealistic. It is done for years already. For instance VPNs (same principle: internet=free space, VPN connection=antennas results in two remote LANs (grids) that can interact as they where one LAN), WLAN bridges (2 remote LANs (grids) gets connected with each other over 2 WLAN transceivers (antennas)) and so on and so on.
     
Thread Status:
This last post in this thread was made more than 31 days old.