could you just make it a part of the main PrC window, instead of making it a whole new window? i know it'd probably take a lot to change it like that, but it could also prevent the scene change bug, if you make the ai window the only part able to be changed until you close out of the ai editor part, or "cancel" out (since it'd be a part of the main, if you didn't want to save the changes to that ai edit, but wanted to keep changes elsewhere, and since the X button would close everything, a cancel button would be needed). you could make it like a new tab to the main window, but make it ask if you want to keep your changes when attempting to return to the scene section, and the close button wasn't pressed (save button?).
of course finding out how to do what you wanted would work as well, but you'd have to either make the main window unable to be clicked on, or make the scene unable to be changed while the ai window is up.
wow... there is a lot of errors in the main scripting of the game, like anding a number to zero when trying to get a non-zero value... 0 AND anything is 0. i even tested to see if the game somehow used something else for anding, made 0 AND 1, 1 AND 1, and 2 AND 2, and the results were false, true, true, meaning 0 and 1 is 0 (as is 0 and anything), so a lot of the scripting (hell, 90% of grunt's is broken) doesn't work as intended because they start the variables as 0 instead of as 1, which would make the ai work properly.
i am going to make the ai work as intended, using terence's enemy mech. guide as a base for what is intended, and fixing anything that should work one way but doesn't. i tested the grunts in battle, and when they were in the front row, and i was in the front, they did beamgun/handclaw at a 50/50 rate (expected if not everybody was in the front or back rows), and when everybody was in the back, they did a 50/50 rate as well, when it should have been at most a 1/8 chance for handclaw. if i were to change the variables in the ai to start as 1, not zero, then the entire script would likely work correctly (though once again the shoot element beamgun, like the mp's machine gun, is not a ranged weapon).
my rewritten version will work as intended originally, though like most other enemies, it isn't needed (just being done so that people will have a smaller scene as a base working as originally intended, especially for those psx modders who want the original ai in tact, (and since they have limited changing room normally) mine will be that, with bugfixes
).
ok... i know how to see if there is any enemy in the front or back row, but not to see if they are ALL in the front or back... to do so, would i have to make an if that checks for (allActiveOpponents.backRow=1 && NOT allActiveOpponents.backRow=0), so that it'd first see if there was any enemy in the back, then check to see if an enemy is in the front, and only continue if someone was in the back but not the front? i do not see any magic function to only return true if all are in the front (mono/guard only use the if any is in the front/back method). i know it will work, but it is kinda big to write, even using variables for the value. meh... it will still make it smaller than the current 850 byte script <_<.
edit: this does work to check for all in the front or back, so i guess i can't complain. i made a test to print 00 (front) if (someone in front && not in back), 01 (back) if (someone in back && not in front), and 02 if neither previous ones were true. the start, barret and cloud were front, and it printed 00, i moved one back and 02 printed, then moved the other back and 01 printed. the original test was only for checking if one was in the front row (seeing if it was true if all were in front), and it printed either 00 or 01, never 02. too bad i don't know of a quick and easy checking method <_<.
ok, the way that i am scripting the ai for the grunt (and will pass over to others if needed for even more space) is making the ai jump to the end when an attack is to be set (the attacks are set at the end), and then finalize there. so what i am doing is going through the regular if statements to find out the target and attack needed to be used, but instead of repeatedly setting a variable for the attack throughout the ai, i am just making it set one time, and the script jumping to the setting whenever it is ready to attack. everything else needs to be set before setting the attack itself, because otherwise it will perfrom the attack early without setting a specific target, but in the case of the grunt enemy, it is pretty easy and efficient to do it this way. but it is hard for the ai editor to show the C equivalent, and somewhat hard to follow (but nowhere near as hard to follow as the original grunt ai... that is a mess >_>).
i was wondering how you have it lay out the code, do you have it just draw brackets and indent based on where the jumps are located, and have it try to follow the jump to see how to put the brackets? if you were to have it draw a left bracket at the start of an if (when a 70 appears), and follow the pointer to the location given and place a right bracket there, and indent everything in between, that'd make the spacing better. do the same for 71, and for 72, actually have the disassembler follow the code and write it right after where the jump was located, so that things were to look more accurate. looping jumps could be a problem in this way, but put the normal LOOP visual after drawing the code once.
ok, this part will porbably be a little big, but should explain what i mean a little bit more (feel free to hurt me if i am just thinking it is easier to do than what it actually is):
this is from the beginning of my mono drive code:
0x000 00 0000
0x003 52
0x004 70 003b
0x007 81
0x008 60 02
0x00a 34
0x00b 70 0021
0x00e 93 (Enemy Sighted!)
0x01e 72 0034
0x021 93 (Warning! Warning!)
0x034 10 0000
0x037 60 01
0x039 90
0x03a 73
0x03b 02 2060
0x03e 02 4140
0x041 80
0x042 60 04
0x044 44
0x045 81
0x046 60 03
0x048 34
0x049 52
0x04a 50
0x04b 70 0084
...
if you follow the jumps, and use the way i said to place the brackets, it would appear like this:
if (Not (LocalVar:0000))
{ //places because of the 70
if (Random MOD 2)
{
Display String: "Enemy Sighted!"
LocalVar:0000 <- 1 // followed the 72 and placed the things within up until the SCRIPT END
SCRIPT END
} //places here because it is the end of the jump
else
{
Display String: "Warning! Warning!"
LocalVar:0000 <- 1
SCRIPT END
}
} // placed here because it is the end of the jump
if (((Self.MP > 4) And Not (Random MOD 3)))
{ // goes on, but rather big, so i just used this small part as an example.
now, the program's normal output for this code:
If (Not (LocalVar:0000) )
{
If (Random MOD 2)
{
Display String: "Enemy Sighted!"
}
Else
{
Display String: "Warning! Warning!"
}
LocalVar:0000 <- 1
SCRIPT END} // goes fine until here, and then the indentation craps out for whatever reason
If ( ( (Self.MP > 4) And Not (Random MOD 3) ) )
{
from what i have seen, it is mainly the indentation going wrong, which should be pretty easy to fix (again, hurting is
allowed :-P), the addition of the code from a jump on (as seen with the message then variable/end statement) would
just help things be easier to follow for mass jumping programs. the only problems i see with this jumping idea is possible
looping errors, where it keeps trying to make a loop repeatedly within the same loop (like writing infinite if's instead of a
while), instead of writing once and printing loop at the spot it would return, as well as it taking a while to render the C
code from the hex, since it would take a good bit longer depending on the coder's format.
but if these were implemented, it would make following your own, and others' code much easier.if someone just looked at the disassembled version of my grunt ai, it would appear to have multiple empty if statements (what happens when it is true, no the actual statement itself), when it is just jumping elsewhere in the script to save space.
oh, and where are the battle square battle formations located, because they are apparently not normal formations?
