Posts by tobydavis

Quote from GKProduction

To test web applications anyone can simply start any Chrome browser with the startup parameter --disable-web-security and drag index.html into the browser.

Please login to see this attachment.

You can also just test your HTML5 application using the Build & Run option in Fusion. This will launch a local server and open it in your browser automatically. Since it is running from a server (even a local one), the application will load correctly.

Quote from semar

Thanks Tobydavis, but sadly it does not work here. Am I missing something obvious ? I've replaced the file in the data\runtime as suggested, and restarted Fusion. Given the ( grayed out ) "Add" effect to an active. No joy.
I'm sure I'm missing something here..
Any help would be greatly appreciated.

Just putting this here for everyone else, but we resolved this in the Click Converse. It seemed to be a problem with your specific version of Firefox (128.8.0esr). Upgrading to a newer version of Firefox resolved the issue that wasn't present on other browsers like Chrome.

Quote from punchbird

That's wild, was it present in Klik & Play then?

Big time nostalgia just mentioning it

That's correct. I tested it along with another user from the Click Converse Discord, and yep, it's there in K&P.

I also did some more testing this morning and can confirm that the bug is present in the Mac, HTML5, and Android runtimes as well.

I believe the bug is likely present on the iOS runtime too, but I haven't tested it.

Quote from Yves

Amazing, 30-year old bug... Yes this will be fixed in the build 296.

I was actually wondering how far back it went last night! Kind of crazy how no one seemed to notice it and report it in all that time. Glad to hear it is being fixed for 296

There appears to be a bug in with the "Number of lives of player reaches 0" event. It will fire for all players whose lives are currently at 0 even if the check was being performed for a different player. This means that the event "Number of lives of (Player 1) reaches 0" will fire twice if Player 1 hits 0 lives first and then Player 2 hits 0 lives.

The inverse is true as well. If Player 2 hits 0 lives first, the event will fire then and also when Player 1 hits 0 lives assuming that Player 2 is still at 0 lives.

This bug is present in the latest Build 295.10 as well as all the way back to the oldest publicly available Build 291.6 (from 2018). I don't know how often people use the built-in lives system, but I noticed it when working on a game that uses the "Number of lives of player reaches 0" event for multiple players on the latest build.

I've tested this on the Windows runtime, but I don't know if the bug made it over to other runtimes as well.

I've attached an MFA demonstrating this issue. You just click the buttons to decrement the Player lives value. When it hits 0, a counter is incremented for the respective player. These events should only fire once, but the event will fire second time for the opposite player again once both have reached 0 lives.

Hoping this can be fixed for Build 296.

Regards,
-Toby

There seems to be a bug in the MacOS video object. It does not respect the scaling options selected for it in Fusion. When the application runs, it starts at a fixed size and does not change, even if the window does. I've tested this with the application's "Resize display to fill window size" option enabled along with setting the MacOS Video object's Scaling setting to "Fill", but the video doesn't scale with the window as expected. I've attached some screenshots of the problem along with the MFA, test video, and compiled test application.

I am using the latest Build 295.10 and testing on MacOS 10.13.6 with a Mid-2011 iMac

Window at default resolution:

Please login to see this attachment.

