Uploaded image for project: 'Spigot'
  1. Spigot
  2. SPIGOT-5541

World#isChunkGenerated returns false after calling World#getChunkAt

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • None
    • None
    • This server is running CraftBukkit version git-Spigot-800b93f-a0e88fb (MC: 1.15.2) (Implementing API version 1.15.2-R0.1-SNAPSHOT)
    • Yes

      If I try to generate a chunk using  world.getChunkAt(x, z) multiple times at once, then calling world.isChunkGenerated can return false at a later time.

       

      Testing:

      I used a small custom plugin:

      https://github.com/mart-r/testchunkget

       

      It's got the testcode [nr] command. What it does is get 2 random numbers in the first world of the server and then generate it with world.getChunkAt(x, z). It then starts a task that'll check if said chunk is marked as generated in one second and then again in another second.

      If you run this command with no arguments (or with argument 1), you'll see the expected result (the chunk was not generated before the command, but is afterwards).

      If you run the command with an argument of 3 (or higher), it'll do the same for 3 (or more) chunks. You'll see that the chunks are marked as not generated after 1 second and then marked as generated after 2 seconds.

       

      Here's the body of the code (also available in the github link above):

         
          private final int timeTotry = 2;
      
          @Override
          public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
              int loops = 1;
              World world = getServer().getWorlds().get(0);
              if (args.length > 0) {
                  try {
                      loops = Integer.parseInt(args[0]);
                  } catch (NumberFormatException e) {
                      // loops = 1
                  }
              }
              for (int i = 0; i < loops; i++) {
                  runTest(world, sender);
              }
              return true;
          }
      
          private void runTest(World world, CommandSender sender) {
              int x = ThreadLocalRandom.current().nextInt(-100000, 100000);
              int z = ThreadLocalRandom.current().nextInt(-100000, 100000);
              sender.sendMessage("Starting... chunk " + x + " ," + z + " in " + world.getName() + " is loaded?" + world.isChunkGenerated(x, z));
              world.getChunkAt(x, z); // generate chunk
      
              BukkitTask task = getServer().getScheduler().runTaskTimer(this, () -> checkTask(sender, world, x, z), 20L, 20L);
              getServer().getScheduler().runTaskLater(this, () -> task.cancel(), 20L * timeTotry);
          }
      
          private void checkTask(CommandSender sender, World world, int x, int z) {
              boolean generated = world.isChunkGenerated(x, z);
              sender.sendMessage(x + " ," + z + " in " + world.getName() + " loade now?" + generated);
          }
      

       

      So unless I'm misunderstanding what World#getChunkAt does (I assumed it would generate the chunk as it returns it and the javadocs say to use this instead of World#load because the latter keeps it loaded) or what World#isChunkGenerated does (I assumed it checks if the chunk has previously been generated, which I assumed getChunkAt did), it feels like a bug to me.

       

       

      PS:

      My issue arose when I was looping through all the chunks within a region and using the World#getChunkAt method to generate them. When I looped through them again checking World#isChunkGenerated, some of them reported to have not been generated. This would seem to be consistent in a way that a certain set of chunks would report being not generated for a some time (up to a few a minutes). It would seem if you leave the chunks be (i.e don't check again for a minute) they'll get back to normal. 

            Unassigned Unassigned
            drives_a_ford Mart Ratas
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: