Posts: 454
Threads: 61
Joined: Jan 2013
Scorecard: mobius
13-Jun-2015, 9:56 PM
(This post was last modified: 13-Jun-2015, 9:57 PM by mobius.)
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.
Posts: 67
Threads: 18
Joined: May 2013
Favorite Pack: CC1
13-Jun-2015, 11:51 PM
(This post was last modified: 13-Jun-2015, 11:52 PM by FelixNemis.)
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
Posts: 454
Threads: 61
Joined: Jan 2013
Scorecard: mobius
oh, that makes sense. thanks.
I kind of thought this remembering how that level in CC2 worked.
Posts: 42
Threads: 5
Joined: May 2012
Favorite Pack: CC1
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.
Posts: 90
Threads: 28
Joined: Dec 2012
Favorite Pack: CC2
Scorecard: Joshua Bone
Same as on floor blocks, but only works on metal walls. Just drag the spool of wire from one square to the next.
My CC1 custom levelset, JoshuaBoneLP.dat
My 'Walls of CC1' custom levelset for CC2, JBoneWOCC.zip, containing levels based on the first 28 levels of CC1.
My CC2 misfit levels, JBoneMisfits.zip, containing 4 levels that didn't fit anywhere else.
Designer totals:
15 levels in CCLP3
52 levels in CC2
Public Apology: I'm very, very sorry about HAUNTED CASTLE, ANTARCTICA, and the endings on VENICE and THINKTANK.
Posts: 42
Threads: 5
Joined: May 2012
Favorite Pack: CC1
That's how easy it was. Heh.
Posts: 42
Threads: 5
Joined: May 2012
Favorite Pack: CC1
03-Aug-2015, 3:56 AM
(This post was last modified: 03-Aug-2015, 4:01 AM by Pulluxx.)
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.
Posts: 74
Threads: 7
Joined: Jun 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:
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
Posts: 18
Threads: 1
Joined: Jul 2015
Scorecard: Brian Raiter
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.
Posts: 42
Threads: 5
Joined: May 2012
Favorite Pack: CC1
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:
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
Quote:It ought to work.
As another programmer, I can't count how many times I've told myself this . I'm running the debug build, maybe it's fixed in the public build .
|