For those of you who haven't been watching very closely let me break it down to what is on the table now. I've been discussing strategies with other VB.NET users who are supposedly knowledgeable about such things and they think that 32 drop-downs with 800 entries (the action lists) is poor design. They don't know the specifics yet, but I'm really not certain anything else will do. I've played with the idea of a listbox that the user can click on to enable editing, but that seems a bit clumsy and adds extra clicks that I don't think the user should have to do. On the other hand, populating each listbox does take forever for each enemy form loaded.
Since I finally got time to play Skyrim I've been doing a lot of that and mostly neglecting PrC. I'll get back to it when I'm satisfied with my killing sprees in Skyrim.
I've also been "commissioned" to see how the texture effects can be safely extended from 15 fps to 60 fps without having to alter the animations themselves. What I've found is that the graphics plugin handles all of that. Since I've gotten Aali's OpenGL driver I can't see how the delivered plugin handles it. It looks like the exe dumps some values in specific places that the graphics driver reads and does things with. I have to do more investigating....
Monday, April 23, 2012
Wednesday, February 29, 2012
Check it out....
Nearly a full month's time gone and hardly a single line of code written. *sigh* Well, the good news is that I'm just a few hours away from being finished with my last undergraduate class of my life. I've got the final to take this afternoon so I'll be burdened by one less thing in life.
Speaking of life, my daughter is finally getting to that six month mellow period. We've started sleep training and it's going surprisingly well. She had a rough night the first night, but she got better the next few nights. Her naps seem to have gotten better too. She was taking four or five less-than-hour-long naps before and since we started making her sleep in her crib she has taken at least one hour-and-a-half long nap per day. Yesterday was the first time she got over four hours in three naps. :D Non-parents and parents of normally sleepy babies wouldn't understand, but this is a big milestone for all of us.
Anyway, back to PrCMDI! I've had many long nights thinking up a strategy for what I want to do with it. First of all will be save files that are NOT scene.bin files. That will open up the possibility for a lot of features like saved histories, comments, and just a bunch of other things. That will make saving and distributing changes super easy compared to how it is now. This way you won't have to compile the scene.bin and compare it to an original one. You'll still be able to compile the data into a scene.bin, but the raw data save will keep the data much better organized.
I'm also still super happy with the way it's being organized now. The current PrC and WM are just these massive classes that handle the data and are interdependent on each other. PrCMDI already has a dozen individualized modular classes that only raise events to each other. I'd like to get most of the code off of the form classes like they are now and concentrate solely on display from there.
Addendum:
Oh yeah. Bosola also suggested some helpful changes to WM so I might be adding those in soon. I might re-write WM again too. It would still look about the same, but the code needs a lot of untangling.
Speaking of life, my daughter is finally getting to that six month mellow period. We've started sleep training and it's going surprisingly well. She had a rough night the first night, but she got better the next few nights. Her naps seem to have gotten better too. She was taking four or five less-than-hour-long naps before and since we started making her sleep in her crib she has taken at least one hour-and-a-half long nap per day. Yesterday was the first time she got over four hours in three naps. :D Non-parents and parents of normally sleepy babies wouldn't understand, but this is a big milestone for all of us.
Anyway, back to PrCMDI! I've had many long nights thinking up a strategy for what I want to do with it. First of all will be save files that are NOT scene.bin files. That will open up the possibility for a lot of features like saved histories, comments, and just a bunch of other things. That will make saving and distributing changes super easy compared to how it is now. This way you won't have to compile the scene.bin and compare it to an original one. You'll still be able to compile the data into a scene.bin, but the raw data save will keep the data much better organized.
I'm also still super happy with the way it's being organized now. The current PrC and WM are just these massive classes that handle the data and are interdependent on each other. PrCMDI already has a dozen individualized modular classes that only raise events to each other. I'd like to get most of the code off of the form classes like they are now and concentrate solely on display from there.
Addendum:
Oh yeah. Bosola also suggested some helpful changes to WM so I might be adding those in soon. I might re-write WM again too. It would still look about the same, but the code needs a lot of untangling.
Thursday, January 26, 2012
Got a few more....
4280|Gil Stolen
4290|Item Stolen
Used in conjunction with Attack Property 6 and 7 to know how much gil/what item was stolen in case the player defeats the thief.
4290|Item Stolen
Used in conjunction with Attack Property 6 and 7 to know how much gil/what item was stolen in case the player defeats the thief.
Thursday, January 12, 2012
More reason to make the xml-based text files
So I've been prodding around in the code looking for new things to discover. Lo and behold I found two interesting things:
1. 9X damage calculations do NOT use the secondary equations
2. secondary damage equation X6 DOES NOT EXIST!
This is why I wanted to add the xml that will allow the user to update their descriptions of various things like damage formulae descriptions.
EDIT: I forgot to mention. 9X is ONLY used by Manipulate to determine if it will "connect" or not.
1. 9X damage calculations do NOT use the secondary equations
2. secondary damage equation X6 DOES NOT EXIST!
This is why I wanted to add the xml that will allow the user to update their descriptions of various things like damage formulae descriptions.
EDIT: I forgot to mention. 9X is ONLY used by Manipulate to determine if it will "connect" or not.
Wednesday, December 21, 2011
Update your WallMarket.dat and ProudClod.dat files.....
So while doing some digging in the executable I found something rather interesting about the AX damage formulae. Turns out they're directly related to the currently blank "Additional Effects" descriptions. Believe it or not, these formulae are using those effects to alter the damage and power of the attacks! So damage formula A0 uses effect 0A, formula A1 uses effect 0B, etc. Check it all out on the wiki.
Now for the more exciting news. I previously stated to a small number of individuals that adding behaviors based on elements would require handling each attack that used that element. If you want to add a counter for a fire elemental then you'd have to make checks if the previous attack was Fire, Fire 2, Fire 3, Ifrit, or Beta. This isn't that convenient if your weapon has a fire elemental attached to it. You can still do fire damage without causing those attacks. WELL, there happens to be a AI battle address that tells you what elements the attack uses.
2120|Attack Element(s)
You can add that line to the .dat files. Oddly enough, this appears to work just fine, but it's never used in any scripts where it would make sense to use. I know there is some enemy that actually does a check if the previous attack is Fire, Fire 2, etc to see if it was attacked by a fire elemental. Like I said before, it won't know if a fire-imbued weapon attacks it though.
That's not all either! There's another address of interesting note. The Attack Properties also get a varible!
2160|Attack Properties
That's the same as the Special Attack Flags as it's labeled in the wiki. This has the potential of determining a few things like if the attack damaged MP, HP was drained, it was a critical hit, etc. Counters can get even more complex now with all this new info. There might even be one for statuses that the attack inflicts or heals. I know there are still at least two values that aren't known that the game DOES point to. There's a 2170 and a 2180 that I don't know what they do. I'll have to look it over.
Now for the more exciting news. I previously stated to a small number of individuals that adding behaviors based on elements would require handling each attack that used that element. If you want to add a counter for a fire elemental then you'd have to make checks if the previous attack was Fire, Fire 2, Fire 3, Ifrit, or Beta. This isn't that convenient if your weapon has a fire elemental attached to it. You can still do fire damage without causing those attacks. WELL, there happens to be a AI battle address that tells you what elements the attack uses.
2120|Attack Element(s)
You can add that line to the .dat files. Oddly enough, this appears to work just fine, but it's never used in any scripts where it would make sense to use. I know there is some enemy that actually does a check if the previous attack is Fire, Fire 2, etc to see if it was attacked by a fire elemental. Like I said before, it won't know if a fire-imbued weapon attacks it though.
That's not all either! There's another address of interesting note. The Attack Properties also get a varible!
2160|Attack Properties
That's the same as the Special Attack Flags as it's labeled in the wiki. This has the potential of determining a few things like if the attack damaged MP, HP was drained, it was a critical hit, etc. Counters can get even more complex now with all this new info. There might even be one for statuses that the attack inflicts or heals. I know there are still at least two values that aren't known that the game DOES point to. There's a 2170 and a 2180 that I don't know what they do. I'll have to look it over.
Wednesday, November 16, 2011
Additional optimism for AI script separation
I was thinking about it this morning (as I was trying to get my daughter back to sleep) that instead of actually running byte-per-byte comparisons on AI scripts that have the same lengths, I can just generate CRCs per script as they load! That way I can compare the CRCs with the lengths to determine if two scripts are identical The possibility of two different scripts with the same length and the same CRC is so close to 0 that logic states it's impossible. As a result, that will turn an "n log n" function into a "< 3n" function! With over a thousand unique scripts that's a vast improvement!
EDIT:
Success! Let me give you an idea of what this does now. In the following list, each listed actor is unique. The entries below the actor's name indicate that there is an AI script present in that section and the number next to that section is a unique script ID assigned as it is read in order:
Mystery Ninja
0: 127
1: 128
3: 129
15: 130
Mystery Ninja
0: 127
1: 128
3: 131
15: 130
Mystery Ninja
0: 127
1: 132
3: 133
15: 130
Mystery Ninja
0: 127
1: 132
3: 134
15: 130
Mystery Ninja
0: 127
1: 132
3: 135
15: 130
Mystery Ninja
0: 127
1: 132
3: 136
15: 130
So with those six actors and 24 active script blocks, there are only 10 unique scripts between them! The init and custom event 8 blocks are all identical and most of the main scripts are the same. The only thing that uniquely identifies them is the "death counter" which will set the level that Yuffie joins the party at. This is just the kind of thing I'm trying to solve. Instead of wasting space copying three identical scripts twice. This way we can create more intricate behaviors and counters while maintaining synchronicity between all six (or a set of six) without having to modify all six.
Slick, right? :)
EDIT:
Success! Let me give you an idea of what this does now. In the following list, each listed actor is unique. The entries below the actor's name indicate that there is an AI script present in that section and the number next to that section is a unique script ID assigned as it is read in order:
Mystery Ninja
0: 127
1: 128
3: 129
15: 130
Mystery Ninja
0: 127
1: 128
3: 131
15: 130
Mystery Ninja
0: 127
1: 132
3: 133
15: 130
Mystery Ninja
0: 127
1: 132
3: 134
15: 130
Mystery Ninja
0: 127
1: 132
3: 135
15: 130
Mystery Ninja
0: 127
1: 132
3: 136
15: 130
So with those six actors and 24 active script blocks, there are only 10 unique scripts between them! The init and custom event 8 blocks are all identical and most of the main scripts are the same. The only thing that uniquely identifies them is the "death counter" which will set the level that Yuffie joins the party at. This is just the kind of thing I'm trying to solve. Instead of wasting space copying three identical scripts twice. This way we can create more intricate behaviors and counters while maintaining synchronicity between all six (or a set of six) without having to modify all six.
Slick, right? :)
Friday, November 4, 2011
AI Blocks not so static....
So this just occurred to me. The pointers to AI scripts are just pointers to a script that gets run until it hits the 73h byte, right? Well it seems to me that this is a grossly underused system. What it does right now is have pointers to the pointers per enemy per script with the actual scripts in between:
[Enemy 0's AI][Enemy 1's AI][Enemy 2's AI][Enemy 0's Sections][Enemy 0's Scripts][Enemy 1's Sections][Enemy 1's Scripts][Enemy 2's Sections][Enemy 2's Scripts]
That seems pretty wasteful. You could do it this way as it is without modification or worry that it'll blow up:
[Enemy 0's AI][Enemy 1's AI][Enemy 2's AI][Enemy 0's Sections][Enemy 1's Sections][Enemy 2's Sections][All Scripts]
What's the advantage? SHARED AI SCRIPTS!! Let's say that we want Enemy 0 and Enemy 1 to behave the same way. They have a 40% chance of not attacking every other turn or so. Why not let their main scripts point to the same script? Oh, but now you say "but their attacks will be different. Unless they're using the same attack that will be useless!" No it won't. Consider this as a script:
0x000: 12 00A0
0x003: 61 0131
0x006: 72 000F
0x009: 12 00A0
0x00C: 61 0146
0x00F: 90
0x010: 60 20
0x013: 02 00A0
0x015: 92
Starting from the beginning we're loading attack ID 0131h and executing it, but starting at 009 we're loading attack 0146h and executing it! This can pose a problem for jumps, but if you pre-load attack variables in the init scripts then you can easily share a more complicated Main between two actors!
This can also be used to share counter-attack behaviors (like running) and a few other things.
Man, I'm awesome. B)
Whoops. I forgot to finish this thought.
One thing I can think of right now that can be changed is that stupid "A Chocobo!!" init script that's shared by EVERY enemy that is in a formation with a Chocobo. They're all the same script so they could all share it and free up space for more complicated script behaviors.
As a result, I was thinking of adding another category to the list of things this handles. Adding AI as a section would be great. That requires naming each one and comparing them one-by-one. That takes time. There are some easy ways to shave off this time like comparing lengths first. There can never be more than 28,672 unique AI scripts contained in the scene.bin and they can have wildly different lengths. The ones with different lengths are obviously not a match.
Also, this would be super difficult and confusing to have to load the scene.bin each time and parse through it like this. I could have PrCMDI create it's own database save with everything already parsed out that it could load much faster than the scene.bin could. You could save as this database (which could be legally freely distributed) and just export to a scene.bin that could be used by the game.
Yep, still awesome! B)
[Enemy 0's AI][Enemy 1's AI][Enemy 2's AI][Enemy 0's Sections][Enemy 0's Scripts][Enemy 1's Sections][Enemy 1's Scripts][Enemy 2's Sections][Enemy 2's Scripts]
That seems pretty wasteful. You could do it this way as it is without modification or worry that it'll blow up:
[Enemy 0's AI][Enemy 1's AI][Enemy 2's AI][Enemy 0's Sections][Enemy 1's Sections][Enemy 2's Sections][All Scripts]
What's the advantage? SHARED AI SCRIPTS!! Let's say that we want Enemy 0 and Enemy 1 to behave the same way. They have a 40% chance of not attacking every other turn or so. Why not let their main scripts point to the same script? Oh, but now you say "but their attacks will be different. Unless they're using the same attack that will be useless!" No it won't. Consider this as a script:
0x000: 12 00A0
0x003: 61 0131
0x006: 72 000F
0x009: 12 00A0
0x00C: 61 0146
0x00F: 90
0x010: 60 20
0x013: 02 00A0
0x015: 92
Starting from the beginning we're loading attack ID 0131h and executing it, but starting at 009 we're loading attack 0146h and executing it! This can pose a problem for jumps, but if you pre-load attack variables in the init scripts then you can easily share a more complicated Main between two actors!
This can also be used to share counter-attack behaviors (like running) and a few other things.
Man, I'm awesome. B)
Whoops. I forgot to finish this thought.
One thing I can think of right now that can be changed is that stupid "A Chocobo!!" init script that's shared by EVERY enemy that is in a formation with a Chocobo. They're all the same script so they could all share it and free up space for more complicated script behaviors.
As a result, I was thinking of adding another category to the list of things this handles. Adding AI as a section would be great. That requires naming each one and comparing them one-by-one. That takes time. There are some easy ways to shave off this time like comparing lengths first. There can never be more than 28,672 unique AI scripts contained in the scene.bin and they can have wildly different lengths. The ones with different lengths are obviously not a match.
Also, this would be super difficult and confusing to have to load the scene.bin each time and parse through it like this. I could have PrCMDI create it's own database save with everything already parsed out that it could load much faster than the scene.bin could. You could save as this database (which could be legally freely distributed) and just export to a scene.bin that could be used by the game.
Yep, still awesome! B)
Subscribe to:
Posts (Atom)
