Aslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=363;area=showposts;start=195e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexba27-2.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=363e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexba27-2.html.zx?h^@>OKtext/htmlISO-8859-1gzip@Wed, 11 Mar 2020 07:58:16 GMT0 0P?h^$ Show Posts - 13375K31C43R

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - 13375K31C43R

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 »
196
Game Modification Station / Re: New patch: Lens Cap Glitch fix
« on: February 28, 2017, 02:50:20 PM »
I know there's a bug with one of the NPCs during the siege (see also: this post), but it's not related to this. Is that what you're referring to?

197
Game Modification Station / Re: New patch: Lens Cap Glitch fix
« on: February 28, 2017, 02:11:36 PM »
Quote from: Lenophis on February 28, 2017, 01:59:15 PM
Wouldn't any battle initiated by NPC contact be subject to this bug?

Yes, except the only case(s) where it's actually a problem are in the White Drgn room, and whatever case(s) Imzogelmo referred to. My understanding is that camera movement prior to battles initiated by NPC contact is actually intentional, particularly in the "save Terra" and "save the Esper" missions, which are the 3-party defense missions. It's intended to provide a focus on the party that's about to engage in battle. In those cases, however, it's allowable because the maps are large enough to provide space for camera movement, not to mention the camera does move back afterward. The reason it's a problem in the White Drgn room is that the map is so small that the camera is fixed by default, so it's a problem if the camera moves because it won't move back.

198
Game Modification Station / Re: Kefka kamikaze
« on: February 28, 2017, 02:04:20 PM »
Quote from: Lenophis on February 28, 2017, 01:41:55 PM
The problem is the game checks for monster AI first, before checking to see if the party is wiped out.

Quote from: 13375K31C43R on February 28, 2017, 11:30:51 AM
One is to add a condition to the "Kefka death" animation of his script that someone has to be alive in the party
If not done properly, Kefka will just instantly die then (without his fancy fadeout).

The problem as I see it is, the whole point of the fancy fadeout is to accentuate the fact that you beat the game, except that if your party is all dead, then arguably you didn't really win. Against any boss, including (apparently) Kefka, the win doesn't count if your party is wiped out in the process, so having an insta-death animation as opposed to the fancy fadeout doesn't really bother me. In fact, one thing that happens in the video is that the wrong "game over" music is played, which could be a side effect for all I know.

Quote from: Lenophis on February 28, 2017, 01:41:55 PM
Quote
and the other is to make the animation void party annihilation.
I have another idea. Upon death, set his HP to full, and then check to see if the party is alive. If so, fancy death. That way, he doesn't insta-die, but then he'll still go through the animation if you win.

The point of voiding party annihilation is that it would make sacrificing your party immaterial as long as Kefka is beaten. Basically, the question is, if your party is wiped out by the same move that beats Kefka, should that count as beating the game or not? The answer, currently, is ambiguous, which I believe is why this weird stuff happens. Your solution basically just removes the insta-death animation from the scenario described above. I agree that would be preferable to having insta-death, but if we decide that the player can win by defeating Kefka in a kamikaze move, then this wouldn't be desirable.

199
Game Modification Station / Kefka kamikaze
« on: February 28, 2017, 11:30:51 AM »
I was just thinking about this glitch, and there are a couple of easy ways to fix it that I can think of. One is to add a condition to the "Kefka death" animation of his script that someone has to be alive in the party, and the other is to make the animation void party annihilation. Which would be preferable?

I guess a more realistic fix would be to add a condition that there's someone left alive in the entire 12-character line-up, but that would be pretty damn tricky.

200
Game Modification Station / Re: New patch: Lens Cap Glitch fix
« on: February 27, 2017, 11:13:21 PM »
Quote from: TheNattak on February 27, 2017, 09:05:30 PM
The ghost npc battles on the ghost train come to mind. I've yet to test if this patch fixes those as well, but I was hoping so as it looks just as bad as the camera can go past the normal map mask/border, I think.

I actually don't remember them in quite that way. As I recall, you have to actually talk to them to start a battle with them, and the camera doesn't move.

