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

Stim/response Editor

Recommended Posts

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.

 

Then you have to do this in a script. How should we parameterize it? This would be a nightmare to maintain, because stims can get all kind of complex parameters, and then we would have to select a script function based on these parameters? If intenisty is 10 take this function and if it is between 10 and 12 take this function and above 12 take this one? And this done in a generic way? That doesn't sound like a good idea to me. And this is only one parameter.

 

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.

 

Each entity can have it's exactly one type of response and one type of stim. And for each of these types you have exactly one scriptfunction, corresponding to it. Seems pretty clean to me. That the same stim can come from different sources, doesn't matter that much, because in most cases I expect that the reaction that a response represents will be the same. I guess the cases where different responses are needed based on where the SAME stim comes from, would probably be much rarer, and you can still do it with scripting. SO it's not as if the mapper doesn't have this opportunity.


Gerhard

Share this post


Link to post
Share on other sites
Then you have to do this in a script. How should we parameterize it? This would be a nightmare to maintain, because stims can get all kind of complex parameters, and then we would have to select a script function based on these parameters? If intenisty is 10 take this function and if it is between 10 and 12 take this function and above 12 take this one? And this done in a generic way? That doesn't sound like a good idea to me. And this is only one parameter.

The easy way out is to just call the scriptfunctions of all applicable responses. :) Mappers can deal with the consequences of having multiple scriptfunctions trigger.

 

Each entity can have it's exactly one type of response and one type of stim.

Hang on... are you saying that an entity cannot have, for example, two fire stims at once? Because greebo's screenshot of the S/R editor has two fire stims listed there. And it would make sense to have this capability: for example, to simulate being shielded from a big bonfire, I might want to make a very strong fire stim that doesn't penetrate walls, and a weaker fire stim that does penetrate walls - both on the same entity.

 

And for each of these types you have exactly one scriptfunction, corresponding to it. Seems pretty clean to me. That the same stim can come from different sources, doesn't matter that much, because in most cases I expect that the reaction that a response represents will be the same. I guess the cases where different responses are needed based on where the SAME stim comes from, would probably be much rarer, and you can still do it with scripting. SO it's not as if the mapper doesn't have this opportunity.

Is the intensity of the stim passed to the scriptfunction? I don't understand much about how it works, but from reading the wiki it looked to me like it wasn't.

 

The design may be clean from an internal programming point of view, but it does complicate UI design because there is a disconnect between "what I respond to" and "how I respond to it". And having one scriptfunction per entry in the response table is just as clean from a programming point of view (if you adopt the behaviour I describe above, of calling all applicable scriptfunctions).


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
Each entity can have it's exactly one type of response and one type of stim. And for each of these types you have exactly one scriptfunction, corresponding to it. Seems pretty clean to me. That the same stim can come from different sources, doesn't matter that much, because in most cases I expect that the reaction that a response represents will be the same. I guess the cases where different responses are needed based on where the SAME stim comes from, would probably be much rarer, and you can still do it with scripting. SO it's not as if the mapper doesn't have this opportunity.

If we want our S/R system to be in any way similar with functionality to the Dromed's one (what is the actual idea, AFAIK) intensity should have to be implemented and also Min and Max conditions for the response to start as well. It's still generic and that's what people are used to, so don't be afraid that it's get too messy.

 

That's also the reason for having multiple responses for one stim. I'd see the responses as very simple - just one action. And then if you want to change the model, change the skin and health points of some entity you would have 3 responses to one stim.

 

So - we're not talking about randomly choosing one of several responses for the stim - we're talking about processing several responses at once or based on the Min and Max intensity condition.

 

Sparhawk - trust us - the old dromeders, who were using that system in practice. Even if something seems to make no sense for you, cause you never know what mappers can come up with and what they might need.

 

And to be honest with you - people will get disappointed if our S/R system is much weaker then the Dromed's one. When I was outside this team, that's how I understood your intentions (and probably not only me) - to make system similar to that in Dromed.

 

 

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

In Dromed you could specify amount of firings or set the flag No Max Firings. Would it be hard to do add amount of firings to our system?

Share this post


Link to post
Share on other sites
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.

 

