Bukkit

@AT_HE

Haha... yes, yes it should. I'll update that now.

@AT_HE

Hi again,

I'll respond to both of your posts with one to make it easier.

So, the nether fence thing sounds like a bug. I never really tested what happens when the door material and the wall material are the same thing. I'll try to look into this soon. I can't think of a great way to make it work without code changes, sadly.

The rest of your ideas are definitely interesting, and I'd like to implement a few.

• Wait for the user to stop moving to warp
  • This seems doable, though is lower priority in my book.
• Changes to /portal list
  • Not a bad idea. I'm not sure whether I want to change the default behavior, but allowing you to list your own portals would be nice. I'll consider it.
• it should shows a tooltip with destination when you look at some portal
  • You mentioned this in your comment on the site. I've added a feature to look into this on the ticket tracker.
• /portal list shows the owner of the destination portal if is not yours
  • Not a bad idea - as long as there is enough room I'll probably do this at some point
• /you could view any portal info with /portal info myPortal
  • I'm pretty sure you actually can do this. It's in the readme file. If not, it should exist and I'll get it back in there.
• what is the purpose of portals have an owner? you still can change portal's name and dest (could be organize in /portal list)
  • Without permissions, it just shows you who created them. With permissions, you can only mess with portals that you own.

As far as dynmap goes, you should be able to do this now. I know it has been done in the past, but never looked into exactly how. In the config file, you should see an option called "autoexport" - this will regularly export a list of all portals, their locations, etc into a comma-separated txt file in the travelportals directory. I'm pretty sure the people who did it were able to use this.

