Jake's RTP

Previous bug fix made ChunkyBorder a hard requirement. That is no longer the case. sorry.

JakesRTP now no longer crashes and burns when you use newer versions of ChunkyBorder -- in fact -- it even works with the newer versions! Note: This update of JakesRTP only works with Chunkyborder versions 1.0.63 and newer, and you can currently only get those through pop4959's dev builds.

Removed a bug where force disabling all plugin compatibility also kills this plugin. Whoops... sorry.

Support has been added for HuskTowns And I didn't even have to add it! The creator added it themselves! You can check it out here if you'd like to. Friendlier error messages This only applies to one specific error, the one that spams the console with constant unsafe location messages and stack traces. Now it only will do it once per wait period (like 15 min or so) instead of very very fast. Also, the /rtp-admin status [thing] command gives more info so if you come to the support discord asking for help, I can better assist with the info the command outputs. Bug fixs Some stuff relating to the high bound was not working as intended. Seeing as this bug existed for like ~8 months and has never been directly reported, I'm assuming it hasn't effected many people. Its fixed now though.

To additions, both I expect 90% of people to not bother with. 1 - Prefer sync vs async teleporting for rtp command: You can now specify if the the plugin prefers sync vs async teleporting for rtp's done through the command. Async is set by default (and is what the plugin always used), but now you can set it to sync if you so choose. To set it, you'll have to add these extra lines to your rtpSettings file. The tradeoff with sync vs async (in this specific case) is fast everything is, and who feels the lag (if it even exists at all). Sync is faster, but can produce lag felt by everyone. Async is slower, but does not generally cause noticable lag, and if it does, only the person loading the command feels it. This is also not important for most people to mess around with since it the timings only change by a couple hundred milliseconds, but hey, if you have a fast server and never experience lag, maybe set it to sync to make the plugin feel that much snappier. 2 - Permission to block specific new players from being rtp'd on first join: Ever want to have it so most people rtp on their first join of the server, but you have a few players who have never joined that you don't rtp'd when they join? Now you can! just give them the jakesrtp.nofirstjoinrtp permission before they are ever on the server!

The beginning of land claim style plugin support! I have decided that its finally about time I added support for land claiming plugins. Since I don't have enough time to do all the ones I want to do immediately, I'm going to post updates as I add support for new ones. This update includes support for GriefPrevention and WorldGuard! (yes, I know WorldGuard is not exactly land claims) So what does this support mean? For GriefPrevention: Players will NOT land in claimed land. Simple as that. For WorldGuard: A custom flag has been added to worldGuard called allow-jrtp-landing with the default value of true. If set to false, players will never land in that region. Config updates... Sorry that the config does not auto-update, I really hate the code I have for the config at the moment and plan on rewriting it all, but just not yet. Three options were added to the main config (config.yml), and they look like this: Code (YAML): #### land-claim-support # Should the plugin prevent people from landing in claimed land? # force-disable-all: If set to true, no support will ever be loaded. If false, then the other options are respected. # grief-prevention : Support for the GriefPrevention plugin. Players will not land in claims. land-claim-support: force-disable-all : false grief-prevention : true world-guard : true If you do not include this text in your config, the plugin will just imply the defaults, so you really only need to copy this if your want to change the settings. If you are unsure if your config is up-to-date, compare it with the version here. Future plugin support: My list of land claiming plugins to support currently looks like this: • [Done] GriefPrevention • [Done] WorldGuard • TownyAdvanced • GriefDefender • Lands • SaberFactions • FactionsUUID • CrashClaim I will slowly work to add all of these, and will likely add them in the order that they are here. If you want to vote on these (to get me to do one earlier) or if you want to suggest another, feel free to join my support discord. That said, I do not know how quickly these updates will come out. Final notes: Some bug fixes include: fixed an error with the low-bound check, added bamboo to the list of things to NOT spawn on, and fixed an issue with the LCF caching locations for teleports relative to a players position (these locations were never used, but could cause a big error). Some slight optimizations were made where made where the safe location checking happens. ...I think that's all

Two more bugs squashed: - Fixed low bound check. - Fixed faulty load-from behavior.

No (known) bugs in 1.17, added a few white-/black-listed blocks since there are now new blocks. Also, fixed the ChunkyBorder comparability!

Previously this plugin would crash when using the latest version of ChunkyBorder. It will no longer crash, instead if the version is not compatible it just won't make guarantees about the point being within the world border. A full fix will be available soon, probably with another update to make sure there are no bugs with 1.17

Oddly specific bug fix here: If a player is waiting for an rtp warmup and teleported to another dimension, they get stuck not being able to rtp again, and the server would spam an error in console. This has been fixed.

Hex colors in messages should work again

