Lunar Magic suggestions and discussion (LM v3.40) - Resource & Tool Releases

Originally posted by simon.caio

I don't know if this is just me, but I needed several times to change the same color in every level I already edited, sorta global color change...but didn't know how to change it other than manually and that is very tedious. Isn't there another way of doing that and if not, would it be an idea to add that possibility?

There isn't. Thing is, I don't think that would come up very often...

Originally posted by simon.caio

Another thing if I may ask: Probably somebody already brought this up, otherwise it would be strange if not - but, from what I know there are some windows in Lunar Magic which, when opened, you can't do anything else in Lunar Magic, other than change things in that active window, for example the "Super GFX Baypass Dialog" or the Edit Animation Window...more often than not, it feels not right and more steps/work to do than necessary - closing the window to open another one, to open again the animation dialog for example or close the super gfx bypass to check the exgfx numbers to close it, to open it again in another level...Is there a reason why this made in this way? Would it be an idea to let the window be active/open and be able to shuffle through level and/or do other things meanwhile?

It isn't brought up because it's considered perfectly normal behavior for many programs. Making all 100 or so of LM's windows able to remain open and updated at all times means added complexity and development time. For the majority of them, there's little reason to bother with it.

Originally posted by Anas

I noticed that for some reason, if you're in 2bpp mode and are ExAnimating a bunch of 2bpp stuff, you have to divide your actual tile destination by 2 in hex. Issue is, what if you need to put something in tile 0x165 instead of 0x164? This is where a semi-major problem will arise. Since 0x165 & 0x164 both divide the same, you can't put your stuff in 0x165... I might be able to work around this scenario, but this can't always be done. Are you going to fix this odd limitation? I just noticed as I was preparing some 2bpp animations for a mode 0 FG.

You can specify a direct VRAM offset to get around that. For example, tile 0x165 in 2bpp mode would be 10B28 (0x165*8+10000).

Originally posted by Runic_Rain

You are amazing. This is exactly the functionality I needed. Lack of save and everything. So good. Thank you!

You're welcome.

i was wondering if it'd be possible to implement rudimentary custom object display, with an external file like custom sprites have for properties/description/etc. i know few people use those, but they're way too useful in reducing level size and setting up complex elements (ex: a floor whose tiles alternate, a collectible that turns into an outline when obtained, etc) to stay ignored imho.

fully functional display of custom objects is certainly way too complex, but given how custom normal objects use their size byte in a standardized way (yyyyxxxx), and how custom extended objects have a fixed size, i think it'd be neat to have, say, something as simple as colored rectangles that display an id and show a custom description when hovered.

quick mockup :

Code

99 008F00 2,2 "A large 32x32 Star Coin, that behaves like a Dragon Coin."
02 F70BE1 "A solid rock of adjustable size."

Originally posted by mathie

i was wondering if it'd be possible to implement rudimentary custom object display, with an external file like custom sprites have for properties/description/etc. i know few people use those, but they're way too useful in reducing level size and setting up complex elements (ex: a floor whose tiles alternate, a collectible that turns into an outline when obtained, etc) to stay ignored imho.

fully functional display of custom objects is certainly way too complex, but given how custom normal objects use their size byte in a standardized way (yyyyxxxx), and how custom extended objects have a fixed size, i think it'd be neat to have, say, something as simple as colored rectangles that display an id and show a custom description when hovered.

quick mockup :

Code

99 008F00 2,2 "A large 32x32 Star Coin, that behaves like a Dragon Coin."
02 F70BE1 "A solid rock of adjustable size."

I second this! It looks simple yet effective enough to identify properly instead of a garbled mess of tiles.

My Mode 0 guide.

My Discord server. It has a lot of archived ASM stuff, so check that out!

I third this.

This shows some of my custom objects, and it is impossible to tell where they meet another object, such as intersections, or when they happen to form a straight line. The picture on the right shows what the object looks like in game.

Filler

