⛏️ Dig, explore, loot, and survive in a vast underground world. Discover hidden treasures, special caverns, dangerous enemies, and depth-based progression from Easy to Nightmare. Experience reworked digging, balanced ore and oil progression, 8-level resource scaling, optional challenge modes, Train Interiors, research upgrades, and a balanced coin market. Enter the optional Dark Zones, where you have only 30 seconds to place lights before the darkness becomes dangerous.
Mods introducing new content into the game.
Changes to enemies or entirely new enemies to deal with.
Map generation and terrain modification.
New Ores and resources as well as machines.
Hello, I'm the author of the Factorio mod "card-tech-draft." It redesigns the entire technology-unlocking flow around a card-drafting mechanic: at the start of the game all technologies are hidden, and players unlock "tech packs" by accumulating progress through mining, drafting one technology at a time from the offered options.
While testing compatibility with The Cave, I found a structural conflict. Your mod has a startup setting, "Everything On Nauvis," which — when enabled — automatically completes the four planet-discovery technologies (Vulcanus, Gleba, Fulgora, Aquilo) for every force. This setting makes complete sense for players who want to focus entirely on the home planet without building a rocket to travel elsewhere — but that's exactly why it conflicts with card-tech-draft's core rule that every technology must be unlocked through the draft. These four technologies get force-marked as researched, bypassing my mod's drafting flow entirely, so they remain permanently stuck on the player's tech tree with no normal way to remove them.
In other words, a player who wants to use both mods together, while keeping the "no rocket, all-in on the home planet" playstyle that The Cave itself offers, currently has no way to make these four technologies respect my mod's drafting rules too.
Before finding this more proper solution, I had already directly modified files inside your mod as a temporary workaround. I'm sorry for that. Transparency is a principle I hold myself to, so I felt I needed to tell you this directly. Specifically: I edited the sync_force function in scripts/everything_on_nauvis_progression.lua, adding one line at the top of the function — if script.active_mods["card-tech-draft"] then return end — so that whenever card-tech-draft is also active, this function returns immediately and does nothing, leaving those four technologies entirely under my mod's own drafting rules. No other line was changed. Players who don't run card-tech-draft are completely unaffected. I've tested this and confirmed it resolves the compatibility issue I described above. This modified copy exists only in my local testing environment — it has not been uploaded anywhere or distributed to anyone.
I have no intention of adding to The Cave's development workload or slowing down your roadmap — this is not urgent on my end — but I would genuinely like to find a way for the two mods to work together. I wanted to ask you a couple of things:
Would you be interested in, or have the time for, exposing a compatibility hook — for example, a remote interface that other mods could query or use to intervene in the "Everything On Nauvis" logic — so mods like mine can handle these four technologies correctly?
If you don't have time to work on this, would you be willing to let me write an independent compatibility patch myself (without modifying your source files, using officially supported approaches like data-final-fixes or a remote interface), and show that development process in a livestream?
A bit of background on me: I'm a farmer with no programming or foreign-language ability of my own — this mod has been developed and maintained entirely with AI assistance from start to finish. If you'd rather I not handle this myself — whether by writing a patch or by sharing the process in a stream — I will fully respect your wishes and take no further action.
Thank you for reading, and thank you for making such a great mod.
Hello Lobelia,
Thank you for contacting me and for being transparent about your private local testing changes.
I have now reviewed the source code of card-tech-draft 0.2.24. At this stage, I am not able to add official compatibility for it to The Cave because your mod still has several fundamental issues of its own. These problems cannot safely be corrected from The Cave’s side without changing or damaging systems that were deliberately designed that way.
Before I can consider integrating or officially supporting card-tech-draft, your mod first needs to become stable and resolve the following issues.
Your mod sets every technology to enabled = false, and get_available_pool then accepts every technology that is not enabled.
However, the pool does not exclude technologies that another mod has deliberately marked as hidden.
The Cave intentionally disables and hides certain technologies as part of its gameplay design. For example:
night-vision-equipment is deliberately removed because Night Vision bypasses The Cave’s darkness gameplay.fluid-wagon is deliberately disabled and hidden when Train Interiors is enabled because that progression is managed separately and the remaining technology would be empty or misleading.These are intentional The Cave design decisions, not compatibility bugs in The Cave. I cannot re-enable these technologies or redesign my progression system to accommodate your card pool.
Your mod must exclude genuinely hidden technology prototypes from its draft system. This should preferably be a general solution because many other mods also use hidden technologies for internal, obsolete or deliberately unavailable systems.
Your manual-mining handler immediately returns unless the mined entity is a resource:
if entity.type ~= "resource" then return end
The Cave’s main gameplay is based on mining cave rocks and walls. These are not resource entities, so a player can spend a long time digging tunnels without gaining any Frog Points. Only directly mining exposed ore or using Mining Drills currently contributes.
The Cave cannot convert its rocks and cave walls into resource entities without breaking cave generation, collision, mining, rooms and several other systems.
If tunnel digging is supposed to contribute to your draft progression, support for The Cave’s mineable cave entities must be implemented inside card-tech-draft.
Your mod repeatedly performs global scans:
The Cave can create multiple Train Interior, Mineral Cave, Uranium Cave, Fortified Vault and Underground Village surfaces. Repeatedly scanning every entity across every surface may become expensive on a large multiplayer save.
This needs to be profiled and optimised from your side. The Cave cannot remove or redesign its multi-surface systems to compensate for global scanning performed by another mod.
The original conflict involves The Cave marking four planet-discovery technologies as researched. However, changing an already researched technology back to unresearched can reverse its effects and potentially damage recipes, progression and existing saves.
The Cave cannot safely erase completed research globally for another mod.
If card-tech-draft is added to an existing save, your mod needs a safe migration strategy, or it must clearly state that compatibility requires a new game. Existing-save handling is part of your progression system and must be addressed from your side.
Your own code and settings describe multiple systems as experimental or not yet tested, including:
These systems need proper testing before I can treat the mod as stable enough for official compatibility.
Testing should include:
Required order of work
The current issues originate inside card-tech-draft and cannot be safely solved by changing The Cave.
Please first:
card-tech-draft.Once your mod is stable and these issues have been resolved, you may contact me again. At that point, I can review the stable version and decide what official compatibility work is appropriate for The Cave.
Permission and The Cave source-code boundaries
You have my permission to:
card-tech-draft source code.You do not have permission to:
everything_on_nauvis_progression.lua.Your earlier private local modification is not a problem because it was disclosed and was not distributed. However, all future published work must remain entirely within your own mod or an independent add-on that does not copy, modify or replace The Cave’s files.
Please stabilise card-tech-draft first. After that, I will be willing to review compatibility again.
Thank you for understanding.
Progress update on card-tech-draft -- compatibility readiness
Since your last review, I've worked through the six items you raised. Rather than waiting until every box is checked, I want to share an honest status update now.
============================================================
DONE (with test evidence):
[1] Hidden-technology exclusion
Added tech.prototype.hidden check to the draft pool filter. Verified via
debug command that The Cave's fluid-wagon is correctly excluded while
remaining enabled/researched in the background.
[2] Manual-mining contribution
Now recognizes The Cave's diggy-rock and diggy-rubble entities via an
extensible allow-list. The list is mod-agnostic by design, not hardcoded
to your mod specifically.
[3] Performance (UPS)
The four per-tick full-surface scans (mining drills, waste-heat boilers,
waste-heat exchangers) have been replaced with an event-driven entity
cache.
Stress test results (same save, ~1,150 mining drills + waste-heat entities
in active interaction):
- Steady-state: < 0.04ms/tick average for card-tech-draft
(well below The Cave's own reported cost on the same save)
- Build spikes: Up to ~10ms when hundreds of entities are constructed
in the same tick (e.g. via console), but steady-state returns
immediately after
This is now below The Cave's own performance footprint in normal play.
[4] Multi-surface compatibility
Verified that Train Interiors' fluid-wagon technology is correctly hidden
from the draft pool, and that the entity cache correctly tracks entities
across Train Interiors' additional surface without issues.
Not yet tested: multiple concurrent Train Interior surfaces (i.e. several
trains active at once). The infrastructure should handle this the same
way it handles other multi-surface cases, but I haven't specifically
forced that scenario.
============================================================
ANALYZED (not yet tested on a real save):
[5] Existing-save research-state safety
I've confirmed via the Factorio API docs that my hiding mechanism only
ever touches enabled, never researched. In theory, this means it cannot
reverse anything The Cave has already unlocked via sync_force().
I have not yet run this against an actual save where those four
planet-discovery techs were already force-researched.
============================================================
NOT YET TESTED (being upfront):
[6a] Multiplayer & multiple forces
Real-player scenarios with joins/leaves mid-draft. I don't have an
active testing community to draw on for this, so this remains untested
with actual second players.
[6b] Space Age + The Cave planet-discovery progression
Not yet tested on a real save with those specific conditions.
============================================================
I'd rather give this honest report now than wait indefinitely for a "complete"
state I may not be able to reach alone.
This covers everything I can reasonably test in isolation. The remaining gaps
-- multiplayer with real players, and the Space Age + The Cave planet-discovery
interaction -- are areas where I'd benefit from your insight on whether they're
actual blockers or acceptable to defer until after an initial compatibility
pass.
Let me know what you think, and whether there's a specific threshold you'd want
to see crossed before we revisit the compatibility conversation.
Thank you for the detailed and honest progress report. I genuinely appreciate the amount of work you have put into addressing the points from the previous review, as well as the care you have taken to distinguish between what has been fully tested, what has only been verified through code and documentation, and what still remains untested.
The improvements you described—particularly the hidden-technology filtering, extensible manual-mining support, event-driven entity cache, and multi-surface handling—sound like substantial and well-considered changes. Replacing the repeated full-surface scans with an event-driven cache is especially valuable, and the performance results you reported are very encouraging.
From my side, you are welcome to continue developing "card-tech-draft" in whatever way you believe is best. You understand the architecture of your own mod, your available testing resources, and the trade-offs involved better than anyone else. You do not need to wait for every possible scenario to be tested before continuing. Whether you want to publish an initial compatibility pass, label it experimental, defer some tests until users can provide real-world feedback, or continue testing privately first is entirely your decision.
The remaining gaps you identified—real multiplayer testing, multiple forces, multiple concurrent Train Interior surfaces, and Space Age planet-discovery progression—are worth keeping documented, but I understand that some of these scenarios are difficult to reproduce without an active testing group. As long as the current limitations are communicated honestly, I am comfortable with you deciding how and when to proceed.
There is only one important boundary I need to make clear: please do not directly modify, patch, bundle, or redistribute altered versions of The Cave’s source code. The Cave is currently in a very active stage of development, and I am personally working through significant changes and improvements to its code. Direct external modifications could easily create version conflicts, regressions, duplicated fixes, or compatibility behaviour that becomes outdated as The Cave continues to evolve.
Any compatibility logic required for "card-tech-draft" should therefore remain entirely on the "card-tech-draft" side, using public Factorio APIs, optional mod detection, prototype checks, remote interfaces where available, or other non-invasive compatibility methods. You are otherwise completely free to structure and develop your own mod as you see fit.
If you discover a situation where you believe a change inside The Cave itself is genuinely necessary, please send me the exact issue, reproduction conditions, expected behaviour, and—if helpful—the interface or information your mod needs. I will review it and, where appropriate, implement the required change on The Cave’s side myself. This will allow us to preserve one authoritative codebase and prevent either mod from depending on private or unstable internal implementation details.
If "card-tech-draft" reaches a stable state, performs well in real gameplay, and proves to have reliable compatibility with The Cave, I would also be open to adding it to The Cave’s list of optional mods. That would allow players who are interested in its technology-drafting system to choose and enable it for themselves, while keeping it completely optional for everyone else. I would prefer to make that decision after we have seen satisfactory results from practical testing, particularly in the remaining multiplayer and Space Age scenarios.
So, in short: please continue in whatever direction you think is appropriate for your mod. I trust your judgment regarding the remaining tests and release threshold. Just keep all compatibility changes on your side and leave The Cave’s source code untouched while I continue working on it.
Thank you again for taking the earlier feedback seriously and for providing such a transparent technical update. The progress you have made is appreciated, and if the final result is stable and works well with The Cave, I will be happy to consider giving players an official optional way to use it alongside the mod.
Hi behroozzx,
Per your last message — you offered to review a concrete issue,
reproduction steps, expected behavior, and the interface my mod would
need, so I want to formalize the one remaining blocker rather than ask
for general compatibility again.
ISSUE
scripts/everything_on_nauvis_progression.lua, progression.sync_force():
when the-cave-everything-on-nauvis is "enabled" (default) and Space Age
is active, this function force-sets researched = true on all four
planet-discovery-* technologies for every force, on on_init,
on_configuration_changed, on_force_created, on_player_created, and
on_player_changed_force.
card-tech-draft's entire design assumes every technology starts
enabled = false and is only ever unlocked through the draft. When these
four technologies are marked researched outside that flow, their
dependent later-game technologies also become immediately eligible for
the draft pool, since my pool logic only checks prerequisite
.researched state, not how a technology became researched. The
practical effect: a fresh game with both mods on default settings can
surface Vulcanus/Gleba/Fulgora/Aquilo-tier tech in the very first draft
offers, instead of only after the player has progressed through the
normal early tech pool.
REPRODUCTION
EXPECTED BEHAVIOR
I'm not asking The Cave to un-research anything — you already flagged
that reversing researched state on an existing save is unsafe, and I
agree that's not a direction I want either. What I'd actually need is a
way to know, before sync_force runs, that a force should be left
alone for these four technologies, so card-tech-draft can put them back
into its own normal draft pool from the start instead of racing to undo
your effect afterward.
REQUESTED INTERFACE (proposal, not a requirement — happy to adapt to
whatever shape fits your architecture best)
A small opt-out remote interface would be enough, e.g.:
remote.add_interface("the-cave-everything-on-nauvis", {
exclude_force = function(force_name) ... end,
is_excluded = function(force_name) ... end,
})
sync_force() would just skip a force that's been marked excluded. This
keeps all logic and state on The Cave's side, requires no change to
existing-save research, and costs one early lookup per force instead of
a scan.
If you'd rather not add a new interface right now, an even smaller
option would work too: a documented remote call or global table that
only reports whether the setting is currently active plus the four
technology names, so I can register my own on_force_created handler to
run before sync_force reads them. Either shape is fine on my side —
I just don't have a way to intervene at all right now.
ON GENERALIZING THIS
Since this is a general "another mod wants to own tech-unlock ordering"
problem, not something specific to card-tech-draft, it's probably worth
designing the hook so any mod can register itself (by mod name or a
generic exclude_force(force_name, reason) call) rather than hardcoding
around my mod specifically. I don't know of another published mod doing
full tech-hiding/drafting the way mine does, so the odds of this
mattering to a second mod are low — but if the interface is generic
from the start, it costs little extra now and avoids a second
one-off request later if that ever changes.
This isn't urgent on my end and I'm not asking you to prioritize it
above your own roadmap — I just wanted to give you the concrete
issue you asked for so you have what you need to decide whether and
how to address it. The local, disclosed-only, undistributed workaround
I mentioned previously remains exactly that: local and undistributed.
If card-tech-draft ever earns a place on The Cave's optional mod list, I'll consider that an honor in itself — thank you for even leaving that door open, and thank you for everything.
As with all my communication and technical work on this project, this
message was drafted and edited with AI assistance. I've reviewed it for
accuracy, but if anything here doesn't match your understanding of The
Cave's code, please treat my technical claims as needing your own
verification.
Lobelia9
Hi Lobelia9,
Thank you for taking the time to document the issue so clearly. I have reviewed the proposed interface and the role of "progression.sync_force()" more carefully.
Unfortunately, I cannot safely add the requested force-exclusion mechanism to The Cave at this stage.
The four "planet-discovery-*" technologies are not being researched accidentally. When “Everything on Nauvis” is enabled, researching them is an intentional and necessary part of The Cave’s progression system. Other parts of the mod expect that synchronization to have taken place.
Allowing another mod to exclude a force from "sync_force()" could therefore leave The Cave in a partially synchronized state. The risk would not be limited to the initial draft offers. It could affect:
Because "sync_force()" currently runs from several important lifecycle events, adding an external opt-out would create another persistent state that every related system would need to understand and preserve. A mistake or an unexpected event order could leave a save in a state where The Cave believes Everything on Nauvis is active, while the technologies required for that mode were deliberately skipped.
That is too much risk for The Cave’s established functionality. The Cave is already running on a public server and has an active player base. I cannot compromise or restructure one of its core progression systems to accommodate a separate, early-stage mod that is still being developed and evaluated.
The underlying compatibility problem also comes from an assumption inside "card-tech-draft": its pool treats every researched prerequisite as if that prerequisite had been earned through the draft. In a modded Factorio game, technologies can legitimately be researched by scripts for reasons unrelated to normal player progression. The Cave is one example, but other mods may do the same.
For that reason, I believe the safer and more general solution belongs on the "card-tech-draft" side. Its eligibility logic should distinguish technologies drafted through its own system from technologies granted externally by scripts. Possible approaches include maintaining an internal record of drafted technologies, excluding externally granted progression markers from eligibility calculations, or adding a specific compatibility rule when The Cave’s Everything on Nauvis setting is active.
This would protect your draft progression without disabling or bypassing required behavior inside The Cave. It would also make "card-tech-draft" more robust when used with other mods that grant technologies through scripts.
Therefore, I will not add the proposed "exclude_force()" interface or change "sync_force()" at this time. This is not a rejection of future compatibility, and I appreciate the professional way you presented the issue. If "card-tech-draft" becomes stable and is eventually considered for The Cave’s optional-mod list, we can revisit compatibility using a separate test build and a solution that does not allow The Cave’s core progression to be bypassed.
For now, however, protecting the stability of The Cave must take priority, and the required adjustment needs to be implemented within "card-tech-draft".
Thank you for understanding.
Hi behroozzx,
Thank you for clarifying why an exclude_force() hook would be unsafe for The Cave.
I have taken your latest suggestion seriously and changed the compatibility approach on the card-tech-draft side, rather than trying to make The Cave bypass its own progression logic.
The current approach is based on a simple principle:
The Cave is allowed to research the four planet-discovery technologies when "Everything On Nauvis" requires it. card-tech-draft does not try to undo that state. Instead, card-tech-draft distinguishes between technologies granted through its own draft system and technologies externally granted for legitimate mod-specific reasons.
Changes made so far:
The draft-pool logic no longer treats a technology's vanilla enabled/researched state as proof that the prerequisite was obtained through card-tech-draft.
card-tech-draft now maintains its own record of technologies granted through its draft flow, including normal pack-opening results and relevant mystery-pack outcomes.
A prerequisite is considered satisfied by the draft system when:
- the technology is recorded as granted by card-tech-draft; or
- the technology is explicitly recognized as an external progression marker.
The Cave's four planet-discovery technologies are currently included in the explicit compatibility list.
This means The Cave can continue to synchronize those four technologies normally, while card-tech-draft does not automatically treat every downstream technology as unlocked merely because some other script changed a technology's researched/enabled state.
I deliberately did not use the earlier time-based approach that treated an externally enabled technology as valid after a delay. That approach was too speculative and could silently produce incorrect progression. The current whitelist is narrower and easier to reason about.
I also added a debug command, /draft-external-tech-status, to make the distinction visible during testing. It reports technologies that are recognized as drafted, technologies accepted through the external whitelist, and enabled technologies that match neither category.
For existing saves, the first construction of this internal record is grandfathered from the technology state already present at that moment. I chose this because retroactively deciding that a player's existing progression was invalid would be much more disruptive than the original compatibility problem.
Following your first review, the draft pool was changed to explicitly reject genuinely hidden technology prototypes, instead of assuming that every disabled technology belongs to the draft system.
This was tested against The Cave's hidden technologies, including the Train Interiors / fluid-wagon case.
The intent is now:
hidden means hidden, regardless of which mod caused it.
This avoids reintroducing technologies that another mod intentionally removed from normal progression.
Manual mining previously only accepted entities of type "resource".
That was insufficient for The Cave because its primary digging gameplay uses cave rocks and rubble rather than normal resource entities.
I added an extensible recognition path for The Cave's diggy-rock and diggy-rubble entities so that this activity can contribute to card-tech-draft progression without requiring The Cave to change its entity architecture.
The compatibility logic is implemented entirely on my side.
I also replaced the previous repeated full-surface scans with event-driven entity caches.
The earlier implementation repeatedly searched surfaces for mining drills and waste-heat entities. This was especially undesirable for a mod such as The Cave, which can create multiple additional surfaces.
The current implementation tracks relevant entities when they are created, removed, or otherwise changed, and performs the heavier aggregate work at controlled intervals.
In my stress test using a save containing roughly 1,150 mining-drill / waste-heat related entities, the steady-state cost of card-tech-draft was below 0.08 ms/tick.
There can still be construction spikes when very large numbers of entities are created in the same tick, but the normal steady-state cost returns immediately afterward.
I consider this a practical optimization rather than a universal performance guarantee. Large multiplayer factories and unusual multi-surface setups still deserve real-world testing.
I also investigated the existing-save problem more carefully.
The important distinction is that card-tech-draft's hiding mechanism operates through technology.enabled rather than reversing technology.researched.
The migration logic therefore does not attempt to un-research technologies or undo their effects.
For a save that is installing card-tech-draft for the first time, a one-time migration hides the technology tree and places the technologies under the draft system while preserving existing researched effects.
A separate /draft-reveal-all command is available as an escape hatch before removing the mod, restoring hidden technologies to an ordinary researchable state.
I understand that this is still a significant save-migration behavior, so I cannot guarantee that every possible mod combination has been fully validated.
During the same development period I also worked on a separate optional, non-invasive compatibility path for the thermal-debt mod. The two mods do not share internal state; they communicate through remote interfaces where available, and each falls back to its own independent behavior when the other is missing.
This resulted in several real bugs being found and corrected through testing, including:
- an aggregate heat-drain budget being applied repeatedly instead of being distributed across its intended interval;
- stale heat values allowing a calculated drain budget to become much larger than the currently available heat;
- whole-factory idle-ratio scaling being inappropriate for the thermal-debt interpretation;
- heatsink coverage being incorrectly restricted to working mining drills—now corrected to cover all working buildings when thermal-debt is present;
- duplicate remote-interface queries in the same polling interval;
- a whole-factory progress/heat source being based on "working" state rather than measured production;
- several intermediate heat-decay formula mistakes that were corrected by returning to the documented original design rather than continuing to tune against an uncertain target.
The key property of this integration is that either mod can run fully alone. The compatibility layer is additive: when both are present, card-tech-draft gains access to thermal-debt's whole-factory thermal data; when thermal-debt is absent, card-tech-draft reverts to its original miner-focused behavior without any loss of functionality. No state is shared between the two mods, and disabling the compatibility mode does not require any recovery action—it simply stops being used.
These changes are not intended to be presented as proof that card-tech-draft is finished. If anything, the debugging process has reinforced for me that interactions between independently simulated progression systems need to be treated conservatively.
Current position
I believe the original compatibility issue you identified has now been moved to the side where it belongs.
The Cave does not need to suppress sync_force(), undo research, or maintain special state for card-tech-draft.
Instead:
- The Cave continues to own its own progression.
- card-tech-draft owns its own draft history.
- externally granted technologies are not automatically interpreted as draft progression.
- known external progression markers can be recognized explicitly.
- hidden technologies remain excluded from the draft pool.
- The Cave-specific digging behavior is handled by card-tech-draft.
- compatibility code remains outside The Cave's source tree.
There are still things I have not been able to validate properly, especially real multiplayer testing with multiple forces and the complete Space Age + The Cave progression flow on a long-running save.
I would therefore appreciate your technical guidance on the remaining boundary cases.
In particular, if you see a flaw in the current "own draft record + explicit external progression whitelist" model, I would rather correct the model than add another workaround around The Cave.
I am also willing to accept the risk of releasing an experimental compatibility implementation before I can reproduce every multiplayer and Space Age scenario myself. I will document what has and has not been tested rather than presenting unverified compatibility as guaranteed.
A small side note, more as context than as a request: the same testing period also produced a separate, standalone thermal-overhaul mod (thermal-debt) that started as a design exercise alongside this compatibility work. card-tech-draft already lists it as an optional dependency (? thermal-debt), so the two mods can coexist without forcing anyone to install both, but they do not share state or require each other to function. Some of the debugging habits I developed there — especially around event-driven caching and batch-scheduled heat calculations — carried over into the changes described above. I mention it only because it is the other major thing I have been working on recently, and because the two mods' development timelines overlapped more than I expected when I started this compatibility pass.
AI-assisted development
I want to be transparent about my development process: all code, debugging, documentation, and these replies have been produced with AI assistance. I am not a professional programmer. I review, test, and validate the generated work against the game's observed behavior and API documentation before
Hi Lobelia9,
Thank you for the detailed update. Handling the compatibility entirely within card-tech-draft while leaving The Cave’s progression system untouched is the appropriate direction.
However, I need to set a clear boundary: I cannot provide further technical review, edge-case analysis, testing, or validation for card-tech-draft. I am currently focused on developing and stabilizing The Cave, and I cannot take responsibility for the implementation or compatibility of another mod.
Please continue developing and testing it independently. All whitelist logic, save migration, multiplayer and multi-force behavior, Space Age compatibility, performance testing, and future maintenance must remain entirely on the card-tech-draft side. The Cave will not add hooks, special state, exceptions, or code changes for this integration.
You are welcome to release the compatibility as experimental and clearly document what has and has not been tested. However, please do not describe it as officially tested, approved, supported, or guaranteed by The Cave.
There is no need to send me further development reports about card-tech-draft or thermal-debt. If card-tech-draft eventually becomes stable, well-tested, and receives positive real-world feedback, I may consider listing it as an optional mod for The Cave in the future. This is only a possibility, not a current commitment.
From my side, this compatibility discussion is now closed. I appreciate the work you have done and wish you the best with your project.
Best regards,