[mod] Empyrion Scripting Mod

Oh i just saw this. This is cool, Astic. So from what i'm seeing anything you put on the boxes shows up on the LCD Screen. Nice! Great Work!

 

Is the EcfParser capable of reading a additional/custom file? Maybe with custom structure blueprint?
I'm not sure if I understand the docu on GitHub correctly.

I try to outsource the item ids groups from the configuration file to a extra file which is capable of providing a hierarchical inheritance structure to accomplish a more logical search structure for item sorting methods:

Code:

{ Note: AllItems
   { Note: Useables
       { Note: Ammo
           AmmoMulti: 2102
           Ammoplayer: 2099,2100,2101,2103,2105,2106,2108,2109,2110,2112,2113
           { Note: AmmoVessel
               AmmoVeselMulti: 2104,2200,2201
               AmmoVesselHV: 2208,2211
               AmmoVesselSV: 2198,2199,2202,2213
               AmmoVesselCV: 2205,2206,2210,2214,2215,2219
               AmmoVesselBA: 2204,2209,2216,2217,2218
           }
       }
   }
   { Note: Blocks
       { Note: BlocksS
           //...
       }
       { Note: BlocksL
           //...
       }
   }
}

 

Das ist vermutlich möglich das er solche Dateien auch einlesen kann, jedoch sind geschachtelte Strukturen in ECF, zur Zeit, nur schwer zu benutzen.

 

Maybe I read "too much " on GitHub but I don't find it. In which namespace or struct is for C# scripts the "SaveGameModPath" located?

 

Es ist in dem NuGet paket welches aus https://github.com/GitHub-TC/EmpyrionNetAPIAccess kommt und ist dort in der Datei https://github.com/GitHub-TC/Empyri.../EmpyrionNetAPITools/EmpyrionConfiguration.cs zu finden.

 

Thanks. I just have one little strange effect. If the script runs the first time the field "EmpyrionConfiguration.SaveGameModPath" is null or empty.
At the second script run the field returns the expected path.

Code:

//...

private static void ParseItemStructFile()
        {
            // this line throws zero-length exception at the first script run.
            sItemStructFilePath = Path.Combine(EmpyrionConfiguration.SaveGameModPath, sItemStructFileName);
            if (File.Exists(sItemStructFilePath))
            {

//.....

 

with

Code:

root.MainScriptPath

you are in the
[EGS]\Saves\Games\[SaveGamename]\Mods\EmpyrionScripting\Scripts
path.

 

From which class is "root" the instance?
Visual Studio does not recognize the name.

 

root wenn du mit einer main funktion arbeitest sonst einfach MainScriptPath

 

Visual Studio needs know the assembly references and/or using namespaces.
It not recognizes the fields you mentioned.

The code help additionally cannot find the references in my linked libraries:



In the ingame editor the names "E, P, Ids, CsRoot" and so on are cool and pretty easy to use.
But for external editors like Visual Studio its a little bit sticky and tricky to find the right "field sources" for the "predefined" fields and tell the editor what references to use.

 

Sorry i forgot to say

Code:

public class ModMain
{
    public static void Main (IScriptModData rootObject)

 if (!(rootObject is IScriptSaveGameRootData root)) return;
                var cargoTargetFileName = Path.Combine (root.MainScriptPath, "..", "CargoTeleport", root.E.Faction.Id.ToString (), $"Cargo-{targetEntityId}.json");

Einiges findest du auch hier in meinen Scripten https://github.com/GitHub-TC/EmpyrionScripting-Collection

 

Thanks, works very well. Just a few lines:


to get different exact group data:


I added the ItemGroups.cs and the first version of the "ItemStructureTree.ecf" below.

There is just one little thing to know:
You have to call for example this at the script beginning to initialize the file location:

Code:

ItemGroups.SetFileRootPath(Path.Combine(root.MainScriptPath, ".."));

Had you the chance to have a look at the custom .dll reference usage issue?

 

I will look at this this weekend

 

Version 5.9.0:

Code:

using System;

namespace TestDLL
{
    public class TestClass
    {
        static Random Rnd { get; } = new Random();
        public int TestMethod()
        {
            return Rnd.Next();
        }
    }
}

[EGS]\Saves\Games\[SaveGame]\Mods\EmpyrionScripting\CsCompilerConfiguration.json

Code:

{
  "WithinLearnMode": true,
  "CustomAssemblies": [
    "CustomDLLs\\TestDLL.dll"
  ],
  "Usings": [
    "TestDLL"
  ],
  "AssemblyReferences": [],
  "SymbolPermissions": {
    "Player": [
      "TestDLL.*"
    ],
    "Admin": [],
    "SaveGame": [
    ]
  }
}

Remember: Assemblies are locked by the EGS playfield process after loading! So, for a new version you have to shutdown EGS, change the DLL and restart EGS again.

 

I will test it today.

I noticed another issue even wih the version before.
I noticed my server has problems to start fluently. Its takes several launch attempts before the server and the mods works without errors:


I deleted my scripts. So no script compiling can cause this. And the server launch still fails.

Then I deleted my "Configuration.json" and "CsCompilerConfiguration.json" from the savegamepath.
And the server starts immediately without problems.

Some setting in the files seems to cumber the mod and therefore the server itself.
Would you have a look? I added the files below.

 

Die Konfiguration ist soweit ok - die v1.1 scheint einige Macken zu haben die das Spiel/Playfield - ggf. mit einem (alten/laufenden) Spielstand - immer mal wieder abstürzen lassen --- natürlich nicht reproduzierbar womit sich ein Fehlerbericht erübrigt.

PS: Der Code von Empyrion ist recht instabil - beim ersten Öffnen eines Containers habe ich seid der 1.1 immer mal wieder diese (verschobene) Ansicht - in der natürlich der Container auch nicht funktioniert ;-)

 

Immerhin hamse gefixt das gelegentlich nur die halbe Struktur geladen wird. Das war immer sehr skurril

 

I'm still testing. Is this a little concat error?
The learn mode generates the marked line with a plus instead of a point:

 

Hier hast du in der Klasse eine weitere Klasse definiert
https://stackoverflow.com/questions...rs-in-string-for-c-sharp-collection-type-name
Besser du machst Scripts nur als Namespace

Code:

namespace EgsEsExtension.Scripts{
...
}

oder

Code:

namespace EgsEsExtension{
namespace Scripts{
...
}
}

 

I changed some calls in the code to enable a simple calling when implemted as .dll.
Visual Studio shows no errors. But ingame it won't work.

I try to change it back be able to copy the code in a save game script file again.
Again Visual Studio shows no errors but ingame it won't work.

I cannot copy the code to the ingame panel because the whole (non-dll) version is too long and I need partly the content of the SaveGameModData interface. Even calling my dll from ingame is not clearly runnable. So I have no unchanged lcd-script-runable version to get ingame error messages.

Without a savegamescript tracking its nearly impossible to track the problem down I think.

Upto now I can only "guess" but I looks like:
If a lcd-script runs my dll, the playfield server crashes.
If a savegamescript runs my dll, nothing "visible" or "noticeable" happens.