Even though you're very much annoyed by this, I fourth this since someone mentioned a that CDM16 allows me to replicate some of the conditional objects one can create with ObjecTool but one also can't forget that this doesn't encompass everything and aren't edge cases either (most notably, item memory which just can't handle with CDM16). The biggest issue IME is the priority between overlapping objects because these do require an object having a specific size, else you'd have to hack around them to be placed the way one intends.

Here is a quick and dirty mockup of what my previous objects could look like.

Filler

Originally posted by mathie

i was wondering if it'd be possible to implement rudimentary custom object display, with an external file like custom sprites have for properties/description/etc.

Make sure to first check the rejected list in the first post of the thread here.

You say that there's no reason to bring up rejected topics unless there is a change in circumstances. As far as I'm aware, the reason given for not implementing custom object display originally was that you weren't sure if many people would bother with them. Given that there is now plenty of evidence to the contrary, it seems valid to assume that the circumstances have in fact changed, so there is reason to bring it up again.

It appears you didn't read the post linked to in the rejection list for that one.

Originally posted by FuSoYa

It appears you didn't read the post linked to in the rejection list for that one.

I did actually. In fact, since you said "See previous discussion or two on the topic from a couple years back." a few posts above that one, I went through the trouble of searching for previous discussion on the topic, in which you claimed that you're not sure yet if many people will end up using custom objects (to save space).

Your linked post also, in my opinion, incorrectly presents your own opinion on the usefulness of custom objects (and/or them being displayed correctly) as "consensus" when plenty of other people involved in previous discussions or the current one would disagree with that sentiment.

You can count me in for the people that would support having custom objects implemented into LM. Honestly, at this point, there likely aren't many major things left that realistically could be added to LM. Other than maybe ExGFX Revolution, making it possible to expand the number of available sublevels, or some of the rejected features, what else is left at this point? Custom objects may not necessarily be a big deal, but I could see them being pretty useful. Not just by saving on ROM space, but it would reduce the amount of map16 tiles you'd need for a custom FG. They'd make things like non-rectangle coin formations and slopes less cumbersome to work with. Not to mention, the object system is basically a scripting language with all the benefits that brings, which could have interesting applications for changing how a level loads (ex. You could skip loading entire objects if a flag is set to heavily alter the appearance of a level without needing to make a duplicate of it). Plus, it'd be nice to have a way for LM to still be able to display objects correctly even if the underlying object system is changed in a way that would cause LM to display the vanilla objects wrong (sooner or later, someone is going to be crazy enough to do that, seeing as how the object loading routine could be more efficient).

--------------------

Also, I have a couple of minor suggestions for you:
- I think the overworld lakitu sprites should display a shadow in the overworld editor. They do in game, so it's a bit odd they don't in the editor.

- Could you add a setting bit to the table at $0FFFE0 that, when set, tells LM to "lock" the overworld editor? I'm working on a patch that completely overhauls the overworld in a way that's incompatible with the overworld editor. It'd be nice to be able to prevent the user from accidentally editing the original overworld by having LM disable most of its overworld functionality. The only exceptions being the layer 3 editor, title screen stuff, and the text editing (You should also change the text editing so it doesn't require saving the overworld to apply those changes).

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

Hello, FuSoYa. I have a suggestion about Bitmap Pasting.

Since I use this feature quite often, having a checkbox like this would be useful .

The process of every time going to the overworld, Change Events passed and then typing "Give me presents!" is a bit tedious. Would be good to have an option to enable it (it could be disabled by default). It's a very handy tool for me and other folks who like to rip graphics.

Originally posted by underway

I did actually. In fact, since you said "See previous discussion or two on the topic from a couple years back." a few posts above that one, I went through the trouble of searching for previous discussion on the topic, in which you claimed that you're not sure yet if many people will end up using custom objects (to save space).

While it's good that you spent the time to read up on some of the past discussion, I'm afraid there's always been some people interested in it so that's not really much of a change. The linked post already describes how it doesn't add a lot.

Originally posted by underway

