øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=278;area=showposts;start=420e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index69d6.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=278e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index69d6.html.zxÅåg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ0P.ÓOKtext/htmlISO-8859-1gzip8:ÖÓÿÿÿÿÿÿÿÿTue, 10 Mar 2020 19:25:16 GMT0ó°° ®0®P®€§²ð®Äåg^ÿÿÿÿÿÿÿÿ·(Ó Show Posts - chillyfeez

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

421
Ah, yes, escape scenarios... This does provide the possibility for one of those, doesn't it?
I don't (yet) have any plans for an escape scenario, but I may be able to work one in down the road...
Actually, as I'm typing this I just realized that I was planning on an escape scenario, the original concept of which did not have a timer, but now it absolutely can!

422
So I've been getting sidetracked from the main game again, working lil goodies in there for later use.
This time, I developed an on-screen timer that counts down. The timer appears when flag 128 is set and disappears when flag 136 is set.

Click to watch the video!

If you're wondering why Tellah is in the video, I haven't actually worked it into TfW yet. I knew this would take a lot of assembly, and I didn't want to mess up my hack before I knew it was going to work. Also, this only shows the timer in action. I haven't worked in anything yet that actually sets the time (that 4:00 was set by hand) nor anything that happens when the timer reaches zero. Still, the hardest part of it has been realized!

423
You're exactly right about how the multiplication works. It's probably important to note that this hack also involves a lot of base stat/level adjustments to work right. What's nice is that once you've found a good balance, if you want to make a monster generally easier or harder, all you have to do is adjust their base level up (for easier) or down (for harder). I don't know exactly how things work in FFVI, but in IV, the only thing that a monster's level impacts is how difficult it is to steal from it. With VI, at the very least, I imagine you'll have to deal with the unreliability of level-based lore magic...
Actually, now that I think about it, isn't there a monster ability in VI that lowers player level for the duration of the battle? Maybe I'm just making that up. It's been awhile since I played the whole thing through.

424
I just commented on your thread over on RHDN with some other info about NPCs, too (saw it there first).

425
Final Fantasy IV Research & Development / Re: Mapping Questions
« on: June 29, 2015, 06:25:42 PM »
Somewhere on this site, Grimoire and I pondered this one. You seem to have gotten some of the ones we hit on, and a few we didn't. Another big one you didn't mention is the Tower of Bab-il crystal room. The map is complete (has a back wall and full detail throughout) but the player never sees north of the eleventh row or so (under normal circumstances, because of the trap door event). You can blank the whole top half out and save somewhere around 300 bytes (yes, bytes, BTW).

As far as the way the data is written affects the amount of space used, you get, essentially, one extra byte for every consecutive tile of the same kind. So adding the extra trees in Baron saves space because you're normalizing the path (and the secret area?) With the rest of the map.
The map data is written out tile-by tile from the top left to the bottom right, except it has the ability to say up to "255 of" any given tile. So instead of (for example) "trees, five of field, ten of tall grass, three of secret passage, fifteen of trees,"  you made it so it just says "thirty-four of trees." The former requires nine bytes. The latter only requires two bytes.

426
Yeah, it is...
In FFIV, normal NPC movement is limited to walking in random directions. The only way to make the one ninja repeadly attack the other ninja was to put in a bunch of event triggers, and in FFIV the player gives up control during events (except control over text windows, of course. I tried to make that event quick enough that it didn't really interfere with gameplay. I know, it's still a little annoying. You start trying to memorize where the trigger spots are so you can make it not happen, and will even take four extra steps to avoid them.
But, it's only the training room, so I don't see it as a big deal.
Incidentally, if you opt not to steal the "epic choices" guy's treasure, those ninja jumping events will stop when he finally gets around to rewarding you for your patience.

Originally, I just had the jumping ninja running back and forth between the two spaces in front of the "limit break" guy, but that plan would invariably screw up his position when you ran the Limit Break tutorial event - he would either end up inside the wall or on top of the other guy. So I went with Plan B.

427
At one point, Grimoire and I were kicking around an idea for a mod that combined a bunch of our stuff, which included using both the level-up and shadow mods.
I don't think they are inherently compatible, but I do think that I concocted a fix...
Now, whether I still have the fix... That's another question.
The max exp gained remains 65535. I've never delved into the (I'm sure, very) exciting world of breaking the two-byte limit on numbers... And I don't think I really ever want to try. Thinking about that kind of makes me nauseous...

Anyway, my mods are free to use as you like... But I can't guarantee compatability.

428
It's a bunch of calculations that all happen at the time the monster stats are loaded from ROM into RAM. First, it determines the average level of your party, pretty straightforward (though as you may know, calculating an average using SNES's math capabilities is anything but straightforward). Then, it compares the average party level against the individual monster's level, and determines a difference ratio. Then it multiplies all stats except magic power and speed by the difference ratio. Then it multiplies speed by the difference ratio and takes the average of the original speed stat and the adjusted speed stat and makes that the final speed stat. Magic power is not adjusted at all (don't remember exactly why).
The difference ratio is saved until the end of the battle to adjust exp award, too.

Some (but maybe not all) of the assembly can be found on this thread:
http://slickproductions.org/forum/index.php?topic=1940.msg20858#msg20858
It went through several prototype phases before Grimoire LD and I settled on something we agreed was appropriate.
I'm sure the system wouldn't work exactly the same for FFIIIUS, but some of that might be at least useful to you...

