S/r Editor: Manipulating Stims/responses

[greebo]

This time there is no suitable stim so I want to invent a new name say, throwStim. Creating a stim actually just creates a label, nothing more. Will it be possible to create this name within the editor or must it be added separately then selected in the editor? (as in Dromed) Adding the stim to an entity defines its properties on that entity or entity type alone. I want to add it and select say, 'contact' type. The intensity is unimportant in this case. I've finished with the carpet and the stim. I close the s & r interface. That task is done.

Adding new stims will not be possible via the GUI, because it involves changes in the mod codebase (SDK code). I don't get your point about the "Adding the stim to an entity defines its properties on that entity or entity type alone" bit. Please clarify.

 

You might wonder where do scripts go in the above response editor? They are included in the effect drop down list as eg, 'call script'. The user then selects the 'edit effect' button and enter the script name and any parameters and these are displayed below the effects box.

There is already the "effect_script" response effect that does exactly what you suggested. However, it's not possible to define an arbitrary number of parameters, because calling scripts from within the SDK code is not that dynamic. I guess sparhawk can tell us more about that, maybe there is an easy way to define an arbitrary number of script parameters.

 

I cannot select existing inherited s & r to examine them let alone edit them.

I agree about the display of inherited stim properties (that should already be possible), but it will definitely not be possible to edit inherited stims or responses, because they are defined on the base entity class. If these are changed you'd change the properties of ALL inheriting entities, which is probably undesired. The way to go here is to override a certain inherited item by a stim of the same ID. The easy way of doing this from within the GUI is yet to be written, but I definitely agree about that feature.

 

If the menu is hard wired into the program then you have to create a default entry before you can edit it.

That's not a real issue, is it?

 

With a radius stim is needed not only the radius and intensity but also a flag to indicate if the intensity falls of slowly from the centre to the circumference or is constant throughout.

That's what the falloff exponent is for. Use 0 to let the magnitude be constant over the stim radius, use 1 to let it fall off linearly, 2 = quadratically and so on (arbitrary floating point numbers are possible).

 

The stim needs a period cycle, eg, every 3000 milliseconds, and the number of cycles with the default (in my experience) of unlimited plus an option to destroy its host entity on completion. Thus from creation the stim might fire six times every 3 seconds then end with or without destroying the entity. Or the stim might continue indefinitely though thoughout the duration of the game.

Ok, that's more or less a new feature. The periodic setup of a stim is already there (that's the time interval property and the "timer reloads after firing" option), what's not yet implemented is the "self-destruct when done" option and the limited number of firings. I will have to implement that in the SDK.

[sparhawk]

Adding new stims will not be possible via the GUI, because it involves changes in the mod codebase (SDK code). I don't get your point about the "Adding the stim to an entity defines its properties on that entity or entity type alone" bit. Please clarify.

 

I'm not sure if this is correct. A mapper should have the chance to create his own stim and set certain properties on it. That's why you have numeric IDs for them, so the mapper can use his own stim/response creation. I guess we will need a scriptfunction like TriggerStim, which should cause the appropriate responses to be set off based on their ID. The idea is that known stims, perform known actions. Like switching off lights, raising alerstate, etc. while unknown stims would just call a scriptfunction. Not sure if this makes sense though, because I guess the basic stims should cover basically all kind of actions, so this might not even be neccessary anymore.

 

I guess sparhawk can tell us more about that, maybe there is an easy way to define an arbitrary number of script parameters.

 

Not really. I was thinking of adding arrays, but then we didn't need them anymore, so I dropped it. Passing arbitrary numbers of arguments can be done from the SDK code, because I wrote a function just for that. But passing them in from a scriptfunction to another, would be harder, because it would require an extension to the scriptinterpreter. Currently it only works from the SDK to script, but not the other way around.

 

That's what the falloff exponent is for. Use 0 to let the magnitude be constant over the stim radius, use 1 to let it fall off linearly, 2 = quadratically and so on (arbitrary floating point numbers are possible).

 

I assume that you calculate the distance, directly when the property is set, because it wont change anymore after that?

 

Ok, that's more or less a new feature. The periodic setup of a stim is already there (that's the time interval property and the "timer reloads after firing" option), what's not yet implemented is the "self-destruct when done" option and the limited number of firings. I will have to implement that in the SDK.

 

Limited number of firings should be easy. Just a number that counts down, and when it reaches zero, it expired. Actually my first implementation contained a lot of this features, but then it became to unwieldy and I dropped it in order to get a basic stim working. Also this can be easily be implemented in a response script anyway, because you just have to count how often it fired, and after it reached it's limite, you can simply switch it off. So you wouldn't even need to implement it in the SDK, but it is more convenient to have it there.

