Allow the MyObjectBuilder_WarheadDefinition to have a configurable WarheadExplosionDamage, the same as the MissileAmmoDefinition.

This way, the damage could be either toned down, or boosted.
An internal Maximum could be imposed if there is a physics limitation on applying damage.

One of this ingame PB pb is missing is access to assembler queue.

It seems not hard to make current queue visible, but i'm not sure if it will be safe (well i'm pretty sure, it will not), therefore queue will need to be accessed either by functions (addtoqueue, removefrom queue), or using interface (IMyQueue), like is for IMyInvetory.

I'm more inclined to IMyQueue (or whatever we will call it) as safe access to queue

ideas welcome

The "landing gear" bug.

Sometimes there are vibrations/wobbling at joints heralding impending doom. Detaching the joint (e.g. detaching a landing gear) would then cause sudden velocity change of one/both attached grids resulting in catastrophic collision damage to what it's attached to/anything close by.

Landing gears, rotors, pistons and connectors all seem to be affected by this issue, but I nickname it the landing gear bug as it's the easiest to reproduce and most dramatic during failure. Having multiple joints attached to a grid increases the probability/strength of the issue. Merge blocks are not affected as far as I can tell.

In-game the joint looks like it is accumulating energy, sometimes instantly or sometimes over time. I suspect a rounding error or similar possibly in the netcode (it happens very frequently in MP/DS, not sure about SP).

Until the root issue is resolved a possible workaround for shattering gears/connectors: during joint detachment, check relative velocity between grids and ensure they are sane. If not, forcibly set it to something reasonable before calling Physics.RemoveConstraint. Things are likely to keep wobbling but at least they don't shatter when you press p.

Hoping with source visibility the mod community may have advantage in eyeballs to finally close this out.

find a better game than this. You are really awesome KSH. Keep doing what you do. The community will always stay with you 👍

On many multiplayer and especially modded servers there is a big need for simple mechanism to disable vanilla blocks for many reasons. Repeating entire entry and adding false seems to be very over-bloated way to deal with it.

Wouldn't entry like this:

be enough?

or even introduce
false
Since public might be handy to keep pre-build stuff on the server.

Maybe it's time to make the dedicated server more friendly to multi-core server processors?

Has anyone started working on this?

I have yet to dig through the source code to find my answer, but just in-case anyone else has the same thought as me, here's my question:

Does anyone see that it might be possible for the server to periodically send a new skybox to all connected clients and have the client change to the newly uploaded skybox? This would pave the way for some really interesting things:

1. Animated skyboxes... i.e, the nearest star or planet rotating. Or the Star Trek "Warp drive" effect that uses distant stars and debris to show movement. This would basically be a small movie in loop.
2. Scenario scenes... Show an approaching gigantic asteroid that gets bigger and bigger, you have to build an asteroid killer and launch it off... when the asteroid is destroyed the animation changes to that of destruction. This
3. ??? Probably some other cool things that I don't have time on my lunch break to think of

Reproduce by placing multiple panels that are set to display text, close enough to each other that you can see both of them. Turn so that only one LCD is in view. When turning back to view both LCDs, the other will read OFFLINE. Affects singleplayer as well as multiplayer.

This one's been bugging me for awhile, so I looked into it. The GetRenderTexture method is responsible for returning the texture to which the text is rendered. The method successfully returns one texture, but subsequent calls fail and return null, due to the m_currentFreeResources >= textureResourceSize check failing. The initial value for free resources doesn't seem very large to me. If I just change it, multiplying it by N, I'm capable of rendering N text panels at a time, with no apparent problems.

I think the resource limit should be set dynamically, somewhere. I'm not really sure where that should happen or what the calculation should look like.

Add the readonly property OpenPosition
to Sandbox.ModAPI.Ingame.IMyDoor

in reality it's m_currOpening.
Primarily for use in the MyAirtightDoor.

Edit:
Renamed from DoorLocation to OpenPosition for consistency with current API.

Putting this in to let people know I'm working on it. I've identified a couple of possible improvements for turret AI.

I intend to address the first two items immediately; the third will require a bit more familiarity with how communication between blocks is handled.

Aimpoint calculation: Current algorithm only considers velocity. Reworking the algorithm to also consider acceleration should increase turret utility, particularly against astronauts and missiles.

