Sprint 11 Review

[Wyqer]

General Information about sprint reviews

As we will release a working iteration of the new framework after every sprint, everyone is invited to help with testing the sprint results.
The only thing to remember is that you should only report bugs in this issue, which are caused by the contents of this sprint (which are listed below). So it is vital to look at the content description to see what was actually added. Only by reading this you know what we've really intended to implement and defined as done.
I guess you understand that reporting things which weren't even planned to be part of the sprint won't help in any way.
This releases (which are also marked as Pre-release) aren't meant to be played as replacement for the current framework. It is for testing purpose or a kind of first look at features/changes which will be part of the 0.97 release in some months.
For serious playing use the latest stable release: v0.963a

Summary of this sprint

With Sprint 11 we've mainly extended some of our last modules and added smaller general tweaks/preparations for the upcoming sprints.

This summary has gotten somewhat longer, so for the tl;dr people out there: We added/reworked/extended/adjusted/planned/prepared some stuff.

The Logistic Module got extended with the (maybe to some already known) KP Cratefiller as adjusted implementation in the Liberation framework. If you don't know this small script addition for missions, have a look at it with the provided link. It's easily added to any mission via very small script work, which is also completely documented in the repository's readme. Furthermore the logistic module got its connection to the resources module for creating/deleting resources at the FOB for resupply or recycling of vehicles. So these features are now "fully usable" (until we extend/rework/nuke it again).

We've also added some additions to the Permission Module. It's now possible to control the access to specific slots (commander and sub-commander are implemented by default), the build menu and the logistic station. This also comes with some code optimizations and CBA settings to control the permission dialog access. I guess we can provide a full documentation with one example on how to implement own permissions with this framework in the next sprint.

With the intended "more strategical stuff" for the commander, we've continued the work on the Garrison Module with a first foundation for the garrison dialog. This dialog will make it possible for the commander to virtually store units at sectors, which then will spawn for sector defense upon enemy attacks. Of course he can also ungarrison specific units or infantry amounts to send these troops via Zeus to other sectors and store them there. This aims for our later goal that the commander really needs to fulfill a strategic commander role which would mostly have enough to do when waiting at a FOB and manage/organize all aspects of the campaign. So we aim for that the commander shouldn't be just a "normal attacking soldier with 2 more dialog options" but feel really like a commander. Especially for smaller groups it would be possible to have the commander player act like in the old framework, of course.

The action to access the garrison dialog is currently removed, as it's not finished yet. If you really want to have a look at this unfinished state, you can remove the comment slashes at this line and for "something more to see" replace KPLIB_sectors_blufor with KPLIB_sectors_all at this line.

One thing that has always been a kind of an "immersion breaker" was the fact, that vehicles etc. are only saved at FOBs and therefore due to needed server restarts you always started from an "assembled state" with your troops. This will change with the Persistence Module which will in the future take care of the saving of vehicles/units on the battlefield. It'll not only save their positions everywhere on the map, it'll also save their damage, ammunition and cargo. So a "small camp" built by parking some resupply vehicles on a mountain ridge without placing down a FOB will be absolutely possible. These features are currently already implemented. With the next iteration we'll add the needed crew persistence and support for the ACE cargo framework.

Another small addition we're currently adding "on the fly" is the Public Attribute for Functions. Meaning for our later function library documentation, which we want to provide for all of you, we'll only list so called "public functions". This attribute means basically, that these public functions can safely be used by other creators/contributors without a specific condition or dependency. Functions which are not public are mostly functions which are created for a specific purpose, so for example to apply the value of a dialog control to a persistent variable. So basically things which aren't useful in a general matter or outside of its current usage. We haven't adjusted all function headers, but we'll add them one by another during the next sprints.

This dev blog really seems to get somewhat bigger, hope you don't mind it.

