Messages

76

Scripting and Reverse Engineering / Re: Usable Savemap

« on: 2014-11-21 20:33:15 »

No, I need Makou to help find all the vars in the game and at the moment it won't search for any and all references to a var.  When that's done, my job will be easier.

This savemap database is here so we don't conflict.  Any modders should tell me which bytes they are using, as follows

Example

Code: [Select]

EC4 to EC6
EC7
EC8
EC9

Hmm, that's a good way to do it (if Makou can do that), but might take awhile. I'm going to see if I can overwrite every variable in the game, and see which ones affect my NULL values - and then I will have the Makou variables for every unused value for sure...

That's a great find NFITC1. I thought we were just limited to 4 bytes with those love points!

77

Scripting and Reverse Engineering / Re: Usable Savemap

« on: 2014-11-21 20:19:32 »

I'm afraid I can't decipher your post

But it doesn't matter because I'm going through every byte.  I need Makou updating for a lot of it though.

If you look at my savemap data at BC9, you'll see what I am aiming at.

Yeah, I know what you mean. Looking at the area where you keep your WEAPON/SOLDIER stuff it relates to 0x0E3C 105 z_30 from my post. You'll see the "41-104" is actually the same as "192-255". Then the 9-32 in mine is 160-183 on yours. Though there are a lot of little differences elsewhere which is interesting, 0E3C itself is blank on mine and used in yours. As is 0E3E. My total of free bytes adds up to 599, while I think yours is 540 or something?

But as long as this is all sorted it doesn't matter how its done. Are you telling Makou to overwrite all values on a savegame or something?

78

Scripting and Reverse Engineering / Re: Usable Savemap

« on: 2014-11-21 19:29:00 »

I'm updating the data top to bottom, starting with Field module.  This will take time.

Cool, looking forward to it! Having it all setup in a Makou-friendly way would be a great step forward. I was actually just making a new Makou-only sheet recently as I didn't really know what I was looking at with the other one.

Also corrected last post, at the end it should't say "Last 224 bytes of 236 appear null" but just "Last 224 bytes of 236". As the values (which I just checked again in Black Chocobo) are correct as  0-2, 6, 15-43, 51-75, 82-85, 87, 90, 91, 99-123, 131-139, 142, 147, 150, 155, 163, 166, 170-188, 192-235 appearing null in z_38 and not the entire last 224 obviously.

79

Scripting and Reverse Engineering / Re: Sound Effects in Makou

« on: 2014-11-21 16:52:09 »

I started one but never finished it, only 42 sounds so far (none of them phoenix down). Also a good list would include if its loopable with AKAO or not. My one has that but no idea when I'll get around to finishing it (probably when my mod is in closing stages).

80

Scripting and Reverse Engineering / Re: Usable Savemap

« on: 2014-11-21 16:23:14 »

That's a nice idea.  Based on your comparison between start and end savemaps, which bytes changed?  How many were left on 0?

My notes were really crappy and done before I even used Makou.. I just wanted a rough idea of how many bytes were actually NULL compared to actual unknown so I could plan my mod a little better (the conclusion was I had plenty of space ). I checked the z_ unknowns from that savemap link in black chocobo and marked the positions of the nulls across several saved games in the samples folder. I'm not sure how it matches up with your chart or Makou.

The format is basically:
0x0BAB    17   Z_8      Unknown 0, 3-8, 13-16 look null and unused

