Author Topic: -Nevermind- Already made.. (Read 3579 times)

Kyuande · August 27, 2015, 11:16:58 PM

Remember when your menu used to play a synth sound when you hovered over a button in the menu?
It now works, no special loops. Even tested on a clean install.

Download - <link removed> (Direct mirror)

Ad Bot · Advertisement

ZER� · August 27, 2015, 11:31:58 PM

Nice, why where they removed in the first place?

Kyuande · August 27, 2015, 11:34:32 PM

No idea, maybe people thought it was annoying?

Nexus · August 28, 2015, 12:54:10 AM

Dude, you didn't parent any of your callbacks. This will almost certainly break every other mod in the game that tries to use those functions.

Here is the proper way to do what you want:

Code: [Select]

package MM_Sounds
{
    function MM_StartButton::onMouseEnter(%this, %modifier, %mousePoint, %mouseClickCount)
    {
        parent::onMouseEnter(%this, %modifier, %mousePoint, %mouseClickCount);

        //do your thing
    }
};
activatePackage(MM_Sounds);


//this is so we don't get a console error when we call parent and the function hasn't been declared yet

if(!isfunction("MM_StartButton", "onMouseEnter"))
{
    eval("function MM_StartButton::onMouseEnter(%a,%b,%c,%d){}");
}

Kyuande · August 28, 2015, 01:02:00 AM

Quote from: Nexus on August 28, 2015, 12:54:10 AM

Dude, you didn't parent any of your callbacks. This will almost certainly break every other mod in the game that tries to use those functions.

Uh, when I parented them, some of the functions said "unable to call blah blah", is there a way to check without console spam?

Nexus · August 28, 2015, 01:04:29 AM

Quote from: Kyuande on August 28, 2015, 01:02:00 AM

Uh, when I parented them, some of the functions said "unable to call blah blah"

See my edit, those functions may not exist but you should not assume no one else might try to package them too. Just because a callback has not been implemented by default does not mean you should not use a parent. At the very least you should simply declare the function normally instead of packaging it so you don't mess up other mods who properly package it.

Kyuande · August 28, 2015, 01:08:17 AM

Wouldn't that overwrite it?

The only thing I can remember is RTB doing this, the only issue is that if the functions don't exist in the first place it will spit console errors. I don't want to put them out as names because I would want the support file to be useful for any add-on.

Just wondering, but would this work for parents?
-bad code-

Nexus · August 28, 2015, 01:17:12 AM

Okay so the idea is that you always want to have a package for any callback that is not yours. You don't need to bother returning the parent in a callback because callbacks shouldn't return anything. If the callback was not created by default, then yes this parent will give a console error. You can fix this by adding the following to your code:

Code: [Select]

if(!isfunction("MM_StartButton", "onMouseEnter"))
{
    eval("function MM_StartButton::onMouseEnter(%a,%b,%c,%d){}");
}

This will check to see if the function has already been declared, and will declare it as a "do nothing" function if it does not. I believe that this should probably come before the package, now that I think about it, since the function in the package may cause isfunction to return true. This will avoid console errors and allow you to properly package these callbacks.

Kyuande · August 28, 2015, 01:23:09 AM

Hmm, what about other functions that would use this?

