New 2.02 feature, paths now trigger targets! (Easier to trigger conversations.)

[RJFerret]

Grayman worked hard adding a great feature for those of us making maps which I'd like to draw your attention to, several path nodes now will trigger their targets, so you can more easily start conversations, have AI comment on their environment, cause a sound to happen, synchronize other AI to move in concert, or activate whatever you can imagine upon reaching/doing these path nodes...

 

• path_corner - triggers targets when node is reached

• path_turn - triggers targets when turn is done

• path_wait - triggers targets when wait is over

• path_sit - triggers targets when sitting anim is done, including any final turn

• path_sleep - triggers targets when lying down anim is done

• path_anim - triggers targets when anim is done

 

This should allow for greater environmental interactivity and dynamics.

 

For example, we often exploit the random targets of path nodes to have AI go different ways or offer different behaviors, to be less predictable to the player, however sometimes they'll repeat the same thing, wasting that work. In recent discussion in another thread, we realized a couple things, a path node could be made to switch, alternating between different destinations, or that random list of destinations could eliminate used routes, to add more variety. (Then when the final one is used, replenish the list.)

 

This also makes randomizing things like loot placement or objective item goals in maps even easier (sans scripting), as you no longer need trigger_once entities, just have an AI target as many path_corners as you want, and have those trigger whatever results should occur from that random outcome, easy-peasy.

 

What other creative implementations come to mind?

[Bikerdude]

Awesome.

[Springheel]

a path node could be made to switch, alternating between different destinations, or that random list of destinations could eliminate used routes, to add more variety. (Then when the final one is used, replenish the list.)

 

I'd love to read up on this...are there instructions somewhere?

[RJFerret]

For the switch: have the next path node target an "atdm:target_changetarget" entity (in targets/). That would remove the used path node from the switching path node, but add the alternative route. Same thing on the alternate.

 

For the random sequence: it would work like this, a branching path node with several random possibilities also targets a trigger_count set to the number of path targets. Each resulting route would target a changetarget entity removing itself from the branching path node. The trigger_count would fire once all branches have happened, targeting a trigger_relay to have changetargets add all the options back to the branching node. Note the trigger_count needs to have "repeat" set to "1" (default is off/0).

 

Does that makes sense, or did I describe it all convoluted?

[Springheel]

I think it makes sense...I've never used a trigger_count before, so I'll have to play around with it.

[RJFerret]

Trigger_count is pretty straightforward: http://wiki.thedarkm...s#trigger_count

[SteveL]

Nice. This technique could be used to make AI cover a whole area without repeating, but in an unpredictable order. And lots more I'd guess.

 

Edit: I wonder if this makes TDM's system of triggers and targets computationally complete? I was thinking that the only thing stopping the system being considered a complete programming language was that there was no way to do different stuff based on the state of the system (=branch down different execution paths). It's tempting to try to make a Turing machine using ai as the input and output (standard way to prove that a system can in theory handle everything that ANY computer program can).

[RJFerret]

Maybe? Although I know people create Turing machines in various computers, I have no idea what they are actually supposed to do.

The Wikipedia entry on Turing machine has a lot of words/info, but very little explanation. The simple.wikipedia.org entry designed for children isn't much better, but is shorter, heh.

 

It does define three aspects though:

1. Certain set of states, which we obviously have.

2. Infinite storage and read/write device. We can obviously provide output (hit button x times to spin number dial), but how about input/read?

3. Transition function. I have no idea what this is supposed to be. Movement of the tape/between rooms perhaps?

 

So much for the Wikipedia for children.

 

I can tell you this, since we have switches, logic gates exist, and we have conditionals. It's the infinite reading that I'm not seeing. Oh, wait a minute, unlit lights. When an AI enters a room, it will turn on unlit lights, which may also target something else (switches/branching). So they could read/respond to that state.

 

So I suppose you'd have one AI be the "tape deliverer", providing/encoding the symbols, and another responding to them in fixed ways to produce output. Does that qualify? (However I don't see the infinite part, as you'd need as many rooms as the tape is long, to be able to go to back and forth on the tape.)

[SteveL]