That part confused me too -- what is the difference between a Response and a Response Script? Shouldn't the Response determine what the entity does when it gets stimmed (which may involve a script)? What happens if you have a Response but no Response Script -- what does the Response actually mean in this case?

 

@greebo: looking very good. I guess if the prototype is ready then now is the time for any GUI comments:

 

1. As discussed, since this has no effect on rendering and for ease of implementation I think this should be a modal dialog rather than a non-modal inspector. This means you wouldn't need a "Reload from entity" button, the "Save to entity" button would be replaced by the normal "OK", and an additional "Cancel" button would close the dialog and abort changes.

2. The checkboxes seem to be non-standard, as if you have created them manually with a separate checkbox and label widget. This means that on Linux I cannot click on the text to activate the checkbox, which usually I can. Is there a reason why it needs to be done this way? If there is a problem with alignment I can look at it.

3. Rather than having a separate "Add stim/response" section with two types of add buttons, I would move the "Add stim/response" button along with its popup list into the main Stim/Response section, and move the "Add response script" button down into the Response Scripts section.

4. There is some strange behaviour regarding panel sensitivity -- if I bring up the dialog for an entity with no SR keys, everything is available, but as soon as I click on the "Stim" or "Response" buttons the whole panel becomes disabled.

 

Coding:

1. I like the SREntity idea, where an object wraps an Entity* and provides the additional functionality to deal with high-level Stim/Response objects, I should see if I can make use of this idea for managing Objectives as well. However, I don't think the SREntity should create and own the GtkListStores -- these should be owned by the dialog (as they are a GUI widget), and passed to the SREntity so it can populate them.

2. You should use TRUE and FALSE with GTK not true and false. Although it may work, it is not defined behaviour since true and false are C++ built-in boolean types, whereas TRUE and FALSE are #defines from the C-based GTK API.

Share this post


Link to post
Share on other sites
@greebo: looking very good. I guess if the prototype is ready then now is the time for any GUI comments:

Thanks. :)

 

1. As discussed, since this has no effect on rendering and for ease of implementation I think this should be a modal dialog rather than a non-modal inspector. This means you wouldn't need a "Reload from entity" button, the "Save to entity" button would be replaced by the normal "OK", and an additional "Cancel" button would close the dialog and abort changes.

Yes, we talked about that earlier and I will change it soon.

 

2. The checkboxes seem to be non-standard, as if you have created them manually with a separate checkbox and label widget. This means that on Linux I cannot click on the text to activate the checkbox, which usually I can. Is there a reason why it needs to be done this way? If there is a problem with alignment I can look at it.

Ah, I didn't know that the label of a GTK standard button was clickable, that is of course a loss. There were indeed alignment problems, as the "radius" checkbox didn't align with the gtk standard checkbuttons. I can revisit this problem and if I get stuck I'll post back here. :)

 

3. Rather than having a separate "Add stim/response" section with two types of add buttons, I would move the "Add stim/response" button along with its popup list into the main Stim/Response section, and move the "Add response script" button down into the Response Scripts section.

You mean, move the combobox above the stim/response toggle buttons (with the green/blue icons) and the Add button to the right?

 

Where should the Add Response Script button go?

 

Coding: I like the SREntity idea, where an object wraps an Entity* and provides the additional functionality to deal with high-level Stim/Response objects, I should see if I can make use of this idea for managing Objectives as well. However, I don't think the SREntity should create and own the GtkListStores -- these should be owned by the dialog (as they are a GUI widget), and passed to the SREntity so it can populate them.

I agree, that would look more consistent. I had it setup this way, because I saw the SREntity as the main "database" for the StimResponse information and the GtkListStore is just another type of data storage. I considered the dialog as some sort of client to the SREntity. But I can of course change it. :)

Share this post


Link to post
Share on other sites

Whoops, I edited while you were replying so I will post these here:

 

- There is some strange behaviour regarding panel sensitivity -- if I bring up the dialog for an entity with no SR keys, everything is available, but as soon as I click on the "Stim" or "Response" buttons the whole panel becomes disabled.

 

- You should use TRUE and FALSE with GTK not true and false. Although it may work, it is not defined behaviour since true and false are C++ built-in boolean types, whereas TRUE and FALSE are #defines from the C-based GTK API.

Share this post


Link to post
Share on other sites
You mean, move the combobox above the stim/response toggle buttons (with the green/blue icons) and the Add button to the right?

 

