Editing Slide delay

'''Slide delay''' is a mechanic that exists only in the MS version of [[Chip's Challenge]], and was programmed into [[Tile World]], that makes [[monster]]s and [[block]]s lag when sliding, and it can greatly alter the outcome of a level. It pertains to [[monster]]s and [[block]]s that enter and leave [[force floor]]s, [[ice]], and [[teleport]]s.

== The sliplist ==

The ''sliplist'' is a list of moving objects, blocks or monsters, that are currently sliding on force floors, ice, or teleports. Chip will never be on the sliplist, is never affected by slide delay, and, importantly, always moves before sliding blocks. Each row in the sliplist contains two elements: the object, and the coordinates of the destination square on the Chip's Challenge [[grid]].

At the start of a level, the sliplist is empty, even if [[monster]]s are currently on sliding tiles; objects cannot enter the sliplist until they make a move. When a monster or block steps on any sliding tile (ice, force floor, or teleport), that object will be added to the end of the sliplist, and when it leaves a "slip" tile, it will be removed from the sliplist. Additionally, if a block slides directly off a sliding tile onto a [[trap]] (like in [[Torturechamber]]), it will remain on the sliplist, and when released, it will slide off the trap one further square in the same direction it was sliding in.

Also notably, should only one sliding space separate Chip from a sliding block in front of him, and the block reaches the ice corner at the same time slide delay affects it, Chip will gain an extra half-move and be one space behind. Since Chip is unaffected by slide delay, he moves before the block, and [[cross-checking]] occurs.

When an object hits an obstacle, such as a [[wall]], while sliding, the impact is counted as a non-slip tile, and the object will leave the sliplist. However, after the object bounces off the wall, it is now considered sliding, and will be added back onto the ''end'' of the sliplist.

== Examples ==

As this [[glider]] begins on an ice tile, it does not count and it will not be added to the sliplist.

<div class="tilebackground-floor" style="margin-left: auto; margin-right: auto; width: 96px; height: 32px;">
{| cellpadding="0" cellspacing="0"
| [[Image:Blank.png]]
| class="tilebackground-ice" | [[Image:Glider E.png]]
|
|}
</div>

This glider, although it is on an ice tile, is unable to move at any point, and will ''never'' be added to the sliplist, since it cannot make a move.

<div class="tilebackground-floor" style="margin-left: auto; margin-right: auto; width: 96px; height: 96px;">
{| cellpadding="0" cellspacing="0"
| [[Image:Wall.png]]
| [[Image:Wall.png]]
| [[Image:Wall.png]]
|-
| [[Image:Wall.png]]
| class="tilebackground-ice" | [[Image:Glider E.png]]
| [[Image:Wall.png]]
|-
| [[Image:Wall.png]]
| [[Image:Wall.png]]
| [[Image:Wall.png]]
|}
</div>

In play, the above glider will not appear as moving in the MS version, but in [[Lynx]], failed moves can be seen, so a glider in this type of prison would be shown continuously turning left and right every 1/10 of a second.

== Slide delay ==

Every tick, which is 1/10 of a second, the game accesses the sliplist and processes them in sequential order, moving each tile from its starting square to its destination square. When an object leaves the sliplist in the middle of this processing, the table will be modified (everything after that object will be shifted up one). However, the processing will ignore this and continue to process the object at the next index; as a result, an object will be skipped. This is what is known as slide delay.

A more concrete example is shown below.

This sample sliplist contains these two objects, both of which are sliding on ice.
{| class="wikitable"
! Object !! Destination coordinates
|-
| Block at [1, 1]
| [2, 1]
|-
| Glider at [2, 2]
| [3, 2]
|}
At the next tick, the game will process the sliplist in sequential order. The current plan is to first move the block from [1, 1] to [2, 1], and then move the glider from [2, 2] to [3, 2].

However, it just so happens that after the block is moved from [1, 1] to [2, 1], it hits an obstacle and leaves the sliplist, only to re-enter at the end of the sliplist, now moving from [2, 1] back to [1, 1]. The table is currently as follows:
{| class="wikitable"
! Object !! Destination coordinates
|-
| Glider at [2, 2]
| [3, 2]
|-
| Block at [2, 1]
| [1, 1]
|}
The game ignores this and continues to process the second element; however, the second element is now still the block, and it proceeds to move the block from [2, 1] to [1, 1]. Now the slip engine is finished, and the net result is that nothing moved.

Look at the example below.

<div class="tilebackground-floor" style="margin-left: auto; margin-right: auto; width: 128px; height: 64px;">
{| cellpadding="0" cellspacing="0"
| [[Image:Glider E.png]]
| [[Image:Force Floor E.png]]
| [[Image:Red Button.png]]
| [[Image:Fire.png]]
|-
| [[Image:Clone Block E.png]]
| [[Image:Ice.png]]
| [[Image:Ice.png]]
| [[Image:Ice.png]]
|}
</div>

This will cause slide delay, because immediately when the glider leaves the force floor, it creates a block, cloned from the [[clone block]] and moving east, that starts moving on ice. Note that if it were a monster clone instead of a block clone, slide delay would not occur because a monster is created 1/5 of a second after the button was pressed. However, no noticeable effect is seen because nothing was skipped.

<div class="tilebackground-floor" style="margin-left: auto; margin-right: auto; width: 160px; height: 64px;">
{| cellpadding="0" cellspacing="0"
| [[Image:Red Button.png]]
| [[Image:Ice.png]]
| [[Image:Ice.png]]
| [[Image:Ice.png]]
| [[Image:Clone Block W.png]]
|-
| [[Image:Glider N.png]]
|
|
|
|
|}
</div>

In this example, slide delay does not occur when the glider hits the red button, because nothing is leaving the sliplist. But, when the block hits the red button, slide delay will occur, as the block that just left the sliplist cloned a block westwards that was instantly added to the sliplist.

<div class="tilebackground-floor" style="margin-left: auto; margin-right: auto; width: 96px; height: 32px;">
{| cellpadding="0" cellspacing="0"
| [[Image:Glider E.png]]
| [[Image:Force Floor E.png]]
| [[Image:Wall.png]]
|}
</div>

Above is a different principle of slide delay. Slide delay is created because the destination of the glider is always the force floor, and will always return to the sliplist. Blocks in this situation will leave the sliplist if they are [[ram]]med.

<div class="tilebackground-floor" style="margin-left: auto; margin-right: auto; width: 96px; height: 32px;">
{| cellpadding="0" cellspacing="0"
| [[Image:Glider E.png]]
| [[Image:Ice.png]]
| [[Image:Wall.png]]
|}
</div>

In the diagram above there is no slide delay, because the glider never returns to ice and will not go back to the sliplist after bouncing off the wall.

== External links ==

*([[David Stolp]]) [http://www.davidstolp.com/old/chips/slidedelay/index.html Dr. pieguy explains slide delay]
[[Category:Mechanics]]