[Bug]: Addons - Inconsistent onInit Functionality

[Pmofmalasia]

Describe the Bug

I am having a few issues with the onInit macro/event. It seems to operate differently depending on the situation:

1. When I first load in the addon, it works as expected.

2. When opening MapTool and loading it as the very first campaign from the default grasslands, it does not appear to run at all - I have a broadcast() function that does not output anything to chat in this instance.

3. When another campaign has been opened in the same instance of MapTool (or the same campaign, just any campaign file), the broadcast() function outputs to chat but none of the functions are defined. The broadcast() function occurs after the functions are defined, so the macro was not aborted early.

4. When run manually by entering [h,MACRO("onInit@Lib:pm.a5e.Core"):""] into the chat, it works as expected.

For troubleshooting purposes, my events file is below:
{ "events": [{"name": "onInit","mts": "onInit"}, {"name": "onFirstInit","mts": "onFirstInit"}] }

To Reproduce

1. Create an addon onInit function as detailed in Craig's devblog. Include a function to define and broadcast function.
2. Add the addon to the campaign. It should work as expected.
3. Save and close MapTool, then reopen it.
4. Open the saved campaign file. The onInit macro should not have run.
5. Re-Open the saved campaign file. The broadcast message should be output into chat, but isFunctionDefined() will return 0 for the function.
6. Manually run the onInit macro in chat. It should now function correctly.

Expected Behaviour

Expect the functions to be defined upon loading the campaign in instances 2 and 3.

Screenshots

No response

MapTool Info

1.11.4

Desktop

Windows 10

Additional Context

The UDFs declared in my onInit macro are standard UDFs, not js.UDFs.

[Pmofmalasia]

Debugging Addons.zip

Campaign file + addon for debugging

[Pmofmalasia]

Update for the 1.12.0 alpha:

1. No change to the above (as expected). Drag and dropping the .mtlib file has the same behavior with how onFirstInit and onInit work.

2. Drag and dropping also creates one new scenario - updating an already present addon. In this instance, onInit activates and onFirstInit does not. Any new functions in onInit are successfully defined as well. This I believe is working as intended.

[cwisniew]

Update for the 1.12.0 alpha:

2. Drag and dropping also creates one new scenario - updating an already present addon. In this instance, onInit activates and onFirstInit does not. Any new functions in onInit are successfully defined as well. This I believe is working as intended.

This should also be the case when you update via the UI if you don't remove first, or at least that is what is intended please let me know if you have had issues with that.

[Pmofmalasia]

I was previously foolishly unaware that you could update via the UI (hence my thinking it was a new scenario). This is working as intended, no issues.

[Phergus]

@Pmofmalasia please confirm that this issue has been resolved with beta 3. Thanks.

[Pmofmalasia]

This issue is mostly resolved for me. In all instances, my functions are defined correctly (which is my main issue with this bug in the first place). The one thing that is still happening is that when loading a campaign from Grasslands, the broadcast() functions are not output into chat. However, if the campaign is already opened and then reopened, they will be output into the chat.

The main issue is resolved from my end, but I believe some frameworks use outputs to chat in OCL/onInit for user instructions, showing if versions are up to date, etc.

[Phergus]

@cwisniew thoughts?

[cwisniew]

@Pmofmalasia I tried with just the simplest case possible, one lib:token with a onCampaignLoad that has just a [broadcast("This is a test!")].

The broadcast appears

1. When loading campaign from freshly started MapTool
2. Reloading the same campaign
3. New Map, then loading the campaign

What other types of things are you doing in your onCampaignLoad macro? Maybe there is some odd interaction happening.

[Pmofmalasia]

@cwisniew this isn't in reference onCampaignLoad macros on Lib:tokens, just onInit for an addon. I only brought up OCL in my previous comment to mention that it had been used that way in the past, and people might want to do so going forward in addons.

My onInit macro declares functions, calls out to another short macro, and has a broadcast at the end, though.

[cwisniew]

@Pmofmalasia tried the same tests with a simple add-on, and get broadcast in all tests.
can you try moving the broadcast before calling the other macro to see if the call is somehow causing the issue and let me know if that works?

[Pmofmalasia]

@cwisniew The broadcast does output to chat if moved before calling the other macro - in case it makes a difference, that macro is called with the macro(): roll option and is not a UDF.

[Pmofmalasia]

I should note if it helps, the called macro also has a broadcast in it which does not display in chat either.

[cwisniew]

@Pmofmalasia

In this test add-on it has

broadcast
call macro from add-on
add on broadcasts
broadcast after add-on

They all work, so I wonder whats different. What is the macro you are calling doing, it seems that something in that macro may be failing which is why the broadcasts are not happening

test-add-on.zip

[Pmofmalasia]

@cwisniew Just did some additional testing - it was something in the macro that was failing. That macro gathers a bunch of information from a bunch of library tokens on the map. It appears that using getLibProperty() on a lib:token causes the macro to fail. I was aware that onInit and onCampaignLoad would not interact well with each other, but not sure if this is unavoidable behavior as well?

[Phergus]

So are you saying that getLibProperty() called on a lib:token from onInit is failing?

[Pmofmalasia]

Yes, but notably if opened while a campaign file where those lib:tokens already exist, then getLibProperty() does not fail.

[Phergus]

okay. Good info.