Where should the Add Response Script button go?

 

Perhaps leave the Add stim and combobox in the same place, but without a separate section title. The Add Response script button could go underneath the list of response scripts, so you have the usual idiom of list-box-with-add-button-underneath.

Share this post


Link to post
Share on other sites
- There is some strange behaviour regarding panel sensitivity -- if I bring up the dialog for an entity with no SR keys, everything is available, but as soon as I click on the "Stim" or "Response" buttons the whole panel becomes disabled.

Will check that.

edit can't reproduce this. For me it's working as it should. You should of course be able to add S/R keys for entities that haven't got any (yet).

 

- You should use TRUE and FALSE with GTK not true and false. Although it may work, it is not defined behaviour since true and false are C++ built-in boolean types, whereas TRUE and FALSE are #defines from the C-based GTK API.

Ah, ok, I will keep that in mind. Are there any systems on earth where one defines TRUE to be different from the C++ true?

Share this post


Link to post
Share on other sites
Hang on... are you saying that an entity cannot have, for example, two fire stims at once? Because greebo's screenshot of the S/R editor has two fire stims listed there. And it would make sense to have this capability: for example, to simulate being shielded from a big bonfire, I might want to make a very strong fire stim that doesn't penetrate walls, and a weaker fire stim that does penetrate walls - both on the same entity.

 

I have to check it in the code, but I don't really understand your example. If I want to make a shiedl against a fire, then I would create such an object and put a response on the script that ignores such fires. The script would then have to check wether the stim came from a static fire, or i.e. from a fire arrow, which might still do damage. Depends on how the shield is supposed to work. Why would I need two stims for the same thing?

 

Is the intensity of the stim passed to the scriptfunction? I don't understand much about how it works, but from reading the wiki it looked to me like it wasn't.

 

Currently there isn't an intensity. I think it would be best to collect what is needed for the stims, somewhere, and then we can implement it. The current version is rather basic and simple because there was not much demand for now, and I never understood how exactly it worked in Dromed, having no experience with it. I learnt a bit now from that thread on TTLG that greebo started and from this discussion, so I will take notes on it for future implementation. I think the SR must definitely be improved for the 1.0 release.

 

The design may be clean from an internal programming point of view, but it does complicate UI design because there is a disconnect between "what I respond to" and "how I respond to it". And having one scriptfunction per entry in the response table is just as clean from a programming point of view (if you adopt the behaviour I describe above, of calling all applicable scriptfunctions).

 

Which causes a big overhead, as there are a lot of functions being called where most of them will decide that they don't have to do anything. For each funciton there is a seperate scriptthread started. I don't think that this is a good idea, considering that stims will play a large part in a normal map.

 

I don't see why there is a problem with the UI though. An entity can respond to a a given stim, i.e fire or water, or invitation or whatever. Do you mean to say that in Dromed you can setup responses as such that you can determine to do this stuff when the response is coming from this object, but do this other stuff when the same type comes from another object?


Gerhard

Share this post


Link to post
Share on other sites
And to be honest with you - people will get disappointed if our S/R system is much weaker then the Dromed's one. When I was outside this team, that's how I understood your intentions (and probably not only me) - to make system similar to that in Dromed.

 

It depends. It doesn't mean that we will implement all aspects of it, because some things may not even make sense or are solved differently. We are certainly trying to make the best of it, but that doesn't neccessarily mean a 1:1 copy.

 

In Dromed you could specify amount of firings or set the flag No Max Firings. Would it be hard to do add amount of firings to our system?

 

Actually I have that planned. :) I also planned to allow for a second timer that specifies how long the stim should wait before restarting again. Not sure if I should do this from within a stim as it can also be implemented from a response script.


Gerhard

Share this post


Link to post
Share on other sites
That part confused me too -- what is the difference between a Response and a Response Script? Shouldn't the Response determine what the entity does when it gets stimmed (which may involve a script)? What happens if you have a Response but no Response Script -- what does the Response actually mean in this case?

 

Not in all cases a script is needed IMO. If somebody implements a response in the SDK directly, then he might not need a script being triggered as well. The default behaviour is to call a script though.


Gerhard

Share this post


Link to post
Share on other sites
Will check that.

