Oraxen tasks

Task guides and troubleshooting for Oraxen. Check the installed release before changing configuration or data.

Build an Oraxen recipe without replacing another recipe

A custom recipe needs its own identity as well as the correct output. Use a disposable recipe to check ingredients, quantities and discovery before changing a recipe players already use.

Check the installed content

Oraxen combines server-side item definitions with client resource-pack assets. Check the installed release before copying a recipe or component example, because Minecraft item formats have changed between releases. Work on a staging copy for changes that affect existing player items.

Work through the change

  1. Inventory the existing recipe files and record the intended output item ID, amount and recipe type. Keep a backup of the recipe folder before opening the builder.
  2. In game on staging, open the required player-only builder, such as /oraxen recipes builder shaped for a shaped recipe. Fill its inputs and output, then save a new descriptive name with /oraxen recipes save <name>.
  3. Inspect the saved definition and confirm that its name does not overwrite another recipe. Test the exact ingredient arrangement and one arrangement that should fail.
  4. Test with an ordinary player who has the intended recipe permission. Repeat with insufficient ingredients and with a full inventory, observing where the crafted result goes.

Verify the result

The output should have the correct Oraxen identity and amount, and each craft should consume the intended ingredients. An unrelated recipe should still produce its original result.

If the result differs

If an administrator can craft but a player cannot, check recipe permissions and discovery. If the wrong item appears, inspect the output ID before rebuilding textures; recipe logic and client appearance are separate.

Keep a recovery path

Restore the previous recipe directory and restart the staging server if the new recipe overrides an existing one. Keep the failed recipe outside the loaded folder while comparing names and ingredients.

References and related help

Check the maintainer reference: Oraxen documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.

Diagnose an Oraxen cooking recipe with the wrong timing

Cooking recipes have processing settings beyond their input and output. Compare one furnace process at a time before changing every custom recipe or the server tick rate.

Check the installed content

Oraxen combines server-side item definitions with client resource-pack assets. Check the installed release before copying a recipe or component example, because Minecraft item formats have changed between releases. Work on a staging copy for changes that affect existing player items.

Work through the change

  1. Record the cooking type, expected input, output, processing duration and experience. Check the current Oraxen recipe reference for the units and fields supported by your release.
  2. Copy the recipe to a unique staging name. Set an observable processing duration and a low-value result so a mistake cannot create valuable items.
  3. Load the test recipe through the release-supported workflow and use the matching cooking block. A furnace, smoker and blast furnace do not accept all the same recipe types.
  4. Time several individual operations while the server runs normally. Check the consumed ingredients and experience separately, then repeat with a vanilla control recipe in another block.

Verify the result

The custom process should use the intended block and timing without changing the vanilla control. Record server tick performance if wall-clock duration differs from the configured processing time.

If the result differs

If the recipe never starts, inspect its type and ingredient matching before shortening the duration. If every recipe runs slowly, investigate server tick delay rather than multiplying the custom cooking speed.

Keep a recovery path

Restore the earlier custom recipe and remove only the disposable furnace contents. Preserve the world save before testing automation around custom cooking, because a recipe rollback cannot retrieve already processed materials.

References and related help

Check the maintainer reference: Oraxen documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.

Keep Oraxen recipe-book groups understandable for players

Recipe-book grouping changes how players discover related crafts. Check grouping separately from crafting correctness so a tidy menu does not hide a missing or inaccessible recipe.

Check the installed content

Oraxen combines server-side item definitions with client resource-pack assets. Check the installed release before copying a recipe or component example, because Minecraft item formats have changed between releases. Work on a staging copy for changes that affect existing player items.

Work through the change

  1. List the recipes that should appear together and record their output types. The maintainer reference describes grouping through a nonempty group and compatible outputs; confirm your installed-release behaviour.
  2. Back up those recipe definitions and change the group on a small staging set. Keep recipe identities, ingredients and outputs unchanged during this presentation test.
  3. Use a clean test player with normal permissions and unlock the relevant recipes through the intended gameplay path. Inspect the recipe book rather than relying only on an administrator account.
  4. Craft each grouped recipe and compare the displayed variants with the actual outputs. Include an unrelated recipe to ensure its discovery and grouping were not affected.