Your linked post also, in my opinion, incorrectly presents your own opinion on the usefulness of custom objects (and/or them being displayed correctly) as "consensus" when plenty of other people involved in previous discussions or the current one would disagree with that sentiment.

That was someone else's word, not mine. I was tempted at the time to point out that LM isn't developed by "consensus", but I didn't bother. It wasn't the first time that someone had assumed LM is some kind of community run project even though it isn't.

Originally posted by yoshifanatic

- I think the overworld lakitu sprites should display a shadow in the overworld editor. They do in game, so it's a bit odd they don't in the editor.

Yes, and probably the blue bird too. I don't think I even initially added sprite shadows to the overworld until I put in the April 1st easter egg years later.

Originally posted by yoshifanatic

- Could you add a setting bit to the table at $0FFFE0 that, when set, tells LM to "lock" the overworld editor? I'm working on a patch that completely overhauls the overworld in a way that's incompatible with the overworld editor. It'd be nice to be able to prevent the user from accidentally editing the original overworld by having LM disable most of its overworld functionality. The only exceptions being the layer 3 editor, title screen stuff, and the text editing (You should also change the text editing so it doesn't require saving the overworld to apply those changes).

I'm not entirely sure that I'd want to lock it out completely. Maybe just display a warning if the user tries to save. As for text editing... eh, I guess there's a number of different possibilities with that. Would have to think about it for a while to decide what/if I want to change things there.

Originally posted by Anorakun

Since I use this feature quite often, having a checkbox like this would be useful . The process of every time going to the overworld, Change Events passed and then typing "Give me presents!" is a bit tedious. Would be good to have an option to enable it (it could be disabled by default). It's a very handy tool for me and other folks who like to rip graphics.

Nice to hear that you're getting some use out of it.

I'd probably rather just enable the feature rather than have an option like that, but I'm still reluctant to do so without adding a few more color conversion methods. Oh well, maybe one of these days...

Originally posted by yoshifanatic

Honestly, at this point, there likely aren't many major things left that realistically could be added to LM. Other than maybe ExGFX Revolution, making it possible to expand the number of available sublevels, or some of the rejected features, what else is left at this point?

Well, one other feature that we don't have is the ability to properly display and edit levels that use BG modes other than 1. Level modes 03-06 aren't fully implemented either.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.

Originally posted by FuSoYa

(words)

LM not being developed by consensus is the opposite of something to be proud of. like it or not, it has become the centerpiece of a sizeable community, and it will remain as such for as long as a viable alternative isn't available.

there is no reason, nor moral nor practical, for such a vital asset to this community not to be run and maintained by it as whole. LM should have never been, and does not have to remain an exception to this.
what you consider "useful", "worth implementing" or "minor" is irrelevant. a tool's primary purpose is to align with its users' needs, not its manufacturer's. LM being developed solely in your spare time has no bearing in this.

your difficulties in managing LM as a project, meeting its userbase's demands and dealing with the responsibility of maintaining a tool necessary to an entire community's existence will always have a single, simple solution, even if "your decision has already been taken". i'll spare you the insult of naming it.

I don't feel particularly strongly about this either way, but I don't really understand what makes a feature useful vs not here. It feels rather arbitrary especially considering other than developing lunar magic you don't really interact with the community around it outside of that, so how would you know what is useful to the people who use it? That last hack you made as far as we know was 20 years ago, which I would at least understand the reluctance to incorporate some sort of community "consensus" if you were developing the tool for your own needs, but that doesn't seem to be the case. It's just really confusing.

Originally posted by FuSoYa

Yes, and probably the blue bird too. I don't think I even initially added sprite shadows to the overworld until I put in the April 1st easter egg years later.

Yeah, I meant to say both the lakitu and the blue bird there. I don't know why I said lakitu sprites, as if there were more than 1 in the overworld editor. XD

Also, another thing, but when I was recreating the overworld sprites to display in the level editor for my patch, I noticed there wasn't a way to edit the appearance of custom overworld sprites. Unless I missed something, perhaps that's something else you could add?