edit can't reproduce this. For me it's working as it should. You should of course be able to add S/R keys for entities that haven't got any (yet).

 

It's definitely sensitive when the dialog is first displayed for a Light entity, at least for me. Are you making an initial call to the relevant update function when the dialog is first shown? It works fine when the selection is changed, but it looks like the sensitivity is just not updated initially.

 

Ah, ok, I will keep that in mind. Are there any systems on earth where one defines TRUE to be different from the C++ true?

 

They are different types - C++ true is a boolean, wherease GTK's TRUE is some kind of integer. This means that comparing them for equality is undefined (I think), and even if it is defined there is no guarantee that whatever GTK's TRUE is defined to be would be equivalent to the C++ true (although it is likely).

Share this post


Link to post
Share on other sites

Well, at least I can't think of any reason to define "true" to something different than an integer 1 (internally), but I won't object using TRUE for GTK calls either. I already changed it.

 

I also swapped the labels to the GTK standards generated by gtk_label_new_with_label(), it's even simpler. I must have either though too complicated or had a slightly different widget setup in mind than what is used now. Anyway, that's ok now.

 

Concerning the panel sensitivity: I can see it now, I had to create an ordinary light to see it (I only had light_torchflames, func_statics and AI around in my testmap). Will squash that one.

Share this post


Link to post
Share on other sites

I think the problem is gone now, at least I couldn't reproduce it anymore.

 

The dialog is modal now and refuses to show if no entity is selected (displays an error).

 

Would it be a problem, if I left the GtkListStore in the SREntity? I somehow find it easier this way, because all the data manipulation is done by the SREntity class and the editor dialog itself hasn't to bother with the row manipulation, it jsut passes the calls to the data class.

Share this post


Link to post
Share on other sites
Would it be a problem, if I left the GtkListStore in the SREntity? I somehow find it easier this way, because all the data manipulation is done by the SREntity class and the editor dialog itself hasn't to bother with the row manipulation, it jsut passes the calls to the data class.

 

Well if it works, and is easier this way I suppose it is OK. Just make sure that you have a clear idea of how and when the list stores should be deleted, since if they are not owned by the tree view they must be explicitly deleted to avoid memory leaks.

Share this post


Link to post
Share on other sites

This should be ok then, because I call g_object_unref() on the liststore immediately after adding it to the treeview. This way the treeview should be the only one holding a reference to it. Next time a new model is assigned, the old one is removed and its refcount should reach zero.

 

What remains is the placement of the add buttons. I'd rather wait with this until the stim/response discussion has progressed, maybe the whole GUI setup is going to be obsolete anyway.

Share this post


Link to post
Share on other sites
Not in all cases a script is needed IMO. If somebody implements a response in the SDK directly, then he might not need a script being triggered as well. The default behaviour is to call a script though.

How woud you implement a response directly in the SDK? Write the script function in the SDK and then just put the name of that script function in the response script?

Share this post


Link to post
Share on other sites

In the SDK you can do everything. Of course it would be pretty hard coded, but it would be doable. You could add something like

if(stim_id == MY_STIM_ID)
  MyResponse();

 

Easy, eh? ;)


Gerhard

Share this post


Link to post
Share on other sites

Oh, you mean put that in the idGameLocal::ProcessStimResponse or whatever it's called? Yeah, that's do-able, but then we'd end up with a giant switch-case there for all the custom responses. :)

 

I was thinking put this in the entity def:

 

response_script: <custom SDK scriptfunction>

 

Then define the custom scriptfunction as an Event_* in the SDK. So the call goes thru scripting briefly but gets back to the custom SDK scriptfunction. That way we could avoid a giant switch-case structure somewhere.

Share this post


Link to post
Share on other sites
Oh, you mean put that in the idGameLocal::ProcessStimResponse or whatever it's called? Yeah, that's do-able, but then we'd end up with a giant switch-case there for all the custom responses. :)

 

 

typedef struct {
  int id;
  void (*Functptr)();
} FuncTableEntry

static FuncTableEntry FuncArray[] {
 { Stim_id1, Function1 },
 { Stim_id2, Function2 },
 { Stim_id3, Function3 },
 { -1, NULL }
}

...


