Jump to content

Forge and Spigot. No not that...


LargePrime

Recommended Posts

I am curious if there is any plan to have a Vanilla/Forge version of Spigot?  Without the CraftBukkit/Bukkit support.

 

Yes MCPC+ exists.  But with the current and future capability of forge, I am looking at a bukkit free future.  But My servers need the efficiency that spigot brings to the table.  It wold be kinda silly If i have to keep bukkit compatibility just for the efficiency.

 

I could find and have not read anything about this. I cant be the only one?

 

 

Link to comment
Share on other sites

I am curious if there is any plan to have a Vanilla/Forge version of Spigot?  Without the CraftBukkit/Bukkit support.

 

Yes MCPC+ exists.  But with the current and future capability of forge, I am looking at a bukkit free future.  But My servers need the efficiency that spigot brings to the table.  It wold be kinda silly If i have to keep bukkit compatibility just for the efficiency.

 

I could find and have not read anything about this. I cant be the only one?

 

 

Link to comment
Share on other sites

I have plans to do this as a side project, but of course that would require the support of the Spigot developers.

Read the EAQ before posting! OR ELSE!

 

This isn't building better software, its trying to grab a place in the commit list of a highly visible github project.

 

www.forgeessentials.com

 

Don't PM me, I don't check this account unless I have to.

Link to comment
Share on other sites

I have plans to do this as a side project, but of course that would require the support of the Spigot developers.

Read the EAQ before posting! OR ELSE!

 

This isn't building better software, its trying to grab a place in the commit list of a highly visible github project.

 

www.forgeessentials.com

 

Don't PM me, I don't check this account unless I have to.

Link to comment
Share on other sites

Spigot's performance enchancments don't lend themselves to Modded minecraft well. Namely it's major ones of re-writing and threading the ticks. Most mods can't handle threaded ticks, and there re-writing of it actually prevents the world from ticking as often as it usually does. However there are projects out there that try to merge the two. But for now there is no plans to move anywhere near the spigot front.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Spigot's performance enchancments don't lend themselves to Modded minecraft well. Namely it's major ones of re-writing and threading the ticks. Most mods can't handle threaded ticks, and there re-writing of it actually prevents the world from ticking as often as it usually does. However there are projects out there that try to merge the two. But for now there is no plans to move anywhere near the spigot front.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Spigot's performance enchancments don't lend themselves to Modded minecraft well. Namely it's major ones of re-writing and threading the ticks. Most mods can't handle threaded ticks, and there re-writing of it actually prevents the world from ticking as often as it usually does. However there are projects out there that try to merge the two. But for now there is no plans to move anywhere near the spigot front.

Are you saying that vanilla server is plenty optimal?

Is Forge looking at helping modders move to threadable mod architectures?  Or ways of writing mods to support higher performance?

Currently Spigot supports ore obfuscation with performance that no mod can match.  Will luacs1998 side project do that, or are you saying Forge will have to ore obfuscate thru mods, if we dont use spigot?

 

luacs1998; with Forge Essentials relatively mature, we can almost drop bukkit now, right? 

Link to comment
Share on other sites

Spigot's performance enchancments don't lend themselves to Modded minecraft well. Namely it's major ones of re-writing and threading the ticks. Most mods can't handle threaded ticks, and there re-writing of it actually prevents the world from ticking as often as it usually does. However there are projects out there that try to merge the two. But for now there is no plans to move anywhere near the spigot front.

Are you saying that vanilla server is plenty optimal?

Is Forge looking at helping modders move to threadable mod architectures?  Or ways of writing mods to support higher performance?

Currently Spigot supports ore obfuscation with performance that no mod can match.  Will luacs1998 side project do that, or are you saying Forge will have to ore obfuscate thru mods, if we dont use spigot?

 

luacs1998; with Forge Essentials relatively mature, we can almost drop bukkit now, right? 

Link to comment
Share on other sites

We have no plans to re-write minecraft to be more threaded then it currently is.

Forge does do a lot of things to increase the performance of Minecraft itself.

However, the main issue is on the modders end, not Forge's.

Spigot can make some of its 'performance improvements' because its working on basically a vanilla base. Where it can do things that completely bork the design of standard game mechanics, and as long as the end user doesn't see it, nobody cares.

