Jump to content
The Dark Mod Forums
Sign in to follow this  
greebo

Stim/response Editor

Recommended Posts

I'd like to get started with the Stim/Response editor in the next few days.

 

From fiddling around with stim/response stuff back in September when setting up the fire-secret in the Bonehoard, I know a thing or two about it, but I'm not an expert on this area. I will certainly play around a bit with the existing system and come up with some designs before I actually start coding.

 

Before I dash ahead and start planning the actual GUI I would also like to post in The Editor's Guild on TTLG and interview a few Dromeders about common Stim/Response tasks, as I haven't any Dromed experience myself.

 

Would that be ok for the team or would you rather leave the planning within these forums?

Share this post


Link to post
Share on other sites

Sounds OK to me. S&R is not really finsihed though. Currently we only have radius stims, but the plan is to also allow for different kind of stims.


Gerhard

Share this post


Link to post
Share on other sites

I have some dromed experience, so I'll try to give some feedback and suggestions as well, while you work on that.

 

BTW:it's one of the core features for our DR, isn't it? I'm impressed by your pace of work, Greebo!

Share this post


Link to post
Share on other sites

I notice that the fledgling S/R editor is presented as an inspector (instant apply, no buttons) while the fledgling Objectives editor is a dialog (explicit apply, OK/Cancel buttons). Do you think the inspector GUI is more appropriate for these? I tend to lean towards a dialog because these are not settings which affect rendering (where immediate feedback is desirable), and there is a possibility of entering an inconsistent state if certain keys are added before others, which might necessitate an explicit Apply with consistency check.

Share this post


Link to post
Share on other sites

You're right, these are valid points. So far I'm setting up the entity key analysis to load existing stims from the entity class hierarchy, so nothing is settled so far.

 

The current window can be turned into an explicit-apply dialog with a few minor tweaks, so I've no problem with doing it that way. :) I'll remove the shortcut propagation to the main window, disable the toggling method and add the Apply button.

Share this post


Link to post
Share on other sites

Where can I find informations of what actually can be done with our S/R system? Knowing this I could suggest some layout for dialog windows.

The things I want to know is the way source objects can generate the stim and the effects they can cause. I suppose these are not identical to Dromed system, are they?

Share this post


Link to post
Share on other sites
There's this on the Wiki:

I found it already - I always do that - first ask and then immadiately start looking for an answer on my own... In other words - my question is kind of STIM_SEARCH send by myself to myself ;)

 

Few thoughts after getting through this article(s):

- I was getting confused at first by the naming conventions. Stim and Response seem to be names for entities, while in Dromed you had respectively Source and Receptron. Stim was the type of information sent and received between them.

- our system lacks intensity value, which is very important. F.e. Water arrow and bucket of water could both have STIM_WATER but using water arrow you wouldn't be able to douse bigger fire, while with bucket you would be able to do it. That's just an example.

- another thing: in Dromed you could have several stims or responses per one entity. F.e. sword sends Bash Stim with diffrent intensity depending on the swing type.

- another thing (as a consequence of intensity value) is fading the intensity with the distance. It could be 0 (equal intensity within radius, 1 - gradient fading or -1 - gradient growing the intensity (rarely used)).

- and one more thing - there was also flag for blocking or not the stimulous by architecture (STIM_VISUAL screams for this one).

- can we set ANY key for any entity using STIMS or scripts are the only reactions possible? In Dromed there was really long list of possibilities...

 

I know that's more about the system rather than GUI for it, but Greebo's work might be an opportunity to talk about it once more and suggest some improvements.

 

I'll try to come up with some suggestions for dialog window layout soon...

Share this post


Link to post
Share on other sites

This is my current progress on that topic. Please note that this is not final in any way and can of course be changed. Feel free to discuss.

 

stimresponseeditordb0.th.jpg

 

So far I've mostly been fiddling around with the back-end handling of the entity's spawnargs and the property/GtkListStore management. The widgets and the back-end can most probably be recycled if the GUI is about to change. :)

Share this post


Link to post
Share on other sites

Looks OK for our S/R system, I think.

 

I don't know that word starting with H... :)

 

And what happens after pressing Add Response Script? Does another dialog windows pop up with proper args to set up?

 

And just suggestion - mappers doesn't have to know the numbers of stims and responses (that's just for coders). What if we get rid of them and sort stims first and responses after them? Would be clearer, I think.

Share this post


Link to post
Share on other sites

The word with "H..." is the German word for "Add". It's a GTK stock item and these get translated to my system language, although I've told GTK to use English, oh well...

 

I'm not quite sure yet about the "Add Response" script button. As there is only one script per stim possible it somehow wouldn't make sense to put it into the Stim/Response detail editor on the above right. A sr_script_STIM_FIRE script would affect the whole entity, not just the currently selected S/R. Perhaps another list view below would be appropriate listing all the active response scripts.

 

The numbers: I partially agree here that these could be removed, although it could be useful to see the index of the Stim/Responses of the entity to locate "gaps" in the index.

 

Thinking about it, I even believe that it should be possible to add a stim and set it to a desired number to allow the overruling of the inherited stims. Imagine a situation where you want to inherit from light_torchflame, but without the default STIM_FIRE. You would have to add another stim and set it to exactly that ID, technically shadowing the inherited one. I'll have to think of a way to allow that in the back-end handling, but I already have an idea.

Share this post


Link to post
Share on other sites

They are all hand-made except for two. I took the eye and the skull from pictures found via google, copied the relevant part out and desaturated/inverted them plus resized them to 16 pixels. Does that imply any copyright issues? I can redo the eye and the skull from scratch, if you like.

Share this post


Link to post
Share on other sites

No, I think that level of modification wouldn't present a problem. I was more worried that they might have come from some online icon library or something, without an appropriate licence, but this fortunately isn't the case.

