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

Stim/response Editor

Recommended Posts

Yes, that two column selector is much neater. Ah so it can be wider than the button so that solves that. I suppose the stim name limits the minimum button width. So what of the delete button? Leave that to the right click menu? You know, I think you've hit it. Without the delete button the add and the selector are bonded together as it were so there is no doubt they work together. Well, I don't know if you intended it but I'd leave out the delete button.

 

I had a glitch I thought was a feature before that has partly gone with this new version. If I clicked on the selector box I had to keep holding the mouse button down until I moved to a selection then release to select. I thought that was how it was meant to be. Now both these selectors work fine and I can left click select. But the Effect selector in the Edit Response Effect still has this glitch. If I left click it then release it closes. I have to keep holding it. BUT if I left click on the very last one or two pixels on the extreme right edge of the little downward arrow box on the right, in fact in the border just outside that arrow box, then it behaves like a 'normal' combo box and remains open even if I move the mouse away. I can then select and LEFT click a choice. Can you see anything different in the way you have set them up?

 

Downloaded the new effects and extracted them to the dark mod def folder. Still getting this memory reference error if I click Apply with empty effects fields. Maybe it will go away on its own in time! The last few lines of the Dark Radiant console window are...

 

...[shaders] materials/shaderDemo.mtr: Failed to parse "skin" (DefTokeniser: Assert
ion failed: Required "{", found "heatHaze")

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

 

The last few lines of radiant.log are as follows. I selected File > New map to clear out my test map just in case then just created a vase to add a response to...

 

--- LoadMapFile ---
g:/doom3/darkmod/maps/m/doorsTut.map
34 primitive
10 entities
Open file g:/doom3/darkmod/ for read...failure
Open file g:/doom3/darkmod/ for read...failure
Open file g:/doom3/darkmod/ for read...failure
Open file g:/doom3/darkmod/ for read...failure
Open file g:/doom3/darkmod/ for read...failure
Loaded Model: "models/darkmod/props/loot/vase_g.lwo"
 RenderablePicoSurface: using shader goblet1
[shaders] Unable to load shader texture: _white
[shaders] Loaded texture: models/darkmod/props/textures/goblet1_d
 RenderablePicoSurface: using shader textures/common/collision
[shaders] Loaded texture: textures/common/collision
libs/modulesystem/singletonmodule.h:95
assertion failure: module still referenced at shutdown

Share this post


Link to post
Share on other sites
I had a glitch I thought was a feature before that has partly gone with this new version. If I clicked on the selector box I had to keep holding the mouse button down until I moved to a selection then release to select. I thought that was how it was meant to be. Now both these selectors work fine and I can left click select.

Haven't tried it yet, but that's good to hear. If this refers to what I think it does, I had the problem where the list would form partially offscreen, and my only choice was to click and hold and let it autoscroll down - otherwise I couldn't select anything above the part where it left the screen. There were tricks to get around it, but it's a definite problem.

Share this post


Link to post
Share on other sites

Maybe there's a boost::shared_ptr exception going on here as this seems to be a runtime error rather than an "ordinary crash".

 

As for the left-mouse-click glitch. I can't influence the behaviour of the widgets themselves, if they're reacting differently to your mouse clicks that's most certainly a GTK issue. Let's see if this goes away with the new libraries (see the other thread).

Share this post


Link to post
Share on other sites

greebo: This is really a follow on to a couple of posts in the itches thread that I started there in error about deleting custom stim names and you suggested a warning confirm before deletion...

 

Yes I was thinking myself it would not be practical to keep track of every entity that ever used the stim. So probably the warning confirm delete is the best option.

 

Other thoughts:

 

Make new names undeletable. The user can still edit that name to something else but cannot delete it. No harm done. It's no different to any other stim. They cannot be deleted even if not used.

 

A hybrid of the above. Once a stim is added to an entity a variable is set unique to each new stim name. If set, it protects the name and the name cannot be removed from the list. It is irreversible so no check is made of how many entities are using it. So even if it is removed from them all then the name is still protected. This does at least mean that new names that are not used, or even created in error and not used, can be removed. An attempted deletion of a protected name could be met with a message "name might be in use" or even "name might be in use, please confirm y/n" Actually that would sit well with your idea but is hardly worth it.

 

Another variation: The above protection variable is incremented every time the stim is applied to any entity and decremented every time it is removed from any entity. Only if it is zero can the stim name be removed. Mmm... what if the entity is deleted? Or cloned? Do clones retain stims? - Yes! so dump that idea.

 

On balance I think your idea is probably best!

 

 

Other oddities and problems:

 

New stim names are, or should be, exclusive to the map in which they are created. Otherwise every new name a user creates would be stored and still be there every time DR is opened (like the default inherited ones) and as new maps are created and new stim names, the list would grow longer and longer. Can't delete anything as they are used in another map. So clearly new names are exclusive to each map. BUT...

 

First, new stim names are not being saved at all! The numeric id is saved but no name.

 