However mods hook a lot deeper then the visual gameplay for the end user.

 

As for ore obfuscation, there are mods that can do that, but honestly, who cares? If you have a dick on your server thats using xray, ban there ass.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

We have no plans to re-write minecraft to be more threaded then it currently is.

Forge does do a lot of things to increase the performance of Minecraft itself.

However, the main issue is on the modders end, not Forge's.

Spigot can make some of its 'performance improvements' because its working on basically a vanilla base. Where it can do things that completely bork the design of standard game mechanics, and as long as the end user doesn't see it, nobody cares.

However mods hook a lot deeper then the visual gameplay for the end user.

 

As for ore obfuscation, there are mods that can do that, but honestly, who cares? If you have a dick on your server thats using xray, ban there ass.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

We have no plans to re-write minecraft to be more threaded then it currently is.

So does this mean luacs1998 side project has been halted?

However, the main issue is on the modders end, not Forge's.

Does Forge have any plans to help modders do better?  Or help Server Owners identify High performance enabled mods that wont choke servers?  Or low performance ones?

So we dont ALL have to test the same thing over and over again?

Spigot can make some of its 'performance improvements' because its working on basically a vanilla base. Where it can do things that completely bork the design of standard game mechanics, and as long as the end user doesn't see it, nobody cares.

However mods hook a lot deeper then the visual gameplay for the end user.

So MCPC+ must really be working their buts off.

As for ore obfuscation, there are mods that can do that, but honestly, who cares? If you have a dick on your server thats using xray, ban there ass.

That's one approach I guess.  Am I free to 'care' and entertain other approaches?

 

I know My MCPC+ servers are faster and lighter than straight vanilla-forge.  I was hoping for even more from a version that dropped bukkit entirely.  If that is not going to happen, then I guess I will stick with MCPC+?

Link to comment
Share on other sites

We have no plans to re-write minecraft to be more threaded then it currently is.

So does this mean luacs1998 side project has been halted?

However, the main issue is on the modders end, not Forge's.

Does Forge have any plans to help modders do better?  Or help Server Owners identify High performance enabled mods that wont choke servers?  Or low performance ones?

So we dont ALL have to test the same thing over and over again?

Spigot can make some of its 'performance improvements' because its working on basically a vanilla base. Where it can do things that completely bork the design of standard game mechanics, and as long as the end user doesn't see it, nobody cares.

However mods hook a lot deeper then the visual gameplay for the end user.

So MCPC+ must really be working their buts off.

As for ore obfuscation, there are mods that can do that, but honestly, who cares? If you have a dick on your server thats using xray, ban there ass.

That's one approach I guess.  Am I free to 'care' and entertain other approaches?

 

I know My MCPC+ servers are faster and lighter than straight vanilla-forge.  I was hoping for even more from a version that dropped bukkit entirely.  If that is not going to happen, then I guess I will stick with MCPC+?

Link to comment
Share on other sites

So does this mean luacs1998 side project has been halted?
luacs isn't part of the Forge team, he can do whatever the hell he wants.

 

Does Forge have any plans to help modders do better?  Or help Server Owners identify High performance enabled mods that wont choke servers?  Or low performance ones?

So we dont ALL have to test the same thing over and over again?

No, server admins need to learn how to admin there servers properly, which includes reviewing performance. We can't control modders, or server admins, it's on there end.

The modding community has always been a community based thing, so if you want to help then start this project up yourself. This isn't something that Forge needs to do.

 

That's one approach I guess.  Am I free to 'care' and entertain other approaches?
You're free to care for whatever you want. However Forge will not.

 

I know My MCPC+ servers are faster and lighter than straight vanilla-forge.  I was hoping for even more from a version that dropped bukkit entirely.  If that is not going to happen, then I guess I will stick with MCPC+?
Sounds about right, Server run just fine if setup properly on just Vanilla/Forge, if you wanna wrangle more 'performance' out of it then you're on your own. Go to the Spigot and MCPC+ community not here.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

So does this mean luacs1998 side project has been halted?
luacs isn't part of the Forge team, he can do whatever the hell he wants.

 

