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

Pages: 1 ... 5 6 7 8 9 [10] 11 12
FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-07 21:06:43 »
ok, another thing now... i noticed that when you add a new move via PrC then go to the assign animations window, the newest move is in all of the boxes that should be empty. after saving my changes in that screen (with all the empty ones with the tentacle move, even though it shouldn't have been, with only the animation changed), and returning to it, the boxes were all empty, even the one that should have been the new tentacle move, i am guessing that it re-refreshed the contents after being reopened, and since i never actually set tentacle to any of them, it sent all of the boxes to an empty slot instead, but did not refresh the contents after clicking it the first time (after creating tentacle, the anim. editor wasn't opened before that).

i checked the hex with an editor for the changed scene, and all but the tentacle id itself were there, so that is working fine, just the editor itself is a little buggy :-P. maybe setting it to an always empty box (instead of one of the available attacks, making a 33rd move in the anim. editor only, that only signifies an FFFF value for the attack id (not an actual move, just for the null value), so that this could be prevented) could fix the problem?

also, i know other things do this, but making a little manipulated attack editor could be helpful for when you make a new move, so that you do not have to use another editor to change the moves, it doesn't even have to enable/disable the ability to manipulate them, just the moves that can be used if it is able to be manipulated. not really necessary, but would be a nice little addition.

edit: the second attempt did successfully add the new move to the atk id in the enemy data, it is just a bug with the window. i checked the next scene i added tentacle to, and it did the same thing. i manually changed the atk to a blank spot then returned it to tentacle, then saved, but when i checked after that (window does not update until after being saved/opening a new scene.bin/changing scenes apparently), it had reverted back to a blank spot, but saved this time after switching to tentacle.

also, with your attack editor (the main window), the attack name will not be saved unless you press enter on it, rather than updating as you type it in, so if i filled out everything on a move, then moved to another scene/move, the name would not save, though the other info would.

Archive / Re: scene.bin ai size reduction project
« on: 2009-06-07 18:25:51 »
i know eligor is easy... it just has a massively high amount of ai it uses (basically repeating the same thing a million times). if you pump up it's stats it can be deadly though, as can any other enemy be if the game is balanced right.

peerless would be something i would give to enemies (stronger ones) as something similar to ffxii's paling, but for both phys  magical, and status resistance in one, and wears off quickly. however, manually setting enemies to be immune tho things with ai editing (setting phys/mag immunity on, dunno if status immunity is there/works or not yet) allows for a longer counter, which is dependent on their attack speed rather than in-game units of time.

