search

CyberdyneCC / Thermos

(NO LONGER DEVELOPED) Minecraft Forge Server Software implementing the Spigot/Bukkit API, formerly known as Cauldron/MCPC
http://cyberdynecc.github.io/Thermos/
GNU General Public License v3.0
258 stars 184 forks source link

allowNetherPortalBesidesOverworld should be true by default #362

Closed WildBamaBoy closed 8 years ago

WildBamaBoy commented 8 years ago

Server Log: N/A

FML Log(s): N/A

Explanation of issue: allowNetherPortalBesidesOverworld is false by default, conflicting with expected behavior from plugins like Multiverse. Ex. creating multiple worlds each with their own version of the Nether. Portals can only be created on the server's selected main world when this option is set to false.

This option should be true by default to prevent conflicting with these plugins.

How to recreate this issue: Built-in functionality.

Modpack Name: N/A

Mods Installed: N/A

Plugins Installed: Multiverse-Core

Warmroast Report: N/A

Thermos Version: 1.7.10-1614.56

Forge Version: 1614

bookerthegeek commented 8 years ago

This is a simple configuration change a competent admin should know to switch if adding other worlds with plugins. The default option is fine.

WildBamaBoy commented 8 years ago

That's not really the issue. Of course anyone running a server should know how to change a config option. But without opening the config, an admin wouldn't even know that this option is present. Their first thought would likely be to look for conflicting plugins (as was mine).

At the very least, a notification that this option is preventing portals from being created should be added.

Time6628 commented 8 years ago

I'm pretty sure multiverse made their own plugin to link nether and end portals to different worlds.

bookerthegeek commented 8 years ago

So....

Thermos = Plugin (technically)

Good job. You found a conflicting configuration options. This does not mean that we need to change the default.

The default works for over 90% of users, and that is what defaults are for. Not to tell you how to do your job, but you should make sure to test things, and make sure you understand them before using. (RTFM)

Sorry that you had issues with this, and I am glad it was an easy fix. Don't take my sarcasm personally. Or do, up to you.

WildBamaBoy commented 8 years ago

I don't believe I explained the issue well enough:

With the current default option, servers running multiple worlds will only be able to create Nether portals in the default world defined in server.properties.

Given my case - I'm running two "Normal"/"Overworld" type worlds that would be linked to the same Nether. It's a very common configuration, even more so having each world with a different nether world attached. I could create a portal (as in actually lighting the obsidian frame with flint and steel) in the default world, but not the second world.

I wouldn't be able to link the secondary portal anywhere else as I could not create it to begin with.

Given the popularity of this type of configuration, and Multiverse-Core/Multiverse-NetherPortals, I think working for 90% of everyone is an absurdly high estimate, especially considering most wouldn't know the option is there as I stated previously.

If it's best for most to have the option at its current default, it would be a good idea to make it more obvious that Thermos is blocking the creation of the portal.

sameer commented 8 years ago

If we add a notification, it might spam the console for those who don't want it.

When you use a software for the first time, it is commonly accepted that the user will read through the configuration options to understand what is available and what needs to be changed.

This option was not implemented by Time or I but rather by Prototik. I believe there was a legitimate reason why this was done (something to do with portal destination conflicts) but I'm not sure.

Thank you for posting this issue, but if we change the default, it will require us to notify everyone of the change, which is definitely not an easy feat. Once a default is created, we cannot really change it without causing mass havoc for people who expect it to remain the same.

Time6628 commented 8 years ago

Here's the issue https://gitlab.prok.pw/KCauldron/KCauldron/issues/58 and the commit https://gitlab.prok.pw/KCauldron/KCauldron/commit/712aab7c57e8fe5fbc5a8317bb7319c8b63f71f2

WildBamaBoy commented 8 years ago

Ah okay, I wasn't aware it was actually from KCauldron. My experience beyond Cauldron before the takedown is hugely limited, and I expected things to work more or less the same. I was previously thinking about a notification in chat for the one lighting the portal, but I see how that would be problematic now.

Thanks for clearing this up.

sameer commented 8 years ago

Thank you for understanding. :smiley: