The features I would like to see as "feature complete"

[g4borg 74]

Dear DevZ.

Some people have issues with DayZ release not being a bug free, all-weapons-vehicles-mechanics feature complete superb game, that will somehow reignite the magic of the game in the past and surpass all AAA expectations. Most only are a bit sarcastic, 1.0 felt a bit rushed and reduced, and fear you abandon extending it.

I am not one of these people. I trust you to continue releasing content, and I rather have you work on the base, than anything else. 

 

I accepted Arma engine for being rather clunky when bohemia was still a small studio, and i could read blog posts of game programming lessons in the changelogs, which i actually read around the same time, so my bond was full of understanding, that things seem easier if you never do them.
DayZ has hands down the best engine bohemia ever created. unlike arma, it is not behind its time, actually has FPS, finally some sane networking instead of the trust-based concept that probably only worked in lan parties, and even the scripting language does not look like php anymore.

But. If you talk about feature completeness, and basicly trying to offer a game, that will not break future mods, I do have to remark, some things are rather disappointing even from the "technical feature complete" aspect.

Especially when it comes to community servers, I would actually hope for the rather painless experience.

1. Proper Database support. Those self corrupting bin files are not a really good solution. They get written a lot onto the disc. The whole process seems unstable. We live in 2019 where postgres is widely available on all platforms and supports binary json blobs for your orgasmic dynamic object pleasure. SQL was made for this. Please add database support for saves and player db.

 

I cannot stress this enough, as a developer, this is the greatest letdown of them all. I do not expect redis key value support for the server, or anything, and I do not even expect you to reimplement the plugin support of arma, which never really went further than loading DLLs and was totally no-linuxy. but using some AUX port to communicate to a third party tool was at least what i hoped for. No, not even that, no db at all, this is imho the only feature that should have been definitely learned from dayz mod back then, as the whole success of it was basicly having your own database - which also helped fixing issues, finding hackers, etc.

1.a) Please do not forget primary keys. Please do not create tables without primary keys.
1.b) Please give us the option to clean up entries ourselves, if lifetime reaches zero. It is enough if the server adds a boolean, that the item in question is considered despawned. The rest is just an SQL statement.
1.c) BIN files and an SQLite DB could still be default setup for servers without db support. It might help you debug stuff even faster like this.
1.d) Please support postgres. If you support MariaDB/MySQL/whatever, i am fine with it, but please also support postgres. Json datatype is your friend. It is super fast aswell.
1.e) Of course adding some nice script options to trigger loads from the db would be awesome.

2. Proper official Docs. Please provide proper offical docs of the Enforce Scripting Language, and the XML files and their entries. You could also work together with community members to provide it, just please make it accessible and up to date. I think a lot of people would be very happy. I am sure this is a fair and nice new years job for someone, please dear scrum management, write that ticket. ;)

3. Join by IP. Join by Steam Link. Joining by IP is impossible from inside the game. steam protocol "connect" links seem to not work (e.g. used by dayzspy). also -connect does not work if you forget to specify port. LAN does not show 127.0.0.1. Stuff like this make it really hard to actually work with testing environments or inviting friends to join your server; if the server browser does not work, not everyone is versile enough to use thirdparty launchers or connection parameters either.

4. Linux Server Binary. Yes, I know you work on this. I actually invested now into a windows server. It is expensive as hell, and feels unconformtable in my trousers.

5. Client Mod Loading. Please provide a unified way to load mods. You could make it compatible to the existing third party solution DayZSALauncher in addition to steam workshop. Just please make it possible for people to join servers without magic. The engine supports it, it feels like you only need to tie it together. Well I do hope you already have planned it.

6. Server Mod Loading. Please add possibility for the dayz server app to download workshop mods from dayz. Other apps already do that for their server solutions, so i am pretty sure it is possible. It would be also a big step for modders and security, to allow server admins to use steamcmd to update not just the server but also the mods it uses via `workshop_download_item` command; which unfortunately does not work for steam accounts not owning DayZ client - of course anonymous download for the server would also be neat.

