ModAPI Changes: Jan 26

Massive ModAPI changes, fixes, improvements, candy, possibly even some clang. Who knows?!

Thanks as always to @Phoenix84 and @Malware for their contributions. They should show up in this thread shortly with more documentation.

Other community contributions by @Inflex and @Elfi Wolfe

MyGameLogicComponent:
First off, there's been some changes to MyGameLogicComponent. This is the class you inherit when you want to attach a script to an entity. Some of you have noticed that blocks randomly stop updating. This is because we are slowly optimizing block logic. When a block no longer needs to run, it simply turns off updates. This has caused no end of headaches for modders, so we've brought you a solution.

Code:

[MyEntityComponentDescriptor(Type, params string[])]

is no longer valid. VS will warn you, the game will warn you, and there's a big fat nasty warning in the game log. Mods using this attribute constructor will continue working as-is in the old system. That means that your script will slowly, silently just stop working. To update to the new system, simply change to this:

Code:

[MyEntityComponentDescriptor(Type, bool, params string[])]

The middle parameter is for EntityUpdate. If you set it to true, your script will use the old system. That means your script will run at the same time as the block's game logic. Use this if your code is timing sensitive. But do keep in mind if the block stops updating, your script will also stop.

If you set EntityUpdate to false, you get the new system, which is where all the fun happens. The new system updates your script completely separately from the container entity. This means that your timing can be off. The entity's Update10 method can run on frame 1, but your Update10 might not run until frame 9.

Also if you set EntityUpdate false, the script's NeesUpdate flag is decoupled from the entity's. You must set MyGameLogicComponet.NeedsUpdate, or your script will never run. You can do this in your Init method, as that will still be called, or you can set it outside your class from a session component or something.

ModAPI Changes and Improvements:

• IMyUtilities.SerializeToBinary and SerializeFromBinary. These methods use ProtoBuf behind the scenes to transform an object to and from a byte array. Perfect for sending data over the network.
• IMyMultiplayer.ReplicateEntityForClient. Forces the server to send an entity to the selected client, even if it's not in their render range.
• Inter-Mod communication. In IMyUtilities, you'll find new methods for registering and sending events, almost identical to the network communication mods have now. Instead of <short, byte[]>, you get <long, object> so you can pass any data at all between mods on the same client.
• IMyFactionCollection.AddNewNPCToFaction. To help you create NPC-only factions.
• IMyFactionCollection.Factions. So you can iterate through all factions in the world.
• Drawing. A lot of the methods in MyTransparentGeometry used Vector3 input parameters, which can cause precision issues. These have been changed to Vector3D.
• IMyPrefabManager.SpawnPrefab has been updated to include an optional callback parameter. Since prefab spawning is done in parallel, you had now way to know when the spawn was finished. The callback is run when spawn is finished, which should solve this problem.
• Fixed ownership not being set correctly on prefabs.
  
• Hand tools now have an OwnerID property which gives you the EntityId of the owning character. Also an OwnerIdentityId that tells you which player has the tool.
• IMyCharacter.EquippedWeapon gives you the EntityId of the equipped tool/weapon.
• IMyGui.IsCursorVisible. I'm not explaining this.
• IMyProjector.SetProjectedGrid. Mods can load any grid objectbuilder into the projector.
• IMyLargeTurretBase.Target. Returns the entity the turret is currently targeting.
• Fix nullref exception in IMyGui.ActiveGamePlayScreen
• Fix missing member of IMyGui.MyTerminalPageEnum
• Fix IMyGui.RemoveScreen event not firing
• Fix IsShooting property on turrets. Will now trigger correctly when AI fires, or the player is directly controlling turret.
• IMyUtilities.MessageRecieved. Event raised when the client receives a chat message.
• DOCUMENTATION! The assembly XML files for all the ModAPI documentation are now included. This means documentation present in the github sources will no longer be missing in Visual Studio when you add a reference in your mod. They'll all be there. A lot of what's in that spreadsheet below also has their own XML documentation, which better describes them. In total there is 2.5MB of raw XML documentation for SE (not including 3rd party).
  