Verify the result

Players should find the intended variants together and still craft each one correctly. A recipe that should remain separate should retain its own entry or documented grouping behaviour.

If the result differs

If crafting works but the book looks wrong, inspect discovery and group compatibility. If one variant disappears entirely, confirm that its file loaded and that the player can access it before changing the group again.

Keep a recovery path

Restore the saved group values if navigation becomes confusing. Do not rename recipe IDs to solve a display problem without checking the effect on existing player recipe discovery and dependent content.

References and related help

Check the maintainer reference: Oraxen documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.

Fix an Oraxen glyph that is clipped above a menu title

A font glyph can exist in the pack while being cropped in a title. Check its height and ascent together before changing the menu plugin or replacing the whole resource pack.

Check the installed content

Oraxen combines server-side item definitions with client resource-pack assets. Check the installed release before copying a recipe or component example, because Minecraft item formats have changed between releases. Work on a staging copy for changes that affect existing player items.

Work through the change

  1. Locate the affected glyph definition and its image. Record its height, ascent and the context where clipping occurs, such as chat, a title or an inventory menu.
  2. Compare the glyph with the installed-release font reference. The documented height must be at least the ascent; also check the image canvas and transparent padding.
  3. Change a copied glyph on staging and generate the matching pack. Test it in ordinary chat first, then in the exact menu that showed the clipping.
  4. Try the normal supported client versions and GUI scales. Keep a screenshot of each comparison so a vertical offset is distinguishable from a missing character or missing pack.

Verify the result

The whole glyph should be visible in its intended context without pushing other text beyond the usable area. Ordinary text in the same menu should remain readable.

If the result differs

If chat works but the menu does not, check that menu integration against your Paper and Oraxen versions. Current docs describe version-dependent GUI packet requirements; adding an outdated packet dependency can introduce another failure.

Keep a recovery path

Restore the previous glyph measurements and generated pack together if the layout worsens. Keep the original image file so you can compare padding without changing the glyph identifier used by menus.

References and related help

Check the maintainer reference: Oraxen documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.

Separate an Oraxen missing glyph from a missing permission

A player seeing raw glyph text may have a pack, permission or formatting problem. Compare the same glyph in two accounts before editing the image or granting broad access.

Check the installed content

Oraxen combines server-side item definitions with client resource-pack assets. Check the installed release before copying a recipe or component example, because Minecraft item formats have changed between releases. Work on a staging copy for changes that affect existing player items.

Work through the change

  1. Record the exact glyph identifier and the text players type or the menu sends. Verify the installed-release syntax rather than assuming another plugin uses the same placeholder.
  2. Test the glyph on staging with one administrator and one ordinary account using the same accepted pack. Compare chat output with a server-generated message containing the glyph.
  3. Inspect the permission rules documented for that glyph and its integration. Grant only the intended narrow permission to a temporary test group and repeat the ordinary-player test.
  4. Revoke the temporary grant and test the denied case again. If permissions work, compare the client pack version and the formatting path used by the failing message.

Verify the result

The authorised player should see the intended glyph in supported contexts, and the denied case should follow the documented restriction. Neither account should need operator status for routine glyph use.

If the result differs

If both accounts fail, inspect pack generation and the glyph character mapping. If only one chat format fails, trace its escaping or placeholder processing before changing the glyph file.

Keep a recovery path

Remove the temporary permission group and restore the previous glyph configuration if necessary. Keep a record of the exact node tested so production access can be granted deliberately without using wildcard permissions.

References and related help

Check the maintainer reference: Oraxen documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.

Check an Oraxen item component against the Minecraft version

A custom item can lose a behaviour after a Minecraft update even when its model remains correct. Check the supported component format before replacing player items or changing the texture.

Check the installed content

Oraxen combines server-side item definitions with client resource-pack assets. Check the installed release before copying a recipe or component example, because Minecraft item formats have changed between releases. Work on a staging copy for changes that affect existing player items.

