Sorry for blowing your mind so violently ;D
Printable View
Sorry for blowing your mind so violently ;D
It's true that X and Y as letters are not the exact opposite of each other and it would be odd to consider them negate-able in that sense. That being said, X & Y represent two different axis and the idea of switching between the two makes sense in my opinion. Horizontal is the opposite of vertical and vice versa. There are only two options to choose from, just like with all of the other negate-able conditions/actions. Unless Fusion 2.5 is going to be having Z coordinate conditions and actions added to it, 'negating' X and Y shouldn't cause any issues for users.
If it were to be added it would certainly be a nice QoL enhancement. I'd find it useful. On the other hand, if it's too complicated to add or there just isn't time to spare on it due to all of the other more important things that need to be worked on then that's totally acceptable too.
That's certainly how I see it. Functionally, it would be very similar to the other cases, which are all basically a switch that toggles between two available choices in a dichotomy. Clickteam happened to name the option "negate", but they could just as easily have named it "toggle" and it would still make sense. The existing feature doesn't always technically "negate" things anyway: you can "negate" a flag, which actually toggles its value between 0 to 1, even though 0 and 1 are not at all negatives of each other. Though we accept this because there's a clear dichotomy between the two in a Boolean context, just as there's a clear dichotomy between X and Y in a 2-dimensional context.Quote:
Originally Posted by Tek
There's quite of a bit of stuff in Fusion that isn't semantically accurate, but I think people recognise that whether something is useful is more important than whether it's technically correct on a semantic level. For example, we use animation "directions" for things other than direction (eg. collision masks), we enter strings into Compare two General Values, Fusion calls always a "condition" even though it's not (it's the absence of a condition). No one seems bothered by those useful little illogicalities, and I suspect that no one would ultimately be bothered by this one. Though if lots of people truly don't like this suggestion, then it should probably be ignored.
LOLQuote:
Originally Posted by Volnaiskra
Negating an X or Y position I would see it working a different way. Example : Xpos 180 if you negate that it would be Xpos -180 Same for Ypos 180 if you negate that it would be Ypos -180
Still don't see a need to change it and add possible confusion of other users by changing X to Y.
Okay, thank you. I will remove that feature from my games.Quote:
Originally Posted by Fernando
But would you really? In most games, Set Xpos to 180 would be a relatively rare occurrence. You'd probably be more likely to see things like Set Xpos to 0 or Set Xpos to X("Player") +(X Right Frame - X("Player") ) /2. You wouldn't expect "negate" to add a minus sign in those situations, so I'm not sure you'd actually expect it in the case of Set Xpos to 180 either. But even if you did, and you unexpectedly got Set Ypos to 180, would you be confused? I doubt it. I think you'd probably understand immediately why Fusion did what it did, even if you didn't fully agree with the semantics of it, and were mildly annoyed that you didn't get the outcome you were hoping for.Quote:
Originally Posted by c4t
I just don't see how it's a big deal. Like I said above, it's arguably no more illogical than what Fusion already does with Flags anyway. Flags in Fusion that are "on" and "off" are really 0s and 1s, and will produce those values when used in expressions. Yet Fusion currently lets you "negate" flags: a flag of 1 can be "negated" to 0 (the real negative of 1 is of course -1), and a flag of 0 can be "negated" to 1 (the negative of zero doesn't exist)
A flag is a Boolean - it takes the value of 0 or 1. Therefore, logically - the alternative of the one is the other. Can you guys take this conversation elsewhere, please? (Start a new thread or something.)Quote:
Originally Posted by Volnaiskra
I'm not sure who this comment is meant to convince, or of what. As you point out, in Boolean 0 and 1 are the two logical alternatives, despite not at all being negated forms of each other. Likewise, in a two-dimensional plane the X axis and Y axis are the two logical alternatives, even though they are not negated forms of each other. This is precisely why I stand by my feature suggestion.Quote:
Originally Posted by Janette5
And as you know, there's been no bugbox for years, so this beta thread is an appropriate place to place a feature suggestion, especially when the suggestion is an addition to a feature that was introduced by this beta. And just as I have a right to make a feature suggestion here, c4t has the right to criticise it (and I in turn the right to reply to that criticism).
Well, internally fusion use an ID to store ACEs, currently fusion just switches one to another.
Maybe future version can get something like custom mapping. Then you can link any pair you like.
And, hopefully 2.5 can get an update of SDK, to let ext developers make use of these new features, e.g., add a new routine, input is current action ID, and return it’s negate one.
Other features like allow extension to read .anm files. I suggested this in discord and Simon said “no, this will leak our source code.” However, on windows, SDK just provide something for compiler to generate a symbol for dynamic link, everything actually is bundled in dll in binary. And as for other runtimes like android, fusion runtime is somewhat “open source”……usually I have to read it’s source to guess some undocumented behavior of windows version…
Another solution IMHO is provide a feature to set a custom encrypt key, as the algorithms is open source, at least documented in one paper. But without key, no one can decrypt it easily, as you cannot extract salt in water as easy as you dissolve it, unless fusion didn’t use something like that, the encryption is just like switch big/little endian, do offset…
Text being chopped off - on the words Red and Green - not sure if this is a bug or a setting (my zoom is at 100%).
Attachment 31658