So what you suggest?
I am biased against declaring everything
Yet i am not biased that old system needs to return
I just wish for getting better new system which will be streamlined
I try to explain to users here that not in all scenarios new system is better
Where i cannot deny new system having its advantages
So again what you would suggest us to do?
Give up on the matter? And i am not sarcastic this is a serious question
I mean i do not care for undeclared vars i care for better system than we have right now
And i believe in the end everyone would care more for better system rather than going back
Give up on going back to the old method/getting frustrated about it? Yes, I definitely think that ship has sailed.
Give up on giving feedback? No, definitely not. I think it’s totally valid to provide feedback on UX methods to make the current method better (as the current method). I think other threads you’ve made with other suggestions are totally valid. I think that’s the best place for people to focus their energy.
I personally think there is a dire need to have a one (or two) click solution to declare an undeclared variable from within an event (or expression) where you’re using something undeclared. I was originally going to make my own thread about it but a few folks have different recommendations on that already.
Again, I just wanted people to not further spiral into frustration for something that won’t come to pass, when they can either focus it on figuring out what’s needed to make the new method better (easy declaration) or to spend their energy on moving towards the new method.
I am not frustrated old system is gone
I just wish that new system gets streamlined
I am aware we are in transition state so i do expect this can’t be smooth change
And i was more of a asking is showing other users other side of the story that in some scenarios new system is not superior to old one not the way to go
Which apparently you meant is not
But then what is left is only to come with other ideas that many users already proposed
YET you are longer here than me for sure i would be curious for your idea
You say other users did recommendations already some different ideas so you did not
Yet you as someone who have much longer experience using gdevelop i say should share his ideas
IDK how gdevelop changed over they years i seen some screenshots
Yet i would care to see what users with longer “usage” have to say when it comes to how they would make new system better
Im deleting this one because this time was my bad, the issue i was having was because i was using an external event page, and since i never declare scene variables.
For some reason i assumed the scene variables i had on the scene attached to the external events would translate to the scene i linked it tho… would be a cool feature, but not how it works, so my bad…
I also learned that the new variable actions do not created variables like the old ones… which is a shame but guess thats the point.
What @Silver-Streak says is the same as what I think. I don’t think the old system will return. The idea would be to propose something to easily migrate projects made with the previous system to the new system. Therefore I have proposed the following.
I don’t see any point in expressing over and over again how good it is to declare the variables beforehand or how bad it is. I think everyone already understands that for each particular case one is better than the other. The question is whether this change can improve the performance of games made with Gdevelop in the future, as 4ian’s mentioned
In that case, I think there would be no further discussion.
Well insein I have to retract my previous reply to you. I hated the idea of the change but tonight I had time to play with the new system and I’m really enjoying it.
It’s not at all what I thought it would be (time consuming, hard to refactor, restrictive, have to adjust to a new workflow). Since all my declared variables have always lived inside a structure, I did as 4ian suggested and used the structure for all my variables, even the ones I normally created by events. I found working as convenient as I would have found it before, and I love the “Change variable value” menu. It’s fast and easy. I even had no problem performing my preferred way to get to any action, which is to copy/paste/modify an existing same action instead of opening the pane to find a fresh one every time. The Change variable value action was very easy to paste and modify to different variables, be they scene or global.
Though I like to name scene and global variables the same thing, I feel like I will be able to keep my variable naming conventions the same (just changing the name of the parent structure) and instead of having to learn a new way to work and keep track of what I was doing, it felt pretty much the same as what I’d been doing except I would have to say faster with the “Change variable value” action menu.
And the local variables! So I’m counting this as a Big Win for GDevelop, although I am only saying from my perspective since it happens to fit in so well with how I prefer to do things. I do understand those that are having difficulty adjusting, because that was my initial thought too, about having to learn a new system.
I think I’ve used this system for around 2 weeks now, and it is not pleasant one bit.
I completely understand your points, but it’s like throughout all of these announcements they miss one key thing, absolutely NOTHING good comes from this system
I genuinely don’t understand why we can’t just have an object variable action/condition, a scene variable action/condition, and a global variable action/condition, then just add an option to declare the variable, and if you click it and it’s a new variable the variable will be added to the variables editor
Another thing about this is that testing new functions with non complete/experimental code where you could need a bunch of variables is wayyy more annoying since you have to manually remove them all with the variables editor rather than just deleting the code with all the undeclared variables
These solutions probably have a few issues of their own which makes them not ideal, the main issue I have is with the GDevelop team somewhat living inside of their own bubble and not listening to community feedback, I still love and support this engine, It’s helped me do amazing things but completely ignoring the new variable system, the lack of any sort of changes due to community feedback is worrying me.
I could care less about the new system to be honest. It’s just I wish the devs were more transparent and open to taking user feedback
On a separate note, the tween system needs a rework wayyy more than variables, it’s a genuine pain surfing through the endless waves of tween actions that practically do the same thing.
The action to change an object variable should be accurately named “Change Object Variable” rather than “Change Variable” to avoid any confusion (you could also seperate the events for global and scene variables for consistency & to avoid confusing searches)
for some reason whenever I drag a condition/action everything turns invalid (red text w/ underline) before becoming valid again when placed
I just realized
That when i type name of variable when adding action or condition
It offers me option to ad/edit it
From drop down menu
If i click that add or edit
It is not added
I still need to add it manually in next window
SO either
A - this window should automatically add my var to the list and all i need to do is select its type in next window eventually global/scene type
or
B - Say “Open variables window list” and not “Add or edit variables”
@BalangoDev
I think for now
Main concerns are updating extensions and examples
Like also fixing multiplayer bugs and creating new examples with multiplayer
And whatever we propose or stand against here is not going into the void
I have no proof that what we ask for any1 read and any1 consider as a solution
Yet i have no proof that wat we ask for is ignored and won’t added to engine
You don’t have also and no one don’t
So i am willing to wait and see how system will be adjusted in the future
Cause i doubt it will stay the exactly the same
that is what i offered above…but with autodeclaration…If GD knows which var you wrote it should be simple to add automatically to the vars list.
This is not a turn back, cos it will get rid of undeclared vars, but they said old conditions are too verbose…(so i guess they’re not going to happen) that is your answer
Just giving my opinion on some things discussed here.
This sounds like a nice feature… but I don’t think it works in all situations. I’ll explain what I mean.
In the case of a simple variable, eg: NewVariable, this is fine.
In the case of arrays or structures, eg: Structure.Child.
If Structure is not declared, then GDevelop would have to declare both variables.
So Imagine if I type 3 or more new variables into the field, eg: Structure.ChildStruct.ChildStruct2.Child.
Maybe this is also OK to let GDevelop create multiple variables all at once?
In the case of expressions.
Eg: Structure[Name].Child -or- Array[Number].Child.
How would GDevelop know where to declare the variables?
It doesn’t work in this case.
With the current system, how would you tell GDevelop whether to declare the variable as a scene or a global variable? This would add an extra step.
I don’t think a feature is good or worth adding if it doesn’t always work.
Having 1 action/condition for scene & global variables allows to easily change a variable from one type to another. I find it way more useful this way.
Imagine you used a scene variable throughout a big project, and later you decided to change it to a global variable. Now you can simply delete the scene variable, declare it as a global variable, and you’re all set.
But if the events for scene & global variables are different, you’d have to search for all the actions & conditions and replace them manually. I faced this issue before and many hours of searching and fixing errors later, I finally was able to do the change. I’m not very good with math, but I think this is a LOT more time than simply delete → declare.
I always declared manually structures and arrays. Since i’ve always considered them “more complex” to remember. I guess it’s like this for the majority here…ofc autodeclaring from conditions will not gonna work…as far as i know it was like this even before.
Did it happened to you?..
this is what ppl above asked (not me).
Do someone complained about variables system in the latest 3-4 years?..
Ofc it doesn’t mean that if something works it couldn’t be improved…but has it been improved?..and you know what:…i can’t judge it,…lol… cos i don’t even tried it…for one simple reason…i already have too many clicks …and i’m at a lower ver.
eg…do you hate now amazon cos it had to put spot on prime?..or to click pop ups to watch something in streaming…doesn’t it breaks your “workflow”…lol…personally i find it irritating…but for others may not be
Maybe I should not bump this up but would like to share a couple final thoughts.
I’m 100% agree, from a business perspective, the primary focus must be to meet the needs and preferences of professional developers with large projects and apply good practices. However, I would also take in to consideration the fact, this is what every single game engines out there focusing on. As I mentioned before, it does not make GDevelop stand out in any way. If GDevelop does the same as every other engine, why anyone should use GDevelop instead of all the other professional engines out there, many of which used by big AAA studios.
I think it is worth considering to maintain a balance to keep GDevelop relevant in the beginner space, not only as an alternative but the #1 option and it is just my opinion but event system alone and some templates and behaviours may not going to be enough as almost every engine out there do have some sort of visual coding solution.
Since the changes are set in stone and decisions are final, I would consider the approach of Visual Studio which is to display a “Fix it” button next to the warning or error message and the IDE literally offer a list of actual solutions you can choose from
WARNING: variable is not declared (Fix it)
decalre as scene
declare as global
declare as local
When the “Fix it” button is clicked, a menu popup with a list of options to choose from. It feels the most beginner friendly option to me that can be documented and easy to use.
As you have noticed they don’t want undeclared anymore.
So a method to declare the undeclared…is pointless…imo
The only thing usefull is a method to declare all variables as fast as possible.
Even a method i suggested above has not been taken into consideration…hopefully (for sure) they gonna do better.
…just forget about undeclared…guess they gonna get rid of em in near future
The fact undeclared variables no longer allowed is not really the problem in my opinion, I am more concerned about the beginner user experience of being overwhelmed by all the new concepts and menus need to know in order to be able to build something. For educators it could also be overwhelming to teach so many different concepts to students before the students can build anything on their own.
In case you are referring to declaring scene variables automatically, as 4ian explained the problem with this is that GDevelop doesn’t know if you need a scene or global variable. If GDevelop declare a scene variable by default but you need a global variable then you need to go and edit the declaration and it would create a workflow that is difficult to document and not very intuitive.
This is why my recommendation is simply a Warning with a “Fix it” button similar to Visual Studio and a list to choose from if you want a global or scene variable. Nice friendly yellow warning, only 2 clicks to fix. Not much trouble.
So guys am I got it right - now I need to declare variable with my hands for each objects in objects list (its going to be ~ 50 characters) just to use their group in code?
Every time I want new variable i need to declare it 50 times with hands??
Or there is a way to declare vars to the whole group instantly?
that is what i offered above…but with autodeclaration…If GD knows which var you wrote it should be simple to add automatically to the vars list.