i am not going to be adding anything yet, but after i finish up to and including air buster, i will be putting my mod up for testing (hopefully it shrinks to 248kb... it is close ^^), and starting my hard/balance mod up to air buster as well (kinda alternate between the two, compressing then making use of the compression. i hope you guys will help me out with the testing as well :-P.

the beta should be up either later today, or early tomorrow (3:30 pm here), since i will have to do school work here soon, which is very easy... my current class is an intro to programming course, teaching about pseudocode (not any actual language, just pseudo), and is my third full intro class, i have had a intro to java, C++, and half a COBOL class before this, all teaching pseudo as well, but i have to take this class to continue on... guess i will get another A then XD.

ok, the blood taste enemy's tentacle drain is physical based, and costs 0 mp, even though it seems as if it should be a magic attack in the ai (checks for mp as well). unlike it's previous palette swap, the guard hound, it cannot use the regular tentacle move. what i am thinking, is that it was normally supposed to have three attacks (bite, tentacle, and tentacle drain), and that the draining version was to be magical based with mp cost attached. if the ai supports this fully, it will be gaining an attack, and it's ai will be slightly altered from normal.

i think i will add the normal tentacle attack, and make it the attack used if it runs out of mp, essentially making it still use it's tentacle attack, just without draining capability, since the tenacle attack is stronger than the normal bite attack anyway. it will also replace the bite attack in another spot, where the possible double attack happens, making the second attack the more powerful tentacle attack, though it would only use this at lower life (commonly at least), so it is essentially a balancing attempt, but with weak enemies :-P. tentacle drain will be switched to magical damage, and the blood tastes given enough mp to use it a good bit, but i will not change their magical power, though i may have to reduce the atk power of the move to accommodate the type switch.

yeah... i checked, and if it were to just do a plain switch, it'd do ~78 damage a hit... if i reduce the power of the drain attack to 1 instead of 10, it'd do the same damage it does now, but in magical form. a really weak attack, but it would still be true to the original damage amount. then again i could keep it physical and just give it mp cost, but then it's magic power goes to waste... though at a 1/16 base power, at 255 magic and at lv 99, it'd only do ~130 damage, hardly anything. i think it will stay physical for now, but with an mp cost, since that works out the best overall.

also, i will be reversing all dropped/stolen items (not making steals drops, and vice versa, but the order in which they are gotten, making the rarer items drop first), since there was obviously a mixup in the layout, since some items are made extremely rare, some items completely missable after a certain point (vagrysk claw anyone?), when the rare item was supposed to be checked for first (giving the rare drops priority if the random number succeeded, instead of going through all common items first). this should help balance the normal drop/steal chances without actually changing the item or drop rates, making the common drops less common, and the rare drops more common.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-07 18:03:59 »
ok, this post is to bump you up (since you only seem to read my additions to my posts if i make a whole new one :-P), and to say that i noticed another little bug. if you start one one scene file's ai editing, and move to another without closing it, the total script size remains that of the first scene visited, or at least it did when switching from eligor's scene, since the total size was still around 3200 for a total size of 700 in the scene i went to.

i think you should make a popup that asks if you want to keep your changes if you use the x to exit, or open a new scene, though you said it has bugs when switching scenes before, and make opening a new scene file remove the current ai editor (with popup warning) and open the new editor, which would fix the counting bug (refresh bug, since it doesn't refresh?). if you made it so that PrC would check to see if an editor was already open, and ask to keep the changes BEFORE allowing you to switch to a new scene at all, to prevent the overwriting bug. it could be a possibility, i just don't know how you'd do that, since i know more about coding in vii's enemy ai than i do in a real language :-P.

Archive / Re: scene.bin ai size reduction project
« on: 2009-06-07 15:40:09 »
im slowly approaching eligor as well... he is where i am at in my hard mod (old one, pre-ai scripting knowledge), and inever found him to be difficult even in a normal game... his ai is really long for any enemy in the game (at the current ai level in vii), and i plan on shortening that :-P. MP and grunt had 861 bytes each... more than even GS did total, and they shrunk down to ~250 apiece, while GS is still around the same original size (about 30-50 lower, but still  :-)).

i think that the row being 16 is the "can't reach" row, but since there isn't any enemies that can fly out of range in the flashback, i dont think it is ever used. otherwise, he should always use fire3/firaga on an out of range enemy. either way, the only way to know is to have his ai active on someone in an out of range enemy battle, or set your row to 16 with ai and have the enemy use it on you (same thing, just reversed). i am almost 100% sure that 16 is out of range row, so i am guessing that putting sephy against a zemzelet or heli gunner for instance (zem would have to be flying), he would always use fire3 until they died.

warbaque... i think you should learn the way to program it with opcodes rather than just in the normal code form, since even if you know how it should look in written form, it won't help you if you can't code it. a good place to fool around with learning ai is the MP fight at the start of the game, just skip the movie (gypt instant yamp) with ctrl+s, run forward when able to, and test your enemy guaranteed, no need to worry about any other enemies possibly showing up. then, when you are done, or it craps out, just quit out and change/try again, taking little time between modifications :-P. and even if your logic is right, there could be little errors (such as using wrong sizes for variables) that would still show correctly in the disassembled view... the more you know about the coding itself, the better off you are. not that learning how it should look is bad, it is just useless without learning the coding along side it.

almost ready to put a beta up for testing, since air buster is a few enemies away. the kernel update issue in PrC happened again, but no biggie. air buster is going to be a fun one though...

wow... i just looked ahead to eligor's ai, and it has 2693 bytes used for it's ai... that is REALLY bad... and i will probably make the scene.bin shrink a size by editing it's ai alone... what were they thinking?

taking a quick look at the scene files again to remove enemies that aren't used in-game (grunt at shinra building for example). should give some more room. at 256 kb currently, it's last scene lookup is now 246, so it is getting pretty close to shrinking yet again. checked the cactuar battle, and it wasn't affected by my scene file hex editing (removed the grunts in it's scene, as well as in scenes 63/64 (erased completely/all FF file), since they were not used), so things got a little boost in shrinkage safely :-P.

Archive / Re: scene.bin ai size reduction project
« on: 2009-06-07 15:10:56 »
yeah... and i wouldn't recommend doing what i am doing, even to myself :-P. with programming the ai, there are many ways to do things, some are better than others, but none "have" to be done a certain way. you could intentionally make the ai do 10x the work to do something, but it could still get the same answer as something 1/10 the size.

the ai does a normal sized script in one frame of the game, so unless you loop things massively, or program really bad, and when i say this, i mean REALLY bad... like using 1kb for a common enemy that only has two attacks :-P, it shouldn't seem any different in-game.

Archive / Re: scene.bin ai size reduction project
« on: 2009-06-07 14:26:28 »
actually, you have them reversed... if (something) returns true whenever the number isn't 0, so 346456456 would be true, 0 would be false. if (something == 1) would only return true when something is equal to one, so only 1 will ever return true, nothing else.

well, if (something=/=0) would work as if (something), but takes an extra three bytes in the ai to do, opposed to the if(something) method. if you use if (not(something)) in the ai (essentially an if(something == 0) statement), it does the exact opposite, and is good for whenever you ned to check something against the value 0, since it takes less room in the ai to do.

