Modular && Function based player_build.sqf

[raymix]

It's now added to Epoch 1.0.5.2 RC

 

 

 

Second concept: 

Github - https://github.com/raymix/Modular_player_build

 

 

Modular player_build Concept

 

Based on files from Dayz Epoch 1.0.5.2 RC and imitates original file/folder structure

 

What is it?

It is a redesigned *player_build* system created by @vbawol that still keeps the default functionality in general, 

however the code concept is designed for maximum compatibility for future addons that uses *player_build*.

 

Why?

There are many great mods out there that reuses whole *player_build.sqf* file. Thousands of servers out there are running

customized file uploaded to MPMissions instead. Basically original file is not even used in-game, just as a reference (unless it's a vanilla server, which is rare).

Many addons reuses this file only to change or add few variables and in most cases only rare few addons are compatible with each other.

 

How does it work?

It's quite simple concept - player_build is simply split apart into multiple files and defined as functions.

..* Default player build is actually modularly built from collection of these functions

..* These functions can receive arguments and send arrays back to caller with handles

..* Fully change outcome of single function by sending it your own customized variables with a single line of code

..* You are not forced to use all functions, this way you can design a custom mod bypassing some unneeded functions (i.e admin build)

..* You can redesign your own functions and reuse *modular player_build* functions in any combination you want

..* This will save mission file sizes for custom addons since most of code is actually inside client files and controlled externally

..* Addon makers that will work together on this project will most likely have their projects fully compatible

 

Can I contribute code or help in any other way?

Yes, you can! Also any testing and bug reports will help us big time.

 

Is this gonna be in official Dayz Epoch build?

No idea, that would be awesome, if this concept works out, I'd say this mod should be almost a "must".

 

What else?

If you have designed popular mod, but it has huge file size and it replaces player_build, there's a good chance it won't be accepted 

as a part of official Dayz even if it would be an awesome toggle-able feature. However modular player_build allows for everyone to 

reuse same files without ever changing them, thus giving ability to initiate their addon from a single file. If we all work together

and create a centralized control file.

This way your mod/addon could be added to Dayz-Epoch client files without ever changing any of default files that would cause incompatibility

plus it will keep the mission file sizes low.

 

 

First concept:

 

Basically, to end the endless compatibility issues with multiple addons that reuses custom player_build, I've designed a fully modular one instead that nobody will need to change directly, but instead they will be able to build their own without affecting original while still retaining ability to grab and push info to original player_build as they please. 

 

What it is NOT: new player_build system. I did not change anything, default player build will still work as originally intended.

What it IS: blocks of player_build are split into multiple functions that both takes and passes arguments. It is also fully documented script with comments that explains everything for people new to scripting.

 

How does it work?

Basically if you enable custom build boolean, player_build will not do anything and will await for your instructions on which code blocks (functions) to use

You can call any function in any order at any time and paste them together to create your own unique build system with few code lines (don't get scared from amount of example code inside init function, it's just for documentation, it can be in fact reduced to like 1-7 lines depending on your needs).

Original player_build detects if you are using custom build system (use boolean inside init.sqf), and if true, it will not follow the normal procedure of building, but instead will await for instructions from external build system giving you full freedom.

 

Examples:

You have admin build system that lets you instantly build without animations or deleting magazine - create new publish function based on original in your own script, reuse rest of the functions in player_build without ever touching it.

You have snap build system, change control and createObject functions, reuse rest of code, pass proper arguments to publish function

You want to build non-epoch items like interior or buildings with right click or action menu - ignore most of functions, only pass your own arguments like classname by calling control and publish functions. Simple!

While running 2 different snap systems would make no sense, but it should be easily possible to achieve, each one running on it's own thread trough spawn

 

The list goes on and on

 

How can I help?

I've obviously based this using only my own experience with few mods that uses player_build. Please check this code and see if it would make your mod work, too. If it doesn't I am open to all suggestions to once and for all stop incompatibility issues.

Bugs... i've only tested it "_this far", you guys are awesome at breaking stuff, see if you can break this one and report back for fixes.

 

Why?

Too many addons replaces default build system leaving server admins with a limited choice of addons they can use, forcing them pass on many great addons out there.

Compatibility - for example Rimblock's Plot for Life vs Snap pro. You either choose one or wait till someone comes up with a dirty workaround. And if either of addons gets updated, the second one will most likely lose compatibility, leaving admin with outdated addon.

If we all agree to a single modular system, we will have much easier time with compatibility without ever needing to replace it. 

This will save mission download size for addons that reuses original player_build

 

Code compatibility:

It was designed using latest player_build from 1.0.5.2 on awol's github

 

What's with DZE_customBuildInit at the end?

Not 100% sure atm, my idea was it will be a precompiled file/function were we can all add calls to our own addons without actually changing them? 

For example with snap_pro

 

player_build.sqf:

[] spawn DZE_customBuildInit; 

compiles (not custom compiles, actual dayz pbo files): This file could contain code for addons that uses player_build and made it into official release without any need of changing any of original files (optional addons). It can ofcourse be brought to mission file as it's light in size.

DZE_customBuildInit = compile preprocessFileLineNumbers "\z\addons\dayz_code\compile\customBuild.sqf";

customBuild.sqf

//random example 1
myAwesomeBuildSystem = compile preprocessFileLineNumbers "custom\awesome\init.sqf"; //loaded from mission file

_itemConfig = [] call DZE_buildFNC_getItemConfig;
args1 = _itemConfig select 0;
args2 = _itemConfig select 1;
args3 = _itemConfig select 8;

[args1,args2,args3] spawn myAwesomeBuildSystem;

//random example 2
officialBuildSystem = compile preprocessFileLineNumbers "\z\addons\dayz_code\compile\somethingToSnapWith.sqf"; //loaded from PBOs in parallel
[DZE_buildItem] spawn officialBuildSystem;

Future: 

If all goes well and you guys agree on these (quite dramatic?) changes, I could do a merge pull on github, but first it needs some extra testing and agreement from other coders/scripters/addon enthusiasts etc, lol.

 

Code?

https://gist.github.com/raymix/7b8ce07521ce17d7ee9e

 

[RimBlock]

Cool, I was going to suggest a separate thread for this.

 

We were discussing slightly different things about functions and the modular building system it seems :) .  I was looking at taking duplicated code out of the player_build / remove / upgrade / downgrade sqf files and put it in a single fn_xxxx.sqf thus reducing the size of those sqf files.

 

