Persistent Bits

Persistent Bits

3M Downloads

Exceeding Chunk Loading tickets?

psychofad opened this issue ยท 16 comments

commented

The Forge Chunkloading settings are default, 25 chunks = 1 ticket. 200 Tickets per mod.

So doing the math, each Persistent Bits chunkloader should use 2 tickets each as they are 7x7 or 49 chunks. Meaning that under these settings I should be able to place ~100 Persistent Bits chunkloaders give or take and still be well within the limits.

Yet, in the startup of the server I am seeing this:

[19:55:18] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at 185 64 203 dim = 5 has been automatically loaded!

[19:55:18] [Server thread/INFO] [FML/PersistentBits]: The mod PersistentBits has attempted to allocate a chunkloading ticket beyond it's currently allocated maximum : 200

[19:55:18] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at -33936 4 -90383 dim = 0 has been automatically loaded!

[19:55:18] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at -22110 94 441 dim = 0 has been automatically loaded!

[19:55:19] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at -5 64 11 dim = 8 has been automatically loaded!

[19:55:19] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at 169 64 -118 dim = 5 has been automatically loaded!

[19:55:19] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at 2150 66 10483 dim = 0 has been automatically loaded!

[19:55:19] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at 235 64 195 dim = 5 has been automatically loaded!

[19:55:19] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at 103 64 41 dim = 10 has been automatically loaded!

[19:55:19] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at -33924 73 -90387 dim = 0 has been automatically loaded!

[19:55:19] [Server thread/INFO] [PersistentBits/PersistentBits]: The Chunk Loader at 224 64 135 dim = 5 has been automatically loaded!

I only count 10 there, yet somehow we have exceeded the limit?

Any clue as to what is going on? I have definitely noticed some of the chunk loaders not working which is what got me looking in the first place. Help!

commented

I:"Chunk Loading Radius"=3

commented

That's what I thought.

I might have a solution, but I'm not certain.

commented

I am no programmer, but I was looking at code for chickenchunks, and one thing I noticed is that he doesn't look for Y coords when assigning a ticket, just X and Z. Could this have anything to do with it?

Again, not a programmer so this may be nothing :P

commented

Give this file a try?

I found (through debug) that each chunkloader was registering two tickets... not sure why. Hopefully that'll help with eating through all the tickets.

commented

I've noticed this as well, actually. I'll see if I can come up with a fix, I wonder what's going on...

I'll keep you updated - I've got a very busy next couple of weeks with school and school-based programming projects, but hopefully I can find and squeeze in a fix soon!

commented

Ok, that was a quick response!

I am going to try increasing the ticket count in the mean time in the Forgechunkloading.cfg and see if I can find a large enough number to keep it happy.

commented

I've found this to be a "solution", but I feel like (especially with my lack of expertise), it's a problem on my end with how I'm generating tickets. I'm going to take a break from studying for my Comp-Sci ethics class to see the loop constructs I use and make sure I'm not generating unnecessary tickets :)

commented

Also, unrelated to this issue, have you had any luck with the RFTools dimension loading issues? I don't use them, but I am having a similar problem with it loading chunk loaders in mining dimensions created with the Utility Worlds mod. Server starts, but they are not loaded until I visit the dimension they are in. Just curious, I know you are busy with school and such, but I didn't see it mentioned anywhere.

commented

It's been mentioned on my twitter like.. once. It's a big concern for me, actually, because I use RFTools Dimensions myself, and it's a huge nuisance.

But - I have NO Idea how to work around it. @McJty, any ideas how I'd go about waiting for a dimension to be loaded to start chunk-loading it?

I've tried Forge Events, but the Load event doesn't work with your dimensions still, unfortunately (I've tried it with unoptimized code that I know should work, and it didn't).

commented

It would help me to know - what radius config do you have set for the PB Chunk Loaders? Currently, referring to this code, it forces chunks with the same 1 ticket (labeled with the x, y and z values of the chunk loader) across all of the chunks its radius covers. I.. think? - this is standard practice.

This is my first venture into chunk loading, and unfortunately it doesn't look like any other mods (open or closed source) do it plainly enough to really use for guidance.

commented

The reason they are registering 2 tickets each is because the ForgeChunkloading.cfg is set to use 1 ticket per 25 chunks, however, when you have Persistent Bits set to a radius of 3 the area is 7x7 which is 49 chunks total. It must utilize 2 tickets to cover this area, 1 ticket would cover 25 chunks while the other would cover the remaining 24. Intended behavior.

As for the TEST version, well, the chunkloaders do not even load and I see this error in the log now:

[18:03:23] [Server thread/ERROR] [PersistentBits/PersistentBits]: There was an error in the code for deserialization. Please contact oitsjustjose on GitHub with a log
[18:03:23] [Server thread/ERROR] [PersistentBits/PersistentBits]: com.oitsjustjose.persistent_bits.chunkloading.DetailedCoordinate
commented

Uh oh.....

Uhhh, try this dev build instead?

I reverted my code but added debug output this time to tell you how many tickets free are left. The default forge chunkloading cfg should be 200 as you mentioned. In my testing, I placed 3 loaders down, and the output was 197.

And it makes sense what you're saying about needing 2 tickets, but I was worried because each ticket's values were the same chunks... that's why I put in my duplicate check. Sorry this has been such a crapshoot, especially because I've never experienced this bug myself.

You may try locating and re-placing all of your chunk loaders. That's not my preferred solution, but it might, just might work.

commented

Well, I have been playing around with ChickenChunks and Persistent Bits and I have noticed a few things. ChickenChunks has a viewer for looking at chunkloaders (/chunkloaders command) and it appears that your chunk loaders aren't loading the entire area. Also, by NBT Editing the forcedchunks.dat located in world folder, I am able to see the cause of the ticket issue. It appears you are not releasing the tickets when a chunk loader is broken. The number climbs every time a chunkloader is placed but does not lower once it is broken. As we had been using them in conjunction with a digital miner in various parts of our world, this makes sense as to why our ticket count had gotten so high.

I wish you the best of luck getting this fixed, but for now I think I am just going to use the updated Chicken Chunks mod. No hard feeling I hope.

commented

HOLY CRAP YOU'RE RIGHT.

I just fixed that. Thank you SOOOOOOOOOOOO much for letting me know!!

commented

no problem, glad I could help!

commented

I've made quite a few changes recently, so I'm testing 1.0.6 in my single player world before I go pushing an update to the masses. Once again, thank you very much for all of your help, I for some reason thought the ticket was already being released when the block was broken, but I guess I forgot to implement that!