i need help fixing the Stuggers 667 map editor tool I'm 90% done fully refactoring

Hey, can anyone help me with Stuggers 667 map editor tool, specifically refactoring broken decompiled code?

90% done fully refactoring the Stuggers 667 map editor tool to make the tool work as intended for everyone.

I've almost got it perfectly working now.

I've made a ton of progress on the Stuggers 667 map editor tool and I pushed a new very nearly fixed version of the project to my GitHub repo:

see if you can get the map objects to render properly when loading a map region? I can't see the map objects when loading a map region area currently, but other than that I got it fully working. I just can't see the map objects now, unfortunately, but I can't seem to figure it out myself and it's driving me crazy.

Check out the README file. It explains the current status of the project and the progress I have made so far, plus the issues we encountered with the map objects not being rendered correctly in the map editor tool.

I'm not a Java developer and have minimal Java coding experience, but over the last year I have made significant progress. However, I'm not sure how to fix the current issues with the current project state not properly rendering map objects.

Brief explanation of the original Stuggers 667 map editor project sent to me originally by Stugger

- The project originally was a Matrix 667 client-server project. Specifically, it was based on a ScapeSoft 667 RSPS client and server project.

- When this map editor tool was originally sent to me, it was in the form of a client and server, both in JAR format. The basic usage was to first run the server JAR, then run the client JAR. Then, if the user was properly authorized and authenticated, it would allow the client to connect to the server and the user would be able to use the map editor as intended. But if not properly authorized, the client would freeze at 7% of the loading-up process.

- The original project used a somewhat strange and unconventional Dropbox SDK file-based method of determining if a user has the appropriate authentication to utilize the map editor tool. (I'm not exactly sure how it originally worked, but something to do with checking if your MAC address matched an existing file within a Dropbox folder or not. If the user was authenticated, it would find the matching Dropbox file and you would be authorized to use the map editor tool.)

Things I've completed so far

- Decompiled the original JAR files from the original Stuggers 667 map editor tool.

- Refactored and completely removed the old Dropbox SDK authentication system the original project used.

- Created a multi-module Gradle project for the code that automatically builds the JARs and places them into the appropriate folder that contains all files the project needs for running.

- Got the project to a point where it allows the client to properly connect to the server, completely bypassing the original authentication method. The project now lets you load the map editor properly and allows the user to open a map region.

The current state of the project has the following issue

- When loading up a region area, the map loads as intended but doesn't properly render the map objects within the map region due to broken decompiled code that is rather hard to understand because of the project's original 667 client's spaghetti code. I'm not sure where the map object rendering code is even located within the project.

remember there may be a lot of broken code not specifically pertaining to object rendering but throughout the codebase you may find other places that the code may still need more refactoring to fix broken or incorrect decompiled code feel free to fix any issues you find