Same issue for $mission and $profiles

Duplicate of https://report.bistudio.com/issues/DZEXP-85

@l909 I do not think this is the same bug, -85 complains about including files, which sounds scary as you can run probably untrusted code.

Finding files to read a set of configs is a thing that is very useful. $ variables should keep working though.....

I concur FindFile cant load in *.json. Test files ItemRenameExpTestMod

Independent confirmation on the same two builds — 1.29.163709 and

1.30.164014.27 — from a server mod that enumerates player record files under

$profile:. Five features silently stopped working. Adding measurements rather

than repeating the repro.

**1. FindFile is not returning nothing. It is searching the server's working

directory.** The prefix is discarded, not rejected. On 1.30, in one run, from a

server whose working directory is its own root:

```

FindFile("*") -> handle, 84 entries (the server folder)

FindFile("addons/*") -> handle, 236 entries

FindFile("$profile:<mod>/Players/*.json") -> NO HANDLE

```

$profile:*, $mission:*, $saves:* and a bare * all return the same

listing. So the mount is not consulted at all, and the remainder of the string

is searched relative to the working directory. That is a narrower statement than

"FindFile is broken", and it predicts every symptom in this ticket.

**2. Only FindFile is affected — $profile: writes still work.** Worth

stating explicitly given this was briefly marked a duplicate of DZEXP-85. On

1.30 we measured creating, writing and reading files under $profile: all

resolving correctly; the mod rewrites $profile:<mod>/Settings.sample.txt on

every boot and reads its settings back from the same mount.

If the intent were to confine mods to the working directory, the write path is

the one you would close first. Instead listing is confined while writing is

not, which is not a coherent sandbox — so this looks like an unintended

consequence rather than hardening.

**3. No live vanilla call site passes a prefixed pattern, which is probably how

this shipped.** There are four FindFile call sites in the 1.30 scripts:

- 2_gamelib/entities/worldsmenu.c:72 — "worlds/*.ent", bare relative.

- 5_mission/gui/newui/videoplayer.c:81 — "video\*", bare relative.

- 4_world/plugins/.../pluginconfigscene.c:112 — FILE_ROOT is declared

"$saves:" but overwritten at line 40 with g_Game.GetMissionFolderPath(),

which is relative. Registered through RegisterPluginDebug.

- 4_world/plugins/.../pluginlocalprofilescene.c:72 — FILE_ROOT = "$saves:",

never overwritten. The only site that would actually pass a prefix, and

PluginLocalProfileScene has zero references outside its own file, so it is

never registered or instantiated.

A regression test built from vanilla usage would not catch this.

**4. The documentation still describes the old behaviour.** EnSystem.c:401

names the three prefixes; :527 and :530 state that Delete and Copy work only

on $profile: and $saves:. 1.30 added a great many [Obsolete] markers

elsewhere and none to FindFile.

**5. A workaround, and its hard limit.** A relative root derived from

GetCLIParam("profiles") works while the profile folder sits under the server

directory, which is the common layout. FindFile refuses an absolute pattern,

and it also refuses ..:

```

FindFile("../*") -> NO HANDLE in the same run where FindFile("*") -> 84 entries

```

So for a -profiles folder outside the server directory there is no pattern

that reaches it, and a mod cannot work around this at all for those servers.

Flagging it in case .. is deliberate and separate from this ticket — it still

bounds how far mods can compensate while this is open.

l909 will it be fixed by 1.30 stable release? This is critical for mods.

Unfortunately I do not have any info about when this will be fixed

So, in case of releasing without this being fixed, many mods will be broken.
I think devs should adress this issue clearly with modding community.

FindFile is also broken for enumerating files in a mod PBO.

Yea, we need devs to adress this one

Additional findings (1.30.164014.27, Windows)

Test setup: a script calls FindFile(pattern, fileName, fileAttr, flags) and counts results via FindNextFile. The file $profile:ExampleMod/Configs/Example.json exists, and FileExist on it returns true.

1. Also reproducible with the retail server executable. DayZServer_x64.exe (DayZ Server Exp, 1.30.164014.27), started without -filePatching, shows the same behavior: the mod finds no files in its $profile: config folder. The detailed pattern results below were collected with DayZDiag_x64.exe (server and client), with and without -resolveFilePatchingUsingEnfusion=1. Both configurations behave identically.

2. FindFileFlags enum values are all 0 in 1.30. Script output: DIRECTORIES=0 ARCHIVES=0 ALL=0 (1.29: 0/1/2). Passing raw flag values 0, 1, 2, 3 or 4 makes no difference, the subfolder pattern returns no handle with any of them.

3. The problem is not only the discarded prefix. Subfolder patterns fail in every form:

   Pattern Result

