Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chunk gets unloaded when dialing from computer interface #152

Open
drzpk opened this issue Apr 29, 2020 · 21 comments
Open

Chunk gets unloaded when dialing from computer interface #152

drzpk opened this issue Apr 29, 2020 · 21 comments

Comments

@drzpk
Copy link

drzpk commented Apr 29, 2020

When I'm trying to dial a distant Stargate (on unloaded chunk) using OpenComputers interface, the dialing sequence gets interrupted before a wormhole is established. However, dialing exactly the same address via a DHD ends successfully.

I did some debugging (using the most recent version built from sources) and it turns out that chunk unload event is fired on the chunk I'm dialing to and that interrupts the dialing sequence. I compared code of dialing from DHD and computer interface and there is indeed a difference, I don't know the internals of this mod to pursue this further, though.

@KamaroTheN7
Copy link

Well, I have this same problem, but when I created respond I got was "You probably have mod, that changes chunk loading", that was true, so I give up, but today I checked it with only Stargate Network, malisiscore and OC, and it still happening.

@KamaroTheN7
Copy link

@ilynPayne A tak w ogóle to fajny twój program wybierający.

@Dockter
Copy link
Member

Dockter commented May 7, 2020

In your configuration files, under "options:", what do you have I:chunkLoadingRange= set to?

@Dockter
Copy link
Member

Dockter commented May 7, 2020

@drzpk
Copy link
Author

drzpk commented May 7, 2020

It's set to 1, I've never modified it. But you assumed otherwise, hence the beta-3 artifact. Well, I tested it anyway and - surprise, surprise - it didn't work. dialing still gets interrupted.


Please take a look at this issue, especially the code snippets. Mine, called from the Lua shell, doesn't work, while @dallenwilson's does.

@Dockter
Copy link
Member

Dockter commented May 7, 2020

I'm making some assumptions as I have no way to test this exactly with your environment. I have not been able to replicate this in my environment but I am not using CC. Looking at how the chunk ticket is created is "SHOULD" keep the gate active.

I need you to give me a thread dump at line 578 of SGCraft.java.

@Dockter
Copy link
Member

Dockter commented May 7, 2020

I could create a debug build specifically for you. Talking with another developer we're curious if you're hitting the max chunk ticket threshold. That would cause this issue as well.

@Dockter
Copy link
Member

Dockter commented May 7, 2020

Pull down this commit: b1937cc and compile. Tell me if you're seeing that debug line during dialing.

@Dockter
Copy link
Member

Dockter commented May 7, 2020

Actually no, that can't be the issue either because you specifically stated using the DHD works fine....
WTH...

@drzpk
Copy link
Author

drzpk commented May 7, 2020

No, this message you've just added didn't show up.

I uploaded the thread dump you asked for (with breakpoint at SGCraft:579, b1937ccf). I also managed to reproduce this error using the world save uploaded below (SGCraft started from Intellij and dependency mods only, no other mods were used). There's an OC setup somewhere around X=33, Y=72, Z=309, just repeat the last command.

threads_report.txt
chunk_loading_test.zip

@Dockter
Copy link
Member

Dockter commented May 7, 2020

Curious. Zidane was thinking the mod to blame would be in the trace, yet SF is in the trace....

@Dockter
Copy link
Member

Dockter commented May 7, 2020

If I load this saved world, can you tell me how to tell the computer to dial out?

@drzpk
Copy link
Author

drzpk commented May 7, 2020

The Lua shell currently is running in the dialing computer and the last command I entered was sg.dial, so just like in a "real" shell, pressing arrow up and then enter will execute it.

@Dockter
Copy link
Member

Dockter commented May 7, 2020

testing now....

@Dockter
Copy link
Member

Dockter commented May 7, 2020

OK, issue confirmed.... working through this.

Dockter added a commit that referenced this issue May 7, 2020
@Dockter
Copy link
Member

Dockter commented May 7, 2020

@drzpk
Copy link
Author

drzpk commented May 8, 2020

Now gates are working fine, no interruptions whatsoever, thank you.

@Dockter
Copy link
Member

Dockter commented May 8, 2020

Thanks goes to you for creating a way for me to perfectly test this. I had researched this previously but could never reproduce it. You're the reason this is fixed for everyone else.

@Dockter Dockter closed this as completed May 8, 2020
@Dockter
Copy link
Member

Dockter commented May 20, 2020

This issue is not fixed with 2.0.4.....

@Dockter Dockter reopened this May 20, 2020
@LemADEC
Copy link

LemADEC commented Jul 8, 2020

For the record, creating a Forge chunk loader ticker doesn't load the chunks immediately. As such, in your forceChunkRangeOnTicket method, you might want to do a World:getBlockState() in each chunks to force the loading so the rest of mod doesn't have to deal with that mess.
Also, it appears the ticket is released and recreated when the gate state is changing. When releasing a ticket, forge may unload the chunks immediately under certain conditions & configurations, causing a whole of issues (memory leak, lag spike and state desynchronization). I suggest to keep existing ticket with its chunks instead of releasing and creating a new ticket.

@Dockter
Copy link
Member

Dockter commented Jul 22, 2020

I think Zidane added an appropriate fix for this. I am including in the 2.0.5 build to be released tonight, give that a try please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants