Open davidlav opened 7 years ago
I can confirm this, nice summary @davidlav this bugged me a lot too, wonder why i didn't notice it. Addition it's not a one time, end of line, scope or file thing. Thank you for the report @davidlav
I noticed this a while back as well. This is currently unfixable because the plugin has no way of knowing if the command on the next line is needing the code brackets. This would be fixable if I had type checking implemented.
Example of what I'm saying:
if true then{} //1
enableSimulation true;
The missing semicolon at //1
won't trigger a syntax error because the grammar thinks enableSimulation is continuing the if statement as if it were typed as such: if true then {} enableSimulation true;
Here is an example of when the code brackets with a command following it is required :
while {b > a} do {a = a + 1}; //{b > a} comes with do {a = a + 1}
Optional warning would be a workaround. Not optimal but a workaround. Maybe with a "disable" button.
Yea it could be an inspection. Would be simple to implement as well.
"type checking" would be very sweet. I'm thinking about contributing, but that would begin with small problems and not that. Did you already search for an easy way to get consistent "type info" for commands of off BIS ?
if true then{}
[] spawn _bla;
This should be easily detectable!
Did you already search for an easy way to get consistent "type info" for commands of off BIS ?
Yes. The issue isn't getting the info. The documentation on the wiki would need to be converted to something that the plugin understands and is also consistent (the wiki isn't 100% consistent). There are currently close to 2,000 commands, some of which have multiple syntaxes. I've done math a while back and it would take about 20-50 hours non-stop with my current method to properly convert all of the commands (and that was with a custom GUI program and automation! lol). I've been brain storming a better method ever since then, but have been falling short. I guess it comes down to algorithms for parsing the wiki.
@kayler-renslow that's what i meant, was thinking about that and that's where the "easy" came from. Machine-learning ? input poorly parsed info from the wiki into something like open ai and give it reward when Arma don't throws errors ?
I looked into the source code of the wiki and the command syntax documentation is essentially plain text. I already have a decent parser to output files relevant to the plugin, but I still have to verify the correctness of each command, which is where the 20-50 hours comes from. Parsing the commands takes only about 3 minutes in total.
I made a custom GUI to make verification and editing faster, but it's extremely tedious. I wrote the code way back in probably June 2016 and managed to complete about 20 or so commands. I thought I was making progress but then realized that after about 30-40 minutes of work, I only completed about 1% of all commands. If I kept at it, it would be done by now for sure.
Type checking would be amazing, but I can't even imagine how difficult that would be to implement in something like this. Just following the conversation though, I would have done exactly what you did insofar as trying to parse the wiki to mine out parameter and return types. But they do so much function (or command) overloading that I can see how that might get very tedious.
It's a shame that a game that has such a rich scripting component has such shitty resources for coders. No official IDE, horrible, god-awful documentation, and a really bizarre syntax to boot.
I wish so bad for Arma 4 (or whatever's next) that with the new engine they'd just switch the scripting language to C++, or really anything with a syntax that lets me access array elements with square brackets, and make a downloadable library with all the commands/functions. But that's just me dreaming...
I would probably have a half-implemented type checking system; each command knows what prefix and postfix parameters it needs (if any). If the parameter is a command, array, primitive, or code block, the type can be immediately asserted, otherwise just make sure a variable is there. Once we get into variable territory, it becomes a nightmare. I suppose I could do shallow type checking for local variables (only check their type in the current file)..
Plugin Version
1.0.7
Summary
Syntax checker doesn't catch missing semicolons after the do {} blocks following switch statements or the then {} blocks following if statements.
Detail
Leaving semicolons off of code blocks is really easy to do since that's how most other languages (at least that I've worked with) operate. Arma's debugger was even telling me there was a missing semicolon and it still took me 10 min to find it because my eyes just weren't used to seeing one there.
Thanks for such a great plugin though!! Way better than all the other IDEs out there.