Second, any new stim names in memory are not removed when a new map is created or another map is loaded. Worse - if a new stim name with the same ID number as the one just closed is in the map loaded then it gets the different name. Well, this is just one bug really.

 

Multiple new stim names with the same name can be created. Not a major problem; the number itself is the unique identifier. I created one called Fire.

 

When the user goes to create a new stim name it might be natural (I've done this a few times already!) to go to the Name input box, type a new name, then click the add stim type button. Result: a new stim name is created with the default name of CustomStimType and that also replaces the name that the user has just carefully typed into the box.

 

Since multiple copies of the same name can happen anyway (they can even all be called CustomStimType) then why not take the name from whatever is in the box or, only if it is empty, give it the default name CustomStimType? A new name might be entered by just typing it in and pressing the Enter key. This would then be a basic input such as when you type a file name in a save dialog and hit either the Enter key or click the OK button. The user types in a new stim name then either hits Enter OR hits the Add button. It is failsafe because if the user has typed in a name then he/she must surely expect it to be the new name. I think the input box should be cleared after every input.

 

I created a very long name. The selector list handled it well by making itself wider. Is there a maximum length? Is there not a case for capping it at a reasonable length? Perhaps 15 or 20 chars is enough for anyone? I hate restrictions but there has to be some limit and I've never created a name in Dromed longer than about 10 or 12 chars that I recall. In fact the longest I made was botLightStim which is 12 chars and the longest in the whole list of Dedex is SilenceEndStimX which is 15. So 15 or 20 or to be ample.

Share this post


Link to post
Share on other sites

@Fidcal: I'm uploading a new build right now, which addresses some of the issues above:

 

http://208.49.149.118/TheDarkMod/DarkRadia..._latest_SVN.zip

 

Changes:

- A question box is shown when a custom stim is about to be deleted.

- Fixed the custom stim types from not being refreshed on map change.

 

For me, the custom stim types were properly saved into the storage entity (which is the worldspawn entity), hence no fix.

 

Regarding the maximum length of the custom stim name: I'm not for restricting the user artificially - if the mapper wants a 120 character description of his stim type, well why not? Storage space is not an issue, neither is the performance (all stim types are translated into numeric IDs during runtime).

Share this post


Link to post
Share on other sites

greebo: Should I install this over my DarkRadiant_latest_SVN_GTK_210 install and delete my other install?

Share this post


Link to post
Share on other sites

Yes, please install this over your GTK 2.10 snapshot, as I didn't package all the DLLs with this snapshot (it would make the downloads unnecessary large. You don't have to delete any other existing installations - the user.xmls should be compatible anyway.

Share this post


Link to post
Share on other sites

Dark Radiant v.0.8.2 of 20 Apr 07 18:31:09

 

Done some more checking on this missing custom stim name thing in the new version and it is saving the names but not displaying when first looking in s & r...

 

I create a new entity; add testStim (1000); save the map; close DR; Open DR with map; the entity's s & r shows in the stim list...

 

# s/r Type

1 S

 

... that is, the name testStim is not there in the entity's stim list. If I click it to highlight it then testStim appears in the type change selector in the right hand editing section but still not in the entity's stim list. If I click Add to add another stim it adds frob to the list at #2 and then the testStim name also appears at #1 position. So that just looks like a display bug only and the name is being saved but not displayed when first shown.

 

Now there's another oddity - every new brush I create has all custom stims added to it automatically! That is, its properties in the entity inspector window show...

 

classname worldspawn

origin -

editor_dr_stim_1000 testStim

Share this post


Link to post
Share on other sites
Now there's another oddity - every new brush I create has all custom stims added to it automatically! That is, its properties in the entity inspector window show...

 

classname worldspawn

origin -

editor_dr_stim_1000 testStim

 

Brushes don't have properties -- entities do. All brushes are a child of the worldspawn entity, so they will all display the same set of properties when selected.

Share this post


Link to post
Share on other sites
Dark Radiant v.0.8.2 of 20 Apr 07 18:31:09

 

Done some more checking on this missing custom stim name thing in the new version and it is saving the names but not displaying when first looking in s & r...

 

I create a new entity; add testStim (1000); save the map; close DR; Open DR with map; the entity's s & r shows in the stim list...

 

# s/r Type

1 S

Ok, I can see the problem now. I'll look into it. :)

 

Now there's another oddity - every new brush I create has all custom stims added to it automatically! That is, its properties in the entity inspector window show...

As Orbweaver said, all "ordinary" brushes are child of the worldspawn entity, that's why its properties are shown when any brush or patch is selected. Additionally, I use the worldspawn entity to store the custom stim type information, that's why you can see the "editor_dr_stim" stuff. These are just the definitions, "real" stim/response spawnargs look like sr_type_1 sr_class_N, and such.

Share this post


Link to post
Share on other sites
Additionally, I use the worldspawn entity to store the custom stim type information, that's why you can see the "editor_dr_stim" stuff. These are just the definitions, "real" stim/response spawnargs look like sr_type_1 sr_class_N, and such.

 

While this may work OK for now, in the long term we should look into changing the actual S/R system to accept user-defined names instead of numbers, so as to avoid cluttering up the worldspawn entity with mapping information that could just as well be constructed by the game itself.

 

E.g.

 

sr1_type = STIM
sr1_class = "My stim class"

Share this post


Link to post
Share on other sites

I think this would just move some of the workload into the SDK parser, but not reduce the actual workload - somebody will have to translate the custom stim names into numbers anyway. I also don't know if this would open issues when entities with "new" stim types are spawned during runtime, which would mean for the SDK code to keep the mapping between the strings and the IDs to recognise the stim type as "known" or "new".

 

As long as only a few stim types are defined by the mapper (IIRC Fidcal was talking about 10 at maximum), this won't be much of a problem, I reckon.

Share this post


Link to post
Share on other sites
I think this would just move some of the workload into the SDK parser, but not reduce the actual workload - somebody will have to translate the custom stim names into numbers anyway. I also don't know if this would open issues when entities with "new" stim types are spawned during runtime, which would mean for the SDK code to keep the mapping between the strings and the IDs to recognise the stim type as "known" or "new".

 

It wouldn't reduce the workload, but I think it would be a better place for the work to take place. Generally such "user-unfriendly" conversions should take place as late as possible, so that the user never has to deal with it (even if they use a different editor).

Share this post


Link to post
Share on other sites

If the mapping is to be maintained in the SDK it means, that it continously has to be done at runtime, while in the editor it would be done only once. Performancewise it would be better to do such stuff in the editor therefore.


Gerhard

Share this post


Link to post
Share on other sites

I've just checked out the latest version of the dialog, and it has certainly come a long way. A few very minor GUI points:

 

1. Numerical entries are generally better implemented as spin buttons, which allows you to easily increment or decrement the value as well as type in a new one. The hour/min/second boxes are a good example of where spin buttons would be useful.

2. I'm not altogether sure that listing the stim numbers in brackets is a good idea -- I can imagine questions like "Why does it say 'Timer (18)'? Are there 18 stims of this type? Does the timer last for 18 seconds?" etc. I can however see that this information might also be useful to some, particularly for custom stim types.

3. You could probably ditch the "Add stim" and "Add response" context menu items, they behave in a rather non-standard fashion (adding a new default item at the end and jumping to it) and there is already a very obvious way to add new items.

4. I would just put "Deactivate", "Delete" etc in the context menus, rather than "Deactivate Stim", "Delete Response" etc. It sounds trivial, but minimising the amount the user has to read is always a good idea.

 

Note that I haven't actually read the entire thread, so it is possible some of these have already been discussed.

Share this post


Link to post
Share on other sites
1. Numerical entries are generally better implemented as spin buttons, which allows you to easily increment or decrement the value as well as type in a new one. The hour/min/second boxes are a good example of where spin buttons would be useful.

Agreed, spin buttons are better here.

 

3. You could probably ditch the "Add stim" and "Add response" context menu items, they behave in a rather non-standard fashion (adding a new default item at the end and jumping to it) and there is already a very obvious way to add new items.

I'll disable them (comment out the code - perhaps there will be demand for them - we'll probably have to discuss that with the end users, i.e. Fidcal :))

 