yay... blugu lost 99 of it's 262 byte size >:D. heh... and it looks like smogger isn't too much different ai-wise from the blugu, just an extra check, and a few modifications to add to make it work. just like with the MP and grunt enemies, since their ai was exactly the same originally (except moves used and random chances... exact same size)... i love it when enemy ai is the same (at least for this mod... overall that isn't a good thing >_>).

Archive / Re: scene.bin ai size reduction project
« on: 2009-06-07 13:25:08 »
@nfit1c: i believe that row 16 is the "can't reach" row, since zemzelet sets its row to row 16 when it flies up. oh, and imagine a fully ai controlled party... that would actually be pretty fun to do for boss battles (big ones)... see how long your ai lives against... your ai :-P.

@warbaque:  that is essentially right, but a way to make your second statement right (since putting just one nonzero value, say 23 for instance, could be wrong, even though it is still non-zero) would be to make if (something >= 1), because it will always be a (positive) non-zero value, though just if (something is much easier to write, and saves space :-P.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-07 04:39:54 »
yeah, so if i added a good deal to the current materia stock, and it sent me over the psx file size limit somehow, i know where to remove from :-P.

no, my kernel is not read only, just checked it. i have had the scene.bin grow after editing only enemy stats/items up to the shinra building (grew at the 58th floor >_>), and is why i had to revert to the pc version (i did like the psx version more, but i m liking the pc one much more lately :-P). i kinda figured the scene.bin was as compressed as it could be, which is why i started my project XD.

Archive / Re: scene.bin ai size reduction project
« on: 2009-06-07 04:24:11 »
@nfitc1: yeah, many of the stats are underused, but i think that is because the game was massively rushed. i was planning on making my balancing/hard mod after finishing the compressed ai mod, but it seems that you guys are more interested in the hard mod right now :-P. i will probably start going back and forth between the two then, after either getting to air buster, or the end of the shinra building (boss galore), and working my way up to that point in my hard mod. i do plan on balancing out the game a lot, and the rarer statuses are definitely making the cut.

peerless will likely be item only (sans aerith of course), or on a late game materia, since it has too much cheapness for an early game ability. darkness will likely be placed onto a separate materia (kind of make separate materia for each specific status type, element type, etc, and it is possible that i will remove the X pluses, since they can definitely break the difficulty), making use of all the room i possibly can in the materia section. dual drain (sap) is likely to be added to the bio materia as bleed/sap, and mixed together with one of the bio spells (likely bioga, making a poison/sap combo which could be deadly, especially if an enemy has it).

@chrysalis: most mods make you start weaker, and make the enemies as strong as they can, but something that isn't usually done is lowering the character growth, thereby limiting the maximum stats you are able to obtain. mix this with limited/no sources, and you have much more room to make enemies grow, since the overall enemy stat average will need to be reduced as well. if you capped lv 99 strength at 70 or so, and removed ultimate weapon abilities, combined with reduced weapon power, then the enemies will not have to be made too much stronger to give you trouble. the lower you place your characters, the more room enemies have to grow without altering the game engine. if you were to make your people have the stats used in paper mario, without editing the base enemies at all, then it is likely that you wouldn't make it past the first fight, though if you did (possible), you are almost certainly not making it past the guard scorpion. if you take the normal character growth in ffvii, and pumped up the enemies even really high, an experienced person will still have little trouble beating it. if you slash your own people (not just abilities' power, but those as well as stat growths), that is a bigger boost than raising the enemies.

if all weapon power was halved (giving ultima weapon 50 atk and making it do normal damage), with a lv 99, 70 strength cloud, you would do ~2350 damage to a 0 defense enemy. as you can see, that is much less than the normal lv 99 9999+ damage, and if 4xcut were weakened as well, then it is likely that without critical hits, you wouldn't even hit the cap. this game has a lot of potential, and i plan on tapping into as much of it as i can, making enemies much stronger than you makes you need to use a strategy other than final atk+phoenix/raise, kotr, 4xcut (and 4xcut counter). darkness will be something that will be greatly helping you out, as will silence, though i will be making enemies change their patterns when afflicted with certain statuses. you can also increase the amount needed to fill your limit bar, making limits much more difficult to get, making things even more difficult.

also, since the ai can do pretty much anything (including change your immunities), it is possible to give you death sentence, possibly with other ailments, and give you immunity to death and immunity to restorative spells, making you a guaranteed dead man with no way of resurrecting yourself, since immunity would be preventing it. if anybody gets that, it'd likely be like a tonberry (knife attack XD), or northern crater enemy/side boss.

the only ai problem (not actually an ai problem, but something related to it) right now is the fact that animations need to be added to enemies to use other types of attacks. for example, the MP (guard at the start of the game) cannot directly use magical attacks, unless it uses it with either it's tonfa attack animation, or machine gun animation, since it wasn't made to use magic, and the actual magic attack animation will not be used, but rather it will show the normal attack done by the MP, but with the magic's effects. I do not know anything about adding animations, and is something that i would likely need help with, and even enemies that can use magic have camera oddities (camera doesn't act right... too slow or fast for the spell depending on the enemy's magic casting animation), but will display the correct magical attack animation. that issue will probably be the biggest obstacle to overcome once you know the ai language pretty well, but if you know how to edit their animations as well (their actual animations in the battle.lgp file, not the animations in the scene.bin, in case i confused you), then you are set, and can make anybody use any move.

when i do begin my hard/balanced mod, i will be testing it every step of the way to make sure everything is balanced nicely (especially since ai is in the mix, though i still always test my work for a while), and if it doesn't suit my needs/others' needs, i will raise the difficulty accordingly >:D.

@warbaque: basically anything is possible with ai if you are creative, though you have limited space (not that any enemy even reached the limit in the normal game, but with mass modifications to power bosses, it *may* be reached, though i still doubt it :-P). increasing the exp/ap is fine, but only if the enemies are getting a nice boost as well, and if you can still easily take everything down, then it isn't good enough >:D. you can easily set the enemy ai to use flags, create custom stats, give auto statuses, bring them back to life automatically when killed the first time (still working out the bugs for multiple times, and i do not know how to fix invisibility, but i know how to avoid it :-P), attack multiple times a turn, and other things as well.

some things that may be possible via ai is to make other enemy battles appear after finishing the fight (i know it can be done by editing the scene file, never looked into doing it via ai), allowing for multiple item steals, such as making it allow you to steal again, and possibly adding different items to be stolen depending on certain conditions (i would love this, and it is likely possible since exp/ap can be set in ai), as well as changing dropped items (again would love this, many different possible uses, such as different drops based on level, or based on your actions in battle). like i said, there is much possible through ai, i would need specific examples to know if it could be (currently) done or not... i am also going to try to figure out as many unknown variables as posible, for even more flexibility with the ai, i already know the invisibility flag (it may just disable the idle animation... possibly resetting the idle animation would bring it back?), the flag to keep the enemy from using the normal death animation, and the magic counter (it counts the amount of times you are hit with magical attacks) variable, though i sadly didn't find any physical/general version of that... they may be with the magical one, and i just set it up wrong, but i am not too sure on that...

but yeah... if you have an idea that you would like to know if it could be added into the ai, just post it here and i will see what i can say about it (still learning myself, but i think i am doing ok :-P).

whew... a long post, but i think i covered everything (hopefully...).

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-06 21:52:36 »
hmm.. nfitc1 has a nice kernel compression, but the scene.bin compression isn't as good, but then again a ton of crap compressed is still a ton of compressed crap :-P. at least the kernel ai doesn't have to be messed with, though plenty can be taken out since cloud's ai for ally death is useless since the ally death thing doesn't work.

the best way to go for updating the kernel with a new scene.bin is either with PrC (if the bug, if it is a bug, is gone), or using hojo then opening/saving with WM. whatever works i guess.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-06 21:36:26 »

Can we keep this topic solely on PrC and its fixes/bugs please? It would be ever so helpful to me in finding issues that need to be resolved. Any AI Editing-related comment should be in a different thread. Please only post in here if you have a problem with PrC or would like to see something added. It is getting too crowded in here.

Thank you.
i was trying to... i even made my own thread and posted the link to it, but it seems that people like to crowd your topics :-P. something buggy i did notice is that when the scene lookup was off (from shrinking too much), and i allowed PrC to fix it, every time i saved it after that it kept popping up with the same message box, so i am guessing that the scene lookup fix isn't quite working, because when i opened it and updated via hojo and came back here, the scene lookup was apparently fixed. it could possibly be that it doesn't update the kernel as being fixed until after reopening the scene.bin, since i only reopened after coming back from hojo.

also, not directly related to PrC, when i updated a fresh kernel with my mod, the file size actually grew, so that it wouldn't fit into a psx iso (testing to see if def was doubled in the psx one... it is btw), but when i opened it with WM and just saved it, the size became SMALLER than it originally was... what is up with that?

everybody can spam me instead... i dont mind ^^.

Archive / Re: scene.bin ai reduction project
« on: 2009-06-06 21:29:49 »
but, that is where the ai is pointing to. if sleep and paralysis were right next to each other bitwise, then i would probably assume it was a mistake for the ai to use paralysis (even though it is used multiple times in the ai). also, you do not have access to anything to remove sleep for that matter, though it is removed by being hit, so no big difference there. also, they can only use it about a third of the time IF the ai takes a few turns beforehand.

basically, the first turn it is possible (a 1/4 chance then), then after that it has to take up to two more turns until the 1/3 chance activates, and if the chance fails, then they have to wait another two turns for another 1/3 chance, so it isn't like they will be using it very commonly on you either way. they do come in groups of 2-3, so if all do get it on the first turn (a 1/64 chance), they have a 80% chance on contact of paralysis landing (essentially an overall 1/125 chance of all three getting paralyzed), so not very likely, and if all three do somehow use it, there is about a 50% chance that all three will be affected... not too good of odds of it happening.

also, another oddity is that hell bubbles has an attack power of 12, but does no damage, while silk has no atk power, but calculates damage... maybe a mixup, and these guys were supposed to damage and paralyze you (kind of like a magical cross-slash?). so many unknown things going on...

ok, about your post in the PrC thread, it is possible to set whatever in-battle flags, since many enemies do that normally (an example is the mono drive, which prints a warning/enemy sighted dialogue box at the start and attacks after that, never displaying the message after that. also, the programming logic for the enemy ai is much different from most programming languages you may be used to. the best way to learn it is to look at other people's coding, though the ffvii ai used initially is usually lain out in a very unusual and inefficient way for many of the enemies, but mine is also hard to follow because i program weird, but in an efficient way :-P.

ok, the blugu enemy is a mess of an ai... i should get a good bit of shrinkage here, but it will take some time, unlike the previous three enemies that were actually half decently done. i also noticed that some enemies actually share ai, showing how rushed ffvii was, since the ai was barely even made to be efficient, much of which isn't even properly working, something that only hackers and those who made the game (sans adamantaimai bug) would notice, since things work normally otherwise.

paralysis only lasts 8 units of time, while sleep lasts 26, so being unable to smack yourself out of it is a fair trade.

Archive / Re: scene.bin ai reduction project
« on: 2009-06-06 20:16:45 »
i know they are stupid, but i have a "no fool left out" policy, so even crappy enemies are given what they were meant to have :-P. an infinite loop is not really good anywhere, and giving them two castings is nice, since they appear in groups of 2-4, is plenty. now, you can have magic evade to lower the chances (not by much, but still) of being hit, and this is (hopefully) going to be a base for other mods, so it is possible that they will have other types of equipment available, as well as the possibility for different materia, so it is possible that slow could be prevented, then no matter how powerful they were made, they would NEVER attack, this is just a bug fix.

also, i updated the mono drive to check fire's mp cost (actually, people will have to change the ai for new moves anyway, so that it checks for the new move's mp instead), so if fire were to be upped in price, there would never be a "out of skill points" message appearing, they'd just physically attack the rest of the fight. only cost me one (not two ^^) byte to add, so no big deal, more friendly than the other way. going to work my way to corneo's mansion before any testing, to speed up the process, and test in one fell swoop.

ok, another predicament... the blugu enemy's ai is set up around checking for paralysis in combination with it's hell bubbles move (to see who is attacked with it), but hell bubbles causes sleep... so either i change the ai to check for sleep, or else i change hell bubbles to cause paralysis instead (easier actually). since i am basing things off of the ai, hell bubbles will now cause paralysis instead of sleep, and paralysis is worse because physical hits will not cure it.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-06 19:48:45 »
this should have been a post in my thread, since i moved over there to keep his thread clean...

first off, i am not really changing any enemies at this point in time, but when i do change things, i plan on reworking a lot of things. for starters, the initial level would be 1, but other mods do that, but i am going to rework the stats to be much lower than normal, sans maybe hp/mp, and make sources harder to obtain (no easy morphing... if anything they would be a rare drop from strong enemies, possibly rare steals as well from other things, but no way to easily stock up). weapon power will take a hit as well, so even at higher levels things will be troublesome (and ultimate weapons will be losing their mass damage boosting, being replaced with normal or other attack mods, but with a higher atk than the rest, and added effects as well), and the enemies will be pumped up, so not only will they become stronger, you become weaker, making extreme damage unlikely.

kotr will also be severely cut down, making each attack weak separately, but will still add up to more than the other summons. enemies will not have guaranteed stats, since i plan on implementing a levl up system for them, automatically using their ai to boost their statuses (levels and such, giving a random amount per level, so each enemy will be different stat wise, and it is possible to fight enemies ranging a few levels below to a few above you, but with a definite minimum, similar to ffviii's levelling system, but i plan on making it better :-P), and change their ai patterns based on their levels. when i finish my true mod (this one i am doing is just for a base that will be easy for anybody to build from, and should always fit back into the psx version unless you massively change the ai, since the size will be significantly lower, allowing for more changes to be made), it should be in no way easy, and tweaking the game after that shouldn't be too hard to do, so if it isn't hard enough, just a few modifications and it will be >:D.

my mod will take a LONG time to complete, especially since i am doing this one first, but when i am done it should give you a challenge :-P. and yes, the enemies will be giving less experience as well, and hopefully i can find something in the ai to check/set the current steal/drop item, so that i can also change the items gotten at will, and possibly give multiple steals from enemies.

Archive / Re: scene.bin ai reduction project
« on: 2009-06-06 18:35:53 »
no, no, i meant that i would like to turn it off through the core of the game (probably in the exe or something, just dont know where atm), only GS has that for now, as well as any other def setting enemy i stumble across, so it shouldn't happen to too many other enemies. i am just adding it to make the ai work more accurately for me, thats all.

i have finished checking all of the enemy ai (actually finished last night) up to and including GS, so if you or anybody wants to test it out, just tell me. i know the first instance of each in the scene.bin "should" work, since i already directly tested them, but any that i had to copy the ai to may not work, since it was all manually retyped back in for each one.

sides... it'd take 36 bytes to halve both defenses (18 apiece), and per enemy would quickly build up... if i were to change it in the core, if it were, say def x 2, then i just make it def x 1, and not have to remove anything ^^.

wow... ok, grashtrikes ai is set up to check for any non-slowed enemy and use silk on them, if they have enough mp to use it, however their silk attack does not cost any mp at all, since they have 0 mp. if you follow through their logic, they will ALWAYS use silk until the enemy is slowed, even if they cannot be slowed, causing a potential loop there. also, their next step checks to see if an enemy is slowed, and chose a random slowed target if they are slowed, and if not, then chose a random target. now, if all people do become slowed, they will begin to attack (no sooner), and will always target a slowed person (all are slowed anyway), so i have a predicament.

either i give their silk move mp cost, and give the grashtrikes mp as well, going against my normal rules to fix an issue (to make it as close to intended as possible), and be able to barely reduce the total ai, or i keep the potential loop and get a bigger ai reduction. i think it is time i have to break my rules a bit :-P. actually, i DID say that i was trying to make it as close to what was intended as possible while fixing bugs, and this can be seen as an ai bug (more of an oversight actually), so i guess its time to fix it up >:D.

ok now, how much mp to make it cost, and how much mp to give them? their base chance to hit is 90% (with guaranteed infliction on hit), so with no magic evade, it will usually hit, and if you are immune, they would use it however many times each to try and slow you. my guess is that allowing each to be used twice max is pretty good, any higher would make them take too long before attacking. also, mp cost should be at, or a little lower than normal slow spell, probably lower since it is kind of a "natural" ability for them, though it could be 255 mp cost for all i care, and i could give them 510 mp, but that is kind of pointless. meh... normal is 20 mp, but i think 8 is good :-P.

hmm... i made GS so that he is hacker friendly when changing stats, but so far with enemies using mp (those that check their remaining mp), i have not made it friendly there... people will have to manually change the check in the ai (only need to change one value, but still) if they change the mp cost of the abilities used... an auto check is possible easily, but takes more room to do, only about 2 bytes more though :P. i will have to make sure all mp using enemies have the check for the move's ability, but if the move is removed, then problems may occur, so it is kinda lose/lose either way.

it also seems that they were originally supposed to cause damage with their silk attack since they have magic power (enemies that don't have magic attacks have no magic), and their silk attack is set to do magical damage, but with no attack power for the move (unlike normally where it is set to "no damage calculation"), but i will not be adding that in, at least not right now, and if i did it would do very little damage.

Archive / Re: scene.bin ai reduction project
« on: 2009-06-06 00:07:45 »
i dont need it to be gone for this mod, since my GS already works by halving it initially, i just really want it for my future mod :-P. any other enemy can have it too, but it just takes up more room this way.

Archive / Re: scene.bin ai reduction project
« on: 2009-06-05 23:14:35 »
i thought i read about barriers in the one post on the proud cloud thread... i dunno what i was thinking about then :-P.

and i know the difference isn't much, but i want it to be exactly the same initially as the original in performance and stats, with only things added to fit into the original ai, like adding cure to adamantaimai, and giving smoke shot from the sweepers the ability to add darkness, since their ai checks for enemies with the darkness stat when selecting a target for smoke shot, that means it was originally supposed to add darkness, and they just forgot about putting the status change on the move :-P.

i know i am being picky, but i want everything to be as close to the original ai as possible. if it was supposed to set defense to 333, and an easy way would set it to 350, i wouldn't accept it, even if it took half the space to do. i'd have to check to see if doing it your way would even save much if any space to begin with...

ok, if i were to use yours, it would be much smaller, but if i could remove the auto def doubling, then i would only be a small bit bigger, and produce much more accurate results compared to the original. you could consider removing the auto double as going against what i am trying to do, but every other normal stat caps off at 255, and yet the defenses are automatically sent past their cap at or over 128 defense, and this feature is what will cause me issues throughout every enemy that has a def change in battle, and will plague me through any future mod i do. to me, removing it is like removing a bug, since your character's defense does not get doubled initially, and there is the move dragon force, which is used by an enemy, meaning defense was not initially doubled for enemies, else this move would not be an enemy skill (it raises the defense mod, essentially increasing your battle defense). i think that the def doubling was a last minute addition to try to increase the difficulty, wich didnt work too well (the game was rushed too much).

only problem... i have no idea where to go to turn off the auto doubling <_<.

Archive / Re: scene.bin ai reduction project
« on: 2009-06-05 22:42:10 »
ok, the initial stats are 40/300 when doubled, and without reducing the 300 mdef to 256, it is already different from the original version. now, adding the barriers, if i allowed it (still makes it different, since the barriers are visible, and normally it has no barriers), the mdef (if reduced to 256 first) would basically act the same as 384 mdef, but the 40 def would act much higher than the normal 255 it is given during the 2nd stage (276 != 255 :-P), and if the initial 300 mdef were not reduced, then it would act like 406 mdef.

yes, that would be a shorter way to do it, but it is still not the same as the normal game unless you alter the initial stats of the GS (i am not altering any enemy stats, only moves when needed, stats are staying the same), or reduce the stats in battle. as i said, i am trying to make this mod as close to the original as possible, no stat changing (only moves if needed), and keeping the ai as true to the original as possible, and adding a status to the GS would defeat the purpose, even if it did something similar. now, when i finish this and get to my hard mod, then i will definitely be doing whatever i can to make the ai as compact as i can while doing what i want, but even then i probably would make the barriers a last resort, especially since i plan on implementing a way to make the enemies level as you do (not all will level every time you do, and stat gains will be from a random amount to give variation... a big pre-battle for every enemy, that is different every time... have to set all enemies' base stats to level 1 as well, so that enemies do not get too pumped up if they are already souped up a ton. this will be a while from now though, and i plan to make it as evil as i possibly can :-P), and giving certain statuses/resistances to enemies, as well as certain new moves as they become higher level is a priority >:D.

ok, current progress (will eventually add a text file listing changes as it gets farther along):
name:               original ai size:     new ai size:
MP                    861                  227
Guard Hound      256                  114
Mono Drive        418                  190
Grunt                861                  234
1st Ray              42                    42
Sweeper           161                  131 (main) (added darkness giving ability to it's smoke attack, since the ai is based
                                               9 (pre-battle)  around you being blinded from it, 100% inflict with 75% atk accuracy)
Guard Scorpion   62 (pre-battle)           90 (pre-battle) (relative defense boost added, halved defenses first*)
                        701 (main)                 645 (main)
                        23 (general counter)   23 (general counter)
                        45 (death counter)     33 (death counter) (removed hurt anim. setting)

*both versions apparently double defense before the battle begins, halving it is so that the defenses can be made to be exactly the same as the original, but with added support for those who wish to edit the enemy stats, since normaly GS would have set defenses no matter what you changed his defenses to. guard scorpion will add 106 to the base defense now (it's base 150 mdef will become 256, the normal stage 1 mdef for it), and in the second stage, it will add 235 to def, and another 128 to mdef (becoming 255def/384mdef at normal stats). the min/max for these values at each stage is 255d/361m in stage one, 490d/489m in stage two.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-05 21:56:26 »
no defense doesn't become absorbed (damn >_>), you just act as if you have 512 def, since the amount of damage would always be lower than 1, and the game makes you deal one damage if damage < 1, and enemies weak to an element take double damage, so 2 damage :-P.

adding barrier defeats the purpose of my mod, since i am trying to give the enemies an exact replica of their ai/stats, just with bug fixes, things left out (sweepers smoke shot not adding blind, when blind was definitely intended as an example), and making stat changes hacker friendly. barrier is adding something not normally there. yes mbarrier/barrier would halve the damage, and would only really work for the second stage (a little more reduction for defense), but the first would still be off.

also, talk in my new thread, not here, so we keep his thread clean-ish :-P it is located here:

this mod will attempt to keep the enemies acting as close to the originals as possible (with some small additions as necessary), while rewriting the ai to be as small as possible, to shrink the overall size of the scene.bin, and to make the code as optimized as possible, all while fixing ai bugs :-P. This is not a hard/balance mod, but rather something that can be used as a base for other mods and such, or for those who just want a bugfixed version of the original.

the size is being made smaller so that other mods will be able to safely add to it without having the space issue the psx version has, allowing for more people to use these mods. the size should become small enough over time so that you should not be able to make it become too large for the psx iso unless you were to add a massive amount to the ai, and i mean a LOT.

Current Release: v0.1, with changes to enemies up to air buster (game order, so the first two reactors :P). here is the link:

Current Size: 256kb, but quickly approaching 248kb

each release will also have an updated kernel.bin (only for if you are not using a modded one), a list with the original/current ai sizes of the enemies, and a file to help people test the ai (if they wanna help me out  :wink:), showing every possible outcome the enemy will have, as in what it will do in one turn, on who, etc.

as of right now, 21 scene files are now empty (as in filled with nothing) that had no enemies used in-game, such as dummy enemies used during testing, as well as an enemy from a scene that has enemies that are used in-game. it is likely there are more to remove, but i haven't checked too far into this yet.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-05 21:13:10 »
it wouldn't work because i am using the original stats, not lowering the initial mdef, and i am making it so that people can raise/lower it's defenses as they desire and still have it work fine, without ever making damage pretty much immune. so what i get is the original 20/40 def, 150/300 mdef, and have to make it work for ANY defense values entered by other people. if this wasnt added, def would always be:

1st - def = X (not changed until second, max 510), mdef = 256
2nd - def = 255 (possible reduction), mdef = 384

mine has a min/max of this in the forms:
1st - def = 0/255, mdef = 106/361
2nd - def = 235/490, mdef = 234/489

meaning that if i used your way, this is how things would be min/max:
1st - def = 0/510, mdef = 0/510
2nd - def = 215/725, mdef (+128) = 128/638, mdef (x1.5) = 0/765

if someone were to raise the defense using yours, they would definitely max out defenses in the second form, and the 1st form could get relatively high as well. i want the def to be raised to equal the normal setting, AND be able to be freely changed without maxing def (512+), and my way seems to work the best. the double def that the engine does is really annoying to me, since you have to work around it, and setting def to max pretty much assures a long, not necessarily hard, battle, where the initial def max would allow you to actually do a decent amount, and then it would make the editor think of other ways to pump up the enemy.

i really should start a topic of my own, so nfitc1 doesn't get flooded with things that aren't about his program... wait... too late :-P.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-05 20:14:58 »
the problem is that when using a relative boost/redux to alter stats with the ai when the def is auto boosted makes it hard to make the defense not cap out fast, or become too low compared to what it normally would. for example, i have GS adding 106 to the 150 (doubled to 300 in game without my initial def halving) to make it hit the normal 256 mdef at it's initial stage (no counter), def is the normal amount 20 (doubled to 40), and then adding another 128 when it goes to the countering stage (hitting 384 normally), and it's def adds 235 to hit 255 def (275 if i didn't halve them first). now, if i didn't set it's defense to halve (both), here is how things would look at different defense values:

initial stats
base def (b4 doubling) -> 20
base mdef -> 150
stage     def     mdef     half def     half mdef
normal    40      406      20            256
counter  275    534      255           384

an example of increased def through enemy editing
base def -> 128
base mdef -> 255
stage     def     mdef     half def     half mdef
normal    256    616       128          361
counter  491    744       363          489 (capped here)

max def run
stage     def    half def
normal    510    255
counter  745    490 (capped)

as you can see, with the innate def doubling, defense values get way too high for a relative defense boost mimicking the regular game's setup, and even if i reduced the initial mdef by 44 to hit 256 (300-44=256), it would still hit the max as soon as someone put the mdef to 214, and def would still eventually go over max as well. it could be made to reduce more as the base rose, but there would be gaps where the def didn't raise as much, and would take much more room in the ai. simply put, for how i am looking at it, removing the innate def doubling would be a great addition, because you can always toughen up the enemies without going past 255 defenses, as in making them level up, add more life, better ai, stronger hits, and then there is little need for a ton of defense.

not too many attacks would be going past 12000 damage a hit, and enemy hp can go extremely high (if all four bytes of hp for the enemies are able to be used, then they can have up to 4294967295 hp, otherwise it would cap at 16777215, either way, more than enough to not need massive defenses, especially since this isn't ffx where you are pretty much doing 100k a hit, and 16.5 million is a lot of hp, more than any good enemy in vii should ever need), so 500 defense is overkill anyway... if you want an enemy to be immune to a type of attack, you can always either make them null physical elements, or use the ai to turn certain immunities on. that's why i think the def should not be auto doubled, since we no longer need it enabled (didn't really help much anyway since enemies were normally weak anyway).

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-05 17:50:07 »
both def and mdef are doubled by the engine, and yes it is true that enemies would need less room to have their def to go up to 510, since it is doubled initially. but, the thing is, enemies shouldn't need to almost null damage (255, the base max for the defenses halves all damage, except def ignoring things, and 510, the doubled max, would take the damage to pretty much nothing, around 1-100 for powerful attacks, since the damage done is damage = damage * (512 - def) / 512, making 10000 damage taken down to  ~40 damage dealt, a really big decrease. if an enemy had that much defense, then it is likely that they wouldn't have much life, or the fight would be really unnecessarily long, especially since hp can go pretty damn high.

yes, an enemy with 400 defense (200 base) would still take plenty of damage, but if you had a good ai, great moves, and ample hp on it, then that high of defense wouldn't really be needed. the main problem with most of the vii fights, is that the enemy ai is too simple, and their moves too weak. many enemies are too low level to be doing a ton of damage, and some at very high levels would still be very easy since their ai sucks. if you balance out the game well, and make it hard from there, then mass def boosting isn't really necessary, just overkill, and making the fights much longer than needed to be.

i guess that the def doubling is good for now, and will still be needed when my first compressed ai scene.bin is done, since the enemies will still be essentially the same, but when i make my REAL difficulty hack (want this done so that i have plenty of breathing room, and so that psx version users can still enjoy my hack, since it should still fit into the original iso easily), i am hoping that i will have a way to stop the initial doubling, even though it is likely many enemies late-game will be hitting the higher stat marks, and the end game optional bosses will definitely be taking roids, so only a few enemies should need past 255 defense, if they even really need it at all. usually, if you know the enemy ai very well, and have a very nice setup, you should eventually win anyway, but my hack is going to be cruel to the users, so massive defense would just be too much :-P.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-05 16:14:44 »
it would require that, since there isn't an editor i know of that can directly copy the ai (even this one... i have to manually retype ai for each new enemy, or hex copy it in, and manually rechange the pointers there), so the best way would be to extract all 256 scene files (in my scene.bin there are currently 19 blank scenes, and some more i know i could delete some enemies from, but not the entire scene data), and hax edit the new ai values in from mine, which isn't too hard to do if you know where to copy from, and it'd be a direct paste, filling the extra stuff with FF (null) values, and since the scene.bin is 256 compressed scene files, more of the same value (in this case FF) causes it to shrink much better.

currently with the first reactor's enemies alone, up to and including the guard scorpion, i shrunk the ai 6816 bytes, removed 12 useless scenes (big save in size), and the current scene.bin size is 256 kb (reduces/increases by 8kb whenever it needs more room or has enough free space to shrink, it doesn't directly shrink as it is changed, i.e. a 1kb reduction to a 256kb scene would either become a 248kb scene (if shrunk enough overall), or stay at 256, but with a good bit more room for editing in that area).

guard scorpion actually grew, but this is because i made it more def change friendly, meaning it has the usual in-battle defense, but usually you could make both defenses 255, and it would still have the same def in-battle, since the ai set it to an exact number, not to a relative increase. a section was added to halve the defense (since both games apparently double enemy defense before even the pre-battle ai takes place (likely a core thing), and my ai now halves it, making the defense change more relative, and allowing it to be raised/lowered as desired in an enemy stat editor). once i know how to change the engine to not double the defense anymore i can shrink the size, and if i kept the original direct defense setting, i could actually have saved about 10% of the space that GS takes up (it's ai has a big portion of dialogue in it, wich is where much of the size comes from), however my goal is to make it as hacker friendly as possible, though it will still be good for normal users, just fixing ai bugs and such.

actually, shrinking the ai could improve performance in-game, since a smaller ai takes less time to be completed, causing less wait time between attacks, though most people will not really be able to see the difference. wait time, as in when a move causes the atb to stop isn't what i mean, i mean the time it takes to finish the ai script. smaller ai also means more room to add more to the ai itself, not just the stats, without making it go past the psx size limit :-P.

i think i will make my own thread when i completely finish with the reactor (going back over the ai to see if they can be modified more, and i know some definitely can be), and have some people test them out to see if there are any bugs, but there shouldn't be any in the original enemies i added... just the copied ones since i had to manually retype them, and didn't test them after that :-P. the first reactor enemies are also (most anyway) in the sector 7 train graveyard, and have different formations there, so testing there would be nice as well. if anybody wants to test it, since it wouldn't be a completed release, i will email the scene.bin to you if you want them, becuase i don't want a lot of people wanting them too fast, since it will be a long time until i complete this little project >:D.

FF7 Tools / Official Proud Clod 1.0 Topic
« on: 2009-06-05 13:24:11 »
and i am in the process of making a scene.bin for the psx (or pc for those who want it) that massively shrinks the ai while doing what the ai was intended to do (as well as fixing bugs), so that psx users do not have to worry about this problem too much. though my style of ai editing is a little weird, so those wishing to add to the ai could have trouble, unless they start from scratch :-P.

however, those who only want to change basic stuff, such as stats and enemy moves (not so basic for the moves) should have no limits in the psx one, unlike they do now. gonna take a while, but will eventually get done :-P.

and yeah... unless you know how to program the ai, you aren't going to be able to with this editor... it takes some learning to do.

Pages: 1 ... 5 6 7 8 9 [10] 11 12