S/R Question, Problems, Suggestion/Request

[SneaksieDave]

That title should about cover it.

 

I haven't used S/R much before now (I've been really quite afraid of it, I admit! (in a good way)), but I used the no frob zone development in progress as an excuse to give it a go. I've got a chest set up with goodies inside, which uses a no frob zone (at this time it seems to be working well) - http://208.49.149.118/thedarkmod/temp/srtest.rar

 

To be absolutely sure I couldn't frob the goodies out with the lid closed, I wanted to frob like a maniac. Of course, I can't do this, because the lid is rather easy to get in the way. So I wanted to make a button which disables the frobability of the lid (yes, there's an easier way to test this: just make the lid non frobable and use a button to open/close the chest - that works fine. But that's now irrelevant to what I'm asking here).

 

So I held my breath, closed my eyes, and jumped into the world of S/R. One thing I tried works great: turning a regular button into a S/R button. I made a button, gave it a Frob response of Trigger on the chest_lid. And just like that it works, this isn't so hard afterall.

 

But the next thing, I just cannot get to work.

 

1. problem: New button, with a Frob Response of Set Spawnarg of frobable to 0 (note that I also tried it with quotes, but that appeared to break the button) on chest_lid. I don't know if I'm interpreting something wrong, or there's possibly a bug, but this doesn't seem to work. Everything is spelled correctly, the targets are set up the same as the previous button, which works fine. I became concerned - can spawnargs only be set at time of spawn? To not have the very powerful ability of changing keypairs on ents with S/R would be most unfortunate.

 

Beyond that, I aimed to set up a third button, with which to actually toggle the frobable value on the lid on and off. I assumed this would work, provided I could get button#2 to work. However, it currently doesn't seem possible:

 

2. suggestion/request: A way to deactivate and reactivate stims and responses on an object (including self) by index, rather than type, because more than one instance of a given type can exist.

 

With the new, third button, I built a Frob Response of Set Spawnarg of frobable to 0 on chest_lid (as before). I then duplicated that response, and modified the new version to set frobable to 1. I then tried to employ two more Response Effects (on each Response) to toggle the activity of both of the Frob responses.

 

To illustrate:

-Frob 1 fires, which disables frobability of the lid. Its second and third Response Effects then disable itself, after enabling Frob 2 (initially disabled).

-Next time, Frob 2 fires, which enables frobability of the lid. Its second and third Response Effects then disable itself, after enabling Frob 1.

 

So basically, a simple internal toggle within the functionality of the S/R button. The problem is I couldn't find any way to distinguish Frob 1 from Frob 2, in the Activate and Deactivate Response Effects. The only option is to choose them by type (e.g., Frob), and not by index number (1 = Frob, 2 also = Frob). If it's possible, this would be a powerful addition.

 

3. problem: a possible issue I just noticed in preparing this post. The user is apparently not shown internal indexes. For example, I just set up an Activate Response for Frob (shown as #1 in the UI list to the user) and the S/R editor shows, "Activate the response with ID 0..."

 

Not a big problem, but if the user reads "1" while internally it's actually "0", it will likely cause some confusion for users. If it cannot (or should not) be forced to use 1 as the base, then I don't think there's any problem with showing the user lists starting with 0.

 

4. problem: Finally, I then changed the values by hand (I believe I got them right; activate 1, deactivate 0... activate 0, deactivate 1). When I then tried to open the entity in the S/R editor again, DR crashed. So for now, all activate/deactivate Response Effects in the map linked above point only to entry 0 (1 on the display, a Frob).

 

I cannot confirm whether or not the by-hand editing actually works in TDM (beyond the DR crash) because of the functional problems in #1 and #2. Defect entries will be created if you want 'em.

[greebo]

1. problem: New button, with a Frob Response of Set Spawnarg of frobable to 0 (note that I also tried it with quotes, but that appeared to break the button) on chest_lid. I don't know if I'm interpreting something wrong, or there's possibly a bug, but this doesn't seem to work. Everything is spelled correctly, the targets are set up the same as the previous button, which works fine. I became concerned - can spawnargs only be set at time of spawn? To not have the very powerful ability of changing keypairs on ents with S/R would be most unfortunate.

Spawnargs are usually parsed by the SDK code at spawn time, hence the name. Sometimes, the code reads the spawnargs later during runtime too, but this is not usual and can't be relied upon.

 

2. suggestion/request: A way to deactivate and reactivate stims and responses on an object (including self) by index, rather than type, because more than one instance of a given type can exist.

So I take it you set up multiple responses to STIM_FROB and want to deactivate one of them? This should be done by a response_effect I guess?

 

That's a feature request to go on the bugtracker then, please. This has to be updated in the S/R Editor as well as in the Mod code.

 

With the new, third button, I built a Frob Response of Set Spawnarg of frobable to 0 on chest_lid (as before). I then duplicated that response, and modified the new version to set frobable to 1. I then tried to employ two more Response Effects (one on each Response) to toggle the activity of both of the Frob responses.

I guess what you need is a response_effect toggling the frobability. I can add such an effect fairly easily => bugtracker (The Dark Mod).

 

3. problem: a possible issue I just noticed in preparing this post. The user is apparently not shown internal indexes. For example, I just set up an Activate Response for Frob (shown as #1 in the UI list to the user) and the S/R editor shows, "Activate the response with ID 0..."

I seem to recall discussing us whether the S/R IDs should be shown to the user (in the first S/R Editor incarnation, they were there), and for some reason we decided to remove them. At any rate, I don't think that Stims or Responses can have ID 0, so I guess the list should be canged to start with index 1.

 

4. problem: Finally, I then changed the values by hand (I believe I got them right; activate 1, deactivate 0... activate 0, deactivate 1). When I then tried to open the entity in the S/R editor again, DR crashed. So for now, all activate/deactivate Response Effects in the map linked above point only to entry 0 (1 on the display, a Frob).

Can you reproduce that crash and send me the map? Even if the settings were incorrect, DarkRadiant has to handle that and should not crash.

[SneaksieDave]

Spawnargs are usually parsed by the SDK code at spawn time, hence the name. Sometimes, the code reads the spawnargs later during runtime too, but this is not usual and can't be relied upon.

Oh my. I have misunderstood this all this time then. I thought we'd be able to use S/R to change keypairs. I'm confused though... if a script can do it, what's the difference, why cannot S/R? Is there any option?

 

That's a feature request to go on the bugtracker then, please. This has to be updated in the S/R Editor as well as in the Mod code.

I guess what you need is a response_effect toggling the frobability. I can add such an effect fairly easily => bugtracker (The Dark Mod).

At any rate, I don't think that Stims or Responses can have ID 0, so I guess the list should be canged to start with index 1.

Okay I'll set up entries for these.

 

Can you reproduce that crash and send me the map? Even if the settings were incorrect, DarkRadiant has to handle that and should not crash.

I'll give it a shot; should work. In fact I'll do that first...

 

 

Edit: It's not so reproducable as I expected. So far I'm not getting a crash, so maybe it was a combination of all of the other things I was trying, too (deleting and adding entries, changing types). I'll try to find it more after making the entries above, and will speak up if I manage to get it again.

[greebo]

Oh my. I have misunderstood this all this time then. I thought we'd be able to use S/R to change keypairs. I'm confused though... if a script can do it, what's the difference, why cannot S/R? Is there any option?

Scripts can do it because there have been scriptEvents installed to change certain properties. The scriptEvents change the actual internal "isFrobable" variable, not the spawnarg, that's why they work during runtime too.

 

Anyway, I can set up a response effect effect_set_frobable with minor effort, as stated above.

[SneaksieDave]

Ah, I see. Well, there's always scripts then. Good to know we can get special case ones though.

 

Note my edit above, so far the crash is not reproduced.

[Fidcal]

As Dave says, the ability to change properties in game would be very powerful. If it can be done in the code "fairly easily" on a one-by-one basis I too am puzzled why a general response can't be set up with three arguments : entity ID, key, val. Is that possible? At the moment we have a handful of different ones for special tasks, change a light colour, change an AI team, now change frobable. If one response could be provided to set any key value on an entity it would be really useful.

 

Failing which, a template script for those of us ignorant of how to do this would be very useful. It would be inferior to using s & r though imo.

[SneaksieDave]

More questions (though I have the feeling they are documented around here, and I just haven't found them - not on wiki apparently):

 

What is Response Effect:

- (Disable, Enable, Toggle) Effect? Not a particle, not a stim, not a response...

- (Start, Stop) Stim Timer? It seems obvious what it is, but there is no timer value to set, so perhaps I understand wrong.

 

And another possible suggestion/request:

Response Effect to remove the target relationship of an entity. I'm not sure if this can maybe already be done, or how necessary it might be, but I was thinking of it in terms of the trigger_on_open setting for doors. As is, a door will just keep triggering each time it's opened. In many cases, that's not desirable. With this Response Effect, a door could trigger an item once (although it is a multiply-triggerable effect, e.g., a thunder and lightning effect) and then remove its target key so that it never triggers that target again, although other things can continue to trigger the target (e.g., a different door, or a special moment in the map, etc). Thoughts? Maybe this could be done with SetSpawnarg, I don't know.

[greebo]

As Dave says, the ability to change properties in game would be very powerful. If it can be done in the code "fairly easily" on a one-by-one basis I too am puzzled why a general response can't be set up with three arguments : entity ID, key, val. Is that possible? At the moment we have a handful of different ones for special tasks, change a light colour, change an AI team, now change frobable. If one response could be provided to set any key value on an entity it would be really useful.

The important thing is that the spawnargs are NOT the actual properties, they are just the startup values for the actual properties. They are spawnargs meant to be parsed once at spawn time. The actual variables cannot be looked up by name (like in PHP or other script languages). Sometimes the C++ variables in the SDK code aren't even named like the spawnargs they are parsed from. Also, parsing the values from string constants is awfully slow, that's why they should be parsed only once.

 

Failing which, a template script for those of us ignorant of how to do this would be very useful. It would be inferior to using s & r though imo.

I know that I can't persuade the majority of mappers, but there is no reason to be afraid of scripting. Of course, setting up Stims/Responses is easy by clicking around in the editor, but learning to do some D3 scripting is in my opinion quite easy. Maybe it's just me being used to reading code, but I wanted to mention it that there is no reason to say "My goodness, it's code, I can't do it then."

 

What is Response Effect:

- (Disable, Enable, Toggle) Effect? Not a particle, not a stim, not a response...

You mean Disable Effect, Enable Effect and Toggle Effect? These are for switching of certain response effects of the target entity. I used this to let the belcher walk in test/stimresponse.map with two response effects being switched on alternately. Not very intuitive to setup, I admit, but they work.

 

- (Start, Stop) Stim Timer? It seems obvious what it is, but there is no timer value to set, so perhaps I understand wrong.

Stims can be timed to fire off after a certain time span. To start/stop the timer, these effects can be used.

 

And another possible suggestion/request:

Response Effect to remove the target relationship of an entity. I'm not sure if this can maybe already be done, or how necessary it might be, but I was thinking of it in terms of the trigger_on_open setting for doors. As is, a door will just keep triggering each time it's opened. In many cases, that's not desirable. With this Response Effect, a door could trigger an item once (although it is a multiply-triggerable effect, e.g., a thunder and lightning effect) and then remove its target key so that it never triggers that target again, although other things can continue to trigger the target (e.g., a different door, or a special moment in the map, etc). Thoughts? Maybe this could be done with SetSpawnarg, I don't know.

It wouldn't work with setSpawnArg, I'm not sure there is a script function for removing targets from entities either. But it's definitely do-able. A scriptEvent is necessary to expose the functionality to scripts, and then it's just a trivial addition of a response effect.

[Tels]

The important thing is that the spawnargs are NOT the actual properties, they are just the startup values for the actual properties. They are spawnargs meant to be parsed once at spawn time. The actual variables cannot be looked up by name (like in PHP or other script languages). Sometimes the C++ variables in the SDK code aren't even named like the spawnargs they are parsed from. Also, parsing the values from string constants is awfully slow, that's why they should be parsed only once.

I know that I can't persuade the majority of mappers, but there is no reason to be afraid of scripting. Of course, setting up Stims/Responses is easy by clicking around in the editor, but learning to do some D3 scripting is in my opinion quite easy. Maybe it's just me being used to reading code, but I wanted to mention it that there is no reason to say "My goodness, it's code, I can't do it then."

 

A couple of points:

 

* parsing stuff from strings isn't that slow, and it doesn't matter if it happens only 1 or 5 times for a certain effect during playing a map

* most people are not coders like you and me, and they will have really difficulties writing scripts. I know this is hard to understand but they will rather click around one day in the editor than to learn for one hour how to write a script.

* I don't quite understand the difference between spawnargs' names and C++ variables - or at least I do think most people won't understand them, and most important, won't know them! This means (if I understand correctly), not only do you need to learn how to write scripts, but you also need to learn that you need to set variable FooBar to alter the spawnarg BooBaz? That would make it even harder, even for coders

 

Would it be possible to have some sort of script generator that can generate simple scripts for stuff like "set the spawnarg XYZ to ABC when triggered"?

[greebo]

* parsing stuff from strings isn't that slow, and it doesn't matter if it happens only 1 or 5 times for a certain effect during playing a map

I'm not talking about 1 to 5 times, I'm talking about performing lexical casts each frame for hundreds of values. Look at all these member variables in the "thinking" entities - parsing all these from strings each frame again would surely be a performance drain.

 

Would it be possible to have some sort of script generator that can generate simple scripts for stuff like "set the spawnarg XYZ to ABC when triggered"?

As mentioned before, setting the spawnarg usually won't do anything. Once the player is spawned, you can set the spawnarg "health" to "10000000", still the player won't get more health points. The train has left at this time.

 

Such a script would only help in the cases where the spawnarg is parsed later than during spawn time.

[Tels]

I'm not talking about 1 to 5 times, I'm talking about performing lexical casts each frame for hundreds of values. Look at all these member variables in the "thinking" entities - parsing all these from strings each frame again would surely be a performance drain.

 

I wasn't talking about every variable every frame - only whatever the mapper wants to change at runtime via trigger, S/R or script.

 

As mentioned before, setting the spawnarg usually won't do anything. Once the player is spawned, you can set the spawnarg "health" to "10000000", still the player won't get more health points. The train has left at this time.

 

Such a script would only help in the cases where the spawnarg is parsed later than during spawn time.

 

Uhm, so how do you set it at runtime, then? And why is setting it at runtime different from setting it at start? This doesn't make much sense and complicates stuff quite a bit..

[greebo]

Uhm, so how do you set it at runtime, then? And why is setting it at runtime different from setting it at start? This doesn't make much sense and complicates stuff quite a bit..

For example, the AI health spawnarg is converted once in idEntity::Spawn() by calling health = spawnArgs.GetInt("health").

 

Once the health value is stored in the member variable int idEntity::health the value can be changed by either calling a scriptEvent or the according class method idAI::Event_SetHealth().

[Tels]

For example, the AI health spawnarg is converted once in idEntity::Spawn() by calling health = spawnArgs.GetInt("health").

 

Once the health value is stored in the member variable int idEntity::health the value can be changed by either calling a scriptEvent or the according class method idAI::Event_SetHealth().

 

Sorry if I am a bit dense, I havent made it yet so far as to write scripts etc So, does this "changed by calling a scriptEvent" mean you need then to know that the health spawn arg is called "health" afterwards - in this case they match, but if I understand you correctly, this isnt nec. the case?

[Crispy]

The name of the variable "health" is completely separate from the name of the spawnarg "health".

 

Let's try an example. Just suppose for a moment that the spawnarg was called "initialHealth". On spawn, the idEntity::health member variable is set to the value of the initialHealth spawnarg:

 

health = spawnArgs.GetInt("initialHealth");

 

Later on, the entity is damaged, so it loses 10 health.

 

health = health - 10

 

The value of the initialHealth spawnarg has not changed, but the value of the health variable has changed.

 

Some time later, a S/R response fires and sets the initialHealth spawnarg to 42. This has no effect on the value of the health member variable. The value of the initialHealth spawnarg has changed, but the value of the health variable has not changed.

 

As you can see, beyond the initial assignment the two values are completely decoupled. Coupling them would pose a number of technical issues, and to do this for every single spawnarg in the entire game would be a mammoth effort. It's a lot easier just to set up specific S/R responses and scriptEvents on a case-by-case basis.

[SneaksieDave]

Sure, but I think what they're getting at (beyond my initial misunderstanding about the spawnargs) is, why can't there be this type of functionality:

 

Object S/R ("decrease target health by 20") -> my target (realtime ID) -> "currenthealth" -= 20

or

Object S/R ("disable target1 of target") -> my target (realtime ID) -> "target1" = ""

 

I think there's some misunderstanding between sides, maybe. We now realize the S/R Response Effect 'Set Spawnarg' can't do it, and why. But what about a new S/R Response Effect of 'Set Property'? Is that possible?

 

If an imp is shot, its health goes down; no one else's does. That imp has a real ID in the game. If he is also something's target, that's another identification link; pressing a button for instance could make him vanish. If the game knows the imp to reduce his health, or the button (which can have S/R) also knows the imp (by some ID or name or whatever) in order to make him vanish, why cannot that ID be used by S/R to affect his realtime properties?

 

Let me emphasize I'm not trying to push the issue, and realize I could be way off here; I'm just trying to help clarify the question.

[New Horizon]

Did Thief 1/2 SR have this type of functionality Sneaksie? I never played around with it enough to know.

[Gildoran]

I know that I can't persuade the majority of mappers, but there is no reason to be afraid of scripting. Of course, setting up Stims/Responses is easy by clicking around in the editor, but learning to do some D3 scripting is in my opinion quite easy. Maybe it's just me being used to reading code, but I wanted to mention it that there is no reason to say "My goodness, it's code, I can't do it then."

I completely agree with Greebo. I am a huge proponent of D3 scripting. Ever since mapping for Doom 2, I've always wished for some kind of scripting system for 3D games. I've had to suffer through limitations of early trigger systems, and had to rely on Rube Goldberg contraptions in later trigger and S/R systems (eg, emulating logic circuitry using HL1 trigger relays). In comparison, D3 scripting is simple and elegant. It may not be as powerful as Unreal scripting, but it's still quite useful and easy, and is great for the vast majority of D3 applications.

 

I sometimes feel like we're following trying to make S/R too versatile and use it for too many applications. I keep on hearing people say "Look at how useful S/R was in Thief! We should try to emulate that!" What they keep on forgetting is that the reason mappers had to rely on S/R so much to accomplish effects in Thief was because it didn't have a proper scripting system (I'm under the impression that its "scripts" were really DLLs - like the SDK).

[SneaksieDave]

Did Thief 1/2 SR have this type of functionality Sneaksie? I never played around with it enough to know.

Not sure, I don't have much experience with it either.

 

On the topic of scripting, it is of course immensely powerful. But we've got to keep in mind there is a very large portion of mappers that are not and will not ever be comfortable (or skilled) with scripting, regardless of the skills or comforts of any of us. So, we try to make tools which help.

[New Horizon]

I appreciate the endorsement of scripting, but I'm just not a scripting kind of person...so I tend to hear alarm bells go off when the S/R system is diminished in its importance. My brain just isn't wired for coding. I've tried, and tried again to no avail. For those who can use scripting effectively, it will be an asset, an ally. For the rest of us, it will be a pain in the ass. You have to remember that not all brains are wired the same. I'm much more visual. I need to be able to see things laid out visually, and can't really understand the way things work out in code. That's actually one of the things I loved about T3Ed...as much of a lemon as it was, it actually had some very useful tools and was relatively easy to understand. Scripting isn't going anywhere, and it's a wonderful option, but we have to make the editor with mappers in mind too, not just coders.

 

If the S/R system can be made even more robust, that's great! It will make a great companion/alternative to scripting.

[Crispy]

Sure, but I think what they're getting at (beyond my initial misunderstanding about the spawnargs) is, why can't there be this type of functionality:

 

Object S/R ("decrease target health by 20") -> my target (realtime ID) -> "currenthealth" -= 20

or

Object S/R ("disable target1 of target") -> my target (realtime ID) -> "target1" = ""

 

I think there's some misunderstanding between sides, maybe. We now realize the S/R Response Effect 'Set Spawnarg' can't do it, and why. But what about a new S/R Response Effect of 'Set Property'? Is that possible?

 

If an imp is shot, its health goes down; no one else's does. That imp has a real ID in the game. If he is also something's target, that's another identification link; pressing a button for instance could make him vanish. If the game knows the imp to reduce his health, or the button (which can have S/R) also knows the imp (by some ID or name or whatever) in order to make him vanish, why cannot that ID be used by S/R to affect his realtime properties?

 

Let me emphasize I'm not trying to push the issue, and realize I could be way off here; I'm just trying to help clarify the question.

You can certainly have a S/R Response Effect that reduces health, specifically. In fact I there probably already is one. What you can't have (at least, not without way too much effort on the coding side) is a generic "Set Property" S/R Response Effect that automagically works for every single value that's ever set by a spawnarg, since the code has no notion of what a "property" is. Teaching it that notion would entail more effort than it's worth; instead, it's easier to write specific S/R Response Effects for each specific value that you might want to change.

[Fidcal]

I come to this thread late. Most of what I wanted to say as I read it through has already been said so I am mainly agreeing with others.

 

I am not afraid of scripting myself. I have a qualification in 'C' and have already looked at scripting. What I AM afraid of the amount of time I know that I shall have to waste scraping together the fragmented information from around the internet to make it effective with Dark Mod (have already wasted a morning just to print 'hello world' in the console). In the future I expect to learn scripting but I can't spare the time now. When I have a month or so to learn the basics then, as ever, I shall probably write a tutorial so others can learn in 30 minutes what took me a month.

 

Even then, scripting will not be easy, even impossible, for many. Everyone has different talents and abilities.

 

Yes, I can confirm absolutely that T2 could change properties using s & r. No problem. I used it routinely. It had a complete list of code variable names equivalents to all the spawnargs.

 

Like others here, I am puzzled why we can change individual properties with ease (change team, colour, etc) but not any general purpose one. What happens in the response function if I change the team of an AI? I presume the function needs only know the team variable in the code and change it. Is it really just a matter of knowing a variable name? So why not a stim response that has a look up table of all spawnarg names (or at least a huge list of all the common ones) and their code equivalents? This list does not need to be in the map or game but only in Dark Radiant. The user select 'set property' response and selects a spawnarg from a list. DR finds the equivalent code variable to change. How is that done in the one off responses like 'change team'? I assume some game function has been created to which the response function passes a team number argument. The function simply changes the team variable. Why not a general purpose function to which is passed both variable name and value? It does not have to literally be the variable name of course but an index value to point to it or to a mini function that sets that variable and returns. There must be some simple way to do this. Otherwise we shall keep having requests for a response that sets this and another that sets that and still finish up with 50 response effects where one would do.

 

One last question: What is the purpose of the set spawnarg response if it doesn't have any effect?

[Crispy]

We discussed that at one point. It's certainly possible, but it would entail a fair amount of work to set up the mappings.

 

One last question: What is the purpose of the set spawnarg response if it doesn't have any effect?

There is the occasional spawnarg which is read on-demand rather than at spawn time.

[Tels]

As you can see, beyond the initial assignment the two values are completely decoupled. Coupling them would pose a number of technical issues, and to do this for every single spawnarg in the entire game would be a mammoth effort. It's a lot easier just to set up specific S/R responses and scriptEvents on a case-by-case basis.

 

So a bad design decision at the start (making the variables decoupled) is now worked around by "adding stuff on a case by case basis" because doing it proper is "too much work". Great

[Tels]

I sometimes feel like we're following trying to make S/R too versatile and use it for too many applications. I keep on hearing people say "Look at how useful S/R was in Thief! We should try to emulate that!" What they keep on forgetting is that the reason mappers had to rely on S/R so much to accomplish effects in Thief was because it didn't have a proper scripting system (I'm under the impression that its "scripts" were really DLLs - like the SDK).

 

While I am a big fan of scripts and their power, I am also a big fan of "KISS". You shouldn't need to learn and write scripts just to change a property value at run-time.

 

"Normal" people (e.g. not people like greebo who have 50h per week to spent on TDM) already struggle with just learning mapping, remember what works how, wha models and entities are available and what the spawnargs are.

 

And quite a lot of time they want to use something they have to look it up again. So when it is already hard to learn a lot of spawnargs, I think it is quite undesirable that people learn a scripting language and another, second, decoupled set of variable names just to create some simple trigger chains or events.

 

Weather to do it "right" and make it easier for mappers, or do it "easy" and make the mappers do all the (learning/remembering) work is a fundamental design decision - and this decision shouldn't done by programmers - as these tend to give answer like "oh just write a script"

[greebo]

So a bad design decision at the start (making the variables decoupled) is now worked around by "adding stuff on a case by case basis" because doing it proper is "too much work". Great

Beware that we're in the middle of year three in development and we didn't exactly write the D3 codebase from scratch. If it was known from the start that ALL class member variables need to be accessible by a "string => variable" lookup it would be a different thing, but that's how the situation is.

 

That being said, I believe it makes perfect sense from the game engine's view that variables are not indexed by a string, primarily because of performance restrictions (and Saving and Loading comes into mind), plus it would be tiresome to use in the SDK.

 

Make a grep in the SDK codebase to find out how often "health" is being used in the code (I think it's about one hundred occurences). Now imagine a lookup some kind of string-mapped storage container each time the variable health is queried. And that's just one variable. There are hundreds of them being used mutliple times per frame.

 

Even if performance issues were to be neglected, my personal opinion is that the amount of work getting such a property system "just" to make S/R more powerful is not justified at this point. Maybe this will be addressed later on, after TDM 1.0 release.

 

Yes, having to meet release dates sucks, but there's no way around that. [Rant over.]