• Fix for SessionComponents with the same class name not loading properly in mods
  
• Fix for workshop items failing to publish
  
• Fix for scripts with the same filenames causing compilation issues
  
• Fix for mods not downloading properly after updating
  
• Added the ability for mods to have collision models on custom entity subparts (without using doors), all subpart collision meshes are now visualized in the debug physics draw.
  
• Added ability to get dummy information, including name and transform matrix, from models.
  
• Added ability to get the character's UseObjectComponent, to see what the player is pointing at
  
• Added IMyGamePaths.ModScopeName which returns your mod's specific path (such as 123456.sbm_Name). This is suitable for appending to paths for loading models, logging, etc...
  
• MySessionComponentBase now has the property ModContext, which is the context for your mod (specifically, the mod that defines the class). This contains the mod name, workshop ID (if applicable), path on disk, and your data path. This is useful for loading models on demand.

PB API Changes:

• IMyShipController.CenterOfMass. Gives you the center of mass in grid coordinates (Vector3I).
• MyShipMass.PhysicalMass. Returns the mass of the ship as seen by the physics engine, which takes inventory multipliers into account.
  
• Added System.Linq to the usings. Enjoy your allocations Linq.
• IMyLargeTurretBase.HasTArget. Returns true if the turret is locked on to something.
  
• Fix accessing MyTerminalControlCombobox from PB. This means PB can set fonts. Rejoice! Thanks @Inflex!
  
• Add IMyThrust.MaxEffectiveThrust. Tells you how much thrust the thruster can provide, taking into account atmospheric effects. Thanks @Elfi Wolfe!
  
• Fix Conveyor Sorter API.
• Add more overloads for IMyCameraBlock.CanScan
• Add ConnectedGrid and other properties for pistons and rotors.
• Add StringBuilder overload for IMyTextPanel.WritePublicText
• Add IMyTextPanel.ReadPublicText to return a StringBuilder. Saves .ToString allocations.
• Fixed the debug draw for camera raycast.

From Phoenix84:

You guys might remember a request a made oh, about 6 months ago, for suggestions on ModAPI improvements.
Well, after lots of work (and waiting), I present to you the fruit of that labor.

This is a near-complete list of the items added to the ModAPI and Ingame PB access.
Done by both Malware and myself. This does not include all the items added by rexxar, such as PB comms.
Huge thanks to Malware for working on the majority of the Ingame side.

I hope to get more added in the future, of course that depends solely on Keen.

 

wooo! Thanks for the great work!

 

So many additions to ingame scipting for the recent time. Thank you!

 

Did I read it right? We can finally set queue for assemblers? Set sounds and know status of laser antenna?
IMyButtonPanel changes: does it mean it is possible to know if a button from specific panel was pressed?
Do I smell the possible increase in character count for ingame scripts too?
Its axciting!

 

That's how I read it too. Assemblers inherit from IMyProductionBlock so yeah, queuing FTMFW!!!

It looks like ModAPI already had most of those methods, though 2 new ones were added. The PB didn't have those and was (I assume) a major limiting factor in the TIM system's ability to manage production. TIM has workarounds but a direct ability for it to manage queues and item building should make a significant improvement in functionality. For those who have built out automated building systems, you had to build a specific assembler per component type and TIM could toggle the objects off/on. This didn't allow for the assemblers to slave well and was generally not efficient. If this works as I hope, we'll be able to build slaved assembler setups and TIM should keep up with component queues easily. Today is a great day!!

 

This doesn't seem useful. Vector3I's are backed by integers and grid coordinates are completely imprecise (On Large Grids, the difference between 0,0,0 and 0,0,1 is 5 meters in the world). Center of Mass will rarely perfectly line up with the Grid coordinate's integer.

A Vector3 that is in "Grid Offset" would be much more useful, so we can actually use the Center of Mass for precise physics calculations. Otherwise, I'll still have to try to find the CoM on my own to get a CoM with better than 5m precision.

 