Window Scaled (Application scales but video doesn't):

Please login to see this attachment.

Any help is appreciated.

-Toby

Quote from Rolando

Any idea when the Clickstore will be up?

Not sure when the Clickstore will be back up, but Clickteam has listed many of the Clickstore items on their Patreon shop for the time being.

Please login to see this link.

If you're looking for something you've already purchased, you should be able to log into the Clickstore and download it. The entire thing isn't offline, it's just in read-only mode at the moment.

Quote from justjose1

So a lot of my game is made up of active system boxes and now when I build and run the game, every time I click on an active system box, the entire game freezes even if there isn’t an event linked to it. Does anybody know what the problem is or how to fix it?

I just tested an Active System Box with the HTML5 exporter and did not experience any crashes. Please also make sure your HTML5 exporter is up to date. You can do this by re-installing the latest patch for Fusion itself, which at the time of writing is build 295.10. The reason this may need to be done is that the files included with a particular exporter may be out of date and for an older build of Fusion. Re-installing the latest patch updates Fusion itself and the files for any installed exporters.

If this does not fix the issue, please include a screenshot of what is in the browser console after the application crashes. This can be done by going pressing F12 and selecting the "Console" tab in the popup that appears in the browser.

Quote from Yves

Ah sorry, I misunderstood what you meant in your first fix as it was hidden. Actually the correct fix is just removing the line that sets qualToOiList to null in unBranchPrograms, you shouldn't remove the call to unBranchprograms

Code

	unBranchPrograms: function ()
	{
		this.bReady = false;
		this.limitBuffer = null;
		this.listPointers = null;
		this.eventPointersGroup = null;
		this.eventPointersCnd = null;
	},

Oh I see. I guess that's the downside to removing things from my comments. I was hoping to cause less confusion for anyone who came across this thread in the future, but I guess I did the opposite. Thanks for clarifying where the actual problem was.

Quote from Yves

I think your first fix was the good one (removing the line that sets qualToOiList to null in unbranchPrograms). In a previous optimisation the initialization of this array was moved to another routine, and apparently I forgot to remove this line.

Hi Yves. I've restored Fix #1 in my earlier comment so other people can see it. I was just really cautious about recommending deleting a line as the fix for the problem.

I'm glad to hear one of my fixes ended up being correct and I wasn't totally off base here

Quote from Yves

Sorry for the delay guys, there were some complications for me since Xmas, the last weeks were a bit complicated (my heart has "changed" and my pacemaker settings required a couple of adjustments). The good news is that everything seems now stable, fingers crossed. I'm back on the build 296 at a normal rate, I'll post an update asap!

And btw thank you all for the kind words

Glad to hear you are doing better Yves! Health issues are never fun. Wishing you all the best

Quote from semar

IT WORKS !!!

Many thanks tobydavis for your patience and time ! Now I can finally use the standard transitions also in HTML5 !

I really appreciate your work and the detailed informations. You have even corrected/updated your posts above - I'm deeply impressed !

You own a pizza margherita and a beer from me

I've tested the whole project right now, and also by the second level the transition works like a charm !

Thanks again for your kindly effort tobydavis - really, really appreciated !

Best regards,
Sergio

Display More

Glad to hear your project is back up and running! I'll have to take you up on that pizza offer if there is ever another Click Convention

It looks like this bug was introduced in Build 295.2. I can't be sure of the details, but there were changes in relation to qualifiers in Events.js (such as the addition of the prepareQualifierList function) that may have caused problems with the previously unproblematic code in RunLoop.js that is triggered after the completion of a transition.

I believe that Fix #2 is the better one at this point, so I would go with that until there is an official fix (hopefully in Build 296).

Regards,
-Toby

This issue seems to be related to one reported by semar in this thread: Please login to see this link.

It relates to qualifier issues on frames with transitions applied to them (like a fade in).

I've provided a potential fixPlease login to see this link.. Not sure if this is how it would be fixed by CT Staff, but it seems to work without issues so far.

Quote from semar

This is indeed really nice to know !

Hi semar,

The problem with the qualifiers seems to be that there is code inside of RunLoop.js that is called only if a frame has a transition applied to it (such as fade in). When that code runs, it calls a function named unBranchPrograms that clears out the list of qualifiers, which results in that null error when the program tries to access them after the fade in. I've come up with a way to fix this.

Fix 1:

This fix involves deleting line 668 in RunLoop.js that calls unBranchPrograms after a fade in, which will prevent the qualifier list from being cleared out.

Please login to see this attachment.

Fix 2:

This fix involves adding a line to RunLoop.js. Just add this.rhEvtProg.qualToOiList = this.rhEvtProg.qualToOiListFull; below line 668 as shown below:

Please login to see this attachment.

You can also undo the patch I suggested for line 1385 in my earlier messages as it is unnecessary and didn't target the root of the issue.

(2/5/25 Edit) The correct fix was actually to remove this.qualToOiList = null; on line 4365 in Events.js as per Yves' Please login to see this link.

Disclaimer:

I didn't write the runtime, nor am I familiar with all of its components, so I can't guarantee this is definitely the correct solution. I would at least try this fix though and see if you encounter any issues (whether they are related to qualifiers or not). If you do, please mention them here.

Hi semar,

Thanks for the MFA.

I think I may have found the problem in the runtime. I will provide it here once I do some more testing.

It is still a change in RunLoop.js and actually makes my previous fix unnecessary since I believe it addresses the root of the problem.

Hi semar,

If you could PM me the MFA you are using that would be great. And yes I agree, using fades seems to cause a problem with qualifiers that wouldn't normally occur in a frame without a transition on it.

As far as the patch I suggested in my earlier message, I found that it could mess up behaviors with qualifiers (such as collisions).

(1/19 Edit: removed code suggestion. See Please login to see this link.)

I am going to keep investigating this, and I'll update you with any fixes I'm able to make.

Note: If you ever need to revert all the changes you made to the Html5 runtime without going back through all the files you changed, then you can just re-install the latest Fusion update, which will return the runtime files to their original state.

You should be able to fix this yourself by going to the Data\Runtime\Html5 folder in your Fusion installation directory (typically C:\Program Files (x86)\Clickteam Fusion Developer 2.5\Data\Runtime\Html5 for non-Steam users), opening up the RunLoop.js file, and changing line 1385 from this:

if (oilPtr.oilRealQualifiers != null) {

(1/29 Edit: removed bad code suggestion, see Please login to see this link. for newer fix)

The problem with your "bad" object is that it has a qualifier on it. So in this case, the object isn't actually "bad", nor is it corrupted. If you remove the qualifier from the "bad" object, the event on line 2 will work on HTML5.

It looks like creating an object that has a qualifier attached to it inside of a "Run this event once" statement causes the error on line 1395 in RunLoop.js. This will only occur if the frame has a transition on it though. If the fade-in transition is removed, then the object's will be created without an error.

You can make the event behave correctly on HTML5 by adding a "Start of Frame" condition to your code. This is also why line 8 works on both platforms without a problem.

Please login to see this attachment.

This will change the behavior on both Windows and HTML5 though, and the objects will be created before the fade-in transition, not after like they are on Windows without the "Start of Frame" condition.

My best guess as to why this problem occurs on HTML5 is that the part of the code in RunLoop.js producing the error runs before the frame is fully loaded during the fade-in transition, and thus can't properly process the qualifiers on the objects that don't yet exist.

I modified the StandardRenderer.js file for the HTML5 runtime to allow a couple of built-in effects to work with objects (not layers though). With this modification, the following effects from the "Standard" effects section will work on HTML5:

• Add
• Invert
• Subtract
• Monochrome

These effects will show up grayed out in the effects window in Fusion if you have the build type set to HTML5, but you will still be able to assign the effect to the object.

Just copy the modified StandardRenderer.js file in the attached zip into your Data/Runtime/Html5 directory and you're good to go!

1/25/25: Updated included zip file