Duping cd disc / hdds having double size after commit "patch copying special "Data" attribute (#439)"

[AlexALX]

Describe the bug

4295fd95ccebe82320770d7aa04b7786003498c5

This change made issue with bigger dupe files.

I have wire CD Disc with dupe size of 918 KB, before this commit, it do properly saving without extra data.

Now after this commit it become into 1830 KB when resave exact same disc. So size are DOUBLED without any reason for that. The disc itself hold ~772 KB of effective data, so final dupe with 1830 kb makes no sense.

i'm not sure if this affect ANY dupe and making it DOUBLE size or not, but definitely issue with CD discs!

How to reproduce the bug

You can test this using any of this dupes: https://github.com/AlexALX/wiremod_e2_os/tree/master/advdupe2/alx_pc/discs

1. Open and paste dupe disc in gmod.
2. Copy it again using advdupe2 tool.
3. Save it.
4. Size will be doubled.

[AlexALX]

Reverting this change fixes issue, size of advdupe become to normal on latest advdupe2 version.

[AlexALX]

After manual debug and investigation with chatgpt, i got next (chatgpt generated):

After investigating this further, I think the root issue is architectural rather than a simple bug.

The built-in Garry's Mod duplicator intentionally saves almost the entire Entity:GetTable():

-- this is terrible behaviour - but it's what we've always done.
table.Merge(data, ent:GetTable())

and later restores it with:

table.Merge(Entity:GetTable(), data)

This allows addons using duplicator.RegisterEntityClass(..., "Data") together with duplicator.GenericDuplicatorFunction to automatically preserve arbitrary Lua fields stored directly on the entity.

AdvDupe2 was originally designed differently. Instead of serializing the runtime entity table, it builds its own filtered, serialization-friendly structure (PhysicsObjects, EntityMods, DT, etc.). This keeps duplication files relatively compact and avoids storing large runtime-only tables.

PR #439 changed this behavior by copying almost the entire Entity:GetTable() into AdvDupe2's serialized entity table to match the behavior of the built-in duplicator. This fixes compatibility with addons relying on the built-in "Data" semantics, but it also means runtime data is now written directly into .dupe files.

In practice this can dramatically increase file size. For example, Wiremod entities expose large runtime tables (Inputs, Outputs, caches, etc.) through GetTable(). These tables are now serialized as well, even though AdvDupe2 already stores the data actually required for reconstruction separately. In my case, CD Disk duplications increased from approximately 900 KB to 1.8 MB solely because of this change.

So there appears to be a tradeoff:

• Before PR Fix copying special "Data" attribute #439: compact AdvDupe2 serialization, but incomplete compatibility with addons expecting built-in duplicator behavior.
• After PR Fix copying special "Data" attribute #439: much better compatibility with the built-in duplicator API, but significantly larger duplication files due to serialization of runtime entity state.

This doesn't necessarily mean the PR is wrong—it fixes a real compatibility issue—but it effectively changes AdvDupe2's serialization model to behave much more like the built-in duplicator. It may be worth discussing whether this compatibility behavior should be optional, or whether runtime-only fields could be filtered before writing the duplication to disk while still preserving compatibility during the copy/paste process.

[AlexALX]

After some thinking i see few ways to "fix" issue:

1. make it as if gtSetupTable.SPECIAL[Key] and not Ent.EntityMods then, so if addon doesn't have EntityMods this means it want to store whole table, but this still not ideal - addon might want modify something, but still save all. This will work with TARDIS addon since it has just a:

duplicator.RegisterEntityClass("gmod_tardis", function(ply, data)
    local ent = duplicator.GenericDuplicatorFunction(ply, data)
    ent:SetCreator(ply)
    ent:Initialize()

    return ent
end, "Data")

This fixes issue but with note above.

2. add OnEntityCopyTableFinish to gmod_wire_cd_disk and gmod_wire_dhdd, or any other device what might have huge data inside.

for example gmod_wire_cd_disk with:

function ENT:OnEntityCopyTableFinish(dupedata)
    if BaseClass.OnEntityCopyTableFinish then
        BaseClass.OnEntityCopyTableFinish(self, dupedata)
    end
    dupedata.DiskMemory = nil
end

Also fixes issue, at least large DiskMemory isn't duplicated - no double size in this case, but still having extra "40 kb" of data to each dupe because of garbage it stores.

3. Add some flag like "RequireFullDataCopy" (or similar) with true by default, but set for all wiremod entities as false by default, other addons like my Stargate Carter Addon Pack also can make support to it and not store all garbage.

---

Want to know what other people think about this issue.

[AlexALX]

Got another idea, maybe add an checkbox "Requre Full Copy (bigger E2)" or something ON by default in advdupe2 stool panel? so then i can controll myself i want it or not. and write good tooltip explain for what.