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.

Changes to the ModAPI - 16/03/2016

Discussion in 'Modding' started by Xocliw, Mar 16, 2016.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. Xocliw Public Relations Staff

    You will find changes coming soon to the ModAPI below. We tried to make most mods compile with the new references and also to update the using but it is still possible there are some mods that are using references directly to namespaces and won't be replaced automatically. Those mods will have to be updated. Also, scripts cannot be updated automatically.These changes will continue to happen until the Sandbox API has been completely refactored. We are sorry for any inconvenience but this process is necessary and will help us develop the game more efficiently.

    It is also worth mentioning that "ModAPI.Ingame" is not valid in mods, it is only for ingame programmable scripts and should not be used in normal mods

    Sandbox.ModAPI.Ingame -> VRage.Game.ModAPI.Ingame
    VRage.ModAPI.Ingame-> VRage.Game.ModAPI.Ingame
    added /Sandbox/Sources/VRage.Game/Components/IMyComponentOwner.cs
    (removed from /Sandbox/Sources/Sandbox.Game/Game/Entities/MyRadioBroadcasters.cs)
    Sandbox.ModAPI.Interfaces -> VRage.Game.ModAPI.Interfaces
    VRage.Game.Components -> VRage.Game.Components
    Sandbox.Common -> VRage.Game
    Sandbox.ModAPI -> VRage.Game.ModAPI
    Sandbox.ModAPI.Ingame -> SpaceEngineers.Game.ModAPI.Ingame
    Sandbox.ModAPI -> SpaceEngineers.Game.ModAPI
  2. Digi Senior Engineer

    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.
    • Agree Agree x 2
  3. Xocliw Public Relations Staff

    In that case, please inform us about blocks that you want exposed to ModAPI and we will add them ASAP. For now, use only .Ingame for critical situations.
  4. mexmer Senior Engineer

    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.
    • Agree Agree x 2
  5. mexmer Senior Engineer

    @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

    • Like Like x 1
    • Agree Agree x 1
    • Informative Informative x 1
  6. Gwindalmir Senior Engineer

    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.
  7. mexmer Senior Engineer

    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.
    • Agree Agree x 2
  8. Gwindalmir Senior Engineer

    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.
  9. mexmer Senior Engineer

    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)
  10. midspace Senior Engineer

    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.

    used to find conveyor connected grids.

    self explanatory.

    base type for cockpits and remote blocks.

    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".
    Last edited: Mar 17, 2016
    • Agree Agree x 4
  11. Digi Senior Engineer

    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 :(
    Last edited: Mar 17, 2016
  12. fremen Developer Staff

    Hi guys,

    We can't add ingame using namespace by default through our "compatibility" feature because it would cause ambiguity between the interfaces in many mods.

    I'm not going to promise anything, but i will try to make the interfaces for all ModAPI.Ingame ones for the next week in my free time ;>
    • Like Like x 2
  13. Lord Bhael Apprentice Engineer

    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.
  14. mexmer Senior Engineer

    there should not be "ambiguity" issue with mod compilation, unless author has declared
    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.
  15. JimLess Trainee Engineer

    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. =(
    Last edited: Mar 17, 2016
  16. mexmer Senior Engineer

    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.
  17. JimLess Trainee Engineer

    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!
  18. mexmer Senior Engineer

    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.
  19. Digi Senior Engineer

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

    But this won't be the last refactoring that's for sure :/
    • Agree Agree x 3
  20. JimLess Trainee Engineer

    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.
  21. mexmer Senior Engineer

    @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.
  22. mikeloeven Senior Engineer

    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
    Last edited: Mar 19, 2016
  23. fremen Developer Staff

    You could open you *.sbs save file (as there are all the blocks saved with programs included) and rename them to correct namespaces).
  24. midspace Senior Engineer

    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.
  25. Lynnux Junior Engineer

    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)
    Last edited: Mar 25, 2016
Thread Status:
This last post in this thread was made more than 31 days old.