CC Zone - Chip's Challenge Forum
bug in editor? - Printable Version

+- CC Zone - Chip's Challenge Forum (https://forum.bitbusters.club)
+-- Forum: Chip's Challenge (https://forum.bitbusters.club/forum-4.html)
+--- Forum: Chip's Challenge 2 (https://forum.bitbusters.club/forum-18.html)
+--- Thread: bug in editor? (/thread-1499.html)

Pages: 1 2 3 4


bug in editor? - mobius - 13-Jun-2015

when I wire a on/off switch to a force floor or a flame jet instead of turning off then on then off again like I'm pretty sure it's supposed to [there are wired force floors in at least one CC2 level I remember, and I don't remember this happening though I do remember something odd about that level...]

what happens is [for example on the flame jet] it turns on, then on the next press nothing happens, though the wire changes color, then on the third press it turns off, next press nothing again but wire still changes color, etc. Why is this happening?

Same thing happened with force floors, they turn direction only after TWO presses.


bug in editor? - FelixNemis - 13-Jun-2015

The flame jets and force floors change state when a wire they're connected to is powered (and do nothing when it becomes unpowered), this way you can hook them up to a button and you don't have to hold it down.

Other things like the pink toggle walls will change state when powered and when unpowered (I think). Also orange buttons change the flame jets but they change back when you step off.

If you wire up a pink button instead of a switch, then they will toggle each time you press it


bug in editor? - mobius - 14-Jun-2015

oh, that makes sense. thanks.

I kind of thought this remembering how that level in CC2 worked.


bug in editor? - Pulluxx - 27-Jun-2015

Maybe I can ask a question here too? I don't get how you place wire on top of wall blocks. Seems like I'm missing something elementary here.


bug in editor? - Joshua Bone - 27-Jun-2015

Same as on floor blocks, but only works on metal walls. Just drag the spool of wire from one square to the next.


bug in editor? - Pulluxx - 27-Jun-2015

That's how easy it was. Heh. Tongue


bug in editor? - Pulluxx - 03-Aug-2015

I thought I'd ask another question here: Has anyone else had problems with recording replays where the recorded player acts as if the dimensions of the level is smaller than they really are? In my playthrough I walk 10 paces, but in the replay the character walks 7, and after that performing the rest of it's actions like it had reached it's destination. It happens every time I record the replay for the level.

What separates this level from the other ones I've done so far and been able to record replays for is that it's pretty wide; I think it stretches to 85 tiles horizontally and about 13 tiles vertically. But I'm not sure if that is the problem. The problem in my case occurs during a long walk on a force floor track, which again, may not be the source.


bug in editor? - _H_ - 03-Aug-2015

I encountered similar problems. After I did some testing, I came to the conclusion, that after pressing a key for more than 4.2 seconds, the replay does not preserve the information of the key being active any more.

Here is a simple program, to reproduce the behavior, instead of going right 25 tiles as the character should, it just moves 21 tiles in the replay. To avoid this, you have to release the key, and press it again, as in the loop, where the replay shows the correct amount of movement to the left: Slight smile

Code:
local ffi    = require "ffi"
local socket = require "socket"

ffi.cdef [[
  void keybd_event(unsigned char, unsigned char, unsigned long, unsigned long); ]]

local s = socket.sleep
local a = {r=39,l=37,u=38,d=40}
function p(x)
  ffi.C.keybd_event(x,1,0,0) end
function r(x)
  ffi.C.keybd_event(x,1,2,0) end

s(4)

p(a["r"])
s(5)
r(a["r"])
s(0.1)

for i=1,25 do
  p(a["l"])
  s(0.1)
  r(a["l"])
  s(0.1) end



bug in editor? - breadbox - 03-Aug-2015

That's odd. 4.2 seconds is the maximum time length for a single entry in the replay data, but the replay format comes with a continuation marker in order to support longer time periods. And many replays included in the CC1 levels use it (BEWARE OF BUG, for an obvious example). It ought to work.


bug in editor? - Pulluxx - 03-Aug-2015

Quote:

I encountered similar problems. After I did some testing, I came to the conclusion, that after pressing a key for more than 4.2 seconds, the replay does not preserve the information of the key being active any more.

Here is a simple program, to reproduce the behavior, instead of going right 25 tiles as the character should, it just moves 21 tiles in the replay. To avoid this, you have to release the key, and press it again, as in the loop, where the replay shows the correct amount of movement to the left: Slight smile

Code:
local ffi    = require "ffi"
local socket = require "socket"

ffi.cdef [[
  void keybd_event(unsigned char, unsigned char, unsigned long, unsigned long); ]]

local s = socket.sleep
local a = {r=39,l=37,u=38,d=40}
function p(x)
  ffi.C.keybd_event(x,1,0,0) end
function r(x)
  ffi.C.keybd_event(x,1,2,0) end

s(4)

p(a["r"])
s(5)
r(a["r"])
s(0.1)

for i=1,25 do
  p(a["l"])
  s(0.1)
  r(a["l"])
  s(0.1) end


Thanks for the heads-up and thorough explanation Slight smile

Quote:It ought to work.


As another programmer, I can't count how many times I've told myself this Smiley. I'm running the debug build, maybe it's fixed in the public build Thumbs up.