17 lists the number of unknown bytes, Z_8 is the unknown place in black chocobo, Unknown just means its Unknown (sorry, didn't bother removing it), then the numbers indicate which positions are NULL - I just noted them as "look null/appear null/unused"


0x0BAB    17   Z_8      Unknown 0, 3-8, 13-16 look null and unused
0x0BB4   16   Z_9      Unknown 0-3, 6-15 look null and unused
0x0C20    4   z_15       Unknown – Only 0 appears unused
0x0BD6    14   Z_10      Unknown, 0, 2-5, 10-13 look unused
0x0BF8    1   z_12       Unknown – looks unused
0x0BFD    2   z_13       Unknown – both look unused, 0 and 1
0x0C20    4   z_15       Unknown – Only 0 appears unused
0x0C24    97   z_16       Unknown – a lot seem null, but some are used inbetween. Null values: 1, 8-31, 44, 47-48, 54, 61, 65, 67, 72-95
0x0C87    29/45   z_17       Unknown[0-28] First 29 bytes of 45 (ENDS AT 0x0CB3 16 Bytes into next bank) 1, 7, 9-38, 41-44 look unused
0x0CA4    16/45   z_17       Unknown[29-44] Last 16 bytes of 45 , see above. 1, 7, 9-38, 41-44 look unused
0x0CB5    49   z_18       Unknown 10-46 look NULL and unused
0x0CE7    7   Z_19      Unknown (only 4 and 6 are NULL values)
0x0CF0    12   z_20       Unknown (1, 4-6 and 9 are NULL)
0x0D01    40   z_22       Unknown – 2-4, 9-17, 19-21, 33 appear NULL
0x0D2A    28   z_23       Unknown – 4-25 appear unused
0x0D47    31         z_24 Unknown  most used except 4, 13, 20, 24
0x0D67    12   z_25      Unknown  (1 to 10 appear NULL)
0x0D74    15   z_26       Unknown – Look All Used
0x0D84    32/64   z_27   Unknown[0-31] First 32 bytes of 64 (ENDS AT 0x0DC3 32 Bytes into next bank)  1-3, 5-8, 13, 16-31, 49, 50, 53-54, 56, 60-63 NULL
0x0DA4    32/64 Bytes    z_27       Unknown[32-63] Last 32 bytes of 64
0x0E28    17   z_29      Unknown (4-5, 7-8, 15-16 look NULL
0x0E3C    105   z_30      Unknown (0, 2, 9-32, 41-104 look NULL
0x0EA5    1   z_31       Unknown Data (used)
0x0EA7    3         z_32 Unknown only slot 2 appears unused NULL
0x0EAC    22   z_33       Unknown  All seem unused and NULL!
0x0EF5    23   z_35       Unknown  3 to 9, 11-12, 14-15, 21-22 appear NULL
0x0F24    5   z_36       Unknown  0 and 1 appear NULL
0x0F2A    50   z_37      Unknown  13-45, 47-49 appear NULL/unused
0x0F98    12 and 236   z_38       Unknown[0-11] First 12 bytes of 236 (ENDS AT 0x1083 224 Bytes into next bank) 0-2, 6, 15-43, 51-75, 82-85, 87, 90, 91, 99-123, 131-139, 142, 147, 150, 155, 163, 166, 170-188, 192-235 appear NULL
0x0FA4    224 and 236   z_38[12-235]      Unknown  Last 224 bytes of 236

81

Scripting and Reverse Engineering / Re: Usable Savemap

« on: 2014-11-21 15:38:36 »

Thanks for this DLPB. it was tricky working out the empty spaces for the smaller gaps.  Damn, that's over 500 bytes unused. What criteria did you use to mark it as "unused" (at least as far it is possible to know)? I used Black Chocobo + many save games to see the null values for my own sheet, but didn't check all of them properly as of yet.

I have worked out quite a few known field vars if you want to add their info to the list? But that's a different purpose to "usable savemap" I think its still quite handy..

For example, here's some on 3-0 to 3-28 in your format that cover Chocobo Racing:

Note: These are ALWAYS set before races, except for 3-25 and 3-28 which are used after the race has concluded, so its rather pointless that the rest are saved IMO, its only because they're needed across the field to the minigame - so I just use them as additional temp fields)
3-0 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-1 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-2 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-3 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-4 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-5 (F): Holds the name of the chocobo you selected to race in chocobo racing minigame (disc 2/3)
3-6 (F): Controls who is the Chocobo rider in chocobo races, 0 = Cloud, 1 = Cid, 2 = Tifa.
3-7 (F): Sets the course of the chocobo race, long or short. 0 = long, 1 = short.
3-8 (F): Seems to control something about chocobo racing minigame, set before match, seen it to set 0
3-9 (F): Seems to control something about chocobo racing minigame, set before match, seen it set to 1
3-10 (F) (2 bytes): 1. In Corel Prison affects difficulty of Chocobo racing (stat values of your chocobo), values from difficult to easy: 3000, 3200, 3700, 4500.
              2. On Disc 2/3 set to match a value from the chocobo you entered into the race
                Note above for 2: If less than 1000, set to 1000 before race. Also cannot exceed 6000 unless you change field script
3-12 (F) (2 bytes): Same as above except the values are: 2200, 2500, 3000, 3500 for a different stat
3-14 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:248 (if racing chocobo 6))
3-15 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:249 (if racing chocobo 6))
3-16 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:250 (if racing chocobo 6))
3-17 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:255 (if racing chocobo 6))
3-18 (F): Set to the chocobo stat of your selected/registered chocobo before chocobo racing minigame begins (example, assigned from 15:251 (if racing chocobo 6))
3-19 (F): Seems to control something about chocobo racing minigame, set before match, seen it set to 7
3-23 (F): Holds the rank of your selected/registered chocobo for the chocobo racing minigame
3-24 (F): Something about chocobo racing minigame, before match begins set to random number + 15
3-25 (F/M): Your performance in Chocobo Racing minigame (Corel Prison part), if you win its set to 0, if you lose is set by minigame to increasing value depending on how badly you performed (the higher the worse).
Extra on above: Checked so Ester knows what to say to you "you were close" or "you suck!". Also records number of defeats in 2-76 with a +1 after every defeat so she can help you if you keep losing. 3-25 is set to 255 after you win and get letter from Dio. Is also set to 255 in elevator before racing. Does not seem to be used by regular races
3-26 (F) (2 bytes): 1. In Corel Prison affects difficulty of Chocobo racing (stat values of your chocobo), values from difficult to easy: 3200, 3400, 4000, 6000.
               2. On Disc 2/3 set to match a value from the chocobo you entered into the race
