Question regarding CorruptionAPI and AetherAPI

[pirate0815]

From my understanding of the source code the two APIs currently use separate implementations for storing aspect amounts per chunk in the world.
The corruption code uses ChunkAspectStorage, while AetherAPI uses AetherWorldState.
While these two persistent storage implementations have some unique functionality (dead zones <=> corrupted chunks) they provide their own independent way of storing aspect per chunk, booth initializing from the Aspects in a chunk using the BiomeAspectRegistry.
With the vessel from thaumaturge implementing its corruption by modifying the BiomeAspectRegistry, instead of using ChunkAspectStorage or AetherWorldState.

Could you please explain to me how those two independent aspects systems are intended to come together, as i currently do not really understand it.

[0vergrown]

Sorry for the late reply, I didn't get a notification for this one. Both systems start from the same foundation. They use the BiomeAspectRegistry to get the initial aspect amounts for each biome. This means both systems see the same starting point for what aspects should be in each chunk.

The corruption system tracks changes over time. It watches how much Vitium builds up in biomes and when Vitium becomes the dominant aspect, it marks chunks as corrupted. This system stores its tracking data separately to remember what has changed.

The Aether system represents the available magical energy (or mana). It takes the biome aspects and converts them into a pool of energy that spells can draw from. When this energy gets used up, it can create "Dead Zones" where magic no longer works.

The vessel connects them by modifying the BiomeAspectRegistry directly. When you use the vessel to create Vitium, it changes the base aspect amounts that both systems rely on. So, the vessel actions affect both corruption tracking and available magical energy at the same time. Yes, they are stored separately, but both respond to the same underlying changes in the world's aspect. The vessel creates Vitium in the biome registry, which both systems then work with in their own ways.

[pirate0815]

Thank you for the explanation.
Would it make more sense for the vessel and other corruption sources (for example when a jar gets broken) to not modify the BiomeAspectRegistry but instead increase the amount of vitium in a region or single chunk in the corruption system?

Because with the current biome approach i see a few issues from my perspective and current understanding of the code:

1. Corruption is not local to the source and its surrounding chunks but instead effects every single chunk in the world of that biome.
2. Booth Systems of Counting Aspects per Chunk (ChunkAspectStorage and AetherChunkData) only use the BiomeAspectRegistry if chunk is initialized, if there is a stored version of disk that is loaded instead.
3. The Changes to the BiomeAspectRegistry do not persist between reloads of a savegame from disk. From looking at the source code i did not find any logic that would save them to disk.

[0vergrown]

Thank you for the explanation.
Would it make more sense for the vessel and other corruption sources (for example when a jar gets broken) to not modify the BiomeAspectRegistry but instead increase the amount of vitium in a region or single chunk in the corruption system?

Because with the current biome approach I see a few issues from my perspective and current understanding of the code:

1. Corruption is not local to the source and its surrounding chunks but instead affects every single chunk in the world of that biome.
2. Booth Systems of Counting Aspects per Chunk (ChunkAspectStorage and AetherChunkData) only use the BiomeAspectRegistry if the chunk is initialized, if there is a stored version of the disk that is loaded instead.
3. The Changes to the BiomeAspectRegistry do not persist between reloads of a savegame from disk. From looking at the source code I did not find any logic that would save them to disk.

I think you're right, actually? I have to look because I vaguely remember there was a commit that dealt with this but it was merged. But to try and fix it, we could instead of modifying the global BiomeAspectRegistry, have the vessel and other sources work like this:

// When the vessel creates Vitium
private void convertAspectsToVitium(World world, BlockPos pos) {
    int totalAspects = this.aspects.values().stream().mapToInt(Integer::intValue).sum();
    
    // Affect the local area instead of the entire biome
    ChunkPos centerChunk = new ChunkPos(pos);
    int radius = 2; // Corrupt chunks in 2-chunk radius
    
    for (int x = -radius; x <= radius; x++) {
        for (int z = -radius; z <= radius; z++) {
            ChunkPos chunkPos = new ChunkPos(centerChunk.x + x, centerChunk.z + z);
            
            // Add Vitium directly to the corruption system storage
            CorruptionDataManager.modifyChunkAspect(
                (ServerWorld) world, chunkPos, getBiomeId(world, pos), 
                VITIUM_ASPECT, totalAspects / 9 // Distribute among 9 chunks
            );
        }
    }
    
    // Clear vessel aspects
    this.aspects.clear();
}

When a jar breaks:

// Add Vitium to the specific chunk where the jar broke
CorruptionDataManager.modifyChunkAspect(
    world, chunkPos, biomeId, VITIUM_ASPECT, jarAspectAmount
);

