Unwanted Spawn Strategy
SXRWahrheit opened this issue ยท 13 comments
Log:
[12:11:09] [Server thread/INFO]: [HomeSpawnPlus] Strategy evaluation started, type=onspawncommand player={BukkitPlayer:Wahrheit}
[12:11:09] [Server thread/INFO]: [HomeSpawnPlus](strategy spawnDefaultWorld) result is [loc={training,0,0,0}, home=null, spawn={null}]
[12:11:09] [Server thread/INFO]: [HomeSpawnPlus] Evaluation chain complete, result = [loc={training,0,0,0}, home=null, spawn={null}]
[12:11:09] [Server thread/INFO]: [HomeSpawnPlus] result changed to safeLocation, new result = [loc={training,0,65,0}, home=null, spawn={null}]
[12:11:09] [Server thread/INFO]: [HomeSpawnPlus] Strategy evaluation started, type=crossworldteleport player={BukkitPlayer:Wahrheit}
[12:11:09] [Server thread/INFO]: [HomeSpawnPlus](strategy default) result is [loc={null}, home=null, spawn={null}]
[12:11:09] [Server thread/INFO]: [HomeSpawnPlus] Evaluation chain complete, result = explicit default
[12:11:09] [Server thread/INFO]: [HomeSpawnPlus] Strategy evaluation started, type=onteleportobserve player={BukkitPlayer:Wahrheit}
Config:
events:
strategies to use when player is joining the game
onJoin:
- spawnNewPlayer
- default
strategies to use when player is respawning after a death
onDeath:
- spawnDefaultWorld
strategies to use when player types "/spawn"
onSpawnCommand:
- spawnDefaultWorld
strategies to use when player types "/groupspawn"
onGroupSpawnCommand:
- spawnGroup
strategies to use when player types "/home"
onHomeCommand:
- homeMultiWorld
world:
infinitus:
onDeath:
- spawnGroupSpecificWorld:heavens
- homeLocalWorld
- spawnNamedSpawn:Godstower
- spawnDefaultWorld
This should be taking me to the spawn on prosperus. No idea why it's preferring the training world.
OK sounds like unintended change of behavior between 1.7 and 2.0 (bug), which I'm definitely interested in reproducing and fixing. Can you pastebin your HSP config.yml and tell me what it is you are doing that you expect to be sending you to the prosperus spawn? ie. if it's /spawn being used and the player has a certain permission or is on a certain world, etc.
Once I have the information, I'll setup a local test scenario to reproduce the issue and once I can reproduce it, it's likely easy for me to gather all the information I need to fix it.
/spawn should always go to the main spawn in Prosperus.
I've tested this locally on "CraftBukkit version git-Bukkit-1.7.9-R0.1-10-g8688bd4-b3092jnks" as well as "CraftBukkit version git-Spigot-"7c1eafc" (MC: 1.8)" using the latest HSP 2.0 build 571.
I setup a new world "dune" and I put a default spawn on there by running "/setspawn". I confirmed the spawn existed and was flagged as default by using /spawnlist:
>spawnlist
[16:42:43 INFO]: Spawn list for all worlds:
[16:42:43 INFO]: id: 1 world,80,64,256 (world default)
[16:42:43 INFO]: id: 2 dune,-144,70,258 (world default)
I then setup a strategy similar to yours:
onSpawnCommand:
- spawnSpecificWorld:dune
- spawnLocalWorld
- spawnDefaultWorld
And upon typing "/spawn" I'm sent to the spawn on dune as I would expect.
So I'm unable to reproduce this bug locally. Can you confirm that /spawnlist shows the that Prosperus has a single default spawn set?
Your original verboseLoggingStrategy output is very terse and shows nothing of running the onSpawnCommand strategy chain. Not sure what's going on here.. Do you have another plugin that might be eating /spawn? Maybe it's a YML formatting issue? I can only formulate guesses since I've replicated the scenario provided but I get different behavior than you, so I'm not sure what's happening that is unique to your environment and so far the log messages don't give me any extra clues.
One last idea, perhaps Prosperus is case-sensitive? Are you using Multiverse? what does /mvlist show?
As best I can tell from the information provided, the command being run is "/spawn", for which I believe the event chain being executed is onSpawnCommand. Is your default world the training world? Try adjusting the onSpawnCommand chain to see if you get different results.
Can you describe what is happening and what you expect to be happening? Also, did this work on 1.7 and now it's not working under 2.0?
Using spawnSpecificWorld:prosperus works, but was not necessary before. I am now using 2.0, reverting to 1.7 changes back to intended (spawn at prosperus spawn) behavior.
While we're working on spawn strategies, onHomeCommand in prosperus_nether is sending people to their homes in prosperus. (Also, on that note, all worlds are lowercase).
[16:26:16 INFO]: [HomeSpawnPlus] Strategy evaluation started, type=onhomecommand player={BukkitPlayer:v0nj3di}
[16:26:16 INFO]: [HomeSpawnPlus](strategy homeMultiWorld) result is [loc={prosperus,-2830,107,2578}, home={id=2720,name=null,playerName=v0nj3di,world=prosperus,x=-2829.5,y=107,z=2578.5,yaw=264.61,pitch=41.55,bedHome=false,defaultHome=true}, spawn={null}]
[16:26:16 INFO]: [HomeSpawnPlus] Evaluation chain complete, result = [loc={prosperus,-2830,107,2578}, home={id=2720,name=null,playerName=v0nj3di,world=prosperus,x=-2829.5,y=107,z=2578.5,yaw=264.61,pitch=41.55,bedHome=false,defaultHome=true}, spawn={null}]
[16:26:16 INFO]: [HomeSpawnPlus] result changed to safeLocation, new result = [loc={prosperus,-2830,108,2578}, home={id=2720,name=null,playerName=v0nj3di,world=prosperus,x=-2829.5,y=107,z=2578.5,yaw=264.61,pitch=41.55,bedHome=false,defaultHome=true}, spawn={null}]
[16:26:21 INFO]: [HomeSpawnPlus] Strategy evaluation started, type=crossworldteleport player={BukkitPlayer:v0nj3di}
[16:26:21 INFO]: [HomeSpawnPlus](strategy default) result is [loc={null}, home=null, spawn={null}]
[16:26:21 INFO]: [HomeSpawnPlus] Evaluation chain complete, result = explicit default
[16:26:21 INFO]: [HomeSpawnPlus] Strategy evaluation started, type=onteleportobserve player={BukkitPlayer:v0nj3di}
Your latest comment regarding prosperus_nether and prosperus is most likely due to the HSP-2.0 feature of associated worlds. HSP's origins are rooted in the fact that I wanted Vanilla Minecraft behavior on my server at the time and Bukkit with Multiworlds was not giving me that (this was MC beta days).
But that philosophy carries on - people should be able to get Vanilla spawn behavior if they want from HSP, and in fact I try to aim for HSP's default configuration to be just that. I noticed at some point that in Vanilla, if you died in the nether, you got sent back to your home on the main world. And I realized in 1.7, this wasn't possible without a lot of cumbersome per-world rules that an admin would have to hand-maintain for every world.
So for 2.0, I created a concept of "associatedWorlds", enabled by default, whereby _nether and _the_end worlds have some association to their base world and HSP default strategies (like homeLocalWorld) will respect that. In the event that a player has a home on nether and the base world, they should be sent to the one on nether. If they don't have one on nether, they will go to the base world home, just like in vanilla.
If you don't like that behavior, you can disable associated worlds in your core.yml.
It also occurs to me it might be better to have left homeLocalWorld alone and to have made a different strategy, homeAssociatedWorld and just make that one the default for new installations. Then both configurations would be possible, on different worlds, rather than a single global config one way or another. Your thoughts would be appreciated if you have any feedback on that.
Oh. It looks like I did exactly what I thought I should have: there IS a homeAssociatedWorld strategy.
Though some research into the core Engine shows I modified it to change even normal strategies, and worse I don't see any code that respects the associatedWorlds setting in the core config. I think this was the last feature I implemented in the 2.0-base before I took a break and it doesn't look like I finished it out completely. I will give this some more thought and probably issue some code updates soon to make it so admins have more choice on how associatedWorlds operate, if they want it at all.
I am finally getting around to updating; pardon my delinquency, I got accepted to UChicago Law and have been making the appropriate preparations as a result. :)
Congrats on being accepted!
As for this issue, this is a long thread at this point and I think we've fixed a few things along the way and run into others. If you get a chance to test, if you could re-post a specific issue (feel free to open other tickets also), that will give me the best chance of reproducing and solving any issues.
Closing this issue to clean up open issues, as I think the original problem here was fixed but a new problem was reported somewhere along the thread. If a new problem is still an open issue, please open a new bug report with logs and instructions on how to reproduce and that will greatly help me in tracking down and fixing the problem.