Okay, I found another possible solution, this shouldn't interfere with any mods unless they use the exact function.
Would this work? Would it need to be packaged? (I think the answer is no because if we try to parent it, there's nothing to parent.)
function GuiControl::onMouseEnter(%this, %modifier, %mousePoint, %mouseClickCount)

Nexus · August 28, 2015, 01:27:42 AM

Quote from: Kyuande on August 28, 2015, 01:23:09 AM

Hmm, what about other functions that would use this?

Okay, I found another possible solution, this shouldn't interfere with any mods unless they use the exact function.
Would this work? Would it need to be packaged?
function GuiControl::onMouseEnter(%this, %modifier, %mousePoint, %mouseClickCount)

Yes, that should absolutely be packaged. If the name that comes before the :: is something that isn't local to your mod, you should package and parent it.

Kyuande · August 28, 2015, 01:33:35 AM

If I remember, I don't think GuiControl::onMouseEnter would affect what GuiMouseEventCtrl::onMouseEnter does, but the other way around will be affected, I think GuiControl should be okay. Probably should be packaged, but doesn't need a parent because the game doesn't come with GuiControl::onMouseEnter in the first place. Thanks for trying to help on this, I probably might be confused still, but I think the way how functions overlap each other is if they are the same exact class, not class type. Such as:

GuiControl -> Gui class types -> Name

Nexus · August 28, 2015, 01:39:29 AM

Quote from: Kyuande on August 28, 2015, 01:33:35 AM

If I remember, I don't think GuiControl::onMouseEnter would affect what GuiMouseEventCtrl::onMouseEnter does, but the other way around will be affected, I think GuiControl should be okay. Probably should be packaged, but doesn't need a parent because the game doesn't come with GuiControl::onMouseEnter in the first place.

GuiControl is the superclass, not packaging and parenting with that will cause more problems than using guiMouseEventCtrl directly. Here are two basic principles you should use:
1. Use the most specific class possible. This means don't use GuiControl when you can use GuiMouseEventCtrl, and don't use GuiMouseEventCtrl when you can just use your object's name directly. Ideally you should use NameOfYourObject::onMouseEtc() instead of a more generic class.
2. If the most specific class isn't exactly your object's name, or if the object is not created by your mod, you need to package and parent the callback.

Kyuande · August 28, 2015, 01:51:35 AM

Well, currently I'm using GuiBitmapButtonCtrl::onMouseEnter because when I use GuiMouseEventCtrl on the buttons for the main menu, the buttons cannot be clicked on.

I know using names is a lot better, but if you had a lot of names but had to use something like this, it's a lot of writing (laziness).

Also, I just did what you said with the current support code, but adding a parent at the end, it doesn't even call the onMouseEnter for the start button, but for the rest of the buttons, they work. (Doesn't make any sense, I'm still thinking about the GuiControl -> Gui class types -> Name function it calls)

if(!isFunction(MM_StartButton, onMouseEnter)) eval("function MM_StartButton::onMouseEnter(%a, %b, %c, %d){echo(\"function called, but is the main called?\");}");

(packaged) - MM_StartButton does not call this because it already has its own function
function GuiBitmapButtonCtrl::onMouseEnter(%this, %modifier, %mousePoint, %mouseClickCount) { if(!%this.isAwake()) return; if(isFunction("mEventHandler_" @ %this.eventType @ "_onMouseEnter")) call("mEventHandler_" @ %this.eventType @ "_onMouseEnter", %this, %modifier, %mousePoint, %mouseClickCount); Parent::onMouseEnter(%this, %modifier, %mousePoint, %mouseClickCount); }

Nexus · August 28, 2015, 01:56:34 AM

Quote from: Kyuande on August 28, 2015, 01:51:35 AM

Well, currently I'm using GuiBitmapButtonCtrl::onMouseEnter because when I use GuiMouseEventCtrl on the buttons for the main menu, the buttons cannot be clicked on.

I know using names is a lot better, but if you had a lot of names but had to use something like this, it's a lot of writing (laziness).

Also, I just did what you said with the current support code, but adding a parent at the end, it doesn't even call the onMouseEnter for the start button, but for the rest of the buttons, they work. (Doesn't make any sense)

if(!isFunction(MM_StartButton, onMouseEnter)) eval("function MM_StartButton::onMouseEnter(%a, %b, %c, %d){}");

(packaged)
function GuiBitmapButtonCtrl::onMouseEnter(%this, %modifier, %mousePoint, %mouseClickCount) { if(!%this.isAwake()) return; if(isFunction("mEventHandler_" @ %this.eventType @ "_onMouseEnter")) call("mEventHandler_" @ %this.eventType @ "_onMouseEnter", %this, %modifier, %mousePoint, %mouseClickCount); Parent::onMouseEnter(%this, %modifier, %mousePoint, %mouseClickCount); }

The MM_StartButton class was used as an example, the point of that piece of code is to make it so you don't get an error when you call the parent. The class used in the eval statement should match the class in the function containing the parent.

Kyuande · August 28, 2015, 02:07:39 AM

-Nevermind, still confused on how this calls functions in general; sorry, not really understanding how this could break mods-
I've updated the code to make it only affect bitmap buttons for now (which is what it is doing)