Just use ChunkAspectStorage that saves to disk and keeps the systems in sync. So, both corruption and Aether systems use the same stored chunk data. This way, corruption becomes something that starts in specific places and spreads naturally, rather than instantly affecting entire biomes worldwide and the data persists between game sessions

[pirate0815]

Thanks for the answer, i now can continue working on alchemy related stuff.

So from my current understanding the current aether aspect values (AetherChunkData) is what easily "accessible" / "free floating" magic generally in a chunk and the amounts stored in ChunkAspectStorage how of an aspect should in principle be in a chunk.
If that is the case, why not simply modify the maxAether in the AetherChunkData instead aspect amount in ChunkAspectStorage?

[0vergrown]

If that is the case, why not simply modify the maxAether in the AetherChunkData instead aspect amount in ChunkAspectStorage?

Because in all honesty, AspectsLib and Thaumaturge are my very first mods with Thaumaturge being the absolute first mod I started coding and learning Java with and I started like 8 months ago now? I remember I started in March of this year and in that time I've also been commissioning people on both mods for features and stuff that's too advanced for me so there's been a lot of hands on them and the Aether, Aspect, and Corruption systems are an amalgamation of code made by myself and people I've commissioned so if you know how, you are more than free to take a crack at it and I'll update it to the Modrinth mavens and then update Thaumaturge so you can use the changes on there too

[pirate0815]

For being your first java project the structure / architecture is actually not bad.
If i remember back at my first attempts at Coding they were way worse.

My question was not meant to be accusatory, even if in retrospect it certainly sounds like that.
It was just to discern if the current implementation was a intentional design decision for lore / game design reason
or an artifact of an iterative development process that could be remade at a later date.

[0vergrown]

For being your first Java project the structure/architecture is actually not bad.
If I remember back at my first attempts at coding they were way worse.

My question was not meant to be accusatory, even if in retrospect it certainly sounds like that.
It was just to discern if the current implementation was an intentional design decision for lore/game design reasons
or an artifact of an iterative development process that could be remade at a later date.

I didn't feel accused at all, no worries, they are valid questions. Everything so far has been intentional. The magic system is centered around the concept of Aspects and their Resonance. It's designed to be a hard magic system with clear rules and defined limitations, and (hopefully) logical consequences that are built on Quintessence and Aether.

In-game, Quintessence is basically just lore. Code and mechanically it doesn't exist because it's raw, unmanifested cosmic energy. You can't manipulate it directly but it serves as the source of magic.

Aether is the tangible manifestation of Quintessence within the physical world. It acts as the medium through which magic is expressed and practiced. Its presence is measured in Resonance Units (RU) and areas in the world naturally possess different "Aether Densities" which are characterized by specific Aspects. For example, a volcano might have an Aether Density rich in Ignis (e.g., 5 RU/m³ Ignis), while a graveyard might have an Aether Density with Mortuus (e.g., 3 RU/m³ Mortuus). In terms of lore, you tap into this ambient Aether to fuel spells.

Dead Zones are areas (in-game chunks) where magic can't be cast. There are two types. Temporary Dead Zones which are localized areas caused by the aggressive overharvesting of Aether (draining an area faster than it can naturally replenish). They recover slowly at a rate of 1 RU per day. Spells cast within these zones are significantly weaker or fail outright. Permanent Dead Zones are the extremely rare variant and occur when an enormous amount of Aether (>10,000 RU) is expended within a very short timeframe (<1 hour) in a concentrated area. This drain collapses the Aether of the location and is completely absent of Aspects. All magical conduits (Gauntlets, Staffs, Wands) malfunction or become inert.

Aspects are the properties or "flavors" of matter and energy that exist within the Aether, they aren't only elements. Because there are 37 (maybe 38 if I include Fames) it means that nearly every item, entity, block, etc can be represented by a characteristic combination of these Aspects.

Then there's Resonance which is the dynamic interaction between Aspects. It can either amplify the effects of compatible Aspects or neutralize those that are opposed. Amplifying Resonance is when certain combinations enhance each other. Aer (Air) and Motus (Motion) for example, have Amplifying Resonance which can lead to enhanced dashing or movement spells. Opposing Resonance is when incompatible Aspects meet, they can neutralize each other. Aqua (Water) and Ignis (Fire) are a prime example because water extinguishes fire, and fire evaporates water but the outcome depends on the relative quantities and conditions of each Aspect involved. Combining opposing Aspects in crafting or spellcasting incurs Resonance Barriers, requiring a significant expenditure of RU to overcome (e.g., combining Aqua and Ignis might require a 20 RU barrier).

So far, Aspects, Aether, Resonance, Dead Zones, and Corruption are coded, decent enough I think but I'm being genuine in terms of contributions. Like if you know a better way, feel free to express it or code a version you think works better, do it. I want this to be the very best it can be and I know I can't do it by myself and lack the skills to in some areas