I found a simple bug.
If you have in your frame the "Fade In" option and you have an Array Object then "Start of the Frame - Set a global value" with the array, the game crash.
The problem solves if you delete the "Fade in"
borrar.mfa
I found a simple bug.
If you have in your frame the "Fade In" option and you have an Array Object then "Start of the Frame - Set a global value" with the array, the game crash.
The problem solves if you delete the "Fade in"
borrar.mfa
I can confirm @dustingunn did broke with the update... Not sure why tho...
But isn't that overly complex for what it need to do anyway? Over 100 events for pixel and bounding box collision seems like too much...
I'm not sure. It used to be a lot smaller but wouldn't work if multiple bullets hit an enemy in the same frame, so I added the nested foreach loops. It's really hard to tell what will and will not work with CF2.5's object picking.Originally Posted by NaitorStudios
This is a known issue, and that's why the "Create before frame fade-in transition" option exists. Select this option for the Array object. IIRC by default extension objects are not created before the transition starts, so if you use their expressions in a Start of Frame event you get a crash.
It's due to this optimization in the new version:
"- Windows runtime: performance issue when a fast loop has several Start Loop actions."
I don't understand what's wrong yet, the optimization is quite simple, either there is something I didn't understand in the original code, or the original code was bugged and the optimization fixed it and broke your events, I'm on it.
So I built non packed exe, Avast does not longer detect it as false positive. All works ok.
Antivirus engines will recognise Fusions runtime exe and packing tools as potential threats and flag as a virus.
This is totally normal behaviour from any AV engine. The only reason they don't flag after updates is because a new build has been relaeased into the wild which they don't yet recognise.
Some will false positive still but you should really learn how to use your AV software. Leaving it unconfigured isn't always the best solution and can really hinder performance.
You have to create exemptions for the Fusion applications and folders which are used to build your software so the AV knows that these files are OK and not to clean/quarentine them.
The same thing happens with any Dev environment where the AV has not been correctly configured to ignore some known processes.
Granted that this could potentially allow unwanted threats in. But unless you are going to places and downloading things you really shouldn't be, then the threat is minimal.
It still surprises me that Clickteam have not used or have some sort of software signing as part of their build process before releasing.
This can help mitigate the distribution of unlicensed versions and an extra layer of trust that should really start to be used now.
https://www.ghacks.net/2018/04/16/ho...ms-in-windows/
Good work thanks Yves.
Regarding this update:
- Windows runtime: List object now supports up to 65534 lines (it was limited to 32767 before).
is there a complication to make lists global?
I can't get it updated. For some reason it stopped working in my computer when I changed CPU and I had to reinstall from scratch. Now the updater says that there is an updated and it begins to download the update - then it never finishes. It continues to restart the download of the patch for ever ("downloading update patch" dialog).
What to do?
Isn't there manual download for the patches nowdays?
No, it's not the reason, for a few builds they were flagging very shortly after the update. I think it's because when they analyze an EXE, their heuristic engine take various things into account to flag it as "possible malware", including the Win32 API functions it calls, signatures and caracteristics of various parts of the EXE, etc. and for some reason the previous builds were close to the border between "possibly safe" and "possibly malware". In the build 293.1 we've worked a lot to remove several function calls that could be considered as suspicious, like using Windows hooks that have been replaced by potentially less suspicious routines, etc. Also we've changed some important parts of the code to change the signatures. I think this makes the runtime look less suspicious to AV's.
Our main program is signed, as well as the runtime used by the editor. But obviously we cannot sign the stand-alone runtime that is used to make stand-alone applications. Firstly as soon as we build an application the EXE of the application gets modified, making the signature sinvalid, and secondly it's the user's responsibility to sign their own applications.
Posting Permissions
Reply With Quote