I’ve noticed that Studio doesn’t have that much of a problem with the amount of lines, it has a problem with the amount of lines it is trying to hide when you close a table.
trying to use the Search function in a script with everything “closed” vs “open” has a VERY noticeable difference, it’s “no lag” to “studio froze for 20 seconds” different.
Have you really noticed any lag while opening closing tables?
yup! most of the tables consists of 20+ values, hence why it has 11k lines
Oh… if I may ask. What really is there in the text? Just random dialogues?? Maybe just split everything into 350 line modules and then use one module to import all of them?
Brother, anyone would notice lag, that’s just how Studio works when trying to compute what is and isn’t supposed to be hidden.
The code behind it just isn’t that good, it tries to compute the ideal indentations but even a task like this which is supposed to be basic is broken.
Try to use the “automatic indentation” function on this simple table:
local T={ a={2,5},
b=1,
c=2,
d={1,5},
}
for some weird reason, that entire table would have no indentations, why? because the script “thinks” that, since it has a table value written on the same line as the the original T table is, it overwrites the indentation characteristic of a table, even when it knows the table value is a table which closes on the same exact line.
replace that a={2,5}, for a non-table value and it would have no problems with indentation detection.
now, how would an programming engine that does this NOT be inefficient with calculating LUA’s formatting, specially when it tries to do something like this all the time?
Get 10k lines of tables and values, play around with it, then use the “close all” function and play around with it again, there’s no way you won’t feel a world of difference, and i say that with a very good setup.
I am not your brother >:/
Anyways, thank you a lot for clarifying this! I really didn’t knew that! Maybe because I usually don’t have large tables or just don’t use the close function. Again thanks!
just values that i will use for my code. e.g. Dialogues, AmountOfChoices, AmountOfDialogues etc. there are no functions.
didn’t you just say that using more modules is worse since it takes more space tho?
I see. And Yes I did say it is bad but now I see no other solution for this issue I suppose. Also I just noticed but it’s in the wrong category. I feel like it belongs in #help-and-feedback:game-design-support.
I disagree. I think it should be in Development Discussion since I was initially asking about if 11588 lines were too much.
I saw somewhere that DragDetector’s function via 30k-100k lines of code, from an engineer who worked on it. That’s way too much, in my opinion. 11.5k lines for the average person could be too much as well, but it depends. If the system you’re making is complicated, it could make sense. If instead it’s a lot of different systems mashed into one script, then it is too much. You should try to separate functionality appropriately to increase efficiency and readability.
me having 11k lines just for one single NPC dialogue data (timmy)
The amount of lines of code shouldn’t matter that much.
It’s whether you can still read it or not that matters.
If you can still read your code and navigate through it without a problem it should be fine.
Otherwise if you have problems with navigating you might want to consider splitting your code.
So it’s a rather subjective question really.
There aren’t really any rules for how many lines of code are too much except for the rules that you made for yourself.
the main problem was performance issues.
I would recommend putting dialog for each character/NPC in a different module script.
I’m assuming it’s script editor performance that’s struggling.
i will try that. thanks for the feedback
I try to keep all modules under 1k lines, ideally much less. However, in your case, it sounds like it’s just a dumping ground for dialog, in which length isn’t really an issue.
The studio draggers are, last time I checked, 80-240k lines of code each. Most of it is duplicated dependencies though.
When I made dialog systems, I just used a module script in each NPC, or in the case of it not being an NPC just put each “category” in its own module. You might have to go a bit more specific than “Set1, Set2, Set3” if you want it to actually help, assuming not all of it is NPC dialog.
he’s asking if the code is repetitive, if it is then why not use functions
You could either split your dialogue into different module scripts for each NPC.
Or split them based in progression. What I mean by progression is like in the first part of the game, you require the module containing dialogue regarding the first part. In the second part, you require the next module.
The number of lines isn’t that much of a problem as long as you are organised. Like maybe you wrote something that lets you just Control+F what you need.