7. Proper Mod Flags, especially Server Only Mods. Is it client/server? Is it cosmetic? Does it have dependencies? Even if dependencies e.g. are not as important, marking a mod as server only might be important for  "equalmodrequired" setting; atm. we can go two directions: either have the player install all mods on the server (leaving out the possibility to use a mod server only), or not use the mod check at all, which is built in (and building our own script based modcheck might be a bit fubar)

Okay, my points are not all totally new, but I wanted to bring them together, after what we experienced in setting up a server.
I hope someone gets to read this, otherwise, thank you all for trying your best in an industry, that is very unforgiving.

Edited January 3, 2019 by g4borg
added point inspired by pilgrim*

[pilgrim* 3514]

1 hour ago, g4borg said:

this is imho the only feature that should have been definitely learned from dayz mod back then, as the whole success of it was basicly having your own database

having the data available to hackers was what destroyed DayZ Mod and rendered it totally unplayable - as we all remember so well. ( - just saying). You can give access to game info to players when the game is an ArmA based cooperative game, because all players are friendly and cheating is uninteresting. This is not an option on a public server where any data locally available will (definitely) be exploited. Hence, rapid total non functionality & un-playability of the DayZ Mod. 

But your points are all interesting. I think they will be read and discussed.
(too bad you went for a Windows server - at least this shows the sincerity of your commitment)

 

1 hour ago, g4borg said:

orgasmic dynamic object pleasure

Disclaimer : the orgasmic dynamic object I associate with has gone out alone in my 4x4 to do some snow stuff today, and has nothing to do with SQL

Edited January 2, 2019 by pilgrim*

[g4borg 74]

1 hour ago, pilgrim* said:

having the data available to hackers was what destroyed DayZ Mod and rendered it totally unplayable - as we all remember so well. ( - just saying). You can give access to game info to players when the game is an ArmA based cooperative game, because all players are friendly and cheating is uninteresting. This is not an option on a public server where any data locally available will (definitely) be exploited. Hence, rapid total non functionality & un-playability of the DayZ Mod. 

I doubt that however, I must say I even totally disagree with this - arma itself was based on a trust based protocol, where the server did not strictly have authority - that is what destroyed the mod most, not available mission / script code. Having the source code does not automatically make it easier to hack someone. IF someone has malicious intents, he will find weaknesses in any code. In fact, if we talk software, any code that is closed source, has no official bug tracker, and only gives you binaries is usually much more prone to problems, than code where everyone can write you an email and say "hey, your code has a backdoor if we do x or y". But usually they also have more money, and a better marketing department (its like arguing internet explorer is a safer browser, because you cannot find any reported issue, while the official mozilla bugtracker has 200...)

Also even then you could have server side logic hidden from the user, did not help.

I do understand why arma was built that way (expecting friends to play friendly war games with tanks and helis, mostly in coop, and wanting to make it easier for lots of units to be usable, so giving clients direct control over them), but it totally backfired, not only on dayz; the hacks were around in arma generally, it only made it more interesting to write even more, as the mod became popular.

But anyway thank you for your positive feedback, having a first response being nice is something uncommon in the internet :)

 

[g4borg 74]

17 hours ago, g4borg said:

7. Proper Mod Flags, especially Server Only Mods. Is it client/server? Is it cosmetic? Does it have dependencies? Even if dependencies e.g. are not as important, marking a mod as server only might be important for  "equalmodrequired" setting; atm. we can go two directions: either have the player install all mods on the server (leaving out the possibility to use a mod server only), or not use the mod check at all, which is built in (and building our own script based modcheck might be a bit fubar)

Added this point inspired by pilgrim*s remark, as I started to realize, this would also be important, very much so.

Also fixed the year to 2019, as this text was started to be written in 2018, but we do not live there anymore :P