As an outlook for S12 and maybe also S13: We've kind of reached a point where the project gets bigger and bigger, more and more files/functions are added and as we're a team of three people, we see the need for a documentation, even for the usage inside the team. So we decided to do a "feature stop" from now and just finish the modules we've started until now. Then we want to write down a sensible documentation for modules which are reused on many places or provide a kind of framework. As a more concrete example we would provide documentation on how to implement more permissions with the usage of the current permission module or how to add something to the persistence module handling, etc.
We're still not sure, if we will just use the GitHub Wiki for this or if we setup a small website which is generated automatically from our source files (for the function library) and some markdown files we add to the repository.

And now one last thing until you're released from reading this dev blog:

Tester wanted

We've found two testers. If someone leaves or we could need one or two more, we ask for more help in later dev blogs.

As the complexity and amount of mechanics/functionalities is growing from sprint to sprint we've come to a point where it takes much time to test all things more deeply as "starts without errors and if I push this button nothing explodes, looks fine". This will possibly lead to the fact that with the progression of the whole refactoring the amount of uncatched bugs which appear in the releases will grow and therefore we have to spend more time for bugfixing in the next and next and next sprint. To avoid this we would like to ask for one or two people who would like to support us as reliable testers. If you're interested in helping us in this way, feel free to start a conversation with one of the dev team on the KP Discord Server. And now the usual overview about the "job":

What you would have to do:

• Deeply test the implementations directly during the sprint upon heads up of the devs
• Provide structured feedback and/or bug reports depending on your test results
• As you'll be added to the "Liberation Support" role on the KP Discord, help people especially in terms of the refactoring etc. (as you'll be very familiar with it due to your "work")
• Keep the public test server up to date and use it for playtests in a dedicated environment (you'll get full admin access via a web interface to the test server for this)

What you should bring with you:

• High reliability in your work and commitments. No "I try it for one week and then I just leave without a trace"
• Knowledge of how to create a Liberation mission pbo via basefile and framework
• Basic knowledge about Git(Hub) so you can pull the code as a local copy, know how to switch branches and how to update your local copy via git
• Good English skills to provide support on Discord if needed and to discuss things with the devs without language barriers
• Knowledge of how to administrate an ArmA 3 server, how to get/read server rpt logs and how to update mods on a dedicated server

What do you get:

• You work together with a reliable team of developers on one of the most played/edited/derivated ArmA 3 mission frameworks, which will also be mentioned
• You can directly influence the look and feel of the mission due to your feedback and your opinions during dev planning/discussion phases
• The test server, which runs on the KP root server, will be in your hands. And if you don't test something or invite some friends for some "hot code Liberation testing", you can of course use that server for own small events or play sessions with your friends for any kind of ArmA 3 mission
• And of course the appreciation of the dev team and for sure the Liberation player community for your support and work

Content of this sprint

Task	Description	PR
#569	Logistic Module pt2	#581
#571	Permission Module Additions	#577
#573	Garrison Module pt3	#582
#576	Persistence Module	#578
-	Public/Private Functions Attribute	#579

Released sprint result

https://github.com/KillahPotatoes/KP-Liberation/releases/tag/v0.97S11

IMPORTANT: You need to log in as admin, to be able to get in on the commander slot. This is due to the new permissions for the commander/sub-commander slot. As admin you can initially set the permissions via the dialog.

Official public Testserver

The latest pre-release missionfile is running on our public Testserver. Feel free to join and have a look at the current development state. We would highly appreciate any feedback and/or bug reports.

Name: KP Liberation Dev Testserver

IP: 195.201.56.254

Port: 2322

Needed Mods:

• CBA A3
• KP Ranks

Bugs found so far

#	Related Task	Description	Reported by
01	#517	Limited camera in zeus estimate the height limit from the ground not from player height (issue if on Water) fixed in 100d785	@Wyqer
02	#529	Vehicles could spawn at the same place and explode, when convoy is spawned. Needs some timing optimization	@Wyqer
03	#533	Spacing between Logistic menu buttons isn't final fixed with #581	@Wyqer
04	#540	Switching sides via preset change causes "pure chaos" fixed with 189bf98	@tyl3r99
05	#573	Infantry doesn't spawn on sector activation fixed with 9a9a572	Discord

Sprint History

Sprint	Quick Summary	Details
10	Resupply of vehicles via a logistic station, first iteration for the enemy commander module, Bugfixes	#570
9	Permission and resources modules, second part of the garrison module, finished universal preset	#562
8	Arsenal, complete settings overhaul and universal unit preset templates	#544
7	Persistent sector garrison, build menu implementation part 4, common functions module	#520
6	Own Respawn template, object manipulation in build menu, event based save/load	#505
5	Freedom replaced with Liberty, extended CBA implementation, refactor mission init, build camera refactor	#494
4	Player and Admin menu, building camera overlay	#471
3	First UI overhaul, config guard, free build camera	#445
2	Event handling and action manager	#427
1	Basic CTI functionality: Intro, Spawn, FOB deploy, capture sector, win campaign	#404

[tyl3r99]

amazing stuff i will do my best to help where i can around RL situations :)

