rotators / fosdk Goto Github PK

ProtoItem as customizable base data container for items allowing extending the info for gameplay related stuff is not needed - GameType implementations may rollout own, similar system.

Still, ProtoItem is used extensively by the engine. To not do many changes at once and to retain server working as close to vanilla as possible the ProtoItem should stay, but keep only data used by the engine.

The plan is for game engine to instantiate GameType objects (be it from save or from map data) that will be using the native objects as their 'resources' This process will be in charge of assigning events to native objects, that means - script and notion of init function is not needed.

That is just another offsets story, but it can't be handled by just scrapping offsets in favour of native getters/setters, GlobalProperties map to GameOpt and it's pretty ubiquitious structure when it comes to Server/Mapper/Client.

Critter::Data.Params is another structure allowing to customize Critter engine type to suit various gameplay behaviours. It needs to be stripped down to the harcoded stuff, and the client-server communication replaced with some facility that's available from scripting API and can be used with GameTypes.

Currently, the manage-native communication that involves arrays is done via MonoListWrapper. It exploits the fact that most commonly used array-like collection is List<T> which, albeit generic, also implements non-generic interface IList. The process goes like this:

// managed side instantiates the collection
var list =  new List<Critte>();
// and requests the engine to fill it
map.GetCritters(0, list);
// the engine then does its magic, and calls following managed method, to actually fill the data:
void Add(IList list, object obj)
{
    list.Add(obj);
}

All is fine and the glue-code is trivial, except two things:

• not possible for the engine to set the collection capacity up-front (IList doesn't expose capacity)
• not possible to copy contiguous memory area

Wheras second, obvious in its nature - we can't rely on the memory layout of managed objects - we still can improve it by using some of the mono_array_ helpers).

The first is real issue. Many engine functions (most of them) know how many elements they want to append, so such optimization is natural.

This was the behaviour in vanilla server, now it's been (temporarily) removed during refactoring

The default SDK convention was to use uint wherever the returning value was denoting the count of something, whereas the common convention (and it's used amongs .NET collection) is to use int.

To remove the friction and unneeded casting, proposal is to alter API to use signed ints there.

One of the following:

• mono side remembers the offsets
• expose native getters/setters

It's not worth to simply refactor dialogs to call mono functions instead of AngelScript ones, following should be done:

• basic Dialog structures exposed to the engine
• events

Then, instead of callbacks assignable from DialogEditor we're gonna have handlers attachable from script.

Currently, Location Enter event is meant to be raised when group enters location, whereas previous entrance_check was there to determine whether entrance is available at all.

• Use
• Trigger

This is because they need certain flags to be set on map, and those flags were handled by SetEvent functions