Leadwerks 5 Scripting

[Rick]

Couldn't you just get away with 1 LE extension for VS Code that allows that communication and debugging communication? I mean VS Code only needs to know from LE to run when in debug mode right?

[Josh]

2 minutes ago, Rick said:

Couldn't you just get away with 1 LE extension for VS Code that allows that communication and debugging communication? I mean VS Code only needs to know from LE to run when in debug mode right?

Okay, so we are looking at something like this then:

[Rick]

Yeah, that way the only thing you have to really create is the 1 extension and the only thing us users have to get is said extension.

[Josh]

I think it would be pretty awesome to have previewers for tex and mdl files.

[Rick]

Just note that because VS Code is built with html/css/js that I would think any 3D viewer you can get working will use WebGL (if that matters). I would love to see that because if WebGL works good enough for an editor then the entire LE editor could be an extension for VS Code OR at least built with Electron which would make extending it as easy as extension VS Code. It also makes creating interesting UI's easier because there are so many stylings for html/css/js that it's crazy. Anything you can imagine is easy to create with that stack from a UI side. I personally would think WebGL would display 3D stuff well enough for the world editor. But if you start just with the model viewer you'd learn more to know if that's possible.

[Josh]

1 minute ago, Rick said:

I would love to see that because if WebGL works good enough for an editor then the entire LE editor could be an extension for VS Code OR at least built with Electron which would make extending it as easy as extension VS Code.

It would be good enough for simple viewing of 3D objects with no effects or shadows. Texture files don't need any 3D rendering at all.

[Rick]

lol You'll get there eventually. Maybe LE 6. Then you'll wonder why you didn't do it sooner

[AggrorJorn]

So is this something I can help out with Josh? Snippets aren't a problem and generating them from the xml files is something that I can look in to. If you your focus on the debugger, I can help you out with the documentation stuff. 

[Josh]

2 minutes ago, AggrorJorn said:

So is this something I can help out with Josh? Snippets aren't a problem and generating them from the xml files is something that I can look in to. If you your focus on the debugger, I can help you out with the documentation stuff. 

You are definitely welcome to pursue the XML / snippet stuff. I don't plan on writing an extension for the debugger myself, I will just find someone who already knows how to do that and have them do it. I want to focus on the engine.

[AggrorJorn]

15 minutes ago, Josh said:

You are definitely welcome to pursue the XML / snippet stuff. I don't plan on writing an extension for the debugger myself, I will just find someone who already knows how to do that and have them do it. I want to focus on the engine.

Thats awesome to hear Josh. I am certain there are people who have made these debugger before. I am going to focus on getting the docs in to the extension now. 

Source code can be found in github: https://github.com/Aggror/VisualStudioCodeLeadwerksExtension

Package updated with some new snippets.

[Rick]

What about a snippet that creates all the LE script functions? I know in VS for angularjs I type ngController and it sets the entire method up. Maybe lescript could create what gets created when you create a script from LE today? All commented out as well.

[Josh]

25 minutes ago, AggrorJorn said:

Thats awesome to hear Josh. I am certain there are people who have made these debugger before. I am going to focus on getting the docs in to the extension now. 

Source code can be found in github: https://github.com/Aggror/VisualStudioCodeLeadwerksExtension

Package updated with some new snippets.

You really want to automate the Leadwerks command stuff. That way if we make a small change to the way it is laid out nobody has to go back and modify 1000 items.

For Lua, I prefer to have the type of statement it is clearly marked:

	"Table Insert": {
		"prefix": "table.insert",
		"body": "table.insert($table,$value)",
		"description": "Inserts a value into a table at the end of the table."
	},
	"Table Insert ": {
		"prefix": "table.insert",
		"body": "table.insert($table,$position,$value)",
		"description": "Inserts a value into a table at the given position."
	},	
	"Function Declaration": {
		"prefix": "function",
		"body": [
			"function $funcname($argument1)",
			"\t$0",
			"end"
		],
	  	"description": "Declares a function."
	},
	"If Statement": {
		"prefix": "if",
		"body": [
			"if $condition then",
			"\t$0",
			"end"
		],
	  	"description": "Conditional statement."  
	},

And the scheme below works well for Leadwerks commands. Each duplicate key gets a space added after the key to make all keys unique, and the description tells the class the method belongs to:

	"Entity:SetPosition": {
		"prefix": "SetPosition",
		"body": "SetPosition($x,$y,$z,$global)",
		"description": "Entity Method\nSets the position of an entity in 3-dimensional space, using local or global coordinates."
	},
	"Entity:SetPosition ": {
		"prefix": "SetPosition",
		"body": "SetPosition($position,$global)",
		"description": "Entity Method\nSets the position of an entity in 3-dimensional space, using local or global coordinates."
	},
	"Entity:SetRotation": {
		"prefix": "SetRotation",
		"body": "SetRotation($pitch,$yaw,$roll,$global)",
		"description": "Entity Method\nSets the rotation of an entity in 3-dimensional space, using local or global coordinates."
	},
	"Entity:SetRotation ": {
		"prefix": "SetRotation",
		"body": "SetRotation($rotation,$global)",
		"description": "Entity Method\nSets the rotation of an entity in 3-dimensional space, using local or global coordinates."
	},	
	"Source:SetPosition": {
		"prefix": "SetPosition",
		"body": "SetPosition($position)",
		"description": "Source Method\nSets the position of a source in 3-dimensional space, using global coordinates."
	},