[tyl3r99]

im having issues trying to use commander slot on my server (0.97S11) I am logged in as admin, any ideas?
screenshots;
http://prntscr.com/n9br2s
http://prntscr.com/n9brbb
https://pastebin.com/Yt70gwSW <--- Exported settings (server)
https://drive.google.com/open?id=1YbTOWw27-88Kf9PR8hykLzCYPlfD4WxH <--- RPT
https://drive.google.com/open?id=1kN0pjoKLoXSnfL_dQV37zBX1eCkS85Rc <--- Mission file

I cant seem to find the whitelist file to add our UID's to the commander roles.

[Wyqer]

Make sure you use the published pbo and not the source code from the branch atm. In the branch there is an issue (which you're describing there) which we found just before publish, so we tweaked the release file. This fix will be added to the repository with S12.
But you could also login as admin, take one slot which is not commander or sub-commander and access the permission dialog via the action menu, to set the permissions.

[tyl3r99]

Ahhh yeah I downloaded the branch S11 and made it into a mission file. Ok Will download the mission from the review page. Thanks wyqer

[EvilSh4d0w]

i have a few questions about the persistence module i think the idea is really great just i see the problem of the performance on many servers and then i'm sure that some players will drive out with the vehicles and leave them there and others will build new and exaggerated then probably hundreds of thousands of vehicles somewhere on the map will be distributed. or through this module it should also be possible that you build positions and these are then stored there and they are there again to be found. what will I think then also again on the performance will be reflected. what possibilities will there be to prevent this possibly? so I think there zb to limit the construction quantities of the vehicles as it is already possible in the version 0.963 with the helicopters and jets but also that one should then think I can limit further or will there be also the possibility that such things are deleted after a certain time if they are unused? or do you have there perhaps already other conceptions?

[Wyqer]

i'm sure that some players will drive out with the vehicles and leave them there and others will build new

This can prevented easily with the solution "social -> talk with each other", which is mostly less effort than technical solutions.

limit the construction quantities of the vehicles as it is already possible in the version 0.963

We don't plan to extend the "vehicle limits" to more than the air vehicle caps

will there be also the possibility that such things are deleted after a certain time if they are unused?

There will be a garbage collection, like it's already a part of the old framework.

[EvilSh4d0w]

i'm sure that some players will drive out with the vehicles and leave them there and others will build new

This can prevented easily with the solution "social -> talk with each other", which is mostly less effort than technical solutions.

limit the construction quantities of the vehicles as it is already possible in the version 0.963

We don't plan to extend the "vehicle limits" to more than the air vehicle caps

will there be also the possibility that such things are deleted after a certain time if they are unused?

There will be a garbage collection, like it's already a part of the old framework.

Yes I think this is easier said than done for some players but yes you're right "talking to each other will help up to a certain extent" which I think would be nice anyway if in the field left vehicles can be marked beyond a server restart on the map.

but thanks for the work, your efforts and the quick answer.

[tyl3r99]

On my public liberation I just enabled full zeus and if I see a vehicle abandoned by a player I keep an eye on it and if it's not used I'll simply go pick it up with a halo drop or slingload

[Wyqer]

Bug 05 fixed
9a9a572

[Wyqer]

Added hint for already hired testers in the dev blog.

Welcome to @Nightwolf2112 and @SSV8TE as our two team testers.