You idea is a bit more .... epic ;) .

 

Some observations / suggestions.

 

Noticed the plot pole in range is hard coded to 30 and not using the global variable (DZE_PlotPole) in DZE_buildFNC_countNearby.  Whilst this matches the original, personally I think that is a bug with the original as well.  If you have changed the plot radius to 20 for smaller builds, it will still count objects outside the players build range.

 

The player_build is now 240 odd lines bigger (780+ vs the origian 560 odd).  These lines will be read every time a player builds something.  Smaller scripts generally run faster so why not move the functions out to separate files (or groups of functions into 2-3 files, maybe fn_PB_checks & fn_PB_create or something).  Pre compile them from the init or custom compiles.  The fn_selfactions suffers from this type of problem as well as more and more just gets tagged on.

 

I also notice you still have the animation in the DZE_buildFNC_publish rather than as a separate function.  This would probably provide one of the biggest benefits to move to its own function and it could be leveraged but a great many scripts or bypassed if the mod writer wishes very easily.  I was thinking of passing [animation-name, num-of-repeats] and returning [abort] (false being sucessful completion, false being interrupt of some kind).

 

Great work.

[raymix]

Some observations / suggestions.

 

Noticed the plot pole in range is hard coded to 30 and not using the global variable (DZE_PlotPole) in DZE_buildFNC_countNearby.  Whilst this matches the original, personally I think that is a bug with the original as well.  If you have changed the plot radius to 20 for smaller builds, it will still count objects outside the players build range.

 

The player_build is now 240 odd lines bigger (780+ vs the origian 560 odd).  These lines will be read every time a player builds something.  Smaller scripts generally run faster so why not move the functions out to separate files (or groups of functions into 2-3 files, maybe fn_PB_checks & fn_PB_create or something).  Pre compile them from the init or custom compiles.  The fn_selfactions suffers from this type of problem as well as more and more just gets tagged on.

 

I also notice you still have the animation in the DZE_buildFNC_publish rather than as a separate function.  This would probably provide one of the biggest benefits to move to its own function and it could be leveraged but a great many scripts or bypassed if the mod writer wishes very easily.  I was thinking of passing [animation-name, num-of-repeats] and returning [abort] (false being sucessful completion, false being interrupt of some kind).

 

Great work.

 

I just wanted to post an idea, something to base actual file off of... like a framework. I guess it could be cut down into even smaller chunks, end result could be a bit more complicated, but that's not really a problem.

Document size grows because I commented almost every single line explaining what each line does, that can be removed ofcourse.

Also it has more lines because I reformatted code to be easier to read, nothing really got changed much, the only things added are function definitions and arguments, that's all. I've only done this for the "documentation", most of lines can be reduced back to a single line if that helps performance.

 

It is true, animation loop can be easily brought to a different function, even spawned on different thread with a scriptDone handle that uses waituntil before going into publish phase. Super easy to do.

 

I'll be going on holidays this saturday out of country, getting married next week, lol, so won't be able to do much work on this, but there's no rush on it, idea is fresh and that's all it really is - an idea. Just thought it'd be fun to break the whole code down into smaller peaces and paste it together using functions instead. 

At current state it uses all defaults - like literary, it's just feeding itself default values, but maybe in future we might come up with more sophisticated system.

 

Few ideas we are getting so far:

Split player_build into smaller documents. So normal player_build only loads initial function, rest of functions are compiled in it's own seperate file, thus avoiding reading large file and only reading code blocks required (rim)

Make most params static and use a config file that lets you build custom array to pass to functions. So instead of long parameters like:

[arg1,arg2.arg3,arg4] call fnc; we could use something like args = [1,2,3,4,5,6,7]; [args] call fnc; This way people can easily configure their build system to use different array depending on playerUID for example. Never having a need for extra player_build file for admins alone. You get the idea...lol