while(FuncArray[i].Funcptr != NULL)
{
  if(FuncArray[i].id == StimID)
  {
  FuncArray[i].Funcptr();
  break;
  }
  i++;
}

 

No big switch statement. :)

 

Then define the custom scriptfunction as an Event_* in the SDK. So the call goes thru scripting briefly but gets back to the custom SDK scriptfunction. That way we could avoid a giant switch-case structure somewhere.

 

I don't think it would be a good idea to really implement responses directly in the SDK, but it is doable. Responses should be rather atmoic functions, so that you can use the from within scripts just like other usefull functions. But it would be doable fo course.


Gerhard

Share this post


Link to post
Share on other sites

As posted in the "current build" forum, the S/R editor is near to completion, apart from the "chance" factor to make stims and responses random (I'll have to add this option to the SDK, but this won't take long).

 

The new build is on FTP, if anyone wants to have a look at it:

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

Share this post


Link to post
Share on other sites

OK, feelings about the S & R interface. This is without reference to anything that has been posted above but is just my reactions to the S & R dialog in DR v.0.8.1 (sorry but that's the number in the 'about' but it's a later update!)

 

By 'dialog' or 'dialogue' I mean the main displayed panel or interface.

I might use 'source' and 'stim' to mean the same thing. Likewise 'response' and 'receptron'. Though technically they are not quite the same things.

 

First here are the links to images of the Dromed interface for anyone's reference:

 

Dromed Source dialog

Dromed Receptron dialog

 

I like the idea of having one dialogue for both S & R but not so sure about having them in a mixed list. Nor do I see the reason for the ID number to be visible to the user unless you have some debug output where it's of use. Unless you can actually pinpoint a use I'd drop it.

 

So I personally would favour having two separate lists in the one dialog. There may even be a case for having two separate dialogs (like Dromed) if it is going to get cluttered. An alternative to consider is one dialog but can switch between showing stims and response lists. After all, although related, stim and response are two quite different things.

 

Remove the Stim and Response and Add S/R buttons and replace those three buttons with just two : Add Stim and Add Response. As it is you can change a stim to a response and back again. Hard to visualize the effect of this once set up.

 

Here's me browsing through the fire S & R in the snow test map...

 

I note I cannot select the inherited S & R that is already there. I see water, fire, and KO responses plus fire and visual stims. At the bottom in response scripts I see Fire, knockout, and water which also I cannot edit. I need some means of either modifying or aborting inherited S & R. In Dromed the only way to stop an inherited response is to add another of the same name set to abort; this then functioned first and stopped the normal response. I would like to see the possibility of changing a fire like this so a water arrow does not extinguish it or its a big fire and you need more water. Not great examples but there are situations when you want to be able to change the default - and probably the way is an over-ride that has an OPTION to abort any existing s & r of the same name plus an option to add a new one. So to change the damage points done by a fire one might either be able to modify the default or cancel it and substitute another.

 

Even if the inherited s & r cannot be changed I think one should see the values associated therewith, eg, what is the intensity or type (radius/contact) of the fire?

 

The scripts need a means of adding parameters; at its simplest a sequence of string values with separators.

 

Room for comments might be useful.

 

Adding custom scripts should be a less-often-used alternative to give 'infinite' flexibility. 99% of all response effects ought to be selected from a list like Dromed with various fields for the parameters. Of course, these are then passed to scripts. Good examples are in the Dromed receptron image link above.

 

The target object is the object on which the effect is to act.

'Me' in that group is the object on which the response property is set

'Source' means the object giving the stim

 

The agent object is for reference information, eg, a teleport might be absolute or offset from a target object.

 

Other parameters are added via the 'Edit Effect' button which reveals a fields input, eg, for the teleport offset.

 

Althought the Dromed interface has been criticised you can see the simplicity of being to read the list of receptrons on an object and see the actual effect of a stim, eg, add metaproperty.

 

I would consider a separate delete button from the right context menu option.

 

Maybe the revert button should have a confirm y/n as some s & r can take a while to set up and it would be rather devastating to have it blown away with a careless mouse.

 

I've gotta go. I'll look at this again later or tomorrow. I'm on UK time.

Share this post


Link to post
Share on other sites
I like the idea of having one dialogue for both S & R but not so sure about having them in a mixed list. Nor do I see the reason for the ID number to be visible to the user unless you have some debug output where it's of use. Unless you can actually pinpoint a use I'd drop it.

 