Does Forge have any plans to help modders do better?  Or help Server Owners identify High performance enabled mods that wont choke servers?  Or low performance ones?

So we dont ALL have to test the same thing over and over again?

No, server admins need to learn how to admin there servers properly, which includes reviewing performance. We can't control modders, or server admins, it's on there end.

The modding community has always been a community based thing, so if you want to help then start this project up yourself. This isn't something that Forge needs to do.

 

That's one approach I guess.  Am I free to 'care' and entertain other approaches?
You're free to care for whatever you want. However Forge will not.

 

I know My MCPC+ servers are faster and lighter than straight vanilla-forge.  I was hoping for even more from a version that dropped bukkit entirely.  If that is not going to happen, then I guess I will stick with MCPC+?
Sounds about right, Server run just fine if setup properly on just Vanilla/Forge, if you wanna wrangle more 'performance' out of it then you're on your own. Go to the Spigot and MCPC+ community not here.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Spigot's performance enchancments don't lend themselves to Modded minecraft well. Namely it's major ones of re-writing and threading the ticks. Most mods can't handle threaded ticks, and there re-writing of it actually prevents the world from ticking as often as it usually does. However there are projects out there that try to merge the two. But for now there is no plans to move anywhere near the spigot front.

While some of the Spigot patches can cause problems for mods, many of the smaller patches are not as problematic. Also the changes are grouped together in separate patches so they can be applied or rolled back individually, if needed. For MCPC+, I applied most all of Spigot's patches, though a couple I turned off by default (so far, disabling chunk tick aggregation since it does reduce ticking noticeably affecting gameplay, as you said; also turned off entity range activation since I expect most players on modded servers will want their entities to be activated no matter how far they are away, but, either feature can be re-enabled in the config if desired).

 

Many of Spigot's improvements, if they prove stable and safe enough, end up getting pulled into vanilla CraftBukkit. CraftBukkit itself has quite a few performance and stability fixes, above and beyond its plugin API which it is most well-known for.

 

However, some of these enhancements even in CraftBukkit can cause unintended interactions with mods. Asynchronous chunk loading, for one. Caused tons of crashes with XyCraft, for example, due to the order which it loaded chunks (not too clear on this problem to be honest, but nallar recently submitted a fix to clear up some if not most of these concurrency issues with XyCraft in MCPC+, by not calling the Forge event asynchronously).

 

But a lot of the changes are fairly benign. Some are even vanilla bug fixes (of course, Forge includes some vanilla bug fixes too). Just one example, CB gets tile entities from the chunk map directly instead of a bounding box on the world; avoiding the off-by-one error which loaded additional chunks, as well as avoiding the expensive searching operation. Maybe this could impact some mods, somehow, granted.

 

Something I've been wanted to work on for a while, but haven't got around to it yet, is automatically remapping Spigot's patches ala MCPBukkit. Main reason why I have not yet is because Spigot is developed as a set of patches on top of CraftBukkit (similar to how Forge and FML include patches on top of vanilla), so the logistics of maintaining a linear history on the remapped source would have to be determined. Should be possible though, just would need non-trivial changes to the automation script.

 

Not to say the changes can be blindly integrated, but would be nice to have an auto-remapped repository of both Spigot and CraftBukkit for reference purposes, to see if their changes could feasibly benefit Forge, imho. Or possibly a coremod could be developed by someone to add the individual optimizations. TickThreading basically does this, adding threaded ticks, but it also has to patch the mods for thread-safety purposes.

Link to comment
Share on other sites

Spigot's performance enchancments don't lend themselves to Modded minecraft well. Namely it's major ones of re-writing and threading the ticks. Most mods can't handle threaded ticks, and there re-writing of it actually prevents the world from ticking as often as it usually does. However there are projects out there that try to merge the two. But for now there is no plans to move anywhere near the spigot front.

While some of the Spigot patches can cause problems for mods, many of the smaller patches are not as problematic. Also the changes are grouped together in separate patches so they can be applied or rolled back individually, if needed. For MCPC+, I applied most all of Spigot's patches, though a couple I turned off by default (so far, disabling chunk tick aggregation since it does reduce ticking noticeably affecting gameplay, as you said; also turned off entity range activation since I expect most players on modded servers will want their entities to be activated no matter how far they are away, but, either feature can be re-enabled in the config if desired).

 

