Hi.

I think it would be nice to be able to expose properties from Lua and set values in the properties tab of the entities instead of hard coding them. This way, we could create a script that we can reuse for multiple purposes that require different values only.

For example, I have created a light switch script that toggle on and off selected lights. But at the moment the way I did it is to enter the ID values of the lights to toggle in to the script itself which means for different switches I need different scripts to toggle different lights. Maybe there is a solution to this, but my point is, if we could expose properties then in similar cases we could have a single script only and set values right in the editor for each entity using that script.

Basically, handle lua script as a component in the properties tab for each entity similar to Unity and other modern engines.

Property types to expose could be:

number
text
Vector2
Vector3
Vector4
list (enter values separated with a comma)
color (would display an actual color picker in the properties tab)
image (pick an image to load from local drive)
sound (pick a sound to load from local drive)
slider (for entering numbers but in case we want to allow people to use a range of values only)

A question.
Should I post this on GitHub or it is fine, devs going to find it here with the Feature request tag?

Thanks.

I believe that Lua is loaded to memory before the game starts, that is why in the editor we need to save the map file before the new lua scripts take effect.


Lets see what others say about this.


But GitHub is the place for this if you want the dev's to see it.

You can read the parameters (well some of them at least) from your Lua script, so for example if you want to pass a number value into a script you can use the 'strength' field in parameters (which in Lua is 'health'). Or you can pass in strings by appending them to the entity name then parsing the name in your script.

@AmenMoses
Thank you for the tip I'm going to try to do that for now

@Pirate Myke
Even if the script get loaded first, it would be executed only after the entity the script is attached to is loaded or not? I don't know how it works only thinking that if I can read parameters (properties) of entities like strength and health it could work the same I guess.
I mark a property (variable) in the script to be exposed and when I open the properties of the entity it would go and display them for me in the properties panel. Then I can set the value for the exposed properties just like any stock property like ammo, health, life..etc and then in-game Lua would go and read the value from the properties of the entity when executed...

Or could make more sense If the properties would be not exposed from the actual Lua script but set in the properties panel of the entity like a custom property and we just make the script to expect the entity has that property with that name and read it just like any property....

Also would like to know what others think about this, I don't want to post anything on GitHub that doesn't makes sense.

Something like this you mean? https://forum.game-guru.com/thread/219317#msg2595755

@AmenMoses
Yes exactly. Select the script then set properties right from the GUI as you described so instead of having 10 different scripts does the same thing only with different values we can have only one and set values in the GUI.
Glad to see that Lee replied saying the functionality to support this is already there and he planned to replace the current entity properties panel with something more dynamic anyway,..... So did this plan moved forward since February?

Nope.

You can clone the repository form GitHub and add it yourself though if you want. I'll happily do the Lua interface parts of it.

Unfortunately I don't know C++ so I prefer using the official build rather than using a custom. But thanks for the offer.
I was about to post this on GitHub but then I saw tons of topics flagged as bug since February, probably it will be not a priority for some time.

I do this with integers and strings all the time in my scripts

If you can convert your stuff into simple data types like strings or integers, you can do this:
Set the name and separate the values with ","


If this is what you want, I could look into the source and maybe I can add another GUI field like "LUA PARAM" and give it to a script, so you not need to change the name.

If you want complex data types or gui elements like vectors, sliders, lists or an explorer window(to choose images or sounds), I am the wrong man for this. I am not that deep into c++ that I can do it.

Ok, I sat down and tried to get a properties line into a script
and here is the result:
I have now a property "LUA PARAM" which I can fill with values seperated by commas

and can get them with:
GetLuaParameterString(e)

the hole script:

Maybe there is a better way and the lua need some optimizing, but it works now.

wow that would be extremely helpful.

Currently i just rely on using the string of the entities given name and reading from that to detect a custom string/variable in the properties.

@Corno_1
Yes, it is something could be useful with my light switch script so I could pass the ID of each light from the properties panel to the script.
But would Lee agree to put this in to a public release?
If he agree, would it be difficult to say add 4 input fields for Lua?

Lua parameters
-Param 1
-Param 2
-Param 3
-Param 4

Just above the General parameters in case if someone need more than 1 input field. I would imagine if Lee agree to release this to the public I would think it would be considered a long term solution so I'm only thinking long term. Who knows when someone going to offer to do this if we need one more parameter field in the future

But in case adding 4 is too much trouble, even 1 dedicated to Lua would be nice too.

Thanks a lot

Or just implement my original suggestion?

i.e. have the script designate via a special header format what the parameters are and have the editor build the gui from it.

Mind you since using the name is so easy and flexible (see GraPhiX explosions thread) this is more of a polishing the Henry rather than an essential enhancement.

Yeah, but personally I like that if something is dedicated for certain things rather than working around staff. I don't personally like work arounds because it is only introduce more problems that also need work around later and working around staff never ends. Some parameter fields dedicated for Lua would at least make the workflow more polished and organized

But yeah would be nice to have it dynamic either expose them from script and generate them by reading the script or have a button on the properties panel to add any number of custom fields we need with a custom name too. But I'm sure Lee doesn't have the time to care about anything like this. The GitHub community page is filled with bug reports, to be honest I find it insane how can someone implement so many bugs Maybe with "work arounds" I guess

Anyway, I'm more than happy if Corno_1 could implement some parameter fields for Lua

When you take something thrown together over a long period of time, with constant changes to the parts it is made up from (for example GG is on at least its 3rd physics engine), which has recently been the subject of a huge rewrite (DX9 to DX11), you are going to get lots of bugs. Also a lot of the 'bugs' that people report are simply things that don't work the way they expect it to or as well as they would like it to, these sorts of things aren't really technically 'bugs' and 'fixing' them can lead to a torrent of complaints from other people when the engine suddenly starts behaving differently when they were quite happy with the way it worked before.

I do not think so, because it is a feelgood workaround for a workaround

The best thing is to create a standardized header which the engine can read and then create a kind of property window, where you can set your values. But of course this is a big task and after there is a really good workaround that will work in the future too(I do not think Lee will change the name property), other stuff is more important.