3-28 (F/M): Set to 255 before Chocobo racing match begins. Then checked after match concludes, based on the number, you receive a certain amount of GP and an item (you then choose between the two). There are many possible numbers to cover all items, from 0 to 23. This number is probably set randomly during minigame after you win (maybe something to do with 3-24 also?).

82

Completely Unrelated / Re: Ehrgeiz Ffvii brawler for ps1? Heard of it?

« on: 2014-11-19 17:25:54 »

It wasn't terrible back in the day. I enjoyed the story mode. The fighting was ok...not the cleanest fighter but not the worst. I'd say it was playable...it's been ages since I played it though so not sure how it aged or how much I ignored due to being a child. lol

Playing Ehrgeiz in 2014? Yikes. Scary thought. I bet it has aged terribly. I wouldn't touch it again with a barge pole.. it had its brief moment.

83

FF7 Tools / Re: [FF7PC/PSX] Field Editor - Makou Reactor (1.6.2)

« on: 2014-11-19 12:57:57 »

How does the model animation speed and model movement speed value work?  There is very little documentation on how these work?

Always thought these were quite simple? Here's what I know, sorry if you were looking for more detailed answer

Model animation speed = 1 means play it at normal speed. At 2 it plays it at maybe half-speed (i.e. slower). Beyond that I didn't experiment (I guess it becomes ultra slower?).
Model movement speed: Around 3000 is running, and 1500 is walking IIRC. Lower or higher than that then you start moving at non-human speeds obviously, which can be useful at times. I just used a 5000 myself.

