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.

"Core Interface Block" and "Advanced Programming Block"

Discussion in 'Programming Questions and Suggestions' started by swixel, Jan 28, 2015.

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

    The Short Version

    We want access to some things, we need access to others to make things work (i.e. time), but that access shouldn't be "free". We can't assume power is meaningless in computing, and we can't make it so programming blocks are more powerful than ships without. Somewhere there needs to be a balance, and from what's missing and what we'd like there are a few solutions. I'm presenting one of them.

    I expect a lot of backlash at the idea/notion of cost for benefit, but I'm presenting little in the way of specifics here, and I don't mean to present a fixed cost to benefit "cost" for this, but rather am trying to point out that it's required. Those who think technology should be significantly advanced by 2077(/"the future") and that these costs shouldn't exist are welcome to that view, but I'd rather that any future changes come in a way which benefits everyone at the same cost, rather than giving us raw power through access to significant things (and data points).

    Should it become feasible to mod these into the game myself, and if Keen has not by that stage addressed the majority of what is discussed, I'll seriously look into it (and probably do it). At this stage it isn't (because the whitelist prevents what I'd like to do).


    With respect to my replies in the other two threads, this probably needs expanding is would drag both threads off topic rapidly. In a bid to keep this centralised, and to discuss the cost/benefit trade-off required, I'm putting this here.

    Core Interface Block
    A "mainframe" style block which is designed to be the central storage hub for various bits and pieces of code, information and data. The idea behind this block would be that it's required for any craft using the Advanced Programming Block (outlined below), but not for the programming block, which cannot use it. The presence of a CIB would enable the advanced features for the programming block, but not access to the CIB. This could be distinguished through access to not only IMyGridTerminalSystem but also IMyAdvancedGridTerminalSystem, which would not be present for the programming blocks. Both blocks would need to know (via the GridTerminalSystem) if a Core Interface existed, so as to enable the points noted below.

    The CIB is designed to be a "processing block". When "off" access/features it provides are gone. It should still have a toggle with on/off being available. The "processing" it provides is to be implicit in nature, which is to say that we can't tap it into, but other things can (higher resolution scanning, scanner feedback along computational routes instead of what I presume is "visible on the scanner", etc.).

    The CIB should contain battery components to run after power failure, this power should match APB time, see APB's battery comment for more information.

    This block would be limited in nature, relatively inexpensive (with the cost coming largely from the Advanced Programming Blocks), and would be primarily a read-only data structure with some "write" memory (in the form of strings). This will make more sense once the APB is defined below.

    This should be limited to one per vessel, and the power consumption based on two parts:
    • Number of blocks in the CubeGrid (cost being higher for active blocks polled);
    • Number of storage groups assigned;
    • Number of blocks "attached" to the CIB (where power is drawn by the blocks, and the CIB itself drawing consistent power based on grid size).
    In addition it would require all IMyTerminal accessible blocks to have "Enable Core Interface Access" added to it as a checkbox (or toggle). By default this would need to be "off" to save power, but when "on" would enable "Advanced" functions (at the cost of power). Of which I had the following in mind (helping both programming blocks and non-programming blocks, justify its existing for all users):

    • Increased sensor range (up to 250m) -- power should scale accordingly;
    • Increased ore detection range (up to 250m) -- power should scale accordingly;
    • Antenna Relay Mode (allowing antennas to relay as a mesh-network) -- power should scale and another slider be used to indicate mesh relay mode, for further power scaling (where something like 45% of the maximum distance should be what it is now with both on, keeping a sweet spot for fleet use and encouraging beacon building and waypoint construction);
    • Auto-logging option for sensors and ore (storing GPS coordinates of Ore and other fixed positions like stations and asteroids using a format like "Ore: {Type}: {Coords}" or "Station ({Faction}): {Coords}") -- this should "spike" the power (encouraging people not to leave them on when in combat, and to add some cost to the benefit). Granted this gives rise to benefits for those using programming blocks (as the power doesn't spike), but power should be spiking for all programming blocks types during execution (see Rationale at the end);
    • GPS access programmatically for all programming blocks (but only if the CIB is present);
    • Limited callback handling (at the expense of power; could trigger a timer or programming block, making it viable for all users, rather than just making arbitrary "events" accessible to everyone) -- this is explained in the Rationale.

    Time Information
    We only need the bare minimum here:
    struct TimeInformation
        // Full 24 hour windows passed
        public UInt16 GameDaysPassed;
        // Full 24 hour windows remaining based on settings
        public UInt16 GameDaysRemaining;
        // Number of 60-step cycles executed (including the floating point for steps)
        public double GameSecondsPassedToday;
        // Number of 60-step cycles remaining (including the floating point for steps)
        public double GameSecondsRemainingToday;
    Ship Information
    The idea here being to simplify our workload by exposing this information to the block at the beginning of every frame, to each ship, prior to damage, etc., being handled, giving us a decent reading of what's happening. This would stop crazy people like me from recalculating the bounding box, rotation, and speed. Here's what I had in mind:
    struct ShipInformation
        // Current ship location (orientation and bounding)
        public VRageMath.MyOrientedBoundingBoxD ShipLocation;
        // Current speed (as shown on the HUD)
        public double CurrentSpeed;
        // Number of kg
        public double CurrentWeight;
        // Seconds of fuel remaining
        public double SecondsOfFuelRemaining;
        // Has batteries in the array
        public bool HasBatteries;
        // Has renewable energy (Solar)
        public bool HasRenewableEnergySource;
        // Owner of the ship
        public String Owner;
        // Faction which owns it
        public String Faction;
        // UUID, or whatever, purely for ship tracking so we can use
        // Merge/Connectors.  This UniqueID should probably be accessible
        // through IMyTerminalBlock has a readonly so we know the owning
        // ship!
        public String UniqueID;
    GPS and Advanced Sensor Support
    To help justify the need for the "Advanced" block the advanced block should get access to limited data (used as part of the GPS system).
    struct SensorReading
        // Use the existing enum... potentially shared/copy/enable this
        // so we can switch using it ;)
        public Sandbox.Game.Entities.MyEntityIdentifier EntityType;
        // Used for ore, ship name, player name, etc.
        public String Identifier;
        // Faction name, "" for neutral
        public String Faction;
        // Owner as a playername, "" for neutral
        public String Owner;
        // Block which detected it
        // (Helps us debug what works and what doesn't)
        public IMyTerminalBlock DetectedBy;
        // Gives the location, orientation, and bounding box
        public VRageMath.MyOrientedBoundingBoxD Location;
    The CIB would need a method to dismiss the sensor reading using the index in the list. To handle this cleanly the "dismiss" message should be index for that frame, it should be stored within the CIB, and the CIB should clean out the "dead" messages itself (not relying on the user to do so directly). This would give rise to the need for:

    // Assuming the following static:
    // static IMyAdvancedGridTerminalSystem AdvancedGridTerminalSystem;
    // Removal
    void AdvancedGridTerminalSystem.RemoveSensorReading(int list_index);
    // Checking for removal
    bool AdvancedGridTerminalSystem.IsMarkedForRemoval(int list_index);
    // Getting all sensor readings
    List<SensorReading> AdvancedGridTerminalSystem.GetAllSensorReadings();
    // Getting only sensor readings not marked for removal
    List<SensorReading> AdvancedGridTerminalSystem.GetSensorReadings();
    For GPS handling simple methods just need to be added to the IMyGridTerminalSystem:
    // Store a GPS position
    void GridTerminalSystem.StoreGPS(String name, VRageMath.Vector3D position);
    // Get a GPS position
    void GridTerminalSystem.GetGPS(String name, out VRageMath.Vector3D position);
    // Has CIB/GPS support
    bool GridTerminalSystem.HasGPS();
    Access to GPS data (programmatically or automatically) should also require both a beacon and an antenna in addition to the CIB.

    Core Storage
    One other problem is storage. Storage should be a cheap system which scales its power based on how much data is stored. The core storage system should be considered to carry a finite number of drives, and each advanced programming block can carry another finite amount (I'd think something like 4 in the CIB, 2 in each APB). The cost of these storage units should be considered as a factor of size stored (number of bytes), OR by "Group" (accessible by string, something like "String GetStorage(String Name)" and "SetStorage(String Name, String Value)").

    This sort of storage should only be accessible to APBs. This will function a bit like SetCustomName but without mangling names or adding needless overhead as we poll our block groups...

    Advanced Programming Block
    The advanced programming block is designed to exist as a "better" programming block, which should cost more, draw more power, and have a slightly higher complexity limit. The idea is that it sits somewhere between the Mod and the In-game block, giving it a better "software" state than the existing block. Requiring a CIB to operate, it is automatically assigned to the CIB and its power draw should be factored into the cost. It gets access to the above (using whatever API is provided).

    The APB should contain batteries to operate for a fixed period of time after power failure. These batteries are solely for the APB, just as the CIB variant is for them. In my mind they may only be activated by direct request of an APB. (To balance this an Advanced Timer Block with more configuration options and integrated batteries may need to be added too.) This would allow:
    • Conveyor-based fuel movement;
    • Battery switching (from recharge to discharge);
    • Management of power (for low-power state via timer/whatever).
    Through the Advanced Grid mentioned above the APB has access to shared storage based on "groups". For all intents and purposes these groups should be accessible via the central grid, and not by the blocks directly. The storage data itself should be considered within the blocks, and some sort of API (requiring at least one empty drive) be used for shifting data around. Data movement should have a time cost (even if it's only a few seconds) to make data all the more precious.

    The Advanced Programming Block should also contain a "Setup" or "Installation" script or interface, which allows given blocks to be assigned to IMyTerminalBlock references for use during code execution. (From a developer point of view this could be Hashed block, local coords, or whatever; the point is the block instance shouldn't shift unless it's nulled by destruction or any other kind of removal.) This sort of script (or interface) should be trivial, heavily limited, and not be executed except manually (by the "installer") or perhaps by the instantiation of the ship in its complete form ("Blueprint Completion" or something).

    Currently the programmable blocks are a seriously powerful tool which allow those of us with the patience to do a great many things. However, the limitations of the blocks are now starting to mirror other points in the game.

    What we need is for the limitations to come with cost/benefit, rather than continuing to expand access to systems without cost. With the addition of the programming block I started to notice what did and did not use power, and how little some of it used. This made maintaining the craft (and its cost) trivial, in that I could poll given blocks in a ship for their location (or hardcode them) and then use thrusters (instead of gyros) to handle my own (albeit imperfect) inertial dampening system, rotation control, etc. (and that sits in two distinct blocks, run sequentially).

    Encourage but not force
    Things like sensors and GPS data are amazing tools for the game, but currently are either too fragile and inaccessible or undercosted for what they are. I love the notion of a GPS system and that radio/chat system being useful for transmitting limited data, but where's my energy hit for using the GPS system? I'm not asking to make survival brutal, but rather for autologging of placement to be accessible to all users, and those who want some minor discount (i.e. through an Advanced Block + CIS) to pay the cost another way (albeit with the minor discount for using a more complex system). This would encourage more people to use the game but not force it.

    Extending not enhancing
    The programming block currently sits in parallel to the timer block; in some ways it's less useful, in others it's more useful. The Advanced model + CIS would give access to more power, but instead of putting it into the core block and outright upgrading it, why not move some of the functionality so that all users benefit, and extend the game by adding a more expensive component (which can be rebalanced/tweaked/broken/whatever) while leaving the programming block being slowly enhanced by minor tweaks/modifications.

    I know to many people the distinction isn't necessary, and they'd rather see the programming block take on all this functionality (particularly at no cost), but the reality is that things like the CIS and the APB would allow existing functionality, while adding a need to extend into more expensive components which are functionally better but with their own downsides (i.e. you wouldn't run more than a few of them on a small ship, it requires more power so you need to be more efficient; batteries drain faster, etc., but for that you get better vessels).

    Access, polling, potential callbacks, but never "events"
    The only other point I'd raise here is that the CIB should enable "callback" events like the sensors have. Upon "finding" something, or upon performing some function, the CIB should be notified. We don't want blocks to perform callback handling but it would be good if certain generic events (like being hacked, running lower on power, or finding ore) could be used to trigger specific blocks. I feel that the CIB should have its own activation cycle, allowing the user to optionally perform something when the callback comes in. (If it's empty it shouldn't draw power or even receive the "event".) This would neatly blur the limitations of time (for a sequencing object) and processing.

    The events that come to mind are:
    • Structural integrity damage (IMySlimBlock can be used here);
    • Build completed (must be from another craft's projector);
    • Ownership change (requiring the enemy to completely demolish the CIB to prevent potential data wipes);
    • Being hacked (any block triggering it, letting APB or PB handle the reaction by polling, a pseudo "alarm");
    • Running low/out on fuel.
    The aim of the pseudo-callback system is to help make ships either entirely or at least semi-autonomous, which, when coupled with access to time and bounding box information makes it significantly easier for people to begin to write neat code (e.g. time + bounding box + known rotation speed + weight = "RotateToFace(VRageMath.Vector3D point)").

    I guess the underlying point of this is I'm not asking for a free lunch. I don't want some arbitrary sweeping upgrade to functionality limited to a portion of the players (even if I'm in that portion). I want some sort of balanced/sensible system which allows the devs to dump more and more data into an optional core block for access, and as it extends it benefits all players, giving us more power but never completely wiping out the need (or want) for human pilots, builders, or handlers.
Thread Status:
This last post in this thread was made more than 31 days old.