201
Game Modification Station / Re: New patch: Lens Cap Glitch fix
« on: February 27, 2017, 08:05:05 PM »
Quote from: Imzogelmo on February 27, 2017, 05:09:16 PM
That's awesome, LeetSketcher. Is this a general fix for all instances or does it only apply to the White Drgn one? (and no, I can't remember offhand what the others were, but there are a few).

I can believe that this is not limited to just White Drgn, but White Drgn was my reference point for the fix. It's worth noting that camera movements on maps that are actually large enough to provide degrees of freedom are unchanged (e.g. the Battle for the Frozen Esper). Also, upon inspection, $055E is ONLY used for NPC contact triggers, so anything that would make a should-be-fixed camera move for any other reason I don't know about is also unchanged.

It would be nice if you could remember those alleged other instances, but I won't hold that against you. :happy:

202
Game Modification Station / New patch: Lens Cap Glitch fix
« on: February 27, 2017, 12:08:09 PM »
Woot! Big thanks to Assassin for helping me figure out how to fix this glitch, the annoying "camera moves to your position when you fight the White Drgn in the Fanatics' Tower and won't move back" glitch! I figured out how to add a map size check on the function that moves the camera to your position, so now the camera will stay fixed. You're welcome, everyone! :childish:

203
Game Modification Station / New patch: Map Mishap Glitch fix
« on: February 27, 2017, 04:11:59 AM »
Well! Now I've FINALLY figured out how compressed data works in this game... and I've found a way to fix the map issues in the South Figaro basement clock room and the Fanatics' Tower without a Zone Doctor-like mess-up of compressed data. The issues I speak of cause tiles around the doors to go all screwy when you open a door and then enter and exit the Main Menu. The doors also stay open to boot. I've also fixed the issue in the Fanatics' Tower that causes the clouds to be visible through the open doors, even though they lead into closed rooms.

:edit: March 11, 2017
Just noticed another graphical goof, though this one's pretty tiny. There's a secret room in Mt. Kolts with a chest containing an Atlas Armlet, and a wall with a hole in it for no apparent reason. It seems like a goof because it's somewhere you can't reach, and it's mostly obscured by a platform; it looks like the wall should continue smoothly there. This was a super-easy fix to add to this patch.

:edit: March 12, 2017
Added another map fix: behind the bottom part of the clock in Zozo's weapon shop, there is a hole in the wall.

:edit: March 13, 2017
Added yet another map fix: the two black tiles in the corner of the screen in Kefka's Tower, as mentioned by TheNattak.

:edit: March 14, 2017
Added ANOTHER map fix: the White Cape chest in the Returners' Hideout can now be opened from the front.

:edit: June 24, 2017
After being informed that this patch conflicted with Phoenix Chest, I discovered that the area where the two patches conflict actually doesn't need to be altered in any way by either patch. Hence, I have done away with that particular change. If you want to revert any changes to be safe, see my latest edit on Phoenix Chest.

:edit: June 25, 2017
While I'm at it, I found another small graphical error: behind the china cabinet before the clock is wound, you can see the bottom half of the secret door peeking out beside, but not the top half. The fix isn't as simple as just adding the top half in because then it shows over the top corner of the china cabinet. Therefore, I opted to remove the bottom half of the door instead. Sure, I could possibly have adjusted the tile priority settings to show the door behind the cabinet, but I don't know what adverse effects that would have on other maps.

:edit: October 3, 2017
This actually happened a few days ago, but I couldn't report it here because Slick was down. A few bugs have been fixed, including bad fix location/size bytes in the patches. I also fixed a bug that made it impossible to leave certain tiles, including the one below the White Cape chest. Finally, the event script changes have been rewritten to use no free space, paving the way for a GBA port.

204
Game Modification Station / Re: New patch: Menu Malarky Bug fix
« on: February 27, 2017, 04:03:35 AM »
Quote from: assassin on February 27, 2017, 02:57:07 AM
- how do the $86 and $87 bitmasks in Functions C0/7CE1 and C0/7D03 work?  what are the criteria for choosing different ones?

