Tip: Layer 3 backgrounds and tides disappear when you hit a message box, so plan your level around that. For example, you can add a sublevel without layer 3 at the start/midpoint, and include your message there.
Brought to you by RPG Hacker and randomdude999 with contributions from boldowa (6646), zetaPRIME, Horrowind, TheBiob, BenJuan26, Vitor Vilela, KevinCathcart and KungFuFurby.
Very fancy changelog and manual. You can check them out here and here.
I wrote a Python binding for the Asar DLL
New defined() function and undef command, which check if a define is defined and allow you to delete existing defines
Syntax highlighting file for Sublime Text
If you start a label with #, it won't modify existing label hierarchies
Include search paths, which will be searched for files to include when a file with that name isn't found using the usual means.
"standard include paths" and "standard define" files, which will be read for include paths/defines and usable in all files
The DLL's asar_patch function has a much more configurable variant called asar_patch_ex, check your wrapper's source code for more info
You can do pushbase/pullbase now because one person wanted that
You can escape ! by using \!, and \ with \\
You can check the title of the ROM you're patching to using the new check title command
You can nest namespaces now, enable it with namespace nested on
You can disable bank cross checking with check bankcross off
New filesize() and getfilestatus() functions that you can use to check whether a file exists and see its size
You can manually set defines now with -Dname=value on the command line
You can put @includeonce at the start of a file to prevent it from being included multiple times (everything after first include of it will be ignored)
Also includes tons of bugfixes, check the changelog. Most notably, fixed the freedata align freeze, and SA-1 overwriting some banks randomly sometimes.
It's nice to see that the new version of asar is finally done! Some of the new features like #Label, check backcross, etc. are going to be very useful for some of the things I've been working on, and I'm also really glad that the canreadfile/readfile crash has been fixed!
Hey! While most of these features won't find any use by a majority of users here, I'm sure that they're a welcome addition for the few that will. Besides, it's always nice to see some bugfixes along the way, too. Well done, you all!
-------------------- Having problems with another user on our Discord server? Don't hesitate to message me here or on Discord.
Heck yes new viking helmet!
The #Label function seems very promising. Do you have to refer to it with the # as well? If you want to load the address for whatever reason, do you have to do LDA ##Label?
Nope, if I remember correctly, you only use it when you declare it. That made the most sense to me to solve the particular problem this type of label was made for. So something like this should work:
I assume you only mean the errors, not the warning, right? I think the warning was already in previous Asar versions and is a result of that one macro's expansion leading to a negative rep. I assume you're aware of that, so in this version you can now actually disable this warning via
Code
warnings disable W1018
As for the errors, I think those are a result of "fixing" the way the sizeof() function works in Asar, leading to an incompatibility that was overlooked and thus not documentated (might want to either add this to the manual or restore the old code and throw a deprecation warning). In older versions of Asar, this function was just kinda hacked in there. Newer Asar versions, however, have specialized support for string parameters in functions, but this requires passing them to the function delimited by double quotes. Since I cleaned up some of the hacky code in Asar, I've changed this function to work like other functions and take regular string parameters, but forgot to mention this anywhere. So in other words: I think changing those calls from a
Code
sizeof(tree)
to
Code
sizeof("tree")
should fix the problem. Thanks for pointing that out (hope that doesn't cause any incompatibility with any existing resources on the site - not sure how widely used that function has been here):
It does fix the problem, but (in my opinion) it's kind of a strange workaround. sizeof("tree") makes me think that I'm getting the size of the literal string "tree" (4 bytes) rather than the struct(/label). Isn't there a way to make it support both labels and strings and any other type?
Other than the problem I have encountered though, I'm really, really glad to see that asar is actively being worked on.
Isn't there a way to make it support both labels and strings and any other type?
That's tricky to answer. I mean from a purely technical standpoint, there probably is (after all scripting languages like Ruby or Python do just that), don't know how easy it would be to add to Asar. I mean Asar doesn't really have a concept of types and it was something I literally added myself to support functions like readfile() etc.
There definitely needs to be a validation at some point, because otherwise there's nothing to prevent a user from passing a number to readfile(), for example, likely making Asar crash (trying to access a double as a string pointer). I think I mainly used the double quote delimiter because it was easy to parse and because it made it possible to check the typing of a parameter before actually using it. I think not requiring the delimiters would require one of two things: either add some kind of guessing algorithm (like "everything that's not a number or a function call is a string"), which seems kinda shaky to me, or let each function evaluate their own parameters themselves, which would be more reliable, though I'm not a fan of that solution (it's basically what sizeof() used to do).
One thing I like about the double quotes is that they're pretty reliable and easy to parse, while also clearly communicating the coder's intention to the program (aka whether they meant a string or something else). I kinda like this from the perspective of code clarity, but on the other hand I'd also like the function to remain backwards-compatible, so I kinda have two conflicting opinions on this. Though one thing I'd definitely like to avoid is what the old sizeof() function did, which basically had its own parameter validation with its own error message. If we added support for untyped parameters back, I'd still want it to work with a generic implementation of parameter validation to make it easy to add new functions to Asar. In other words, this code at the beginning of the sizeof() function
Code
validateparam(structname, 0, Type_String);
should still work as expected and be the only bit of code needed to validate the function's parameter, so if a solution to this could be found, I suppose it would have to be within the context of this validateparam() macro. Can't quite say how simple that would be to do without looking into it further, though.
1 
Some of the new features like #Label, check backcross, etc. are going to be very useful for some of the things I've been working on, and I'm also really glad that the canreadfile/readfile crash has been fixed!
Follow Us On