Ofcourse this is where plotpole ranges and other stuff comes in, too - a config file that can be controlled dynamically with some script magic.

[RC_Robio]

You guys are making it too easy!!  ;)

[raymix]

Holy shit dude, I just had most epic idea ever.

Have a centralized config file that #includes other mods. So if someone comes up with an interesting build system, you don't need to do some long ass tutorial, but instead just tell people to include your file into config and done. Think this is plausible.

[mudzereli]

not a bad idea but I'm not sure how many people will actually end up using it.

 

Let's say you and Rimblock both adapt this new player_build.sqf.

 

Unless I am misunderstanding, the player will have to choose between building an item that has snapping or building an item that works w/ plot for life?

 

Seems like there would be just as many compatibility issues, just manifested in a different form.

[raymix]

not a bad idea but I'm not sure how many people will actually end up using it.

 

Let's say you and Rimblock both adapt this new player_build.sqf.

 

Unless I am misunderstanding, the player will have to choose between building an item that has snapping or building an item that works w/ plot for life?

 

Seems like there would be just as many compatibility issues, just manifested in a different form.

Yep, but that's why we're here to try to fix that compatibility issue. This is where dynamically changed functions could come in - if Plot for Life is enabled in config, then appropriate additional values would be sent along to a function. Just an idea.

[mudzereli]

Yeah I hear you. I was just making sure I understood correctly. I am not trying to shoot down the idea or anything. This would definitely be great for having something like admin build vs player build but there are still some cross mod compatibilities that need to be ironed out.

 

To make it work cross mods it seems like it needs to have some sort of event/listener elements where mods can register some code to be executed within & between functions.

 

could definitely work though

[raymix]

You got it all correct, at current state it is same problem in different format.

I've to go now, but i'll be back home later, might try to split this up into several files and start up a github repo, see where it leads us from there.

 

Registering project for compatibility sounds like a great idea, thanks. Maybe a single github project that gathers all projects together (single config file, not actual addon scripts) to assure compatibility. Mind you, that core files has to be the same for time being - as in this should not be an intrusive or destructive project to default system for those who prefer vanilla over mods.

[PryMary]

So what you are suggesting is a MOD template that just injects it's own code to a base default file?

 

Sort of like a module system in which a modder can make a mod that only has specific functions relating to that mod which is called in a centralized config. Sort of like the mod's developed for a EVE Online Killboard. They all follow a template and allow for cross mod compatibility?

 

Pry

[raymix]

So what you are suggesting is a MOD template that just injects it's own code to a base default file?

 

Sort of like a module system in which a modder can make a mod that only has specific functions relating to that mod which is called in a centralized config. Sort of like the mod's developed for a EVE Online Killboard. They all follow a template and allow for cross mod compatibility?

 

Pry

I guess, yeah. Either something that lets people make their own modifications to file simply by changing values instead of reuploading whole file, or something where all mod makers that uses player_build uses same config file to manipulate the outcome. Maybe something like - "mod ready" config file, where user uploads a specific addon to his mission file and enables it inside config, that lets other mods automatically adjust to it? No idea how to achieve that out of my head, but I'm pretty sure we'll come up with something

 

for example - snap pro only changes controls (f key and 45 degree rotation) and create object (spawns an object helper on the pivot). Other systems that uses buildings could not only be compatible with this, but actually benefit from that.

[PryMary]

So to make this work you would need a centralized config file in the core of Epoch, then every mod would need an init / compiles / variables + other needed files.

 

In the config you would add say:

 

#include "snap_pro\init.sqf";

 

in turn the snap_pro init would then call it's needed compiles and variables and inject them into the player_build (Core) file as and when needed. In effect making Mod's into Modules which can be turned on / off and only requires n00bs like me to upload a folder to the "Modules" folder and turn it on with:  #include "snap_pro\init.sqf"; in the central config file?

 

Am I making any sense or have I gone to Europa and back with this LOL

 

Pry

[raymix]

@PryMary: not sure how this will work out, it's still just an idea. So I am open to any new ideas to make this happen.

 

also i've split up functions into multiple files instead, so instead of 1 large file, fewer smaller files will be used and only loaded as required. Should serve as an optimization to code, I guess (thanks, RimBlock).

For time being I've added extra file for snap pro, too (controls file). I'll see if I can think of a better way to do it. However this is also one of intended ways how this mod should be used - create your own structured function, call it, reuse rest of files that you did not need to change from original files.

https://github.com/raymix/Modular_player_build

 

haven't actually tested it yet, just pasted it together for now, but should work fine. Need to rest for a bit now, then I'll see what else can be done

[raymix]

Just a heads up, guys, this is part of Epoch 1.0.5.2 now.

https://github.com/vbawol/DayZ-Epoch/pull/1505#event-150343475

 

To give you an idea - it's player_build function split into 10 smaller functions. If you are an addon maker and only need to modify small bit of code, you can simply add custom compile that will overwrite existing precompiled function with  custom path and edit it to your heart's extent. Epoch will then automatically call your function without any need to bring over player_build to mission file and fight over it with other mods. I might do a quick demonstration video today on what can be achieved.

[raymix]