[Fidcal]

I don't get your point about the "Adding the stim to an entity defines its properties on that entity or entity type alone" bit. Please clarify.

A stim name itself is just a label, a name without any properties whatsoever. What properties does 'waterStim' have? None of itself. Any properties such as radius or contact, intensity, etc are defined in an archetype or instance and can be different in other archetypes or instances.

 

Suppose I want to make a map with radio-active materials in a mine, maybe a few rats down there get radioactive too. I need to create a new stim and call it perhaps radiumStim. Where would I add that name in DR? There must be a list of default stims to which the map maker can add more for that map only.

 

Anyway, once added to the list of stim names for that map it has no powers nor properties of any kind. It's just a name. I might change my mind or forget it and not even use it at all. When I add that stim name to some rock I define some properties on that rock archetype or instance alone to be associated with that label radiumStim. On one rock it might be used as a weak radius stim and on another as a strong contact stim. Whatever properties I define are on a particular archetype or instance only and can be different on the next one.

 

If, in Dark Mod, it is NEVER possible for the map maker to add new stims then it is ESSENTIAL that a generous set of spare stim names be included and NOT used in the general hierachy so they are free for the map maker to define. Various unused generic names might be included such as magicStim, vomitStim, slowDeathStim, etc. but the possibilities are endless so maybe the answer is to include names like A1 thro' A9, B1 thro' B9, etc so if I want to create a radiumStim I can at least use the name R1. It is possible but risky to use existing stim names that are already in use for something else. For example, if Dark Mod includes a 'holyStim' for use on holy water against undead and my map does not use undead I could use that stim for some other purpose like a stinkStim the player might drop to deter human guards from the area for a time. But if undead with a built in response to holyStim came along they would die which is not what is intended. A poor example but you can see that map makers need to take great care if using stims for other purposes that they do not come into contact with the wrong response. It is bad practice to re-use stims that way. Hence the need for the map maker to be able to create new ones or at least use ones that he/she knows are not used. Care also needs to be taken with third party add-ons that might include use of these normally unused stim names that they are declared.

[OrbWeaver]

I think the SDK code limits the stim types you can have, it is not up to DarkRadiant to define new ones because they do not exist in the game.

 

It does raise the question though, do the stim types actually "mean" anything at a code level, or is their meaning entirely defined by what responses you add for them in your map? If the code does not care about the stim types, perhaps you could just make up new ones in your map?

[sparhawk]

That's the case. The names for the stims are just that. Symbols, as convenience for the mapper. The code itself doesn't know any of their meaning and all the logic of the responses is done in the scripts.

[greebo]

The way the system is defined, it's of course possible to define new stims (the names STIM_FIRE, etc. are mapped to integers), and I agree that we need a GUI to do something like this in DarkRadiant.

 

However, a small change in the SDK would be appropriate, because at the moment the spawnargs are named:

"sr_type_1" => "STIM_FIRE"

which uses a string representation (that is resolved within the SDK). This should be replaced with a single integer, this way it shouldn't be too hard to let the mapper define new stims.

 