The ID is neccessary, because the user can put his own stim/response types by writing a different ID there. Named IDs just means that we already know about them and know how to process them. An arbitrary number can be used, by the user to create his own responses for custom stims. The editor should check though wether the entered ID matches a known named ID and then display it instead, so that the user can not accidently use an already known number.

 

After all, although related, stim and response are two quite different things.

 

Not really. A stim is very closely related to it's response (or vice versa) so IMO it makes sense.


Gerhard

Share this post


Link to post
Share on other sites

I just typed quite a lot and then deleted everything again. :) The dialogue requires that you really think about how the stims/responses work and I forgot about this. After recalling the design of the S&R it makes perfect sense. :)

 

Only issue is, the timer option may not make sense, but I have to check the code to see how it works. Also, when I create a timer stim, I would expect that the timer editfield would be mandatory, which it is not. Currently you can leave it unchecked, which doesn't really make sense IMO.


Gerhard

Share this post


Link to post
Share on other sites

@Fidcal: I'm afraid you did not use the latest build I linked three posts above? The "Add S/R" button and the response scripts have already been removed/replaced/redesigned with new items. The system has been undergone quite some changes, so some of your suggestions are already implemented.

 

I agree about your point of having a possibility to override inherited stims and responses. And this is exactly the reason why I included the index column in the list, because you will have to define a stim on the inheriting entity with the same index to override it.

 

I will have to look at your other feedback again in more detail, I couldn't go through everything right now. I'll edit this in this post.

 

edit:

I like the idea of having one dialogue for both S & R but not so sure about having them in a mixed list. Nor do I see the reason for the ID number to be visible to the user unless you have some debug output where it's of use. Unless you can actually pinpoint a use I'd drop it.

As above, the IDs are the key to override inherited stims/responses. The functionality is lacking at the moment, so I'll have to add such an option to "override" stims and provide another effect that does just nothing.

 

So I personally would favour having two separate lists in the one dialog. There may even be a case for having two separate dialogs (like Dromed) if it is going to get cluttered. An alternative to consider is one dialog but can switch between showing stims and response lists. After all, although related, stim and response are two quite different things.

I agree that Stims are different to Responses, but for consistency/flexibility reasons I'd vote for leaving them in one list. I would find it inconvenient to switch dialogs between setting up stims and responses. Then again, that's just me. :)

 

Remove the Stim and Response and Add S/R buttons and replace those three buttons with just two : Add Stim and Add Response. As it is you can change a stim to a response and back again. Hard to visualize the effect of this once set up.

The "Add S/R" is gone and has been moved into the context menu of the S/R list.

 

I need some means of either modifying or aborting inherited S & R.

Agreed and confirmed, I'll implement such an option to define an "override" stim/response using the exact id of the inherited one. There will be an "effect_nothing" that will just do nothing, if no alternative effect is desired.

 

Even if the inherited s & r cannot be changed I think one should see the values associated therewith, eg, what is the intensity or type (radius/contact) of the fire?

This works for me, the widgets are of course insensitive, but I can see the value (compare default light_torchflame entity).

 

The scripts need a means of adding parameters; at its simplest a sequence of string values with separators.

There is an effect_script now that can be used to fire custom scripts, if the existing predefined effects are insufficient. The parameters of this function are fixed, but you can store additional information on the entity that can in turn be used by the script. This is a more sophisticated setup and will require some additional work than just clicking. The GUI will probably be not much of a help here, I'm afraid. The entity inspector and your preferred script editor are the way to go here.

 

Room for comments might be useful.

What do you mean here? Some kind of textfield whose contents get stored in the entity or something different?

 

Adding custom scripts should be a less-often-used alternative to give 'infinite' flexibility. 99% of all response effects ought to be selected from a list like Dromed with various fields for the parameters. Of course, these are then passed to scripts. Good examples are in the Dromed receptron image link above.

A small set is already available, more certainly are upcoming on request (if they're easily implemented).

 

I would consider a separate delete button from the right context menu option.

What do you mean here exactly?

 

Maybe the revert button should have a confirm y/n as some s & r can take a while to set up and it would be rather devastating to have it blown away with a careless mouse.

Agreed, that might be safer.

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