Aslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=262;area=showposts;start=45e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexde67.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=262e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexde67.html.zxh^Ћ.OKtext/htmlISO-8859-1gzip(.Tue, 10 Mar 2020 22:44:48 GMT0 0Ph^#. Show Posts - Madsiur

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 - Madsiur

Pages: « 1 2 3 4 5 6 7 8 9 10 »
46
Game Modification Station / Re: New bank C3 disassembly, and related docs
« on: November 04, 2016, 01:56:18 PM »
Quote from: Novalia Spirit on November 04, 2016, 12:19:28 PM
This is my attempt at restoring the relic indicators in the Equip menu, which were removed in favor of longer item names.

Nice patch! Have you made a test with white/grey icons to see how it looks instead of turquoise? I have the impression turquoise text fits well in the SFC version but turquoise icons seems to fit less well. Maybe it's just me being picky also...

As for the character name on the bottom right of the portrait, it looks good and not out of place. Good job!

47
Game Modification Station / Re: FF3us 1.1 differences
« on: November 03, 2016, 12:11:31 PM »
Thanks for the link!

Yeah I've done a bin difference starting at $C30000 on both files and I had 0 result, meaning outside $C0, $C1 and $C2 banks differences there would be nothing... unless I did my bin difference process in a wrong way.

48
Game Modification Station / FF3us 1.1 differences
« on: November 02, 2016, 09:09:40 PM »
I was wondering if there was (lost) somewhere a document with all the difference between the two FF3us versions?

I know Imzogelmo has a $C1 bank document concerning this but outside that I was curious to see the differences... I could always do a bin difference between both ROMs and dig in the disassemblies / ROM map but figured I could ask experienced people first...

Thanks

49
Game Modification Station / Re: Maps without names
« on: October 29, 2016, 08:38:46 PM »
Quote from: Xenovant on October 28, 2016, 07:17:34 PM
I don't use Zonedoctor, I don't trust it. I used it a few times and I always ended with corrupt maps xD. I use "ff3le rogue". It has its issues too, with the checksum and with the minimaps/F1 bank, but at least I can manage to keep it under control, and I fix that mess once I'm finished, or I avoid it, if I can.

Yeah Zone Doctor is less stable than FF6LE, particularly the event editor. I don't recall major problems using the map editor of Zone Doctor but maybe it depends what you edit. As for FF6LE Rogue are you saying it has problem saving compressed graphics in bank $F1 or you dislike the feature altogether?

Quote from: 13375K31C43R on October 28, 2016, 06:51:06 PM
By the way, is it a problem that Zone Doctor tends to change a bunch of data at CC/FF00?

Isn't this free event space? FF3usME does the same, I think for setting data of your ROM when you use it in the editor. It's the reason why mblock129's event patches gets overwritten by FF3usME each time you use the editor. My guess would be Zone Doctor store something there concerning its event editor, even if you don't actively use the thing.

50
Game Modification Station / Re: Zozo NPCs
« on: October 21, 2016, 12:29:58 AM »
Quote from: Imzogelmo on October 21, 2016, 12:05:13 AM
I'm simlply saying that I *could*, and knowing that I can do something is satisfaction enough.

That would make a nice patch for a complete hack. You could use a free SRAM byte with a bit set randomly on intro for 7 different puzzle solutions. You could even do 16 or more if you want. Take an unused event command and make a command C0 equivalent and chain them, only it would check the specific SRAM bit or even do if(sramByte < 0x10) branch; else if(sramBytes <= 0x20) etc... for more than 7 possible outcomes. Then you branch your NPC dialogues depending and the event for the clock the same.

I'm almost tempted to do this but I'm too lazy to fully test such a system, poor testing is my biggest flaw.  :sad:

51
Game Modification Station / Re: Possible FF6 event bug on game reloading
« on: October 16, 2016, 04:44:52 PM »
Quote from: C. V. Reynolds on October 16, 2016, 04:02:35 PM
I'm interesting in using this fix. I see two patches here, though. What is the difference between Free Moving Terra and Frozen Terra Fix?

You should use Frozen Terra Fix. The first patch (Free Moving Terra Fix) was an event modification that fixed the bug instance but did not addressed the root cause of the problem. Frozen Terra Fix address the root cause and it is an ASM fix. I made sure with LeetSketcher that it doesn't conflict with one of his fix and it probably doesn't with other bank $C3 fixes though I'm not 100% sure.

I removed the attachment with the first patch to clarify the question.

52
Game Modification Station / Re: Possible FF6 event bug on game reloading
« on: October 16, 2016, 02:19:33 PM »
Quote from: 13375K31C43R on October 16, 2016, 12:40:37 PM
Also, a couple of things. First, if you change the JSR at the end of your data-clearing function to a JMP, you can remove the RTS. Second, exactly what RAM needs to be cleared? I'm seeing different versions of this all over the place. It seems $0867 needs to be cleared, $1068 needs to be cleared, and everything in between needs to be cleared. Is this correct? If that's the case, you should set X to start at #$0800 because otherwise you're also clearing $1069 and neglecting $0867.

Thanks for the optimization tip!

In fact, for this specific bug, $0869,X to $086E,X for objects $00-$2F should be cleared but might as well clear all objects data ($0867-$1069). The specific approach would make the code longer and I think it's logic to reset everything that should be reset. So yes setting X to #$0800 is right, I somewhat calculated and came up with #$0801. It was a mistake.

 :edit: Patch removed!

53
Game Modification Station / Re: Better bank C2 disassembly
« on: October 16, 2016, 09:42:01 AM »
Quote from: 13375K31C43R on March 05, 2016, 06:46:19 PM
:edit:
Managed to decipher some more data, particularly the in-battle menu drawing scripts.

Good job! This document is a good reference. However I have to do a small observation; the line formatting of 1 byte instructions is a bit broken compared to the rest (instruction and comment shifted to the left). I'm using notepad++.

54
Game Modification Station / Re: Possible FF6 event bug on game reloading
« on: October 16, 2016, 09:31:50 AM »
Quote from: 13375K31C43R on October 16, 2016, 04:42:10 AM
By the way, the data-clearing function you devised also gets called when trying to save the game.

Yes, $C31566 is called from multiple points.  :blush:

Hooking the fix on the $C329C2 subroutine which is not called on game save seems to solve the problem. However I have an efficiency question... At which point should one sacrifice free space in a limited free space bank to save cycles? The 16-bit version of the modified code takes 18 bytes of free space instead of optimal 14 bytes (because A is 8-bit where I hook my code) and the 8-bit version would take 13 bytes. However the 16-bit loop save 8750 cycles compared to its 8-bit version. I'm unsure what to do...

Code: [Select]
; Sustain Load menu subroutine
org $C329EB
JSR fix

org $C3FFA9     ; code ends at $C3FFBA
fix:
REP #$20
LDX #$0801      ; covers $0867 to $1068
branch:
STZ $0867,X
DEX
DEX
BPL branch
SEP #$20
JSR $1566       ; previously at $C329EB
RTS

55
Game Modification Station / Re: Possible FF6 event bug on game reloading
« on: October 15, 2016, 09:01:03 AM »
Quote from: 13375K31C43R on October 15, 2016, 05:10:38 AM
Not bad! Unfortunately, this ASM fix overlaps with my "No X in Fight" patch.

Is there any space left in bank $C3 for fixes? I could try moving it to bank $C0 if there is more room there.

56
Game Modification Station / Re: Possible FF6 event bug on game reloading
« on: October 14, 2016, 04:48:34 PM »
Well I did a few tests and the save file is loaded correctly in RAM. However, $1FD3-$1FF2 get overwritten before map load by what was left in $086A. I am unsure which call to C0/6E88 is the culprit but I re-initialized the objects data ($0867-$1068) right before loading a save file and the bug is gone. The fix takes 18 bytes at end of bank $C3. Doing an init on objects data before save load shouldn't affect anything (I think) since all that is blank when starting the game (without resetting).

Code: [Select]
org $C31572
JSR fix


org $C3FFEE
fix:
TAX
SEP #$20       
LDY $00
TDC
branch:
STA $0867,Y 
INY
CPY #$0801 ;$0867-$1068
BNE branch
LDY $00 
RTS

 :edit: Patch removed

57
Game Modification Station / Re: Possible FF6 event bug on game reloading
« on: October 09, 2016, 12:04:22 PM »
Since it's part of the save RAM I was thinking maybe there is at least one case in the game where you load a game and character objects are already present on map thus requiring their position. Can't think of any example though. 

:edit: (5:00PM): Or did you meant clearing $0869-$086E for objects $00-$0F on game reset? I'm not sure when the game update into $1FD3-$1FF2 but if at game load $1FD3-$1FF2 is used to fill $0869-$086E the problem would maybe be there. I'll try to get a better grasp on all this with a debugger. An ASM solution would be more elegant than an event edit.


 :edit: (2:00PM): I came out with an event fix requiring 21 bytes in free space and modifying 12 bytes in original event. Basically I call a variance of CB/0072 at the same spot that only created objects. Then I use object $04 queue further down to call the second subroutine that show object $04 in-between its two queues. I separated its queue into two to respect the original event flow  (command E0 when object is already shown). Then I show objects $01 and $05. No FD command(s) used as filler!

Code: [Select]
CA/FDE4: B2    Call subroutine $D1F9D0

CA/FE62: B2    Call subroutine $D1F9D8
CA/FE66: 41    Show object $05
CA/FE68: 41    Show object $01

D1/F9D0: 3D    Create object $04
D1/F9D2: 3D    Create object $05
D1/F9D4: 3D    Create object $01
D1/F9D6: 45    Refresh objects
D1/F9D7: FE    Return

D1/F9D8: 04    Begin action queue for character $04 (Actor in stot 4), 4 bytes long
D1/F9DA: D5        Set vehicle/entity's position to (20, 28)
D1/F9DD: FF        End queue
D1/F9DE: 41    Show object $04
D1/F9E0: 04    Begin action queue for character $04 (Actor in stot 4), 3 bytes long (wait until completed)
D1/F9E2: E0        Pause for 4 * 1 (4) frames
D1/F9E4: FF        End queue
D1/F9E5: FE    Return

58
Game Modification Station / Possible FF6 event bug on game reloading
« on: October 08, 2016, 10:40:36 AM »
The game can freeze at wounder returner scene on emulator reload (a game reload) if you replay the Terra / Banon scene in Returners Hideout and choose 3 time "No". It seems objects $01, $04 and $05 last positions on that map is not changed (or cleared). Here is a video showing the freeze: https://youtu.be/BRpmoZQ4YVU?t=3m25s

Could that be related to $1FD3-$1FF2 that are not reset to 00 00 for characters 01, 04 and 05? Eventwise their objects are not deleted (only hidden) after the scene (except Locke). I proposed as workaround to move the call to CB/0072 further down the event right before object $01, $04 and $05 position are set (long description: http://www.insanedifficulty.com/board/index.php?/topic/8008-softlock-tell-astral-no-3-times-and-cutscene-breaks/page__p__143004#entry143004).

Was this freeze or possible bug something known?

59
Game Modification Station / Re: FF6LE Rogue CE / Zone Doctor CE
« on: October 07, 2016, 10:16:16 PM »
 :bump:
I added link in original post to Zone Doctor CE (equivalent to FF6LE CE). I now have two stable releases with most bugs created by me fixed. The editors now also allow chest expansion, using $1E20:0 to $1E3F:7 as extra SRAM bits. This allow 768 chests, but you can place 819 if you want in total.

60
Game Modification Station / Re: FF6LE Rogue CE
« on: September 18, 2016, 03:55:39 PM »
Quote from: Imzogelmo on September 17, 2016, 03:09:16 PM
I know you'd like a "no strings attached" Treasure chest data expansion, but, as an intermediate step, what if it were possible to have additional chests with the restriction that they share the same marker bits as existing chest data (as you know, the game does this anyway for chests that "upgrade" if unopened in WoB)?

This is very feasible. If two chests share the same bit, max space = max space + 1 chest (excluding those in vanilla or lowering the max space and considering them). I can see this as a good intermediate step like you say. You could even troll the player by having chests unobtainable in certain location but obtainable in another map of the said location with some map modifications. No chest wasted!

On another note, I've released version 0.4a. It fix two bugs with ROMs bigger than 32Mbit. Version 0.4 had DTE optimization and special chars allowance (like actor XX name) but it results in de-centering the location name since I think the game count 1 byte as 1 character for location names. I removed DTE optimization and special chars in 0.4a. Version 0.5 should follow 0.4a in that regard but both 0.4 and 0.4a are available for download.


Pages: « 1 2 3 4 5 6 7 8 9 10 »