Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

I Wanna Lockpick Editor

All-in-one Editor and Player for custom IWL levels · By L4Vo5

Bug reports Sticky

A topic by L4Vo5 created May 06, 2023 Views: 496 Replies: 32
Viewing posts 1 to 20
Developer

Bugs are icky and gross so if you find any toss them in this sticky post where they can't escape! (make sure to grab them very gently so as to not harm the bug, otherwise I won't be able to fix it)

AHH HAIRY SPIDER: negative imaginary instances of a door take away the wrong keys.

https://drive.google.com/file/d/1TeAWxdFc-qLxZRAA5mVDzNGUGaglIk2z/view?usp=shari..

Tiny side bug: we are all aware that the graphics of a door won't update unless you hit "s" twice. Not the mega bug, we can be patient.

take positive real
take negative imaginary
...right?
Blue positive blast doortake positive imaginary
take negative real

But which way is it actually supposed to go? 

https://drive.google.com/file/d/1Lgb_nCPNWNt9chXfYHiTd1a9n0gFu7M1/view?usp=share...

Developer

fixed both in 0.2.0.2

the door UI glitches out of existence when I set it to glitch

well I just found another bug...


Developer

what did you do to get the bug? it's pretty much impossible to fix bugs if I can't replicate them on my end

I have no idea, but I fixed it by downloading the zip file again

(2 edits)

The new 3.0.0 version is crashing for me a lot. I don't really know why. 

1. I tried to open a door with -i copies of itself, using a -i master key. That may or may not have caused a crash.

2. I somehow placed down a doors hitbox without the actual door??? I was really confused but I managed to remove it by placing a door where the hitbox was to attempt to delete it.

3. I got another crash... somehow. It was in editor mode somehow

4. Can you reenable zero-copy doors in the submenu and only the submenu? It makes levels easier to design, and you can just ban the placement of zero doors.

UPDATE: Okay, so imaginary door destruction actually works okay somehow most times. When the game crashes, the last image is the top row of blocks being lined up unusually well instead of scattering like normal. Maybe after cloning, the animation bugs? Maybe it's related to doors of different sizes?

I need to save my levels more.

ONE LAST THEORY: Sometimes when I place a door down, its lock gets misaligned and rendered at the wrong size.

 

I think the pure door is somehow writing its 2-tall size lock to the brown door. If the door also somehow wrote the wrong total size, the particle engine might be getting incorrect data.

Developer

let me know if you figure out how to replicate the door hitbox thing

I could do the zero-copy door thing, but how does it make level design easier?

(1 edit)

I think it would make the menu navigation easier. Whenever I want to make a door that extends in a purely imaginary direction, I try to set the real count to zero before I change the imaginary component. You can set keys to 0+0i so this isn't a problem, and locks use the checkboxes so no issue there. But when I try it on the whole door, I wind up with a negative-copied door. Being able to set doors to 0+0i in the side menu, even if you can't actually place them down, just makes more sense to my brain.

(1 edit)

um

woop

I don't know why, but the black door isn't reversing my keys. (I have 1+1i brown) What's weird is the bug doesn't always occur, especially if I go to the door immediately. 

and now it wont post wonderful

if you hold down the stop button in playtest mode and press a then let go of the stop button the keypad appears in the editor

and you are softlocked

Developer

fixed in 0.4.0.0

Why does opened blast doors sound exactly like opened normal doors ?

You can curse brown doors.

Opening a cursed Master Door still plays the opened Master Door sound.

Sometimes when you open a level the doors will LITERALLY destroy themselves. I'm not even joking.


Developer

Hmm this might have the same root cause as another bug I wanted to fix

(2 edits)


doors when you place them sometimes have incorrect lock 1 sizes, or are transparent for some reason

i think they might be claiming the id of an open gate or something


I haven't seen the transparency issue, but the incorrect lock size issue still exists.

(+1)

the undo system sometimes reopens the door immediately after you undo, it seems the undo position is still in contact with the door

also sometimes doors appear as x0 for 1 frame

come on now...

this might have to do with the gate cloning thing


also, sometimes you can open doors while viewing from the wrong axis?

Developer

what do you mean with the axis thing?

please disregard that i was misremembering a mechanic

All levels after Level 2(Level 3, Level 4, etc.) seem to be linked to Level 2, so i make a Change in Level 3, & it's applied to Level 2 & Level 4, so i effectively have 2 Levels, Level 1 & Level 2+(I know that this bug exists in at least the Linux & Browser Version(as im on Linux))

So it turns out there is an easy Work Around, when you make any amount of new levels, they all are linked, you make a change to one, it is applied to all, but if you save your level & then load it, it fixs the problem

Developer

Yeah I realized what causes this, the code for making the new level is dumb and just uses the same level every time ..

(1 edit)

ok, so, what if mod-pack/texture-pack support exists? its a neet way to make cool fan-games to this fan-game, am i right?

edit: oops i meant to post this on the feature requests thing...

The gate color can be a gate's lock color, and if you have too many gates on a level, the level will glitch out and go to the bottom right when you exit fullscreen

(3 edits)

I've got a couple:

* Lock requirements are limited to between +1000000 and -1000000. I get that door copies do this so they can use a million as infinity, but lock requirements shouldn't have the same limit - note that key counts do not have this limit. (Also, perhaps infinite copies should be a separate checkbox toggle in the editor for doors like it is for keys? If so, I don't see any reason why 1 million would have to be used as infinity. If the numbers are in floating point, floating point has actual values for Infinity and -Infinity, just use those (or, if you can't for some reason, make it some number larger than the integer precision limit, like 10 quadrillion or 1e300). If the numbers are an integer type, just use their max value. If infinite copies is made a separate toggle, the users don't need to know what that number is internally...)

* Entries seem prone to crashing. If you use level entries to enter more than two or so levels in the same session, the program crashes. (Is the editor storing all of the information for the previous level when you enter a new one? It shouldn't have to. Wouldn't just the level number and your X and Y positions you were at in that level when you entered the current one be enough information to save?)

Okay, it turns out the crashes are more prevalent than I thought. Just playing the game for long enough can eventually lead to a crash upon trying to open a door. The timing for this happening seems to be random, though I think it gets more likely the longer the program's been running for.

I found a couple more bugs:

1. Mouseover has a barrier in the y-axis that it can't go below. If you try to mouse over a door or key that's too far downwards, the info box will appear significantly further up than it should. This applies both in the editor and in gameplay. (I'm not sure whether there's also an x-axis barrier)

2. The description of the levelpack and the author/s of individual levels are not saved. The rest of the level info (levelpack name, author/s of the levelpack, names and titles of individual levels, etc.) is saved, but not those two bits for some reason.

Jumping while standing on an infinite key makes it impossible to undo to before you touched the infinite key.