This is named community, where people consolidate and help each other.

EU part of the community was silent, i've sent this post to Enfusion Modders, and there were couple people interested in game progress. So i've asked many developers and community hosters to highlight this huge problem to the devs.
No bots were used in this work, if so, BI can delete this post and purge 225 upvotes from my rank, i dont care about rank or anything else, my motivation is the game and cool stuff that i can make in it, simple as that.

We as modding community need more memory, so there can be more complex and great mods.

@l909 Hello.
Any updates on that:?

i think that won't make it into the game, because of user-safety concerns. (Same story with $ virtual file storage)

@l909 hey, heres my research on that

Summary

A member (method or field) added by a later modded class block is not visible inside an earlier block of the same class. Each block is compiled as a separate class in a base chain, this in a block has that block's class, and member lookup only walks toward the base.

Reproduced on DayZDiag_x64 1.30.164200 -server). The same code is in 1.30.164078 and 1.29; there the hidden name looks like TestClass1@226#38.

Repro

```c

class MFR_Test

{

}

modded class MFR_Test

{

void MFR_Test()

{

float a = GetRadius(); // Undefined function 'MFR_Test#440#29.GetRadius'

// float b = this.GetRadius(); // same error

// float d = m_Late; // Can't find variable 'm_Late'

float c = MFR_Test.Cast(this).GetRadius(); // compiles, returns 10

}

}

modded class MFR_Test

{

float m_Late = 7.0;

float GetRadius() { return 10.0; }

}

```

Actual: Can't compile "Game" script module!, Undefined function 'MFR_Test#440#29.GetRadius'.

Expected: compiles. All blocks are one class: ClassName() in the first block prints MFR_Test, and the Cast form finds the method.

Cause (addresses: DayZDiag_x64 1.30.164200, image base 0x140000000)

1. After parsing, the chain builder (0x1402659F0) turns every modded class X into a new class derived from the previous one. The previous class is renamed to X#<file index>#<line of the block that replaced it> and marked displaced (AST +0x6A). The class pass (0x1402A0790) copies the mark into class flag 0x800.

2. The body pass (0x1402AA6F0) sets the current class to the block's own class; 0x1402936D0 binds this to it and super to its base. The current class is also used to find the method being compiled and for the private/protected checks (0x1402ABBE0, 0x1402AC0B0).

3. An unqualified call uses this as the receiver (0x1402A9C20). The call compiler (0x1402A48B0) takes the receiver's class and calls FindFunction (0x140298B50): class methods via 0x14028F480, then module globals. Variables go through 0x14028F700. Both walk cls = cls->base (+0x28) only.

4. Members added by later blocks sit in derived classes, so they are never reached. MFR_Test.Cast(this) works because the name MFR_Test resolves to the last block.

Fix

Where the compiler resolves a name against a receiver class (call compiler, and the variable / member-access path), a miss in a displaced class should switch the receiver class to the last class of the chain and repeat the lookup. The rest of the access then uses that class:

```c

member = LookupInClass(cls, name); // class and its bases, no globals yet

if (!member && (cls->flags & CLASS_MODDED_DISPLACED)) // 0x800

{

member = LookupInClass(cls->moddedTop, name);

if (member)

cls = cls->moddedTop; // slot, static-call class, access check use it

}

if (!member && !explicitClass)

member = LookupGlobal(name);

```

moddedTop can be stored in the class pass where 0x800 is set; the chain is final by then. It is the type that owns the original name, so the chain builder should keep that name on the AST node when it renames it (its second loop already saves the old name).

Why not the simpler-looking options

- Retrying inside FindFunction / FindMethodIndex: they return only a function and a slot. The caller keeps the old receiver class, and for a static callee 0x1402A48B0 builds the call from that class plus the slot, so at runtime the slot is read from the displaced class's table.

- Typing this as the last class: this is bound in two places (0x1402936D0, 0x1402A0790), and the current class can't change because it locates the method being compiled. The private check needs the current class to derive from the receiver class, so every this-call to a private method in a modded class would fail, vanilla classes included. It would also change which version unqualified static calls bind to.

@l909 hey, i've made an research on that:

DayZServer_x64 1.30.164078, compared with 1.29.163709 (identical behaviour)

Summary

Not caused by #ifdef and not a 1.30 regression. Inside a modded class layer, an implicitthis call is resolved only from the current layer down to its bases, never up to the final class. Whether the code compiles therefore depends only on which of the two PBOs is loaded first.

1. How modded classes are built

For each modded class X the compiler renames the current X to X@<file>#<line>, makes the new layer derive from it, and rebinds the name X to the new layer. Result: one inheritance chain base -> layer1 -> ... -> top. The name X always means the top layer. A lower layer has no link to the layers above it.