Fixed missing permission check

Thanks to Bowie!

Thanks to spigot user 4ubuntu, JakesRTP now has a Russian translation! No features were add, no need to update if you don't speak Russian.

Want rtp-on-death to respect respawn anchors? Now they do! When respawn anchors first came out, I had issues working with them so I just commented out the code and forgot about it. Today is the day that I added it back, and at someone's request, you can also configure if rtp-on-death respects them or not, independently from beds. I'm not too sure why this is useful, but apparently it can be! Settings file change. Since the config isn't auto-updating yet, the new line will only show up for people downloading this plugin for the first time, but if you use rtp-on-death, are updating from an older version of this plugin, and explicitly want to set respect-anchors to false you can still easily do it by just adding one line to config.yml like so Code (YAML): rtp-on-death: enabled : false settings : 'default-settings' respect-beds : true respect-anchors : true # Defaults to true, add this line and set to false to modify. require-permission : true Side notes: As far as I remember, there are no sneaky fixes this time. Oh, and this still works perfectly fine on pre-1.17 servers (since they don't have respawn anchors)

I've been seeing issues where other plugins override the effect this plugin has on first joins and on deaths, so now (if your setting has this enabled) the listeners will be on high priority, giving them the best chance of being the last one to act on the event. If somehow the locations are changed again, you will get a nice blurb in console telling you another plugin modified the event, and who the potential perpetrators are.

Fixed small bug existed where reloading the plugin didn't properly reload the rtp-on-death settings.

Small bug fixes related to rtpSettings files that use the load-from setting

replaced a < with a <=

First, everything changed in this update is additive. This update will not make any of your old configs break or anything, this just adds a new way to work with more configs. ******** Changes: Now you can make a rtpSettings file take values from another file. The general idea of this is that if you want two rtpSettings where the only difference is the [any-option-what-at-all], you can make the second rtpSettings file super easily. How To Use If you want another settings file to inherit all unset settings from another file, simply add a line that says load-from: [settings-name] to it. In the new file, you can include as many or as few options as you would like. For any options you do not include, the value will be taken from the settings defined in load-for, but any setting you include will take effect. Example For this explanation, lets assume that you still have an rtpSettings file named default-settings.yml and that this settings file is properly configured. Now lets say that you want to make another rtpSettings file where everything is identical to default-settings.yml, except the cool-down is 555 seconds and the then-execute command contains a lot of "Q"s. To do this, all you would need to do is make a new file (named whatever you would like, but for this example it will be named testy.yml) and make it look something like this: Code (YAML): load-from : default-settings enabled : true cooldown : 555 then-execute : - 'tellraw %PLAYER% {"text":"You have been QQQQQQQQQ %LOCATION% in %WORLD%!"}' So there are two lines that are required for this, the ` load-from line and the enabled line. The enabled line is always required for an rtpSettings file to be loaded, but the load-from line is only used to grab values from another config. If the load-from line is present, any configurable option in the current file that is not present will get the same value as that in the named settings. So for this example, since we are loading from default-settings, the warm-up time, for example, of testy will be the same as default-settings`. More words The example I made up for the last section is really a weird example to go with so here are some more. Say you want to have 3 rtpSettings where the only difference is the distribution, all you would have to do is configure the main one, then make two more that inherit (using load-from) from the first, and set their distribution. With this new way of configuring, two of the files would only have to be 2 lines long, and if you ever make changes to the first one, it will carry over Sneaky Bug Fixes In v0.12, the message displayed when someone used /rtp on a settings that costed in-game money was not properly parsed. This has been fixed.

