Auto Generate Variables

[Slastraf]

If I sometimes work at line 494 in my script and want to create a new variable, i need to scroll to the top and then make a new one , then try to find the line 494 again, remember what I actually called the value (sometimes need to scroll up again ,ha) .

I think one will know what I mean.

 

What would be good Is a tool at the side of the script editor where you it generates values by selecting the data type, what its called and so on.

 

Just a smaller change that I would add to all the changes that we await for the script editor.

[Rick]

Honestly, the bigger question there is should we have single scripts that are 494+ lines long? We should not. If it gets that big it's a great time to try and refactor things out to other scripts (make a system). Now, when I have files this big if I'm prototyping things out, it's always in the back of my mind to refactor out to it's own system/class as it'll improve the readability a ton. It's pretty rare that any sub-system would need to be that big. Just to give an alternative view.

[mdgunn]

Interesting idea. Recent trends in editors have tended towards light-weight editors with plugins to add small extra features which are often simple or text based UI additions. Unfortunately the Leadwerks editor lacks some basic editor tools and doesn't allow plugins.

 

For your scenario I would usually use what in most editors would be called a 'bookmark' at the location I want to return to (not a feature of the editor - but present in most other editors).

 

The other way that is supported is to use Ctrl-G to move to a line number ( so Ctrl-G '0' ENTER will get you to script property area at the top, and CTRL-G '494' ENTER will get you back to your coding location. I think Ctrl-Home and Ctrl-End jump between the top and bottom of the page too.

 

Rick also makes a good point that some good coding practices can help keep things from getting out of hand, such as splitting out functionality into separate files and breaking out lengthy code sections to functions. The main body of the sequential code is then likely to remain close to the property definitions with the function definitions out of the way at the bottom or in separate files. The 'flow code' becomes a series of simple logic statements and function calls and the function names give you something identifiable and memorable to jump to with Ctrl-F should you want to navigate around. It takes some discipline to work this way.

 

I think a lightweight editor with plug-in support would have been a nice way forward to allow the community to drive forward what is perceived to be the necessary extensions, and also to learn and build upon those too. (See Sublime editor, Visual Studio Code, Brackets etc.),

[Crazycarpet]

Why do new variables need to be at the top? For organization sake I guess. But I mean as long as the variable exists in whatever scope you're trying to reference to it from you should be able to define variables anywhere...

 

Maybe I'm misunderstanding the suggestion but often times in Lua I don't want my variable declared at the top, lots of the times I want it to be 'local' to a smaller scope, so I define in further down and sometimes even in it's own block using 'do' like:

do
local whatever = 4
print(tostring(whatever)) --Would print '4'.
end
print(tostring(whatever)) --Would print 'nil'.

 

I do think in some cases it'd be handy, but overall I feel like it'd create clutter, and I feel like there's better things Josh could dedicate time to.

 

Definitely misunderstood the suggestion.

Noticed literally after posting, lol. For a moment I never realized you were talking about the 'Script.' variables that you can see in the editor, this would actually be fairly useful but as Rick said not too many scripts are going to be that large.

[Einlander]

Honestly, the bigger question there is should we have single scripts that are 494+ lines long? We should not. If it gets that big it's a great time to try and refactor things out to other scripts (make a system). Now, when I have files this big if I'm prototyping things out, it's always in the back of my mind to refactor out to it's own system/class as it'll improve the readability a ton. It's pretty rare that any sub-system would need to be that big. Just to give an alternative view.

 

Great if you are using c++ but the lua export version doesn't support linking to external files.

[Rick]

Great if you are using c++ but the lua export version doesn't support linking to external files.

 

I've had a few beers but I'm not sure I follow. You can for sure make lua files other than entity scripts and include those into your lua scripts. With the import statement there is really no reason to have really big lua files.