myst6re: I also found another bug in the text editor, this one is quite annoying, when using the memory option to pull string data from variables, you can only set the memory to use banks 1 or 11. If you do change it to something else, it won't be saved when you go to another text box and then come back, it will just reset to 1 or 11.

If you check the game scripts you can see they use banks other than 1 and 11, so it is bug IMO. For example, Chocobo Farm uses: {MEMORY:var[15][74];size=1}, but this would be impossible to set using your text editor. You could only have [1][74] or [1][#whatever] or [11] [#whatever].

84

FF7 Tools / Re: [FF7PC/PSX] Field Editor - Makou Reactor (1.6.2)

« on: 2014-11-16 23:40:06 »

{VARN} is not a good name for this tag. In fact there is one which display a variable in decimal, another wich display in hexadecimal, and I don't remember for the third.
So there is a confusion with the opcode "set window variable" which set a variable in the order of appearance in the text.

Interesting. That makes more sense. Thanks!

85

FF7 Tools / Re: [FF7PC/PSX] Field Editor - Makou Reactor (1.6.2)

« on: 2014-11-16 21:31:53 »

Does anyone know what's up with displaying coordinate variables in a dialogue box? The triangle ID comes up OK, so does X coord (at least most of the time), and then Y is in hexadecimal for some reason (though it oddly worked out OK a few times.. and sometimes not OK, unless I interpreted it wrong). Added them as 16-bit variables. Seems to be buggy when you display more than one variable in a window at the same time, though didn't try one at a time yet..

Reason is I was just using it for testing positions and directions and such, but still its quite a pain

86

FF7 Tools / Re: [FF7PC/PSX] Field Editor - Makou Reactor (1.6.2)

« on: 2014-11-11 18:35:31 »

Thanks for the quick reply on this. Other than those bugs, the program is perfect

It seems that is a rellocation bug when the field is bigger than the original.

Yes, it does seem so. I'm willing to help test it if you need it, I hope it can be fixed.

Fixed recently, thanks anyway!

Strange, I'll look at it.

Great! 

87

FF7 Tools / Re: [FF7PC/PSX] Field Editor - Makou Reactor (1.6.2)

« on: 2014-11-11 00:03:16 »

Strange, did you try inserting the new field file using cdprog? As long as your file is only slightly larger than the original one it will still fit into the sector.

Mostly that is the safest way to go. Extract your whole FIELD directory using cdmage, then mod the directory using MR and finally insert the modded files in cdprog, that's 100%.

Another issue when using a different method like Hack7 or MassIsoupdate is increasing the ISO size. As I know that you are creating mods you should know that it is pretty tricky to have the image size increased as you can't make small ppfs anymore.

For MR this may be a small bug in the save ISO function.

Yes most definitely a bug IMO. Because as soon as it tries to move it to a new sector the game just doesn't use it, instead it just uses the old script. I never noticed before because I always used MassIsoUpdate.  I also replicated the problem with original Japanese version,  as soon as it changes the sector for rootmap.dat (this time to LBA 202) it just uses the original script and not the updated one.

So with Makou iso save feature it seems it doesn't like an increase in filesize... to replicate just open the ISO, copy and paste the existing script a few times over in rootmap.dat (until it moves the file to new sector) and now Makou will only see the new script, but the game will default to whatever old script was in the original sector. Now the question is does Makou do this with all fields or just this one?

meesbaker: Yes, it is strange... CDProg is not option due to filesize. And yes MassIsoUpdate increases the ISO size by 2 bytes, but at least it always works and I can insert decent amount of text, which is probably what people using a field editor want to do otherwise they would use translation tools. A lot of people can download like 10 GB in like a minute now anyway.

Edit: Yes it seems this occurs with all fields unfortunately, as I added some very explicit text which did not appear. 

Also some other smaller bugs I found:
1. If you add a new text to the end of the list (for example, there's 15 texts, and you add number 16), then you can't use it for a window autosize preview. At least not until you add number 17 (and then 16 works).
2. If you save an ISO and its busy (such as with CDmage) it returns an error about being busy. If you then close CDmage and then try to save it, it will just fail over and over again. So basically you will lose all your work if your ISO is accidentally busy.

88

FF7 Tools / Re: [FF7PC/PSX] Field Editor - Makou Reactor (1.6.2)

« on: 2014-11-10 23:24:40 »

MR auto deletes unused text, so if you create new dialogue but never call upon it in a field script the dialogue will just be erased.

Nah, that's definitely not the issue, for a couple of reasons:
1. I only touched this field manually.
2. I never use that auto function, doesn't sound useful to me (plus too risky).
3. I made changes not to do with dialogue also.
4. Obviously I did call upon it.

I just copied a fresh ISO and inserted that same script, and now the game just displays the game's default script without any changes at all, though the script IS inserted and viewable in Makou (again at LBA 1227, but its not linking to it). The script isn't even that much bigger than original either. So just seems a litttle strange MassIsoUpdate can handle this properly and Makou can't (since Makou can do everything else )..

89

FF7 Tools / Re: [FF7PC/PSX] Field Editor - Makou Reactor (1.6.2)

« on: 2014-11-10 22:57:09 »

I just came across maybe a major bug with the PS1 version. I was using the open ISO feature on a clean ISO, I removed all the unused text from rootmap.dat (the train screen in midgar), and started adding some new text and dialog display. It worked fine (both in-game and in editor), at least for awhile... after making a few extra changes I went to play the game again and my changes stopped showing up. Makou saved the file and scripts fine, but the game would only show me my old version (not any new changes).

Why would the game show the old version when it clearly saves a new one? I checked the LBA of the Rootmap.dat and it was moved to 1227.

So I exported the script from Makou and inserted it using MassIsoUpdate on a different ISO and it worked fine as it should.. so the script is saving correctly. So I inserted 30kb of script and the LBA changed to 1570. But the Makou ISO is just always stuck showing me the old version (I don't even know where it could possibly store that old script since its saving the new script?). Weird huh! It must not be updating Field.dat properly or something?

90

Completely Unrelated / Re: Ehrgeiz Ffvii brawler for ps1? Heard of it?

« on: 2014-11-10 11:10:38 »

I remember playing the Japanese version when it was released - it had an interesting RPG mode. I don't remember it being the worst game ever, but it certainly wasn't brilliant.. When I got Power Stone 1 and 2 on Dreamcast it reminded me a little of Ehrgeiz, though of course Power Stone was much better

91

FF7 Tools / Re: [FF7] Dialogue/Events editor - Hack7 (v3 BETA 3)

« on: 2014-11-03 12:06:07 »

Just a heads up, the Mass Field Update tool has been updated and now supports all (most?) versions of FF7. Handy if you have a custom kernel, scene, field models/dat etc. files which you just want to put into an ISO quickly without fuss (Makou doesn't let you import model description settings in the dat for some reason). I also found the ISO it produces is now less prone to errors. Three cheers for Lasyan 

http://lasyan3.free.fr/index.php?page=ff7-outils&lang=en

92

Scripting and Reverse Engineering / Re: Battle/Global Variables

« on: 2014-10-31 00:27:34 »

if your looking to save things to the charcters themselfs there is 4 unused bytes in the char data too

char data is saved as seen here in memory it should be the same.

z_4 being the unused / unknown (but never seen with a non 0 value)  bytes.

Can you even write to those character info records from the field script (never mind battle)?

93

FF7 Tools / Re: [1.5.1] Makou Reactor - a FF7 field editor

« on: 2014-10-30 17:20:14 »

Little request if you don't mind, it would be cool to copy and paste models and animations from one field to another without having to manually set them. Like copy Red XIII's model and animations from bugin2, and paste it into mds5_1 for example.

Done, thanks for the suggestion.

I just noticed the above posts, but I can't seem to do this, how do I copy for example, a chest or potion field model, into another field? When I try it doesn't show the correct model preview (or none at all). This is for all PS versions. If I just save it, does it show up in-game? Or is this a PC only feature? Thanks!

Edit: No worries, figured it out!

94

Releases / Re: [FF7PSX NTSC-U] Disc Extension Patch (v1.0)

« on: 2014-10-29 16:57:37 »

After looking at Bosola's great notes and some trial and error, I've replicated the patch for other PSX versions (I wanted to patch the Japanese versions, I only patched the kernel myself, but don't see why it wouldn't work for scene.bin as well) I wrote this quite quickly but should be a good guideline..

1. Open Bosola's US patched ISO in CDprog and check the movie dir's LBA and size for KERNEL.BIN and SCENE.BIN (this saves some work doing it yourself)
2. Note that null1min.dat has been deleted in the US Patched ISO (this file is for making the game run on really old PlayStations).
3. Open Japanese ISO (or another version, I'll just call it the JP ISO from now on) and delete null1min.dat from the movie directory with CDProg. Using CDProg again create new file called KERNEL.BIN in the movie directory with the same LBA and size values as the US patch's KERNEL.BIN in the movie dir (if your also applying SCENE.BIN, do the same for that file).
4. Extract yamada.bin from US patched ISO and open in hex editor (you will want to check the values).
5. Extract yamada.bin from JP ISO and copy down the values for the KERNEL.BIN and SCENE.BIN according to the directions in this thread (you will be copying them from the values of the US's yamada.bin - don't copy all of them, obviously - just the scene.bin and/or Kernel.bin):  http://forums.qhimm.com/index.php?topic=9737.0
6. Using CDMage import your modified yamada.bin into JP ISO, followed by your OWN (or JP original) kernel.bin into the new kernel space on your movie directory (if its smaller than 64kb, it will just be padded and still work).
7. And your done.. at least for disc 1.
8. For discs 2 and 3, you will probably want to check the values from the US patched versions 2 and 3 (those versions may even have two NULL files, see if they are deleted in US patch, I haven't checked it myself).

For testing I used modified kernel.bin to see if it was successful (battle message), but if you don't have one - just opening your equip menu and getting into a few battles should be enough to test it. If CDmage says you can't import over the kernel.bin in the movie dir you have done something wrong and need to start again. If the game doesn't boot but works absolutely fine via save states you've also done something wrong but getting close

One thing I'm not sure about is my original KERNEL.BIN still exists in the Init directory. Whether you delete that or not is up to you I think, I don't think it can harm anything?

Have you added much data to your KERNEL Bosola, how does it hold up?

I took a look at applying the magic defense bug also, but seems a lot a more work with armor pointers and stuff..

95

Gameplay / Re: Unused/useless variables safe to use in savemap? (PSX)

« on: 2014-10-28 15:46:02 »

Yeah I did check that out along with Safer Sephiroth's AI. That part doesn't seem too complicated but makes me think of a good question.. whose pre-battle AI goes first? If I change Ultimate Weapon's HP in Cloud's pre-battle AI, would that affect Ultimate Weapon? I'm assuming my one would kick in first (as the first character/bitflag?), and then Ultimate Weapon's HP would go back to normal (unless I also change scene.bin).

96

Gameplay / Re: Unused/useless variables safe to use in savemap? (PSX)

« on: 2014-10-28 03:53:57 »

Yeah I'll keep it short and sweet. I think it will be fun.. and will give me flexibility in the field having power over those stats. Actually, it looks like the only things I can't change is morph/steal/item drops (don't see them on opcode list, unless its unknown?).  I was expecting only to be able to change HP values at the most    Oh, modding FF7 is awesome!

I looked at the Kernel sizes for the Japanese version its just under 20kb by default, while the US one is 22kb by default. Does the script section have a specific limit or is it a overall kernel limit you're talking about (I'm not planning on making many significant changes to it other than scripts)? I've seen people saying around 27kb is maximum? I pasted in 200 lines of opcodes/argument numbers in a text file and it came up at around 1.6kb. Not sure how much it would be in the kernel, but I hope that's alright..

97

Gameplay / Re: Unused/useless variables safe to use in savemap? (PSX)

« on: 2014-10-27 23:59:24 »

Past a certain point, it won't be big enough anymore. Once you reach Guardian in the Underwater Reactor, that's when it goes past 255 (in the actual formation, his left hand is FF/255 and his right hand is 0100/256).

I was thinking from the field you set the variable to 1 when you need it On and to 0 when you need it Off.
01 2010
60 32 (change to 60 01)
44 (change this to a 40)

Then it'll be If ( (GlobalAddress = 1) ) and you can toggle it on and off for those certain boss enemies you want to buff, if that's the goal.

Hmm, seems quite simple, how about this instead?

var 80 and 81 - add them together in script to get enemy ID
-  add secondary if statements, if encounter Guardian, etc, then affect ALL enemy IDs in battle (maybe lose some flexbility though)
var 82 - A MAX HP value to set (same as HP)
var 83 - multipliers for stat combos/MP (allowed 255 combinations right? maybe you could even include a combo for random encounters which simply sets HP multipler for all enemy bitflags)
If all four vars are active, turn on the script for next encounter?

Lol, would this actually work?

Edit: Not asking you to give code example, I think I know enough now to experiment at least (thanks to you) 
Edit 2: Just remembered only 1 byte for var 82.. maybe can merge HP multiplier into var 83 and have one var free for something else?

98

Gameplay / Re: Unused/useless variables safe to use in savemap? (PSX)

« on: 2014-10-27 22:39:42 »

I was planning to pass value from bank1 var 81 (via field scripting) to refer to enemy ID (I tested it with regular variable and it works, so I assume that would work). Most bosses aren't multiple parts..and there could be special exceptions for them. Though I'm not sure 1 byte is enough to refer to all enemy IDs?

99

Gameplay / Re: Unused/useless variables safe to use in savemap? (PSX)

« on: 2014-10-27 21:29:09 »

I'm using bit flags in my mods already (said it in my first post here), just asking how it relates to this battle script.

Actually, I may have made a mistake in testing "by bit" by using wrong ISO, it doesn't seem to function now. But the enemy ID one works fine though, I'll see if I can retune it by checking out what Safer Sephiroth does.

Edit: Ah, right, I'll try using bit 4 in a moment to see if that has any affect.

Edit 2: Excellent, I got the If statement working with this code (modified from Sega Chief's original code)

LocalVar:01A0 <- 5
LocalVar:0000 <- 80
TempGlobal <- &GlobalVar(0000)
If ( (GlobalAddress > 50) )
{
   LocalVar:0100 <-  (ActiveMask.EnemyID == 22)
   LocalVar:0100.HP <- LocalVar:01A0
   Display String: "test"
}
SCRIPT END

100

Gameplay / Re: Unused/useless variables safe to use in savemap? (PSX)

« on: 2014-10-27 20:47:16 »

Yep, I was just playing with HP only and not MaxHP so I could get the basics down first.

I can report gladly that all the code above works (as I thought it would). Excellent! While I understand Enemy ID, I'm not sure I quite understand what is Bit 3? Is it monsters from the area you are fighting in or something? How does it only affect Guard Scorpion?

This is my code (setting HP to 5):

LocalVar:01A0 <- 5
LocalVar:0100 <- FlagBit(3)
LocalVar:0100.HP <- LocalVar:01A0
SCRIPT END

Now for the big test, throw it into an if statement haha. I haven't had any luck with this at all previously. Maybe with the enemy ID located in a variable it can work this time