No, PB cannot set the assembler queue. It isn't possible to allow that right now because of the way the code is structured. We can't add the types needed because it causes a circular dependency issue and the compiler just falls apart. I have no idea when or if this will ever be fixed.

 

So technically it can but the compiler will break if we try eh? >.<
As for sound block, will there be a method to get a list of all avilable sounds so use can pick from them, or in the very least check if a sound avilable insted of trying to set it and check if a sound is selected?
--- Automerge ---
oh and my question about the button panel..?

 

Well.. I just seem to have set the assembler queue with an in-game script..so it seems to work fine?

EDIT:

Script To Build 1000 Steel Plates Below:

Sorry about the edits. Wasn't expecting to publish it. Should be working now.

If you want to know the item ids to use then make sure it's attached to an lcd and then simply start creating items manually in the assembler, which will cause the screen to list the id's and amounts. You can just copy them in to the script above.

 

Will it be okay to use parts of this in station OS script I work on, or if you plan to publish this as fully flagged script then add extention so other scripts can support this and call it from outside?

 

Isn't there already a mod that expands the PB API that allows this function?

EDIT: replied too soon. Should have read the rest of the thread.

 

Feel free to use it modified or as is, anywhere you like. Same goes for everyone else. I look forwards to seeing what you do with it.

 

rexxar, I'd love to hear if you have additional thoughts on the assembler queuing from the PB. I've been mapping out ideas for a TIM system built into a mod that might be more performant and less steps to setup. If queuing is limited in the PB, do you see any concerns with doing it via a mod?

 

Those id's are not unique. They change for every assembler block. Or at least that's how it was explained to me

 

it unique. but looks like something exposed where it must not.
without way to take definitions it's useless.

 

It would take about ten minutes to list off all the definitions on the LCD and hard code them into a script for everyone to use to build whatever they like really. Quite frankly, getting the definitions isn't an issue at all.

I'm happy that it's been finally added, to be honest.

 

You could save those definitions to the Storage of a PB so you don't need to hardcode it for every script

 

EDIT: ooh weird..I inadvertently deleted my post. Recreating...

A little experimentation says otherwise. The script below adds 1000 steel plates to all of the assemblers on your grid.

Sounds good to me.

EDIT: Wow, this automerge thing is annoying.

 

Did the complexity limit for PB's change?

 

Those definitions are in one of the game files, cubeblocks? I cant remember, Ill check tomorrow and post when I have the answer.

 

Linq, Mass AND Thrust for PBs? This is great!

 

This is awesome! The Linq thing will be really useful! Does it have full access to system.linq so that I can simplify all of my codes with linq?

 

What is linq?

 

I just tested IMyThrust.MaxEffectiveThrust on an hydrogen thruster which was not connected to conveyor network (so it was not able to get the hydrogen), and its MaxEffectiveThrust was equal to MaxThrust, i think in this scenario would make more sense if MaxEffectiveThrust = 0. I also suggest to take into account power overloading since it can decrease the thrust of ion and atmo thrusters, and regarding hydrogen thrusters the MaxEffectiveThrust should also take into account situations where the supplied hydrogen is not enough to reach MaxThrust. Anyway big thanks for all this changes.

 

VRage.Game.ModAPI.Ingame.IMyCubeGrid CustomName get/set Get/set the grid name (as seen in Info tab)
=> seems to be missing for the regular ModAPI, or does ModAPI have access to all the stuff within the Ingame Namespace?

PS: WOW! so much change, so much new stuff to discover Great job guys

 

@Chrison
ModAPI does have access to the ingame ones but there's no need to use those since the modAPI ones extend the ingame ones.

 

wow, thats incredible update

 

linq. Finally !

AFAIK you had to type all "System.Linq.Enumerable...

 

For the Hydrogen that would be for the pilot to worry about.
and as for account power overloading... if you are already overloaded the computers have already shutdown on your ship.

 

Thanks mate, I was too lazy to open visual studio and have a look :-D
I knew something inherited the other one but not which way it worked