Scripts / "Entity name variable passer parser". Seriously... :)

Author
Message
!nullptr
Forum Support
9
Years of Service
User Offline
Joined: 27th Mar 2015
Location: Australia
Posted: 19th May 2015 05:14 Edited at: 19th May 2015 05:22
In a recent Steam thread, Lee hinted at using the entity name property to pass a variable list for use in GG so I set about making something up to test it out.

In short, this code is a framework for passing a var list via entity name and is parsed to break it into multiple varName's and varValue's so you can use it in code. Examples for use might be tree shade and height etc., weight of objects... personal name of entities... etc. You name it.

EG: A barrel that has a weight of 200kg and a strength of 50 might be named "b1 w200 s50". This parser will seperate the "variable list" into

b1
w200
s50

and subsequently broken further into

varName= "b" varValue ="1"
varName= "w" varValue="200"
varName="s" varValue="50"

From this you can write a simple function or if statement etc. to determine what you want to do.

eg:
if varName == "b" then
doBarrelCode(varNum)
end

This type of hack has been on my list for a long time and although I had a rough entity grabbing script previously I wasn't happy with performance so I rewrote a version making better use of LUA string functions and I think I have a done it the fastest and most efficient way possible. (always happy to be corrected)


NOTES
1) This parser does follow a reasonable naming convention (the options are infinite right?) but I tested it with both one and many "options" and values.
2) This is a coders piece of script to be torn apart and utilised, not a PnP script for non-coders sorry.

Development/ Gaming Rigs
Sys 1: i7-4770 (3.5)/16Gb/128 SSD/3Tb/970gtx/2 x 23, 1 x 27 LCD - Sys 2: i7/8Gb/670gtx/1.5Tb/1 x 23 LCD - Sys 3: Amd Quad/8Gb/645gtx/1Tb/30" LCD

Attachments

Login to view attachments
PM
J_C
16
Years of Service
User Offline
Joined: 9th Nov 2007
Location:
Posted: 19th May 2015 09:57
SisterMatic nice piece of code...

I saw the same post by Lee and I also started to write the same thing...

In mine I setup up the variable holders first...

local object_data = {}
local myVar1[e] = {}
local myVar2[e] = {}
etc..

then in the init_name function
object_data[e] = name
myVar1[e] = nil
myVar2[e] = 0
-- reset the rest to 0 - as 0 means no effect...
etc..

then in main function

if myVar1[e] == nil then
-- get the user variable out of object data
split_object_data(e)
else
-- use the user variables
do_main_code(e)
end

So I only split the variables out once at the start.. I did not use the variable name part as you do
just -- objetctName 10 20 30
so MyVar1[e] = objectName, myVar2[e] = 10, myVar3[e] = 20 , myVar4[e] = 30

Yes this type of code is going to be very useful...
PM
3com
9
Years of Service
User Offline
Joined: 18th May 2014
Location: Catalonia
Posted: 19th May 2015 10:27
Some relevant values of an entity are reflected in the properties panel.
Therefore, these values ??must be stored in an array probably.
I am not a fan of using these values, since these values ??may change, instead prefer to work with a variable that access that array.
Example with a barrel. In its property panel you have values ??like:

Name: Barrel
Static: Yes
IsImobile: Yes
Physics: On
etc.
Therefore the engine should have those values stored in an array such as: EntityValues = {name, static, IsInmobile, Physics, etc} -

So if I write something like: g_entity (e) {"name"} = GetEntityName (e)
I should get the name of the entity, can even pass this value to a variable, and work with this variable, something like: Ename = g_entity (e) {"name"}.

If Ename == barrel Then
do something
Else
Do nothing or something else
end

So, never may if any of Those values ??change further.

I guess TGC firts plane work with ids intead of names, Because various entities can share the same name, so you can Work With them like one array.

I thought TGC can continue working with, so if engine Then look entities sharing the same name, Those entities working as an array, so if you change something in one of them, so the change will be reflected in the other ones, sharing the same name.
Otherwise, the change only affect single entity, these being referenciate (e).

The same for the other entity values.

This way you can change any value via properties panel, without affecting your script.

Anyway more commands would be pretty nice, something like:

Kill_Entity(e) -- so you don't have to care of entity health.
IsDeath(e) -- ditto

3com
Laptop: Lenovo - Intel(R) Celeron(R) CPU 1005M @ 1.90GHz

OS: Windows 8.1 (64) - Ram: 4 gb - Hd: 283 gb - Video card: Intel(R) HD Graphics

PM
!nullptr
Forum Support
9
Years of Service
User Offline
Joined: 27th Mar 2015
Location: Australia
Posted: 19th May 2015 22:17 Edited at: 19th May 2015 22:21
@J_C
The original was written purely to demonstrate the principle of the actual parsing rather than the functionality. It's certainly not production code

But yes, during init or in RT works just as well. EG: I have 2 different ways running this, 1 is a persistent array construct formed at init (a new tree shade script) but another works more efficiently for "disposable entities", it's an "on-the-fly" parser. (I rarely use a global array unless I want to store a value and carry it around).

As an aside, another thing I've already done is added another delimiter so I can parse string values such as "red" or "dented" (in the case of barrels). The code above uses numeric values only. Ultimately the choices are pretty well infinite and limited only to maximum string length. (Anyone know what that is?)

@3Com
Quote: "I thought TGC can continue working with, so if engine Then look entities sharing the same name, Those entities working as an array, so if you change something in one of them, so the change will be reflected in the other ones, sharing the same name.
Otherwise, the change only affect single entity, these being referenciate (e)."

Using something like an RT parser does this. In fact it's more functional because you can address all entities called "barrel" in addition to saying whether the individual barrel is "empty" or "full", "red" or "blue" and it does not matter if the entity number changes during development.

On the barrels I could use "b1 h20 s7" or "b2 r9 x52" - same script, they're both "barrels" but have different values which I may/may not use.

Agreed if we had id's in properties it would be nice but it would be limited to the number of fields offered unless we are given the ability to add id fields (which would be *very* nice!).

This method is akin to the old "modem strings" we used many years back where the entire string was parsed to set the modem values. The individual coder sets his own naming conventions for the "entity string" and simply parses to strip the vars and values.

tbh, even if I was given additional id's I'd probably still use an RT parsing method because it's a one location edit (in properties) and can be limited to one script for *every* entity
Development/ Gaming Rigs
Sys 1: i7-4770 (3.5)/16Gb/128 SSD/3Tb/970gtx/2 x 23, 1 x 27 LCD - Sys 2: i7/8Gb/670gtx/1.5Tb/1 x 23 LCD - Sys 3: Amd Quad/8Gb/645gtx/1Tb/30" LCD
PM
3com
9
Years of Service
User Offline
Joined: 18th May 2014
Location: Catalonia
Posted: 19th May 2015 23:19
Even some RegeX can do that.
In fact I use it to carry weapons and anmo thru ie: level1 to level2.

3com
Laptop: Lenovo - Intel(R) Celeron(R) CPU 1005M @ 1.90GHz

OS: Windows 8.1 (64) - Ram: 4 gb - Hd: 283 gb - Video card: Intel(R) HD Graphics

PM

Login to post a reply

Server time is: 2024-05-04 14:37:21
Your offset time is: 2024-05-04 14:37:21