I've added a new tool to SonLVL's updater that will allow you to load two object layouts, compare them, and select which objects you'd like to include in an output file. If you load Layout A from a SonLVL project, it will also display a preview of the level, highlighting objects that exist only in A in red, and objects that exist only in B in green.
As of late, just about every time I open up SonLVL to do something, it takes a good minute or two to attempt an update, and then that message appears. Is any one else having this problem? It's happened to me on multiple machines and on multiple connections.
Maybe your antivirus software is blocking my website? Maybe you've just had really bad luck and my site's been down every time you opened SonLVL. If it really bothers you, you can move the SonLVL Updater into a different folder and SonLVL won't attempt to check for updates anymore. I might also be able to reduce the timeout period.
Happy Birthday MainMemory! I've been trying to get back into the hacking scene lately with Mercury's handy-dandy ReadySonic disassembly; however, while it is based on the Git S1 disassembly and I have been able to use SonLVL with it in the past, I receive an error when I try to load any act after Spring Yard 3. I did a search and couldn't find the error anywhere in this thread, but if you've seen it before, maybe you know the problem.
There should be a "Report Issue" button somewhere on the error message, which will bring up a more detailed error report. That particular error is extremely generic, and gives no helpful information on its' own; nearly anything can cause it...
Good to see you again, Pacguy. Thanks for your input, I haven't been able to replicate this error any other way so I didn't think it would be common. I'll log into Github and submit the issue.
I think I've seen that issue before, it's a problem with one of the object definitions, but I don't really know how to fix it, other than just deleting that particular definition. I'd kind of hoped that maybe someone could have fixed it by now. Edit: Oh, wait, levels after SYZ3? That's a new one, hm.
Well, I just checked, and it doesn't happen with any of the levels in a plain S1 GitHub disasm, so something in ReadySonic's mappings data doesn't agree with SonLVL. I looked into an issue like this once, and the problem was that ReadySonic injects a bunch of conditional assembly blocks into its mappings, which SonLVL isn't equipped to handle. For that reason, I don't officially support ReadySonic in SonLVL. Basically, you have two choices: remove the offending data from the mapping file(s), or disable the object definition(s).
Sorry, but what's wrong with this update, seriously? Some objects become question marks (unknown objects), such as bridges or rings, and the "Sonic" object no longer appears at the top of the list.
Well, I've changed the sprite format and the object definition API a bit, so that's probably why the objects appear as unknown. Objects are now sorted by ID, as it was previously random since I switched to multithreaded loading. I suppose if it really bothers you, I could try to sort objects by INI order. Also, why do you even need a Sonic object at all?
Okay, but how can i restore their appearance? Because this is really annoying. At worst, can I go back to an earlier version?
You can restore their appearance by rewriting the object definitions to use the new APIs. I would suggest looking at the changes I made to the definitions that come with SonLVL: https://github.com/sonicretro/SonLVL/commit/9de9485eaaab0a07459861889ad27434e4304160
SonLVL now has support for displaying (not editing) animated art. Before you ask, no, the art isn't animated in the editor, that would be way too intensive for my current drawing system to handle. Currently only the S1 and S2 GitHub disassemblies are equipped with the data to support it. Unfortunately, due to the way certain animations are set up, I've had to include several binaries in the project files, so the art in the editor may not always reflect the art in the ROM. All animated pattern mappings/blocks in S2, because I can't parse the ASM as it is in the disassembly. The GHZ flower stalk, because it's compressed. The MZ lava, because it's stored in a weird format that I can't copy directly into the art. Sonic 3 & Knuckles will have support as soon as Neo is finished with the object definitions.
But in the case of the binaries specifically, they could be ported manually or the project files for them could be re-pointed to the in-source files, couldn't? Looks awesome, anyway!