First of all, I want to say that the gregtech mod changed my life. I love it very much, I’m with you from GT4. This is a colossal job! Thank you very much.
GT6 I can’t work with the miniature nether portal. In a single player game everything works, but not on the server. I use the thermos core. Chunk was loading anchors. The portal simply does not communicate. Tried different coordinates. I even set it to 0 0 in both worlds. Maybe you need to configure something in the thermos configs?
How close to 0 0 are you exactly? I wonder if one Portal has positive Coordinates and one has negative Coordinates, and that is why they dont want to connect to each other.
Has to do with differences between vanilla/forge and bukkit.
From GT_API_Proxy:
@SubscribeEvent(priority = EventPriority.LOWEST) public void onWorldSave (WorldEvent.Save aEvent) {checkSaveLocation(aEvent.world.getSaveHandler().getWorldDirectory(), F);}
(Plus other events that call checkSaveLocation)
On forge that getSaveHandler().getWorldDirectory() gives you the base path of your world (i.e. ./greg6-world, while it gives you the ‘level’ path for bukkit (i.e. ./greg6-world/DIM-1 if the event is from that ‘level’ (that is, dimension), vs ./greg6-world which you only get for DIM0 in bukkit).
It works that way in bukkit due to historic reasons, and bukkit/forge hybrids keep it for compatability I assume. Or perhaps it has never been a problem since few mods seem to care about the actual save location.
GT_API_Proxy#checkSaveLocation() compares the passed in File location with a stored one, and it will think the world has been changed if they differ (which they will since you get one for each dimension and they never match.
GT_API_Proxy#onWorldTick() also uses checkSaveLocation() to handle TileEntities that do care about worlds, like miniature portals. If they think the world has changed they will invalidate the per-world list of active portals, and this will happen like every second so portals never get a chance to connect…
(plus it will spam your gregtech.log with “Loading world!”/“Saving world!” every second, filling that up…)
Personally I worked around it by just changing GT6 slightly, I have no idea how much this breaks things like multiverse2 and what not… 
But it does work around the problem on bukkit hybrids (I’m using a slightly modified Crucible build)
gt6.diff.txt (2.7 KB)
Sorry but your Theory on that is absolutely bogus, I only use that Event to reset the Mini Portals in the event of “exit to main menu, then load a different save file”, which is purely for singleplayer bug prevention, and therefore completely unrelated to anything Bukkit/Cauldron/Etc in this particular bug report.
Obviously, this might fix some OTHER bugs, just not this one.
Oh sure, I’m not versed in the codebase so I’m sure I’m missing a lot here 
But I did have the same bug with portals refusing to connect on bukkit, while just using the pure forge.jar as a server made the portals work.
Debugging led me down this path.
in the event of “exit to main menu, then load a different save file”
checkSaveLocation() gets called all the time in onWorldTick()…
https://github.com/GregTech6/gregtech6/blob/master/src/main/java/gregapi/GT_API_Proxy.java#L651
On vanilla/forge that call in onWorldTick passes in ./world-name no matter the dimension, so there’s no problem. But on bukkit where the getSaveHandler().getWorldDirectory gets you ./world-name for dim0 and ./world-name/DIM1 for The End, and so on, there’s a problem.
mSaveLocation might have stored ./world-name/DIM-1 (the nether) from the previous call, and now the event is from say ./world-name/DIM-42 (the outer lands).
We now have a mismatch in checkSaveFile, mSaveLocation and aSaveLocation don’t match.
https://github.com/GregTech6/gregtech6/blob/master/src/main/java/gregapi/GT_API_Proxy.java#L193
MultiTileEntityRegistry.onServerSave(mSaveLocation) gets called (every second), and ultimately (I don’t know the whole callstack) MultiTileEntityMiniportal#onServerSave() gets called which clears both portal lists.
Please correct me where I’m wrong.
Wait something might spam this function resulting in constant reset of that list BEFORE the portals can connect to each other using the list…
It may or may not fix it, but you’re still gonna have this…
gregtech.log (20.3 KB)
Every single second it’s gonna dump a Loading World!/Saving World! line, for every dimension, into your logs/gregtech.log.
It’s why I did it the easy way and asked the DimensionManager for the root dir of the current world. It returns the same base save directory on both bukkit and ‘vanilla’ forge, so the mismatch isn’t triggered and the log isn’t spammed, plus it fixes the portal ‘bug’.
But I can check if the CODE_CLIENT conditionals at least make the portals work, gimme a second…
Yeah CODE_CLIENT means it will only do that in Singleplayer, since Servers only ever run once.
Yeah, a quick test between the nether and overworld worked for me atleast.
But that’s quickly gonna bloat the logs 
gregtech.log (223.6 KB)
That was a few minutes of testing.
Yeah I wanted to fix one thing at a time, the logs thing needs fixing too. ^^
by the way the reason i called your thing bogus at first was because i thought your FIX was doing this, and not my unfixed version. Just to clear up that misconception ^^
Yeah, it’s fine 
Wait something might spam this function resulting in constant reset of that list BEFORE the portals can connect to each other using the list…
Yes. I guess that means it wasn’t impossible to make the portals “work”…
If you lit up a portal, changed dimension and lit up the other portal - all within at most 1 second, before all activated portals got removed from the Lists - you could have had them be connected for a few ticks… 
Yeah if you’re fast enough in activating the Portals (like within the same damn Second), it will work.
Anyways, I think the Secret Version should have this and the Log spam fixed now. ^^
Well, it doesn’t spam the logs and portals work.
But… when all the dimensions are loaded on startup,
Dimension 7/Twilight Forest ends up being the first loaded ‘world’ (for me), so that’s what gets stored in mSaveLocation since its onWorldLoad() gets called first
Loading World! ./greg6-231006/DIM7
So now the endergarbage.*.dat and certificates.dat end up inside ./greg6-231006/DIM7/gregtech
gah, thats annoying… guess i need to try fix THAT too. I hope DIM 7 is at least consistent for you lol
Okay I looked at your diff again and am now using DimensionManager, its working properly now. Shit like this is so damn hard to find because the “Call Hierarchy” tool does not work well on Vanilla Client/Server stuff…
Not sure what decides the event order, but it seems stable and DIM0 gets events last.
Anyways, that works for me, thanks. And hopefully should work for @ananta69g as well.
Oh yeah. It’s great. The portal now works well. I fed my base with lava from hell. Thank you both very much! @Gregorius @Nanitozoo