Inactive [SEC] AntiXRay v0.6.10 - protecting ore from XRay mod and transparent texturepacks [1000]

Discussion in 'Inactive/Unsupported Plugins' started by asdaarg, Apr 11, 2011.

  1. Offline



    Reporting Errors the follow things have to be mentioned:
    • CB Version and AXR version
    • Whether you started the AXR version with a fresh ore file or not (doing /axr off before upgrade)
    • If not, since what version you've been using the same ore file.
    • If you get any errors in console, check the debug.log for "Error"s and "Warning"s. and post those.

    Upcoming features for 0.7:
    - AXR Chest chest hiding feature developed by MrSelfDestrukt
    - New advanced visibility test (almost done, only need to test it now and decide whether its going to replace or be an alternative to the original light based test) Details here and here


    AntiXRay hides ores from players by turning them into stone until they have been exposed, thus making it impossible for any client side hacks to detect them, as their location is not sent to the client.

    Backup your world(s) I cannot guarantee that ore doesn't disappear from them due to this plugin. Even if you did not backup, there is a foolproof solution here. If you decide to uninstall, type /axr off, and not delete the ore data file before your ore is restored unless your intention is to strip your worlds from ore.

    If you upgrade from 0.5.21 it is recommended that you do /axr off first flush out errors from the ore file. If you do not have enough RAM, you can do this in steps using 0.6.9 but you need to set lenient=true in the config file to allow the file to be loaded
    NSCommand <-- Required
    Source and old versions

    - Specify what ores to hide(works with non ore blocks too as long as they don't use data values or extra data such as chests and signs (use some chest locking plugin for keeping your chests from xrayers)
    - Multi world support
    - Permissions support
    - Stores ore data in binary files (one per world) and only keeps data about loaded chunks in physical memory. It is on average 400 bytes per chunk in and guesstimatedly around 450 in physical memory, so it is reasonably small, but some people might play on huge worlds and want to conserve memory.
    - Saves data about chunks immediately on any changes (they are assumed to be by far sufficciently rare that any performance is won by buffering is neglible. As such it also prevents potential ore duplication on server crashes)
    - chunk and world statistics
    - ingame map of loaded chunks
    - background processes that does not freeze the server
    - dump ore statistics into file and compare them to see the changes in ore content.
    - lots of configuration options

    Ores will become visible under any of these circumstances:
    - A surrounding block is lit by torch and player is within the chunk or adjacent chunk and within 16 blocks to player on Y axis.
    - A surrounding block is lit by a third block broken falling or removed by explosion and player is within the chunk or adjacent chunk and within 16 blocks to player on Y axis (occurs once every 2 seconds, but configurable).
    - A surrounding block is broken or falls or removed by explosion
    - A surrounding block is changed by another plugin (can be cpu intensive if you worldedit a big area for instance - might do a workaround for this)

    Current Limitations:
    - Ores at light level above pitch black on chunk generation will not be hidden e.g. near lava or surface cave entrances.
    - Ores will not be found exploring caves in pitch black (who does that anyway?) These two limitations was to allow a light based visibility test that relies on a test already built into the server, thus avoiding extra performance overhead as well as headache of coding it myself. Despite these limitations, AntiXRay should make it far beyond pointless to search for ores using XRay or transparent textures.
    - Gravel and sand dropping on chunk generation may expose ore. This is assumed to be rare enough to have neglible effect.
    - The data file will not repack itself. The ratio between generated ore and mined ore is assumed to be very high, and the file size is considerably small but nonetheless, should you want to "repack" it, just turn axr off and on and the new file will be smaller excluding the gaps between chunk entries. But again, do some basic math and count the amount of ore blocks mined in total, multiply that by 2 bytes. After a month of mining 10000 ore blocks, you shaved 20k off that 3M file.
    - If you place a torch there is a tiny delay as seen in the video due to client side prediction and lag between the time the info of the ore to get back to the client from the server. This can seem unnatural so I might make a better vision test later that doesn't rely on light. However it would be more expensive in terms of cpu cycles.
    - If you have a slow server or a lot of players, you might want to remove coal from the config list. It speeds it up at least 200%. There are some optimizations I can do that I might add later that will speed up things further.


    /axr on - hides all unlit ore
    /axr off - reveals all hidden ore (and deletes the data file!)
    /axr on <world> - hides all unlit ore in specified world
    /axr off <world> - restores ore in specified world
    /axr worlds - world statistics
    /axr chunk - chunk statistics at chunk player is on
    /axr chunk <x> <z> - chunk statistics at specified chunk
    /axr map -shows map of loaded chunks in current world
    /axr map <world> -shows map of loaded chunks in specific world
    /axr map <zoom>
    /axr map <world> <zoom>
    /axr map <x> <z>
    /axr map <world> <x> <z>
    /axr map <zoom> <x> <z>
    /axr map <world> <zoom> <x> <z>
    /axr show
    /axr show <world>
    /axr hide
    /axr hide <world>
    /axr dump <world> <file>
    /axr diff <filein1> <filein2> <fileout>
    /axr gen <world> <x1> <z1> <x2> <z2> command for generating a rectangular area of chunks
    /axr gen copy <world1> <world2> command for generating all the chunks in world2 that are registered in world1
    /axr pack <world> - removes dead space in ore file (not that there is much from just mining but the axr chest will create significant amount of dead space.
    Auto-backup, that will backup your ore file on startup
    /axr backup <world> - backs up the ore file of the world if and only if the file passes the corruption test
    /axr test <world> - test the ore file and memory for errors for a specific world
    /axr test - test the ore file and memory for errors for all worlds
    /axr mirrorworld <world1> <world2> - creates a world world2 with the same seed as world1.
    These functions are not recommended for use unless you know what you're doing: (they can be destructive of tile entites)
    /axr chunk regen - regenerate chunk (to as it was when world was initially generated)
    /axr chunk regen <x> <z> - same but for specified chunk
    /axr chunk regen <x1> <z1> <x2> <z2> - same but for axis aligned rectangular area
    /axr chunk regen ore - only regenerate ores in chunk at player position
    /axr chunk regen ore <x> <z> - same but for specified chunk
    /axr chunk regen ore <x1> <z1> <x2> <z2> - same but for axis aligned rectangular area

    Note about regeneration: ores, trees, flowers and mushrooms are random each time and not tied to world seed (bukkit/mc issue)



    timerms - the time between light check by broken third block in milliseconds.
    maxdep - buffer size for number of ores that can occur in a chunk - don't change unless you have another plugin that adds tons of ore.
    maxheight - is the number of Y-levels in your map.
    ChunkFileBuffer - sets how much is buffered for new chunks to be stored until the index is rewritten (at the end of the file.)
    Materials - what ores you want to hide. (has to have same number of elements as maxys)
    maxys - the first Y level from bottom they cannot occur at. (has to have same number of elements as Materials)
    worlds - what worlds are loaded at startup (comma separated)
    autostart=all (normal) worlds are loaded at startup (unless CFGworlds is set)
    nounload = keeps all ore data in physical memory
    debug - turning on writes to a debug file keeping track of important info that may be needed to solve bugs or figure out why lag occurs
    fileindexdebug - turning on debug file needed as a quick check of the consistency of your ore file
    mapcol - the chatcode colour of each type of block in ascending order, shown in /axr map
    mapwidth - the width of the map shown in /axr map
    mapheight - the height of the map shown in /axr map
    schedulerload - 0-100 percentage of time going to execute any background process.
    schedulerstatustimer - time in millisecs between each status report of a background process
    filterorenotinstone - filters ore upon exposition that is not in stone (can be used to restore ore from a backupped ore file or ore file generated from a fresh world with same seed)
    autorepack - pack ore files automatically at startup - on by default
    autobackup - backup ore files automatically at startup(requires autorepack) - on by default
    maxfaces - specify max amount of exposed faces per chunk before error occurs
    lenient - ignore lindex errors when loading file (useful if you have them from before and want to filter them out)
    All CMD_... options are for redefining the commands so you can type something else.

    • Fixed Array index out of bounds in listindex accessing materials that has not been loaded yet.
    • Added /axr mirrorworld <world> <mirrorworld> command
    • Fixed NPE when trying to expose ores in world hole.
    • checking whether wrong file exist during repack.
    • fixed NPEs in some commands that can occur if you use it and the world is off.
    • fixed open file pointers during repack.
    • fixed NPE during repack when load fails.
    • fixed NPE when running test on all worlds and not all worlds are on
    • added various memory checks and chunk data entry overwrite checks
    • fixed NPE when trying to flush the debug file when debug file is turned off.
    • added lenient config option to ignore lindex errors when loading file (useful if you have them from before and want to filter them out)
    • added more information on error when loading from file
    • added config option maxfaces to specify max amount of exposed faces per chunk before error occurs
    • /axr off now gradually unregisters chunks - as a workaround to what appears to be a problem with chunks not getting fully removed from memory despite trying both unloadchunk calls through bukkit. This allows one to shut down the server and continue restoration after a restart if one does not have enough RAM
    • /axr pack <world> - removes dead space in ore file (not that there is much from just mining but the axr chest will create significant amount of dead space.
    • /axr backup <world> - backs up the ore file of the world if and only if the file passes the corruption test, also packs the new file.
    • /axr test <world> - test the ore file and memory for errors for a specific world
    • /axr test - test the ore file and memory for errors for all worlds
    • autorepack config option - pack ore files automatically at startup (if and only if the file passes the corruption test) - on by default
    • autobackup config option - backup ore files automatically at startup(if and only if the file passes the corruption test, and also requires autorepack) - on by default
    • new .ore extension for ore files (rename your old files)
    • removed glowing redstone ore from default ore list (never occurs naturally anyway)
    • fixed faulty scanning issue
    • fixed hopefully last exposed ore face index error
    • fixed false positive in memory check
    • debug.log flushed when error occurs (it is otherwise flushed once in a period of time)
    • more details in debug log when error occurs
    • removed lindex spam in debug log until lindex error occurs
    • Fixed /axr gen not triggering scan anymore
    • Fixed /axr gen not unloading chunks
    • Fixed (workaround) huge memory leak during /axr off /axr show /axr hide and /axr gen caused by bukkit's unloadchunk function
    • Additional file corruption checks that will make noise as soon as something goes wrong
    • Fixed another potential index derangement bug.
    • Fixed array out of bounds exception during previous fix
    • Fixed a couple of bugs offsetting exposed ore face indicies when mining adjacent block potentially causing array out of bounds exceptions at a later stage and the revealing of wrong ores when exposed to light.
    • Added debug logging of exposed ore face indices when found, as well as fault intolerant check that will warn you about any corruption of the indices after the event.
    • fixed half of ore not being hidden when a chunk is generated on load.
    • removed various unnecessary details to be logged in debug.log
    • fixed bug restoring ore, hiding and showing in wrong world
    • revert hack to set block material of a chunk to physical updates due to lacking javadocs to figure out what function to call
    • Switched to non physics updating block material setting hack
    • Updated to #733
    • Added detailed debug logging of background processes.
    • removed logging of filepointer
    • fixed failed scan after /axr gen unloading chunks that were originally not loaded, consequently also /axr gen causing server to freeze and timeouts on clients.
    • fixed /axr gen not unloading chunks that were originally not loaded
    • /axr gen and /axr gen copy now actually usable
    • ore in stone filter now also applies to /axr off and /axr show (not just when it is found by light detection)
    • added /axr gen command for generating a rectangular area of chunks
    • added /axr gen copy command for generating all chunks that are registered in another world
    • Configuration option CFGfilterorenotinstone implemented, that allows filtering of ores not in stone (can be useful in recovering lost ore from a world with the same seed)
    • fixed ore regen not working when axr is off in that world
    • removed physics lock spam
    • fixed more concurrency errors during background processes (hopefully for the last time)
    • fixed more concurrency errors during background processes
    • fixed concurrency errors during background processes
    • fixed debug off in config file causing unable to start (again! although different place now)
    • ore stats dump - listing all chunks ore counts into a text file
    • ore stats diff - showing difference between two ore stats dump files (these two tools are useful if you are worried that your ores might disappear)
    • show command - reveals the ore but does not unregister them or delete the file
    • hide command - hides again ore that was revealed with show.
    • show, hide and ore stat dump are background processes that does not freeze the server.
    • axr off is now a background process
    • load percentage of background processes can be configured
    • specify map zoom and center
    • Fixed file index debug listing not showing
    • file index debug listing can be turned off in config.txt (fileindexdebug)
    • area regeneration functions now tolerate any two coorner in rectangle in any order.
    • fixed debug off in config file causing unable to start
    • added axr map command for showing map of loaded chunks
    • fixed light expose unmapped material (probably why you got grass/smooth stones)
    • fixed light expose restored block being block at exposed face
    • fixed light expose no chunk location offset (why you got it at spawn)
    • fixed exposed face location wrong axis (probably floating blocks)
    • removed unnecessary cacheing of chunks at startup by not using chunks as keys for file index(probably solve memory problems for large worlds)
    • bypassing unnecessary cacheing of blocks using minecraft hackery.
    • revised scan algorithm, bypassing bukkit wrapcode resulting in at 5-10 times faster scanning.
    • fixed queries on unloaded sidechunks during scan resulting in loading and even generation of chunks that on top of it due to eventlock get ignored by onChunkLoad, thus leaving chunks of unhidden ore.
    • fixed light expose filling 0s after removed index
    • probably more bug fixes, can't remember them all
    • world statistics: type axr world - shows also what worlds are on/off
    • chunk statistics when axr is off no longer causes world to be registered without any chunks being loaded
    • axr on doesn't show NaN when there is nothing to hide
    • proper colouring
    • empty chunks are no longer ignored.
    • Fixed potential ore type shift bug
    • Moved listindex before file is loaded so debug info can be displayed even if it crashes while loading.
    • added rectangular area regen functions
    • Fixed silly nullpointer exceptions
    • Specify what worlds to turn on and off
    • Specify what worlds to load at startup
    • option to keep all ore data in memory
    • chunk statistics (useful for checking that your ore doesn't disappear or duplicate)
    • chunk regenertaion (restore a chunk to state at world generation)
    • chunk ore regenertaion (restore only ore)
    • Fixed some other bugs related to exposed-face-to-ore index
    • Index debug file working again (it was still expecting 0.1.5 files)
    • Added potential ore file corruption warnings to debug file output
    • Fixed bug locating exposed-face-to-ore index elements having no array bounds check.
    • Fixed bug exposed-face-to-ore index elements not being removed
    • Fixed bug exposed-face-to-ore index not being updated when ores are recovered and removed from hidden ore list (new bug in 0.2)
    • Fixed bug at y levels above 128-16 looking for ores above the map
    • Uses NSCommand now (it did right from the start but its now a separate plugin)
    • auto-creation of config files
    • defaults to ops only when permissions is not present
    • Light detection optimization based on a separate list of faces exposed to nonsolid materials (this might not work with all materials yet such as stairs and singlesteps, but its not like the world generator puts them in the caves anyway) resulting in at least 10 times faster execution of light checks. This should reduce all lag that's not due to scanning new chunks for ore.
    • Once again more detailed debug log
    • Fixed bug in ore restoring function causing large veins of ore to be generated out of nothing
    • More detailed debug log
    • Removed file corruption check that's hogging up some cpu cycles during file load and write events (the latter occured during scan event) - so this should speed up scan events.
    • pseudo error "load error 1" moved to debug log.
    • Added 1 tick delay of scan in onload event since it appears bukkit fires it before the chunk is populated with ore. This fixed the bug of ore appearing if you teleport or walk far away from initially scanned chunks.
    • removed physics event logging since it appears to always be neglible.
    • Added message at startup informing you about the waiting time of scanning all loaded chunks may take a while.
    • Fixed bug starting server without plugin data folder causing it unable to write debug file
    • Added more debug file details (when its scanning, loading from file, or just loading from memory when neither is shown)
    • Those who who don't hide coal, should experience faster chunk scanning now
    • Fixed bug due to player location being null for some weird reason
    • Added debug logging of time spent on the main time consuming procedures.
    • Fixed config file not loading properly
    • Removed wtfexception spam
    • Initial Release
    Donate (Not necessary but appreciated)
  2. Offline


  3. Offline


    Boy so I had no idea that attempting to restore the ore after 5 days of using this plugin would literally stop my server (block lag began with a slight delay, and ended with an average 10 second delay in all operations) with the lag it created... on top of this it was not even unable to complete it's restoration operation before my automated restart kicked in and inturrupted it (it was at someting like 3,000/18,000 restored.) Should I be concerned with the fact the operation was incomplete by the time my restart mechanism halted operations?

    I run a very small server - about 5 players active generally at any given daytime hour, so the lag from my server would be nothing compared to a serious server. I went ahead and typed in /axr on as soon as the restart commenced hoping that this would help the situation... hopefully someone can let me know if I should be attempting a restoration of sorts, though! I believe it only deletes the ore information AFTER you restore, right? Meaning that since I turned it back on, it should be working as intended without error?
  4. Offline


    Ore lit even by moonlight (=4) will not be hidden.

    Yes, you should be safe. It will not delete the ore file until all ore is restored. If it is interrupted however some of the ore will be visible, and if you want to rehide it you type /axr hide. Else you could try /axr off again.

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



    Having some major problems with this, since we put it in, we've started to get corrupted chunks - single chunks being replaced with absolutely nothing. I can't tell if it's another plugin conflicting with it or not, but the chunk has became something of a tourist attraction, so we've kept the plugin in.

    However, this is a problem: (during startup) (frequently during play, usually in chunks of 10-20, always causing massive lag and occasional crashes).
  6. Offline


    Hm, I have a backup of my world from it's original state. However, I don't understand how to use any multi-world plugins. Can I just use the axr plugin on the original world. and then use that ore data on my current world to restore the ores like that?
  7. Offline


    Also maybe lower the scheduler priority???
  8. Offline


    What value would I want for this setting?
  9. Offline


    Can I have a look at your debug.log (it can be big so you might be best off zipping it) as well as your .world.index files?

    Well if it gradually increases, I might have to do something else. Not sure why that would happen yet. Did it happen to you btw?

    In fact yes, its possible to skip the multiworld step if you don't use /axr gen copy. If you have a backup of any age you can use that, but otherwise you need to copy the corrupted world and delete its region folder. Use the rectangular /axr gen to generate the chunks to trigger the ore scan. Then use the new ore file to bring back the ore in your corrupted world.

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


    I had a similar issue as LucidLethargy last night while trying to prep an unmodified backup for map rendering (i.e. one that did not have any of its ore replaced). I used axr off from inside the game and it proceeded to process about 14,000 chunks. It ran out of memory and crashed at about 13,000, at which point I had to stop the server and restart it. I left it running (apparently normally) from there because I didn't have any more time to work on it.

    What's the procedure the plugin follows in such a situation? Is it like a transaction where none of the ore is changed back if any part of the rollback fails? Or is it incremental (i.e. it will resume from where it failed next time I try to turn it off)? I'm a little worried I would be locked into being unable to turn this off if necessary.

    Also, I'm a little unclear on how the plugin behaves when the server is restarted; do all the ores remain hidden on a normal shutdown? Given the speed of the shutdown/startup sequence, that would be my guess, but just wanting to make sure I'm right.
  11. Offline


    Good thing to know, so its probably also why it starts lagging, that it uses up your memory. I'll see if I can find what could cause it.
    Edit: I'm unloading the chunks that were not loaded, right after restoring them, before going on to the next chunk. However, I have a leftover Block based settypeid there, which could blow the bukkit block cache. We'll see if changing that has any effect.
    It gradually restores the ore but it will start all over after a failure.
    Restart or reload does not affect it. The info about the ore is in the file, while in the world, there is smooth stone in its place.

    Okay, its fixed now, bukkit issue again, although thankfully there was another unloadchunkrequest function that didn't have the same issue. Also fixed some problems with axr gen, so that should be usable again.

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


    Default is 30 I think, I upped it to 90 on my test machine so all the processes were much faster. Try halving it maybe? I don't have a very big server and have left it at default for now.

    I hope someone else gets to test it like I did, I don't "need" to do this again, but sure makes me want to just for a test.. :)

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


    It stopped working with 0.5.16 when I added the sidechunk tests so it doesn't prematurely scan the chunks before the sidechunks have generated ore on it. Since axr gen immediately unloaded the chunks (from bukkit, not from axr) it always failed the tests. Now it unloads both from bukkit and axr, but it overrides the side chunk tests. This can have unintended side effects though - axr gen should never be run with axr on without first running it once off, but you figured that out far ahead of me, but now I know the reason :)

    Upcoming features for 0.6:

    - New advanced visibility test (almost done, only need to test it now and decide whether its going to replace or be an alternative to the original light based test) Details here and here
    - Auto-backup, that will backup your ore file on startup after a validation process to check that your file isn't corrupt.
    - Backup on command.

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


    Sometimes there is a mistake. How do I fix it? What's wrong?
  15. Offline


    Your ore files are probably corrupted. Can I have a look at your debug.log and .index.txt files?
  16. Offline


  17. Offline


    It shrinks a lot of you zip it, unlike the ore file.
    Edit: It looks like your chunk index is fine, but you are using an older file version, which may still contain face index errors. You could do /axr off and /axr on to refresh it, and if you are using the latest axr, the errors should be gone.
  18. Offline

    put debug.log

    I tried to enter / axp off but after entering the command server is hung

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


    do it using 0.5.21

    This is the sort of stuff I hate about java. You're used to do things a certain way in C++ and java is deceptively similar in syntax, but you have no unsigned variables so you do something like this:
    int x=xz&0xF;
    int z=xz>>4;
    or something like this:
    and then you have hidden bugs bugging you all this time torturing you since the very inception of this program. Why on earth does java even have these low level operators if you can't use them for anything useful?

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


    Sounds like my concern is being addressed in future versions, and I also can schedule it lower anyway - thank you for all your work asdaarg! This plugin allowed me to stop worrying about people exploiting, and that really is an amazing advantage. Now all we need is something to prevent or more importantly DETECT duplication, and servers will be able to run with zero chance of exploitation just about.
  21. Offline


    Show Spoiler
    2011-05-06 19:48:20 [INFO] RazMage [/*:54722] logged in with entity id 82
    2011-05-06 19:48:20 [INFO] CraftPlayer{name=RazMage} logged in with entity id82
    2011-05-06 19:48:20 [INFO] [StealthLogin] RazMage logged in secretly!
    2011-05-06 19:48:23 [INFO] Connection reset
    2011-05-06 19:48:23 [INFO] RazMage lost connection: disconnect.overflow
    2011-05-06 19:48:23 [INFO] [StealthLogin] RazMage logged out secretly!
    2011-05-06 19:48:24 [WARNING] Can't keep up! Did the system time change, or is the server overloaded?

    I'm assuming that any player will still get this if their logout location hasn't been scanned since they last were on the server. If an admin is doing an /axr off at times either for testing , or paranoia regarding loss of ore it will cause issues to a player, but only for first time login.

    I've reported this before, but just updated to newest version and did a /axr off and back on just because.. lol

    A pre-scan would be nice, but like some things it may only get used once. :)
  22. Offline


    Could this new algorithm be used in a proxy?
    I would much rather take this down the stack as to not worry about un-recoverable block loss.
    As an upside of using it as a proxy it would work with the default Minecraft server.
  23. Offline


    You can use the /axr dump and /axr diff commands to verify that your ore blocks don't appear out of nowhere or disappear, but you need to use /axr show first since it only counts ores that aren't hidden, and then /axr hide when you're done.

    Yes, so its a bit low priority atm, maybe later. Would have to dig into dynmaps source to get all the chunks.

    A proxy would be very problematic if not impossible to implement when you don't have a direct access to all the variables that are needed for visibility tests. A light based visibility test perhaps, but its still not going to be easy to implement without consuming a lot of resources. FYI, there is a recovery process that will get your ore back even without backups. Also the next version is going to have a fix for a bug that might have been the cause for the occasional ore file corruptions that people have reported.

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


    Block positions, player positions, and commands, what other variables do you need?
    Also a light map is sent over the wire.
    Only really need to change the initial map stream and let the update packets show the ore.
    I guess my main worry is state is written to the map.
  25. Offline


    In principle everything the client needs is sent over the wire, but the proxy would have to reconstruct a world based on the packets which is too much of a hassle, when all is available on the server.
  26. Offline


    Does the /axr gen world command regenerate ores or what? I already accidentally mowed down someone's house with the chunk one.
  27. Offline


    /axr gen does two things. It generates chunks if they are not already generated. It also triggers a scan of the chunk if it hasn't been scanned before. It can thus be useful to prescan large areas. It also has a use in the ore restoring method. /axr regen can mow down buildings if that's what you meant.
  28. Offline


    I see, yeah, I'm trying to fix my ores since I started getting tons of errors about a file pointer exception and all my ores are stone. Your post that you linked to from the main post was somewhat confusing so I think I'm going to use this to regenerate ores.
  29. Offline


    <original data deleted, player changed his information and the real issue is not nearly as serious as it first seems>
    It seems at times my players destroy blocks too fast (like with tnt) when they build back said blocks by placing stone, it reverts to the original state. This is not a big deal really, but if it's not known I wanted to report it. I believe it may already be known though.

    Is this happening with others, or is my plugin malfunctioning somehow?
    I am on 0.5.21 & Bukkit 740

  30. Offline


    What file version does the .index.txt say at the top? I'll think about the TNT issue
  31. Offline


    Sure, it's not the biggest deal really all things considered - I wouldn't fret too much. I believe you're looking for this information, too, but let me know if this is not it and i'll get what's required!:

    Version: 2 room for:25312 chunks found...25312 chunks:

Share This Page