[MECH] Fortification - Redstone defenses and tools [BukkitDev]

Discussion in 'Archived: Plugin Releases' started by Rogueleader89, Aug 6, 2011.

  1. Offline


    Important Note:

    This thread is largely outdated as I restart this plugin and move most of the information on it to a much more nicely formatted wiki. For latest info see the patch notes on the bukkitdev page (though the descriptions below will provide you with the basics of the most commonly used mechanisms).

    Also note that if you want to reach me about this plugin, bukkitdev is a much better place to do so.

    BukkitDev: http://dev.bukkit.org/bukkit-mods/fortification/

    This plugin uses the vault plugin for permissions and economy (without, it defaults to everything usable by everyone, teleblock shields bypassable by ops). Also (optionally) uses the Factions plugin for faction-based filters on some redstone devices or (optionally) towny for the same purpose.

    To steal my old description from the hmod page (with some updates, again, sorry, out of date, working on it):

    This is a redstone focused plugin aimed at leveling the playing field in pvp by providing defenders with the tools necessary to mount a proper defense. This being said, many of the features I am adding can serve non-combat purposes as well.

    What's in this plugin?

    As of v0.7 it adds flame turrets, sensors, trap doors, send signs, teleblock shields, chest shields and various other redstone based devices to minecraft (all of which are listed/explained below).



    Flame Turret

    You can make a flame turret if you have the permission "fortification.turret.flame".
    To do so place a sign on the block type defined in config (netherrack, id 87 by default).
    The first line must read "Flame" (no quotes, not case sensitive)
    second line is "[Turret]" (again not case sensitive and no quotes)

    When the sign is provided with power (via redstone) and the ground on the opposite side of the netherrack is level, fire shall appear up to 5 spaces (or whatever you define in the config under flame-turret-range) out from the netherrack (fire will not pass through solid blocks and can not appear in midair).

    Web Turret

    You can make a web turret if you have the permission "fortification.turret.web". To do so place a sign on the block type defined in the config (default is lightstone). Works just like the flame turret except the first line is "Web" (no quotes, not case sensitive). Unlike flame turrets, web turrets do not fire in a line. They fire a shot centered at the web turret length, 9 web total is placed around this spot. The web vanishes after a set amount of time (default 10 seconds, adjustable in config file).

    Arrow Turret

    You can make an arrow turret if you have the permission "fortification.turret.arrow". To do so place a sign on the block type defined in the config (defaultly this is set to 0, meaning it works with all block types). Works the same as the flame turret and the web turret except that the first line reads "arrow", "default", or is left blank (no quotes, not case sensitive). Arrow turrets fire in a (relatively) straight path from the side of the block opposite that of the arrow turret sign.


    You can make a sensor if you have the fortification.sensor permission.
    To do so place a sign on a block of your choice, with the first line of text being the type of filter you want on the sensor (blank = default), and the second line being "[Sensor]" (without quotes, not case sensitive) and a lever on the opposite end of that block. Now, in the case of the default sensor, when someone passes within 8 (or the length defined in the config file) blocks infront of the sensor it will detect their presence and activate the lever (and thus turn on any redstone near it). Filters can be applied to sensors to change how they detect people.

    Sensor Filters:
    playerdetect - Sensor detects only the two people listed on the 3rd and 4th lines of the sign.
    playerignore - Detects everyone except the two people listed on the 3rd and 4th lines of the sign.
    factiondetect - Detects people in the factions whose faction tags are on lines 3 and 4 of the sign (Requires factions plugin.)
    factionignore - Detects everyone except the people in the factions whose tags are on lines 3 and 4 of the sign (Requires faction plugin.)
    itemdetect - Detects people who are carrying an item with the id specified on line 3 or 4 of the sign.
    itemignore - Triggers if the detected player does not have the item listed on line 3 or line 4.
    weapondetect - Detects people who are carrying weapons (sword or bow).
    weaponignore -Detects people who are not carrying weapons.
    tooldetect - Detects people who are carrying tools (pick, shovel, axe, or shears)
    toolignore - Detects people who are not carrying tools.
    areaAlert - Detects everyone and broadcasts their display name and their location to everyone within a configurable radius around the sensor.
    factionalert - Detects everyone except people within the factions listed on line 3 and 4 and broadcasts the name of the person detected and their location to everyone within the factions listed on the 3rd and 4th lines.

    For a full list of sensor types ingame, type "/sensor". For more info on a specific type, type "/sensor type". (This also works for turrets, but its kind of pointless since there is only one turret type right now).

    Trap Doors

    You can make a trap door if you have the fortification.trapdoor permission.

    To do so place a wall sign with [Trapdoor] on the second line (case insensitive) on a block of the type you would like the trap door to remove(/replace if you have it set to replace blocks in fortification.properties (defaults to false)).
    On the first line put the length you would like the trapdoor to span (must be an integer greater than 0 and less than or equal to the maximum defined in fortification.properties, defaults to 4).
    From here you just have to provide power to the sign, power will remove blocks of the type the sign is on out to the length you set. If you have replace-trapdoor-blocks-on-power-off set to true it will replace all air (id 0) within the set length with the block type the sign is on when the redstone is powered off.

    Send Signs

    placing [Send (direction)], where (direction) = the first letter of a compass direction ([Send N] for instance or [Send U] for up, D for down), will, upon receiving redstone power, send text from one sign to another (one sign in the direction you are sending, one sign in the opposite direction, text that is sent is text which is on the same line that [Send] is on on the send sign, can have [Send] on multiple lines).

    For instance, if you had a setup like the below (will replace with pictures later :p)

    |South Sign 1 | | [Send N] | | North Sign 1|

    and the send sign (middle) recieved power, the sign to the south (South Sign 1) would have its next transmitted to the sign to the north (North Sign 1), so that the north sign would then read "South Sign 1". Options in the properties file include whether or not you can send commands via send signs (looks for [ ], thus compatible with craftbook as well as other commands in fortification, also checks for AllDo: PlayerDo: and ServerDo: signs from signcommands), whether or not the original text is erased, and whether or not sent text can overwrite existing text. Command permission is fortification.sendsign

    Message Signs
    The first line of the sign is the name of the person you want to send a message to. The second line is [Message]. The third and fourth lines are the message you want to send. When redstone power is recieved the message on the third and fourth lines is sent to the person on the first line. Command permission is fortification.msgsign

    You can make a teleblock shield if you have the command permission fortification.shield.teleblock

    As their name suggests, teleblock shields prevent teleportation within a set range around the teleblock shield (configurable in fortification.properties). This prevents both teleporting in and out. It effects everyone except people who have the fortification.ignoreteleblock command permission or are an op. By default, teleblock shields must be built on obsidian.

    You can make a chest shield if you have the command permission fortification.shield.chest

    Chest shields detect chest use within a set radius around them (configurable within the config file, default 5). They are set up much like sensors with a lever on the opposite side of the chest shield sign. There are three varients of chest shields: chest, playerchest, and factionchest. Playerchest shields ignore the people listed on lines 3 & 4 of the shield sign, factionchest ignores people in the factions listed on lines 3 & 4 (requires faction plugin). Note that these do not prevent use of chests, they merely trigger redstone when someone tries to use so that you can set off traps/combine with message signs/whatever.

    Config Options (open)

    sensor-range: range of sensors, width is always 3.
    chest-shield-id: the block id required for a chest shield
    trap-door-range: range of trap doors
    send-sign-search-distance: range of send signs
    send-signs-remove-original-text: whether or not sent text is lost at source
    send-overwrites-existing-text: whether or not sent text overrides existing text
    allow-command-sends: whether or not commands using [] are sent.
    flameturret-block-id: block id of flameturrets (0 = any block allowed)
    chest-shield-range: radius of chest shield detection.
    send-overwrites-commands: whether or not sent text overrides [] commands.
    teleblock-string: message given on teleportation being blocked
    replace-trapdoor-blocks-on-power-off: whether trapdoor signs toggle blocks on/off or just remove them
    teleblock-shield-range: Radius of teleblock effect of teleblock shields
    allowed-trapdoor-blocks: set the block ids usable with trapdoors
    flameturret-range: range of flame turret fire
    teleblock-shield-block-Id: Required block id for teleblocks (0 = any block allowed)
    webturret-block-id: Required block id for web turrets (0 = any block allowed)
    webturret-range: Range at which web turrets fire
    web-dissipation-time: Time in seconds before web from turrets disappears
    arrowturret-block-id: required block id of arrow turrets (0 = any block allowed)
    sensor-broadcast-dist: distance the alert from an areaAlert sensor is broadcasted.
    msg-builder-only: If true, message signs force their creator's name on to the first line and factionalert sensors require that the creator is either a part of or an ally to the factions listed on lines 3 and 4.
    #If you have an economy plugin + Register the configuration options below allow you to set #the cost of individual mechanisms. If you lack either or the cost is set to 0 the mechanism #will be free.
    webturret-cost: 0.0
    flameturret-cost: 0.0
    sensor-cost: 0.0
    chestshield-cost: 0.0
    teleblockshield-cost: 0.0
    sendsign-cost: 0.0
    equalsign-cost: 0.0
    trapdoor-cost: 0.0
    arrowturret-cost: 0.0

    Planned Future Updates (open)

    Prevent a single message sign from spamming a player constantly with text.
    Add command that allows player to mute all messages from message signs.
    Add support for sending messages from message signs to all members of a faction.
    Create new type of send sign that exchanges/flips text between two signs (so s1 becomes s2 and s2 becomes s1)
    Add ability to move strings from one line of a sign to a different line on another sign, for instance "[Send N3] would send the string on the line the send sign is on to line 3 on a sign to the north.
    Add device that can detect the destruction of nearby blocks and activate redstone when they are destroyed.
    Add optional fuel/ammunition costs to turrets
    Add area health regen signs w/filters and ammunition requirement (shield type)
    Add new sensor types (multi-directional, radius detect, more filter options (such as mob filters))
    Advanced sensors that can send name of detected player to another sign or display it for use with send signs.
    Ammunition/item use system for turrets/shields.
    String transmitter/reciever, to send text from sign to sign at a great distance.

    Turret types to add:
    Multi-directional turrets, place block ontop of turret block, fires out in all user chosen directions
    Floor traps - turrets that come up from the floor and fire once when redstone triggered.

    Feel free to drop me a line, I am always open for more suggestions for new features.
    MuttsNuts and olimoli123 like this.
  2. Code:
    10:38:29 [SEVERE] Could not pass event PLAYER_TELEPORT to Fortification
    java.lang.ClassCastException: net.minecraft.server.TileEntityFurnace cannot be cast to net.minecraft.server.TileEntitySign
            at org.bukkit.craftbukkit.block.CraftSign.<init>(CraftSign.java:16)
            at org.bukkit.craftbukkit.block.CraftBlock.getState(CraftBlock.java:203)
            at bukkitdev.Rogueleader89.fortification.FortificationPlayerListener.searchradius(FortificationPlayerListener.java:368)
            at bukkitdev.Rogueleader89.fortification.FortificationPlayerListener.findteleblock(FortificationPlayerListener.java:415)
            at bukkitdev.Rogueleader89.fortification.FortificationPlayerListener.onPlayerTeleport(FortificationPlayerListener.java:679)
            at org.bukkit.plugin.java.JavaPluginLoader$9.execute(JavaPluginLoader.java:300)
            at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:58)
            at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:338)
            at org.bukkit.craftbukkit.entity.CraftPlayer.teleport(CraftPlayer.java:269)
            at de.tomgeiger.buxville.vaults.commands.EtherCommand.onCommand(EtherCommand.java:93)
            at org.bukkit.command.PluginCommand.execute(PluginCommand.java:39)
            at org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:163)
            at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:353)
            at net.minecraft.server.NetServerHandler.handleCommand(NetServerHandler.java:756)
            at net.minecraft.server.NetServerHandler.chat(NetServerHandler.java:721)
            at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:714)
            at net.minecraft.server.Packet3Chat.a(Packet3Chat.java:33)
            at net.minecraft.server.NetworkManager.b(NetworkManager.java:226)
            at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:92)
            at net.minecraft.server.NetworkListenThread.a(SourceFile:108)
            at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:471)
            at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:374)
            at net.minecraft.server.ThreadServerApplication.run(SourceFile:417)
    10:38:29 [INFO] Uriel_Septim lost connection: disconnect.quitting
  3. Offline


    0.8 is up. Quite a few changes/additions. Full list below.

    Increased detection radius of sensors to detect 1 block above and 1 block below the level of the sign
    Added arrow turrets under the permission "fortification.turret.arrow"
    Fixed permissions errors related to information commands, specifically for flame and web turrets.
    Replaced BOSEconomy support with Register support to allow multiple different econ plugins to work (note you need to download Register and put it on your server for this to work).
    Message signs now include their location with each message.
    Trapdoors now go through lava/water
    Added itemdetect and itemignore sensor filters to detect or ignore people carrying items of the specified id(s)
    Added weapondetect and weaponignore sensor filters to detect or ignore people carrying weapons (swords, bow)
    Added areaalert sensor filter to detect a player and then broadcast their name and location to players within a certain distance (found under sensor-broadcast-dist in config)
    Added factionalert sensor filter to detect players who are not in the specified factions and then broadcast their name and location to all players within the specified factions.
    Added tooldetect and toolignore sensor filters to detect or ignore people carrying tools (pick, shovel, axe, shears)
    Added a new config option "msg-builder-only" that prevents people from listing names other than their own on message signs and stops a person from listing factions they are not a part of or that their faction is not allied with on factionalert signs
    I was unable to reproduce the error listed by Joy in the post above on this build so hopefully it is fixed, otherwise I'll look into it again for 0.9. Also there is a known graphical bug with arrow turrets in that the arrow appears to immediately stop and fall to the ground, doing nothing, but infact it is shot and works as intended outside of this graphic.

    I've also been moving my own server to superperms recently and can confirm that bpermissions is able to run this plugin with all permissions seeming to work correctly. If you are running any superperms plugin though let me know if you have issues with this build as I will probably convert this the rest of the way over to superperms next build if needed.
  4. Offline


    im sorry but a video showing this mod would help us please
  5. Offline


    I'll see if i can find the old hmod one someone made for me, otherwise I lack the video software necessary at the moment, but i'll see if someone on my server is willing to help out.
  6. Thanks so much for updating, testing today!

    Get some of these errors:

    But I believe it's a known Bukkit bug.
  7. Offline


    Someone on my server couldnt seem to get trapdoor signs to work side by side for awhile. It was saying invalid block type and popping off the sign on the second area of the 2x4 stone bridge when they tried to do it. It started working again later, but no idea why.
  8. Offline


    Keeps saying i dont have permission to build this turret. Im using bPermissions. please help
  9. Offline

    Scruffy Puppy

    Sensor signs keep getting stuck on activating redstone and don't always reset. Also, it seems a bit wonky on placement of trapdoor signs. Sometimes allows it, sometimes says it's not the right ID. Teleblocks and chest shields have no description on how to actually make them and send signs are pretty buggy. Arrow turrets seem wonky as well.

    Overall this is a great mod, but there's so many bugs I'm having problems with it.
  10. Offline


    ran into the sensor issue you mention the other day. I believe it only effects north facing sensors, but I'll look more into it for next release. I'll add shield info in with the next few commands (essentially its line 1 = teleblock, line 2 = [shield] for teleblock, l1 = chest, l2 = [shield], lever opposite side of sign like sensors for chest shields (similar for factionchest)

    First I've heard of trapdoor problems, I'll check into it as well.

    As to arrow turrets, the arrow path itself could probably use some adjusting (they don't fire straight so they start a bit above and infront of the block), if you are refering to the arrows not showing up in flight or appearing to fall its a known bug related to the spawnarrow code not updating the client that I do not know how to (and possible can not) fix at the moment.

    @Undectectable What turret and what permission nodes are you using?

    Unfortunately I have a ton of work to do this week/weekend and gdc online next week, I'll try to squeeze out a bug fix between all of this if I can, otherwise the next release is looking to be the weekend after next.
  11. Offline


    If you can make a video of everything being used, that would be great,
  12. Offline

    Scruffy Puppy

    Alright. Have you ran into problems with Send signs? Can you make a way for a teleblock to be triggerable instead of a status effect. I would love a way to have a switch that would put a teleblock field around my base to stop Runecraft teleports.

    Other things I would like to point out.
    -Faction alert Sensor floods the chat way too much. A small cooldown of about 3 seconds per person would be great if you could? Would still like to recieve alerts of each person, but there's no reason to send 7 messages for a single person crossing two blocks.

    -Trapdoors and Sensors really need a way to effect the directions up and down. That would be grand.

    -Perhaps add a line somewhere on the Sensor signs that effect their range, much like trapdoors. The same would be nice for Web turrets.

    -A way to combine the factionignore and factionalert signs. Perhaps add the option to put a lever on faction alert signs?

    I'll come up with more later. I really love this mod, it's doing great things for me and I have a lot of things planned to build of amazing levels!
  13. Offline


    Add the turret's node to the group you wish to grant permissions. This will make that group able to build that type of turret. Then make sure you have the correct group attached to your name in the correct world file.
  14. Nice sub
    Any news on fixes? Still have this plugin disabled due to the spam :(
  15. Offline


    I actually like almost all of those ideas (and have already planned for a few like up/down facing sensors), I'll definitely look into a bunch of those. Factionalert signs actually can have levers on them as they are, but i think they trigger on everyone right now, making them auto-ignore would probably be a good idea, i'll see if i can't change that for the next version. Send signs right now do work (at least I haven't seen otherwise..), but they are very limited due to looking for exact sign angles (a north facing sign can't send to a west facing sign etc.), they were meant to be a part of a larger system that I've kind of put on the backburner for now so its unlikely they'll get fixed up for a few updates at least.

    Range for webturrets is planned, problem with range on sensors is that I'm already running short of lines on the sign to put sensor variables on :p, kind of the one thing stopping my further expansion of sensor modification outside of seperate filter types.

    @Joy finally getting a bit of free time here and there to work on this so I'll get at least some bug fixes out this weekend. With spam I assume you are referring to the factionalert sensor message spam?

    EDIT: Dividing the bug fixes into two parts in the hopes of getting at least some preliminary stuff out today since its taking longer to switch over to the new configuration api then i expected. Mostly bug fixes, though a few new features such as vertical trapdoors and (very badly implemented) toggleable teleblocks (which i will redo in 1.8.2....). Also got the basic code for vertical sensors set up for the next version, but not functional in this one.

    0.8.1 Changlog

    • Fixed north facing sensors so that they properly reset after detecting a player
    • Fixed south facing trapdoors so that they detect the correct block ids
    • Added 3 second delay between chat messages sent by FactionAlert and AreaAlert sensors (will be configurable in next version once new config api is set up).
    • Added optional ability to toggle teleblocks on/off by placing a redstone torch on the opposite side of the sign and turning it to its off position (yes this works poorly, will definitely change to something more usable in 1.8.2)
    • Fixed misguiding instructions on sign placement that pointed to old help commands which no longer exist.
    • Removed check on sensors to see if someone is leaving an area (since sensors are on a time delay to turn off regardless) to improve performance.
    • FactionAlert Sensors no longer trigger redstone if the player detected is in one of the two factions listed on the sign.
    • [UpTrapdoor] and [DownTrapdoor] are now available mechanisms, work the exact same as trapdoors except they go up or down in direction (sign is still placed on the side of the block).
  16. Offline


    Feature Request: Support Towny! Support for sensing town members and nation members.
  17. Offline


    Where are all the permission nodes at? I found some listed on the bukkit dev site but this can't be it....right?
    fortification.torret.flame: true
    fortification.turret.web: true
    fortification.sensor: true
    fortification.trapdoor: true
    fortification.equalsign: true
    fortification.sendsign: true
    fortification.msgsign: true
    fortification.shield.teleblock: true
    fortification.ignoreteleblock: true
    fortification.shield.chest: true

    am i missing something? are the nodes listed somewhere and im just not seeing them? any help is greatly appreciated!
  18. Offline


    offhand you're missing fortification.turret.arrow
    also (if this is set up how i think it is..) I've checked on the old * nodes from past permissions in a way that the new bukkitpermissions should pick up on (so fortification.shield.* should give permission for all shield types, fortification.* permission for all mechanisms).

    If you are refering to filters potentially missing permission nodes, the short answer is that they currently don't have them, I've considered giving them a few times (so fortification.sensor.playerdetect would be a permission and so on), but haven't really had the need for my own use and nobody has requested them here, if you need permissions for that sort of thing just let me know I can probably add them fairly easily.

    I'll put together a full list of permissions in its own separate section for the next release (since they are kind of scattered right now..).

    @NotYetRated I'll look into it a bit, I don't run towny on my server though so no promises.
  19. Offline


    Thanks for the replay and this is my first attemp at permissions for my server but I you can implement a fortification.* that would be great but not neccessary. I think it all depends on how you set up your permissions really.

    Thanks again mate and a seperate permission section will save me and other much time and we will greatly appreciate it!
  20. Offline


    fortification.* should already work, if its not then reply back and I'll make sure it does for the next version (or even today's beta release if you're fast enough :p).

    @NotYetRated and for you, I've looked a bit more into towny, seems pretty simple to implement checks for it like the faction checks, i'll put up a beta release with the simple to implement stuff today if you want to try it, otherwise a list of things that might be useful to have related to towny would be great since I haven't used the plugin personally (right now i'm setting up nationdetect/ignore, towndetect/ignore and likely town/nationalert).

    EDIT: As long as we're talking about filters and such, I've been considering adding a config option to only allow faction moderators to place factionalert signs, is there some sort of equivalent ranking within towny I could make an option for its town and nation alerts?
  21. Offline


    Wow Rogue quick response time!

    What I would want it for, is exactly as you are doing. Town check, nation check. That way, my server members can set up fortifications against enemy towns and nations, yet let friendly towns in unharmed. As far as alerts, make sure I am understand it correctly. So you set up an alert sign, for say EnemyNation, and it relays the alert to whoever set up the sign? There are "Mayors" (owners of the towns) and "Kings" (Mayors of the towns who formed a nation), there are also "Town Assistants", which have all the power of mayors, but are titled as assistants.

    I would say for alerts though, have it warn the entire town. As the information is relevant to anyone in the town under attack.

    If you need anything tested, let me know!
  22. Offline


    Version 1.8.2 is up, still updating this thread with changes and such but it can be downloaded.

    0.8.2 Changelog
    * Added Towny support with townAlert, nationAlert, townDetect, townIgnore, nationDetect, and nationIgnore sensor filters.
    * the msg-only-builder config option now requires towns listed within townAlerts to either be the builder's town, within the same nation,
    or in an allied nation, and nations in nationAlert to either be the builder's nation or an allied nation.
    * Added upward and downward facing sensors [UpSensor] and [DownSensor], all normal sensor filters apply.

    @NotYetRated yes, alert signs send the name and location to everyone within the towns/nations/factions specified, there is an optional setting in the config which makes it so only people in those towns/nations/allied towns/nations can place the signs (so as to prevent people from spamming an enemy). And town assistants/mayors sounds like what i'm looking for.
  23. Offline


    I haven't checked the fortification.* use yet but if I read the BukkitPermissions guide correctly they do not operate that way UNLESS you have implemented it. If that is the case i would greatly prefer a "fortification.all" node compared to the asterisk as that will avoid confusion.

    Also, just wanted to say thanks again for the great plugin and looking forward to comparing your permission nodes with those I found on the "overview" page on BukkitDev
  24. Offline


    It all works as far as I have tested so far!!!! This is spectacular!

    Is there any way to reset a triggered sensor after an amount of time?

    Specifically, I have a member wanting to close a gate if it detects weapons. The thing works, but he then has to manually reset the triggered switch to reopen the gate....

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  25. Offline


    it already should reset the lever after a set amount of time, if thats what you mean, should be about 3 seconds... hrm... I'll look into it a bit, maybe i missed a reset somewhere (use to have an issue with north facing sensors like this, could be related), in the meantime if you can figure out which direction his sensor was facing that would be helpful.

    Also i appear to have stumbled on a bad bug that stops 1.8.2 from working on some setups that aren't running towny, working on a fix now.

    EDIT: and its up.
    0.8.3 Changelog
    * Fixed an issue that prevented the plugin from working with certain server configurations lacking Towny.
  26. Offline


    Ahhh, they are resetting after about 3 seconds apologies!

    There is a slight problem though, not sure if it can be fixed.

    I have some members who made a weapondetect which shuts a fence on people walking through a gate with weapons. It works well, except if the player stops at the fence and waits a moment. The gate will then open allowing the people with weapons through... Any way to avoid this, or fix it?
  27. Offline


    unfortunately that is the one disadvantage of the current timing system on sensors, I assume the gate triggers again as they are walking through.. hmm..well, for the most part, the problem will have to be taken account on your end for now, if you can put 2 gates immediately next to one another and just have it be a thicker gate they probably won't be able to get through both since the sensors trigger on a single block worth of movement, at best they'll get smashed by the first gate which will likely hurt them a bit and then push them back out.

    I have a few ideas on how to fix the core of the problem I might try, but they're unlikely to make it in for at least a few more builds (if they work in the first place) due to the amount of rewriting/performance testing that would have to be done with them (sensors use to be very performance heavy because they had too much sensitivity, which rules out a lot of the easy fixes), I'll definitely look more into the issue though at some point, but for now at least, a couple of other features take precedent over it.
  28. Offline


    I kind of figured as much haha. But the double gate system does seem to work well! If all esle fails, a flame strip or something for those abusing it may do the trick :)
  29. Offline


    13:22:58 [SEVERE] Could not pass event SIGN_CHANGE to Fortification
    java.lang.NoClassDefFoundError: com/nijiko/permissions/PermissionHandler
    at bukkitdev.Rogueleader89.fortification.FortificationListener.onSignCha
    at org.bukkit.plugin.java.JavaPluginLoader$35.execute(JavaPluginLoader.j
    at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.jav
    at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.j
    at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:1045)
    at net.minecraft.server.Packet130UpdateSign.a(SourceFile:41)
    at net.minecraft.server.NetworkManager.b(NetworkManager.java:226)
    at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:92)
    at net.minecraft.server.NetworkListenThread.a(SourceFile:108)
    at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:464)
    at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:374)
    at net.minecraft.server.ThreadServerApplication.run(SourceFile:417)
    i didnt understand this problem but here it is in case you wanted to read it
    happens when i make a sensor

    and i couldnt get web turrets to work either but other than that i love your plugin it is great and yer i could'nt get sensors to work
  30. Offline


    Here's an interesting suggestion you could consider adding, since you support Factions and Towny.

    Why not add another set of sensor filters that are dependant on the factions listed on lines 3 and 4 such as: EnemyDetect, AllyDetect, EnemyIgnore, and AllyIgnore, where it checks the relationship status of the sensed individual to the factions or towns/nations listed on line 3 and 4.

    So for instance, if I used EnemyDetect - [sensor] - MyFaction, then it would automatically check factions for who is an enemy to MyFaction and trigger accordingly, which makes it easier to set up faction defenses specifically against enemies, without ever having to change the signs around (because lets face it, if you have more than two factions you're at war with, and you can only list two names on a FactionDetect sign, it starts getting more complex and problematic to defend against them).

    For Towny, those same filters could work directly for nations, since nations can only go to war with each other, so the filters would check the relationship status of the listed nations with the nation of the individual passing by the sensor to see whether it should trigger or not.

    If you could add these filters to a sensor, it would allow players to use those filters universally, and change 'who' they detect simply by changing their nation/faction relationships accordingly and letting the sensors automatically update and judge by current relations.

Share This Page