Yeah, you can't in practice do "infinite" in TDM, but you don't need an infinite tape for most programmes. I had in mind a row of lights representing the "tape" with different colors indicating the "alphabet" (changeable through switches, but in reality that'd just be window dressing. The real "letter" of the alphabet and the state of the system would be stored by what-targets-what).

 

I've not thought this through I admit and I'm going to try to resist the temptation to think it through for now as if I get challenged to do it I'll happily vanish for several days on the task and at the end of it I'll have achieved nothing useful whether I succeed or fail. The main purpose of Turing machines, other than being amusing toys for idle coders, is to show that some or other setup is capable of handling all computational logic. People have managed to build computers based on universal Turing machines in the world of Conway's Game of Life, for example, even though the entire universe consists of only a grid and 2 laws of physics. Mathematicians have subtler uses for them I believe, but those I don't understand.

[161803398874989]

Hold on, this is my area of study.

 

A Turing machine has two components: a tape, and a head. You also need a bunch of "states", which are exactly what you think they are, for example "currently checking if player is in this room". The tape is made out of an infinite number of squares, starting at square 0 (the beginning square, which is always blank), then 1, 2, 3, 4, etc. It goes on forever, but this is just a mathematical way of saying "we can't run out of memory", since that would complicate things. Practically we don't use the infinity of the tape. Anyhow, in each of the squares there can be a symbol, or it can be blank. Typically we use 0 and 1 as symbols.

Now, the head is in a certain state, (roughly) meaning it's performing a certain task. It reads the symbol on the tape, and then based on the symbol it read and the state it's in, it writes another (not necessarily a different) symbol on the current square, goes into another (not necessarily different) state (moves onto another taks) and either moves a square to the left or to the right. The Turing machine ends it computation when it doesn't know what to do.

To begin with, we put an unbroken string of symbols on the tape, starting from square one. This means we cannot use spaces and square 0 has to be blank.

 

An example of a Turing machine might be a machine that converts 1's to 0's and vice versa. We have states q_0 (I just awoke and haven't done anything, the beginning state) and q_1 (currently converting 1's to 0's and 0's to 1's). Now, since the head of the tape starts at a blank square (the beginning square is always blank), we need it to move to the right to start converting the input. We also don't need to do anything to the blank space, so we write a blank (we'll use the letter B ). For the state, we know the input starts at square one, so we want to be ready for that as we'll end up on square one, so we go to state q_1. Quickly put:

(q_0,B ) -> (q_1,B,R)

Mean if in state q_0 encountering symbol B, go to state q_1, write symbol B and go one step to the right.

Alright, suppose we are in state q_1 (currently converting). Say we read a 0. Then we need to convert this to a 1 (so write a 1) and go to the right to see if there's more to convert. That also means we should remain in q_1. With reading a 1 we need to write a 0. Thus we get:

(q_1,0) -> (q_1,1,R)

(q_1,1) -> (q_1,0,R)

Now, what happens if we reach the end of the input? We'll encounter a blank square, and at this point the Turing machine does not know what to do, so it quits. The end result is that all the 1's and 0's on the tape have been converted (the input had to be unbroken) and the Turing machine has done its job.

 

Does that make more sense?

 

Like I said above, the infinite thing is just so you can say you never run out of room. You can use a finite room with a finite amount of light switches as input (it's not required to be able to write blanks), then a guard as the tape head and have him move to the next object based on his state or whatever. It's probably complete. Most things are.

Edited July 8, 2014 by 161803398874989

[buck28]

QUESTION: This may have been covered, but can this new version be used with a map in progress with the current version? Or should the map be finished with the current version, before updating to the new version??

[RJFerret]

Yeah, I've never been that impressed with Turing machines I've heard about (one in Legos and in Minecraft made the "news" for example), as using a highly advanced multiprocessor computer, in an artificially limited fashion, to emulate a simplistic computing system with a fraction of the ability of the CPU of the environment seems pointless to me. I suppose people would be offended if I refer to them as Turing masturbations instead though.

But this mental exercise was not for naught. One thing I've kind of wanted with trigger systems I've set up in previous missions was a "variable" for storing/recalling info, and I now recognize that exists in several different forms. We'll see if I remember that some months in the future if I wish for such ability again, heh.

[quote name='buck28' timestamp='1404842156' post='349687']
QUESTION: This may have been covered, but can this new version be used with a map in progress with the current version? Or should the map be finished with the current version, before updating to the new version??
[/quote]

If you use this feature in your map, it will need to be run on TDM 2.02 (which you can specify in one of your map's text files). If the map is run in an older version of TDM, the triggering would not occur.

[buck28]

Thanks RJ...

[RJFerret]

Does that make more sense?

 

Like I said above, the infinite thing is just so you can say you never run out of room. You can use a finite room with a finite amount of light switches as input (it's not required to be able to write blanks), then a guard as the tape head and have him move to the next object based on his state or whatever. It's probably complete. Most things are.

 

Yes, a lot more sense thanks, and considering I'd googled for some other examples/info/"how to" unsuccessfully, I'm very appreciative.

 

I agree it's complete, but would up the "probably" to assuredly, and I believe there would be multiple different manners in which that could be tediously designed.

[SteveL]

QUESTION: This may have been covered, but can this new version be used with a map in progress with the current version? Or should the map be finished with the current version, before updating to the new version??

 

You can just upgrade now and continue mapping, including making use of the new features. No need to do anything special, if we did our job right

[RJFerret]

Thanks RJ...

 

You are welcome, and I just double-checked, this line goes in your "darkmod.txt" file with your map, if you have used these new capabilities and your map would be broken without their availability:

Required TDM Version: 2.02

With that the map would be prevented from running in TDM versions 1.01 (when the version check was added) through 2.01.