266 replies to this topic

[XMSB]

I do have my thoughts about the removal of the screen and map flipping. If anyone actually intended to make a vertically or horizontally flipped version of an already existing overworld, dungeon, or interior map, then they would have to use RC4 or lower since they wouldn't have this option in the next build. So I honestly think you should have kept those features, not to mention, I don't mind re-tiling the maps, or rearranging a few combos after flipping the map and/or screen.

Edited by XMuppetSB, 27 September 2012 - 12:55 AM.

[HylianGlaceon]

I found a few minor bugs again.

#1 - If the Roc's Feather, (or any item in that class) is my current item when I save in my quest, when I continue it'll be switched to whatever item is to the right of it. I tried it with "Can Select A Button Item on Subscreen" Quest rule and without, it still does it in both A and B slots. It only seems to do this with the Roc Item class. I'm not sure if it's due to how my subscreen is set up or something, but I thought it's worth mentioning.

#2 - I don't know if it's just my quest, but when I have the same quest rule listed above on and just the Sword in Init Data to start with, it'll be on both A and B item slots. Once you collect a Rupee, it goes away and sticks to one Button oddly enough.

#3 - If you jump left or right with the Roc's Feather and slash with the sword while in the air, Link's sprite goes a little over where you can see 2 Links.

That's it for this time at least. I'm glad to see the other ones I reported got fixed too!

[aaa2]

I think I see how you are going about that now. It's starting to get complicated as there are possibly three separate issues there. :\ I'll try and debug it on Tuesday, when I get back home.

I managed to get my script code working afterall but by doing that i found out which bugs there are:
1. DrawLayer does not grab Layer 6 in the same way like it did not grab layers beyond Layer 0 in RC3.1
2. DrawLayer is unable to handle Combos with mutiple Csets on one Combo(aka. the blue box next to the solidity box)
3. DrawLayer seems to smear garbage anywhere there transparency down to the lowest layer.(that could be a drawbitmap effect though i dont know)

This should be all i guess

Edited by aaa2, 29 September 2012 - 03:27 AM.

[ShadowTiger]

I would actually be glad if you removed those. They once ruined my quest when I triggered them by accident. Thank goodness for backups!

Though, technically, if you had triggered them, wouldn't it have ameliorated the situation if you had triggered them once again? It would have flipped everything right back to its original position. If it didn't, then no wonder it's buggy and was removed.

My thoughts is that its removal not really that detrimental to the ZQuesting process. If you had copied and pasted a screen, then flipped it, it doesn't change the individual combos to their visually mirroring partner combos. It just moves the combos that are already there across the screen. It still looks awful until you at least ctrl-click the new combos into position from the combo page, which is still time-consuming. Not as time-consuming for the 1x1 combos that don't have a mirroring direction combo, such as cliffs or dirt/lake/dense-trees sides, but it still takes time.

I'm still alright with it. I never once used it. A little bit of mental math is more than useful for exercising brain muscles in counting tiles to see where to put matching elements of a screen.

[Saffith]

Yeah, doing it again didn't completely reverse it, and undoing it was even worse. I'm quite certain that's the cause of the warp destination problem a few people have had.

[MoscowModder]

Yes, once I figured out how to undo it, all of my warps were still messed up. Thus the desire to see it removed.

[Xenix]

Okay, so freeform combos will work properly in the editor and when they hits the changer in preview mode, they change to what was specified, but when I go to view them in the player, they act as if there are no changers and completely ignore them.

Edited by Sepulcher, 29 September 2012 - 12:10 PM.

[Jared]

Woah, I actually broke Zquest. :o

I went to Leech when Grabbing tiles, put "8-bit", and put "0" in the box. Then clicked okay, and it crashed.

[Orithan]

Woah, I actually broke Zquest. :o

I went to Leech when Grabbing tiles, put "8-bit", and put "0" in the box. Then clicked okay, and it crashed.

Sounds like that there is a divide by zero error somewhere in the coding.

Also, the bug where the Screen-> properties menu randomly pops up and continues to do so until I click out of the program in classic layout is still there (and has been from at least build 1194). Is there anything new on it yet?

[Saffith]

Also, the bug where the Screen-> properties menu randomly pops up and continues to do so until I click out of the program in classic layout is still there (and has been from at least build 1194). Is there anything new on it yet?

This is the first I've ever heard of it, so no.

Also, there is no Screen->Properties, so I don't know which one you mean.

[Orithan]

This is the first I've ever heard of it, so no.

Also, there is no Screen->Properties, so I don't know which one you mean.

Screen->Properities is the menu with all of the flags and settings for each screen (or is that Screen->Data instead?)

[HylianGlaceon]

I don't know if I'm doing something wrong, but the neck sections of the Fire Gleeok aren't working properly in my quest. For some reason it's using tiles from the body for it, even though it's set properly as far as I can tell. I even loaded a couple tilesets and the tiles were set up the same as I had them. I haven't even modified the Fire Gleeok before, so it would still be set up the same as it was in the PTUX Tileset.

The regular Gleeok works fine with the neck sections however.

EDIT: Also, the number of heads seems to be off. I'll set it to 2, and it'll have 3 total.
EDIT2: Actually, nvm the first edit, the graphics are just really screwed up. I think the number of heads is right.

EDIT3: Also, you remember that Armos bug I mentioned with the Walkthrough walls? I got rid of the Armos combos on the other side and the room still crashes when I walk through that wall at times which makes me think something else is the problem with it.. I can give pictures or send a quest file if that helps. It's being a real pain..

Edited by HylianGlaceon, 02 October 2012 - 08:17 PM.

[Gleeok]

I managed to get my script code working afterall but by doing that i found out which bugs there are:
1. DrawLayer does not grab Layer 6 in the same way like it did not grab layers beyond Layer 0 in RC3.1
2. DrawLayer is unable to handle Combos with mutiple Csets on one Combo(aka. the blue box next to the solidity box)
3. DrawLayer seems to smear garbage anywhere there transparency down to the lowest layer.(that could be a drawbitmap effect though i dont know)

This should be all i guess

Nevermind. Should be fixed in a bit. Thanks.

[edit] Not sure about the transparency thing though.

[aaa2]

Nevermind. Should be fixed in a bit. Thanks.

[edit] Not sure about the transparency thing though.

Hmm how to explain it best. I made a custom scrolling script that also has automatic shadows incorporated, however if anywhere there is a place on one of the two screens it scrolls inbetween where there is a transparent spot that is transparent for layer 0-6 then while scrolling at this spot(can also be a nearly whole screen) random garbage is being smeared. The same behaviour is also visible in the testquest i pm'd you some time ago if you want to check out what i mean. It's not that bad though so if you can also forget it if you want.

[Moosh]

Why's there a GetDMapScreenD() function but no GetDMapScreenState() function in ZScript? Just curious.