Lua interaction? Not really

[L B]

I had been quite impressed when I added that small bit of code that made Lua work magically:

IntPtr lua = Core.GetLuaState();
Core.lua_pushobject(lua, Framework.Pointer);
Core.lua_setglobal(lua, "fw");
Core.lua_pop(lua, 1);

 

 

This is the C# equivalent of the C++ code in the C/C++ forum that Josh posted.

I was quite happy because I now saw the waterplane and the skybox from my test scene directly in my program.

 

Although I noticed something:

• It just takes the Lua scripts, not the SBX file
• It renders the parameters it feels like taking into account.

 

Lua not SBX examples (suggestions):

1. Add a water plane in the Editor. Set its "Softness" value to 4, let's say. Try it in your code. There will be a water plane, but with Softness at 1, the default value. Now edit the water plane script, and change the default value of Softness to 10, if you wish, and save the script. Run your code, the softness will be at 20. In this case, we see that the code interaction does not use the custom parameters of the objects, only their default ones.
2. Add an atmosphere in the Editor. If you have a custom skybox, change it to yours. You will see your new skybox material perfectly in the editor. Now go in your code: You'll see an atmosphere and a skybox, yes, but with the default FullSkies_Clear081284791 material. Now go back in the editor, and change the Lua script of the skybox material to have your custom skybox material as a default. To be adventurous, let's even change the property of our atmosphere instance to the default skybox. Now go back to your program, and you'll see it now has the custom skybox material. Why? Because it only takes the one from the Lua script, not from the SBX file.

 

Selective rendering examples (suggestions):

