egomassive's Knytt Stories Plus mod

I'm well aware of that (though in what level does Juni meet a human? I must have missed that one); I have notes jotted down for a potential level based on that theme - including questioning how in a certain story Juni is rescued from a desert island via a human bird-machine even though we, as a species, no longer believe sprites, pixies, fairies and so on to exist outside of fairy tales*.

I feel though that numerals make a good compromise between something legible for the player and the logography that the knytts of KU interpret from our letters (the way they see 'U' as a cup and 'J' as a hook and so on). I meant to say that Nifflas seems to have felt the same since (if memory serves) he used Romand numerals himself in KU. I'd say Roman numerals more obviously represent quantities than numbers do since numerals depict the quantities pictographically while numbers are just symbols, and thus numerals would be easier to interpret as quantities to a creature unfamiliar with our writing.


*

Ah, good point about roman numerals.

in what level does Juni meet a human?

Ohh yeah, stupid me. I was thinking about it even as I wrote that post, too, because it's one of the best pieces of evidence we have regarding the scale of knytts to humans. Clearly my brain was not working well yesterday.

I like this version of the gold blocks, but I worry that they're too flashy compared to the key blocks. I could take out the creature and center the numerals, but some of them are of odd width. The creature obscures that some of them are off center. Also the creature really drives the connection between these blocks and the golden creatures.

Also the creature really drives the connection between these blocks and the golden creatures.

An alternate way to suggest this connection would be to use the same colour palette as the golden creatures for the whole sprite, and have the locks give off the same sparkle particles (maybe with something like an occasional diagonal shine animation). Then you could experiment with removing the creature from the design.

I might try to contribute some designs of my own at some point, assuming that wouldn't be trespassing on your domain.

For me, ensuring that the player is able to understand the connection between the golden blocks and golden creatures is more a part of the level design (forcing the player to cross up/over/around golden blocks that would later be unlocked on the way back).  I would definitely appreciate a better way for players to tell how many creatures they need for a specific block, but I feel like putting the creature on the block itself is a bit too visually busy compared to the general simplicity seen in KS art.

@Sergio: I like the idea of a shining effect. I don't mind at all if you try your hand at it.

@Ultigonio: I agree about the flashiness of all my designs thus far. It's hard to match the simplicity and understanding of a key and a key-hole. You make a good point about leaving the connection between blocks and creatures up to level designers. My philosophy is that I'm catering to the rank amateurs, be they designers or players. I should have a little more faith in the masses.

Something I've noticed, and this is true for both KS+ and the original game, the invisible block in bank 16, object 14 actually adds color to the game. This is true of every invisible block that has the lines through it indicating that creatures can't get through it as well as Juni. So the effected objects are: bank 16, object 14 - 16, 19 - 28. 17 and 18 are not effected. And the invisible block that allows creatures through it but blocks Juni bank 16, object 13, also does not change the color.

It adds 1 point of blue to the color in a 255 RGB color scale.

Original blocks to the left, then where the invisible blocks were placed on the middle, and how they are rendered with the invisible blocks on the right.
The red was not part of the original image, it's just to show where the color changes from the invisible block adding 1 Blue point to blue on the RGB scale.