Share this post


Link to post
Share on other sites

Stim/Response Editor is looking great so far. :) I've been keeping tabs on it since you started. Great to see it becoming more and more functional. Whoo hoo.

Share this post


Link to post
Share on other sites

Thanks. :)

 

I'm nearly done with the prototype, the "Save to Entity" and "Re-load from Entity" buttons are still missing, but I expect to be done with that tonight.

Share this post


Link to post
Share on other sites

The prototype is done now and the basic functionality is there, although I most probably forgot something important.

 

stimresponseeditorv2dq1.th.jpg

 

I won't upload a new build today, because I still need to do some tests tomorrow, but those who build directly from SVN can already try it out. :)

Share this post


Link to post
Share on other sites
This is my current progress on that topic. Please note that this is not final in any way and can of course be changed. Feel free to discuss.

 

Looks good. :) For timers you will also need two mutual exclusive radio buttons, to select wether it is a singleshot or continous timer. Or you can use a dropdown box for it, watheverer is more convenient.

 

As for the S&R implementation, there still needs to be some work done to polish it. I implemented only the most rudimentary version of it, to make it work, and lay down a foundation, but I didn't know to much about it. I guess this has to be revisited to add also the intensity and other such stuff.

 

I'm not sure, if Ishtvan already implemented it for radius stims currently go through walls (which may or may not be desired, depending on the circumstances). And it should also be usefull to have that direct line of sight option as well.


Gerhard

Share this post


Link to post
Share on other sites
I'm not quite sure yet about the "Add Response" script button. As there is only one script per stim possible it somehow wouldn't make sense to put it into the Stim/Response detail editor on the above right. A sr_script_STIM_FIRE script would affect the whole entity, not just the currently selected S/R. Perhaps another list view below would be appropriate listing all the active response scripts.

 

The add Response script would be only an edit field, where the user can provide a functionname. I think for completness sake it should be there if you configure a response. The reason why I only allow one response per type is, because it doesn't make sense to have more reposense. Who would you know which one to choose? For example, a light can have only one response to water, which is to go out. If there are more then one usefull responses, then the mapper should differentiate it in his script, as we can not know in a generic way, which particular water script would be the correct one.


Gerhard

Share this post


Link to post
Share on other sites
The prototype is done now and the basic functionality is there, although I most probably forgot something important.

 

Looks pretty good. :) Next time you update DR I will start to use it, as the configuration for S/R is pretty tedious.

 

One thing that you should add though. The predefined stim types are ok in the combobox, but you should add an edit field which is non-editable, and the entry "User defined" in the combobox, if you don't already have it. If the user selects "User defined" in the combobox, the edit field should become editable and the user can type in a number that defines his, well, user defined stim id. The predefined are also only numbers in truth, but they are there for convenience. As label for the edit you can use "Stim-Id".


Gerhard

Share this post


Link to post
Share on other sites
For timers you will also need two mutual exclusive radio buttons, to select wether it is a singleshot or continous timer. Or you can use a dropdown box for it, watheverer is more convenient.

That's new to me, I never saw such a parameter in the documentation. Or is this a planned feature? Are there two distinct options (1/0) and what is the key name for this option?

 

One thing that you should add though. The predefined stim types are ok in the combobox, but you should add an edit field which is non-editable, and the entry "User defined" in the combobox, if you don't already have it. If the user selects "User defined" in the combobox, the edit field should become editable and the user can type in a number that defines his, well, user defined stim id. The predefined are also only numbers in truth, but they are there for convenience. As label for the edit you can use "Stim-Id".

The stim types are loaded from the doom3.game file, where all the stims and their id's are defined (in XML). One possibility would be to add them to this file, so that they get listed properly.

 

If this should be handled by the GUI, I'd rather vote for a button "Create Stim Type" where the mapper can define a new stim, which gets saved to an XML file. This way the mapper can reuse the stims and conveniently assign them without having to enter the id each time.

Share this post


Link to post
Share on other sites
That's new to me, I never saw such a parameter in the documentation. Or is this a planned feature? Are there two distinct options (1/0) and what is the key name for this option?

 

This was already implemented, but maybe the documentation was not updated.

 

sr_timer_type_N=SINGLESHOT
sr_timer_type_N=RELOAD

 

Default is singleshot, so you only have to specify RELOAD, or otherwise nothing (remove the key).

 

The stim types are loaded from the doom3.game file, where all the stims and their id's are defined (in XML). One possibility would be to add them to this file, so that they get listed properly.

 

Not sure what this means. :unsure:

 

If this should be handled by the GUI, I'd rather vote for a button "Create Stim Type" where the mapper can define a new stim, which gets saved to an XML file. This way the mapper can reuse the stims and conveniently assign them without having to enter the id each time.

 

Saving them for later reuse is probably a good idea, but then there is not THAT much to configure on a stim/response. Also wouldn't the dialog be the same as for the predefined ones? Maybe we need to add individual behaviour later on, for known stims, but currently we don't have this.


Gerhard

Share this post


Link to post
Share on other sites
The reason why I only allow one response per type is, because it doesn't make sense to have more reposense. Who would you know which one to choose? For example, a light can have only one response to water, which is to go out. If there are more then one usefull responses, then the mapper should differentiate it in his script, as we can not know in a generic way, which particular water script would be the correct one.

What if you want different responses based on the intensity of the stim? For example, a really big fire might sputter a bit if you shoot a water arrow at it, but it should go out if you submerge it in a pool.

 

Besides that, it just seems better from a UI point of view to have everything organised the same way... instead of just having "stims" and "responses" as being the only things that you have to manage to set up S/R, you now also have "response scripts" - which are not specifically associated with any particular response. Bit counter-intuitive IMO.


My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...