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

Pages: [1]
1
I could have mentioned that my previous post concerns the PSX versions (more specifically NTSC) of the game.
Can't say I know if it works on the PC, but the vast majority of glitches (of this nature) are the same on both platforms.

2
The Cave in the middle of the snowfield doesn't reset the counter any more than any other Glacier field adjacent to the snowfield map.

When you pass out you are brought to the hut, the pass out variable is not reset at this time. Instead, it is reset if you return to a glacier field (not the rotating snowfield map) with a value >544.

Side note
This is where the pass out glitch comes into play, the function detecting if the variable is >544 reads the variable as signed, meaning that a value >7FFF will be interpreted as negative, and thus not above 544, and the pass out variable will not reset, and nor will you pass out.
So if you run around at the base of Gaea's cliff for almost 2½ hours and then return to the glacier you'll be impassoutable!

3
I know of one RNG table (0-255) that goes 177, 202, 238, ..., 171, 176, 12. This baby is to my knowing often used for various randomness in fields but not for randomness on the world map.
Apart from the just mentioned one I only know of one other RNG table and it goes 99, 6, 240, ..., 199, 106, 202 but that isn't it either it seems.

Anyone happen to know which RNG table is used for worldmap randomness?

4
Sorry, FF7

Yes. I know about the RNG-list and pseudo randomness, but it isn't simply picking the first number for the first battle and then moving on to the next number for the next battle.

