02-25-2014, 01:56 PM
> Working with ZBS is a bit cumbersome due to the fact that our plugins can span over multiple files, the studio has hard time dealing with that. For example the project analysis only works on a single file, not on the entire "plugin" (in the MCS sense).
Do you mean static code analyzer? Yes, the analysis is done only in the current file. The rest of the functionality doesn't depend on any particular project/file structure.
> As for the interpreter, I don't quite follow what all those functions get for parameters and what they are expected to do and what to return.
The "interpreter" logic sets some parameters (like redirect) and calls whatever executable is needed. For "normal" Lua interpreter, it's "lua" or "lua.exe". The bulk of the functionality is to figure out where the executable is on different platform and how to run it with the current file/project.
> The API part will be difficult, too, since some of our API functions are overloaded - they support multiple different sets of parameters, although technically they are all under the same function name. Take for example the constructors for cBoundingBox class ( http://mc-server.xoft.cz/LuaAPI/cBoundingBox.html ) - there are four of them. I haven't seen anything in the ZBS API specs that would allow this.
You are right; there is nothing that handles overloaded functions. In one case where this came up I suggested to use one signature to specify args/returns and put the rest in the description itself. I've been thinking about ways to support this, but it's not likely to be implemented earlier than v0.42.
Here is an example of how this may look:
return {
cBoundingBox = {
args = "(MinX, MaxX, MinY, MaxY, MinZ, MaxZ)",
description = [[(cBoundingBox) cBoundingBox (OtherBoundingBox)
(cBoundingBox) cBoundingBox (Min, Max)
(cBoundingBox) cBoundingBox (Pos, Radius, Height)
Creates a new bounding box...
]],
returns = "(cBoundingBox)",
type = "function"
},
}
Save this as api/lua/mc.lua and add "mc" to api = {"wxwidgets","baselib","mc"} in interpreters/luabase.lua if you want to enable this in "default" Lua interpreter.
Do you mean static code analyzer? Yes, the analysis is done only in the current file. The rest of the functionality doesn't depend on any particular project/file structure.
> As for the interpreter, I don't quite follow what all those functions get for parameters and what they are expected to do and what to return.
The "interpreter" logic sets some parameters (like redirect) and calls whatever executable is needed. For "normal" Lua interpreter, it's "lua" or "lua.exe". The bulk of the functionality is to figure out where the executable is on different platform and how to run it with the current file/project.
> The API part will be difficult, too, since some of our API functions are overloaded - they support multiple different sets of parameters, although technically they are all under the same function name. Take for example the constructors for cBoundingBox class ( http://mc-server.xoft.cz/LuaAPI/cBoundingBox.html ) - there are four of them. I haven't seen anything in the ZBS API specs that would allow this.
You are right; there is nothing that handles overloaded functions. In one case where this came up I suggested to use one signature to specify args/returns and put the rest in the description itself. I've been thinking about ways to support this, but it's not likely to be implemented earlier than v0.42.
Here is an example of how this may look:
return {
cBoundingBox = {
args = "(MinX, MaxX, MinY, MaxY, MinZ, MaxZ)",
description = [[(cBoundingBox) cBoundingBox (OtherBoundingBox)
(cBoundingBox) cBoundingBox (Min, Max)
(cBoundingBox) cBoundingBox (Pos, Radius, Height)
Creates a new bounding box...
]],
returns = "(cBoundingBox)",
type = "function"
},
}
Save this as api/lua/mc.lua and add "mc" to api = {"wxwidgets","baselib","mc"} in interpreters/luabase.lua if you want to enable this in "default" Lua interpreter.