My understanding is that it's more like a donkey on a glasshouse: No one's quite sure what it's doing up there, but everyone suspects that disturbing it would probably do more harm than good.Originally Posted by Wodjanoi
My understanding is that it's more like a donkey on a glasshouse: No one's quite sure what it's doing up there, but everyone suspects that disturbing it would probably do more harm than good.
Name based variables
Probably requested a lot of times before, but just to bring it up again in case if possible, can we please have name based values, strings and flags?
I don't know how hard it is to implement into current Fusion, but it would be exteremly useful if possible.
As index based variables can be annoying to work with when implementing generalized systems, one simple example: upon pressing space -> subtract 1 from "health" value of "enemies" qualifier
If some objects under the "enemies" qualifier had there "health" value at a different index, the above event would be modifying a different value at this point...
It can be a different value system added alongside the one we currently have (like how instance value is) maybe even enabled optionally from app properties, and I honestly don't care if name based variables are slower, the added convienince would make it worth it when needed
I'm pretty sure the answer has always been that no, it would be prohibitively difficult to implement.Probably requested a lot of times before, but just to bring it up again in case if possible, can we please have name based values, strings and flags?
I don't know how hard it is to implement into current Fusion, but it would be exteremly useful if possible.
As index based variables can be annoying to work with when implementing generalized systems, one simple example: upon pressing space -> subtract 1 from "health" value of "enemies" qualifier
If some objects under the "enemies" qualifier had there "health" value at a different index, the above event would be modifying a different value at this point...
It can be a different value system added alongside the one we currently have (like how instance value is) maybe even enabled optionally from app properties, and I honestly don't care if name based variables are slower, the added convienince would make it worth it when needed
Over the years, I've learned to try and make a habit of reserving certain altVal slots for situations like this. I keep a list of universal altVals referenced in a spreadsheet and try and stick to that when making a new object, to try and minimise the time I spend painstakingly rearranging objects' altVals (which still does happen more than I'd like).
Though there's a relatively easy solution for your particular example. Select all of your "enemies" (frame editor>Right-click>Select Object with a given qualifier.....make sure all possible "enemies" exist on this frame), and press the "New" button to add another altVal. The next freely available altVal slot will come up, whether it's Alterable Value AJ or whatever. Whatever it is, if it doesn't say "Undetermined", then it's guaranteed to be free for all of your selected items, so just use that for your "health" altVal from now on. (temporarily name it something like "h_ealth" then use Find All to locate and replace all instances of "health" with the new one)
Another thing you can do is reserve certain very-far-down altVals for certain tasks. For example, I use Alterable Value ID for 'marrying' objects (eg. if I create a turret that belongs to a ship, I set Alterable Value ID of the turret to the Fixed Value of the ship so I can scope the pair later). I also use Alterable Value IN to store Instance Values in some situations. You could, for example, use Alterable Value HE for health, and there are some other potentially meaningful ones, like Alterable Value GO, Alterable Value FX, Alterable Value IS. The benefit of using these sorts of altVals is of course that they are so low down the list that they're very unlikely to conflict with any of your existing named variables. But because they're so low down, you don't want to actually name them (that would require clicking the "New" button hundreds of times), which is why you go for ones that have some inherent meaning in the existing name (ID, IN, GO, FX, IS etc.). When setting, Alterable Value HW onwards are the most convenient because they are instantly visible when you press End in the dropdown.
@endloz
Not exactly what you're looking for but this may be of use to you.
There's this thread (link) where users asked for the nostalgic look of Klik & Play and The Games Factory 1 for build 294. I did my best and made 2 skins; on the 1st page you will find some screenshots and on the 2nd page a ZIP file with the skins. You may want to try them out and see if they make your experience with the new interface a bit to your liking. This is as far as I managed to get as the current skin editor can't edit toolbar icons.
Hope this helps.
Thanks for the suggsitions, I already use some of them, but yea it's the not the most convenient way unfortunelyI'm pretty sure the answer has always been that no, it would be prohibitively difficult to implement.
Over the years, I've learned to try and make a habit of reserving certain altVal slots for situations like this. I keep a list of universal altVals referenced in a spreadsheet and try and stick to that when making a new object, to try and minimise the time I spend painstakingly rearranging objects' altVals (which still does happen more than I'd like
Though there's a relatively easy solution for your particular example. Select all of your "enemies" (frame editor>Right-click>Select Object with a given qualifier.....make sure all possible "enemies" exist on this frame), and press the "New" button to add another altVal. The next freely available altVal slot will come up, whether it's Alterable Value AJ or whatever. Whatever it is, if it doesn't say "Undetermined", then it's guaranteed to be free for all of your selected items, so just use that for your "health" altVal from now on. (temporarily name it something like "h_ealth" then use Find All to locate and replace all instances of "health" with the new one)
Another thing you can do is reserve certain very-far-down altVals for certain tasks. For example, I use Alterable Value ID for 'marrying' objects (eg. if I create a turret that belongs to a ship, I set Alterable Value ID of the turret to the Fixed Value of the ship so I can scope the pair later). I also use Alterable Value IN to store Instance Values in some situations. You could, for example, use Alterable Value HE for health, and there are some other potentially meaningful ones, like Alterable Value GO, Alterable Value FX, Alterable Value IS. The benefit of using these sorts of altVals is of course that they are so low down the list that they're very unlikely to conflict with any of your existing named variables. But because they're so low down, you don't want to actually name them (that would require clicking the "New" button hundreds of times), which is why you go for ones that have some inherent meaning in the existing name (ID, IN, GO, FX, IS etc.). When setting, Alterable Value HW onwards are the most convenient because they are instantly visible when you press End in the dropdown.
I started experimenting with a custom way of handeling data types using Arrays\INI, still not the best way, but it's easier and more feasable with the help of a new extension called DarkScript which can run functions with\without parameters even inside expressions, return data, keep object selection, run functions with delay..etc
Example:
Still not that readable, and I don't think that would work with auto object selection cases "magic scoping", but if name based values will never be implemented, I think this may be one of the best methods to try
Hopefully F3 is not that far away
Yeah, that doesn't look readable at all to me, though I'm terrible at reading syntax. I can tell that it's not complicated, but it still looks like gibberish to me
Ultimately, I think the best solution is to just bite the bullet and clean up your objects so that they have consistent altVals. Otherwise you're probably just creating workarounds to make up for disorganisation which may hurt you in other ways in the future. But there would probably be a number of different ways that you could do index-independent variables if you really wanted, though all would probably add some extra complication.
For example, if one enemy's "health" altVal is index 5 and another's is index 19, then at edit-time you could pick an alterable string for each enemy (any alterable string - it wouldn't matter) and set it to "healthV5" and "healthV19". Then, at start of frame, you could do a forEach loop for the enemies, running a fastloop 100 times for each one. In that fastloop, you'd check the first 100 alterable strings, and if the first 7 characters of any of them is "healthV", you would read the number after "V", which would give you the index of that enemies' "health" altVal. You could then then store that somewhere and subsequently use it to set the correct "health" altVal for each enemy.
By the way - just checking that you've seen the Named Variable Object? I think it's basically what you're after - but I think it's Windows-only, which is probably why you're not using it.
There's another extension-less method that I use in my game that I think is relatively neat and convenient. As my game evolved, I had a group of NPC objects that used one system, and a group of enemies that used a different system. Partway through development, I realised that both NPCs and Enemies should be able to use the same easing system to handle things like curved movements (eg. jumps). But the two object types were already full of their own mutually-incompatible altVals. In other words, I was stuck with the sort of problem that you described. My solution was to create a new proxy object that is shared by both NPCs and enemies, and which contains all the required easing altVals in a neat list. Whenever the engine creates an enemy or an NPC it also creates a new proxy object and 'marries' the two. Meanwhile, I now give both NPCs and enemies an additional new qualifier called "EZ easable":
Then in the Easing section, the code doesn't directly concern itself with enemies or NPCs at all, but deals directly with the proxy objects:
I find this solution relatively painless. You get to use a brand new object with neatly ordered altVals that are guaranteed to never get out of sync. It doesn't add much complication to your code - you just need to add a condition here or there when you scope an enemy/NPC to scope its proxy object too. And the performance impact is negligible unless you're going to have 10,000 enemies onscreen; it's just a bunch of motionless invisible objects. If your enemies already have 'married' helper objects (eg. collision detectors), you could potentially even just use those.
Thanks for the suggsetions, in case of the named values object I already know about it, there are two main reasons of why I still don't use it yet, one being that it's still Windows only (I heard it will be ported to other runtimes at one point though), second being that it doesn't assign to specific objects it's basically like global data, so for each object to have it's own list of variables I would have to do some linking or having the fixed value of the object in the variable name it self and handle that in events kinda defeating the main purpose...Yeah, that doesn't look readable at all to me, though I'm terrible at reading syntax. I can tell that it's not complicated, but it still looks like gibberish to me
Ultimately, I think the best solution is to just bite the bullet and clean up your objects so that they have consistent altVals. Otherwise you're probably just creating workarounds to make up for disorganisation which may hurt you in other ways in the future. But there would probably be a number of different ways that you could do index-independent variables if you really wanted, though all would probably add some extra complication.
For example, if one enemy's "health" altVal is index 5 and another's is index 19, then at edit-time you could pick an alterable string for each enemy (any alterable string - it wouldn't matter) and set it to "healthV5" and "healthV19". Then, at start of frame, you could do a forEach loop for the enemies, running a fastloop 100 times for each one. In that fastloop, you'd check the first 100 alterable strings, and if the first 7 characters of any of them is "healthV", you would read the number after "V", which would give you the index of that enemies' "health" altVal. You could then then store that somewhere and subsequently use it to set the correct "health" altVal for each enemy.
By the way - just checking that you've seen the Named Variable Object? I think it's basically what you're after - but I think it's Windows-only, which is probably why you're not using it.
There's another extension-less method that I use in my game that I think is relatively neat and convenient. As my game evolved, I had a group of NPC objects that used one system, and a group of enemies that used a different system. Partway through development, I realised that both NPCs and Enemies should be able to use the same easing system to handle things like curved movements (eg. jumps). But the two object types were already full of their own mutually-incompatible altVals. In other words, I was stuck with the sort of problem that you described. My solution was to create a new proxy object that is shared by both NPCs and enemies, and which contains all the required easing altVals in a neat list. Whenever the engine creates an enemy or an NPC it also creates a new proxy object and 'marries' the two. Meanwhile, I now give both NPCs and enemies an additional new qualifier called "EZ easable":
Then in the Easing section, the code doesn't directly concern itself with enemies or NPCs at all, but deals directly with the proxy objects:
I find this solution relatively painless. You get to use a brand new object with neatly ordered altVals that are guaranteed to never get out of sync. It doesn't add much complication to your code - you just need to add a condition here or there when you scope an enemy/NPC to scope its proxy object too. And the performance impact is negligible unless you're going to have 10,000 enemies onscreen; it's just a bunch of motionless invisible objects. If your enemies already have 'married' helper objects (eg. collision detectors), you could potentially even just use those.
In case of the seperate object only for storing data linked to the main objects, yeah it's a nice idea and it's the one i'm using right now for some specific cases, it unfortuntely can slow down the app a bit in runtimes like Android with low end devices.
The solution I experiemnted with also works, and a bit faster as it doesn't require object linking or creating more objects, the only problem is it can be hard to read especially if you are not used to it yet, I think mixing methods and using the one best suited for the task would be the best thing for now
Not sure if this has been suggested before but I just had an idea pop into my head. 'Variable descriptions' when you click on them in the properties panel:
Screenshot 2023-05-28 135025.png
Would be a nice way to help you remember what does what.
@NaitorStudios, @Volnaiskra, @goldeng - thank for help!
@NaitorStudios your "Default Fixed (Old)" skin help me partly. I will try to replace the remaining icons based on your skin.
half-fixed UI.jpg
The toolbar looks a lot better, but the Properties icons are still very broken.
Posting Permissions
Reply With Quote
