A guide to simulating multiple instances in kismet.

  • The problem that requires multiple instances in kismet usually only arises when there is a delay involved somewhere (usually multiple places) along the line. The following structure in kismet separates the delay from the actions being performed at the cost of timing precision.

    This can almost always handle as many players/pawns that you can throw at it.

    The 3 main structures in here are:
    The input event in the top left.
    The control loop in the bottom left.
    The action loops on the right.

    The control loop at the bottom is set to a desired time interval and once fired all action loops are executed, starting at the bottom. Players/Pawns are dumped in at the top and at each successive time interval are dropped down 1 action loop.

    In this example I have the time interval set to 1 second. So I have access to the player/pawn at 0/1/2/3/4/5 seconds after the event.

    You can change the time interval and number of action loops so that you have access whenever you need it. For example 0/10/20 seconds after the event with a time interval of 10 seconds and only 2 action loops.

    The input event can be anything you need it to be as long as you have access to the instigator. You then dump the object along into the top of the action loops and add 1 to a counter in the loop letting it know that there is 1 player/pawn awaiting actions.

    The controller section makes sure that the loops are only running when there are players/pawns in the action loops. The first comparison is a safeguard to make sure that the delay is not fired while the action loop is in progress. (This part is actually ineffective and needs work) Both outputs set the control loop to execute 5 times (this is always equal to the number of action loops.) EDIT: Set the integer labeled [Number of Loops] equal to the number of loops you have PLUS 1. That will cover any edge cases that might break the structure.

    This is the very last loop at t=5 seconds. Kismet comes in from the control loop and immediately checks if there are any players/pawns awaiting action in this loop. If there are, it accesses them, performs any required actions at this stage, removes them and decrements the awaiting players/pawns integer. If there are no more, it jumps up to the next action loop.

    In the next loop up the only major difference here is that when a player/pawn leaves this loop, he is added to the next loop down and the number of awaiting players in that loop is incremented. All action loops except the very last must drop the player/pawn into the loop below it.

    In the very first loop, the only difference between the loops below is that the player has been added in from the initial event and the counter has been incremented.

    I used this structure to have anyone who strikes a peasant take 10 damage over 5 seconds. You can use it for anything else that requires “multiple instances”.

    Some notes about using this:
    This is a computationally heavy solution to what can usually be solved easier.
    Players/Pawns can be entered into this structure multiple times. Whether this is a good thing or a bad thing is up to you. But disallowing this makes this even more computationally heavy. (When a player triggers the event, check if theyre in an Exclude ObjectList, if they are not then pop them into that list and then take them out on the last action loop)
    The time interval must allow all of the action loops to execute. Do not set your time interval to something like .0001 seconds.
    This structures timing is not precise. When you trigger the event, depending on whether or not you were the first to start the control loop, it will take anywhere from 0 to [your set time interval] seconds for the first action to occur. You can lower your time interval and add more action loops for more precision at the cost of more computations.
    Do not put delays into the action loops. All timing must be based on the time interval and picking the appropriate action loop.

    I hope this helps anyone who ran into this particular problem with kismet.

  • for another example on a similar theme - control loops and action loops - have a look at the kismet for my duel map.


    hard stuff though

    yeah no Delays anymore
    and .0001 I’ve noticed this is issue also in matine cuz it won’t interpolates well then or sth

    golden rule of UDK: the closer to 0 the more magic will happen :D

    I’ve favourited this url link in my UDK guides collection :)

    btw: it seems I won’t need any tutorial after all,
    boats will be ultra intuitive, am reworking now xD

Log in to reply