Originally posted by FuSoYa

I'm not entirely sure that I'd want to lock it out completely. Maybe just display a warning if the user tries to save. As for text editing... eh, I guess there's a number of different possibilities with that. Would have to think about it for a while to decide what/if I want to change things there.

Do whichever way you think is best. Also, I brought up text editing since I had to implement a way to edit the message box and castle destruction text in my patch just to work around the fact that LM forces you to save the overworld to do so. I didn't want to force the user to download a separate patch just for that.

Originally posted by FuSoYa

While it's good that you spent the time to read up on some of the past discussion, I'm afraid there's always been some people interested in it so that's not really much of a change. The linked post already describes how it doesn't add a lot.

You don't think it would add a lot, but Custom Objects would still be a useful addition. Even if it's just being able to change how LM displays objects and you leave the ASM implementation to other people (similar to how you handled custom overworld sprites).

Heck, it may actually be more useful now more than ever. Specifically, the overworld patch I'm making uses the level editor to allow for the creation of much larger overworld maps, among many other things. The vanilla objects don't make much sense to use for overworld maps and it would be a lot better if there was a way to make objects that are tailor made for them. Not to mention it would improve my implementation of events if the user could just place objects down to manage them.

So, it's now no longer just "oh, these will help save some ROM space". Custom objects would now make overworld creation with my patch a lot easier and more intuitive, potentially even more so than editing the original overworld tilemap. In addition to the possibilities I hinted at given the fact that scripting languages can be particularly powerful if you're creative enough. I mean, LM already implements a couple custom objects that have nothing to do with placing tiles, like the music bypass one that overrides the level music setting in the header. So, you could extrapolate that more could potentially be done to change the way a level loads in. There is some untapped hidden potential with the object system, but few are going to utilize that potential unless LM supports a way to display custom objects at minimum.

Originally posted by imamelia

Well, one other feature that we don't have is the ability to properly display and edit levels that use BG modes other than 1. Level modes 03-06 aren't fully implemented either.

Yeah, those could be other things that could be added to LM at some point. But, the point I was making was that there aren't that many huge innovations left that LM could realistically add. So, FuSoYa might as well experiment and implement stuff that, even if they don't seem super useful at a glance, would still be nice to have as an option.

One example being the feature implemented years ago of being able to sacrifice the global ExAnimation slots for more local slots. While it's likely been a niche feature in the past few years, it has suddenly became much more useful, as my overworld patch forces overworld maps to share global animations with levels (there is no way around it). So, being able to sacrifice those global slots for more local slots means you're not restricted to only having half the animation slots the normal overworld gets. I didn't even consider that when I first suggested this feature, but now I'm glad it's been implemented.

My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.

Originally posted by mathie

there is no reason, nor moral nor practical, for such a vital asset to this community not to be run and maintained by it as whole. LM should have never been, and does not have to remain an exception to this.

On the contrary, there's a very good reason: That's not their asset, and not their decision to make.

Like it or not, this is in fact a hobby for many people, done in our spare time. These tools you're using have been provided for free. Not out of obligation, but because their creators have decided to do so of their own free will for their own individual reasons. Everyone is perfectly free to decide for themselves how much of their own time, skills, knowledge, art, tools, code, or anything else that they want to give of themselves. And it is not up to you, me, or anyone else to try and dictate otherwise.

I have already made my position on the above quite clear over the years, and laid out guidelines in the first post of this thread. If for some reason you don't believe that you can respect them, then I would suggest that you leave. Harassment will not be tolerated, and you will certainly not change my mind by engaging in it.

The topic of implementing custom objects in LM is now temporarily off limits. In the future, please don't derail a suggestion into areas that you know perfectly well are a dead end. $#ab{-_-}$

Originally posted by yoshifanatic

Yeah, I meant to say both the lakitu and the blue bird there. I don't know why I said lakitu sprites, as if there were more than 1 in the overworld editor. XD

Well, you can place more than 1 if you really want, though it seems like half the shadow can go missing when you do.

