Iris2.de

Hello Iris2.0 team,

I took a look at the source code and informed myself about lua. I generally understand what lua is.

What my 2 questions are:
1) Why did you use lua? Couldn't you just use c++ and make a full c++ project? What is the big advandage of lua?
2)Is the source code of lua compiled in the exe? Are alle needed scripts compiled into bytecode at runtime of the iris client?

mfg Hurraa

1)
yes writing the hole thing in c++ would be possible but recompiling sucks . there was also a need of a scripting language for macros and stuff like this.
we took lua because we dont like python and lua is capable of everything we needed. its fast and easy to integrate. its also an often used scripting language in games.

2)
yes the lua interpreter is compiled into iris2.
yes iris compiles and interprets all lua scripts at runtime

_________________
O-->---

The lua intepreter is in the iris.exe and all the source code is somewhere lying in ../Data/...?
Isn't it then possible to change iris 2.0 client without any knowledge how to compile client (because all the lua source code is in ../Data/lua/..)?

A last question:
You guys compiled a lua intepreter into the iris.exe. Lugre works with the lua scripts. Who does actually render every frame? C++ or Lua?
I just saw that Lua kind of handles all the filework stuff.

thx Hurraa

I'm new myself to the project but I'll try to answer and they'll correct me if I'm wrong.

The lua interpreter source code is in ..\Iris_SVN\lugre\lib\lua-5.1.4\src, but I think you're asking about the rest of the lua code for Iris. So yes, it is possible to change Iris 2.0 client without compiling the client because in ..\Iris_SVN\lua (and some other places) there are lua files that do anything from packet handling to generating gumps, etc.

From my point of view so far, I want to stay inside of ..\Iris_SVN\lua when helping to improve Iris unless something leads me outside (like a bug or something that affects what I'm doing in Lua).

The lua scripts call on part of their Lugre library (written in C++), and that calls Lugre's (and subsequently OGRE's?) PrepareFrame() and RenderOneFrame() so the answer is C++ because that's what OGRE is written in?

Here's the run down of the actual rendering call:
main.lua: function MainStep () =>
lugre_game.cpp: void cGame::RenderOneFrame() =>
lugre_ogrewrapper.cpp: void cOgreWrapper::RenderOneFrame() =>
OGRE


Of course I think I'd prefer if it were all C++ (recompiling whatever is changed and creating a new exe), but that could be because I just started checking out Lua last week. There is one thing that annoys me about Lua. Since it is dynamically typed, when I find a variable, I'm not able to quickly find all of the available subfields of that variable (like the members of an object).

An example from when I first started is:
local playermobile = GetPlayerMobile() in gui.paperdoll.lua
From the code below it, I knew that the variable playermobile had a serial and name fields, but little did I know it was a full blow mobile with

which was listed as a comment in another file (no header file explaining the mobile object that is easily searchable). I followed the functions calls to obj.mobile.lua and eventually found that comment. But that's not all that's a part of the mobile. In the initialize function more fields are added!

the project consists of 2 parts. iris specific code and lugre specific code. lugre is our "common game code" library. for example the game
http://coffee-n-code.org/project_sites/alteration/
also uses lugre code + very little c + lua.
so the lugre contains a readonly checkout of lugre (c++ and lua part).
the custom game code is in the src (c++) and lua (lua) directory.
the data directory contains all media stuff (images, models, textures, ...).

lugre uses the ogre3d engine. so rendering is done in c++ (ogre3d) but the mainloop is in lua and calls ogre to render the current frame.

nearly the complete game code is written in lua. only some low level things and time critical things
are c++.

@Rabban
i think your explanation is correct and yes some parts and objects are ugly and full of undocumented and not obvious stuff.

_________________
O-->---

mobile and item are two classes that are widely used, we should document them better.

where would you expect to find docs for them ? (e.g. where did you search first) ?



lua scripts are automatically compiled into some internal bytecode by the lua lib at startup, so it doesn't have to be re-parsed from plaintext at runtime all the time.

Good question

I mean if I had been smart, when I saw "local playermobile = " I probably should have gone directly to obj.player.lua and then to obj.mobile.lua instead of just following each function all (which lead me there).

I think my problem was a matter of seeing "playermobile" and then not knowing its type for sure and having no definate place to look (like a class header file as an example).

I guess, if you want to add any comments/documentation, I would put a note at the top of obj.player.lua saying plainly that the player is a mobile from obj.mobile.lua, then make sure that the mobile description of fields is complete at the top of obj.mobile.lua, and finally at a high level (maybe in the doc folder) have either just a fake class hierarchy (because we have no types exactly) with links to the corresponding files where they are sort of defined. It could be a UML diagram if anyone specializes in that sort of thing.

Personally, documenting isn't fun .