2. Where the call fails

Precedure_2() without a receiver is compiled as a call on the current function's this, with no explicit class. The lookup class is the static type of this, i.e. the layer that owns the method body TestClass_1@441#1). The method lookup walks that class and its bases, then global functions. A method declared in a later layer is never found, so the compiler reports a hard error (not the FIX-ME warning path):

Undefined function 'TestClass_1@441#1.Precedure_2'

Member variables behave the same: Can't find variable 'm_Var'.

3. Why it depends on load order

Layer order = CfgMods order = config load order. PBOs are sorted by prefix (case-insensitive); then a dependency pass emits each addon once its requiredAddons are loaded. Command-line order and -mod vs -serverMod do not matter. The code compiles only if the server PBO happens to load before the client PBO; changing a prefix or adding one requiredAddons entry flips it. Same algorithm and same results in 1.29.163709 and 1.30.164078.

4. The call itself is valid

In the failing order (client layer below the server layer), this compiles on 1.30.164078 and calls the server-side method at runtime:

TestClass_1.Cast(this).Precedure_2();

The same works for a field added by the upper layer. The name TestClass_1 already resolves to the top layer while the lower layer's body is compiled, and at runtime this is always an instance of the top layer.

5. Suggested fix (small, local, backward compatible)

In the call compiler, where the method lookup on the class of this fails, before reporting "Undefined function":

- if the call has no explicit receiver (implicit this, or this.) and the class of this is a renamed modded layer,

- repeat the lookup on the top layer (the class currently bound to the original name),

- if found, compile the call as on Cast(this) to the top layer: a normal virtual call on this.

Apply the same fallback to member variable lookup ("Can't find variable"). Code that compiles today is unaffected, because the fallback only replaces an error. If a lower-layer type can be instantiated through reflection, use a checked (null-safe) cast for the fallback call.

Changing the load order (e.g. loading -serverMod first) would not fix it: it only changes which pattern fails.

Workaround for current builds:

TestClass_1.Cast(this).Precedure_2();

or an empty hook in the client layer, override in the server layer, and the client CfgPatches in the server's requiredAddons.

You're incorrect, since i've posted the reason and solution for this particullar issue https://report.bistudio.com/issues/DZG-837?commentId=6abe9e0f41140b7f57bbe1eb

I think it’s simply a matter of stability and architecture, since a static memory arena is fairly easy to use and gives you both speed and stability.

Hello, please consider removing your comment. This is an English-only bug tracker, and it’s not the place to insult devs.
It’s great that devs are listening to the community and fixing such issues in 1.30.

Hey, i've made research on that
Heres my analysis

Problem
A static method is bound when the call is compiled, not when it runs. In the report, TestOverrideFunction() is written inside the original MissionServer. So the call is bound to the original class, and the override static from the modded class never runs from there. Measured:

• An unqualified call inside the original class, from a static or an instance method, runs the original.

• MissionServer.TestOverrideFunction() runs the override wherever it is written.

• An unqualified call inside the modded class, or inside a subclass of MissionServer, runs the override.

• override static compiles with no error and no warning.

So the same call gives different results depending on which class body contains it. The pbo that holds the modded class doesn't matter.

Cause

• modded class X creates a new class derived from the previous X and rebinds the name X to it. Subclasses derive from the newest class. Code written inside the original X keeps the original class as its scope.

• Name lookup (RVA 0x24D8E0, overloads at RVA 0x24DA10) searches one class. That is the type named in X.F(), or else the class whose body is being compiled, followed by its bases. The lookup records the function's 1-based slot in that class's method table.

• The call compiler (RVA 0x2596D0) checks the static flag, bit 0x4 of the function flags at +0x50.

  • For a static function it drops the implicit this and stores the lookup class in the call descriptor (RVA 0x24CE40; slot at +0x08, class at +0x10).

  • For an instance function it stores no class.

• At run time the opcode 6 handler (RVA 0x21E196) resolves the target at RVA 0x2253A0:

// RVA 0x2253A0, error paths omitted
if (!receiver)                                  // static call
    table = cls ? &cls->methods : &module->functions;
else {
    if (!cls) cls = (*receiver)->type;          // instance call: run-time class
    table = &cls->methods;
}
return table[slot - 1];

For TestOverrideFunction() from the report:

cls  = MissionServer /* original */;                  // scope of the body; the modded MissionServer is a separate derived class
func = FindFunction(cls, "TestOverrideFunction");     // original function, slot k
desc = { .slot = k, .cls = cls };                     // static: class fixed at compile time
// run time: cls->methods[k - 1] -> the original, whatever the modded class declares

