Dear Readers!

 

This entry i write about my expereinces and lessons i learned during the making and after making the current realised version of SLOS ( SLavers Of Skyrim ). This is purley scripting and modder stuff that may not intrest all readers.

 

For new readers backrgund about me:

i not a programmer by profession, i learning by my own on the fly. Probably some of my "discoverys" not new to a expereinced programer who do programing for living. 

 

About the architecture of Slavery Player Modul and API system inside SLOS:

 

This 2 is a indepedendent system inside the system, with independent porpuse. API system ment to give other systems acces external resources like SexLab.

Slavery Player Modul ment to provide frame work to player slavery.

 

Both case i know from the start i need a dedicated API script, that referenced by other elements of the mod and only this way accesing this system resources/services.

( This latter turned out a very good call! ) No expection no direct calling or dodging this requirement.

This made possible to me do things inside these systems witout need owerite or change anything out side the effected system i working on.

 

Originaly i planned make Slavery Player modul a single uniform system that has a API attached on it and call for the day.

Anythin need to done just call the API and magic happens. At the end of curent realised version: V - 0.0021, i realized this is not going to cut it.

Not only all the inner part of Slavery Player Modul placed one single script file, this it self not problem. But all the functions in the sub branches of the framework inter connected.

Like spagetty the threads mixed.

Changing anything become more and more complex each time i added a new element to it.

Considering this is a relative early stage of devlopment this system and only  few futures added.... (zone functions, player mind effect, slave master preferences implemented, plus few punishment method.... and not functioning escape detectiong system )

this is very few compered the expected final form.

if i continue useing the after mentioned architecture its lead a un usable mess.

 

So i decided do it agin... rewrite a some what working code and re arrange.

First important step to cut the Slavery Player Modul parts, lets call it sub modules for now.

 

This parts/sub modules: recive 1 and only 1 single job that need to do and done care anything else.

With this the mess reduced near 0. Secund thing: the sub modules need own API section! Yes you heard right!

Evry single one need a own dedicated code section for porpuse to give interface the other part of Slavery Player Modul.

At first might sounds crazy or waste of resources. Well normaly i say yes. This case when i dont know how mutch going to change each sub modul and expected change a lot...

its a requirement, this way i more free to change what inside each sub module.

 

Third addition to original architecture is a control script. i dont know better name for it. This sub modul/part. Assigned a special job to give out orders to all other and make them work as one.

Probably the API going to brige request to this script and this one assign task to other modules.

 

Fourth change i made in the zones: the zones i use detect and control player movment changed a lot.

Now they them self tasked keep track when need report the player entered or exited the zone, and keep track where to report it.

 

Original version uses a function that recives all event on zone enter or leave and from here select what to do based on tons of other settings.

Evry single time a new zone use case added i need alter this function in the original version.

its not to efficent say to least as the system need check ALL possible case where the zone has effect.

 

TLDR:

New lessons learned during devloping V 0.0021

1- making application interface to a part of a mod is good

2 - if a part of the mod has lot of futures all future need own separate modul, with own separate interface

3 - if a script recive a task best if the reciving script do the task. or foward it to other script if absolutly needed. Do it as last resort.

4 - separating functions, variables are good pratice dont mix things! one variable, one function need to do exactly 1 single thing not any more!

if starting use 1 thing more than 1 place its going to make mess!

5 - if a problem very big and need to be scattered mutliple littile problems, the solution it self need to be keept scatered in modules too!

 

Despite "this"( i need rewraite/organize 2k+ lines of code ) i happy  i learned something new and next time i make other mistake not this one.