What we do need is a way to store these new stim types within the map (having just numbers wouldn't require storage, but numbers are hard to keep track of). Either they are saved in the worldspawn entity or we let DarkRadiant create a .def file (which is not very elegant).

 

(Third option: let the mapper do the work by himself (he/she would have to edit a .def file manually, which isn't too much work after all).)

[Fidcal]

Just to reinforce this, Dromeders routinely create their own stims. Here are extracts from an old Dromed S & R tutorial by Sledge. Note the importance of the last sentence of the first paragraph...

 

"When doing your own effects, it is best to create an entirely new source or "stim." Click on Stimulus in this part of the Object Hierarchy and click "Add." Type in the name of whatever stim you like. Then, save the gamesys AND the mission you're working on. You have to re-open your mission for this particular change to take effect. Make sure you have set the gamesys in your mission (set_gamesys x.gam) before you save and re-open the mission. If you have a new stim to use, whatever new effects you create will in no way affect anything else in the game."

 

"For most things, you will want to choose your own custom stim. From the drag down menu, select the name of a stim. If you added one previously (see above) and saved your gamesys and re-opened your mission, your new stim should appear at the bottom of this menu."

 

I see this tutorial includes a list of all response effects and what they do in Dromed (though I'd have to examine it more closely to see if it is T2 or T1.) The whole text file might be of interest and stimulate ideas. It is published publically somewhere but if anyone wants I can upload it to my site. It's only about 36K so can be skipped through reasonably quickly for anything relevant. Hell, it's no effort so I'll put it up anyway

HERE

 

The topic of the mapper making changes to the properties of archetypes (which again, Dromeders are used to) has been raised and might need its own thread at some point. I see the def files but not the hierachy - what properties would be inherited by other entities. I won't pursue this here but many Dromeders would be looking to see how to do this if they moved over to TDM.

[greebo]

The topic of the mapper making changes to the properties of archetypes (which again, Dromeders are used to) has been raised and might need its own thread at some point. I see the def files but not the hierachy - what properties would be inherited by other entities. I won't pursue this here but many Dromeders would be looking to see how to do this if they moved over to TDM.

The entityDefs found in the .def files have an "inherit" key set which specifies what entity they should derive from. They basically inherit everything that has been defined on the base entity. If you don't want a keyvalue to inherit, you will have to override it by defining the same key on the inheriting entity and change it to fit your needs.

 

There is no way to change the contents of the .def files from within the editor currently. If you need to change an entity definition, the text editor is the way to go here.

[OrbWeaver]

Editing archetypes does not make sense in the context of a Doom 3 mission, because the concept of the "gamesys" does not exist. In Dromed, you could completely customise the gamesys and bundle it with your mission, but in Doom 3 this does not happen -- if you changed a basic entity declaration, this would affect ALL missions that used that entity class, not just your own map (consider it as though all changes you make are written to the dark.gam file, rather than the gamesys in your own mission).

 

In Doom 3 you would to create your own entity types for your mission, in a separate DEF file, and bundle this in the PK4 along with your other resources.

[sparhawk]

Just to reinforce this, Dromeders routinely create their own stims.

 

Yes, but that doesn't mean that we are doing it the same. Specifically since there ARE differences between Dromed and Doom 3 and not everything makes sense. We are porting some of the concepts, but not the code itself. So even if we have recreated a stim/response system, that does not neccessarily mean that it is 100% identical to Dromeds S&R system. And since Doom 3 offers a full scripting langauge, you can do a lot of stuff more naturally, then using an awkward way of creating chains of commands to achieve something in Dromed, which is done in such a way only because of the lack of real scripting.

[Fidcal]

Yes but just because Dromeders sometimes used s & r to achieve effects that Dromed did not provide by any other means does not mean that they did not also use s & r as useful vicinity triggers when no other vicinity trigger would have been suitable or even work at all.

 

If map makers cannot create new stim names or at least use some reserved unused names, how will they set up a new stim/response trigger when needed? Even if a script does what they want if they need a trigger where two things come into contact, how will they create such a trigger? They will be forced into the bad practice of using an existing stim name and taking care not to allow anything else that responds to that stim to ever come into contact with it. There will always be the risk of conflict. It is not the effect that is the problem; it is needing an exclusive trigger that cannot trigger something else by mistake or indeed, the response you want be triggered by a different trigger than intended.

 

If a mapper needs to set up a situation where an effect or event ONLY takes place when Item A comes into the vicinity of Item B, then an exclusive trigger is needed - even if the effect is some simple already-provided for effect.

 

Let me recall some examples from my own T2 missions...

 

Example 1 : The player has to place an ring on a particular table. I added a new stim I named ringStim to the ring and a response to that stim on an unrendered marker covering the surface of the table. If I had used an existing stim such as fireStim then the ring might kill the player or an AI carrying a torch wanders too near the table and 'Objective Complete' displays. If I used say, an existing stim called 'frobStim' to send a signal then if frobStim is used anywhere else in the mission then there is the risk of conflict. The player or another AI brings some other item with frobStim on it near the table and 'Objective complete' pops up. Or the true ring is not dropped on the table but on or near something else with a frobStim on it and it calls a completely different effect.

 

Example 2 : An AI has to fight a winged harpy like creature with 'flight' simulated by vertical motions up three to six feet as the AI attacks with a sword. I add a new stim to the AI's sword, let's say harpyStim, and a response to that stim on the creature. As the AI's sword comes close to the creature an incremental vertical teleport offset response kicks in as the response to the harpyStim on the sword. The creature flits about its attacker in quite a realistic way. Again I cannot use an existing stim name such as waterStim or the AI might find torches being extinguished by his sword and the harpy will fly if I wet it with a water arrow. Might be fun but not what is intended.

 

So it's the exclusive trigger that is the problem. How to trigger an exclusive effect when sword and harpy come close and when ring and table come into contact.

 

If there is a serious problem with a mapper adding new names then just include some unused ones : UserStimA to UserStimX or whatever can be squeezed in (the more the better, a dozen might not be enough.) They should be easy to include. If they are not used there is no harm done but if they are not included then mappers will improvise with existing names and keep their fingers crossed. By merely adding a few names to a list you provide Dark Mod with immense extra power and flexibility to the imaginative mapper. More efficient of course if the mapper can give them sensible names - maybe even virtual names - an extra string field to help the mapper ID his creation.

 

If Dark Mod provides some other means of detecting when two items are in vicinity of each other with the flexibility and control of S & R then why include S & R? Even if Dark Mod might provide an alternate way to effecting my two examples, can it be guaranteed to do so in every possible situation that a mapper would like to implement?

[Crispy]

Personally I think it makes sense to offer some user-defined stims if we can, even when we have D3 scripting available. If only to ease the transition from Dromed.

[OrbWeaver]

I agree, if there is no meaning at the code level for the various stim types, it makes little sense to restrict them to a predefined list.

[sparhawk]

Yes. That's what I said before, and it was also planned like this. The integer is used because it is fast to compare, and stims might be used quite a lot.

[greebo]

Before I can add this functionality, we will have to agree on where to store a possible name/description of the user-created stim types.

 

Should this be the worldspawn entity (this would make the stims strictly map-specific) or should this be a newly created "atdm:info_stimresponse" entity (which could be copied, if the mapper wanted to copy some of the custom stims from another map)?

 

Third option: Don't specify a name for the new stim and just use the number (ID).

[OrbWeaver]

Aren't the current types specified with something like sr_type_STIM_WATER? Couldn't it be implemented so that the WATER part could be replaced with any text string, and responses with the equivalent type would be activated?

[sparhawk]

If I remember correctly, the namepart is either the name (if it is known), or the number. So this should already work. Of course, having a number is not really nice, so it would be good if a name could be used and mapped to a number. This could be done by DR, which could substitute the name with the number. But it would still need to store the name mapping somewhere. Another solution might be to modify the S&R code, and assign a number. We could create a block where the code can take the number from. Currently we have reserved about 1000 Ids, Up to ST_USER = 1000. We could reserve another 1000 (or even 10000) for such automatic assignments. Or we could completely ditch the numbers and always assign a number to it.

The algorithm should be simple. Whenever a name is encountered, that is not a known name, we start to use a number for it. Of course if somebody misstypes a known stimname, it would be hard to track, but with the DR interface, this shouldn't be a big problem, because the user wouldn't type it anyway.

[OrbWeaver]

But it would still need to store the name mapping somewhere.

 

Why not store the mapping internally at runtime? Presumably, the numbers are used to make comparison quicker because a string comparison could be slow, but this is an implementation detail which does not need to be exposed to the mapper. The SDK could build up a mapping between names and numbers when it loads in the map, and thereafter use only the numbers to compare stims and responses.

[sparhawk]

That was my proposal above. We automatically assign the numbers when we encounter an unknown string.

 

The only problem I see with this is, that we constantly would have to compare a lot of strings, whenever we enouncounter a string, because we can't know if this is a new one or not. But then, it depends on how many custom stimtypes are really created, and this would only happen when a new stim is set up.

[Crispy]

The only problem I see with this is, that we constantly would have to compare a lot of strings, whenever we enouncounter a string, because we can't know if this is a new one or not.

Wouldn't be that bad if you used a hashtable.

 

I think the slight performance hit is worth it anyway. You'd only need to look up one name/number mapping for each time a stim was triggered.

[sparhawk]

Once a stim is setup you don't need it. Only when you load a stim/response.

[Crispy]

True. Okay, even better then.

[Fidcal]

Without mentioning DM I've been trying to find out HERE how many new user stim names a Dromeder might need. That is, if DM went the route of a finite number of set unused names allocated to the mapper, what might be a practical limit. I don't want to encourage the fixed allocation of user name route but if taken it might not need to be that large.

 

Note also the unusual method of using a min and max intensity as a 'wavelength' so the same name could be used over and over for different tasks like a key ID. I assume 'magnitude' in DR is the equivalent to 'intensity' but is it intended that a response would respond to any value up to the set magnitude or just exclusively to that one value? Dromed has min, max settings plus no min (ignore min) and no max.

 

If the above 'trick' were available so a mapper was not completely stuck after using all user names then perhaps only 10 fixed names UserStim0 to 9 might be enough. I'm thinking of if the only practical way to provide them was in a selector list where a hundred such names would be ridiculous.

 

At the end of the day the ideal will always be for the mapper to have the option to create distinctive new names.

[greebo]

You won't have to worry about the amount, it will be totally customisable. It wouldn't make sense for me to artificially restrict the number of custom stims, so I will just let the user specify a name (which is mapped to a number anyway) for his new stim and that's it.

 

I like the idea of a "magnitude threshold" for responses, this maybe useful. I think I'll implement that.