429
That's true, and it looks like s/he finally gave in and played "the right way."

And, as they say, there's no such thing as bad publicity.
The thread has over 100 more hits since s/he started posting.

430
My understanding is that some hex editors will actually allow you to view the offsets in LoROM. Windhex apparently is one. For whatever reason, Windhex doesn't really work very well on my computer, so I don't use it, but if it works for you, it might make things a bit easier.

431
*sigh*

so I finally get somebody showing interest for TfW on RHDN, and it ends up being this:
http://www.romhacking.net/forum/index.php/topic,19749.0.html

These comments on the board in addition to four PMs saying basically the same thing... Like s/he is mortally offended by the notion that I would implement a system that discourages cheating. And I'm trying to explain this is not supposed to be a difficulty mod! Part of why I want play testers is to ensure that the game isn't too difficult for people who don't cheat!

Gotta love it...

432
Pinkpuff, do you think you will write a bulletin on RHDN for it?
If not, would you be opposed to one of us writing one?
I mean, that hypothetical "one of us" could even run it by you first before posting it if you'd prefer.
It just kinda seems a shame for something that took this much work and is this extensive to be left to The Fates to control who happens to stumble upon it on RHDN.

433
LoROM is the offset system used by the SNES.
It corresponds to the regular (viewable in a hex editor) offset of teh ROM, but not on a 1:1 basis.
When you view hex in Geiger's SNES 9X Debugger, you're viewing the LoROM offsets (which is why offset B000 in your hex editor is not the same as B000 in SNES 9X).

There is an algorithm:
LoROM enumeration begins at 8000, then for every 8000 the ROM offset increases, LoROM increases by 10000.
so...
Code: [Select]
ROM (in a normal hex editor) offset LoROM offset
-------- -------
0000 8000
8000 18000
10000 28000
18000 38000
20000 48000

When Grimoire LD and I post stuff on this site, we're usually using LoROM, because we tend to do most of our assembly hacking in a live ROM. You get to see instant results that way.

434
ok, the commands to mess with are:
Code: [Select]
$13/E56D BD 00 20    LDA $2000,x
Code: [Select]
$13/E110 7D 00 20    ADC $2000,x
Code: [Select]
$13/E580 BD 40 20    LDA $2040,x
and
Code: [Select]
$13/E118 7D 40 20    ADC $2040,x
Basically, these commands determine the position of each planet (and moon) depending on some constantly-rotating data in the 7E:2000 area of RAM.
Each planet's data has a relative location in this bank, separated by an increment (x).
So, for the first planet, x=00, and the game looks at 7E:2000. For the second planet, x=2, and the same command makes the game look at 7E:2002. Then x=4 and the game looks at 7E:2004, and so on in that fashion.

The trick is to take away the indexing...
That is, instead of
Code: [Select]
LDA $2000,xit'll just say
Code: [Select]
LDA $2000
or, instead of
Code: [Select]
ADC $2000,xit'll say
Code: [Select]
ADC $2000
So for every planet, the game just looks at the data that is supposed to be used for the first planet.
I'm not sure why, but the result is wobbly orbits.

In order to change the indexed LDA into a normal (non-indexed) LDA, just change the BD to AD.
so, for example
Code: [Select]
$13/E56D AD 00 20    LDA $2000
And to change an indexed ADC into a normal ADC, change the 7D into 6D.
so, for example
Code: [Select]
$13/E110 6D 00 20    ADC $2000
Try playing around with these commands and see what kind of fun you can have.
you can also change the "2000's" into "2002," "2004," "2040," "2042," etc.
2000, 2002, 2004, 2006, 2008, 2040, 2042, 2044, 2046 and 2048 are all accessed by these routines so changing any instance of 2000 or 2040 to any of these values will produce different orbiting results.

These offsets are all in LoROM, by the way. You can play with a live ROM by opening it in Geiger's SNES 9X Debugger, viewing the IN SPACE visual effect, then use the emulator's hex viewer to view/change the assembly at those offsets.

Does that make sense?

435
Another conundrum solved!

Thanks, by the way, Bahamut ZERO, for the suggestion - observing the item selection window was EXACTLY the key to figuring this out.

In order to make the Dialogue window appear on the bottom half of the screen, the following five bytes need to be changed:
Code: [Select]
OFFSET (LoROM) DEFAULT VALUE CHANGE TO PURPOSE
-------------- ------------- --------- -------
B444 13 8F Vertical position of the top of the center portion of the window (immediately below the top frame)
B455 03 88 Vertical position of the top of the window frame
B471 14 90 Vertical position of the bottom of the center portion of the window (this value is incremented as the wondow opens, btw)
B4A4 05 88 Vertical position of the bottom of the window frame (also incremented as the window opens)
B0EB EC 70 Vertical position of the text within the window

It should be noted that making these changes makes it impossible to see the yes/no and GP windows when they appear (unless you were to change their positions as well), because the dialogue window has top priority. I think for the purpose of TfW, I'm going to make the dialogue window position dependent on an event flag, so the window will be on the top half by default, but if I want to make text appear on the bottom half instead, I'll just set the flag first!
 :cycle: