Bukkit

@zonedabone

Ticket 29 updated with a wall of SEVERE errors -.- Reverting to a 'stable' build as I'm fairly certain the untested build contains a memory leak.

[Edit] ...and once again, on the last released build, signs.dat size cut in half, half the signs not working.

I was just thinking again, could you make a commandblock activate on interaction with a portal block like walking through a nether portal?

@zonedabone

It's been running on the server all day, no crashes thankfully, haha.

Signs.dat was reset once again, however I can't tell if it was done before or after I uploaded the untested jar.

I'm keeping an eye on it now, and will keep you posted.

Yes I did. I also looked at the working file i manually saved previously. The difference between the files seems on the face of it to be extra stuff on the end of the broken version (everything after "false"); up to there they seem the same. But of course I may be missing something.

Yes, this version seems worse. Automated saving does not seem to work and trying to manually save now causes and "internal error" with this in the log:

2012-05-09 18:13:54 [SEVERE] null
org.bukkit.command.CommandException: Unhandled exception executing command 'cmds' in plugin CommandSigns v1.7.3
at org.bukkit.command.PluginCommand.execute(PluginCommand.java:42)
at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:166)
at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:473)
at net.minecraft.server.NetServerHandler.handleCommand(NetServerHandler.java:821)
at net.minecraft.server.NetServerHandler.chat(NetServerHandler.java:781)
at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:764)
at net.minecraft.server.Packet3Chat.handle(Packet3Chat.java:34)
at net.minecraft.server.NetworkManager.b(NetworkManager.java:229)
at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:113)
at net.minecraft.server.NetworkListenThread.a(NetworkListenThread.java:78)
at net.minecraft.server.MinecraftServer.w(MinecraftServer.java:551)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:449)
at net.minecraft.server.ThreadServerApplication.run(SourceFile:492)
Caused by: java.lang.NullPointerException
at org.zonedabone.commandsigns.CommandSigns.saveFile(CommandSigns.java:306)
at org.zonedabone.commandsigns.CommandSignsCommand.onCommand(CommandSignsCommand.java:146)
at org.bukkit.command.PluginCommand.execute(PluginCommand.java:40)
... 12 more

@zonedabone

Bravely running it on our main server right now, will check in the morning and let you know if there were any issues.

Cheers

@prizna123

I'm using GroupManager with a similar situation, perhaps what I've got setup is similar.

Give the guest group the permission "usesign.guest"

For your commandsign, use the following commands (one of many possible solutions)...

/cmds line0 @guest
/cmds line1 /^manuadd <NAME> [rank]

line0 - @ checks the group's name (only 'guests' will be able to use it). Replace 'guest' with your guest group's name. line1 - Substitute 'manuadd' with the command to change the rank of a user. Leave <NAME> as it is the player's name (the one who clicks it) and finally replace [rank] with the rank you'd like the guest to be promoted to upon click.

Hopefully this works for you

I am using permissionsEx and want to allow players of a guest group to upgrade their ranks with command signs, but can't get it working, what permissions will I need to add to the guest group to allow them to do this? I have tried giving them commandsigns.use.super but it doesnt seem to work.

thanks,

@Jong1

I've ran into this issue three times, on two separate servers (main & dev).

Yesterday, the dev server restarted, signs.dat was completely wiped - not recoverable. Few hours later, the main server restarted, signs.dat was half-wiped - not recoverable. Today, main server restarted and signs.dat was wiped once again. Thankfully I had a backup this time.

I can't provide you with logs, sadly, however I highly suggest putting a safeguard in place that backs up the signs.dat file. I was very disappointed, hours of work setting up around 100 command signs on the dev server for a new map: wiped. Thankfully I now know better.

Opening ticket now with the one persistent message I keep getting in console...

On another point, I love the power, but now a CommandSign can be attached to any block I am worried about maintenance issues. There seems to be no way to delete CommandSigns unless you know where they are and there is now way to highlight them in game or even look up their locations in a database/yml. You could have an ordinary block doing something (anything!) in response to redstone, for example, and it could be really hard to troubleshoot!

I feel we need some way to either highlight or at least know the locations of CommandSign blocks and some way to clear them down en-mass. If highlighting is too tough, maybe some commands to clear all in a server, world or within a given radius?

Hi. Yes, definitely downloaded the latest, although the plugin.yml still says 1.7.2. As I said, on my live server (not even sure what the operating environment is, it is hosted by MultiPlay) a signs.dat file is not even created - when installed, when a sign is added or on server reboot.

When I ran my test version on Windows 7 a signs.dat was created, but it was empty and was never updated.

Running the save command seems to fix everything, so it does seem there is still some issue with the automated save of sign data.

It was only looking at the source on GitHub I saw that I need to SAVE the signs after creating them!! This is not in the command listing, maybe it should be? :)

I've just finally installed this and I too am having the problem where signs are not being saved. They work perfectly until the server is rebooted (really nice by the way) but then nothing.

Thing is NOTHING seems to be saved in the signs.dat file. The modified timestamp is still the same as when first installed! Any ideas?

Edit: I tried deleting the plugin folder and letting CommandSigns recreate it and this time no sign.dat file appeared at all, only the messages.yml, before or after shutdown. There are no errors in the server.log and all works perfectly until server reboot.