Merging issue with multiple packages

[thevisad]

Multiple packages are having merging problems with all of the differences, Namalsk, Orign, Messaging and SSZeds.

[thevisad]

merging all of the problems of the same sort into one issue

[JoSchaap]

current merging system is a problem indeed :)

isnt it an ide to work with placehoders that will be replaced with PKG code (kinda like how the BE filters are updated atm)

so in the server code you reserve blocks

/* #PACKAGE001# */

/* #PACKAGE002# */

/* #PACKAGE003# */

/* #PACKAGE004# */

/* #PACKAGE005# */

in the commonly-by-packages-alterred files which are replaced with the actual package code? this also removes the need of merging alphabeticly :)

[BBSDeadEye]

Take a look at https://github.com/BBSDeadEye/DayZ-Private-master/tree/Pkg-Test I was already going for that but its far from done. I have commited what I have so you can see what I am going for.

The Idea is similar to yours. Just having to truly merge a file with placeholders. Only Problem is, that its a WIP and my time is limited :P but: @thevisad I think this could be ready until the weekend if you are intrestet

[BBSDeadEye]

So I think I found a system that works. In my Pkg-Test branch there are modified packages and util directory and a PkgBuilder.exe . The Idea is that you have comments in the util\dayz_server\ files that mark begin and end of an area. The pkg files hint with their file names where and how to insert them. Examples

1. server_playerLogin.before.modelCheck.sqf will add the contents of this file before the content of // START modelCheck comment in the server_playerLogin.sqf file
2. server_functions.after.include.sqf will add the contents of this file after the content of the this area, just before the // END include comment of the server_functions.sqf file
3. server_playerLogin.replace.modelCheck.sqf will replace the contents of server_playerLogin.sqf within the area // START modelCheck and // END modelCheck

this methods allow to insert and overwrite parts of a file very exactly. This maybe is not the best practice, but either is replacing the whole file every time like it is done now. Also, a computed diff is much to dependent on human decisions as you all know on conflicts like in a git repository.

For best efficiency the package order should be:

1. all files from util // this is the base 'repo' for building and contains all base classes
2. all files from hive // theoretical you could use other hives too!
3. all files from hive addons (dayzplus etc..) // I think the place for this package is at the same level or closely after the hives
4. all files from maps // custom code like skin checking, vehicle checks etc..
5. custom packages // killmsgs, buildings etc... do integrate better after all other pkgs are build in.

I had very good results with this method and it allows enough freedom to combine/overwrite in every way needed for package building.

If you think this method is good enough, I could either release the sources of PkgBuilder.exe (A very simple c# program) or send the code to gdscei for integration into the RealityCP.exe (or fork his repo and push something)

[BBSDeadEye]

note: I only have converted some of the packages to this system. However, the old system with replacing each other is also supported. Example:

5. server_monitor.sqf will replace the complete contents of the server_monitor.sqf

so you see this system also allows to work like the old one :)

[thevisad]

This seems to be a very tedious system to break down, especially with only 1 or 2 users creating the packages and how often they change. I agree that the current system is not perfect, but it is much more manageable at this moment. If we are going to replace things like this, we need to keep an eye on the future.

[BBSDeadEye]

It may look difficult to maintain but basically its the same like when you make a diff for a file. Only that these files do only contain the differences. If you project this diffs to the server files base you get exactly what you need to work for.

Another but similar, maybe better maintainable approach would be to have the contents of the file like before, but mark the replacements directly in the file via i.e. comments. So you have to whole file like before but can insert.replace via commands that are given within the comments.

[thevisad]

I would have to see this in action in order to better appreciate it then.

[BBSDeadEye]

My other approach with the comments still seems to have some issues (for example the private variable lines which are tricky) I see you already have done some things for a new struktur... Are you on to this issue?

[thevisad]

200

[thevisad]

Unable to resolve this issue, the merging system just simply cannot handle all of the merging tasks that are required for this to work properly. Closing issue, please post in the forums at http://opendayz.net/index.php?forums/support.100/ for any further support.