Target prioritization: Current algorithm is a simple "closest first" for all target types. For certain target types (missiles, meteors), targets where the sum of the normalized relative position and normalized relative velocity of the target is close to zero (IE: it's coming right for us, Cap'n!) should really have the highest priority, though distance should remain a factor. This is the highest priority item; currently, meteor defense is very unreliable, which is frustrating.

EDIT: See pull request #65 .
EDIT: No longer considering the following part of the same issue:
Distribution of targets between turrets: Ideally, we should have a way of spreading the targets out a little between the turrets on an individual ship. One way of doing this is adjusting each target priority by a random amount, so that the more alike the priorities of two targets are, the more likely it is that the turrets will pick a different target at random. A better (but harder) way is to arrange for a shared target list between turrets on the same ship, or somehow partitioning the space around the ship into different fields of responsibility assigned to different turrets. This is a lower priority item than the above two, though.

Access to the IMyStorage CreateStorage(byte[] data) from an external point other than IMyVoxelMaps. This will require specifying VoxelMaterials.

This is to provide access to externals tools like SEToolbox or from within Keen's own VRageEditor tool as another plugin, to building custom Voxel Asteroids.

This unnamed class should not be white-listed for use in the Mod API.

Expected methods:
IMyStorage CreateStorage(byte[] data);
LoadMaterialData(IEnumerable voxelMaterials)

Additional details:
Would like to also be able to use some of the MyVoxelShapes.
IMyStorage will naturally provide the method; Save(out byte[] outCompressedData)

Perceived issues:
The low level classes may be too intertwined with live game data syncing to allow use without having to load the entire game engine.

This is a sample application to test what is available at the moment, and the issues I'm running into.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using Sandbox.Engine.Voxels;
using VRage.FileSystem;

class Program
{
    static void Main(string[] args)
    {
        // Make sure the following are available/copied into the bin path:
        // Be aware if you are running x86 or x64 to use the appropriate .dll's.

        // HavokWrapper.dll
        // Sandbox.Common.dll
        // Sandbox.Common.XmlSerializers.dll
        // Sandbox.Game.dll
        // Sandbox.Graphics.dll
        // SharpDX.DirectInput.dll
        // SharpDX.dll
        // SharpDX.XAudio2.dll
        // SteamSDK.dll
        // steam_api.dll
        // steam_api64.dll
        // VRage.Audio.dll
        // VRage.dll
        // VRage.Input.dll
        // VRage.Library.dll
        // VRage.Math.dll
        // VRage.Native.dll


        // Game Content path.
        var contentPath = @"C:\Program Files (x86)\Steam\steamapps\common\SpaceEngineers\Content";

        // base User path.
        var userPath = Environment.ExpandEnvironmentVariables(@"%AppData%\SpaceEngineers");

        // Our test asteroid.
        var filename = Path.Combine(contentPath, @"VoxelMaps\Arabian_Border_7.vx2");

        try
        {
            // Force loading of the SteamSDK into memory, so the remaining Types in Sandbox.Game are available when MyOctreeStorage is initialized.
            //var ass = Assembly.Load(new AssemblyName("SteamSDK"));

            // Initilize the FileSystem. This is required for MyDefinitionManager to call LoadData().
            MyFileSystem.Reset();
            MyFileSystem.Init(contentPath, userPath);
            MyFileSystem.InitUserSpecific((string)null);

            // Call LoadData() to load up all the base definitions.
            // ##### static MyDefinitionManager.ctor() calls MyObjectFactory.RegisterFromAssembly(). This will forcefully load all the Types in Sandbox.Game.dll.
            // ##### There are a lot of dependant Types that need to be loaded.

            // #####
            // Here is where it all breaks down, as MySandboxGame has to be created in memory to be able to 
            // load Voxel Material Definitions. Other definitions will load, but the Voxel Material is dependant on the game engine.
            Sandbox.Definitions.MyDefinitionManager.Static.LoadData(new List<Sandbox.Common.ObjectBuilders.MyObjectBuilder_Checkpoint.ModItem>());

            // Check that materials exist.
            var materials = Sandbox.Definitions.MyDefinitionManager.Static.GetVoxelMaterialDefinitions();

            // Attempt to load the Voxel file.
            // If the specific Voxel materials that the asteroid requires are in the MyDefinitionManager memory, the voxel will load.


            // ##### static MyOctreeStorage.ctor() calls MyOctreeStorage.RegisterTypes(). This will forcefully load all the Types in Sandbox.Game.dll.
            // ##### There are a lot of dependant Types that need to be loaded.
            var storage = MyStorageBase.LoadFromFile(filename);

            Debugger.Break();
        }
        catch (Exception ex)
        {
            // Check your exception.
            // "The given key was not present in the dictionary." will mean, you are missing a required VoxelMaterialDefinition.
            Debugger.Break();
        }
    }
}

