Ok. So you want the green collision events to capture collisions 'inside' this new proposed action of yours. That's the piece of the puzzle I was missing. I'm with Linky: I definitely see the appeal now, but it sounds too big a change to expect any time soon. As far as performance goes, though, I believe that you could actually get significantly better performance using forEach loops.
In your example where an object moves by 10px, in the majority of cases no collisions will actually be present. But with your proposed action, you're forcing Fusion to check collisions 10 times each tick anyway. It would be considerably cheaper to first check a larger primary collision detector that checks all 10 pixels at once. Then you only bother checking the 10x individual collisions in the (rare) cases where the primary detector hits something. If you know that your enemy will always move 10px then you just make your primary detector 10px wide. If your objects move by a variable amount, then you would scale the detector dynamically as needed before each test. The cost of calculating and scaling the detector, and the the cost of occasionally having to perform 11 collision checks instead of 10, would be far outweighed by the benefit of having to usually perform only 1 collision check instead of 10.
My enemy system uses a lot of these sorts of techniques, where I'm always trying to minimise the amount of collision checks and calculations the code needs to do. As a result, I can comfortably have almost 200 enemies in a level at 120fps, with them all running, chasing, jumping gaps, aiming, shooting, navigating slopes, AI, all done with smooth bicubic easing movements. I can get more than 300 enemies at 60fps, on my strong but aging PC. And this isn't just in a naked test, but inside my game, where I've already got loads of stuff eating up performance: 3000 objects, player movement, shaders, particle effects, 1080p, etc.
My enemy system contains 1000+ events (including 700+ 'on forEach loop' events), and 100+(!) different collision detector objects that all test for different things. To be clear, if I place all 300 enemies in front of the camera at once then the performance will plummet, partly because of the GPU load, and partly because many parts of my code only run for on-screen enemies (ie. visual stuff like animation switching, particle effects, Z-order). But in any real-world scenario that my game would actually use (eg. ~100 enemies on the level with ~10 on-screen at any one time), the performance hit of my forEach-based enemy system is virtually non-existent. Yes, it's a very complicated system (it took me a year to make), and I wouldn't recommend it for a beginner, but one of its benefits is its efficient performance. And I believe that its good performance is because I use forEach loops.
For example, here's a single enemy navigating some platforms. It needs to do a lot of things: look for holes or obstacles, decide whether to jump (and if so, test the distance and altitude of the landing spot, as well as for potential hazards, then calculate the arc of the jump), deal with sloped surfaces, aim, test line of sight to the player. Plus the engine has to constantly assess whether to display it behind platforms (eg. when on a ceiling) or over the top of them (eg. when on the ground)*. There are different detectors for each of these situations. But if you observe at how these detectors move in the GIF below, you'll notice that very few of them are tested each frame. Many are tested only once or twice per second, while others only get tested a few times in the entire GIF, as needed. The engine will even dynamically change the rate at which some of these detections are tested: if an enemy speeds up, it will start checking for certain collisions more often; if it slows down, then less often. All of this modularity is only possible because of forEach loops (or at least I think it would be a lot harder without them):
* You can see this glitch out towards the end of the ceiling-ride sequence, actually - I need to fix something there :/
Interesting. Changing the key (eg. as below) makes it work. But when you test for the same key twice, it's like Fusion treats it as a single condition and only bothers to check it once.
Originally Posted by Tebi1234
It works if you done it like this:
Originally Posted by Tebi1234
Use "logical or" for these kinds of stuff as it works as a real OR, while the filtered one relates to scoping and whatnot:
Though this is not the right place to post questions, this a is a thread for posting bugs / suggestions about the latest Fusion beta build
Unless you thought it's a bug with Fusion ofc.
It's a bit weird I had to change the order too to make it work though, maybe that's just how Fusion works.
I agree with Tebi1234 that this is a bug. As you say, changing the order of the conditions is necessary to make it work, and changing one "space" to a different key also makes it work. Neither make much sense. There's probably some technical/historical reason for why it works this way, but surely it's not the way it should work, and I doubt it was purposely intended to work this way.
Yeah, I hope I could have edited my post, because seconds after I posted, I realized it may be an actual bug because it works weirdly
Originally Posted by Volnaiskra
Actually another instance of OR acting up weirdly is this example:
The collision is bugged out because of the OR but if the events were just split up normally then this won't happen
The Japanese version CF2.5's help index and search aren't work. Can you modifiy it?
Is D3D11 effects in a different gamma space, having half precision floats or something?
Found some weird inconsistencies in colors, can't quite get the DX11 version of a shader to match, even with demultiply, multiplying by Tint and so on...
A gradient seems more stepped, almost posterized looking in DX11 if compared to DX9 for no apparent reason...
problems with admob, after adding the GPG connector, my project cannot export, and if I remove admob, I will be able to export.