Faster turnaround/iteration time for scripting

[Tvok 10]

In this thread, post any tips or tricks you've found to get faster turnaround time when writing/testing SQF scripts (both MP and SP).

My current process for testing SQF scripts in MP is:

• Make changes to the SQF file in notepad++
  
• Click exit to get out of the mission
  
• Prompts if I'd like to exit (yes/no)
  
• Saves the game
  
• Press escape to get out of debriefing
  
• Press escape again to leave the lobby
  
• Click 'Restart' to get rid of save data (prompts yes/no)
  
• In lobby, join as the first slot
  
• Click continue in briefing to get into the game again
  
• If the script didn't work, scour my changes to find out what went wrong
  

If anyone knows ways to speed up this process, post them here! Some things I'd like to know about:

• Disabling save/load
  
• Auto joining with no lobby
  
• Skipping briefing/debriefing screen
  
• Syntax checker or better editor for SQF, outside of the engine
  

My first tip to everyone:

Make sure to put '-showScriptErrors' in the launch options for Arma3, and take screenshots when the errors appear.

[KC Grimes 79]

enableSaving [false, false];

I'll take my payment in cash, please.

No seriously, put that in your init.sqf while you are still editing your mission, that way you don't have to save for 3-5 seconds every time you exit the mission, and no need to hit restart.

Auto-join without lobby would be done in SP. So, depends on your mission, and depends on what you want to test. Personally I don't suggest this. I test all missions in the MP menu, just to keep it all in one place. Doesn't hurt, only helps.

Nothing you can do about briefing screen I believe.

For Syntax checker, there are plenty. I cannot for the life of me remember what the name of the one I use is, but give it a google. There are plenty Arma 3 syntax highlighters for Notepad++, and other programs.

[kremator 1065]

Notepad++ is my personal favourite.

[Grumpy Old Man 3550]

Using notepad++ changed everything for me, especially with the syntax highlighter.

What I'm wondering about is, if there's a way to auto format code with notepad++, so it formats the code using rules like indenting new brackets etc.

[das attorney 858]

My first tip to everyone:

Make sure to put '-showScriptErrors' in the launch options for Arma3, and take screenshots when the errors appear.

Better than that, check the .rpt file for log of errors :)

[k0rd 3]

I thought this was going to be script optimization thread :)

[Tvok 10]

;2672227']

enableSaving [false, false];

Awesome.

Better than that' date=' check the .rpt file for log of errors :)[/quote']

Awesome.

Already those helped immensely. I'm even seeing errors that weren't being reported via 'showScriptErrors'.

I happened to find a mini tutorial on skipping the briefing screen:

http://killzonekid.com/arma-scripting-tutorials-how-to-skip-briefing-screen-in-mp/

I also found another one on skipping debriefing:

http://forums.bistudio.com/showthread.php?175344-Skip-Debriefing

I have yet to test either of them (I know one is for Arma2). I will report back tomorrow with my findings :D

[Magirot 14]

In lobby, join as the first slot

joinUnassigned = 0; in description.ext will skip this bit, if you meant that you choose the slot manually.

What differences are there in testing in a non-dedicated server MP, and the editor's preview, by the way? Besides scripts like initServer, initPlayerLocal etc. being executed.

[Tankbuster 1747]

;2672227']

enableSaving [false, false];

/thread.

---------- Post added at 09:01 ---------- Previous post was at 08:58 ----------

Use an RPT watcher. I use baretail.

I wrote more about it here' date=' if anyone is interested.

[url']http://forums.bistudio.com/showthread.php?176552-Baretail-RPT-viewer[/url]

Edited April 21, 2014 by Tankbuster

[Larrow 2827]

Ill second Tankbuster's recommendation for baretail. Awesome for debuging your scripts and watching your own diag_log's with colour coding to determine script flow.

[Tankbuster 1747]

For file editors, I use Freds Posiedon editor. Better than np++ in almost every way.

[holo89 10]

For file editors, I use Freds Posiedon editor. Better than np++ in almost every way.

+1 for poseidon

edit: using load folder as project is kind of powerfull. And you can search throughout your missions files this way. also has color which is different from notepad, took me a bit to get used to new colors. I really recommand it, and explore it, it worth the time.

Edited April 21, 2014 by holo89

[Tvok 10]

For file editors, I use Freds Posiedon editor. Better than np++ in almost every way.

Looks good and targets Arma, I'll give it a try!

Auto-complete is probably the thing I wish for most to speed up script dev time (I see it has some support for that). Having to bounce back and forth between a browser / arma community wiki and back to scripting takes a lot of time.

[holo89 10]

Looks good and targets Arma, I'll give it a try!

Auto-complete is probably the thing I wish for most to speed up script dev time (I see it has some support for that). Having to bounce back and forth between a browser / arma community wiki and back to scripting takes a lot of time.

it has, and even variables autocomplete...

also try positionning on an arma keyword like allowDamage, and press F1... bang the wiki on it...

[DasClark 10]

Just a little heads up, if your script is called directly (and not precompiled into a function), you don't even need to leave the mission to change it. It will load every time you call it. This way, you can put it on a repeatable radio trigger or addAction to test. Make it quick to debug certain types of scripts.

Das

[Tvok 10]

Just a little heads up, if your script is called directly (and not precompiled into a function), you don't even need to leave the mission to change it. It will load every time you call it. This way, you can put it on a repeatable radio trigger or addAction to test. Make it quick to debug certain types of scripts.

Das

Fantastic. Most the stuff I was doing was in init (setting up callbacks using addAction and addEventHandler). Now that I know calling a file/function re-compiles each time, I'll definitely move that action/event code to their own files. I might even add a special action to 'un-init' anything that was previously setup.