Originally posted by yoshifanatic

Also, another thing, but when I was recreating the overworld sprites to display in the level editor for my patch, I noticed there wasn't a way to edit the appearance of custom overworld sprites. Unless I missed something, perhaps that's something else you could add?

It already exists, it uses the .s16ov file extension for Map16 and .sscov for tooltips/layouts (see the "Custom Map16 for Sprites (Editor Display Only)" and "Custom Tooltips for Sprites" topics in the help file).

To edit the Map16 though you pretty much have to set up a dummy level with the overworld sprite graphics then use the level Map16 editor and export/import as a raw bin file.

Originally posted by yoshifanatic

Do whichever way you think is best. Also, I brought up text editing since I had to implement a way to edit the message box and castle destruction text in my patch just to work around the fact that LM forces you to save the overworld to do so. I didn't want to force the user to download a separate patch just for that.

I see. I guess at worst I could maybe use the same bit as an indicator to just save the text straight to ROM when hitting ok in those windows. Not exactly ideal, but it would save me from having to consider other structural and layout changes for now.

In service of a productive discussion in this thread, and since I've been working with the user toolbar functionality of Lunar Magic a bunch, I had a couple thoughts on that feature:

User Toolbar Toggle Buttons
Since I can expose some of Lunar Magic's existing functionality in a user toolbar, here's a few I'm actively using for example:

Code

***START***
LM_VIEW_SURFACE_OUTLINE
12,View Tile Outlines (Ctrl+F2)
LM_USEIMAGE_LIST

***START***
LM_VIEW_POW
13,View Blue P-Switch/POW Effects (F12)
LM_USEIMAGE_LIST

***START***
LM_VIEW_SILVER_POW
14,View Silver P-Switch/POW Effects (F11)
LM_USEIMAGE_LIST

***START***
LM_VIEW_LINE_ON
15,Toggle ON/OFF Switch Animation (0)
LM_USEIMAGE_LIST

I find myself missing the ability to make said buttons a toggle button (like the "View Animation" button) so there is adequate feedback in the toolbar UI--i.e. the button stays pressed when a user presses it to activate a thing and has to unpress it to deactivate. If future LM provided something like LM_USETOGGLE_BUTTON that we can put in the txt file that lets us set the type of toolbar button, that would be quite helpful.

Internal Icons for Lunar Magic functions
Keeping with the fact we can show LM functions in the toolbar, it would be extremely helpful if some of those functions had their own internal icons so people wouldn't have to come up with their own (as I have below for the buttons above) for when they're put on the toolbar. Admittedly, I have seen the list of functions and a lot of them would be troublesome to make icons for so it's debatable if they would all need icons.

I've been working on a small patch which allows the user to remap the vanilla animations and I'd like to request a small feature if at all possible.
In part, one of the functions of the patch allows you to move the vanilla animations from the compressed region at $7E7D00, essentially storing the GFX data as uncompressed GFX.
This opens up the ability to retain the vanilla animations, while allowing the original GFX33 area to be used for ExAnimations.

The only "problem" is that the animations don't display properly within Lunar Magic when setting this setting, though they work perfectly fine in-game.
This is because Lunar Magic is still assuming the data to originate in the RAM region of $7E7D00/$407D00.
Would it be possible to add an exception where, if $00A39E (default: $7E) is not in RAM, it will pull from the associated bank in ROM instead?

If that isn't a possibility, would it be at all possible to eventually incorporate a feature that allows us to remap the vanilla 4-frame animations directly within LM?

I've been producing some documentation on how the vanilla animations work as part of my work on this patch. I'm sure you probably have your own internal documentation, but I can share my notes if this seems like a project you'd be willing to tackle. I feel like it wouldn't be terribly difficult, but I think it's only possible with assistance from you, as some tables may need to be remapped -- for example, $05B98B is a 15-byte table which determines the animation set per-tileset, but the 15th byte bleeds into the animation tile data table at $05B999 -- in a proposed feature, this table might be relocated so that the conflict is removed.