Tracking down what could be the reason for this bug. It's one of the serious bugs that ruined a joy of survival mode.

Add the readonly property CurrentPosition
to Sandbox.ModAPI.Ingame.IMyPistonBase

Add Access to the MyObjectBuilder_ShipBlueprintDefinition player repository in the MyBlueprintDefinitionBase.

Much the same way GetPrefabDefinitions() and GetPrefabDefinition(string id) work.
return a list, and return the CubeGrids in the Player's personal Ship Blue prints.

ShipBluePrints are not static like Prefabs, and can change during game play.

In modding, if you make a block that has its collission model placed outside of the block's grid position, you won't be able to weld/grind it if another block is next to it (in the gridspace where the collission would be).

To explain better:

The red block is my custom block, the black block next to it is a button panel and the green things are their respective collission boxes.

If you have just the red block you can aim at it only by aiming through the collission box towards its placement box, but if the button panel (or any block) is there, aiming at the red block's collission selects the button panel instead.

i would like to be able to access PowerConsumer with ingame api, so we can write power management scripts without need parsing data from detailed info (which is also incomplete)

values what i think we need
IsPowered
IsAdaptible
MaxRequiredInput
RequiredInput
CurrentInput

MyRenderComponentBase has a PersistentFlags field which can have a CastShadows flag, removing that flag does not disable the shadows on the object.

In case there's doubt about how I use it:

        private IMyEntity SpawnPrefab(string name)
        {
            PrefabBuilder.CubeBlocks[0].SubtypeName = name;

            MyAPIGateway.Entities.RemapObjectBuilder(PrefabBuilder);
            var ent = MyAPIGateway.Entities.CreateFromObjectBuilder(PrefabBuilder);
            ent.Flags &= ~EntityFlags.Sync; // don't sync on MP
            ent.Flags &= ~EntityFlags.Save; // don't save this entity
            ent.PersistentFlags &= ~MyPersistentEntityFlags2.CastShadows;
            ent.CastShadows = false;

            MyAPIGateway.Entities.AddEntity(ent, true);
            return ent;
        }

That spwans all my custom entities which all have shadows, the other flags with no sync and no save work fine.

I have no real clue how to fix this myself though.

By including this variable in IMyShipWelder, IMyShipGrinder, and IMyShipDrill, in-game programs will able to determine if a tool block is being used, and take action according to that value.

MyDirectXInput.GetJoystickAxisStateForGameplay() says it returns 0 to 1 but it actually returns even higher than 1 if you have sensitivity high enough.

EDIT: Hmm, on further looking around I belive it works as intended but the comment is misleading instead.

Due to conflicts inherent to using MyGameLogicComponent scripts, using them is not always ideal.
This is especially an issue with upgrade modules and the fact we can't create our own block types.

If you have a custom block script using MySessionComponent, and load a world with already placed upgrades, they will not get refreshed and loaded.
They require an event, like block placement, to trigger again.

I propose triggering this refresh event during a more common operation as well, such as power changes.
I have a proposed patch I will attach to this defect.

There are few blocks, that are not devived from MyFunctionalBlock, but from MyTerminalBlock,
as a result these blocks cannot be turned off. (this of course applies also to their I interface for PB/modapi)

It's following blocks
MySolarPanel
MyOxygenFarm
MyShipController
MyButtonPanel
MyControlPanel
MyWarhead

MySolarPanel, suppose it's not an issue, there is no benefit in turning solar off ... but it's inconsistency

