Changes to the ModAPI - 16/03/2016

What's the alternative then ?
A lot of the blocks don't have a modding-dedicated interface and using the .Ingame one is the only good choice.

 

how about every block that has Ingame interface?
then we can discuss, which fields with getters we also want to have setters.

i will give diff between ingame and modapi later, if digi is not faster.

 

@Xocliw following interface list is based on current sourcecode (001.125.001) - please mind i have not checked whitelisting in IL compiler, but i somehow expect ALL those whitelisted
as start it would be good if EVERYTHING in column B is also in column A

 

Not sure why you listed all of those.
Half of them will absolutely never be added to the ingame namespace.
A PB will never have access to voxels, configs, UI, or GPS.
GPS might be useful, but also very spammy, so that won't happen.

However I do agree all the Ingame ones should be in the ModAPI. I think @Xocliw's warning is not as bad as it sounds.

 

phoenix please ... again ... i didn't ask about adding modapi interfaces to ingame.
i listed all, to have it covered, and want all items in column B (ingame) to be present on column A (modapi).

i'm quite aware there are lot of interfaces in MODApi that should never ever be present for PB.

 

I know what you were asking, my point was why did you waste your time documenting interfaces that have no bearing on this discussion?

It adds noise and confusion.

 

it's simple output from interface dump, i didn't waste more time than converting csv into google doc sheet, and using sort, because output was not sorted alphabetically (since it was going trough xml from class diagram)

 

I certainly would like to stop using Ingame namespaces in my mods, as the namespace conflicts are irritating to deal with, but there are still interfaces which do not have an equivalent in the ModApi.

IMyShipConnector
used to find conveyor connected grids.

IMyShipGrinder
self explanatory.

IMyShipController
base type for cockpits and remote blocks.

Also,
the Ingame namespace needs to be whitelisted, otherwise when you call any property on it through the ModApi interface, you get the "blah.Ingame.blah used in xxxxx not allowed in script".

 

I have a few mods that use the IMyGravityGenerator* ones and IMyCockpit as well. But I'm certain that throughout all the mods that all the Ingame ones are used.

Empty interfaces that get extended by the ingame ones (like IMyTextPanel) would be good enough to avoid Ingame namespace alltogether in mods.

And VRage.ModAPI.Ingame isn't whitelisted ? That'll certainly break/limit a lot of script mods

 

Thank you. Truly. There are more than a few that don't think you guys/gals do enough, but you are obviously going above and beyond your minimum job requirements. From the rest of us, again, thank you for your dedication. We do appreciate it.

 

there should not be "ambiguity" issue with mod compilation, unless author has declared

Code:

using Sandbox.ModAPI;
using Sandbox.ModAPI.Ingame;

eg. both namespaces
it should give him ambiguity issues already though, with many block and interfaces
of course such scripts can exist and i understand your concerns.

anyway, thanks for your time.

 

You would bring your solutions to the fact that mod's can not be installed from the workshop, and will be required to run through -plugin, i guess.. modding is dying. =(

 

i think is rather opposite, so mods will finally have clean interface, that doesn't change now and there, and there will be less issues with compatibility.
of course old mods will suffer, but mod that has been created, uploaded, and then not maintained, doesn't deserve anything else.
mods are mostly not maintained, because their authors stopped playing game.

 

but this interface, no one will not be maintained and never be expanded ... ie it will be useless. Up to now there is no way to create dialog boxes!

 

Interface is term and doesn't refer to UI in this case.

as for UI, there is rumor going on about customizable UI, when UI gets rework ... i say rumour, since i read it from different sources, but never seen any note from KSW regarding this - except "current UI is only placeholder, we will make some better".
if you look trough UI code on github, you will see it's currently not exposable to modapi.

but regarldes UI programable interface is exposed to modapi or not. first step to help maintaining mods is having unified namespace and interfaces.

 

Well, this wasn't that bad, for me at least, only had to update 4 out of my ~20 script mods

But this won't be the last refactoring that's for sure :/

 

in order to you understand what I mean. "While doing surgery, patient had died." The first step was taken in 1000 steps back. Now twitching late, you just wrap the this web. So how do keen, spit on mod which broke for the patch, making their work more useless and harmful.

You have my deepest condolences and experiencing about it.

 

@JimLess no, it's you who is missing point.

while you are right, it might come late for some, and i will not defy it.

Point is, that step has been finaly taken, and if it leads to modapi without changes, that requires you to fix your scripts every few weeks, it's good step, regardless how late it come.

 

It appears that ingame scripts for the programable block can't access the ingame namespace either

i discovered this when i noticed that MMAsters configurable automatic LCD's was broken by this update and the error on the block referenced the ingame namespace

this is a pretty major break since to the best of my knowledge this mod is a programmable block script and should still be able to use this namespace

also since this is used for displays on probably damn near 90% of blueprints and since its a script not a mod updates will not be pushed to existing ships unless each block is manually updated

I think it somehow blacklisted ingame scripts downloaded from the workshop despite them not being mods

 

Be careful with any program you open the .sbs file with to edit the PB script, as you can unintentionally add extra whitespace and linefeed characters, making the script too long to work.
The LCD script by MMaster like many others are close to the character limit, and would not pass the check for compiling.

 

In my mod scripts I have found two interfaces so far which require "ModAPI.Ingame" as of patch 1.127:
IMyBeacon (Sandbox.ModAPI.Ingame)
IMyGridTerminalSystem (Sandbox.ModAPI.Ingame, beware that also the parameters of its methods require types of this namespace ! E.g. Sandbox.ModAPI.Ingame.IMyTerminalBlock instead of Sandbox.ModAPI.IMyTerminalBlock)