Skip to content

Developer's FAQ

Jump to bottom
friznit edited this page Feb 12, 2016 · 1 revision

h1. Developer's FAQ

{{toc}}

h2. Why use feature branches for every module? And would this make the pre-release merge a nightmare?

Feature branches are only used while the code is unstable. Once the module code has been peer reviewed and tested, its merged back into the develop branch. This gives us an extra layer of stability and the opportunity to ditch features if they are not working out and the punters get master (for stable code), develop (for tested code) and individual features if they want to live on the edge.

h2. How do we allow for mission parameters using the modules approach?

We insert mission params at PreInit. More info ?

h2. How can I access values of the module params (f.e. dropdowns or fields that can be set in editor)

You can access the values of the parent arguments class of your modules cfgvehicles.hpp with getvariable

Example: .... class Arguments { class CQB_debug_setting {......

_logic getvariable ["CQB_debug_setting",false];

h2. How do i implement CBA Debug (DEBUG_MODE_FULL) correctly

In "\x\alive\addons\main\script_mod.hpp" there is a list of DEBUG flags for every module, you should add your new module in there:

Example: // #define DEBUG_ENABLED_MAIN // #define DEBUG_ENABLED_SYS_ADMINACTIONS // #define DEBUG_ENABLED_FNC_STRATEGIC #define DEBUG_ENABLED_NME_CQB #define DEBUG_ENABLED_SYS_NEWSFEED #define DEBUG_ENABLED_SYS_RWG

In your modules folders script component there should be a sub-define like this:

Example: #ifdef DEBUG_ENABLED_NME_CQB #define DEBUG_MODE_FULL #endif

This way you can control debug for each module, and its only controlled during compile. Its for debugging within the addon and its main purpose is to enabled debugging mode of CBA related stuff like turning on logging, etc. and not suited for endusers usage. For example LOG(), TRACE() only work if DEBUG_MODE_FULL is enabled. Its not to be mistaken with an enduser debug-functionality (fe. CQB debug where you turn on the markers on and off directly in game or the module switch in editor).

h2. What is the order of initialisation before a mission?

XEH PreInit

Module eventhandler Init (in config)

Module init line (in editor)

Mission Init.sqf

XEH PostInit

Module config function

h2. How can I read/write data to/from my module?

The ALiVE mod uses Arma2Net (by Scott W) for all external data access. Specifically, we have written a number of Arma2Net "plugins" to allow us to read/write data from web services and databases.

h3. Set Up

External services often rely on username, password, auth keys etc, these things are not suitable for Server Admins to include in mission PBOs, so shouldn't be configured on a per mission basis using editor modules. Instead, the Arma2Net plugins we use rely on a set of text files (on the server) to store this information.

For ALiVE, you are required to register on ALiVE War Room (alivemod.com), create a group and then register your PC/Server as a game server. Its important to ensure the public IP of your machine is correct and updated if changed. You will then be able to download the alive.cfg file which provides the credentials required for DB access.

In addition you will need a copy of Arma2Net running as an addon on your server machine, this can be downloaded when registering your server on War Room. Our own plugins (from the repo) are included in the Arma2Net download.

Also see here https://dev.withsix.com/projects/alive-repo/wiki/SettingUpData

h3. Posting events to alivemod.com War Room

alivemod.com is the current web "front-end" for ALiVE players. The purpose of this website is simply to provide a sense of community and allow players and groups to track their "performance" via the ALiVE War Room.

For more information http://dev.withsix.com/projects/alive-web/wiki

The sys_statistics module currently tracks player activity such as weapons fired, kills, vehicle time etc. sys_statistics uses in game event handlers to capture events. Each event triggers a function (such as sys_statistics_fnc_getOutEH) that records the event information and formats it as an array of key/pair values. The data is then applied to a PublicVariable called "ALIVE_sys_statistics_UPDATE_EVENTS". sys_statistics currently has its own PublicVariableEventHandler that listens for changes to that PV, once triggered the data is appended to some common server/op data (including date/time, server IP, operation name, map etc). The data is then sent to a sys_data datahandler (created in sys_statistics) where the data is converted to a JSON string and is then pushed to Arma2Net using Arma 3's callExtension command. Specifically, we call SendJSON (which is function in ALiVEPlugIn) that can send a JSON string to a web service. In the events case we are posting to a couchDB and those events are shown live on the website.

Of course any module can then post to the website using the following code (example for a combat dive event):

You can use an array as below or a CBA hash.

// Log data
_data = [ ["Event","CombatDive"] , ["unitSide",_sideunit] , ["unitfaction",_factionunit] , ["unitType",_unitType] , ["unitPos",_unitPos] , ["unit",_unit] , ["diveTime",_diveTime] , ["Player",getplayeruid _unit] , ["PlayerName",name _unit] ];
		
// Send data to server to be written to DB
GVAR(UPDATE_EVENTS) = _data;
publicVariableServer QGVAR(UPDATE_EVENTS);

Once you have decided on the event you would like to post, we need to update the website data feed code to cater for it. Here's an example bit of Javascript code that displays a hit event:

	if (row.value.Event == "Hit" && row.value.PlayerHit == "true")
	{
		$('#data')
		.append(row.value.Map + ' - Grid:' + row.value.hitPos + ' - ')
		.append(row.value.gameTime + ' local
')
		.append('' + row.value.hitfaction + ' ' + row.value.hitType + ' ' + row.value.PlayerName + ' has come into contact with a ' + row.value.sourcefaction + ' ' + row.value.sourceType + ' and has been hit.')
		.append('
' + parseArmaDate(row.key) + ' - Operation ' + row.value.Operation +'
')
	}

h3. Setting up an (optional) local replicated version of the community couchdb

Download - http://mirrors.ukfast.co.uk/sites/ftp.apache.org/couchdb/binary/win/1.3.0/setup-couchdb-1.3.0_R14B04.exe

Run installer, select to run as a service, next, next, finish

You will access to our ALiVE Repo pages in order to get the scripts to sync to our prod DB. See here https://dev.withsix.com/projects/alive-repo/wiki/

h3. Posting live data to xRTML

TBC

h3. Storing data to SQL/CouchDB

In the XEH_preServerInit.sqf of your module insert:

	
// Setup data handler
	GVAR(datahandler) = [nil, "create"] call ALIVE_fnc_Data;
	[GVAR(datahandler),"source","couchdb"] call ALIVE_fnc_Data; //maybe chosen by mission maker via module params
	[GVAR(datahandler),"databaseName","arma3live"] call ALIVE_fnc_Data; // maybe chosen by mission maker via module params
	[GVAR(datahandler),"storeType",false] call ALIVE_fnc_Data;

Whenever you want to store data call

_result = [GVAR(datahandler), "write", [_module, _data, _async, _uid] ] call ALIVE_fnc_Data;

_module = string - essentially the table/data bucket, this has to be unique _data = Array of key/value pairs (soon to be CBA Hash) _async = true or false, currently if false the write is done asynchronously and no db response is returned. If done synchronously, confirmation data is returned _uid = string - unique identifier for that record (will be used to reference that record when reading data)

h3. Reading data from SQL/CouchDB

See Code Examples.

Clone this wiki locally