Easy Menus: the priority for me (events can wait).

Remove Events: Needed for sure but see above: can wait.

Handle destroyed blocks: yes. I posted you about this: a way to compare a ship blocks "state" before and after (on demand). Maybe keep 2 blocks lists instead of one ? So you can "diff" them and react accordingly ? For example refresh the main blocks list and readdapt the events. Or consider you are in battle and activate weapons etc.

LKS

Ok let's start ;)

Suggestion: Ship Status.

What is a "Status": an array of keyed strings:
[StatusName] [StatusValue]

For example:
"Alert" "ON"
"Doors" "Closed"
"Guns" "Active"
"Factory" "Producing: Ammos Only"
"Fighters" "Launched"
"Flares" "Standby"
"Structure" "Not damaged yet"

Etc
This way you can:
- get a status value (if GetShipStatus("Doors") == "Closed" ...) => GetShipStatus will returns null if the status does not exists so you can catch it.
- set a status value (SetShipStatus("Doors", "Closed") ...) => will replace an existing status if already present or create a new one if not or remove a status if the value is null for example (SetShipStatus("Doors", null) => remove it)

Now the question is: where to store this status ? 3 options:
- in a single PB if it's enough
- in a main PB controlling the ship that we can interact with using your PB communications implementation
- in a common LCD that will act the same that a main PB except that it will display the status (you can also have more than one LCD to display that in a lot of rooms in the ship ... control room, hangars, factory, etc)

As I said before that should also have an "impact" on events ... some events would only react (if the condition is true/false) depending on the ship status.

More to come (about events)
LKS

Suggestion: New Events Implementation.

Why not to implement Events the same way ApplyAction does ? I will be writing in pseudo code because it's late and I do not care about the C# syntax ;)

So instead of:
list myblocklist = ...
addEvents(myblocklist, ...)

Why not to simply write:
list myblocklist = ...
myblocklist.addEvents(...)

I think it should be more "consistent" with the rest of the API ? Maybe a simple "wrapper" can do the job.

LKS
More to say about events (again :P)

I've noticed in your events example you use often a "toggle system". I'm not against it but is it always the best way to do it ?

For now, for example, one door is activated on the event "on open", and activate the "on close" event then remove itself from the events list. Thats fine.

Keep that.

But why not another (plus) way to do that ? The same way sensors are working ?
(again pseudo code)

myblock.AddEvent(condition, doitiftrue, doitiffalse)
the same way (see post before)
myblockS.AddEvent(condition, doitiftrue, doitiffalse) => apply the same event to a list of blocks

Now, and because I'm short in time, events should retain their "master function", too. So you can apply a kinda "remove" function, this way:
thatblock.RemoveEvents()
or:
thoseblockS.RemoveEvents()

But if you have some kind of "key" to name events:
Let's say
myblock.AddEvent("eventtype", conditions ...)
You can partially remove events from objects and not the whole list:
myblock.RemoveEvent("eventtype)

For example
if (GetShipStatus == "alert")
mydoors.AddEvent("alert", conditiononopen, activateinternalturrets, deactivateinternalturrets) => will activate a "bi condition" event on each turret only if the ship is under attack AND depending if a door was opened or not
else
mydoors.RemoveEvent("alert") => will remove a huge list of events to not handle anymore
endif

LKS

SRY in the previous post you should read activate a "bi condition" event on each DOOR ... in case of alert status, if a door is open turrets will activate, if no door is open turrets will deactivate

LKS

@LukeStrike, those are good suggestions. Originally I had planned to implement events something like that. The main reason it works like it does now is because the events are stored and handled in the EasyAPI class and I don't at the moment have any linkage between the EasyBlocks class and it. It wouldn't be that hard to store the events in a static property on the easyAPI class so I could interact with it from the EasyBlocks class but I haven't thought through the best way to handle it.

Do you think it's possible/a good idea to implement events as a "keyed" list ? Something like that:

[context] [object] [conditionfunction] [iftruefunction] [iffalsefunction]

Where [context] is anything you want (let's say a string for example "Alert ON") and the rest is selfexplanatory

This way you can easily have acces to them using search functions, for example to remove them or just apply few of them based on context, object, etc ... things like:

EasyEvents.RemoveContextEvents("Alert On");
EasyEvents.RemoveObjectEvents(mydoor);
EasyEvents.HandleConditionEvents(testifdoorisopenfunction);

It's just a global idea, not sure if it's a good one ;)

LKS

Suggestion: why not to re-write the debug functions ?

So instead of having an "hardcoded" throw exception in each of them you can replace them for example with:

... Dump() -> returns a string of all blocks (type and name) that you can manipulate
... DebugDump -> throw/display the dump string as an "exception" using the Log function
EasyUtils.Dump() (or DumpBlocks) -> as I said before
EasyUtils.Log(string) (or Throw/ThrowException) -> the same way
EasyUtils.DebugDump() (or DumpLog) -> will call EasyUtils.Log(EasyUtils.Dump)

I'm sorry but it is not very clear (I'm tired :P) ... the main idea is:
1° regroup all the "dump" functions (dump, dumpactions, dumpproperties) in for example the EasyUtils class
2° they will only return a string
3° using/in combination with the "Log" function you can throw those resulting string in the exception panel

The main idea behind is also to use LCD to display "results" instead of having to use the exception mode:
myLCD.Display(EasyUtils.Dump());

Something like that ;)
LKS

re: suggestion for Debug* methods to just return string instead of throwing an exception with string, an optional boolean argument would best provide that. E.g.:

public string DebugDump(bool dontThrow = false) {
if(!dontThrow) {
...normal method innards...
}
return debugString;
}

re: ship status features:

I strongly recommend keeping such specific features out of EasyAPI's core, perhaps provide in a separate file so it can be dropped into the core (copypasta) if needed. Think of it like an EasyExtension. There could be a lot of EasyExtensions. I think messaging and LCD features are suitable for EasyExtensions too.

re: debug

Yes it's a good idea :)

Just instead of the code you submitted I suggest:

public string DebugDump(bool throw = true) { ...

Because I dislike double negatives :P

LKS

re: ship features

I agree too. I've also been thinking about extensions, in a serie of classes. in separate files that anyone can "merge" (copy paste) to fit his/her needs. So the EasyAPI could concentrate only on the "core", and we can add external features (because I don't want to modify the core itself to avoid "multiple branches")

And as you said, communications, LCDs, ship status, maybe airlock/doors systems, multiple turrets handling etc should be provided in external files.

The problem is: is there any kind of "repository" that we can share ?

LKS

re: is there any kind of "repository" that we can share ?

Workshop
github

Really, uses of EasyAPI that provide specific features should simply be Workshop scripts on their own, if they are on github and forks of EasyAPI then updates to EasyAPI will be...err...easy to merge.

Yes the workshop is probably the best way. Do you know if there is an "easy way" to link projects together ?

LKS

Good idea, the debug functions returning strings instead of throwing exceptions is easy, I'll add that right now. I already have easyAPI on github. I was thinking it would be cool to split all the classes up into different files and then "compile" and possibly minify them for distribution. I don't know if you guys have used any web/javascript libraries like bootstrap. But what many of them have is a web ui that allows you to check all the features you want to use and then it compiles them all into one script. I'm thinking of maybe having something like that for easyAPI so you can select LCD, Menu, Ship Status, etc, and it will compile them into one file for you to copy/paste into the game. What do you think about something like that?