More Data
In the memory the RNG list can be found at address 000E0638 to 000E0737 (PSX NTSC US version).
The value that is increased by 1, 2, or 3 (I've only observed those three increments) at each battle can be found at address 00071C20 (PSX NTSC US version).

If we stay at the rather small field (ID#461, 01CDh) that resides in between the 'Mt. Corel Reactor' field and the 'Roller Coaster Section' field and play 20(23) Battles it will all line out like this;

Battle Formation # (1st Encounter to the left):
#4,#2,#1,#4,#3,#2,#4,#3,#4,#2,#4,#2,#1,#3,#2,#4,#2,#4,#3,#2,(#4,#4,#4,...)
#1 = 1x Bomb, Chance 18/64
#2 = 2x Bomb, Chance 17/64
#3 = 1x Cocatolis, 2x Boatfloat, Chance 15/64
#4 = 2x Cocatolis, Chance 14/64

Counter That is Incremented at Encounter (and remembered between soft resets, is 0 at start):
2,4,6,8,11,13,15,17,20,22,24,26,28,30,33,36,38,40,43,46,(48,51,54,...)
Note: It will be 0 before your first encounter but turn to 2 the instance you get that first encounter. I.e. It is incremented AT encounter and not after.
Also Note: Fighting one or more battles at any other field Could alter this pattern, but will not necessarily do so. Because of this I believe the encounter itself has something to do with this value's behavior.

First 20(23) values in the RNG list:
decimal: 177,202,238,108,90,113,46,85,214,0,204,153,144,107,125,235,79,160,7,172,(223,138,86,...)
hex: B1,CA,EE,6C,5A,71,2E,55,D6,00,CC,99,90,6B,7D,EB,4F,A0,07,AC,(DF,8A,56,...)


What I think I know
For the first encounter the 3rd value in the RNG list will be used (the one in slot 02 if you count the first one as being in slot 00), namely 238.
And the game does the following:

x = 238
r = 'Battle Formation #1 Chance' * 64  //18
s = 'Battle Formation #2 Chance' * 64  //17
t = 'Battle Formation #3 Chance' * 64  //15
u = 'Battle Formation #4 Chance' * 64  //14

If x<r*4 {Give Battle #1}
Else If x<(r+s)*4 {Give Battle #2}
Else If x<(r+s+t)*4 {Give Battle #3}
Else {Give Battle #4}  //(r+s+t+u)*4 will always be 256 in a set of 4 battles

For the 2nd encounter the 5th value in the RNG list will be used, the one in Slot 04, namely 90. A similar check to the one above is made BUT for some reason the 6th value in the List (Slot 05) has something to do with the outcome. If the 6th value is set to 00h the game will pick the battle # just like it did for the first encounter but if set to 80h it wont, i do not know why.


This is pretty much what I got so far, I will probably try some more in a very near future but for now this is it. Anyone up for the challenge is more than welcome to help out or solve this before I do :)

EDIT:
Been looking at it some more and did managed to figure most of it out. Was still somewhat puzzled as to why it used RNG x+1 instead of x sometimes though, but fortunately Terance's "Enemy Mechanics" actually hand an explanation for that specific behavior and with that all the remaining blanks could be filled. So yeah, problem kinda solved.

5
I'm trying to figure out exactly how the game picks the order of different battle formations. I know some about it atm but not enough yet to figure it out.
If anyone happens to know all this already feel free to enlighten me :)

What I know (in short)
I know that from a hard reset the order of the enemy formations you encounter (in random field battles) will always be the same.

E.g. if you encounter EnemyA, EnemyB, EnemyC, in that order (in three separate battles) you will again if you hard reset the system (turn the PSX power off/on) then load a file and fight in the same area.
If you from a hard reset fight only one battle (against EnemyA), then soft reset and load a file and fight another battle in the same area this battle will be against EnemyB, and if you soft reset again and fight another battle yet again this one will be against EnemyC. In other words, the order is kept/remembered as long as the system isn't powered off.

I know that the RNG-list that is used for deciding when to give you an encounter is also the RNG-list that is used to decide what encounter (battle formation) that will be (and I have a somewhat good idea of how the actuall values in the RING-list are used to decide the formation).

I have located a counter that keeps track of how many battles you have fought since latest hard reset, however its behaviour is somewhat random (it's increased by 1-3 per battle) but if it is reset back to 0 (by unnatural means) you will reset the order (i.e. the next Fight will be against EnemyA, then B then C). What decides how this counter behaves is still unknown to me though.

I'm currently not at my work station so I don't have the memory addresses for all the values involved, as soon as I get back I'll add them to this thread, but until then the above information will have to do.

6
This is used to look up a table containing 256 numbers already distributed from 0 to 255 in a seemingly random manner
/.../
So if you're going to do any analyzing, I'd suggest you focus on what is actually happening in the game, rather than on the numbers behind it

Got ya, still interested in that Table though.  :|

7
Ok, I've manage to find (what really seems to be the only) 3 variables that are involved in giving you an encounter. But this is about as far as I will get :/

#1. the so called Danger Counter
Same one that Terence mentions, increases by a number per battle check depending on the current Field and if you're walking or running.

#2. a Battle Check (bcheck) Counter
This counter increases by 2 per battle check regardless of if you're running or walking. 1 byte in size.

#3. Battle Check Loop (bcloop) Counter
Each time the battle check Counter is looped back to 0 this one increases by 13. Also 1 byte in size.


All I know is that depending on the value of the bcheck and bcloop counters a danger limit is set. If, during a battle check, the danger counter equals or exceeds this limit you will get an encounter.

E.g.
bcheck = 76
bcloop = 0
sets;
limit = 1024

The behavior of this limit seems next to hard coded if u ask me >_<.

These are the variables addresses in the PSX memory (hope it's of any help);
8007173c - danger counter
8009C540 - bcheck counter
8009AD2C - bcloop counter

Anyway, I probably approached this thing from the wrong angle to begin with and really do need help finishing it (I've hardly ever studied and/or interpreted the game disc data). The "only" thing that's left to find out is if the limit is hard coded or is a function of bcheck and bcloop and if so what does it look like.

8
That random number generator might be what you are looking for in any case.

That random number generator might have been what the programmers intended to use for Field random encounters, but seeing how there's nothing random about these encounters I simply doubt the final product does.
According to Terence the World Map random encounter mechanics uses a random variable (as well) and I have no reason to doubt him on that one, because World Map encounters are, unlike Field encounters, actually random (as random as can be).

That what was supposed to be random isn't. What and the behavior of whatever replaced it is what I'd like to know. Looks like I'll have to pioneer the dmn thing :/

9
This called Danger Counter in Terrence FAQ. He gave complete description of random encounter, what else you need?

No I'm not talking about the danger counter, that would be another variable (one that isn't looped back to 0 when it reaches 256), but yeah I'm already aware of that one.
As stated though, he mentions a random variable, but the encounters are not random at all so that can't be it. Also,if you're close to get a battle while saving, load up and that battle will be skipped (but this will only be the case if you were close enough to it), seeing how there is no mentioning about this in his FAQ the description it's definitely not complete.

But apart from that random variable (which really cant be random) I believe he got most of the mechanics correct. So i guess my actually interest is that "random" one and its actual behavior.

10
I'm already familiar with those FAQs, that was what I were referring to when I mentioned Terence in the opening post.
I'm not at all interested in the battles them selfs really, just exactly how the game determines when to give you any one of them (Field only).

Terence explanation seems fairly accurate but he mentions a random variable being involved, but since the battles are all but random that cant really be it.
Furthermore I've located one variable that is increased by 2 for each battle check and is looped back to 0 when it reaches 256 that in some way is involved in determining when to allow a "random" battle, but there is no mentioning about this variable in his FAQ.

So, I stand blind... still

11
Well, partly because I want to find out what (if something) went wrong with the randomness in Field encounters, seeing how they aren't very random at all but instead most predictable.

But mostly for in-game reasons. With full knowledge of when they occur I would, simply by walking a specific way, be able to alternate the random encounter pattern, and thus (hopefully) reduce the frequency of random battles. I've already managed this to some extent already, but so far I'm just fooling around in the dark till I get something concrete to work with.

12
Have anyone ever fully mapped and documented how the game determines when to give you a random encounter? Tried finding something (on this board), but no luck.

I did find something Terence wrote on the issue a long time ago. It offered a good but unfortunately not full explanation :/

13
Thanks.
Yes, I would like to play with the fields myself and take a more in-depth look at how the scripting for that scene works but I don’t have the PC version =/ (seems like Meteor only works with the PC version of the game, or am I wrong?).

As for Zagan's line that is what he says if you run back down from the Nibel Montains right after your group has departure.

14
Hello Board. I got two (well, kinda anyway) questions I’d love to get answered, dont be shy =)

First Q
In FF7 when revisiting Midgar on Disc 2 you’ll trigger a scene involving the turks in the first Midgar Subway Tunnel screen.
What I’d like to know is exactly what Cloud can (and will) walk into to trigger this scene. Is it one (1) invisible wall/area/box that covers the entire tunnel or is it two (2) walls/areas/boxes (one on each side of the pillar in the middle)?

Second Q

Would anyone know exactly why I’m able to dodge the textbox paralysis in this scene (data wise that is)?
http://www.youtube.com/watch?v=YytCBTInUJg
I’m rather certain it has something to do with the door opening at the very same time that I am hitting the action button (seeing how I’m incapable of doing it with the door already opened).
My guess would be that Cloud is paralyzed for an instance when he hits the door and is then automatically un-paralyzed when the door has been opened. So, if I hit the action button at the same time that I’m paralyzed by the door the texbox will appear (not capable of paralyzing me any more than I already am) and the next thing that happens is that the door un-paralyzes me with the textbox still there.

15
Archive / FF7 _PSX_ Mod-ability
« on: 2006-03-01 15:36:34 »
Quote from: FeuFeu
Maybe not, in fact. Some tools works with files (or file formats) that are the same between the two versions /.../
(By the way, nice to see you here, BrutalAl :) )


I see, might be worth a in-depth look at sometime then after all.

heh, nice to c u 2

16
Archive / Monologue
« on: 2006-02-27 23:59:35 »
I'll interpret this... silence as a "not very bright at all"  :z

17
Archive / FF7 _PSX_ Mod-ability
« on: 2006-02-25 14:56:25 »
IF one would want to Modify* FF7 (PSX) would her/his future look any bright? I've glanced through the Tools available at this and affiliate sites but most, if not all, of them seems to be for the PC version.  :erm:

*Can be anything from enemy stats, battle spoils, chest content, dialogues/text to enemy logics, battle setups, field events, the works

Mod Edit: Moved to Game-Tweaking

Pages: [1]