Extensibility!

[ironchefpython]

Half those handlers are not engine functionality though - is the open doors handler also written in JavaScript?

If you remembered my door example, the event handler to handle the custom event to open a door invoked a hypothetical ending api call to replaced the closed door model with an open door model.

Event handling and propagation alone is not enough.

Event handling and propagation plus the ability to modify the world through the engine API is enough.

 

[Immortius]

If you remembered my door example, the event handler to handle the custom event to open a door invoked a hypothetical ending api call to replaced the closed door model with an open door model.

Yes. This sems to be too high a level for a basic API call to me. Just a little bit worrisome that a mod that introduces doors can only work if doors are already coded into the engine api?

To be a fair, this may be down to your lack of familiarity with how Terasology works at the moment preventing you writing an API at the correct level. The idea of a block having two meshes and switching between them is incorrect for instance. Individual blocks do not have state that affects their appearance, because the block at each position of the world is represented as simple byte linked to a block definition. The entity system can add some state on top of this, but it can't change a block's shape. Instead you would change which block is at the position between the two states. Additionally, if a door is a rectangle on the edge of a block then opening a door could simply mean switching to a block in the same block family, but rotated 90 degrees towards the door's attachment point. So I guess I would expect the API to be more around changing what block is in each world position, and querying block families for the correct blocks to use, that sort of thing. You shouldn't need an open or close door method at all.

 

[ironchefpython]

Yes. This sems to be too high a level for a basic API call to me. Just a little bit worrisome that a mod that introduces doors can only work if doors are already coded into the engine api?

You may have missed the point of my (pseudo) code. It used an engine api to add two new event types to the game. Before the mod was loaded, there was not support for the open and close events, but a mod should be able to create new event types as a way to propagate state changes.

The idea of a block having two meshes and switching between them is incorrect for instance. Individual blocks do not have state that affects their appearance, because the block at each position of the world is represented as simple byte linked to a block definition. The entity system can add some state on top of this, but it can't change a block's shape.

True, I wasn't using the modding API as it *is* (as it currently isn't), I was using a hypothetical modding API that would allow changing a block's appearance and collision mesh by changing a model. I see there are numerous use cases for this, from buttons and levels that change position, to plants that grow, etc. But let's say that all those use cases would be supported through block replacement. In that case, mentally change the engine API call from a mesh replacement to a block replacement.

You shouldn't need an open or close door method at all.

I wouldn't want to have an open or close method in the base engine, but mods should be able to define new methods in their own code that would send a custom event.

 

[Cervator]

So what I'm gathering is:

Immortius: "There is no spoon"
Ironchefpython: "We're adding mods with their own internal spoons"

Is that a somewhat fitting summary? Yeah, no doors in the core engine, just blocks/meshes/meta objects that may make up doors. Yet a mod about doors might have its own provided openDoor() that it wants a part of the core engine to register as the thing to trigger in case of an event?

 

[ironchefpython]

So what I'm gathering is:

Immortius: "There is no spoon"
Ironchefpython: "We're adding mods with their own internal spoons"

Is that a somewhat fitting summary? Yeah, no doors in the core engine, just blocks/meshes/meta objects that may make up doors. Yet a mod about doors might have its own provided openDoor() that it wants a part of the core engine to register as the thing to trigger in case of an event?

Basically. If I were to quibble, I would say that the modding API allows the creation of a custom "open" event that a door (or floodgate, or chest, or drawbridge, or book, or nuclear silo) could register an event handler for.

Creation and propagation of custom events would be the primary mechanism for mods to invoke the behavior of another mod.

 

[Cervator]

Ah, so there's some mod-to-mod stuff floating around in here

Still very curious how we can combine that sort of event-centric mod power with the event stuff in the ES.

 

[woodspeople]

This may have become a bit of a side issue as the thread has gone on, but one thought: coders and non-coders can be accommodated in mod development by (somebody) building a capability (via external app or in-game GUI) that does round-trip mod-code generation/editing. Meaning, non-coders can click a bunch of buttons to create variations on normal game behavior (all orcs wear monocles, for example). The capability, call it ModMaker, generates code that makes the mod work. If it's round-trip (meaning, it doesn't destroy what you type by hand) it can act as a teaching system so non-coders can eventually become coders and reach directly into the generated code without needing the crutch. Probably obvious but worth considering...

 

[ironchefpython]

This may have become a bit of a side issue as the thread has gone on, but one thought: coders and non-coders can be accommodated in mod development by (somebody) building a capability (via external app or in-game GUI) that does round-trip mod-code generation/editing. Meaning, non-coders can click a bunch of buttons to create variations on normal game behavior (all orcs wear monocles, for example). The capability, call it ModMaker, generates code that makes the mod work. If it's round-trip (meaning, it doesn't destroy what you type by hand) it can act as a teaching system so non-coders can eventually become coders and reach directly into the generated code without needing the crutch. Probably obvious but worth considering...

Mods that don't involve new logic or behavior would likely be simple edits to a JSON data file. If someone was so inclined, they could make a tool that would read JSON, allow a non-technical user to edit the values, and save it again.

 

[Immortius]

You may have missed the point of my (pseudo) code. It used an engine api to add two new event types to the game. Before the mod was loaded, there was not support for the open and close events, but a mod should be able to create new event types as a way to propagate state changes.

No, I get that. It is what the code doesn't demonstrate that I'm talking about. While the event handling, adding new events, and so forth are a nice backbone, they are meaningless without the functional parts of the API which are not demonstrated, and not described in your existing documentation. Which is a pity because you've missed addressing all of the concerns that make doors an interesting case - them being composed of multiple blocks, consideration of their direction, how they are placed and removed, the interaction between the door and the blocks that compose it. I'm sure you are planning them though and this will come out as part of your proof-of-concept work.

This may have become a bit of a side issue as the thread has gone on, but one thought: coders and non-coders can be accommodated in mod development by (somebody) building a capability (via external app or in-game GUI) that does round-trip mod-code generation/editing. Meaning, non-coders can click a bunch of buttons to create variations on normal game behavior (all orcs wear monocles, for example). The capability, call it ModMaker, generates code that makes the mod work. If it's round-trip (meaning, it doesn't destroy what you type by hand) it can act as a teaching system so non-coders can eventually become coders and reach directly into the generated code without needing the crutch. Probably obvious but worth considering...

This is sort of what I was talking about with entity prefab editing earlier - we should have a tool in the game that allows creating and editing entity prefabs. This would include everything that describes the appearance and behaviour of a type of entity - e.g. setting the mesh used to display an item, setting what actions should be performed when it is used, and so forth. Underneath this produces some data that can be saved to binary or JSON as appropriate. This would cover a lot of the basic types of mods - appearance changes, mixing together existing behaviours.

The step beyond that is something like Unreal's Kismet or something of that ilk.

 

[ironchefpython]

Which is a pity because you've missed addressing all of the concerns that make doors an interesting case - them being composed of multiple blocks, consideration of their direction, how they are placed and removed, the interaction between the door and the blocks that compose it.

I agree, I did a lot of hand-waving in my examples. I'll put together something a little more concrete, and explicitly enumerate what API calls I'm depending on.