New optional feature: Cost to use /RTP I've been wanting to add economy support for a while now, and I've got the most basic form in. You can now set a cost in an rtpSettings file, though it will only charge the player if they use the /rtp command (and not if they are teleported through /forcertp. This will change in the future. How to use: Much like the last update, if you already have your rtpSettings files you will have to add a new line like such: Code (YAML): # This only is used if you have an economy plugin. # If you do have an economy plugin and you want to disable this feature, set cost to 0. # Note: Cost can be a floating point value (ex: 6.67) cost : 0.0 # Set the cost here! Obviously you don't need the comments, but that is how it is written in the default config file. Also, if this is the first version of the plugin you download, the line will already be there. Additional notes: There are now four more text lines that have been added to the language file and as always you can overwrite these messages in language-settings.yml.

A new (optional) feature has been added: Warm-ups! Now if you want a player to have to wait a few seconds before getting teleported, you can. How to use: Since the config is not auto-updating (yet), to use the warmup, you will have to manuall add the following 4 lines to your rtpSettings file(s): Code (YAML): warmup: time : 0 # In seconds, how long is the warm-up? Set to 0 to disable. cancel-on-move : true count-down : true If you are unsure as to whether you correctly added the lines or not, check to see what the default config looks like here Additional notes: There are now three more text lines that have been added to the language file and as always you can overwrite these messages in language-settings.yml. There are also permission nodes for avoiding the warm-up. There is one generic one for avoiding all, and a more specific option for avoiding the warmup for a named setting. Please note that anyone who is an OP on the server gets to avoid warm-ups by default so if you can't get warm-ups working immediately make sure that's not the issue. Sneaky bug fixes: Players can no longer get teleported into water if there is kelp in it.

If rtp-on-death or rtp-on-first-join was enabled, the randomTeleporter would have trouble loading with the newest config. This has been fixed.

If an rtpSetting can't get loaded, you now will always know the last successful thing that was loaded which can very heavily imply what was wrong (if there is no explicit message, its the line after the last successful setting)

Somewhere around v0.10 a bug was introduced that caused a very quickly reoccurring issue with the LCF. That has been resolved. For some more specifics, the issue was that if the landing world was not in the call from worlds, this error would get spammed in console even though that was fully intended functionality. Code (Text): [J-RTP] An exception has occurred that should be impossible to occur. Please report this. biz.donvi.jakesRTP.JrtpBaseException$NotPermittedException: RTP is not enabled in this world. ~ECG

Thanks to Amgelo we now have a spanish translation!

The location cache filler was a bit too excited to shut itself down.

Title says all. There was an issue with checking locations async in minecraft 1.12.2, and now the issue seems to be gone.

I just don't know which version to compile to so 8 it is

Now you can use automatically generated distributions with world-borders in default Bukkit and with ChunkyBorder installed. Example: You use ChunkyBorder, you set the border to a star with some arbitrary size. If you set the distribution in your rtpSettings file to world-border then the distribution will be large enough to cover the area. Oh, and since there is support for border regions aswell, you will never have anyone get teleported outside the world border, even if it is a ridiculous shape like a star.

It has been a while since I've had the time to work on my personal projects, but now that I have free time again, there will be updates again. The first major change is how the config is done, instead of being one large file, its split into 3 sections. There is the global/static settings (in config.yml). Then the profiles/rtpSettings which are now in their own folder. Each file in the folder is a different profile/rtpSettings, and each profile is linked to a distribution. Like profiles, distributions are also in their own folder, and each file is a unique distribution. Distributions can also be used by multiple profiles, so if you want the same simple thing but say for 3 different worlds, you need 3 profiles but only one distribution. In the future, I plan on also adding commands to modify any of the config files, but not yet. A new distribution shape has been added: the rectangle! I know that doesn't seem like much (especially because its so simple), but somehow I managed to not include it before, so now we have it. It also supports having a rectangular gap inside it at any arbitrary size and location, as long as the gap is fully within the main area. Later, I will also add ellipses. One of my favorite additions over the last few days has been the start of world-border compatibility. I've only just started this one, but its something that has been asked for a lot. Currently, support for world borders only goes to make sure no one is ever teleported outside a world border, but soon I plan on adding custom distributions that perfectly fit the world borders. Also, its not just vanilla world borders, I've also got support for ChunkyBorder! OH and I added an Icelandic translation thanks to my friend Arn!

If given the jakesrtp.usebyname permission, players can type a name of a rtpConfig (they show up in tab complete). This requires the player to have permission to use /rtp, permission to use rtp-by-name, and if the settings require a specific permission, it needs that too. .SpoilerTarget">Spoiler: new perm Code (YAML): jakesrtp.usebyname: description : 'Allows players to give a rtpSettings name after rtp as such : "/rtp <settingsName>"' default : false

There is now a new file called "language-settings.yml" that allows you to choose the language that all the messages will be in (currently only English, please feel free to contribute), and then the ability to overwrite existing messages with your own custom ones. This supports line breaks, legacy colors, and hex codes! Time to have good looking messages! Woo!

Replaced a \ with a /.

You can now automatically have commands run when someone rtps. When you configure an rtpSettings section, you can write commands under then-execute like so: Code (YAML): then-execute : - 'tellraw %PLAYER% {"text":"You have been teleported to %LOCATION% in %WORLD%!"}' This could be useful if you want to give players a title on screen, sound effects, or potion effects when they teleport. .SpoilerTarget">Spoiler: Avaliable Placeholders Code (Text): %player% The players minecraft name %player_display_name% The players 'display-name' or nickname %location% The location the player landed, formatted like this: world (867, 53, -9) %world% The world the player landed in, formatted like this: world %x% or %y% or %z% Each of these will give its corresponding value, formatted like this: 86 %location_old% The location of the player before they moved. %world_old% The world the player was in before they are moved. %x_old% or %y_old% or %z_old% The x or y or z location of the player before they were moved.

This is a pretty minor fix but it will stop some error messages that would commonly occur within the first few seconds of the plugin starting. Now, if there is no lag, the location-caching-thread will start up one second after the plugin loads, but if there is lag, it will wait for the average tick time to be under 55ms for 5 seconds. In testing, this stopped the first few calls to cache a random location from timing out or failing, and had no noticeable effect otherwise.

Since I plan on allowing players to rtp using different rtpSettings (configs/worlds), I split up the player command and the admin override command into two separate commands. Also, I found (and fixed) a small bug that was responsible for the async locations taking way too long to find. Now the rtp-location-cache will fill basically instantly (assuming you have between-time set to 0 and run paper!) so you won't need to worry about it draining in regular use.

Summery: This should now work on any version between 1.12.2 & 1.16.1 inclusive. All future releases should as well. Now I haven't tested all versions and subversion (because running that many different version servers and clients takes a lot of time) but I have added a 1.12.2 patch that gets applied when needed, and allows the plugin to work as if it was intended to be on 1.12.2. Since 1.13 and up are a lot closer to each other, not nearly as much was needed to do to make them work, and I didn't test everything, so let me know if there are any issues. Speaking of issues, there is an error that commonly happens on shutdown, and while I do intend to fix it, its worth noting that it causes no issues.

You can now rtp in the nether! Its been a while since I started working on this update, so there may be other changes that I forgot about. Speaking of, you can now set the highest y value you can be teleported to, and the method of checking (start from top, or start from middle). That's all.

Changes: • Added force-destination-world to the config. If set to true, players will always be rtp'd into the given world regardless of which world they run the command from (as long as the world they ran it from has rtp-enabled) Fixes • Added multiverse as a soft-depend so that multiverse worlds can have rtp enabled without needing to reload the plugin • Plugin has a whole lot less of a chance of causing an infinite block when reloading. (It used to randomly get stuck when reload was run. Now, if it gets stuck at all, it should be no more than 5-10 seconds) • Added missing return statement, making async location checking ~5 times faster. This will not be very noticeable though as async wait times are not felt in the main thread. Also this was an incredibly stupid bug that I'm embarrassed I left in the code, so lets just not talk about it. Its gone now. Fixed.

Instead of all the console messages being 3 lines long, they are now 1 line! Also, you can enable or disable the logging of specific features. I prefer leaving all of the log messages on, but turned rtp-fpr-queue off by default, as it can send a lot of messages.

Even though this update adds very few settings, it is probably the biggest single update to this plugin so far! Don't want to read the whole update? Watch this video showing off the new speed of the plugin instead. Here's the more wordy update for those interested: Now Supporting Location Caching Previously, J-RTP would find the location at the time the command is run. If it took 800ms to load a chunk, and 200ms to find a safe location in that chunk, the server is waiting a full 1000 before the next tick gets processed (more about that later). That means running the command to getting teleported could at times take over a whole second. To fix this, I have added location caching. Basically, the server will "run" the rtp command at startup and find a few safe locations to teleport players to. When the player runs the rtp command, they instantly get teleported to the location, avoiding all the lag. That doesn't fix the whole problem though, since loading chunks could still take upwards of 800ms, and thats why this plugin now uses PaperLib... Now uses PaperLib for async chunk loading. (And I also made as much of my run async as I logically should have) getChunkAtAsync() Did you ever hate having the whole server lag when one person runs /rtp? That lag is gone now, hidden away in an async thread where it won't bother anyone. I may joke, but even though the process still happens, since it is happening outside the main thread, the server as a whole will not feel any lag. Take this as a reminder to use paper over spigot though. I may have moved a lot of the processing of my own plugin into its own thread, and while the performance increase from that will be noticeable, most of the performance increase comes from methods that only work using Paper.

Fixed a tiny bug

Config has been changed! Make sure to edit the new config to have the settings that you want! Added an option to RTP a player when they first join. To use the feature, simply enable it in the config, and state the rtp config to use, and the specific world to teleport the player in. API version changed to 1.16, if you want to use this plugin on 1.15, download version 0.4

Everything works the same.

It was tested 200 times, not a single bad result. Going to keep testing though.

Completely redid the way that a valid safe location is found when starting with the initial location. The new algorithm can quickly look around the initial random location to find a safe location, and when chunks are already loaded, it generally won't spend over a millisecond on it. Also, the new algorithm preserves more of the uniform randomness that the random distribution methods bring.

Made the permission nodes conform to conventions. Properly listed permission node jakesrtp.admin in plugin.yml Added tab-complete to /rtp-admin