API Bugs

How do you find out the position of the ParentBlock?
PS: Any news about the bug with the C# compiler?

 

Now that Reforged Eden is about to be released for 1.7 i am getting more and more requests, from communities that want to wipe and restart, when the C# scripts will be available again. Can you please give me a time frame for the fix so I can pass it on.

 

Build: v1.10 4243
Mode: SP
Type: API V2 IApplication.GetAllPlayfields()
Description: A call to IApplication.GetAllPlayfields() from an SP client is inconsistent with MP client

With a client connected to an MP game a call to GetAllPlayfields() returns only playfields in the current solar system. If connected to an SP save the API returns all row from the Playfields table in global.db but the individual solar systems are not grouped in the returned data. While you can infer solar systems based on using PlayfieldType:3 (the "sun" itself) as a delimiter, this depends on sorting order which could introduce problems.

Request: Add Playfield.SolarSystemName to the returned data for grouping and/or limit both use cases to the MP connection behavior through an optional "CurrentSystem" boolean filter parameter.

 

On an MP with activated EAC, the client's API should not be executed at all as this opens up a wide range of cheating possibilities. Unfortunately this has been broken for some time so that the client API is ALWAYS executed and leads to unforeseen side effects if the same mod is installed there as on the server.

 

Is there a way using the API to determine if EAC is active at the server? Unexpected consequences sounds ominous. My mod is all about making client/pf/dedi messaging easy, so any warnings appreciated. I'm still more comfortable with the V2 API and haven't really worked very much with your EmpyrionNetAPIAccess wrappers yet so I haven't been doing much of anything with the dedi side.

Some sorts of "cheating" are eye of the beholder sorts of stuff- OnEntityLoad gives you a life signs monitor that Horrors just spawned at x/y/z and polling on IEntity is the scene from Alien when Hudson starts yelling "game over man!" In an MP game (EAC or not) some players having access to feature/function that others don't is an unlevel playing field- making "Client Mods Allowed" a server settable gameoptions parameter would be a good thing.

In a related yet unrelated thing I'm wondering if the potential for unreviewed code injection is the reason that CSharp scripting got yanked- the CSharpCodeProvider() gives unsanitized access to the bare metal with the privs of the user meaning unfettered access to all the users files at a minimum.

My use case is creating a parallel registry and logging app with better search, filter, and mapping tools. The MP behavior is the API I'd really like, basically a .GetSolarSystem() call. I can get what I need when an SP game gets everything by filtering but after you've been to a lot of places, getting 300+ entries sent to you when you only want a dozen will burn cycles and buffers to get the data I want.

 

Things like "AddItem" or "Block" manipulations are probably more serious here.
This would require a complex filter of functions that a client mod could call.
For the C# scripting, the EmpyrionScriptingMod, I have created elaborate white/blacklists of the classes/methods a player is allowed to use.

With the dialog function, which also offers an input, you could achieve a lot from the server

 

Yeah, I used the service bus pattern a lot in my professional life so it's kind of a "when you have a hammer everything looks like a nail" thing. I'm sending out the delegate handler events as messages...

Code:

{
    // marshal data & publish GameEvent()
    JObject json = null;
    if (arg1 != null || arg2 != null || arg3 != null || arg4 != null || arg5 != null)
    {
        json = new JObject();
        if (arg1 != null) json.Add(new JProperty("Arg1", arg1.ToString()));
        if (arg2 != null) json.Add(new JProperty("Arg1", arg2.ToString()));
       [...]
    }
    string jsonString = json?.ToString(Newtonsoft.Json.Formatting.None);
    await CTX.Messenger.SendAsync("ModApi.GameEvent." + type.ToString() + "/E", jsonString);
}

Calling code to do stuff in the game gets done with RT loaded DLL methods bound to topics the mod subscribes to. Subscribing apps aren't in the game loop and the broker takes the hit for distribution, potentially across a data center LAN/WAN. Doing it this way lets me write console & WinForm programs that interact with each other and the game and the latency is negligible.

Having the code running outside the game makes it lots easier to debug with breakpoints etc. Just getting logging working has made lots of things that are tedious in registry easy to do with SQL in a db browser window.

I'll take another run at the dedi side- doing anything meaningful in an MP game really calls for it.

 

I was just working with this and I am running into a stack dump issue (Graphics device is null. Crash!!!) when attempting to use Eleon.Modding.IGui.ShowDialog() from the client. Not sure if you or others have successfully used this but for some reason it's killing the app with a low-level unity bug when I try ... I've done lots of variations, but they all force a dump and exit with the "graphics device is null" error.

Later .. Just got it to work but needed to run it directly in a delegate handler (vs as an awaited task) ... since tasks are separate threads and the handlers run in thread they were invoked from. These sort of dumps seem to be associated with Unity having an affinity for the main thread- I think this is the sort of stuff the Update() delegate is for. Should be able to toss the call over to that via Enqueue/Dequeue.

 

I have only used ShowDialog in EmpyrionScripting in a EGS dedicated server environment so far

 

It works in client but only on the thread initiated by the mod. If dedi initiates, then they send it to clients via their net code which sets stuff up correctly. Using an OnUpdate() handler gets you to the right place. Weird issue, but not a bug.

If you have a "look at this" suggestion for how to get the contents of ItemStack for a specific container in a structure via Request_??? I'd greatly appreciate it. I got it working in IModApi for single player...

var content = _ctx.LoadedEntity[entityId].Structure.GetDevice<IContainer>(vector).GetContent())
​

...where vector is the pos, but this depends on having a dictionary of IEntity interfaces.

For MP I can get these from OnPlayfieldLoaded() on the PF server (IPlayfield.Entities()) but I am not getting a PF load event in my mod for the starting playfield so I don't have an IPlayfield to make the call. Warping to new PFs does trigger the OnPlayfieldLoaded() so guessing this is a race condition with the mod starting in parallel with other PF server start tasks.

 

The event will be fired, but only when a playfield is really needed in the PF server. You can then get the Enties in the MP via the events

Code:

....Playfield.OnEntityLoaded
....Playfield.OnEntityUnloaded 

Code:

02-06:06:06.891 07_06 -LOG- Loading playfield 'Haven'
...
02-06:06:07.073 07_06 -LOG- {EmpyrionScripting} StartScripts for Haven pending
02-06:06:07.074 07_06 -LOG- Playfield 'Haven' with type 'planet' class=3 and playfield seed 844686 loaded (183 ms)
02-06:06:07.091 07_06 -LOG- Connected player 76561198002547809/'ASTIC' as client 1
....
02-06:06:14.386 07_06 -LOG- Player loading: id=1139 name='ASTIC' pos=(-318.15, 87.55, 436.14) ctrl=-1
02-06:06:14.405 07_06 -LOG- Got player id: CId=1, EId=1139, 76561198002547809//'ASTIC'
02-06:06:14.407 07_06 -LOG- {EmpyrionScripting} AddEntity: Haven:[1139] ASTIC
02-06:06:17.074 07_06 -LOG- {EmpyrionScripting} StartScripts for Haven
02-06:06:17.144 07_06 -LOG- {EmpyrionScripting} RemoveEntity: Haven:[11010] Vega AI
02-06:06:17.159 07_06 -LOG- {EmpyrionScripting} AddEntity: Haven:[11010] Vega AI
02-06:06:17.165 07_06 -LOG- {EmpyrionScripting} RemoveEntity: Haven:[1057] UCH Wreckage
02-06:06:17.167 07_06 -LOG- {EmpyrionScripting} AddEntity: Haven:[1057] UCH Wreckage
02-06:06:17.167 07_06 -LOG- {EmpyrionScripting} RemoveEntity: Haven:[1038] Spider Nest
02-06:06:17.167 07_06 -LOG- {EmpyrionScripting} AddEntity: Haven:[1038] Spider Nest
02-06:06:17.167 07_06 -LOG- {EmpyrionScripting} RemoveEntity: Haven:[1037] Damaged Hoverbike
02-06:06:17.168 07_06 -LOG- {EmpyrionScripting} AddEntity: Haven:[1037] Damaged Hoverbike

 

Bug/Inconsistency ... the ChatMessageSent event is not signaled by calls to the Application.SendChatMessage() method from the client while it does get sent when the UI "." method of sending messages is used.

This can be tested either with a mod or a dialogue execute script such as this one:
Eleon.MessageData md = new Eleon.MessageData();
md.SenderType = Eleon.SenderType.Player;
md.Channel = Eleon.MsgChannel.Global;
md.Text = "Hello World";
Application.SendChatMessage(md);

This will send a "Hello World" message to the client, but it will not trigger ChatMessageSent event in a client mod in single player mode.

Why it matters: The dialogues execute method has access to a very limited set of interfaces and the ability to load others at runtime via reflection is disabled. SendChatMessage is widely used to communicate with mods in SP, COOP, and DEDI modes to enable user triggering and interface with mods. A dialogue execute could, for example, let the client application respond by doing a callback using the Gui.ShowDialog() with text links to provide an alternative and potentially more dynamic interface for dialogues in a way that is familiar and doesn't require SendChat modal typing. You could do this sort of mod for an MP game, but a single player would need to run the scenario in COOP in order to allow communication between the dialogue system and a client-side mod via the DedicatedServer event which is correctly sent by the API call.

API triggered in coop/dedi mode:
DedicatedServer/E/Application.ChatMessageSent/f352044d9c7/45 {"GameTicks":2580,"SenderEntityId":-1,"SenderType":"Player","SenderNameOverride":null,"SenderFaction":"Faction.0","RecipientEntityId":-1,"RecipientFaction":"Faction.0","GameTime":0,"IsTextLocaKey":false,"Arg1":null,"Arg2":null,"Channel":"Global","Text":"Hello World"}

Client triggered by UI in single player:
Client/E/Application.ChatMessageSent/26af2e4f4c1/899 {"GameTicks":124091,"SenderEntityId":1008,"SenderType":"Player","SenderNameOverride":null,"SenderFaction":"Player.1008","RecipientEntityId":-1,"RecipientFaction":"Faction.0","GameTime":0,"IsTextLocaKey":false,"Arg1":null,"Arg2":null,"Channel":"Global","Text":"Hello World from UI!"}

 

All good, I signed up for being an unpaid tester years ago.

Just a thought but making the V2 interface open source like GPL could be done in a way that wouldn't expose your private structures for exploit or impact your copyright. You choose what fixes and extensions, if any, you pull back into the shipped product. Anything that supports and enables the content and server hosting community helps promote and improve your game.