1. If you still have that atmosphere instance, try setting the default value, in Lua, of "fogmode" to "1" (we already saw that setting it in properties don't work, so if we expect results, better change it directly in the Lua). Now just to be sure, also enable it on your instance of the atmosphere. Go back to your program: the fog isn't there. For some reason, it doesn't render the distance fog.
2. Same goes with Saturation/Brightness/Contrast, if you feel like exploring.

 

My questions are: Is this normal? Do I have to manually parse the SBX? If so, what is the point of the few code lines mentioned above? And if I have to parse the SBX myself, could I please get back the "classname" key?

 

 

On a side note: Is submersion now bugged? Can't get it to work since the last sync.

[TylerH]

Yes, we are experiencing this EXACT same problem with Jeklynn Heights at Vex.

 

Our environment_atmosphere, light, etc. entities do not load their saved properties from the SBX file and run in the LUA script properly, so things like intensity, brightness, saturation, contrast, etc. do NOT work.

 

If you find a solution, please let me know.

 

Maybe we can find out the specific area of cause, or worst case, motivate Josh to get this fixed.

[L B]

Yes, we are experiencing this EXACT same problem with Jeklynn Heights at Vex.

 

Our environment_atmosphere, light, etc. entities do not load their saved properties from the SBX file and run in the LUA script properly, so things like intensity, brightness, saturation, contrast, etc. do NOT work.

 

If you find a solution, please let me know.

 

Maybe we can find out the specific area of cause, or worst case, motivate Josh to get this fixed.

 

 

If I could use "GetEntityKey(ent, "classname");", I could more than easily write a custom parser. But this is not the way Lua means to interact with code.

[macklebee]

If I could use "GetEntityKey(ent, "classname");", I could more than easily write a custom parser. But this is not the way Lua means to interact with code.

 

You do not need the "classname" to do this.

 

And yes, this has been an issue since singlestate was introduced. Its been brought up before now that some of the standard entity scripts do not work now outside of the editor. For example the emitter lua scripted entity will not show up at all outside of the editor.

[gordonramp]

I think this is something for Josh to put right. He is often telling potential customers to go the Lua way, so if they do then there needs to be 'seamless compatibility' between the Editor and the Lua Engine. Workarounds can only achieve so much and they often lead to complications. It's great that we have got this far but I don't think it's time to get too confident yet.

[L B]

You do not need the "classname" to do this.

 

And yes, this has been an issue since singlestate was introduced. Its been brought up before now that some of the standard entity scripts do not work now outside of the editor. For example the emitter lua scripted entity will not show up at all outside of the editor.

 

I could parse it all myself, only it'd be easier if I could just iterate through the children.

[macklebee]

I could parse it all myself, only it'd be easier if I could just iterate through the children.

 

you can find the child if you search for a unique property... like the atmosphere entity should be the only one that has a "skymaterial" key... the waterplane entity should be the only one with a "submersioncolor" key... this is how this has been done for bmax and c++ since 2.3 came out.

[Wchris]

I think this is something for Josh to put right. He is often telling potential customers to go the Lua way, so if they do then there needs to be 'seamless compatibility' between the Editor and the Lua Engine. Workarounds can only achieve so much and they often lead to complications. It's great that we have got this far but I don't think it's time to get too confident yet.

+1

 

i agree, a wisywyg editor is what i was expecting

 

And yes, this has been an issue since singlestate was introduced. Its been brought up before now that some of the standard entity scripts do not work now outside of the editor. For example the emitter lua scripted entity will not show up at all outside of the editor.

also discovered this last week, but did not understand exactly why it was not working.

 

I think this is something for Josh to put right. He is often telling potential customers to go the Lua way, so if they do then there needs to be 'seamless compatibility' between the Editor and the Lua Engine. Workarounds can only achieve so much and they often lead to complications. It's great that we have got this far but I don't think it's time to get too confident yet.

i also agree, workarounds will lead to complications because we will have to remove them once it works like expected, and this can be a difficult task when the code grows. Not to mention it'll be frustrating ... because things that worked one way will no more and request redesign.

[L B]

you can find the child if you search for a unique property... like the atmosphere entity should be the only one that has a "skymaterial" key... the waterplane entity should be the only one with a "submersioncolor" key... this is how this has been done for bmax and c++ since 2.3 came out.

 

I don't feel like I should have to hack an engine that I purchased.

[macklebee]

I don't feel like I should have to hack an engine that I purchased.

 

how is using another key other than classname a hack? classname was just another key given to a an entity...

 

 

in any case though, i agree the lua scripts need to be fixed to actually work outside of the editor correctly.

[L B]

how is using another key other than classname a hack? classname was just another key given to a an entity...

 

 

in any case though, i agree the lua scripts need to be fixed to actually work outside of the editor correctly.

 

From Wikipedia:

Hacking (English verb to hack, singular noun a hack) refers to the re-configuring or re-programming of a system to function in ways not facilitated by the owner, administrator, or designer. The term(s) have several related meanings in the technology and computer science fields, wherein a "hack" may refer to a clever or quick fix to a computer program problem, or to what may be perceived to be a clumsy or inelegant (but usually relatively quick) solution to a problem (see also "kludge").

[macklebee]

And my point is that there is no difference between getting the child of scene by finding a particular classname key as compared to finding a unique key for that child...

 

if you are that hung up on some arbitrary keyname, then just add it to the INI file for each entity that you wish to parse in the SBX file...

 

but in any case, if the lua scripts worked correctly you shouldn't have to parse anything in the SBX

[Pixel Perfect]

The point I guess is that classname was a generic place holder for identifying the entity type in question. Other unique keys may exist which could be used but their original intention was not to fullfill this requirement but to represent a property value. The solution is not very eloquent. This is just the sort of 'pulling the rug from underneath peoples feet' that annoys people. People have to yet again dig into their code and alter it. Not everyone is even using Lua or intends too.

[macklebee]

The point I guess is that classname was a generic place holder for identifying the entity type in question. Other unique keys may exist which could be used but their original intention was not to fullfill this requirement but to represent a property value. The solution is not very eloquent. This is just the sort of 'pulling the rug from underneath peoples feet' that annoys people. People have to yet again dig into their code and alter it. Not everyone is even using Lua or intends too.

 

so add it to the ini file for that entity if you cannot be bothered to change one line in your code

 

and if you are not going to use lua at all, then are you going to delete the lua scripts for all of the standard entities from your game? how do you rectify working in the editor versus what is in your game? use scripts in the editor but not in your game? seems like that would be difficult to do... or at the very least it removes the WYSIWYG feature of the editor...

[L B]

Macklebee, why do you keep on trying to put a temporary, not intended method instead of pushing to get the actual problem fixed?

[macklebee]

Macklebee, why do you keep on trying to put a temporary, not intended method instead of pushing to get the actual problem fixed?

 

if you look at the old 2.2X LE, the standard entities all had the classname keys inside them. This is not the case for 2.3. So add it to the friggin INI file yourself! I don't understand why you expect Josh to do that for you... yes, it would have been nice if it already came like that... but sheesh, Josh has alot of more important things to work on than to add one line to a text file for you...

[Pixel Perfect]

use scripts in the editor but not in your game? seems like that would be difficult to do... or at the very least it removes the WYSIWYG feature of the editor...

Thats the exact point I'm trying to make. We are all being forced down the Lua route like it or not ... this was not what we were led to believe prior to the release of 2.3 I prefer to handle everything directly myself in C++, I don't want to be reliant on other peoples high level code unless I chose to. We have only really just got the engine API stable and now we are adding dependancy on a whole new layer and one which is much slower and suffers from a complete lack of professional debug facilities.

 

I've not bought into the 'Lua is the new holy grail' bit and I object to being railroaded into it!

[VicToMeyeZR]

 

 

I've not bought into the 'Lua is the new holy grail' bit and I object to being railroaded into it!

 

Well if it wasn't really good, I don't think some of the big name AAA titles would have used it, do you?

[macklebee]

not disagreeing with you one bit... it should be optional. I was just curious on how you were handling the fact that the Editor uses scripts to handle stuff and your program does not... So I assume that you do not even bother with putting entities like the atmosphere, emitters, waterplanes, in your editor scene then? Since all of those things you are saying that you are going to control by your code... I am just curious on how you handle it... because at the moment, I am getting tired of the lua only working in the editor as well.

[Pixel Perfect]

Well if it wasn't really good, I don't think some of the big name AAA titles would have used it, do you?

AAA companies do not use LUA to write their game engines as far as I am aware, its generally used for high level scripting of AI of which all of the base functionality has already been written in C++ or some comparable language. But this is besides the point, we were given the impression by Josh that LUA would be optional and its not proving to be quite the case!

 

 

not disagreeing with you one bit... it should be optional. I was just curious on how you were handling the fact that the Editor uses scripts to handle stuff and your program does not... So I assume that you do not even bother with putting entities like the atmosphere, emitters, waterplanes, in your editor scene then? Since all of those things you are saying that you are going to control by your code... I am just curious on how you handle it... because at the moment, I am getting tired of the lua only working in the editor as well.

I could use the editor as a full WYSIWYG level designer and rely on the use of scripts but I really don't need to as I mainly use my own Editor for the fine tuning and dynamic running of my game levels. Most of my emitter based classes have lots of encapsulated functionality with them and I create them in my own Editor either with simple placeholders in the sbx file or via a seperate config file that is saved from my editor and loaded by the engine. Now I could convert all this to LUA and gain the advantage of using them directly in the Editor, but then I'm having to do so in a language which is not my first preference and there are many things that the leadwerks Editor just can't do for me anyway ... so there is little gain for me.

[Josh]

The problem with the SBX properties not loading is fixed in the DLL which has been uploaded.

 

If you want the file name of a model, there is a command for that:

http://leadwerks.com...odels#ModelName

 

If you want to add a "classname" property for parsing, just open the model .ini file and add something like this:

classname="light_directional"

 

That is how it is done in SDK 2.25. I think it is easier to just rely on the model name, because then there is not an extra property to add. Instead of looking for a classname value called "light_directional" look for a file name called "light_directional" (with the file path and extension removed).

[macklebee]

The problem with the SBX properties not loading is fixed in the DLL which has been uploaded.

 

I don't know why you need a "classname" property, or why you can't add your own if you feel like it. I don't recall ever using this, except in 3D World Studio, a long time ago. If you want the file name of a model, there is a command for that:

http://leadwerks.com/wiki/index.php?title=Models#ModelName

 

well, before 2.3 you had the key "classname" inside the INI files... now its not there or the INI file doesn't exist for all entities... but yes, exactly... its just a key.

 

Also, whats going on with Vec2's? they seem to be different as of last night's sync.

[L B]

if you look at the old 2.2X LE, the standard entities all had the classname keys inside them. This is not the case for 2.3. So add it to the friggin INI file yourself! I don't understand why you expect Josh to do that for you... yes, it would have been nice if it already came like that... but sheesh, Josh has alot of more important things to work on than to add one line to a text file for you...

 

Well, I'm not complaining about this. Adding the line or a custom property myself isn't trouble, except I would expect the base entities like atmosphere to work without me having to modify them. But it's all fixed now, will test them tomorrow.

[Josh]

I really recommend using the model name, because it is pretty redundant to have to add a classname property any time you add a new class.

[Wchris]

The problem with the SBX properties not loading is fixed in the DLL which has been uploaded.

 

Thanks Josh ! Very fast like always

 

i synced 2.3 and it works much better now. Except for Macklebee's problem, the firepit's fire particle is still not showing.

 

can you do something about this also ? Many Thanks