MissionServer.TestOverrideFunction() works for a different reason. Its qualifier is resolved by name first, which yields the newest modded class, and the lookup then runs in that class.

The override check (RVA 0x25A620) accepts override on a static as long as the base function is static too. It only warns when the static usage differs. That is why nothing is reported at compile time.

Solution
In the call compiler, resolve an unqualified call to a static of a modded class the same way as the qualified form. Only this function changes. The VM, the call descriptor and the bytecode stay as they are.

// RVA 0x2596D0, after FindFunction / overload resolution, unqualified calls only
if (!qualifier && (func->flags & FUNC_STATIC))
{
    Class* owner  = func->owner;                   // class whose method table the lookup used
    Class* newest = FindType(owner->name);         // the lookup `Owner.F()` already does for its qualifier
    if (newest != owner)                           // true only when the class has been modded
    {
        func = FindFunction(newest, name, args);   // same overload resolution as for `Owner.F()`
        cls  = newest;                             // goes into the call descriptor
    }
}

• It reuses an existing rule. The compiler already does this lookup for ClassName.F(). The fix makes F() inside a class mean the same thing, which is what modders write today as a workaround.

• Only modded classes change. For a class that was never modded, FindType(owner->name) == owner, so the generated code is the same as now. Vanilla's own modded classes (PluginDiagMenu, PluginDiagMenuClient) don't override statics.

• Plain inheritance stays as it is. Without modded classes, statics are not virtual either: a base class that calls F() gets its own F, even on a subclass instance that declares override static F(). Vanilla uses override static this way in ParticleSource, PlayerSoundEventHandler, InfectedSoundEventHandler and DynamicMusicPlayer, so the fix leaves this case alone.

• It costs nothing at run time. Everything happens at compile time, and a static call stays a direct slot lookup.

Hello. Will this issue get attention?

thank you very much for response and promise of upcoming fix

xd, nvm

@adiga hello, may i know the reason for your downvote? Is something wrong with described issu?

@l909 Did you pass on the new information?

This problem existed earlier than 1.28, i have encountered this, when i was developing some mod, which baked DOOM textures and maps into scripts file.
So this is NOT new behaviour.

Servers reached to this limits becaus of:
AI, which gives opportunity for unskilled people to make mods, so there are MORE mods
AI UI, which generates HUGE scripting files to give beautiful UI (im not big fan of that)
Simply more people are making good mods now
And yes, obfuscation is obviously somewhere in the list, i saw PBOTools updated their tools because of that issue, their tool was flooding pbo with garbage.

Im posted info within regular scripts
you have very small limit for scripted mods

This is pure architecture flaw, since nobody uses memory arena for dynamic sized data, such as scripts
Memory arena is used for apps, which know how much memory it needs

Your take has no ground on it


If you don't encounter it, it doesn't mean that nobody does.

I dont know i can share them here, search them yourself, there is plenty, and most share this functionality

This is why there is so many new launchers appeared, since situation got worse

This is pretty big problem, which killing fair servers, which dont want to lure people into their p2w server.

He encountered mirrored server
NovaDayz is #1 mirrored server in CIS segment, having tens of thousends mirrors of good servers
This is so basic situation with community server search

Proposed fix

Make the allocator a standard D3D11 dynamic ring: map with NO_OVERWRITE while the write doesn't overlap data queued in this frame, and with DISCARD when it would. Only this function changes (plus the same change in its index-buffer twin, see below). Rotation, buffer size and callers stay as they are.

// slot.used: bytes the write head has advanced in this buffer since the current frame
//            started using it, or since the last DISCARD
void* VCacheRing::Alloc(uint count, uint stride, uint* out)   // out[0] = offset, out[1] = generation
{
    const uint size = count * stride;
    if (size > capacity)
        return nullptr;                                // can never fit; the UI draw path already skips on nullptr

    const uint aligned = AlignUp(slot.offset, stride);
    const bool wrap    = aligned + size > capacity;
    const uint start   = wrap ? 0 : aligned;
    const uint advance = (wrap ? capacity - slot.offset : aligned - slot.offset) + size;   // includes the skipped tail

    MapMode mode = WRITE_NO_OVERWRITE;
    if (slot.used + advance <= capacity) {
        slot.used += advance;                          // nothing queued this frame is touched
    } else {
        mode = WRITE_DISCARD;                          // fresh copy; queued draws keep the old one
        slot.used = size;
    }

    if (mode == WRITE_DISCARD)
        buffer->generation += 2;                       // invalidates every range cached before the discard
    else if (wrap)
        ++buffer->generation;                          // unchanged from current code

    slot.offset = start + size;
    if (out) {
        out[0] = start;
        out[1] = buffer->generation;                   // callers that cache store it, as today
    }
    return buffer->Map(start, size, mode);
}

Why this is the stable option:

• Standard D3D11 pattern. This is the documented pattern for dynamic buffers: append with NO_OVERWRITE, DISCARD when full. VCacheVB is already D3D11_USAGE_DYNAMIC, and the engine's Map already turns mode 4 into D3D11_MAP_WRITE_DISCARD.

• No change for normal frames. Frames that fit in the ring take the same path as today. Only frames that overflow it behave differently: a frame whose total, including the skipped tail, would reach the capacity now gets a DISCARD instead of overwriting its own data. This also covers the other rings that share this allocator.

• Caching rings stay correct. The same allocator serves rings whose clients cache vertex ranges across frames (e.g. RVA 0x1279A0, 0x25C160). They re-validate those ranges with RVA 0x29FFF0: gen == cached.gen || (gen == cached.gen + 1 && cached.offset > head). After a DISCARD the new buffer copy no longer holds those ranges, so the generation is advanced by 2, which fails that check for anything cached before. The current code already DISCARDs without changing the generation once used reaches capacity, so this also closes that latent case.

• The line limit goes away. Above 2 MiB per frame, the cost is one buffer rename per extra 2 MiB, handled by the driver. For example, 30,000 lines ≈ 4.8 MiB → 2 renames. The VCacheVB size becomes a pure performance setting.

• Index-buffer twin. The index allocator at RVA 0x29FA90 (used by RenderMesh2DContext rings, RVA 0x1AFE30 / 0x1B0B20) has the same wrap bookkeeping. It is not on the CanvasWidget path, but it should get the same change.

Hello, thanks for the response.

Video: minimal repro mod in action - https://www.youtube.com/watch?v=TsGt41L9xis

Repro: minimal repro mod - https://drive.google.com/drive/u/3/folders/1dArY1a3CxRk1CNl6o2kSBV7RkuU5zX77

• Minimal mod with source attached, vanilla API only, tested on the DIAG build.

• One full-screen CanvasWidget from a plain layout: ignorepointer 1, size 1 1, halign left, valign top, hexactpos 1, vexactpos 1, hexactsize 0, vexactsize 0.

• Every frame: Clear(), then N × DrawLine. Each line is horizontal, 4 px long, width 4, opaque red (a 4×4 square), on a 200-column grid.

• Up/Down arrows change N by 100. Backspace sets N to 0.

• Result: from 0 to 11,900 lines there is no corruption. At about 12,000 lines corruption starts. The exact number depends on what other UI is on screen.

Requested info

• Client build: 1.29.0.163709, Steam Stable (build ID 24689949)

• GPU: NVIDIA GeForce RTX 4090 (Gigabyte WINDFORCE)

• Graphics settings: DayZ.cfg and graphics.DayZProfile are included with the mod source

Root cause
To help you out with solution, here's details on why its happening:

CanvasWidget lines are drawn through the shared immediate-mode dynamic vertex buffer "VCacheVB", 2 MiB per buffer. When a frame needs more than that, the ring allocator wraps to offset 0. Because of a bookkeeping error, it keeps mapping with D3D11_MAP_WRITE_NO_OVERWRITE over the start of the same frame's data, which the GPU hasn't consumed yet. As a result, the vertices drawn first in the frame get overwritten.

How a line reaches the GPU:

1. CanvasWidget.DrawLine (RVA 0x40AC20 → 0x3FA9A0) appends two points {x, y, width, color} (16 B each) to a per-widget array at +0xF0. There is no limit at this stage. Clear() only zeroes the count at +0xFC. Lines stay until Clear() and are re-submitted every frame.

2. On draw, each line becomes a non-indexed quad: 6 vertices × 28 B = 168 B. Vertices are staged 2,400 at a time (cmp 960h, RVA 0x3B75D0), so each batch of 400 lines is one draw. For each batch, space is allocated in VCacheVB, the vertices are copied in, and then ID3D11DeviceContext::Draw(count, offset / stride) is called.

3. VCacheVB is created at renderer init with 0x200000 bytes per buffer (RVA 0x283C17), and there are [renderer+0x1638] + 1 buffers. They are rotated by RVA 0x295E70, which calls the ring advance at RVA 0x29F9D0 with resetOffset = false.

Capacity: 2,097,152 / 168 = 12,483 lines per frame, minus everything else drawn through VCacheVB in that frame (vanilla widgets, text). This matches the onset at about 12,000 lines.

The bug is in the allocator, RVA 0x29FB90:

aligned    = align_up(slot.offset, stride)
free       = capacity - aligned
slot.used += size + (aligned - slot.offset)          // on wrap the skipped tail (capacity - aligned) is NOT added
mode       = slot.used < capacity ? WRITE_NO_OVERWRITE : WRITE_DISCARD
if (size <= free) slot.offset = aligned + size;
else            { slot.offset = size; aligned = 0; } // wrap to 0
Map(buffer, aligned, size, mode)

1. The offset isn't reset on rotation, so a frame starts writing at some offset o.

2. On wrap, the skipped tail T = capacity − aligned isn't added to used. T is smaller than the allocation that caused the wrap: at most 67,200 B (400 lines) for a canvas batch.

3. After the wrap, maps stay NO_OVERWRITE until used reaches capacity. That happens at o + T instead of at o.

4. So the range [o, o + T) is overwritten. It holds the first vertices of this frame, whose draws are still queued. Only after that does the mode switch to DISCARD.

This explains the symptoms:

• Only the geometry drawn first breaks.

• It flickers, because the result depends on whether the GPU has already read that range.

• Splitting lines across several canvases doesn't help, because everything shares one ring.

@l909 Hello, 100 upvotes on this one, i think all this people deserve concrete plan for this change, since this become #1 problem for complex servers.
I gave as i think the propper solution earlier in the thread.

Hope for you😶‍🌫

ok, i think 91 votes in 2 days without a mention in statistics list is not fine

ok, we'll see

In such game, as dayz, there can't be something like tight limit to mod amount. It must be limited by avalible RAM of given machine.

Game uses static memory arena. Because of that we have strict limits on modding.

Proposed design according to engine constraints

Keep IStaticBuffer as a bump allocator over one contiguous range. Back it with a large address space reservation and commit pages as cur advances.

// Init: was malloc(size) + memset(size)
bool IStaticBuffer::Init(uint32 reserve)
{
    m_Base = (uint8*)VirtualAlloc(nullptr, reserve, MEM_RESERVE, PAGE_NOACCESS);
    if (!m_Base) return false;
    m_Cur = m_Committed = m_Base;
    m_End = m_Base + reserve;
    return true;
}

void* IStaticBuffer::Alloc(uint32 n)
{
    ScopedLock lock(m_Locked ? &m_Cs : nullptr);
    uint8* p   = AlignUp(m_Cur, 8);
    uint8* end = p + n;
    if (end > m_End)
        Fatal("Script module '%s' ran out of static memory (%u of %u kB reserved)", ...);
    if (end > m_Committed)
    {
        uint8* to = Min(AlignUp(end, kCommitChunk), m_End);   // kCommitChunk: 1-4 MiB
        if (!VirtualAlloc(m_Committed, to - m_Committed, MEM_COMMIT, PAGE_READWRITE))
            Fatal("Out of memory while growing script static memory");
        m_Committed = to;                                      // new pages are zero
    }
    m_Cur = end;
    return p;
}

• Sizes. On 64-bit PC, reserve 1 GiB for each script module and for the engine's global buffer. Reserved address space costs no RAM, and x64 user space is 128 TiB. The limit becomes the reservation, which modded servers will not reach, and memory use becomes what the scripts actually need.

@onno what do you think?

So, here what im talking about
I have issue, which is got upvoted 30+ times in one day.

Top 5 active issues doesnt reflect "ACTIVITY" at all meanings, so i think this is a problem

• #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.

@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.
  

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."

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"

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

l909 Hello, this need attention

l909 mind giving us feedback on that, as well for https://report.bistudio.com/issues/DZEXP-134

nah, its problem related to FindFile beeing broken, if it was removed, devs like to break modding lives.

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 dont think this is related to post, consider to stop offtop talks.

l909 we need an update on this, pls.
Are devs able to fix one missing binary flag? (https://report.bistudio.com/issues/DZG-502?commentId=6ab6e2df41140b7f57a3be7f here my research)

l909 we need an update on this, pls.

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

l909 we need an update on this, pls.

so maybe "Top 5 voted issues" need to be removed, so it clears to "Top 5 active issues"
For me activity windows is very small, it feels like if you posted, it will be here in couple days with couple of upvotes and comments, and then it washed by other
No matter how many upvotes youd get in that period and so, no reason to keep the conversation up, while the problem exists.

So maybe unsolved problem, needs to be uptoped on activity, since ASSIGNED status doesnt mean anything at all, since devs can work on this tasks for years

l909 can devs adress this is issue and increase couple constants for their beloved modding community?

Server owners already hitting limits, so this is not FUTURE problem devs, this is NOW problem

would be great