MyOxygenFarm, you most likely will not find situation when you will want to turn it off, except times when you will want to conserver energy (there are construction, which put oxygen behind blastdoor/hangar door, so why they should consume energy, when they don't produce oxygen ???)

MyShipController, MyButtonPanel, MyControlPanel - there might be times, when you want to disable them, but you can't there is no way (for ship controller at least main cockpit disables it partialy) - if they were inherited from MyFunctionalBlock, they will have enable action, like other blocks

MyWarhead - here might be inheritance intentional, so you will not be able easily disable warhead, but then again, inconsistency

just for consistency it would be better, if all functional blocks are inherited from same class without exception.

Example:

• Pressing 2x ALT results in the third person view resetting to center.

I looked at both the script for the drill booster as well as the drill code in the SE source and it looks like the drill definition already contains 2 properties;

SensorRadius
SensorOffset

These directly control the drill's area of effect on the asteroids mined by the drill. I think it would be very useful if these two could be exposed via ModAPI so that the scripting for the booster could modify these as well as the effectiveness of the drill as well. Do you think this is a valid addition to ModAPI or should these properties remain as part of the drill definition only?

Markam67

There is some idea for improving LCD screens :

• Able to choose a monospacing font
• Able to set colors (background/foreground) of each characters (and not only screen)
• Access to the display matrix of the screen

A humble request, transparency options for LCD screens' background and text.

I keep getting a definition error after running or debugging the project.

Unable to find audio file: 'RealWepPlayRifleImpMetal', 'REAL\IMP\RealWepPlayRifleImpMetal3d01.wav'.

I looked for the wav file myself in the game directory and was unable to find it. I did find the .xwm file though. In the audio.sbc file, I tried deleting the entry for the xwm file but I still received the error.

When we increase the max range of the sensors, per KionX's contribution, the "gizmo" drawing (Show Sensor Range Fields), doesn't show beyond the hardcoded 200m in Sources\Sandbox.Game\Game\Entities\Blocks\MySensorBlock.cs

   private const float m_maxGizmoDrawDistance = 200.0f;

First version of programming block had an unintentional but useful feature - terminal blocks had events (the very same events that you can find in ModAPI - for example IMyDoor.DoorStateChanged). Back in those days you could wire up an event handler from a programming block and execute a piece of code every time someone opens or closes the door, without any delays , workarounds or custom mod scripts. Of course this event handler would never get unsuscribed so it lived as long as the game session.

I propose to create some kind of event system for terminal blocks that we can use from programming block scripts. Below I give some code examples that illustrate the whole idea:

void Main()
{
   IMyTerminalBlock block = FindDoor("My Door 1");
   const string EventName = "Opened";

   // Subscribe to an event named "Opened" on block "My Door 1"
   AddEventHandler(block, EventName, EventHandler);
}

void EventHandler(IMyTerminalBlock block, string eventName)
{
    // Handle an event

    // Remove event subscription
    RemoveEventHandler(block, EventName, EventHandler); 
}

These AddEventHandler and RemoveEventHandler should perform invokation with respect to programming block state and should not prevent any garbage collection issues.

In my opiniom, this feature will allow players to create complex interactive scripts that work without any timer-based solutions and can process different kinds of events.

Let's discuss this idea, shall we?

As title says, please add documentation on the most important and most used methods and classes. That would be very helpful.

Thanks.

Hi,

after several tedious hours just to download VS Community, I managed to successfully build the solution with no errors.
However, when launching, I get an Exception checking for Enum duplicities. Check it out:

static void TestEnumNotDuplicitiesInAssembly(Assembly assembly, HashSet<object> hashSet)
{
    foreach (Type type in assembly.GetTypes())

    MyEnumDuplicitiesTester.cs Line 76
    An unhandled exception of type 'System.Reflection.ReflectionTypeLoadException' occurred in mscorlib.dll
    Additional information: Unable to load one or several required types.

'assembly.ExportedTypes' threw an exception of type System.IO.FileNotFoundException
Unable to load file or assembly 'SteamSDK.dll' or one of its dependencies. Unable to find specified module.

File is not missing anywhere, so I don't get what's the problem.

Thanks in advance.

1. AI engagement range is currently moddable but does not function beyond the default 800m

2. Missile turrets have a burst count and reload time assigned here:https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/07519235308594be64a1a96254897942206899bf/Sources/Sandbox.Game/Game/Weapons/Guns/Barrels/MyLargeMissileBarrel.cs
   as m_burstFireCount and m_burstFireTimeLoadingIntervalConst_ms
   Modding of these values would be very helpful (adding them to the base turret could be good as well with a -1 burst count option for gatlings)

3. I haven't found it in the code yet but the AI aiming point is based off the next barrel to fire but the check against shooting its own ship/grid is drawn from the center of the block instead of from the barrel causing many turrets to shoot their own ship even when the ship is not moving.

Two mods having scripts that are attached to a block type will not both run.

And it's a 'notice' in F11 when playing offline:

Entity script overwritten: MyObjectBuilder_MyProgrammableBlock

when both are using:

[MyEntityComponentDescriptor(typeof(MyObjectBuilder_MyProgrammableBlock))]

Programmable block being an example.

This is a serious issue that breaks mods by having other mods installed, most of the time they won't even collide since scripts are filtering specific subtypeids too.

Hello All,

I have noticed 3 issues with Windowed Mode. I normally play in Windowed Mode with a resolution of 1600x900.

Issue 1: On startup, SE remembers to set itself to Windowed mode, but does not set the resolution to what was previously set.

Issue 2: Additionally, SE will set the window size to the highest supported, however it will only render at whatever was set in the video settings.

Issue 3 (Really 2.1): If you now go to the video settings, it will read as your last supported resolution, however you will be rendering at whatever is in your config file.

The easiest way to reproduce this is to set SE to Windowed Mode and at the lowest possible setting. After you save this config, if you restart SE you will notice SE taking up most of your screen, but drawing at a very low resolution.

After digging in the source code, it looks like SE is running the following logic:

1. Check if requested DisplaySetting (width, height, refresh rate) exists in list of SupportedDisplayModes. If so, we return with this value.
2. If not, we setup a fallback mode using the last in the list of supported display modes
3. Otherwise (and I'm skipping some logic here), we create a screen mode with fallback settings (800x600).

The easiest way I am finding to fix this is to force modeExists = true either by removing the foreach loop in vrage.render\myrender-device.CreateDevice() or simply setting modeExists = true after the end of the loop. This solves both issues 1 and 2, however it then bypasses the whole logic of checking if we have a supported resolution.

After MyRender-Device.CreateDevice, if we don't use the easy fix above, it then returns the last supported display mode from the list. It is then after this code that creates the window using this setting, but uses our preferred render settings for the actual rendering.

Any ideas?

Currently 95% of network traffic is being generated by working Refineries and Assemblers. I know there is a hope for new multiplier that will greatly improve this situation. However even so, this optimization is needed because our host servers are blowing up.

I propose to batch a production queue and depends on amount of material to refine * time needed to do it, the result is coming out only when whole lot is completed. Spitting out results in near real time is not necessary. If you want your result quick, just add smaller amount of input resources. Also I wish to see refinery management under production tab to unify with all production blocks. Experimenting with refinery that is based on assembler block works just fine.

seems Audio.sbc definition contains sounds, that are not in SE content directory.

for now (as workaround) i have copied from my game folder audio.sbc into Sources\SpaceEngineers\Content\Data\

filesize diffence is roughly 10k

As per title, to have blocks managed by admin without workarounds that never works and fully protects against destruction.

Just downloaded the files & followed instructions on on github page (same as readme file).

I get errors all telling me that these dlls are missing:
Sanbox.game.dll (located SpaceEngineers-master\Sources\Sandbox.Game\bin\x86\Debug). I checked and there is no such file in there.

The next one is SpaceEngineers.Game.dll (located in the same directory above).
I have tried rebuilding the project but no success.

Error 1 The command "....\3rd\Utils\RunTemplate.bat "C:\Users\KuroodoD\Desktop\Programming\SpaceEngineers-master\Sources\Sandbox.Game\Engine\Utils\MyEnumToStringsGenerated"" exited with code 1. C:\Users\KuroodoD\Desktop\Programming\SpaceEngineers-master\Sources\Sandbox.Game\Sandbox.Game.csproj 1223 5 Sandbox.Game
Error 2 Metadata file 'C:\Users\KuroodoD\Desktop\Programming\SpaceEngineers-master\Sources\Sandbox.Game\bin\x86\Debug\Sandbox.Game.dll' could not be found C:\Users\KuroodoD\Desktop\Programming\SpaceEngineers-master\Sources\SpaceEngineers.Game\CSC SpaceEngineers.Game
Error 3 Metadata file 'C:\Users\KuroodoD\Desktop\Programmin\SpaceEngineers-master\Sources\Sandbox.Game\bin\x86\Debug\Sandbox.Game.dll' could not be found C:\Users\KuroodoD\Desktop\Programming\SpaceEngineers-master\Sources\SpaceEngineers\CSC SpaceEngineers
Error 4 Metadata file 'C:\Users\KuroodoD\Desktop\Programming\SpaceEngineers-master\Sources\SpaceEngineers.Game\bin\x86\Debug\SpaceEngineers.Game.dll' could not be found C:\Users\KuroodoD\Desktop\Programming\SpaceEngineers-master\Sources\SpaceEngineers\CSC SpaceEngineers

Currently, if a mod wanted to limit the placement of blocks on grids via certain conditions (i.e. no more than 15 turrets and 5000 blocks), they have to delete the blocks after getting to the BlockAdded event on their grid. It would be better if we could stop the block from being placed at all. We could easily pass the explanation to our users already. But actually stopping the block is a bit complicated.

Currently it seems there are two places where SE checks if a block can be placed:

• Using the hand placer tool - MyBlockPlacerBase.Shoot() checks for MySession.Static.CreativeMode OR some internal game logic and then MyCubeBuilder.Static.CanStartConstruction(character). This check on the cube builder looks for copy/pasting OR MySession.Static.SimpleSurvival (not sure what that is) OR finally character.CanStartConstruction(blockDefinition) to see if the Character has the necessary items to place in their inventory.

• Welding a projection - MyWelder.Shoot() checks MySession.Static.CreativeMode OR development mode OR Owner.CanStartConstruction(info.hitCube.BlockDefinition))

  As a modder, I'd love to be able to insert a check of my own before character.CanStartConstruction(blockDefinition) in these, and possibly alongside the CreativeMode check (if someone is using my mod in creative mod, they're probably testing out ships that will be allowed).

If I was just going straight in, I'd add something along the lines of CanStartConstruction(character, block) to MyCubeGrid and put checks for it next to Owner.CanStartConstruction() and CreativeMode in the above two places. Grid, character, and block would all be needed.

But I see a few places that seem ripe for refactoring, so I'm hesitant to include these here until I get some feedback on how to proceed.

• character.CanStartConstruction is called in a lot of places and makes a lot of sense as a method to check inventory (although I might rename it along those lines).
• MyCubeBuilder.Static.CanStartConstruction is only ever called in MyWelder.Shoot()and includes the call to character.CanStartConstruction - perhaps its logic should be mostly moved to MyWelder, with the check for the paste grid remaining in MyCubeBuilder.Static under a different name?
• The series of checks in MyWelder and MyBlockPlacerBase share a lot of logic, which it might make sense to decompose to its various atomic areas (i.e. checks for various game modes to Session).

Could some other devs and/or Keen provide some thoughts on how to proceed here?

This would have virtually no negative side effects because the Mod creators can choose whether they want to modify the radio antenna range, and nobody is forced to install a mod.

Ongoing bug which means spawning prefab ships on a server/hosted game, doesn't work as only the host sees the spawned ship. This applies to Mod API calls, and to Exploration ship spawns.

I'm not able to debug this myself, so I'll document what I discovered so far. Not sure if this is a client or server problem. Also questions over if this is a design flaw relating to entity.Save = false creating a paradox (ship not saved to map, nor broadcast when clients first connect).

Let me know if you need an example mod to test this against.

MyAPIGateway.Multiplayer.SendEntitiesCreated(entitiesList);
which ends up calling
MySyncCreate.SendEntitiesCreated(entitiesList);
which calls
MySyncCreate.BuildCompressedMessage(...)

As in the title, the SpaceEngineers project won't load. All the others work fine. It just says "load failed" next to the name in the Solution Explorer and gives me the following error:

\git\SpaceEngineers\Sources\SpaceEngineers\SpaceEngineers.csproj : error : The expression "[System.IO.Directory]::GetDirectories(c:\Program Files (x86)\Steam\SteamApps\common\SpaceEngineers\Content)" cannot be evaluated. Could not find a part of the path 'c:\Program Files (x86)\Steam\SteamApps\common\SpaceEngineers\Content'. \git\SpaceEngineers\Sources\SpaceEngineers\SpaceEngineers.csproj

Btw, my Steam folder is on another drive and not in the default location, so obviously it won't find the game's content folder there.

[This is a question for the devs]

What are your thoughts about adding "real" functions and properties to the interfaces to wrap terminal actions and -properties? Because they are far more convenient to use than string-based actions and properties, and if you would consider including the intellisense xml in the release, it would provide inline help to those using Visual Studio or other IDEs supporting these.

I am speaking of full wrapping, including both getters and setters for properties. An example is providing a

Color Color { get; set; }

to the light interface.

What, if any, are your reasoning for not doing this?

It would be great to have annotated fields declared within an in game script show up as a input field of the programming block control panel. (Similar to unity's inspector if you are familiar)

For instance the following

[Slider(0, 1)]
float value;

would display a slider named "Value" within the programming block control panel.

Some more examples:

[ToggleGroup]
bool value1, value2, value3;

Would have a set of check boxes where only one could be true

[Selection("a", "b", "c", ...)]
string[] list;

Would create a list of options to add and remove similar to the sorting block item filter

[GridBlock]
IMyThruster thruster;

Would create an input field to select an add a thruster from the control pannel to reference in the script

[GridBlock]
IMyThruster[] thruster;

Same as above but as a re sizable array to insert more than one thruster

[This is a question for the devs]

So that any checkboxes in the UI get their terminal properties for ingame scripting, like the slider and color controls does?

can any of devs please shed some light to this part of code
if i comment out that "TEMPORAL HACK" line, it solves problem with some of my script on DS

Sources\Sandbox.Game\Game\Screens\Terminal\Controls\MyTerminalControlOnOffSwitch.cs, line 49

    public MyTerminalControlOnOffSwitch(string id, MyStringId title, MyStringId tooltip = default(MyStringId), MyStringId? on = null, MyStringId? off = null)
        : base(id)
    {
        if (MySandboxGame.IsDedicated) return; // Temporal hack 

        Title = title;
        OnText = on ?? MySpaceTexts.SwitchText_On;
        OffText = off ?? MySpaceTexts.SwitchText_Off;
        Tooltip = tooltip;
    }

this line of code prevents DS from loading on/off switches decription, and also on/off text value, which results in returning empty string, therefore you cannot check if something is switched On or Off, this is problem, since not all On/Off switches have coresponding Property exposed on interface.

Currently, calling ...
Sandbox.Definitions.MyDefinitionManager.GetVoxelMapStorageDefinitions()
will return a list of ...
public ListReader

We need a method on IMyVoxelMaps, that will allow us to specify a MyVoxelMapStorageDefinition to create a voxel map in game.
CreateVoxelMap(string id, Vector3D position);

or....

allow us clone the Storage on the MyVoxelMapStorageDefinition, to use in the existing CreateVoxelMap() method.

So I read @lord-devious's comments in #4, and I am also of the opinion that the API used for in-game scripting could use some refactoring so as to be more immersive. Names like IMyCubeGrid could be changed to e.g. IVessel or something that fits the game's flavor. The actual implementation classes could keep their current names, as I believe they are used directly by modders, so it makes sense for those names to be more in touch with the real world. Or perhaps it'd be better to completely duplicate the interfaces into a separate in-game-only namespace? Then there's no overlap, and it would be easier for the game designers to control what's available to players in-game, while giving the modders lots of freedom.

Expanding on that, there are other design improvements (#29) that people would like to see in the in-game API, that would need to be taken into account in any redesign. As another example, I'm not really a fan of the extension methods on IMyTerminalBlock. These exist so that scripters don't have to cast from e.g. IMyCargoContainer to IMyInventoryOwner in order to look at contained items. Personally, I would have just made the cargo container/assembler/refinery interfaces extend from IMyInventoryOwner, so neither casting nor type checking would be needed.

Anyway, I'd like to hear others' opinions. I know @Spartan322 had some comments in the original thread. Maybe we could get a general feel of what the community thinks the scripting APIs should look like.

Is it possible to port this game to Linux?