Ingame Programming missing API and functions and known issues

So i've decided to sum up, what i'm mostly missing on blocks in ingame API
Please add things you want to see, or that should be here
Before i list missing APIs i add few known issue and possible circumvents

Some values are not available trough IMyTerminalBlock.GetProperties(), but you still can parse them from IMyTerminalBlock.DetailedInfo(which is enough, if you don't need to modify this values), list of detailed info strings can be found here https://forums.keenswh.com/threads/guide-programmable-block-detailedinfo-output.7230123/

Some values are not availale trough IMyTerminalBlock.GetProperties(), but can be obtained using IMyTerminalBlock.GetActions() and IMyTerminalAction.WriteValue(), this includes for example status of airvent depressurize switch or values of sliders (see https://forum.keenswh.com/threads/block-evaluation.7358840/ ). There is known issue tho', that on DS WriteValue not working for all values (or rather it's working for half of them at most) see at the end

As of 1.0.85 - all control values should be available trough IMyTerminalBlock.GetProperties(), this include On/Off buttons and checkboxes as Boolean, Sliders were already available (as float) and Color controls as Color.

there are though values, and APIs we are missing anyway

Missing apis
GPS
- gps access interface @Wicorel

All blocks
- missing methods to change ownership and sharing (while i expect this functionality to be limited only to owner of block, it's still missing, so you cannot trough script lock block only to your self, then share it back with faction fox example)
- missing mass information (@Gloin the Dark) (fixed 1.0.83)
- missing API to get block damage information (@Gloin the Dark)
- checkboxes have no access (either by "action" or by "property") (fixed in 1.0.85 - see above note)

All blocks allowing grid connection/separation
- missing method for retrieving connected grid (@JoeTheDestroyer)

ProgramableBlock
- missing api or accessor for programmable block, that is running script (eg. like GridTerminalSystem returns current GTS, RunningBlock - or whateverelse - will return IMyProgramable block object of PB running the script) (@Gloin the Dark) (fixed 1.0.83 - IMyProgrammableBlock Me)
- missing api to access game timer (clock) (@Gloin the Dark) - need to use game(server) supplied timer not RTC, to avoid timing issues when simspeed is != 1 (fixed 1.0.83 - TimeSpan ElapsedTime) - currently it's broken again, doesn't show correct time (reevaluation and fix needed)

IMyAssembler
- missing method to switch cooperative mode (fixed 1.0.85 - it's checkbox)
- missing method to switch repeat queue (fixed 1.0.85 - it's checkbox)
- missing methods to access and alter production queue

IMyButtonPanel
- missing method to retrieve button pressed (@plaYer2k)
- missing method to set/get button title (@plaYer2k)
- missing api to get player using button panel (@plaYer2k)
- missing api for retrieving button sequence (button pressed, when, by who) (@plaYer2k)

IMyConveyorSorter
- missing method to switch whitelist/blacklist
- missing method modify filter
- missing method to disable sorter/filter

IMyCubeGrid
- missing method to retrieve center of mass (@plaYer2k)
- missing api to retrieve velocity, orientation and movement vector (@JoeTheDestroyer )
- Vector3I WorldToGridInteger(Vector3D coords); @Gloin the Dark (added 1.0.83)
- Vector3D GridIntegerToWorld(Vector3I gridCoords); @Gloin the Dark (added 1.0.83)
- void ColorBlocks(Vector3I min, Vector3I max, Vector3 newHSV); @Gloin the Dark
- void ConvertToDynamic(); // converts station to ship @Gloin the Dark
- bool CubeExists(Vector3I pos); @Gloin the Dark (added 1.0.83)

IMyDoor
- missing method to disable control panel (T access)

IMyGridTerminalSystem
- missing API to get blocks that are derived only from IMyCubeBlock and not from IMyTerminalBlock (@Gloin the Dark)
- missing API to get list of accessible grids (CG) (@plaYer2k)
- missing API to get list of accessible GTS (like the list, you get from dropdown menu in terminal)
- API to change shipname (@joemorin73 ) - might move to different place

IMyLaserAntena
- missing method to switch permanent connection (added 1.0.83)
- missing method to get connected antena object (@Gloin the Dark) - IMyLaserAntena or IMyTerminalBlock for antena block itself, or IMyTerminalGridSystem for grid connected to antena

IMyLandingGear
- missing method to check if it's ready to lock (@Dawnkeeper )

IMyMotorSuspension
- mising API to access wheel angle, steering angle and rotation speed(@plaYer2k)

IMyOreDetector
- missing api to get list of detected ores

IMyPlayer
- missing api to access user keyboard input (@plaYer2k)

IMyRadioAntena
- missing method to get accessible friendly antena object(s) (@Gloin the Dark) - List<IMyRadioAntena> or List<IMyTerminalBlock> for antena block itself, or List<IMyTerminalGridSystem> for grids connected to antena
- method to retrieve list of detected antenas (like on hud) @g4borg

IMyRemoteControl
- access to waypoint list and other autopilot related functions @Wicorel

IMySensorBlock
- missing API to get all detected objects in range (@plaYer2k)

IMyShipConnector
- missing method for retrieving connected connector (@JoeTheDestroyer)(added in 1.0.83)

IMyShipController (cockpit, flightseat, control station, remote)
- missing info from HUD (speed, mass) (@Gloin the Dark)
- missing orientation (movement vector) (@Gloin the Dark)
- missing gravity information (vector, strength) (@Gloin the Dark)
- missing api to get player using controller (@plaYer2k)
- missing api to check if controller is occupied (added in 1.0.81)

IMyTextPanel
- missing methods to get/set private text (added in 1.0.81)
- missing methods to get/set private title (added in 1.0.81)
- missing method to remove textures (you can add them, but not remove) (added in 1.0.81)

Known issues
- IMyInventory.TransferItemFrom() ignores sorter on path, and item size (passing large objects trough small conveyor)
- IMyInventory.TransferItemTo() ignores sorter on path, and item size (passing large objects trough small conveyor)
- IMyTerminalAction.WriteValue() not working properly on DS (confirmed bug https://forums.keenswh.com/threads/1-0-78-ds-missing-action-value-string.7358023/ ) (fixed in 1.0.83)
- Vector3D components (X,Y,Z) return bad values (fixed in 1.0.123)
- SetPrivateText and SetPrivateDescription don't work on DS/MP

 

IMyCubeGrid.GetCubeBlock() will return the IMySlimBlock for a given position in a grid.
But it filters out slim blocks that are not linked to a terminal block.
Therefore there is no way to get the repair status or location of armor, windows, conveyors, etc.

Edit:
I have requested this. A ticket has been created. Waiting for fix.

 

I was unable to get some of the claimed functionality of the Turret API to work. Specifically, setting Azimuth and Elevation and using the related Synch functions did not work in my tests. However, I don't know if that was due to a bug in the API, or due to an error in my code. I am not aware of any proof-of-functionality for those in-game API features.

 

No API to get the mass of a grid or block. (no workaround)
No API to communicate between ships. (very slow workaround using LA)
No API to get the orientation of a grid (in world space). (clunky workaround exists)
No API to get ore deposits detected by ore detector. (no workaround)
No API to get ship speed or direction.
No API to get gravity field.
No API to control production queues (in assemblers)
No API to get the programmable block that the program is running on. (IMYProgrammableBlock.IsRunning() also reports true for other running blocks. When one program starts another program block, both report IsRunning() == true)
No API to get in-game time. (Ticket created, waiting for fix.)

 

as for ship speed and direction, which interface you suggest should have it?
from what i recon, most suitable would be IMyShipController - this interface is shared by all cockpits, seats, and remote

as for gravity field, not sure, what you want to do with this, but you can get settings from gravity generator, therefore getting projection of gravity field is easy, also thanks to fact, that our gravity generator have unrealistic contant output in constant area.

IMyAssembler is descendant of IMyProductionBlock ... i will not list same thing twice

i would not include this, since there is no functionality for integrid communication at all, there is not even block for it (remote doesn't not count) - so, until we have block that allows integrid communication, i would not count this as missing api.

 

Yes. Perfect.

I have a repair bot I am working on that could use the gravity field to know where to park. Can't access the gravity generator of the ship, because drone is seperate ship. Also there may be overlapping gravity generators. Also, planets will have gravity. Also needed to know which direction objects will fall when ejected from connectors or ejectors.
Gravity field can be seen when in a cockpit or remote control, so the best place to put this would be IMyShipController.

Sorry, I missed that you already had that...

But there is...
If you are on a ship with an antenna you can access the control panel of any other friendly ship with antenna within range. If that ship has a remote control block you can control the ship.
So the appropriate block would be the antenna.
IMyRadioAntenna
List<IMyRadioAntenna> GetOtherFriendlyAntennasInRange();
EDIT:
Since the radio antennas create a network the API should be...
List<IMyRadioAntenna> GetConnectedRadioAntennas();
Once you have the list of antennas. You should be able to get the GridTerminalSystem for that antenna.
IMyRadioAntenna
IMyGridTerminalSystem GetGridTerminalSystem();
Should work for laser antenna too...
IMyLaserAntena
IMyLaserAntena GetConnectedLaserAntenna();
IMyGridTerminalSystem GetGridTerminalSystem();

 

ok, it's another hud information, so probly adding it to ship controller, but since it's hud, guess gravity value, and vector (like on hud), should be enough.

as for antenas, yes i forgot, you can switch grids in terminal, and this must have some interface. makes more sense under antena, other option is to have under IMyTerminalGridSystem.GetAccessibleGridSystems(List<IMyTerminalGridSystem>); but antena will make more sense

 

Well this turned more into a suggestion or wanted feature thread than actually "missing" in a sense of "not working".
So lets add a bit.

All blocks
- A property for the actual power consumption aswell as the max power consumption.
- Get the orientation in world coordinates (without the need of using multiple blocks and additional math).


IMyCubeGrid
- Get the Center of mass.

IMyGridTerminalSystem
- Get all IMyCubeGrid per GTS. This is important for when we can get a grids center of mass and mass but it doesnt contain any IMyTerminalBlock.
- Getting all IMyCubeGrids on a GTS aswell as all GTS in antenna range should be done through a simple property like .Blocks and .BlockGroups and exposea List<T>.

IMySensorBlock
- Return all entities in range and not just the last detected one. List<IMyEntity> IMySensorBlock.DetectedEntities

IMyMotorSuspension
- Expose wheel angle and steering
- Let us set the steering angle and rotation speed for them.

IMyPlayer
- Allow access to the keyboard inputs so that we can directly type in things and interpret them with programming. A special interface block (like a cockpit) could be acceptable where only "Esc" lets you leave.

IMyShipController
- Get the astronaut that currently uses the controller. IMyPlayer IMyShipController.Player (null if empty)

IMyOreDetector

Code:

public interface IMyOreDetector : IMyFunctionalBlock, IMyTerminalBlock, IMyCubeBlock, IMyEntity
{
  // These two are present currently
  float Range;
  bool BroadcastUsingAntennas;
  // This is the list of all the detected ores
  List<IMyOre> detectedOres;
  // This is the list of all the ores we currently detect by their TypeName
  List<string> detectingOres;
  // This is the amount of ores that has to be exceeded in order to detect it (according to this change [URL="/post/please-change-the-ore-detector-back-to-how-it-was-7219230"]https://forums.keenswh.com/post/please-change-the-ore-detector-back-to-how-it-was-7219230[/URL])
  float minimumAmount
}
// This is a new struct containing informations about the ore
public struct IMyOre
{
  // the position of the ores
  Vector3 Position;
  // the type of the ore like: gold, iron
  string TypeName;
}

Forgot the others but i sure will add them alter.


Edit:

IMyButtonPanel
- Make the description string per button accessible both as getter and setter.
- Expose the button state when someone pressed it (useable for tick-based programs) and return the player who pressed it (null when not pressed).
- Allow to continuously press a button (holding T down while aiming at the button) which is properly detectable through ingame programming.

 

that's intentional, i plan to point this out to devs, since ingame programming need improvement.

there are few similar threads in modapi section.

also there are lots of things, that are currently available trough modapi (for example assembler queue), but for some reason they are not propagated to ingame script api (my guess is, ingame scripting is low priority)

 

power consumption can be parsed from detailed info, but detailed info is not present for all blocks, so i will add this.

Can we access any cubegrid except GTS in ingame scripts? i will put this to GTS for now, might change it later

i think, this is covered by antena access

not sure about this one, this might create wait loop in script, can you give example when you will use this?

i will not add last one, since this not working ingame (at least not on DS, you can just push button indefinetly - when continuous button press is implemented, it will make sense to ask for api)

 

And yet parsing and working with strings in general is a rather bad way when the actual information is present as numerical value already.

What do you mean with "except"? Each GridTerminalSystem consists of one or more CubeGrids. Though not all CubeGrids are accessible by iterating through all blocks of a GridTerminalSystem.

Well "Get all IMyCubeGrid per GTS" is not.
But your solution for my second suggestion (Get all GTS within antenna range) is imo too "complicated". It simply is a list, no need to use a method and possibly "search" even.
Thus the antenna GTS equivalent should work like the .Blocks and .BlockGroups lists do. They simply expose a List<IMyGridTerminalSystem> you can directly iterate through.

What do you mean? IMySensorBlock, IMyMotorSuspension or IMyPlayer?
Also why should that "create a wait loop"?
I will assume here that you were refering to the IMyPlayer and us being able to get the key inputs. For that you would simply get a list of keys that are currently pressed.
So first lets see how the game actually stores key inputs, more precisely the single keys pressed.

Code:

/// List of keys pressed when the frame was
public List<byte> Sandbox.Common.Input.MyInputSnapshot.KeyboardSnapshot

So the keys are simply encoded in bytes, stored in a list.
Forwarding this list so that it is accessible from ingame programming would be very useful.
(Adding support for the whole MyInputSnapshot would be even better as that handles mouse and joystick too)
One could have a text panel with a corresponding program. The player sits down in front of the text panel on a passenger seat.
Then the program would grab all the inputs done by that player so that he could natively write text into the text panel as if it were a console. You could type "close doors" and the program would read that and interpret it, which in this case would be to simply output them 1:1 to the text panel.

There of course are certain issues with that. The list per player inputs could be a dictionary with limited size and fifo order so that the oldest entries get pushed out. The gametick would be the key and the input the value. Then the programm could read the inputs depending on the time. Overflows are ignored and the program doesnt have to run every tick.
Another problem is of course that all key input interpretations except a few (in my above example only Escape to leave the input mode) had to be suspended. So for that there had to be a good solution. I would suggest a hotkey to enter such an input mode as player on the fly like ctrl-q.

As for the other quotes you made, i dont know why or for what purpose but you could add that info if you think there is something lacking.

 

first - quoting system here is quite ... well it's regular bb, but with styles and so ... sometimes it looks diffent, and i'm too lazy to reedit everything ...

Didn't know about keyboards snaphot. it makes sense. will add this to list.

As for parsing detailed info ... i take it for time being as workaround (not solution), of course i will like to have all informations either as properties (GetProperty()), or much better as accessors(fields)

As for GTS vs. IMyCubeGrid ... guess it's missunderstanding on my part, visual representation ingame mislead me.
GTS.GetAvailableGrids(List<IMyCubeGrid>) should list all grids, like terminal dropdown menu does.

If they allow access to blocks, that are not derived from IMyFunctionalBlock, i expect it will also allow access to grids, that are composed only from this kind of blocks. (eg. grid simply from blocks of armor connected on rotor, and so ono)

 

Well that is examply the use i would like to avoid. You are also mixing IMyGridTerminalSystem and IMyCubeGrid up again
IMyCubeGrid (CG) is each grid that is tightly connecte to each other, block on block.
IMyGridTerminalSystem (GTS) is what you can access through when opening the terminal screen (K).
Each GTS consists of at least one CG up to an "infinite" amount. A rotor or piston for example separates CGs.

Here is a colored image i used to illustrate the difference.


As you can see, there are five colored structures. Each of them is a separate CG. The two merge blocks within the middle (red and green structure) are not connected to each other.
The result of that is that you see five CGs (teal, yellow, red, green, pink) and two GTS (teal + yellow + red / green + pink).
I hope that makes it a bit less confusing and more clear.


So instead of having a function that takes a list and then fills a list (like your GTS.GetAvailableGrids(List<IMyCubeGrid>) example), why not just get a list right away. Like the already mentioned .Blocks and .BlockGroups properties that return a List<T>.
Btw when i talk about properties here, i mean the C# terminology. https://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx

So instead there should just be this:

Code:

List<IMyGridTerminalSystem> IMyGridTerminalSystem.AvailableGridTerminalSystems

In that case you could skip generating and populating a List<T> every time it is needed - because it doesnt change within that game tick anyway, aswell as it doesnt take any parameter to justify a method - and instead just access theem right away like:

Code:

void Main()
{
	for(int i = 0; i < GridTerminalSystem.AvailableGridTerminalSystems.Count; i++)
		someMethodThatDoesSomethingToGTS(GridTerminalSystem.AvailableGridTerminalSystems[i]);
}

static void someMethodThatDoesSomethingToGTS(IMyGridTerminalSystem gts)
{
	...
}

as opposed to:

Code:

void Main()
{
	List<IMyGridTerminalSystem gts = new List<IMyGridTerminalSystem>();
	GridTerminalSystem.GetAvailableGTS(gts);
	for(int i = 0; i < gts.Count; i++)
		someMethodThatDoesSomethingToGTS(gts[i]);
}

static void someMethodThatDoesSomethingToGTS(IMyGridTerminalSystem gts)
{
	...
}

So even though the code dosnt look like it actually is more, it does create a new list every time an then fill that list with what is static for the current game tick anyway. Thus it is redundant work.

 

i see, didn't know 1 GTS could own multiple CG ... but makes sense.

i always though GTS is actualy whole terminal system, while CG is actual entity (large ship/small ship/station), but indeed i forgot about pistons and rotors.

i see then problem here.

in some of my scripts i compare CubeGrid of PB with CubeGrid of object from list, but essentialy i want to filtr out objects, that are not part of same entity (ship/station), and there can be parts on same entity, but not is same cg (because of rotors)

guess we will need both then ... all available GTS and all available CG

 

player2k mentioned wanting to have access to know if the ship controller is occupied by a player

Also, Gloin asked for in game time. This is important for keeping track of elapsed time in the game..

Please add these to the master list.

 

As with the last time somebody made a thread like this, I'll suggest:

A method to get the cubegrid connected to a Piston/Rotor. Something like a ConnectedCubeGrid property on IMyPistonBase and IMyMotorStator.

Similarly, a method for connected connectors. So a ConnectedConnector property on IMyShipConnector.

Wouldn't input functionality be better attached to IMyShipController? If you attach it to the player, then we could steal input from a player even when not in a control seat (e.g., when detected by a sensor). That doesn't really seem to fit the game mechanics.

Also, I think kinematics (velocity,etc) would be better attached to each cubegrid, rather than the ship controller. It would be useful to have these properties for all cubegrids without having to slap a cockpit on each one. Also, you may as well ask for all the kinematic properties while you're at it (linear acceleration, rotational velocity/acceleration, moment of inertia).

 

looks like somewhere along i lost this edit when using multitab:confused:, i added imybuttonpanel, and playerinfo to list once already .... will redo it then

 

IMyShipController is interface, that is inherited by all cockpits, seats, remote and controll panel, it has nothing with player object, you not stealing anything from anyone.

IMyCubeBlock has position and orientation, you can calculate your movement, and honestly it doesn't make sense if you will access movement for any/every block in grid.

while when accessing IMyShipController (which usually has also HUD for player), information is there, therefore it's already calculated and can be forwarded.

 

player2k suggested adding the input functionality to IMyPlayer, which is what I was replying to.

I missed that you had already listed that functionality under IMyShipController (as I was suggesting).

No, it doesn't. All we have access to is the local orientation (how it is rotated on the cubegrid).

Furthermore, I wasn't talking cube blocks, I said cube grid.

As you already noted, we already can get the global position of any block and the cube grid itself via GetPosition(). Having a GetVelocity(), etc makes no less sense that what we already have. There's not much point in having it for every cube block, but we should atleast have it for every cube grid.

I'm well aware that "you can calculate your movement", I've been doing it for months. The suggestion (by others, not me) to have velocity available is to avoid having to do this (for various reasons). You can calculate your orientation too, and quite painlessly, but that doesn't stop people from asking for a simpler, more reliable method.

What I am against is tying this functionality to something nonsensical like the ship controller, whose purpose is controlling the ship, not providing kinematic sensing.

No, the "information" is not there. The GUI is merely accessing the physics properties (IMyEntity.Physics.LinearVelocity) of the underlying cubegrid. It is already calculated (by the physics engine) for each cubegrid, so there's no practical reason we shouldn't have access to it. The ship controller is completely unrelated to this, there's no need to involve it.

 

Any time based calculations (ex, speed based on change in position over time) need access to 'game time" to be accurate; otherwise the calculations break after save/load and slower than 1x game speed.

 

I would prefer to get the actual block, which then in return can get the .CubeGrid. That seems to be a more versatile approach.

Well the input is directly linked to the IMyPlayer or client as that is the origin. Using an IMyShipController would limit you again in several ways. Most noteable you wouldnt directly but only indirectly know whos input that is and you had to have a IMyShipController for inputs.
But like i said, that would require a good and clean approach. So maybe even a system where the access to read a players inputs had to be requested (once the player pressed a hotkey to listen to them). Then he sees basic informations about that request like what the blocks name is, which direction and distance aswell as who the owner is.

To prevent request-spams, only one request per X seconds (configureable?) per block aswell as in general is allowed. So to give example values, each block could request only once every 5 seconds and in general only once every second a request can pop in.

The requests would be like a fifo list that is visualized at the side. When the player/client disables the listening mode again, all requests are automatically declined.
The listennning mode could also run in different access levels, only own blocks, faction blocks, all blocks. Any block that does not suit the filter will automatically get declined.
Also only one request can be accepted. Once one has been accepted, the others get declined aswell.

Sure not very easy, but also not that complicated. There just has to be a good model, thoughts about abuses and potential fixes.

Indeed. I was sure that i said that too, but apparently i just read if off another threads suggestion.
Fact is though that each CubeGrid is a collection of physical entities that acts as one in a certain degree, thus the relevant informations like orientation, velocity, mass etc should be read there.

Could you also add the suggestions to the OP?

IMyMotorSuspension
- Expose wheel and steering angle. Access rotation speed and steering angle.

IMyOreDetector
- Get ore informations (Position, Type) of ores.

IMyButtonPanel
- Get a list of pressed timestamp+button/IMyPlayer} pairs

Also please change the input API to the IMyPlayer interface and not to the IMyShipController as that makes little sense following my above explanation here.

 

That's what I indicated for connectors (return the other connected connector directly), so I assume you're referring to the piston/rotor case? I didn't suggest doing the block directly there because I don't know if all blocks (for example, armor blocks) have the IMyCubeBlock interface, so I thought it was safer to just return the attached cube grid instead. If all blocks have that interface, then yeah, I would prefer returning the directly attached block as well.

This is the part I objected to ("doesn't really seem to fit the game mechanics"). It feels "cheaty" to me for the player to be able to provide input from anywhere. Some object needs to receive the player's inputs and I think that object should be the one tracking key presses.

How about this. A new interface IMyInputDevice that objects can inherit from and a new control key to activate "input device" mode. In this mode, until the player presses some quit key, all input is captured and made available via that interface. This way various blocks like control chairs, lcd/text panels, key pads, etc can implement the "input device" functionality. Then players will have to interact with a physical device to provide input avoiding my "cheaty" complaint as well as the "request spam" problem you mentioned. (A terminal action to activate the mode would be nice too, but it would have to be restricted to only work on the cockpit,chair the player is occupying.)

 

Well i imagined that as small keypad on your wrist or even a BrainComputerInterface, which isnt far-fetched either.
So i could see it as handtool too, you standing in front of a text panel and are able to access it on the fly. If handtools were accessible from non-pilotable seats like the passenger seat, that would be ideal.
A new block really is the last option i would like to see.

So my prefered approach would be to accept a build-in keypad, much like we got a build-in antenna too, to access them.

Edit:
We can also access a gridterminalsystem for "anywhere" within 200m of antenna range. Modern smartphones got a pretty good range with wireless technology too. Thus it doesnt seem to be that cheaty to me.

 

The problem is your argument basically applies to the interface as a whole. We have HUDs today, and high quality augmented reality setups seem likely to happen in the next 60 years. Various kinesthetic controls could be built into the suit. This basically obviates the need for a whole host of blocks in the game: Ship controllers (VR remote control), keypads, lcd/text panels, buttons, etc.

This doesn't matter anyways, I'm not arguing based on realism grounds (I hate realism arguments, I want the game to be fun, not realistic.). I'm arguing based on game mechanics. And currently, controlling things on ship (antenna interface aside) requires interacting with a physical object. And while you can technically control everything on your ship via the Terminal system interface, it's not very fun. If you insist on being able to provide input from anywhere, do it the same way as cameras, remote controls, etc: have a "Provide Input" button in the Terminal interface. But the primary interface should always be physical.

I wasn't suggesting a new block, quite the opposite in fact. I was suggesting integrating this input functionality into pre-existing objects. You would walk up to a text panel or keypad and press the "input device mode" key, then any keys pressed could be captured by the PB (while you stand there). Using the key on a cockpit/flight seat would still seat you in it and provide the HUD/view, but remove the toolbar and disable flight controls (in favor of capturing the input).

 

i think, both of you should be content with formulation bellow

All blocks allowing grid connection/separation
- missing method for retrieving connected grid

 

I think what we concluded was "retrieving connected block (or grid if block not possible)".

I know in the connector case, I would definitely want the block, not the grid, as finding the companion connector from its grid is non-trivial.

 

connector is explicitly specified, but for other it might be quite problem, until we get access to regular blocks (eg not derived from IMyFunctionalBlock), you will not be able to get block that is connected if it's for example armor cube (eg. ship parking at landing "area" from AC or BD blocks)

 

I propose that these functions be moved from
Sandbox.ModAPI.IMyCubeGrid
to
Sandbox.ModAPI.Ingame.IMyCubeGrid.

Vector3I WorldToGridInteger(Vector3D coords);
Vector3D GridIntegerToWorld(Vector3I gridCoords);
void ColorBlocks(Vector3I min, Vector3I max, Vector3 newHSV);
void ConvertToDynamic(); // converts station to ship
bool CubeExists(Vector3I pos);

It would be a super simple change that would break nothing, since Sandbox.ModAPI.IMyCubeGrid inherits from Sandbox.ModAPI.Ingame.IMyCubeGrid.

 

Oh, I didn't see that. Sorry.

That's basically what I said, above, but if we could get blocks that would be ideal. Hence the fallback "grid if block not possible".

Hmm, I can think of evil things that could be done w/ this... (A giant armor block display, for example)

We used to have access to this, but it was removed (sometime in Feb. IIRC). I would like to have it back, but since it was explicitly removed I assume Keen probably has a reason for it.

 

That would be cool.
They have added things "just for the fun of it", like space balls and artificial masses.