1000x zoom on a single tile-sized cross section of the black side. True black on the right (#000000) and very, very dark blue on the left (#000001).

I've only begun to notice because I've taken to using invisible blocks to construct the level so that I don't have to use a tileset if I just make the entire screen by just painting a gradient and adding flourishes to the screen with the tileset. It's easy to be unnoticeable if you don't use zoom, and also if the tiles you use it on are not surrounded by the same singular color. This isn't necessarily something that needs a fix as 99% of people will never notice it but I just thought I'd point it out because it does cause some things to look strange with 3x zoom. Also, if anyone else was seeing this and thinking there was something wrong with the way the picture is being rendered (I tried repainting the gradient like 3 times to fix this until I noticed it was only where invisible blocks were placed).

For the most part "Invisible" blocks are simply nearly-invisible graphics that are drawn into the background and collision mask. Unfortunately the underlying program, multimedia fusion, does not have an option to draw only to the collision mask, and it treats pure black as invisible by default. Using #000000 and an alpha channel would not work in this case.

The other objects you pointed out are not drawn into the collision mask or the background. They reside invisibly on screen as objects. The creatures in the game are hard-coded to obey the specific invisible block that blocks them, in many cases on an individual basis.

I've released a new version.

Get KS+ 1.1.9

This has new versions of Golden Creature blocks. It also makes attachments and overlays work together the way I thought they did.

I like the new Golden Creature locks. The attachments and overlays changes have caused me to have to fix a few things and sadly irredeemably ruined my layering in a particular screen, but I guess it makes more sense overall now.

I was wondering, would it be possible to have an object that blocks all user input except for the 'down' key? It would save scrambling to correctly layer 'no climb', 'no jump', sticky', 'sign' and 'shift' blocks during ingame cutscene conversations.

Sorry about that Talps. Normally I would be hesitant to make such a large change to something established. According to my memory and the documentation it was supposed to work the way it does now. Even for the conversion of Healy's little level I had to turn layer 2 into custom objects in order to put it behind the player.

I had considered making a combintion object that acts as sticky, no-jump, and no-climb because they are often used together. I didn't because I felt the advanced signs, timed shifts, and hide-shifts would eliminate much of the need for these situations. Granted, some of these can be rather tricky to use. You can usually remove the climb power at the beginning and return it at the end if you know for certain that the player has it, but this is only necessary if there is the possibility of being in or near a wall. ... For simplicity's sake I ought to just make the combination object.

If there are two shifts on a screen with a timed shift and you move to a second untimed shift after being on a timed shift, it seems to combine the shifts together occasionally, but in such a way that seems based on the timing of when you leave the timed shift and enter the untimed shift's area. Also, both of the shifts are being used as a shift on touch.

To explain further, I had two separate screens that are the same except one has a laser and one does not. This is before the feature of shift saving, so to create "fail states" I was using a shift that goes to a further duplicate that would have an animated death screen based on using the relative placement of a trigger. So you would shift from being "hit" with the laser into a death scene. The laser itself is just a separate shift. But initially to have the laser be an obstacle rather than a wall, it turns on and off in intervals using timed shifts which push Juni back and forth through two screens. Except the area with the laser shifts Juni into the death screen instead. The problem is that it seems to combine the shift-on-touch timed shift with the separate shift-on-touch untimed shift. So if I want the the untimed shift to go ShiftXMap(A)=2 it will actually shift 3. And the only thing I can think that's making it happen is the that the timed shift is saying ShiftXMap(B)=1. If I test level directly onto the Shift A it will work, shift to the death screen and sometimes the timed shift will not result in this error, the unpredictability of it makes me think it can only be the timed shift. On other screens using ShiftXMap(A)=1 and ShiftXMap(A)=-1 ShiftXMap(B)=1, The negative 1 sometimes wins over the B in this case and doesn't add them together but it just becomes -1.

I've also experienced screens that appear to be correct but the geometry is wrong, like it's showing me one screen but the collision masks and the shifts are of another. I've also seen the opposite where I've shifted into void screens only to have a shift suddenly work and then I'm out of the void screen and into the screen I was supposed to have shifted into in the first place. And this has also happened when exiting a screen that uses a timed shift on touch back and forth between two screens and when leaving either screen using a warp, though this is much less likely to cause an error, I do believe it can and I believe that it's, again, caused by using a timed shift-on-touch in a near screen encompassing manner or simply having the timing be very close to another shift's activation when it's shift-on-touch.

I've also found that it finds certain shifts more acceptable than others, in the way that it is removes likelihood of the error if instead of having the final "death" shift screen X=3 if you put it below as Y=1, it doesn't seem to add them together. But even with using a shift of Y or X instead of Y with whichever one of the timed shift-on-touches are originally using there are some strange results with the second shift that results in the death screen. Sometimes aspects of that shift-on-touch will not activate, if it says "stop music" only sometimes will it stop music even if it shifts to the correct screen. As if maybe the other shifts are retaining the aspect of the timed shift-on-touch while still using the other shift-on-touch to tell Juni where to go.

In general I'm just finding timed-shifts used anywhere near other shifts and even warps have really unpredictable results. Granted, they're probably not supposed to be used this way and the save-replacement shifting can produce the same results but I created a lot of content for these timed shifts already. If you need me to upload what I have my level to show you what's happening, I will. Though it's really hard to get predictable reproduction of bugs when it comes to this problem.

Screw it, here's the level: https://www.dropbox.com/s/3jzfb7wwe5eb1gt/plural%20-%20The%20Empty%20Planet.knytt.bin?dl=0

On x1053 y1037 is the easiest way to see the error because it reproduces most easily. Shift B on that screen is supposed to shift X=2 but it will Shift X=3 into a void screen many times upon exiting the timed shift's area of Shift A, into the Shift B area. If you "test level" starting inside the Shift B it will work correctly, but if you test the level outside in Shift A then go into Shift B, it will, more often than not, in my experience, go into a void screen.

That is a very complex post. I will look into this issue using the level. I'll tell you in advanced that some shift functions only activate once per overlap, and there are some functions won't activate if you are touching another shift. It's to resolve conflicts where adjacent shifts have opposing instructions. It's aimed at a scenario where you cross the first shift, it activates, you touch the second shift while still residing on the first, the second shift activates, you turn and cross back over the first shift, it has already activated while being touched so it does not activate again. These features are also dependent on shift-on-touch activation.

That explains why sometimes the "stop music" effect does not work occasionally. I imagine it's because it's probably the only thing with opposing instructions within the two shifts, aside from the distance in screens. This isn't like a huge deal because I've pretty much resigned myself to either fixing this with redundant screens or just scrapping the idea altogether. But the way the shifts add into each other really made my brain fry trying to figure out what I was doing wrong, I initially thought I had just put too much stuff into the level and it was imploding or something.