Many of Spigot's improvements, if they prove stable and safe enough, end up getting pulled into vanilla CraftBukkit. CraftBukkit itself has quite a few performance and stability fixes, above and beyond its plugin API which it is most well-known for.

 

However, some of these enhancements even in CraftBukkit can cause unintended interactions with mods. Asynchronous chunk loading, for one. Caused tons of crashes with XyCraft, for example, due to the order which it loaded chunks (not too clear on this problem to be honest, but nallar recently submitted a fix to clear up some if not most of these concurrency issues with XyCraft in MCPC+, by not calling the Forge event asynchronously).

 

But a lot of the changes are fairly benign. Some are even vanilla bug fixes (of course, Forge includes some vanilla bug fixes too). Just one example, CB gets tile entities from the chunk map directly instead of a bounding box on the world; avoiding the off-by-one error which loaded additional chunks, as well as avoiding the expensive searching operation. Maybe this could impact some mods, somehow, granted.

 

Something I've been wanted to work on for a while, but haven't got around to it yet, is automatically remapping Spigot's patches ala MCPBukkit. Main reason why I have not yet is because Spigot is developed as a set of patches on top of CraftBukkit (similar to how Forge and FML include patches on top of vanilla), so the logistics of maintaining a linear history on the remapped source would have to be determined. Should be possible though, just would need non-trivial changes to the automation script.

 