And then here's a static class function and a constant, both clearly marked:

	"Window:Create": {
		"prefix": "Window:Create",
		"body": "Window:Create($title,$x,$y,$width,$height,$style)",
		"description": "Window Static Function\nCreates a new Window object"
	},
	"Window.Titlebar": {
		"prefix": "Window.Titlebar",
		"body": "Window.Titlebar",
		"description": "Constant"
	},	

 

[Rick]

Those lua statements are pretty verbose. One of the main points of snippets is to be short and to the point. Generally not having spaces or capital letters. Since in lua you type "if" for the statement then "if" would make more sense. For table insert just tblinsert as most ppl will type tbl and it'll come up and they'll hit enter. It's more about grouping correctly with the first letters so people can just filter quicky and then use arrow keys to select the item.

 

[edit]

Dear god please give me that "print" snippet! I'm so sick of typing System:Print("") all the time!

[Josh]

1 minute ago, Rick said:

Those lua statements are pretty verbose. One of the main points of snippets is to be short and to the point. Generally not having spaces or capital letters. Since in lua you type "if" for the statement then "if" would make more sense. For table insert just tblinsert as most ppl will type tbl and it'll come up and they'll hit enter.

You start typing table.insert, and then snippet acts as autocompletion. There are tab stops marked so you can fill in the values quickly: The descriptions explain exactly what the statements are.

Making up new keywords like tblinsrt is dumb because now you have two APIs to memorize.

[AggrorJorn]

21 minutes ago, Rick said:

What about a snippet that creates all the LE script functions? 

Update with that. If you have more ideas feel free to list them here.

[Rick]

3 minutes ago, Josh said:

You start typing table.insert, and then snippet acts as autocompletion. There are tab stops marked so you can fill in the values quickly: The descriptions explain exactly what the statements are.

Making up new keywords like tblinsrt is dumb because now you have two APIs to memorize.

Snippets and autocomplete are 2 different concepts. It sounds like you guys are trying to merge them which might be a bad idea. There are a decent amount of table functions for lua so when I type "tbl" they would all come up. I'd arrow to the one I want and it'll fill it in for me. That's what snippets are and do.

[Josh]

2 minutes ago, Rick said:

Snippets and autocomplete are 2 different concepts. It sounds like you guys are trying to merge them which might be a bad idea.

Exactly. The VSCode snippets are good enough I think they can be used for the LE5 autocompletion for Lua. It's not 100% perfect but for a dynamically typed language I think it is sufficient and it prevents those "der...what's that command called?" moments.

[Josh]

Information on creating a custom debugger. Looks like it communicates through stdin/stdout alone:
https://code.visualstudio.com/docs/extensions/example-debuggers

So if I write a command-line debugger for Leadwerks (using Leadwerks[!]) I think it's just a matter of knowing what the VSCode text syntax for debugging is.

[Niijel]

Just a few brief comments from a leadwerks noob - I think the event hook for plugins is very neat, I prefer the comment route for variable types ( hate anything automatic as they inevitably will make mistakes). Its worth having a read of the process the GoDot devs went through with the same issues relating to script languages - I dislike their end result but they considered the same issues to get there.

If I had to vote for a scripting language my vote would go to LUA. - mainly because of the resources and examples available across the internet and its stability and current age, regardless of the capabilities of squirel/atom etc are they still going to be around in 3 years?

What I do think is important with plugins/API usage is easy identification of sources of instability / bugs in 3rd party code and the tools to help avoid them (frameworks,examples,test rigs) I prefer this to rigid standards and 'authorisation'/'official'/'approved' methods as these can stifle inovation.

Great progress towards 5 is being made and it is going to be amazing - keep up the good work Josh and everyone involved!

 

[AggrorJorn]

On 3/17/2018 at 4:21 PM, Rick said:

It sounds like you guys are trying to merge them which might be a bad idea.

Extending the intellisense of vs code so that Leadwerks specific objects are recognised would be preferable. However generating snippets based on the Le API is an alternative/backup solution. It is part of the experiment to see what works best.

[Josh]

22 minutes ago, AggrorJorn said:

Extending the intellisense of vs code so that Leadwerks specific objects are recognised would be preferable..

This sounds like a never-ending task that will never be quite right. The snippets generated from the docs sound like something that can be realistically done within a few days and solve the big problem of not knowing what commands are available or what arguments they take. I think for a dynamically typed language this is satisfactory.

if we can get smart pointers, debugging, and API snippets working with VS Code the experience already will be miles ahead of LE4. It will be a great experience for experts and beginners alike. I can’t wait to use it.

[Josh]

On 3/16/2018 at 12:33 PM, Josh said:

• Autocompletion with knowledge of Leadwerks API and Leadwerks C++ types.
• Debugging.
• Exposing C++ classes to script with support for smart pointers.

Okay, so autocompletion is accounted for, in my opinion.

I have create a CL debugger and I can find someone to write the debug adapter based on this code.

The next big concern is smart pointers in Lua and how the object persistence will be handled.

[AggrorJorn]

What was your opinion on the api docs being hosted on Github? I think it would make changes to the API as well as the generated snippets a lot more maintainable and complete.

 

[Josh]

11 minutes ago, AggrorJorn said:

What was your opinion on the api docs being hosted on Github? I think it would make changes to the API as well as the generated snippets a lot more maintainable and complete.

 

I'm not very motivated to work on that right now since I would then have to grant permissions to specific people and still manually update the website, and it's just a lot of time fiddling around with web stuff.

[AggrorJorn]

1 hour ago, Josh said:

I'm not very motivated to work on that right now since I would then have to grant permissions to specific people and still manually update the website, and it's just a lot of time fiddling around with web stuff.

Maybe at a later stage perhaps. For now I will use https://www.leadwerks.com/documentation/toc.xml to retrieve the latest xml and generate the snippets.