Jump to content
The Dark Mod Forums

Making things happen with the Stim/Response editor, for Noobs like me.


STRUNK

Recommended Posts

At the workshop I messed around with the Stim/Response editor, trying to figure out what one can do with it, and I found some pretty nice applications.

I made 8 different setups with The Stim/Response editor, all with different Stims and a whole scope of Responses. Make things happen on the impact of gas, fire, water, a falling object,  moss , frob, holy water and a switch/trigger. There are more "Stims" available, but thats for later worries.

The things you can make happen are numurous; you can make fire, make things disappear, make things move, start sound fx, spawn particle fx and more! .....  Try the Stim/Response editor today! : )

It's amazing: https://streamable.com/blyxp

The white pilars, aswell as the  white tile and the rope arrow (hidden inside it's pillar) have the Stim/Response attached, other entities don't: Select one of them, and there you can find the Stim/Response information; go to "Entity" (top menu) and select "Stim/Response..."

Every Stim can have any response, so the appearing rope arrow could be triggerd by the gass arrow ... or a fountain could be triggered by a fire arrow. It's up to you ... what ever you want to do.

Watch Springheels turorial on traps for an example of interaction with the Stim/Response editor:

https://youtu.be/0H9BkPED9yQ&feature=youtu.be&t=480

Questions: Ask them : )

 

Workshop2.map

Edited by STRUNK
  • Like 3
Link to comment
Share on other sites

  • 2 months later...

I have a switch that activates a mechanical device. To make sure that the player notices that something important has changed, I have positioned several lamps in certain corridors far away from the switch in question.

The current setup uses targets from the switch to activate the lamp entities. An elaborate task if you have several lamps and/or want to add additional lamps. Could this be solved via S/R as well?

Link to comment
Share on other sites

The system originally comes from Thief 2 (and probably Thief 1 and Ultima Underworld before it), and Sparhawk did a pretty good job porting it to TDM, considering he wasn't a T2 mapper so was just going by hearsay. 

The one tip I sort of remember is that if your stim is static and diffuse and it's sometimes not firing, it's sometimes better to use a proximity stim than a touch one, since a proximity stim will always trigger. 

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

Not really sure I can follow from the description how this specific task is elaborate. By the sounds of it you could speed up the task by selecting the switch, then additionally selecting one lamp after another and hitting ctrl - k to set them as targets.
 

It'd cause plenty of clutter in your editor window, but I could suggest adding a new layer for 'disturbing things' so you can hide things like this switch with its huge web of lines.

Edited by Dragofer
Link to comment
Share on other sites

I'm not sure if the above is a good application of a stim-response system. The idea behind this was to create a coherent system of reactions that would work every time on certain classes of objects, so the world feels immersive, consistent, and responsive to player actions. These seem like singular examples that are used once, so it's probably better to use scripts for that.

Edit: in Thief implementation, stims and responses are actively "listening" to each other, so this is creating a certain load on your CPU. Not sure how big of an impact this means in TDM and on modern systems, but I guess that too many custom stims and responses can be a performance problem.

Edited by peter_spy
  • Like 2
Link to comment
Share on other sites

I agree with Dragofer: if you keep your switch selected and then select a light, ctrl+k, deslect light, rinse and repeat would be the quickest way to do it.

On 1/2/2020 at 7:59 AM, peter_spy said:

I'm not sure if the above is a good application of a stim-response system. The idea behind this was to create a coherent system of reactions that would work every time on certain classes of objects, so the world feels immersive, consistent, and responsive to player actions. These seem like singular examples that are used once, so it's probably better to use scripts for that.

Edit: in Thief implementation, stims and responses are actively "listening" to each other, so this is creating a certain load on your CPU. Not sure how big of an impact this means in TDM and on modern systems, but I guess that too many custom stims and responses can be a performance problem.

For me the S/R-system was always a simplified script system that makes it easier for beginners to create effects that go above the simple "a switch causes an effect". There are many things you can do with it, that avoid scripts. Scripts are, of course, much cleaner and more powerful, but for a beginner the S/R-system is easier to learn.

Link to comment
Share on other sites

I get the feeling, as it's basically having to learn C++ fundamentals (which is not a good first programming language, according to 100% of the devs I talked to :D). Just bear in mind that S/R is more for stuff like your explosive barrel class listening to fire stim and exploding upon receiving.

