I’m talking about instances like gunship battle where you would have to export whole transport manager, there are also scripts that use world packets and with upcoming packet structure changes you would have to export specific serverpacket classes or it would cause a lot of code duplication otherwise. Which in turn would lead to searching all scripts to update a packet structure.
Spells are part of specific bosses and they are closely tied to their boss scripts. It would cause code fragmentation where you would have to modify completely different parts, one in lua, other in C++ to fix a bug. There would also be situations where half instance is scripted in lua and other half in C++ which isn’t really attractive.
I’m not saying that it can’t be done in lua but the whole idea of this scripting engine is to make scripting easier and in most boss script situations it just isn’t easier than C++
I would however request that PRs which use the C++ system don’t start getting rejected with the reason “do it in Lua” (and vice versa), unless of course there’s a clear outline such as “Scripts for SAI will only be accepted in Lua” so everyone is on the same page.
Well it isn’t exactly “extremely easy”. Google “c++ pointers in Lua” and you’ll find a lot of interesting discussion. There are 3rd party libraries which make the task easier but it still looks like it would overly complicate things which can already be done with the C++ engine.
It would be a royal pain for a Lua script to generate a Unit pointer (eg: Unit*) to pass to a function exposed by the core. You basically need a separate version of the Unit class for the Lua C API to work with. Not impossible but why bother?
For example, this is one of the problems with it having no type safety or checks:
Light user data is the way to go if you literally just want to pass a pointer around.
A problem with light user data, however, is that you can’t tell what kind of pointer it is. It really is just a void*. So a C++ function bound to Lua could have any light user data passed to it and you have no way to distinguish whether it’s a GameObject* or a Texture*, unless you build your own system outside of Lua to identify these objects from a void*.
This is all about using the correct tool for the job. I don’t see why I should script, say Deadmines, Scarlet Monastery, Stratholme etc in cpp when it can be done easily and feasibly in Lua. I’m no expert on the subject of how spells are scripted, but as far as I’m aware spells are not scripted inside the instance/boss cpp am I correct? If so, then how is this any less fragmented than adding the spell script to one location and the boss script to another? I can’t think of a spell that has to be specifically handled for a boss fight that is also used for something completely different that would need any special override for that one boss only.
I can see larger events, like the gunship battle being done in cpp, however there’s nothing stopping any of the required functions to be ported to the Lua API.
Also, packets as you brought up, if need be, can also be handled in Lua for the special cases where they would have to be used. The way the Lua API works is they wrap the core functions the exact same way you would call them in a cpp script. So if you first have to update any structure, you’d have to do the same amount of job in cpp as with your Lua wrapper. If done properly then the scripts themselves wouldn’t necessarily have to be touched at all.
I won’t get into the technical aspects of all of this as this is not my forte, and I’m sure Rochet could get into greater detail as to how this works, but we do have methods in place to retrieve a unit’s object (pointer). These are the same functions the core use to retrieve a unit’s pointer, simply wrapped and exposed to the Lua API.
And on 3rd party libraries, we did play around with… whatever it was called, I cannot recall as of right now, and had a functional version using the said library to expose the entire core function list for creatures, players etc. We did however decide against using it.
Spell scripts are actually in the same file as boss script. Sure vanilla/bc instances are easy to script and can be done with simple functions but MoP, WoD scripts are way more complicated.
And about the packets. For every different packet that you would have to add it to lua wrapper and how does that make scripting easier than in C++? I don’t think that scripting should involve making wrappers for every other script.
You are talking like you are going to make a wrapper for every core header file, why not just rewrite core in lua then? There are things that are better done in C++ and you shouldn’t make workarounds just to prove that it can be done in lua.
No, you wouldn’t have to make a wrapper for every single packet. See http://pastebin.com/VWLXjqcp as an example. Packets can be both created, sent and read in Lua. The generic CreatePacket and SendPacket wrapper is what would have to be edited if the core function structure was changed.
And no, I’m not talking like I’m going to wrap every single core header. This is simply to prove a point. Like I said, this is about using the correct tool for the job. I don’t see cpp being the correct tool to use when scripting things like generic instance and boss scripts, however this is personal preference.
Would you not have to do this anyway? And no, not necessarily. You could have an extension containing the used packets and call the said functions, like the above script, in any other Lua script.
just to let you know, constructing a packet in any script is just a hack, there is no script which should ever use this, so dont even try to bother with it /emoticons/default_smile.png
That’s fine, was just showing the above that packets can be done just as easily in lua as in cpp, since he brought that up as a reason why not to use a scripting language
Not even that, the instances he mentioned were completely changed in Cataclysm and are now way more complicated to script, in fact, most instances are.
Be it complicated or not is still besides the point. What I wanted to know was whether or not scripts working 100% blizzlike would be rejected just for the sake of them being written in Lua and not in cpp.
We still haven’t discussed that within the team, but my take on it is yes, boss and instance scripts would get a “No” from me if they were done in Lua instead of C++.
To add to that, we’d also like to improve on our current implementation of C++ scripting, I personally like Intelz’s idea.
Let’s split this discussion into a separate topic if needed. One for ideas to improve our current core C++ scripting implementation and this for Lua with the strict requirement that it would be for a certain set of things.
That said, I say we lock this for now until the team decides which is to be used for which.
Other than the fact there’s no void function DoSomething() this looks as “simple” as C++ would be. I guess I still don’t get it, other than the hotloading which can be done with libraries, I still don’t see how it’s simpler when the code is identical (wait() is just a wrapper for sleep()).
Well technically there is no default wait() in Lua, there’s a “busy wait” and a “sleep” which both do the same thing and could also be easily implemented in C++. Also, for Boost threads there’s condition_variable::timed_wait() which again isn’t “hard”. Since we already use Boost, why not… use it?
A common need is to pause (sleep) a program for a certain number of seconds, preferably without busy waiting.
This function to do this without busy waiting does not exist in ANSI C, so it does not exist in stock Lua. However, there are extension libraries and calls to external programs that can do this.
Either way, I’m still not convinced that “simple” scripts in Lua would be any more difficult to do in C++ but that’s just my opinion.