Not to say the changes can be blindly integrated, but would be nice to have an auto-remapped repository of both Spigot and CraftBukkit for reference purposes, to see if their changes could feasibly benefit Forge, imho. Or possibly a coremod could be developed by someone to add the individual optimizations. TickThreading basically does this, adding threaded ticks, but it also has to patch the mods for thread-safety purposes.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Hi, im making a BlockEntity that can contain fluids, and render them in the GUI, only one fluid works perfectly, I can fill or drain it, sync it to the client, and render it. The problem comes when i try to have two fluids in the same GUI, depending on what I delete or leave, the fluids act differently; for example, deleting both of them from "saveAdditional" and "load" methods makes that the fluids cannot render. Also, it can only render one fluid alone, or again, render one fluid, but twice (copies one fluid to the other one). FYI the left one is water, the right one is a red custom fluid. How can I fix this? BoilerBlockEntity: https://pastebin.com/e6b2U3sD BoilerMenu: https://pastebin.com/D375yCNr BoilerScreen: https://pastebin.com/WMrK83Du 
    • container@pterodactyl~ Server marked as starting... [Pterodactyl Daemon]: Pulling Docker container image, this could take a few minutes to complete... [Pterodactyl Daemon]: Finished pulling Docker container image container@pterodactyl~ java -version openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server VM Temurin-17.0.10+7 (build 17.0.10+7, mixed mode, sharing) container@pterodactyl~ java -Xms128M -Xmx10240M -Dterminal.jline=false -Dterminal.ansi=true -jar server.jar Starting net.fabricmc.loader.impl.game.minecraft.BundlerClassPathCapture [15:07:29] [main/INFO]: Loading Minecraft 1.20.1 with Fabric Loader 0.15.9 [15:07:29] [ForkJoinPool-1-worker-3/WARN]: Mod geophilic uses the version v2.0.0-mc1.20u1.20.1 which isn't compatible with Loader's extended semantic version format (Could not parse version number component 'v2'!), SemVer is recommended for reliably evaluating dependencies and prioritizing newer version [15:07:29] [main/INFO]: Dependencies overridden for fabric-api, cem, colormatic, debugify [15:07:30] [main/WARN]: Warnings were found!  - Mod 'Debugify' (debugify) 1.20.1+2.0 recommends any 3.x version of yet-another-config-lib, which is missing!          - You should install any 3.x version of yet-another-config-lib for the optimal experience.  - Mod 'Fabric API' (fabric-api) 0.87.0+1.20.1 recommends any version after 4.5.0 of Fabulously Optimized, which is missing!          - You should install any version after 4.5.0 of Fabulously Optimized for the optimal experience. [15:07:30] [main/INFO]: Loading 174 mods:         - appleskin 2.5.0+mc1.20         - architectury 9.1.12         - ash_api 3.0.2+1.20.1         - axesareweapons 1.7.1         - balm-fabric 7.0.7         - betteradvancements 0.3.2.161         - betterdeserttemples 1.20-Fabric-3.0.1            \-- org_reflections_reflections 0.10.2         - betterdungeons 1.20-Fabric-4.0.1         - betterfortresses 1.20-Fabric-2.0.2         - betterjungletemples 1.20-Fabric-2.0.1         - bettermineshafts 1.20-Fabric-4.0.1         - betteroceanmonuments 1.20-Fabric-3.0.1         - betterstrongholds 1.20-Fabric-4.0.1         - betterwitchhuts 1.20-Fabric-3.0.1         - bookshelf 20.0.3         - cardinal-components 5.2.2            |-- cardinal-components-base 5.2.2            |-- cardinal-components-block 5.2.2            |-- cardinal-components-chunk 5.2.2            |-- cardinal-components-entity 5.2.2            |-- cardinal-components-item 5.2.2            |-- cardinal-components-level 5.2.2            |-- cardinal-components-scoreboard 5.2.2            \-- cardinal-components-world 5.2.2         - carryon 2.1.1.3         - cloth-config 11.1.106            \-- cloth-basic-math 0.6.1         - collective 6.65         - comforts 6.3.3+1.20.1            \-- spectrelib 0.13.12+1.20.1                 |-- com_electronwill_night-config_core 3.6.5                 \-- com_electronwill_night-config_toml 3.6.5         - completeconfig 2.5.0            |-- completeconfig-base 2.5.0            |-- completeconfig-gui-cloth 2.5.0            \-- completeconfig-gui-yacl 2.5.0         - connectiblechains 2.2.1+1.20.1         - customizableelytra 2.1.0+1.20         - cyclepaintings 3.2         - debugify 1.20.1+2.0         - diagonalfences 8.0.1         - diagonalwindows 8.0.1         - doubledoors 5.0         - easyanvils 8.0.1         - easymagic 8.0.1         - easyshulkerboxes 8.0.0            \-- puzzlesapi 8.0.2                 \-- puzzlesaccessapi 8.0.5         - elytraslot 6.3.0+1.20.1         - emotecraft 2.2.7-b.build.50            \-- bendy-lib 4.0.0         - enchanted-vertical-slabs 1.9         - endrem 5.2.2         - fabric-api 0.87.0+1.20.1            |-- fabric-api-base 0.4.30+7abfd51577            |-- fabric-api-lookup-api-v1 1.6.35+4d8536c977            |-- fabric-biome-api-v1 13.0.10+b3afc78b77            |-- fabric-block-api-v1 1.0.9+e022e5d177            |-- fabric-blockrenderlayer-v1 1.1.40+b3afc78b77            |-- fabric-client-tags-api-v1 1.1.1+97bb207577            |-- fabric-command-api-v1 1.2.33+f71b366f77            |-- fabric-command-api-v2 2.2.12+b3afc78b77            |-- fabric-commands-v0 0.2.50+df3654b377            |-- fabric-containers-v0 0.1.63+df3654b377            |-- fabric-content-registries-v0 4.0.9+b3afc78b77            |-- fabric-convention-tags-v1 1.5.4+a1a980da77            |-- fabric-crash-report-info-v1 0.2.18+aeb40ebe77            |-- fabric-data-generation-api-v1 12.2.2+1e61dba177            |-- fabric-dimensions-v1 2.1.53+8536527b77            |-- fabric-entity-events-v1 1.5.22+b3afc78b77            |-- fabric-events-interaction-v0 0.6.1+e91849a877            |-- fabric-events-lifecycle-v0 0.2.62+df3654b377            |-- fabric-game-rule-api-v1 1.0.38+b04edc7a77            |-- fabric-item-api-v1 2.1.27+b3afc78b77            |-- fabric-item-group-api-v1 4.0.10+23d9108177            |-- fabric-key-binding-api-v1 1.0.36+fb8d95da77            |-- fabric-keybindings-v0 0.2.34+df3654b377            |-- fabric-lifecycle-events-v1 2.2.21+b3afc78b77            |-- fabric-loot-api-v2 1.1.39+b3afc78b77            |-- fabric-loot-tables-v1 1.1.43+9e7660c677            |-- fabric-message-api-v1 5.1.7+3265161977            |-- fabric-mining-level-api-v1 2.1.49+b3afc78b77            |-- fabric-model-loading-api-v1 1.0.2+709a987177            |-- fabric-models-v0 0.4.1+9386d8a777            |-- fabric-networking-api-v1 1.3.10+eeb8eb3677            |-- fabric-networking-v0 0.3.50+df3654b377            |-- fabric-object-builder-api-v1 11.1.1+6beca84877            |-- fabric-particles-v1 1.1.1+201a23a077            |-- fabric-recipe-api-v1 1.0.20+b3afc78b77            |-- fabric-registry-sync-v0 2.3.2+4df89eb277            |-- fabric-renderer-api-v1 3.1.2+6bdb2ed077            |-- fabric-renderer-indigo 1.4.2+6bdb2ed077            |-- fabric-renderer-registries-v1 3.2.45+df3654b377            |-- fabric-rendering-data-attachment-v1 0.3.34+b3afc78b77            |-- fabric-rendering-fluids-v1 3.0.27+b3afc78b77            |-- fabric-rendering-v0 1.1.48+df3654b377            |-- fabric-rendering-v1 3.0.7+b3afc78b77            |-- fabric-resource-conditions-api-v1 2.3.5+ea08f9d877            |-- fabric-resource-loader-v0 0.11.9+132c48c177            |-- fabric-screen-api-v1 2.0.7+b3afc78b77            |-- fabric-screen-handler-api-v1 1.3.29+b3afc78b77            |-- fabric-sound-api-v1 1.0.12+b3afc78b77            |-- fabric-transfer-api-v1 3.3.0+cdf060b277            \-- fabric-transitive-access-wideners-v1 4.3.0+6c31357e77         - fabric-language-kotlin 1.10.10+kotlin.1.9.10            |-- org_jetbrains_kotlin_kotlin-reflect 1.9.10            |-- org_jetbrains_kotlin_kotlin-stdlib 1.9.10            |-- org_jetbrains_kotlin_kotlin-stdlib-jdk7 1.9.10            |-- org_jetbrains_kotlin_kotlin-stdlib-jdk8 1.9.10            |-- org_jetbrains_kotlinx_atomicfu-jvm 0.22.0            |-- org_jetbrains_kotlinx_kotlinx-coroutines-core-jvm 1.7.3            |-- org_jetbrains_kotlinx_kotlinx-coroutines-jdk8 1.7.3            |-- org_jetbrains_kotlinx_kotlinx-datetime-jvm 0.4.0            |-- org_jetbrains_kotlinx_kotlinx-serialization-cbor-jvm 1.6.0            |-- org_jetbrains_kotlinx_kotlinx-serialization-core-jvm 1.6.0            \-- org_jetbrains_kotlinx_kotlinx-serialization-json-jvm 1.6.0         - fabricloader 0.15.9            \-- mixinextras 0.3.5         - forgeconfigapiport 8.0.0         - furnacerecycle 2.0         - geophilic v2.0.0-mc1.20u1.20.1         - gildedarmor 1.8.0+fabric-1.20.1         - guiclock 4.2         - guicompass 4.2         - iceberg 1.1.15         - interactic 0.2.0+1.20         - java 17         - kiwi 11.1.1         - lazydfu 0.1.3         - leavesbegone 8.0.0         - lithium 0.11.2         - minecraft 1.20.1         - mixin-conflict-helper 1.2.0         - mixintrace 1.1.1+1.17         - moonlight 1.20-2.8.13         - morebannerfeatures 1.2.0         - mousewheelie 1.12.2+mc1.20.1            |-- amecsapi 1.5.1+mc1.20-pre1            |-- coat 1.0.0-beta.20+mc1.20-pre1            |-- fabric-key-binding-api-v1 1.0.36+fb8d95da77            |-- fabric-screen-api-v1 2.0.7+b3afc78b77            |-- tweed4_annotated 1.3.1+mc1.20-pre1            |-- tweed4_base 1.7.1+mc1.20-pre1            |-- tweed4_data 1.2.1+mc1.20-pre1            |-- tweed4_data_hjson 1.1.1+mc1.20-pre1            |-- tweed4_tailor_coat 1.1.3+mc1.20-pre1            |-- tweed4_tailor_lang_json_descriptions 1.1.0+mc1.20-pre1            \-- tweed4_tailor_screen 1.1.4+mc1.20-pre1         - mru 0.2.1+1.20         - netherportalspread 7.5         - nochatreports 1.20.1-v2.2.2            |-- fabric-rendering-v1 3.0.6+b3afc78b82            \-- fabric-screen-api-v1 2.0.6+b3afc78b82         - nullscape 1.2.2         - nyfsspiders 2.1.1         - owo 0.11.1+1.20            \-- blue_endless_jankson 1.2.2         - patchouli 1.20.1-81-FABRIC            \-- fiber 0.23.0-2         - player-animator 1.0.2-rc1+1.20         - puzzleslib 8.0.24         - rare-ice 0.6.0         - replantingcrops 5.1         - riverredux 0.3.1         - shuffle 9.0.0+1.20.1         - sit 1.20-24         - snowrealmagic 9.0.1         - snowundertrees 1.1.0+1.20         - sound_physics_remastered 1.20.1-1.2.1         - starlight 1.1.2+fabric.dbc156f         - statement 4.2.8+1.14.4-1.20.1            |-- kanos_config 0.4.1+1.14.4-1.19.4            \-- statement_vanilla_compatibility 1.0.1+1.16.5-1.17         - terrablender 3.0.0.169         - transparent 8.0.1+1.20.1         - trinkets 3.7.1         - universalbonemeal 8.0.1         - vanillatweaks 1.5.69         - visualoverhaul 5.0.1            \-- midnightlib 1.4.1         - visualworkbench 8.0.0         - voicechat 1.20.1-2.4.24            \-- fabric-key-binding-api-v1 1.0.36+fb8d95da82         - wandering_collector 1.2.1+mc1.20-pre5            |-- coat 1.0.0-beta.20+mc1.20-pre1            |-- tweed4_annotated 1.3.1+mc1.20-pre1            |-- tweed4_base 1.7.1+mc1.20-pre1            |-- tweed4_data 1.2.1+mc1.20-pre1            |-- tweed4_data_hjson 1.1.1+mc1.20-pre1            |-- tweed4_tailor_coat 1.1.3+mc1.20-pre1            |-- tweed4_tailor_lang_json_descriptions 1.1.0+mc1.20-pre1            \-- tweed4_tailor_screen 1.1.4+mc1.20-pre1         - waterdripsound 1.19-0.3.2         - weaponmaster 3.0.5         - yet_another_config_lib_v3 3.1.1+1.20            |-- com_twelvemonkeys_common_common-image 3.10.0-SNAPSHOT            |-- com_twelvemonkeys_common_common-io 3.10.0-SNAPSHOT            |-- com_twelvemonkeys_common_common-lang 3.10.0-SNAPSHOT            |-- com_twelvemonkeys_imageio_imageio-core 3.10.0-SNAPSHOT            |-- com_twelvemonkeys_imageio_imageio-metadata 3.10.0-SNAPSHOT            \-- com_twelvemonkeys_imageio_imageio-webp 3.10.0-SNAPSHOT         - yosbr 0.1.2         - yungsapi 1.20-Fabric-4.0.1            \-- org_javassist_javassist 3.29.2-GA         - yungsbridges 1.20-Fabric-4.0.1         - yungsextras 1.20-Fabric-4.0.1 [15:07:30] [main/INFO]: Applying default options... (YOSBR) [15:07:30] [main/INFO]: SpongePowered MIXIN Subsystem Version=0.8.5 Source=file:/home/container/libraries/net/fabricmc/sponge-mixin/0.12.5+mixin.0.8.5/sponge-mixin-0.12.5+mixin.0.8.5.jar Service=Knot/Fabric Env=SERVER [15:07:30] [main/INFO]: Compatibility level set to JAVA_17 [15:07:31] [main/INFO]: Preloading Debugify [15:07:31] [main/INFO]: Loaded configuration file for Lithium: 115 options available, 0 override(s) found [15:07:31] [main/WARN]: Reference map 'mru-refmap.json' for mru.mixins.json could not be read. If this is a development environment you can ignore this message [15:07:31] [main/WARN]: Reference map 'yungsextras.refmap.json' for yungsextras.mixins.json could not be read. If this is a development environment you can ignore this message [15:07:31] [main/WARN]: Reference map 'yungsextras.refmap.json' for yungsextras_fabric.mixins.json could not be read. If this is a development environment you can ignore this message [15:07:32] [main/WARN]: Error loading class: fr/catcore/server/translations/api/resource/language/SystemDelegatedLanguage (java.lang.ClassNotFoundException: fr/catcore/server/translations/api/resource/language/SystemDelegatedLanguage) [15:07:32] [main/ERROR]: A mod crashed on startup! net.fabricmc.loader.impl.FormattedException: java.lang.RuntimeException: Could not execute entrypoint stage 'preLaunch' due to errors, provided by 'spectrelib'!         at net.fabricmc.loader.impl.FormattedException.ofLocalized(FormattedException.java:63) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:162) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:68) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.launch.knot.KnotServer.main(KnotServer.java:23) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.launch.server.FabricServerLauncher.main(FabricServerLauncher.java:69) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.installer.ServerLauncher.main(ServerLauncher.java:69) ~[server.jar:1.0.0] Caused by: java.lang.RuntimeException: Could not execute entrypoint stage 'preLaunch' due to errors, provided by 'spectrelib'!         at net.fabricmc.loader.impl.FabricLoaderImpl.lambda$invokeEntrypoints$2(FabricLoaderImpl.java:388) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.util.ExceptionUtil.gatherExceptions(ExceptionUtil.java:33) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.FabricLoaderImpl.invokeEntrypoints(FabricLoaderImpl.java:386) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:160) ~[fabric-loader-0.15.9.jar:?]         ... 4 more Caused by: java.lang.NoClassDefFoundError: net/fabricmc/loader/impl/entrypoint/EntrypointUtils         at com.illusivesoulworks.spectrelib.SpectrePreLaunchFabricMod.onPreLaunch(SpectrePreLaunchFabricMod.java:33) ~[spectrelib-0.13.12+1.20.1-205a4d5a45c9ac39.jar:?]         at net.fabricmc.loader.impl.FabricLoaderImpl.invokeEntrypoints(FabricLoaderImpl.java:384) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:160) ~[fabric-loader-0.15.9.jar:?]         ... 4 more Caused by: java.lang.ClassNotFoundException: net.fabricmc.loader.impl.entrypoint.EntrypointUtils         at jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) ~[?:?]         at java.lang.ClassLoader.loadClass(ClassLoader.java:525) ~[?:?]         at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.loadClass(KnotClassDelegate.java:226) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.launch.knot.KnotClassLoader.loadClass(KnotClassLoader.java:119) ~[fabric-loader-0.15.9.jar:?]         at java.lang.ClassLoader.loadClass(ClassLoader.java:525) ~[?:?]         at com.illusivesoulworks.spectrelib.SpectrePreLaunchFabricMod.onPreLaunch(SpectrePreLaunchFabricMod.java:33) ~[spectrelib-0.13.12+1.20.1-205a4d5a45c9ac39.jar:?]         at net.fabricmc.loader.impl.FabricLoaderImpl.invokeEntrypoints(FabricLoaderImpl.java:384) ~[fabric-loader-0.15.9.jar:?]         at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:160) ~[fabric-loader-0.15.9.jar:?]         ... 4 more container@pterodactyl~ Server marked as offline... [Pterodactyl Daemon]: ---------- Detected server process in a crashed state! ---------- [Pterodactyl Daemon]: Exit code: 1 [Pterodactyl Daemon]: Out of memory: false [Pterodactyl Daemon]: Aborting automatic restart, last crash occurred less than 60 seconds ago.
    • i cut it up into 3 parts   because it was too big apparentley  1:https://paste.ee/p/Y2stT     2https://paste.ee/p/c96dU         last part: 3:https://paste.ee/p/Sohay   
    • anytime i use it and hit submit it says page expired due to inactivitiy im not stoppoing for more then 30 sec
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.