4. $profile:ExampleMod/Configs/*.jsonno handle

5. $profile:ExampleMod\Configs\*.jsonno handle

6. $profile:ExampleMod/Configs/*no handle

7. $profile:ExampleMod/*, $profile:ExampleMod*, $profile:ExampleModno handle

8. $profile:ExampleMod/Configs/Example.json (exact name, no wildcard)no handle

9. profiles/ExampleMod/Configs/*.json (relative to the working directory, where the profile folder actually is)no handle

10. <absolute path to profile folder>/ExampleMod/Configs/*.json (absolute path)no handle

11. $profile:*handle, lists the server working directory (e.g. !Workshop, addons, mpmissions), not the profile folder

12. $saves:*identical to $profile:*

    Even root-relative and absolute paths into a subdirectory return nothing. Only a top-level wildcard returns results, and those come from the working directory. $profile:ExampleMod* returns no handle, although ExampleMod exists in the profile folder. That matches the prefix being discarded and the working directory being searched instead.

13. Impact example: A server mod loads its configs at startup via FindFile("$profile:ExampleMod/Configs/*.json"). On 1.30 it finds zero files, so the mod runs without its configs. Its in-game menu stays empty and never leaves its loading state. Reading and writing the same files by name through $profile: still works.

l909 we need an update on this, this is very serious problem, since core system doesnt work properly.

I feel this is becoming a breaking point for many modders. We don't sell our mods or make money from them. We do it for the challenge and the community.

We've invested countless hours into building some really cool mods for ourselves and the community, but this situation is making it difficult to stay positive when we're not moving forward with maintenance and bug fixes.

I really hope we can be kept in the loop with regular updates, which is exactly why this platform was created.

I'll give it a few days, the update for Badlands is scheduled to drop in (16 Days), we need to know if we have to rebuild all our mods. Maybe someone has found a workaround or solution that can be shared here so we don't lose faith in the game.

Honestly, reading fubar88’s comment hits home. I’m starting to feel the same way.

I enjoy making mods. I’ll happily spend an entire evening or even weeks figuring something out because I want to see it work and share it with our players. But right now I don’t even know whether I should wait for a fix or start rewriting things.

There’s already talk of people leaving DayZ over this, and honestly, I understand it. After putting so many hours of your own time into something, it’s exhausting to face this uncertainty and wonder how much of that work you’ll have to redo.

Community mods like DayZ Expansion give people a reason to log in every day. Players build entire communities around them. That contribution deserves to be taken seriously, especially when the people behind those mods are saying they’re struggling to keep going.

Several experienced modders have tested this, posted their findings and explained what’s breaking. We’ve done what we can from our side. It’s frustrating to keep coming back to this thread hoping for some news.

I don’t expect anyone to promise a fix overnight. But can someone from the dev team please tell us where this stands before the update? Even if the answer is that it won’t be fixed in time, we need to know so we can prepare.

Yep, thats true, technical debt increases every patch, and public part of community, are willing devs be more focused on community part of the game.

I posted a janky workaround that works as long as the profile folder is under the gamefolder. I've since added indexing so I don't have to use FindFile.

To be honest, a workaround isn’t hard to do, but for huge mods, it is still pain.
It’s not acceptable that the devs don’t reply or say anything in 12 days after the creation of the issue.

The release is in like 15 days it’s a joke.

l909 Hello, this need attention

Can you share workaround, so anyone whom reach this problem, can fix their code fast.🙏

the workaround is probably to have all mods agree on a format where you have a file, which contains a list of all files in this folder, which is read instead of using FindFile, which then needs to be updated every time a file is created or deleted. Not great and doesn't fix the problem and can easily cause problems if not updated properly, but would work if there is no other way, but this should definitely be fixed in my opinion.

I also cannot understand how we only got his one experimental update so far and not a single hotfix for the most important bugs preventing us from properly testing our mods...

100% I also don't understand either. I have many mods using your mods and Expansion mods as dependencies, so I can't even load my mods to properly test, as some dependencies are also waiting on this fix.

Let's go mod Tetris, seems safer. 😂

Who needs mods when you have a new map with bikes 🤣🤣🤣🤣🤡

Seriously, a massive amount of mods depend on CF and/or the broken function - and none can be tested. @l909 We need a fix now.

I have forwarded the concerns from the community to the dev team based on the amount of comments here.
But no other info that I can provide at the moment.

Currently we are working on fixing this on an eventual 1.30 update sometime after the initial release.

So you are breaking most community servers? Seriously?

thats also what i thought.... .

haha .... will quit this shit..

Well this is unexpected. surly we getting pranked 🤣. but thanks for the update.

We dont need it sometime, we need it ON 1.30
This is so frustrating. This is like one of the most HOT topic on this bugtracker and you respond us with "uhhh maybe sometime after"
If devs dont fix this in 1.30 release, nobody believe in purposes of this bugtracker, since no matter how many people vote, how many people comment, devs dont care and answer us "some day we fix"

l909 you must give us the answer like this:
"Currently we are working on fixing this on an eventual 1.30 second experimental"
AND NOT THE
"Currently we are working on fixing this on an eventual 1.30 update sometime after the initial release."

Honestly, this is a huge "F-you" to all modders.

We’ve been reporting this for days, multiple modders have confirmed it, and we’ve explained how badly this breaks existing mods. And now the answer is that you’re "working on fixing this on an eventual 1.30 update sometime after the initial release"?

So the plan is to release 1.30 with a known issue that breaks core functionality used by mods, and only fix it sometime afterwards?

DayZ has been kept alive by its modding community and the people running community servers for years.
Mods are a massive part of what keeps people playing this game, and this is how the modding community gets treated when a critical function is broken?

It’s honestly insane. You’re asking modders to deal with broken functionality, potentially rewrite huge parts of their mods, and somehow keep everything working for their communities, while the game moves forward with a major expansion and new features.

From a modder’s perspective, it feels like the priority is getting the new content out the door while the people maintaining a huge part of the game’s community are told: "We’ll fix it sometime after release"

And when the new expansion is already being met with its own issues, including buggy bikes, it makes this even harder to understand. Why is a critical issue affecting the existing modding ecosystem being pushed behind the initial release?

We don’t need a promise that it will be fixed "sometime after" We need this fixed before 1.30 releases!

Otherwise, what exactly are we supposed to do? Ship broken mods? Tell server owners that their mods may stop working? Rewrite everything around workarounds that may become obsolete once the actual fix eventually arrives?

This is incredibly frustrating, and honestly it makes the whole purpose of the Experimental feedback process feel pointless.
We’ve reproduced it, documented it, tested it, provided additional findings, and repeatedly explained the impact.

At some point, we need more than "maybe sometime after release"

I am done with this and i am not alone....

@l909
So, im making all i can for devs, to fix issues, which you can make only if you developing your game withot regression testing, while changing core functionality.
Since they made use of new filesystem in the engine, they simply forgot to adapt FindFile and #include to new system. This clearly shows lack of testing.



Background

In 1.30 the engine file layer was rewritten. The RTTI of 1.29 has enf::IFileSystemRV, enf::IFileSystemRVWin32 and enf::VFindFilePBO. In 1.30 these classes are gone, replaced by enf::FileSystemImpl and enf::FileSystemDefNativeDir. The script prototypes of FindFile and the other file natives are the same in both builds.


FindFile passes the FindFileFlags value as the file system index

Summary

The new FileSystemImpl::FindFirst no longer has a flags parameter. Its third parameter is now a file system index, where -1 means "use the file system named by the path prefix". The script native FindFile was not updated and still passes the script's flags argument in that position. The FindFileFlags value is used as a file system index, and the file system selected by $profile: is ignored.

Details

1.29, native FindFile (RVA 0x2636E0):

handle = fs->vfunc[0xD8](fs, pattern, &findData, flags, -1);   // FindFirst(pattern, data, flags, fsIndex)

1.30, native FindFile (RVA 0x2A58E0, call at 0x2A59CF):

handle = fs->vfunc[0x100](fs, pattern, &findData, flags);      // FindFirst(pattern, data, fsIndex)

1.30 FileSystemImpl::FindFirst (RVA 0x1FBCC0), reconstructed from the disassembly:

FindHandle* FileSystemImpl::FindFirst(const char* pattern, FindData* data, int fsIndex)
{
    PathRef ref = ResolvePath(pattern);   // RVA 0x1FFC50: "$profile:x/*" -> {profile def, "x/*", MOUNTED}
    if (ref.kind == NONE) return NULL;
    FileSystemDef* def = (fsIndex != -1) ? m_Systems[fsIndex].def : ref.def;   // array at +0x118, no bounds check
    if (ref.kind == MOUNTED)
    {
        if (def) return def->FindFirst(ref.relPath, ...);   // searches only this file system
        // no prefix: try every file system in turn
    }
    ...
}

The engine's own recursive directory walker (FileSystemImpl vtable slot 0x108, RVA 0x1FC200) calls the same FindFirst with a real file system index, so the new signature is intended. Only the script wrapper still uses the old argument order.

Script passesValue1.30 searches in FindFileFlags.DIRECTORIES0file system #0 FindFileFlags.ARCHIVES1file system #1 FindFileFlags.ALL2file system #2

FindFile("$profile:FindFileListTest/*", ...) looks for FindFileListTest/* in one of those file systems, not in the profile folder. It finds nothing and returns 0. CF GetFiles only wraps FindFile, so it fails too. FileExist and OpenFile use other code paths and are not affected. Vanilla FindFile calls on game data may still work if those files are in file system #0.

Suggested fix

• In the FindFile native, pass -1 as the file system index, as 1.29 did.

• Bounds-check fsIndex in FileSystemImpl::FindFirst.
  

• #include parses the file name instead of loading the file

  Summary

  In 1.30 the preprocessor handles #include "file" by running its own text loop on the file name, with a length of 0. The loop returns at once without an error. The file is never opened and the directive is ignored with no message. This affects every #include, not only $profile: paths. Symbols defined in the included file are then unknown, which is the error in the report.

  Details

  1.29, include branch of the preprocessor (RVA 0x117A30):

  // name copied from the quotes, '\' replaced with '/'
  if (CheckPathAccess(name, 1))                         // RVA 0x271110
  {
      err = LoadFile(parser, name, false);              // RVA 0x118380: open, read, preprocess
      if (err) Error("Can't find file '%s'", name);
  }
  else Error("File '%s' is not accessible", name);

  1.30, the same branch (RVA 0x3B0B50, call at 0x3B146E):

  if (!CheckPathAccess(name, 1, "script include"))      // RVA 0x2B4A90
      Error("File '%s' is not accessible", name);
  err = PreprocessText(parser, name, 0);                // RVA 0x3B0B50, the function this code is in
  if (err) Error("Can't find file '%s'", name);

  PreprocessText (RVA 0x3B0B50) takes (parser, textBegin, textLength). With a length of 0 its loop exits at the first check and returns the parser's current error code, which is 0.

  The loader that should be called still exists in 1.30. LoadFile (RVA 0x3B15B0) opens the file and reads it. It then calls Preprocess(parser, name, text, length) (RVA 0x3B0960), which runs PreprocessText on the file contents.

  The 0 passed as the third argument matches the false passed to LoadFile in 1.29. The call may have been switched to the wrong function or overload during the refactor.

  Consequences

  • Every #include in mod scripts is ignored on 1.30.

  • A missing include file no longer produces "Can't find file". On 1.29, #include "does_not_exist.c" should fail with Can't find file 'does_not_exist.c'. On 1.30 it should compile with no error. This follows from the code; I did not run it.

  • Vanilla scripts only contain #include inside comments, so vanilla is not affected.

  • There is no workaround in script. Mods have to read such values at run time (for example with JsonFileLoader) until this is fixed.

  Suggested fix

  Call the file loader (LoadFile, RVA 0x3B15B0 in 1.30) from the include branch instead of the text loop.
  
  
  
  
  There is no way your engine devs, can't fix couple lines of code in 14 days
  If so, it tells everything about devs who make our modding experience that funny.

on an eventual sometime after release update?
This has to be a very late April Fools joke. If this is serious... say goodbye to a not small amount of Modders that kept DayZ Community Servers alive

This is very annoying, you spend MONTHS making a mod for it just to break at every update. It's a shame you think so little of us modders, I thought a lot of you were at one time?

With this attitude towards the community, the game will simply die.

You can work-around it.
https://gist.github.com/lava76/c2abebb99ff4c9929e9e467a0e3895cc

gist is now obsolete. See https://report.bistudio.com/issues/DZEXP-134?commentId=6ac1194f41140b7f57c5c89d

Amazing always good to learn from someone els, well done i did someting similar also added subfolder scaning 😊
https://github.com/FUBAR88/DZEXP-134-temp-fix

@lava76 maybe put that into CF so not everybody has to reimplement that?

For those who want to know what to look for, thats my summary so far:

https://github.com/bzed/dayz-dev-plugin/blob/dayz-1.30/compatibility/version-130.md

(and for the AI users, its part of a skill, mainly tested in linux, but working very well for me.

$storage: works fine, but you can only use it after the mission has started (OnMissionStart).

(this was re bzed's github link, not the ticket)

My gist is now obsolete, the functionality has been added to CF-Test (on Steam) as CF.ResolvePath and CF.FindFileEx. The latter is a wrapper around FindFile that'll do all the necessary work: Test if the issue is present, and then use CF.ResolvePath to deal with it. Switch all your FindFile calls to CF.FindFileEx to use it.

@lava76 thanks a lot, will update the skill!

@lava76 Thank you will test and revert back what a legend.

@lava76 works like a champ you guys saving the mod community.
https://github.com/FUBAR88/DZEXP-134-temp-fix

https://github.com/bzed/dayz-dev-plugin/blob/dayz-1.30/compatibility/version-130.md - updated.