4. I would just put "Deactivate", "Delete" etc in the context menus, rather than "Deactivate Stim", "Delete Response" etc. It sounds trivial, but minimising the amount the user has to read is always a good idea.

Agreed.

Share this post


Link to post
Share on other sites

Perfect! I've already completed 3 and 4 and am halfway through 1. :)

Share this post


Link to post
Share on other sites

I have barely used it recently (sorry I know :blush:) but the first thing that jumped out at me was the ordering of the Add stims popup. It's set up as alternating rows instead of two columns:

 

1 2
3 4
5 6

 

instead of

1 4
2 5
3 6

 

And they're by the number mentioned above instead of alphabetically. If the number isn't important to the user (is it? I don't know) then alphabetical might be a good order. Very trivial, but like I said, it just jumped out at me. :)

Share this post


Link to post
Share on other sites

I just tried to set the sorting of this dropdown field, but it doesn't seem to work (as it does with other dropdowns, I did that before). Perhaps this is not possible for 2-column drop-down fields? I'll have to look into that.

Share this post


Link to post
Share on other sites
2. I'm not altogether sure that listing the stim numbers in brackets is a good idea -- I can imagine questions like "Why does it say 'Timer (18)'? Are there 18 stims of this type? Does the timer last for 18 seconds?" etc. I can however see that this information might also be useful to some, particularly for custom stim types.

How about "Timer (#18)"? Might be a bit clearer.


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

Is there any actual need for a mapper to know that "Timer" is stim 18? Could we just not number the built-in stims, but still have "My custom stim (1001)" for the created stim types? I think this would be a good balance between providing useful information and not cluttering the interface.

Share this post


Link to post
Share on other sites

Ok, I'm through with all the 4 aforementioned items. All the numeric entries have been replaced with GtkSpinButtons and the stim type id is hidden now for the built-in stims. Custom stims still show their ID.

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...