Work through the change

  1. Record the exact Minecraft, Paper and Oraxen versions and the affected item ID. Keep a copy of its current definition and one representative existing test item.
  2. Open the item documentation for that release and identify the behaviour field involved. Do not mix a legacy item setting with a newer Minecraft component example unless the release supports it.
  3. Create a new staging item ID with only the base material and affected behaviour. Obtain a fresh copy and test the relevant interaction without optional mechanics.
  4. Compare the fresh simplified item, the full new item and the existing old copy. This separates an unsupported definition from item-update behaviour or another mechanic.

Verify the result

The fresh item should have the intended behaviour on the supported server version. Existing copies should change only according to the item-update policy documented for your installed build.

If the result differs

If the simplified item fails, inspect loading warnings and version support. If only old copies differ, investigate the supported updater path; a resource-pack rebuild alone does not rewrite stored server-side item data.

Keep a recovery path

Restore the earlier definition and keep valuable player items untouched while testing. If an item migration is necessary, prepare a separate backed-up procedure rather than distributing replacements during diagnosis.

References and related help

Check the maintainer reference: Oraxen documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.

Find duplicate Oraxen item IDs before merging a pack

Two content packs can define the same internal item ID. Compare their definitions before merging files so one pack does not silently change an item players already own.

Check the installed content

Oraxen combines server-side item definitions with client resource-pack assets. Check the installed release before copying a recipe or component example, because Minecraft item formats have changed between releases. Work on a staging copy for changes that affect existing player items.

Work through the change

  1. Export the current item definitions and list their internal IDs. Compare the incoming pack in a separate directory, including recipes and mechanics that reference those IDs.
  2. Mark duplicate IDs and decide which existing identity must remain stable. A new filename or display name does not necessarily create a new item identity.
  3. Import a small nonconflicting section into staging and inspect startup warnings. For each collision, plan a new unique incoming ID and update its references consistently before loading it.
  4. Test representative existing items alongside fresh incoming items. Check recipes and interactions, not just their models, because two items can look different while sharing conflicting definitions.

Verify the result

Every intended item should resolve to a single definition, and the incoming content should not change the behaviour of existing owned items. Referencing recipes should produce the correct unique output.

If the result differs

If the wrong item appears, search all loaded definition files for its ID. If only its texture is wrong, inspect model references after resolving ID collisions rather than renaming more live items.

Keep a recovery path

Restore the complete previous definitions and generated pack if the merge changes existing content. Do not remove player inventory data to resolve a collision; keep the incoming pack isolated until its IDs are consistent.

References and related help

Check the maintainer reference: Oraxen documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.

Test an Oraxen pack update with a clean client download

A cached client pack can hide a successful update or make a broken update seem healthy. Compare a clean download with an existing client while keeping server definitions unchanged.

Check the installed content

Oraxen combines server-side item definitions with client resource-pack assets. Check the installed release before copying a recipe or component example, because Minecraft item formats have changed between releases. Work on a staging copy for changes that affect existing player items.

Work through the change

  1. Record the installed Oraxen version and the pack build being tested. Save the source assets and generated output together so the comparison uses a reproducible build.
  2. Change one disposable staging texture with an unmistakable difference and generate the pack through the supported workflow. Inspect build errors before sharing its download address.
  3. Join with a test client that has not cached this pack version and accept the pack. Compare the disposable item with a client that previously used the earlier build.
  4. Check the server-provided download settings and any external hosting cache if the clients disagree. Confirm that the downloaded file is the new output rather than changing item IDs to force a visual difference.

Verify the result

Both clients should receive the intended build and show the changed test asset. The server-side item identity and unrelated textures should remain unchanged throughout the comparison.

If the result differs

If a clean client also shows the old asset, inspect the generated file and hosting path. If only the existing client differs, investigate cache identity and the release-supported pack delivery settings.

Keep a recovery path

Restore the earlier assets and pack output together if the new build is invalid. Keep the test change out of valuable items and avoid asking every player to clear unrelated client data during diagnosis.

References and related help

Check the maintainer reference: Oraxen documentation, Oraxen documentation.

Before changing live data, read how to keep a completed recovery copy. For startup errors, use the log collection guide.