A bug that occurs during the movement of objects already modeled or moved in groups

[Dariosky-01]

Salutations

There is a problem, as specified in the title, which occurs on elongated objects, single creeds, but of the chosen size (beyond the single block) or more elongated objects, positioned in the drawing you want in the layer, and moved in groups, a simple example would be to think all the selected layer using hotkeys, moving everything. The problem is easy to find in this context of movement of the whole level. When for example you move the whole level and move upwards, you are strangely not stuck in this context of situation if at least object were placed in the highest position i.e. at 0Y, so if you drag everything upwards, the whole level becomes thinner by massing all, if I were to bring perhaps the lowest visible point (an object set at 25Y during the command select all active) to height 0Y, perhaps I would get a bunch of objects piled up in a single row (0Y) this is certainly an unwanted effect, because it is a phenomenon that destroys all the level designer work very easily, it is a bug that must be eliminated by blocking the possibility of advancement by making this happen. I believe that the only way to avoid this would be to give an attribute to the "select all" command (CTRL + A) which avoids automatic modeling (blocks it), if instead it is not "select all" active but only a few objects are selected with the pointer it should always be locked at least the drag (which could go upwards ends) ends and the command is given with the pointer "model" using the arrows appear in the object inside the layer. I believe towards down beyond line 25Y this effect does not happen but it could be an illusion, as it could be true for the first 16 Blocks of level size and do the same effect beyond 16X, this because the vertical size could coexist together with the level set horizontal but it could only be no more than 16X because a vertical level, as we know, is 16X wide but it is as long as possible therefore 240 Blocks.

Update:

I was able to ascertain that this defect manifests itself banks in the left edge of the level, most likely it would also do it towards the right but since the level has been limited to 240 blocks to avoid errors it should not happen, only that if an object ended up inside that area it would cause an error equally even without opening that area, so moreover there is to limit the right side border on 240 blocks like the left side border in the initial leftmost part of the whole level.

I also ascertained that it is a problem that already originates from Michael's Foundry version so as soon as the current version 0.5.0 is corrected as the software in its normal version should be the defect will appear, currently the defect is another in this new ver. 0.5.0: If you select everything and click on an object when all inside the layer are selected, the multi selection disappears and only drags the one you touched.

[TheJoeSmo]

While you mentioned that the effect of the objects being forced to their respective minimum or maximum, you never specified what ought to happen. Should the items be deleted? If only part of the object should be cut off, what should the object do? Likewise, how should this operation be shown to the user: If you move the items up one and they get deleted and the user returns them to their original state, should the generators be different than they were? And if not, what ought they do to return to their former state? For this, I believe a gif should display how the generator should be displayed, or at least a series of images, as it is quite cumbersome to write or read such specific descriptions.

[Dariosky-01]

I have already said everything, I have not omitted anything, it is understandable that you may not have understood something but I will address all the problems as well as those that were initially unclear even to me before the title "update".

If the whole level is selected and brought up all the objects pile up do not disappear, so what was long (in height) will shrink to become a block if an object is for example an x-block enlarged by 10 blocks in long and broadly forming a square of many x-blocks (10 10) this will shrink only in height resulting in an object 10 m wide but 1 high, if there were 2 objects x-blocks long and 10 wide then two objects 10 10 one exactly on top of each other by pushing these upwards both will come to be one above the other always resulting in a wide (extended) 10 x-block and long (tall) 1 x-block object (and they will join, because this is a other defect to fix)

This stacking also happens in the level in column 1 where the extreme left row of the level exists and the positions Y0X1, Y1X1, Y2X1 etc. exist ...

Bringing the whole level down does not seem to understand this effect.

since it happens to the left of the level, for logical reasons I think it does, at the most extreme point on the right, but it might not happen in this new version for two reasons: Because the level editing area has been reduced in size to 240 (the reason we know, to avoid errors in the game being started) this reduction from 256 blocks in size to 240 is a false reduction in reality, it is a palliative solution, in the sense that the ability to act to the user to select 256 blocks in the options has only been removed but the real size of the level is always 256 blocks, the maximum one, if we could access 256 blocks on the far right line again, the same thing would happen at the top and in the extreme left line, currently since it is possible to force the hand to fate by bringing objects into that area intentionally blocked by the user, we should make sure that when the user moves an object or more objects towards only this area (between the 16 blocks are in the difference between 240 blocks and 256) once passed there forcing the hand to fate, if the object is unique or a multitude are selected of objects, every object passes in that zone is eliminated if the single object or many objects are deselected and at that moment they are in that zone.

I believe that the same effect I am talking about in this publication, again for logical reasons, should happen even if we bring all the objects to pile up in the lowest line during the level set as a level vertically in the low line if only the size 256 blocks could be set , but since it happens down there the same as what happens with the horizontal layer between 240 and 256 level-sized blocks then also down there the objects should disappear once deselected.

To return to the main problem of the bug mentioned in this publication, it would be necessary, as I have already written in the publication, that once an object or more objects have been selected they must remain locked in their extension functionality, and make the extension functionality available again only when the double arrow is displayed in the pointer which suggests it is possible to extend the object, but during the dragging the functionality must remain blocked, as the spaces between the different selected objects must never change, during the multiple selection of the objects and the enemies must like create a logical image of the positions and must block the possibility that they can approach each other, perhaps a method would be to cover the spaces of the minimum selection frame with invisible blocks it can be created with all the objects at the extremes "in all cardinal points" (I mean that if I have an x-block in position x1y0 and another in position x3y2 solt anto in spaces: "x2y0; x3y0; x1y1; x2y1; x3y1; x1y2; x2y2 "empty spaces should be created to avoid that they, even if blocked in their lengthening, are all a single block to the software avoiding the drawing of the level from misaligning)