Finally, permissions. You should be able to set up whatever plugin you are using to give different permissions to users based on the world that they are in. (If you don't have one, I've had success using http://dev.bukkit.org/bukkit-plugins/permbukkit/ in the past. See here for sample configuration: https://github.com/SpaceManiac/PermissionsBukkit)

If you give users in world "world" travelportals.classicuser and users in all other worlds travelportals.nopermission, you should achieve what you want. Something like this:

groups:
    default:
        worlds:
            creative:
              - travelportals.classicuser: true
            nether:
              - travelportals.nopermission: true

Unfortunately, I've had very little time to attend to my bukkit stuff lately. I don't think I'll get to this very quickly. (Life and all that) I'd be surprised if I find time in the next week or two. I won't forget about it, though.

@AT_HE

Hello,

You should be able to do this with the built-in permissions support. If you look in the configuration file, you should see an option to enable permissions. From there, just block travelportals.*for all players in all worlds you do not want them to work in.

Your first configuration option (inter-world portals) is interesting. I hadn't thought of that before, and would be a useful option. I'll add that to the bug tracker. The second one should really just be handled by permissions, however.

@Nosxxx

Are you absolutely sure that you are on 2.2.6? BukkitDev takes some time for files to be approved; if you downloaded from BukkitDev right when I commented you might have gotten 2.2.5 by mistake.

I just re-downloaded the latest release, loaded it up on my test server and tried it via the console and it worked as expected.

>portal deleteworld myworld
13:41:02 [INFO] This will irreversibly delete all portals linked to "myworld"!
13:41:02 [INFO] Are you sure you want to do this?
13:41:02 [INFO] Type /portal deleteworld myworld confirm  to delete.
>portal deleteworld myworld confirm
13:41:05 [INFO] All portals linked to "myworld" have been deleted.
>

If you're sure that you have 2.2.6, let me know and I can try to figure out what is going on. Please upload your config file to http://dev.bukkit.org/paste/ or something similar too if this is the case.

(I'm really hoping you're on the wrong version though, because I am really not sure how that could happen otherwise)

@Nosxxx

Ugh, yeah... your first version of the comment was right. For now you have two options- do it from the server console (the plugin essentially ignores permissions there) or give yourself travelportals.* temporarily to get access to everything. (Admittedly, this is what I did during testing)

I'll try to get a corrected version out soon.. I think I'll take a closer look at permissions in general. I saw some weirdness in there while I was making this release; now is as good of a time as any.

Thanks for pointing it out

@Nosxxx

Hey again,

I just tossed up a new version. It still needs to go through the approval process, but should be available soon. It has the deleteworld command you need. If you don't feel like waiting, I have it mirrored on my site here.

Enjoy!

Chris

@Nosxxx

Hey,

So, I'm in full agreement. You're able to rename all instances of a word, but I never gave a good way to delete them.

It should be pretty quick to write up, but I'm a bit strapped for time lately. I should be able to get it in by late Thursday worst case. I'll see what I can do.

Thanks for the feedback!

Chris

@IamHD

Hm.. I hadn't considered putting it into the console before. That feature was more meant to be used with mapping tools, etc so you could show your portals on a map. It wouldn't be too hard to give an option, but it seems a little awkward to do it that way. (I'm afraid of confusing users by printing out 500 lines like that into the server console) What benefit would putting it into the console have?

As far as not having it in help, that surprises me. Must have been an oversight in my part. I know it's in readme.txt... but no one really reads that :p I'll get that in there now.

I think I'll also add an import command. It'll probably be just as rudimentary as the export (just a file inside the TravelPortals folder); someone will probably find a use for it though.

Sorry for hitting you with that much information at once by the way. When someone asks a question that I end up reading as why, I tend to give a very verbose answer.

</book>

@IamHD

Hey,

So, I have to disagree with you about using a serialized file to store portals. Yes, your situation is unfortunate, but it is a rare one that should really only occur in the case that your server is forcibly shut down (read: power failure or similar) while portals are being saved. In addition, the plugin will warn you in the server console on the next startup, and you can recover your portals using the automatically saved backups in this case.

If that happens, the last few copies of the serialized portals file should be stored in your configuration folder. If yours happened long ago, the backups will probably all have the same problem though, so the point may be moot.The times I've seen this problem all portals stopped working immediately, and some console output came with it. It'd also create a new storage file, assuming the file was completely beyond repair.

As far as storage goes, I think a serialized file is just fine. Yes, it can fail catastrophically, but this is exceedingly rare. This is the 3rd or 4th case I've seen ever.. and this has been around since the hmod days. Thousands of people have set this up and used it without ever running across this. With the backups, recovery is completely possible as well. This is the first complete failure I've heard of since I implemented the backup system.

Giving sqlite as an option might be nice, but I don't really believe it is necessary. It really wouldn't offer any advantages beyond slightly better recovery in your exact situation. (And possibly better performance if you have extremely high numbers of portals) It would add a little extra bloat though, and at this point require a bit of rewriting. Even then, if you crashed while saving the data to the sqlite database file, recovery would be pretty ugly. I'd argue that it might be harder than just restoring an automatic backup like you do today.

As for why I made the decision originally, when I initially wrote this plugin for bukkit, it was not as far along as it is now. I don't believe SQLite support in Bukkit was nearly as far along as it is now. (Multiple libraries, etc.) It wasn't commonplace to have a database system at all back then. In addition, the plugin stores very little information about each portal, to the point that it makes the most sense to keep it all in memory. It just didn't make much sense to implement a full database layer for the small amount of data being managed at that time.

-

All of that said, I'd be willing to take a look at your file and see what I can pull out. Just upload TravelPortals.ser somewhere and I'll see if I can make any sense of it. If you want to see what's stored, you can also try doing /portal export as an op; that will generate a list of all portals in plain text in a file named travelportals.txt. (Should be in the plugins/TravelPortals folder, but it's been a while since I've used this)

I suspect you're probably somewhat hosed... in all cases I've seen, we'll warn you in the console, then create a new file for portals if a new portal is created. You'd still have a few backups to work off of, but those would be overwritten as new portals were created.

I'm terribly sorry for your bad experience with the plugin; I wish you better luck in the future, should you continue to use it.

Chris

@luridftw32

Wow, you beat me to the next steps. Yeah, I suspect it has something to do with your config. If you get stuck, please paste your config.yml file to pastebin or something like it and I'll take a look later today.