W
warbaque
Guest
I recall NFITC1 mentioning somewhere in WM thread about using more efficient compression method than default.
- Status
K
Kudistos Megistos
Guest
This is true; it's a good thing as well, since it means we can add quite a bit to the kernel and still make it fit into the PSX ISO.
S
secondadvent
Guest
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 
. 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.
. 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.
Last edited:
N
nfitc1
Guest
KERNEL.BIN look-up fix needs to be addressed. That's a feature that is very important to the function of the game so it'll need to work. It might be that the KERNEL.BIN you're trying to fix is read-only. By default, the PC's KERNEL.BIN is, but the kernel2.bin is not. I'm accounting for that in WM, but I'll have to check PrC and see what it's doing.
In regards to the compression of the scene.bin, I haven't really done much testing. Scene.bin is compressed with the highest level of GZip like the KERNEL.BIN is. The scene.bin doesn't ever get larger if small changes are made so I didn't bother to look at it.
On the subject of character AI, only Sephiroth's scripts and Vincent's Main script are important. That's all mentioned in the WM topic, though.
In regards to the compression of the scene.bin, I haven't really done much testing. Scene.bin is compressed with the highest level of GZip like the KERNEL.BIN is. The scene.bin doesn't ever get larger if small changes are made so I didn't bother to look at it.
On the subject of character AI, only Sephiroth's scripts and Vincent's Main script are important. That's all mentioned in the WM topic, though.
S
secondadvent
Guest
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 .
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). i kinda figured the scene.bin was as compressed as it could be, which is why i started my project XD.
.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
). i kinda figured the scene.bin was as compressed as it could be, which is why i started my project XD.
S
secondadvent
Guest
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 ), 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.
), 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
.
N
nfitc1
Guest
I can't capture the "use X to exit" event because that's on the OS level and not on the program level. I just need to get rid of the X button all together. I also need to make a list of things that will need to get fixed.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
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
I could easily tell if an editor's open though by adding (yet another) invisible true/false value... I'll look into it.
S
secondadvent
Guest
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. 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.
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
. 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.
Last edited:
N
nfitc1
Guest
I fixed quite a few of the attack animation-related bugs you've brought up and changed the format at little. Have a look.
Hopefully there will be another tab soon that will deal with formations, but that'll come later.
Hopefully there will be another tab soon that will deal with formations, but that'll come later.
S
secondadvent
Guest
looks pretty good :wink:. glad you added the manipulate thing as well .
have you ever figured out what as wrong with the kernel updating?
right now i am trying to understand air buster's ai fully, i have most of it down, but some other things are plaguing me still... have to filter through the ai to see what is going on with them.
.have you ever figured out what as wrong with the kernel updating?
right now i am trying to understand air buster's ai fully, i have most of it down, but some other things are plaguing me still... have to filter through the ai to see what is going on with them.
N
nfitc1
Guest
Yes. I forgot that it doesn't directly fix the KERNEL.BIN, rather it makes a KERNEL.BINtest, or something like that, that needs to be renamed. This is mostly a "oops" on my part as I forgot to undo that. The KERNEL.BINtest should be correct, but I didn't test it very extensively (hence the "test" at the end). If you can confirm that it's correct I'll remove that "feature" (since it IS documented) and just rewrite the KERNEL.BIN instead of creating a new one.
S
secondadvent
Guest
i will compare it to an exact hojo copy that was resaved in WM and get back to you shortly (possibly create kernel files and manually check there, in case it somehow compresses differently) 
.
also, kind of a little thing for my stupid mistakes i make occasionally... could you add a disassemble check that returns an "error in code" message in the disassembled code if someone enters two values to the top of the stack then tries to use the 90 opcode? this makes it so that stupid errors like this are prevented, because you are supposed to store the first value into an ADDRESS, not a value, and i do this once in a while still. it would also prevent those new (or doing my mistake) from making this error, so that they know to fix it when it is done. not necessary, but i was wondering if it could be added >
.
also, where is a good site to upload files, so that i can up my files when i am ready? i know of a couple but wanted to know one that preferably allows you to update your files (instead of just upping a new file), and that doesn't require registration
ok i did a plain comparison (from a resaved kernel to the test kernel), and there were many places different, but i sort of expected that. i will first extract all of the files from each into a separate folder and compare them one at a time. i may also compare it to a freshly changed one from hojo's updater to see if it is just the compression of WM setting the differences.
ok, just by opening the test kernel in WM, it displayed this in the debugger:
Code: [Select]
i will try to make kernel pieces to possibly pinpoint the areas with problems.
.also, kind of a little thing for my stupid mistakes i make occasionally... could you add a disassemble check that returns an "error in code" message in the disassembled code if someone enters two values to the top of the stack then tries to use the 90 opcode? this makes it so that stupid errors like this are prevented, because you are supposed to store the first value into an ADDRESS, not a value, and i do this once in a while still
. it would also prevent those new (or doing my mistake) from making this error, so that they know to fix it when it is done. not necessary, but i was wondering if it could be added >.also, where is a good site to upload files, so that i can up my files when i am ready? i know of a couple but wanted to know one that preferably allows you to update your files (instead of just upping a new file), and that doesn't require registration
ok i did a plain comparison (from a resaved kernel to the test kernel), and there were many places different, but i sort of expected that. i will first extract all of the files from each into a separate folder and compare them one at a time. i may also compare it to a freshly changed one from hojo's updater to see if it is just the compression of WM setting the differences.
ok, just by opening the test kernel in WM, it displayed this in the debugger:
Code: [Select]
Code:
See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box.************** Exception Text **************System.OverflowException: Arithmetic operation resulted in an overflow. at WallMarket.Form1.GUnZip(Byte[]& byteCompressed) at WallMarket.Form1.SeparateFiles() at WallMarket.Form1.Open_KERNEL(Char kernel) at WallMarket.Form1.OpenKERNELBINToolStripMenuItem_Click(Object sender, EventArgs e) at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e) at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ToolStrip.WndProc(Message& m) at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)************** Loaded Assemblies **************mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll----------------------------------------WallMarket Assembly Version: 1.2.1.0 Win32 Version: 1.2.1.0 CodeBase: file:///C:/Documents%20and%20Settings/ryu/Desktop/ffvii%20hacking%20tools/wall%20market/WallMarket.exe----------------------------------------Microsoft.VisualBasic Assembly Version: 8.0.0.0 Win32 Version: 8.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll----------------------------------------System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll----------------------------------------System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll----------------------------------------System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll----------------------------------------System.Runtime.Remoting Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll----------------------------------------Microsoft.VisualBasic.PowerPacks Assembly Version: 9.0.0.0 Win32 Version: 3.0.30214.0 CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic.PowerPacks/9.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.PowerPacks.dll----------------------------------------Accessibility Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll----------------------------------------System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll----------------------------------------System.Core Assembly Version: 3.5.0.0 Win32 Version: 3.5.30729.1 built by: SP CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll----------------------------------------************** JIT Debugging **************To enable just-in-time (JIT) debugging, the .config file for thisapplication or computer (machine.config) must have thejitDebugging value set in the system.windows.forms section.The application must also be compiled with debuggingenabled.For example:<configuration> <system.windows.forms jitDebugging="true" /></configuration>When JIT debugging is enabled, any unhandled exceptionwill be sent to the JIT debugger registered on the computerrather than be handled by this dialog box.
Last edited:
N
nfitc1
Guest
I tried and tried and tried and got it to do this by adding two little lines in the handling of code 90h. Yeah, no big deal.also, kind of a little thing for my stupid mistakes i make occasionally... could you add a disassemble check that returns an "error in code" message in the disassembled code if someone enters two values to the top of the stack then tries to use the 90 opcode? this makes it so that stupid errors like this are prevented, because you are supposed to store the first value into an ADDRESS, not a value, and i do this once in a while still
Good luck finding one. I use FileFront and they require you to register and you can't just update files (yet).
You'd really only need to compare the KERNEL.BIN2 files since that's where the scene look-up lies.
Yikes! It failed to GUnZip?! That shouldn't be possible unless Hojo's writing it wrong.... Can you send me the Hojo'd KERNEL.BIN so I can test it please?
S
secondadvent
Guest
yeah, no prob, i'll send it to you shortly. this is what i got when i compared the two kb2 files: 0xf1d=3869 to 0xf3c=3900 (32 bytes), so there is a difference in that area. i do not know much about the kernel.bin, so i do not know what this area is.
i was planning on using filefront (everybody else here does) anyway, but i dont like to register >_>.
edit: ok, i sent the original hojo, the WM saved hojo, and the test versions to hopefully help narrow down the problem, and let you see the differences better.
i compared all of the files to check to see if something caused errors in the rest of the files, just in case some oddity happened somewhere, but luckily there were only changes in the kernel2 file.
oh, and once i finish my current version of my mod, i am going to focus on figuring out some of the unknowns in the ai, especially since there are many used in the ai at a later time (the closest i know being the sample boss in the shinra building). hopefully i can add more options to what we already have available >.
oh, and the debug message popped up when i opened the test kernel with WM... that is something caused by PrC's updating. hojo's files always open nicely without any errors, but the size is usually bigger because of the lesser compression used.
update: i found the other kernel0 file... it got mixed up with my other files where it extracted :|
i was planning on using filefront (everybody else here does
) anyway, but i dont like to register >_>.edit: ok, i sent the original hojo, the WM saved hojo, and the test versions to hopefully help narrow down the problem, and let you see the differences better.
i compared all of the files to check to see if something caused errors in the rest of the files, just in case some oddity happened somewhere, but luckily there were only changes in the kernel2 file.
oh, and once i finish my current version of my mod, i am going to focus on figuring out some of the unknowns in the ai, especially since there are many used in the ai at a later time (the closest i know being the sample boss in the shinra building). hopefully i can add more options to what we already have available >
.oh, and the debug message popped up when i opened the test kernel with WM... that is something caused by PrC's updating. hojo's files always open nicely without any errors, but the size is usually bigger because of the lesser compression used.
update: i found the other kernel0 file... it got mixed up with my other files where it extracted :|
Last edited:
N
nfitc1
Guest
I see what you're saying now. PrC's test KERNEL is bad, not Hojo's. I was confused.
I'm looking at it now...Well, maybe after lunch. I'm hungry.
I'm looking at it now...Well, maybe after lunch. I'm hungry.
S
secondadvent
Guest
heh... i just ate not too ling ago, so i am set XD. i also made a guess as to the usage of the row? and sideattack flags, not quite sure if it is correct, just an immediate guess from what i saw in AB's script, you may know more than i do about it. if you know anything, i could use some help with completely understanding it's ai... the row thing is killing me >_>.
going to have to make a little test to see what the initial facing is, to better make sense of the code, and to see which row is which.
ok, it's starting facing is 1, so i think that i was right with the row layout. i will make cloud and barret use the same code to display their current value, to see if their row flag is the way i think they are.
cloud's starting facing is 0, and barret's is 1, so i think i got the middls part backwards... the back attack damage would happen in they have the SAME facing, since with different facings they'd be facing each other, or looking away from each other. gonna update the other post until i learn more...
also learned the back attack and ambush settings, so added them as well. pincer attacks are likely the middl person in your team facing a different direction while the other two face the opposite direction, i am not at a pincer attack area, so i do not know which sides are which, though the same thing applies.
going to have to make a little test to see what the initial facing is, to better make sense of the code, and to see which row is which
.ok, it's starting facing is 1, so i think that i was right with the row layout. i will make cloud and barret use the same code to display their current value, to see if their row flag is the way i think they are.
cloud's starting facing is 0, and barret's is 1, so i think i got the middls part backwards... the back attack damage would happen in they have the SAME facing, since with different facings they'd be facing each other, or looking away from each other. gonna update the other post until i learn more...
also learned the back attack and ambush settings, so added them as well. pincer attacks are likely the middl person in your team facing a different direction while the other two face the opposite direction, i am not at a pincer attack area, so i do not know which sides are which, though the same thing applies.
Last edited:
N
nfitc1
Guest
You're straying from the "no AI discussion" request.
I figured out why the test KERNEL wasn't working. It was a pointer mistake on my part. That really screws things up, doesn't it?
I figured out why the test KERNEL wasn't working. It was a pointer mistake on my part. That really screws things up, doesn't it?
S
secondadvent
Guest
i never new there was a no ai discussion request... how else can i point out things regarding ai to possibly add to PrC ?
yeah... a pointer not pointing right is never good >_<.
on the (not adding more ai stuff XD) topic of the facing flag, i am going to check and see which side of a side attack gets which value set... i'll take the info from my other post i have been updating here and add it to my thread, to abide by the rules of you thread >. going to update the dat file with names/better names for the flags and such i figure out, to make life easier later .
here is what i updated so far in my dat file:
2120|MagicCounter //counts how many times hit with magical attacks
4020|Flag:Invisible //makes the character invisible (dunno how to bring back... maybe setting an idle animation and turning it off?
4027|Flag:Facing //the current facing of the enemy
402C|Flag:NoDeathAnimation //prevents the normal death animation from occurring if true. used for setting custom death animations
402E|Flag:Intangible //unable to be hit when on
updated: setting the idle animation again on an invisible enemy doesnt work to bring them back <_<.
?yeah... a pointer not pointing right is never good >_<.
on the (not adding more ai stuff XD) topic of the facing flag, i am going to check and see which side of a side attack gets which value set... i'll take the info from my other post i have been updating here and add it to my thread, to abide by the rules of you thread >
. going to update the dat file with names/better names for the flags and such i figure out, to make life easier later .here is what i updated so far in my dat file:
2120|MagicCounter //counts how many times hit with magical attacks
4020|Flag:Invisible //makes the character invisible (dunno how to bring back
... maybe setting an idle animation and turning it off?4027|Flag:Facing //the current facing of the enemy
402C|Flag:NoDeathAnimation //prevents the normal death animation from occurring if true. used for setting custom death animations
402E|Flag:Intangible //unable to be hit when on
updated: setting the idle animation again on an invisible enemy doesnt work to bring them back <_<.
Last edited:
N
nfitc1
Guest
That's what I meant by this. Although discussion of addresses is fine. I also don't mean to say that you've violated it, I meant to say we're getting close to off-topic-ness.i never new there was a no ai discussion request... how else can i point out things regarding ai to possibly add to PrC
BTW- How would you like a resizable AI Editing window? I know I would. That works now too.
Last edited:
S
secondadvent
Guest
that was one of my early ideas for this program, since the resized version is still the same size, just in a bigger gray space XD. dunno if i ever posted about it or not... probably got lost in my massive posts.... i need to tye less or something .
the next release is going to be a good one >.
off topic: i have an idea... if the variable that is supposed to be limit level (you have a ? there), it could be possible to change limit levels in battle, and possible to make it so that you have to use a level 1 limit before it allows you to use a level 2 (as in it will start at level one, and work it's way up to 4, then go back to level 1, IF you have limits in those levels), making easy omnislashing out of the question, at least it could only be used every four attacks then. it could also be made so you have to use a limit level a few times before it allows you to use a higher level one, but that could make things overly complicated for the player. increased limit requirements, as well as increasing how much you need to be hurt to fill the bar, combined with only being able to use limits in order by level would make limits something that you have to work harder to gain, and to use... i just have to see what is up with the variable first.
.the next release is going to be a good one >
.off topic: i have an idea... if the variable that is supposed to be limit level (you have a ? there), it could be possible to change limit levels in battle, and possible to make it so that you have to use a level 1 limit before it allows you to use a level 2 (as in it will start at level one, and work it's way up to 4, then go back to level 1, IF you have limits in those levels), making easy omnislashing out of the question, at least it could only be used every four attacks then. it could also be made so you have to use a limit level a few times before it allows you to use a higher level one, but that could make things overly complicated for the player. increased limit requirements, as well as increasing how much you need to be hurt to fill the bar, combined with only being able to use limits in order by level would make limits something that you have to work harder to gain, and to use... i just have to see what is up with the variable first
.
Last edited:
- Status