That said, I was thinking the other day about something like GUI scripting system in Thief 3, where you used clauses, conditions, and actions. You could get something similar with Gherkin syntax. Such framework is very non-coding user friendly, and the code itself has to be written in such way that's highly reusable. It's probably too big of a task for a single person though.

Link to comment
Share on other sites

4 hours ago, peter_spy said:

Still, it's easier to pick up Python, Java, or other high-level language as a first one, so you don't have to worry about performance optimisation and memory management stuff.

Doom Script is a high level scripting language made specifically for idtech 4, you cannot use it to do anything else but script idtech 4 based games. So it lacks many of the capabilities those languages you mentioned have, but because of that, is much much less complex than python, java, LUA, etc, those are generic languages with, like I said, many more capabilities than necessary for games scripting, especially Python that i've heard can be used has a low level language as well.

Spoiler

 

In Doom Script you don't need to really worry about performance optimisation, this if you don't want to but of course you should learn how to create performant code, if not you will never take real advantage of the language, but IMO that comes with experience and you should not worry about that initially. 

About memory management, I don't code in Doom Script for 2 years or more now, so take this with a grain of salt but afaik, it is a "garbage collected" language, like the ones you mentioned, meaning that you cannot create memory leaks with it, or memory overflows (I never did even when I was just starting to code in it), memory is managed automatically by the idtech 4 script compiler, it was after all a language also made for the idsoftware artists to use and you cannot expect them to know how to prevent those.  

In Doom Script you just need to remember to declare what a variable is, a float (there's no int in Doom Script), even a single value like 2 is a float (2.0) behind the scenes, a string (text), a boolean (true or false), a game entity or a object type, and that's it, there's no memset, memcpy like capabilities, you can sort of manage memory yourself with new and delete, in object scripts, because of Doom Script OOP capabilities, but the memory space is managed/allocated for you, and if you forget to delete a object made with new, it will be done at game quit time for you.  Btw you are not required to use those if just making simple scripting for maps. 

Scripting maps with Doom Script, is as easy as it gets with text based programing languages, this unless someone makes a visual scripting tool.

 

 

Link to comment
Share on other sites

I learned (or re-learned) coding with DoomScript and TDM's C++ sourcecode, and I found it valuable. Maybe the best thing that makes them good for learning is just that small bitesized chunks of code can do really cool things that you immediately see in game. It's better for motivation. 

I wouldn't defend C++ as "good or fun to work with", but I'd at least acknowledge that it forces discipline early on, whereas something like JavaScript might encourage you to be sloppy. All of that said, I think Python is the best for casual programming and is probably best all other things being equal, but you don't see awesome games you want to play around with the coding for in Python. 

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

Agree. I think I do know of one old game whose engine and scripting was entirely made with python (very early python), Severance Blade of Darkness, the first game also that I saw using, per-pixel lighting, stencil shadows and rigid body physics. 

Edited by HMart
Link to comment
Share on other sites

Actually, you do have to remember about killing "threads" in DoomScript, even though they're not threads in the usual sense (as they're queued in a single line, not assigned to CPU cores or anything). And it's not like process or memory management is a disadvantage of either DoomScript or full C++; this is what languages suited for realtime applications should do.

But, for first language it's better to choose something simpler. You'll have to learn tons of new stuff anyway, and thinking about too many things at once is rather overwhelming. And it's not like writing e.g. in Java doesn't require or encourage discipline; at least if you do courses (or even use it at work), you'll get familiar with good coding practices.

Link to comment
Share on other sites

As I fiddle a bit with coding myself at the moment (doing some courses...), I have to say that Python seems as easy as it can get for a first programming language. Actually, I understand now why people think it's fun. :)

I must admit that languages like Javascript, PHP or Python encourage a certain sloppy behavior though. I switched back to C# after a while, and was kind of horrified about the need to express yourself so precisely. :D Especially the loose typing is something you will have issues with, when switching, or switching back to a strongly typed (if that's what it's called) language. You have to be much more precise with those languages. Which, obviously, makes them much more suited for tasks which require optimized programming for good performance, the way I understand it.

Horses for courses, I guess.

Edited by chakkman
Link to comment
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.

  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...