What's Happened?

AStages v0.8.0: A Major Step Forward

Caution

This new modifications were literally a FLOP! Those changes remains the basis of the mod, but KubeJS has different problems interfacing with those methods. I want to keep this page online because is part of the history of the mod!

The development of a mod is a journey of growth, both in understanding programming and in mastering the tools of creation. Over time, this process pushes developers to strive for better solutions—more efficient code, yes, but above all, more modular structures that allow for scalability, flexibility, and faster implementation of new features. This philosophy has been central to the evolution of AStages.

When I began working on this mod, I was inspired by another project, Game/Item/Whatever Stage, but as development progressed, I felt an increasing desire to take a different path and create something different. AStages has been shaped by that ambition, and with version 0.8.0, the mod enters a pivotal transitional phase. This update represents a shift toward a cleaner, more robust codebase—one that is not only more customizable but also capable of scaling to meet new demands.

This version has allowed me to refine AStages into a more powerful and flexible tool, laying the groundwork for future updates that will be faster to implement and more impactful in terms of features and functionality. The changes introduced here reflect not just technical improvements but also a commitment to providing the community with a mod that evolves alongside their creativity.

Version 0.8.0 is a step toward the future of AStages, and I’m excited to continue sharing this journey with all of you. Thank you for your support as we move toward a new era for the mod.

Presenting new changes!

Presenting the new code formatting modes! This change, while breaking backward compatibility (please don’t hate me for it!), introduces a unified and streamlined structure. From a KubeJS perspective, only one new formatting style has been introduced, while restrictions via commands remain virtually unchanged.

Let’s take a look at an example from the old code format (v0.7.0). This example demonstrates a restriction on interacting with a structure, allowing players to fight and interact with it, but not place or break blocks:

// Old Code Example (v0.7.0)
AStages.addRestrictionForStructure("astages/structure", "stage_structure", "minecraft:pillager_outpost")
    .setCanAttackEntities(true)
    .setCanEnter(true)
    .setCanInteract(true)
    .setCanBlockBePlaced(false)
    .setCanBlockBeBroken(false)

And now, here’s the same restriction in the new code format (v0.8.0):

// New Code Example (v0.8.0)
AStages.addRestrictionForStructure("astages/structure", "stage_structure", "minecraft:pillager_outpost")
    .set(Attributes.ATTACKING, true)
    .set(Attributes.ENTERING, true)
    .set(Attributes.GENERIC_INTERACTIONS, true)
    .set(Attributes.BLOCK_PLACING, false)
    .set(Attributes.BLOCK_BREAKING, false)

The most noticeable difference is the method used to define restriction properties (properties are now called attributes): instead of creating hundreds of individual getters and setters, all restrictions are now managed through the single, unified method: setAttribute(attribute, value) and getAttribute(attribute). This approach greatly simplifies the code and offers a consistent way to handle restrictions, reducing redundancy and improving maintainability.

Special thanks to @Pie (Jerry Rig Everything) for this fantastic idea!