True, for owners of private servers, there should be different options that provide the ability to specify both strictly required modifications to connect to their server (breaking this list is an exception from the server, an integrity violation or a mismatch is an exception, as is done in equalmodrequired now). Also, there must be an option that indicates modifications that are not required to connect the player on the side of his game client, but can be connected on the server side of the game (this is extremely convenient for people who make minor changes to the server side of the game in their own mind).
Yes, in the current form sigtarurechek performs its function, but not as we would like, and it does not provide decent protection. And connection equalmodrequired forces even purely server modifications to distribute for the client of a game that automatically leads both to distribution of individual developments on the server, and to superfluous problems in the form of the excess mods which are not necessary for players.
In addition to the above, there is also another problem. People entering from the game browser inside the game on the server with modifications simply kick with them, and rarely one of them can understand at least why. There is no way to indicate even the server page to such people, let alone to indicate to the player why he is excluded and what is wrong with his side. As a rule, such people simply go to look for other servers, thus online on servers that can be made interesting and unique, simply lost, and the server is forced to close.

When the logs cycle and add to the file count, it will not be good enough

I believe that such restrictions should not be on the server side and on the client side for the single player mode (offline). In any case, I do not even see the reason for such restrictions, it creates additional difficulties in working on the game and its code for everyone who tries to create their modifications in any way. But if you have a need for this kind of thing, I would advise you to simply add an optional parameter to the configuration of the server and the game client that allows you to either remove such a lock or specify its size. This would solve a lot of questions and problems for both the authors of the game, as well as for the authors of modifications.

i understand that on user side there have to be limitations, and solutions against abuse have to be found.

A devmode parameter will not be sufficient to resolve the max file count issue, as the general user does not set launch parameters to join servers.

Fixed in 1.03.

it is posted Feb 14 2019, 8:34 PM
Devs, why this don't fixed?

What jacob is suggesting sounds like a good compromise as having my mod in a folder is okay but base game is still all over the place.

Also, it does not show inventory in case if you create physics on the object using dBodyCreateDynamicEx and after 15 seconds that physics geometry will respawn/destroy itself so you can not open inventory of object any more

Fixed in next 1.03 iteration

This seems to perform well enough atm so we will release some use examples soon for you to fiddle with

I have narrowed the issue down with further testing. This filter prevents my object from beeing visible

Buildings are not visible in the vicinity.

It would help knowing what exactly are you trying to use this for, but from a quick test, overriding IsInventoryVisible() should make the building visible in vicinity, the snippet above deals with inventory being visible through walls

If it is indeed to problematic (I don't see how), can all the files in the DayZ scripts.pbo also be moved into a DayZ subfolder in all the modules?

I was thinking about this a little bit, and thought to myself what I would do with a Enum.Insert, and I have determined that my use would be to add EventTypes, so I could make a custom events that would run on the event system. Unless there is a simpler way of doing this.

It seems to save the data correctly; however, it doesn't load the map/class correctly, and results in said error.

Yeah already checked the progress in 1.03 and it's good.

The issue here is that the system is still WIP and you tried to fiddle with it somewhat early. There has been some progress made for 1.03 but it's not quite done yet, we will release use examples when we consider it usable enough

Salutesh and I were just discussing this.

Add an example of where would you want to use this please

So changing this on the workbench level could be problematic, but you should be able to do what you need already by using folders/custom names

Actually, we should have the possibility to do modded class of magazine for overriding some functions

Actually new idea.

@Masspwnaged @Niphoria @Baconproteter @AussieCleetus

Because you don't have to, class Magazine is inherited from class ItemBase which can be modded

The weather controller class also has this issue, it seems like it's intended to be an extendable/modded class but it reports the same thing, engine class cannot be modded. This is in the weather.c script file. Not sure if it's intended or not, just reporting it.

If the directory creation in $profile is lifted, the file count cap can be avoided. I'm personally finding a lot of issues with creating a config json file on a regular player's system (or even an inexperienced server owner's server), because of the limit to file count and the fact that logs cycle (not a bad thing on the cycling, it just means that unless archived regularly, the cap is hit faster).

proposed solution to this won't make it in time so we will temporarily increase the limit to 50MB per file in 1.03

Alternatively, add a function "SetFrequency" to the AbstractWave class. Since volume can already be controlled via script this would then give total control over both. The formulas for calculating both volume and frequency can be done in enscript then.

I would love to make some mods publics, but that would suck to force my french players to have english strings. This is a must have.

Possibly this could at least be added to the debug version of the game, as that is primarily used by developers anyway.

More information on this one if @rVn not sure what we mean by that. Currently, there is a function in vehicle script class

My use case for the ability to edit every house is properly add a proxy to all the doors so I can attach an object such as a code lock.

There are some of the reasons why it should be edited:

FIxed in 1.03

This requires a cleanup before release, logged as to-do

The issue here is that internal debug functionalities in general are separated from retail exe's on purpose because many of them may affect performance in some form even if they are not 'active'. That being said a bunch of them are pretty important from development perspective so we are looking at possible options at this point.

DLL extension support is not planned, and unlikely to get in assuming the amount of work required and the issues which would require solving.

This right here does the trick. Problem solved!

Just use the passed in mod parameter to split the files.