The only values held in $86 and $87 are 0Fh, 1Fh, 3Fh, 7Fh and FFh. By the looks of it, these are related to map sizes and are used for clamping things like NPC locations to map coordinates (e.g. you can't have an NPC at (40, 8) on a 32x32 map).

Hmm... I wonder if we can use that to fix the camera problem in the Fanatics' Tower's White Drgn room...

Quote from: assassin on February 27, 2017, 02:57:07 AM
- sometimes, the direction in $087E,Y can be above 4, but apparently not when C0/5263 is called.  any idea what these higher values/bits mean, or in what contexts they are or aren't stripped out?

$087E,Y is usually used for movement direction (0 = none, 1 = up, 2 = right, 3 = down, 4 = left). It's also sometimes used with higher values, including for stuff like movement speed, but your guess is as good as mine about how that works.

Quote from: assassin on February 27, 2017, 02:57:07 AM
- there is weirdness with the Opera House rats encounter triggering:
http://mnrogar.slickproductions.org/phpBB3/viewtopic.php?f=2&t=236&p=2680#p2680

I think it's just delayed reaction. You can run into the same thing in the 3-party defense battles.

Quote from: assassin on February 27, 2017, 02:57:07 AM
or maybe it'll make things worse, as entities "occupying" two tiles at a time increases their chances of colliding.

My patch doesn't do anything if there's already an object at the destination tile, and as far as I understand the game generally does a pretty good job of maintaining this.

Quote from: assassin on February 27, 2017, 02:57:07 AM
now, even if it is the latter answer, it'd be hard to blame your patch, as the idea that an entity straddling two tiles is in both seems pretty sound to me... and it's ultimately the limited tile-based placement system that's probably at the root of things.

That's exactly what it is. For example, Locke is able to bypass the guard in South Figaro if you enter the Main Menu with precise timing because when the guard starts to take a step downward, he's treated as being at the tile beneath him as well as his current tile, and he's not removed from the "current tile" until the step is completed. When exiting the Main Menu, however, he's put back at the "current tile" but not the destination tile, which means the destination tile is open for Locke to step to, and then the tile behind the guard opens up when the guard is done stepping, allowing Locke to carry on through.

205
Game Modification Station / Re: New patch: Menu Malarky Bug fix
« on: February 21, 2017, 09:35:49 PM »
Well, I just downloaded the zip files and I can confirm they are dated February 21.

206
Game Modification Station / Re: New patch: Menu Malarky Bug fix
« on: February 21, 2017, 06:59:57 PM »
Why would I hate you?

207
Game Modification Station / Re: New patch: Menu Malarky Bug fix
« on: February 21, 2017, 06:50:25 PM »
Those might just be the reverse patches, those haven't changed. They should be dated February 21. If not, they should be dated February 10, which is when it was updated previously.

208
Game Modification Station / Re: New patch: Menu Malarky Bug fix
« on: February 21, 2017, 06:13:13 PM »
I sifted through all the maps in Zone Doctor, and I can confirm that other than the World Maps, the largest maps are 128x128.

I've also now updated the patch.

209
Game Modification Station / Re: New patch: Menu Malarky Bug fix
« on: February 21, 2017, 04:34:28 PM »
No, I already know there are some 128x64 and 128x128 maps. The Serpent Trench "3D current" map is an example of a 128x128 map.

210
Game Modification Station / Re: New patch: Menu Malarky Bug fix
« on: February 21, 2017, 11:24:32 AM »
OK, after some more digging, I actually found the REAL problem: this "extra NPC space" issue only occurs with NPCs that are moving up or left. The reason for this is that within NPC data, the game keeps track of NPC coordinates in two ways: tile coordinates and pixel coordinates, where each tile is 16x16 pixels. There's an update function that gets called to update the NPC's tile coordinates based on its pixel coordinates, but it always rounds down, so when my "NPC space refresh" function is called with NPCs that are moving up or left, the coordinates end up being one space off in that direction. I know how to fix this, but first I want someone to confirm or deny this: apart from the World Maps which are 256x256 tiles, are there any maps in the game that are wider or taller than 128 tiles? I think the answer is no.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 »