Dariosky-01
commented
2 years ago Update.
Today I still examined the vertical level, I had not analyzed some things.
I would like to say that in a large level the minimum, ie 16 blocks, the initial game board is higher than the modifiable base in Foundry, I am talking about the working area for the user to change the level. The open level during the game always shows a height of 12 positions and a size of 16 level blocks, minimum size, the high limit coincides with the level limit during the game, I made some pictures and the high limit of the picture confirms it the "muncher" drawn. Always at a minimum size, what appears evident is that there is an error in the calculation of the size of the Foundry workspace if the lower part of the open level does not coincide with the lower part of the game board during active play. I have just ascertained a fact, the extra work area that is at the bottom and 4 positions down, but this is because we are only at a minimum size.
I have ascertained that the hatch size of the jump area marked as "Zone Jump" is correct if it is 15 positions long downwards, in all the jumps in all the positionable airs but it is incorrect only in one case, in the first zone, the one where the level is minimized, to 16 blocks in size. There is a reason. The fact is that each other level is always 16 for each of its added magnitudes, but this causes an error in Foundry on its exposure to the user in drawing the lowest area of the software workspace to make it truly coincide with that. visible that you really notice in the picture displayed when the game is started, and is started by trying a large level with a minimum size of 16 blocks. Given that after the 12 positions in the vertical direction of the level there are 4 other empty positions not used (because the game board, once the game is started, never goes down before its lowest starting point, but Mario always rises) in level size minimum meant 16 blocks, the 12 of height of the visible picture plus the 4 make 16 blocks, the minimum size. In the image the bushes on the right can confirm, they are the limits for each large (16,32,48). Now if we want everything to work, including the dashed jump zone, we have to consider how the jump zone works. The jump zone at size 16 being oddly high at 15 positions from the minimum level 16 causes damage, causes an empty area at the top to complete all at 16 as a total height equal to the minimum level. This lack is caused at height Y0 and row X0, so this row is totally skipped. Since the system counts another 15 positions down to calculate the jump zone, under Y31 if the level quantity would be set to 32 blocks another empty line would appear. To the next size, since Foundry counts the jump zones starting from the end of the previous one, it would be there if I set it in the window with a previous number, obviously this error is reported, so with a level size of 48 blocks I would find myself an area not hatched of 2 staves, at Y47 and at Y46, this and there are two and not three because the first is always at Y0, after the first all remain as a remainder below the last dashed jump zone precisely for the reason that Foundry adopts as start of the jump zone a position subsequent to the previous one, in practice the first jump of the first zone allocates the beginnings of the following zones, eventually causing an accumulation of space, of 15 positions not served by the jump zone, because 15 16 = 240 and the last one in the jump position 0 is the last one who completes the total of spaces to 16, one space for all the zones, 16 16 = 256 blocks.
Now this I thought is only solvable in one way. The first "jump zone" must be the dotted one, that is, that should be inside the first play area of 16 blocks is high in a different way than the other subsequent zones, it is 12 or 12 high, also the work area it should change in its height, but only in the first zone, it should be 12 positions high. The others that follow should always be 15 more positions, both in the level area and in the jump area, because this is the only way to make the base see the user inside the Foundry work area coincide with the area that opens the game started. If you look in the pictures there will be below and do the math, the best way to do this is to modify this vertical system in this way. The ground you can see in the walkable part is always the perfect position for Mario with the Y24 position setting code.
Mario's positions also need to be changed. Below I will consider only the minimum level quantity to make a comparison with the true Y positions.
Y0 = Y1
Note: It is a working position but it moves the game board up if as it happens when flying, because Mario is very high above the starting point of the game. It's okay if the game starts with 16 level-sized blocks because that effect is not noticeable so maybe it could only stay active under the condition of level-sized 16 blocks; If you change size, Mario's position changes automatically, a bit like it should happen with the setting position Y15 during the transition from horizontal level to vertical level if position Y15 is set.
Y4 = Y6 Y7 = Y9 Y11 = Y13
Note: Appears after the visible square, Mario is alive if he has a base at Y14 but there is no point in starting from there.
Y15 = Unknown point: I suspect it's in the game data because of the noises I hear.
Y20 = Y6
Note: Same as Y4 setting but Mario depicted in a different position inside the workspace.
Y23 = Y9
Note: Like the same setting of Y7, in this case only Mario's position on the work area changes but remains the same for the game.
Y24 = Y10
Salutations
I wanted to raise an issue regarding the sizes of Foundry's workspaces along with those actually used by the game, but I don't know if the game's real ones are because the game may be modified due to the Foundry's changes, making it look similar to the game original but actually turning out different.
There are facts that I want to expose.
A vertical level 16 blocks in size creates a 16 * 16 work area (all the numbers I will mention are calculated by counting the spaces by hand using the game objects in the level area, so without counting the number zero)
A vertical level set at 16 blocks widens the height making the work area reach 27 blocks in height.
Mario at position y24 always appears by counting two positions from bottom to top (it is position y24 counting from the other and counting zero "y0" as the first number)
So the difference in height between a horizontal level and a vertical level, when the level is set as size 16, is equal to 27-16 = 11. These 11 spaces, if we were to be coherent they should check as width in the vertical level, but it is obvious it is wrong I think that something else happens, I will tell later and I will say why.
Mario as I said, as I said, if set to 24Y and we open the game, with a level set horizontal it appears stationary because it is the real position. If we use the same position y24 in the vertical level, Mario's height changes, it rises together with the level, resulting at height y10, by 11 positions, therefore from top to bottom, the same 11 positions of difference in height between a horizontal level and a vertical one with an air size of 16 boocchi.
There is another phenomenon, Mario appears in the game started in another position, if placed at position y24 (actually y10 if it is set vertical) a block appears higher than where it appears if the level is set vertically, it appears at position y9, to do this if we put a floor under Mario that appears in Foundry and then start the test with the emulator he falls from a small height, moves immediately, falls from a higher position.
I was aware of all this, it seems logical that while the starting positions: "11y, 7y, 4y and 0y" with a level 16 blocks large and set vertically, do not show Mario because for the game system, most likely it appears a lot the higher the point from where Mario's position starts to count at least this we could think in any case it is always impossible to use even the position y15 under these pure conditions that appears in the editor because I have tested and it is not seen, nor if Mario is small nor if it is large.
I don't know why when the object is set, it jumps to position 0 (zero) in the first area (level size 16 blocks) when the level is set vertical, it leaves an empty line at the top, thus starting from y1 and not from the real point of start, as happens in a horizontal level at x0, moreover if I let the object jump to zero position being with a level 16 size in a vertical level, if I put an object in the lowest area to easily notice a difference, and I leave the hatch that can be activated "Jump Zones" I can see that the zone does not continue below ends at y15 and not at y16 (as human logic thinks it should be). dashed from the jump area) If I advance with the opening it seems there is an extra line, counting the first at the top with the second acquired with the size 32 blocks plus many other lines, the more blocks are added, for example with 64 blocks I will find a non-hatchable from the jump area. row at height y0 plus all the other added options of vertical level size, so if I am at 64 at the bottom, at the bottom I will find three rows of blank space that cannot be selected, the reason seems simple here, there are 15 positions of the zones, and at the at the end I will find 15 empty spaces by selecting 256 blocks, because 15 zones multiplied by 1 space have been added together are 15, and in the previous publication I had mentioned this space of 15 spaces, but given there is also zero position zone, the spaces are 16, one at the top and 15 at the bottom, 16 spaces multiplied by 16 the space is 256 but this defect is caused by the fact that the zones are 15 spaces high.
Moreover, if you don't put the "Background For Pipe Level" object, everything looks wrong, the background appears full of non-capable "Jelectros" objects with the "immersion in water" playability attribute.
To begin with it seems logical that there is to be fixed:
1) The size of the "jump zone" when the zones are applied at a vertical level from height 15 to 16, starting from y0 and not from y1 ending at y15
2) It is likely that by adjusting point 1 mentioned above Mario's position will be fixed, but as he starts counting from his ideological starting point zero y and, as Michael may have worked on a trick to make the game tweak and run at full size too. 16 blocks, I believe that a modification of the position of the Mario position number is needed when the "vertical level" setting is active so that the correct position number appears in the setting meaning a count from below, because the y position always changes at every lengthening of the vertical level but the difference in height from the lowest point to Mario never changes, obviously on condition of 16 blocks of size some positions need to be obscured to prevent Mario from going off the level and creating an error.