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

Pages: [1] 2 3
General Discussion / Re: what's up with the filter?
« on: 2020-06-19 02:56:55 »
i doubt that is the case, and even if 'ordinary man'  ::) himself DID request this, he can't really do that and you know it

It has absolutely been requested:

The moderators are choosing to honor (a reasonable) request from ordinary man, nothing less, nothing more. Moreover, they have no choice but to anonymize his profile if requested due to GDPR. The right to be forgotten provisions do not necessitate posts be deleted, but they do give anyone the right to request anonymity and mandate it be granted. Ordinary man has requested it, so your anger at the mods regarding this is misplaced.

Thank you myst, absolutely loving this release. Game finally playable again on PC, I was getting tired of hearing the first 20 seconds of the main theme over and over and over...

Announcements and site development / Re: An apology
« on: 2020-06-16 00:44:27 »
I think all of the moderators for their courage in making this difficult decision. Obviously I think it's overdue, but I do not wish to speak about it at great length as my feelings regarding the matter are already quite well established.

To those of you are upset, no one "prodded" DLPB. He has been throwing these sorts of toxic fits for years, aimed at a whole host of forum members before either Odin or I joined. He was banned in the past for similar things, and that full context needs to be considered when understanding the moderators decision here.

To clear the air:

TrueOdin and I had no quarrel with DLPB before he dishonestly instigated conflict with Odin (and myself, though I had absolutely nothing to do with that project). I apologize for the ferociousness of my reaction to that situation and for the legal escalation that followed (though, to be clear, I was -- and am still, entirely correct about the legality/details). After DLPB removed the offending material, I realized, after discussions with several friends & forum members, that I was acting out of anger and the most responsible course of action was to admit my mistake and de-escalate that situation. This is the reason DLPB was permitted to re-upload reunion, and I had hoped this would be the end of the matter -- but he just couldn't stop pushing his luck.

Let's be clear -- no one has ever prodded DLPB, DLPB specifically slandered one of my closest friends (Odin) completely unprovoked, and this is merely one of a long list of toxic, childish, gatekeeping behavior he has engaged in anytime someone comes along who tries to take what he thinks is his "guarded knowledge" and make it public. The most you can say is that my reaction was disproportionate and vicious -- and I agree with you -- and take responsibility for that (Not an excuse, but I'm going through a divorce, and had to sign papers a few days earlier -- so I was already unbalanced when that situation arose.)

But Here's the truth: DLPB should've been banned before Odin and I ever joined the forum. His presence is hostile to the atmosphere of sharing and collaboration that should (and mostly, does) define this lovely community of modders.

I reiterate my thanks to the moderation team, and I look forward to moving this game forward together, to democratizing knowledge of this game as much as possible, and to many more years with this qhimm family.

All the best,

SisterRay is still pre-release but the source code is available if you are an interested developer:

Just saw this.

I want to say congratulations to everyone involved, and a big THANK YOU. This is the kind of development that will make this modding scene thrive even more and for longer. This is amazing and it brings me so much joy. Thank you!!

I have two questions about the possibilities of this project:

1. Would it be possible to add a fourth party member during battles? I'm talking completely playable just like in previous pre-FF7 FF games.

2. Would it be possible to make the menu of FF7 to be like the one in FF7 Remake? I'm talking how the menu of the Remake pops up over the screen of the game, allowing the player to still see the game screen underneath the menu. I think this is much sleeker than having a menu that is in its own completely separate screen.


1: While it is possible, in the strict definition of the word, it is extremely difficult to do. This is one of the most hardcoded aspects of the game (and is hardcoded not just in battle/menu code, which is where the bulk SR's current re-implementation runs) and thus I will need near 100% engine replacement before it can be attempted.
2: It has never occurred to me to attempt this. I want to say "yes" but I'd need to test some things first to be certain.

General Discussion / Re: There's a FF7 Disassembly?
« on: 2020-05-05 21:29:02 »
Hey man, let me push my changes first (I have a bunch of other stuff that needs sync'd, reversing work on the focus/camera stuff, etc pertaining to the playable summons mod and such)

EDIT: Updated with like a years worth of stuff lol.

Then you can go here

download and install these plugins as per the readme, and you can load/apply the json sync file to your own disasm, make any edits contributions, write those changes to a new ida-sync json file and add to the PR. Similarly you can export your disasm using produce-file without applying this one.

Sadly this disassembly does not conform to a consistent convention for naming structs (It conforms to several, depending on when I reversed that part lol), etc. I'd love to have a community one where we put some guidelines in place regarding style, comments, etc at some point.

General Discussion / Re: There's a FF7 Disassembly?
« on: 2020-05-05 06:03:14 »

Requires IDA-Tools at the same repo. Out of date also (No one was using it so I got lazy about updating it), I have much more reversing done, if you are interested I will update the repo in the morning. I ask only that you sync any new discoveries you happen to make and submit PRs.

I probably should make an announcement thread about SisterRay now...

Glad to be a part of this project =)

You'll find it's a lot harder than you imagine.  I know it seems like everything's possible and is round the corner, but I know from experience that you find out otherwise ;)

And even with a tool in place that does more, you still need modders to use them.  I've seldom seen a single mod around here get to completion - and that even includes my own (though it is healthy).  Most mods that try to edit scene.bin and kernel quickly die off when the daunting task of balancing through the entire game becomes clear.

Even translation projects came and went.  The only reason mine succeeded is because I am a fanatic, have supreme will power, and the help of two others who put enormous time in.

Noted, but I've shipped much bigger projects than this (in the 500k + sloc range). Also don't underestimate the power of good abstractions. It took 3 months to re-implement the menus as a set of widgets/events, but now that I have them working in terms of that abstraction it takes me less than a day to create an entire new menu from scratch. I'm building the project so that I get similar force multipliers everywhere.

Big projects like this sort of work that way; to make them healthy in the long tail, you have to put a bunch of effort into abstractions upfront which make the work needed at later stages easier. And I can always hire people to help whenever I decide that makes sense.

Some heads up from my side there will be a tool in the very far future which will break the limits which the game has. Quantumpencil is working on it, the name is Sister Ray. More weapons will be a piece of cake. Nevertheless atm we can't mod the game as much as we want to and if SR will be ready one day isn't also sure to 100%. But I cross my fingers.

Oh yee of little faith. It's definitely coming. I'm having to work on it a little more slowly than I expected but my motivation has not faltered.

Anyway, everything you have mentioned is fairly doable except for the first, which is possible but I'll have to literally have the whole battle engine re-implemented first (and probably much more than just that) I will be adding in battle party member switching (think FFX) though, but the game hardcodes checks and loops over the party as by index range bounded above by 3 like 391513053 times, so even with my extensive rewrite of the engine it'll take me years to have all of that code under my control so I can actually expand the number of party members.

2 is trivial, it's been done several times. I've done it and DLPB has done it.

3 just hook in on battle end/reset and set it to 0, shouldn't be that hard.

4: Not that difficult if you understand battle engine well, I've basically solved all the parts of this (and much more actually, I can get entirely new animations into the game and have them played however I like, so limit break model animations are usable outside of the context of the "Limit Break" command as a subproblem)and this will be a default option with sister ray.

5 is possible and not all that difficult. The simplest implementation would to to disable atb switch (I've already got the entire battle menu re-implemented w/ a widget system so this is easy)  which is bound to an input handler in the battle menu input handler routine, and then not update the ATB gauge when the menu state-machine is set to select -- which also takes place in a battle menu update handler (The one associated to state 0 of the state machine), I already control all this code. Could even add a "pass" command if you don't want to act with a quicker ATB recovery divisor than if an action is taken ti simulate "Wait" in that kind of game. You could then create a new widget ala FFX and display the turn order without too much trouble.

6 hard to do "properly" but possible. I've solved many sub problems but not quite there yet (I've rewritten the battle/menu inventories and got the game reading from my own weapon registries, so more weapons/items/gear is no problem EXCEPT that you can't easily give them to your party outside of SR code.) I believe the solution here that i'll use is modifying Makou Reactor so that it outputs an intermediary form of the field scripts which contain symbols representing items/weapons a specific modder has added, and then just substitute in the true indexes in the various registries I've got holding all this information in an extensible way.

7 is possible but very time consuming. Better tooling is needed

No problem, any time =)

Make some cool 4x cut animations for sephiroth =D

Hi, I've been largely absent from the ff7 modding scene for a few years due to work obligations but I recently started working on some old projects again.

I've been editing some animations for one of my projects and have hit a bit of a roadblock, at current moment I'm adding new animations to the SAAA skeleton specifically the ones that are missing and I've had a lot of success, using some resources online specifically the wiki.ffrtt and the work of borde and L Spiro. At current moment I'm working on animation #6 the 'death' animation that the SAAA skeleton is missing. It works in game and functions exactly as I want it to apart from one thing. For some reason the weapon is not where it should be and I cannot open the animation in Kimera, I assume this is because weapon animation data is stored in a separate file or a separate place in the **DA file, i've been looking online but can't find any information on the topic and I thought that maybe somebody more experienced would have an idea of where I should look.

Thanks in advance.

So i've found something strange, editing the value at offset 40(decimal) in the **AA file seems to effect which animations have a weapon in them, for instance in my case I have added animations 6, 10, 16, 17, 18, 22 & 34 to the SADA file. Changing the value to 01 removes the weapon from all but animation 0 and 1, but when I do this I am able to edit these animations in Kimera without causing a runtime error. If however I keep it at the default value these animations are unable to be edited.
Basically I'm just curious if the weapon animation data is inside the **AA file(Though i doubt it due to it's length).

1: Yes, that's because weapons actually have their own animations, for player model characters they are offset by 0x34 within the **da files (and this is, unfortunately, how the battle engines finds them). If you want the weapon to animate, then you will need to repack a corresponding weapon animation at index 0x6 + 0x34.

2: That dword is the number of weapon models, it need to always be 0x10 for player models in the vanilla game or weapons with model ID's greater than that will fail to allocate properly, since the code that loads them checks that the weapon model ID (gotten from the low byte of a field in the kernel.bin for the equipped weapon) is less than that value before allocating and initializing the polygon file and bone for the weapon

Not true. Lots of scientific simulation and maths code is still written in Fortran. And safety-critical embedded systems are often written in Ada - I have a friend who was writing new Ada code for satellite systems as recently as three years ago.

Yeah, maybe, but it is also almost impossible for 99% of human beings to write large applications in C that are totally secure, unless you've got some kind of cybernetic implants in your brain. For instance - quick q, what's wrong with this snippet?

That second null check won't do what you think it will, at least at first glance.

Of course, fiendishness like this is exactly why I think C is rewarding to learn. But actually using it is a different story!

This is a very common C gotcha (attempting to dereference podhd via &(podhd->line6) is undefined behavior if podhd is NULL. The check for NULL belongs before the attempt at dereferencing podhd and really any C programmer will know that. There's nothing wrong with the "second check" except that it's misplaced, and most good compiler's (gcc, for example) will optimize it away as the attempt to dereference podhd in the previous line will let the compiler know (mistakenly) that podhd cannot be NULL.

Simple solution, check for NULL before you dereference pointers. These sorts of things are more of a hassle when you're learning than later on when you've developed good habits w.r.t NULL handling (responsible for about 90% of C's "gotchas"). Being able to propogate constraints like this and letting the compiler (or instructing it with __builtin_unreachable) optimize away unnecessary works/checks is another factor that contributes to the performance advantage well written C code enjoys over most other compiled languages.

While I may have exaggerated about C/C++ being the only choice in those domains, it definitely has by far the largest marketshare. Ada isn't used outside U.S defense/aviation as far as a I know (and as much of a chore as the language is to work with, the extremely rigid typing and so many extra security checks -- totally makes sense for "mission critical" software so I'm glad it's preferred in those spaces. The amount of work to get a similar level of reliability out of C would definitely not be worth it, but that's not C's niche and that's fine -- just as the vast majority of problems in the domain above are not so 'critical" as to warrant the 5x development  time that results from trying to use the Ada ecosystem and deal with inane number of error checks it mandates. For that fast majority of speed critical applications, C is faster, much faster to develop in/easier to work with, portable, and "secure enough" provided your team is experienced enough to avoid the most common pitfalls.

Fortran is still around in some legacy code (and numpy/scipy) but mostly seems to be a legacy code language still adored by academics (and hence scipy/numpy, and other scientific computing libs are often written in it). I don't have any personal experience with the language, having only briefly encountered in in undergrad in the context of simulating physical systems in physics class before I realized I wasn't very good at physics. It's not as fast as C/C++ and those sorts of numerical modelling tasks are HPC, so I really don't understand why it's the preferred language for physicists in particular... but it is =p. Maybe someone with more physics experience (I never got past QM I) could offer more insight there.

The only reason Delphi died (although it hasn't) is because of poor decision making by Borland in their hay-day, coupled with the fact they were competing with the might of Microsoft (who also ship the libraries and even freeware compilers) meaning many gravitated towards C over Delphi.  Also, I hear, MS bought out loads of Borland's team.

As a language, Pascal is superior imho.  It was, after all, made to create good programming practices:

And came after C.

I think C is a terrible language and this becomes more apparent when you see mediocre code that will then not compile properly on another compiler. 

If you want to create a portable, self sustained program that will work almost universally when you ship the source to another person, then Delphi - or any other high level language - is the way to go.  I don't need to mess about with memory management, crazy syntax, and other annoyances.

Of course, no-one is going to agree on this - but I'll dance the day that C dies.  ;D ;D ;D

The trouble we've been having with Aali's source would never ever have happened with Delphi - the language simply doesn't allow for it.

The trouble with Aali's source is just due to it being a large project with no sensible build system, and no management for its dependencies, it has nothing to do with the C language specifically. Also the reason that similar C code may not compile on different compilers is directly related to other strengths of the language and it's very wide adoption, namely:

1: Unlike other languages, there are actually different compilers as no single organization "owns" C and it's useful enough in a wide range of domains to warrant compilers optimized for specific types of problems. Also competition leads to innovation and both gcc and MSVC are incredibly good compilers by pretty much any measure, capable of extremely sophisticated optimizations.

2: It does not have the additional overhead of an interpreter or a runtime virtual machine (like JVM or BEAM) so the machine code runs without any other layers of virtualization.

It's also actually the most portable language that doesn't require some immense amount of overhead, and there are many domains it is *exclusively* suited for.

Pascal (and probably Delphi too), for example --  is way less portable than C or C++, getting it to work on anything other than windows would be a nightmare. People program toasters in C, robots, and a large maority of embedded systems. As the easiest and most portable non-interpreted or runtime VM based language, C enjoys many advantages in a great number of circumstances. Those advantages have tradeoffs of course, but so does the convenience and hand-holding of C's competitors.

You may not like it --  but C and C++ (especially C) are the de facto languages of systems programming, embedded systems, games programming, drivers, vms, compilers, interpreters and any performance sensitive task for a very, VERY good reason.

I hate to say it, but you're gonna be waiting a long time if you're hoping for it do die =p. It's been forty years and nothing has really threatened it's position in any of the above domains.

Also Pascal (I don't know about Delphi's history specifically) lost to C because of the rise of Linux, crappy portability, poor (and late) advanced OOP extensions, and being too verbose (ok, the last one is just my opinion). No language with a single proprietary 'creator" which doesn't open source it's compiler is ever going to keep up with a language like C/C++, which has huge communities improving gcc/domain optimized toolchains and contributing to new new language versions to this day. So Microsoft may have played a role, but there was definitely more than that to the story

I don't think it's a good language for any user.  It baffles me why it's so popular.  Not to mention all the different compilers with their different quirks.  The language doesn't promote good efficient coding.  It's an annoyance. 

To this day, people keep repeating the lie that it's faster than other languages.  It just isn't.  They all end up as assembly and all modern languages have optimization.  The differences you will see at that level are not perceptible.

This is not true. It's strange to say that a language is faster than another language; obviously you could write horrible C-code that constantly cache missed, inefficiently allocated/de-allocated memory many times, is chock full of copies, etc. However C does not force you to rely on higher level "safety" features present in most other compiled language which means it does allow you to write much faster code than in most other languages. There's a reason why it remains the only choice for real-time (deterministic) programming tasks, or embedded systems programming. It's also lean and contains a small but useful set of core language features that are fundamental to computer science as a discipline -- unlike C++ -_-. Also this difference is absolutely perceptible, usually can be as much as 1-2 orders of magnitude over similarly well written code in a more restrictive language.

That's not really why it's good for a beginner, it'll be a while before you're worried about structure your data and iteration loops in a way that allows the most efficient pre-caching, or aggressively pre-allocate to avoid mallocs, etc. Getting the most of the freedom C offers requires substantial maturity as a developer and it requires you to structure your code in a specific way. If you don't have that, then sure, some other compiled language might get close to C's performance -- but everything you depend on is written in C, including many interpreters/compilers/drivers, and this is the case because in the hands of someone who understands programming at a low level it is STILL the best choice available. It's also the best choice available for editing compiled executable files,  as it will let you get very close to the metal and won't get in your way with annoying unsafe blocks or restrictions on casting like other language which are attempting to 1-up C (Rust, for example -- and have failed) do.

C is good for a beginner because in order to be able to use it all, it requires you learn common transferable skills and  develop a deeper understanding of core programming craft/CS concepts, which is a huge part of being a competent software engineer. There's no chance you'll spend much time working in C and not quickly develop an understanding of memory management, calling conventions, all steps of the compilation process (linking in particular), encoding schemes, etc.

Better tools are useful, but one should not be reliant upon them. This is why it's crucial that every engineer, at some point in their career, invest in learning C well if they want to expand behind writing CRUD app code and really begin to understand not just "x web framework" but computer science more broadly.

The other thing I will say that hasn't already been said: Learn a text editor well (Emacs/vim) and learn bash.

Thank you ergo_joe =). I've not been visiting the forums regularly since I joined the discord, but this is helpful.

I'm relocating all the kernel data right now, then I'm going to come back and do the same thing with the model data. Should be able to add new animations, items, weapons, armors, and materia within just a couple of months =)

Hardest part is going to be figuring out the animation structure and mapping it, I think. Kimara must already know this so its source code should help, but I need to figure out what chunk of **da data is getting copied/indexed by FF7. If the process is dynamic or based on metadata in the other model files, then we might be able to just extend Kimera to create new animations instead of having to malloc new memory specifically for a given animation -- and the game will just load them and convert

This would really be preferable, because the game dynamically loads/indexes model animations in battle based on the models present. From what I've seen so far, I think it can load a dynamic number of animations per model based on the **da file structures (which I don't understand yet).

Once they're loaded with a new index, we're done =p.

Don't try to take the easy way (because there isn't one). Realize that being a programming/CS are huge fields with a lot to learn, and prepare yourself for a multi-year journey.

I would suggest learning at least three languages, in the following order:
  • one classical systems language(C)
  • one functional language (Elixir/Erlang would be my bias cause <3 OTP and BEAM)
  • one scripting language (Python, probably).
  • If you want to learn specifically for modding, learn x86 after C

I would suggest C first, as it's the classical programming language and a lot of other popular programming languages are modeled on it. You can get close enough to the ASM to write code in C calling fist size structs in compiled executables, etc so it's by far the most useful languages for modding compiled code. C++ is also woefully complex for a beginner, I've worked in it for like 10 years and probably know 25% of the language spec cause it keeps getting more bloated.

Also take at least one systems programming course and one algorithms/data structures course, or familiarize yourself with the relevant material. Graph-traversals, dynamic programming, greedy/random algorithms, hashing and complexity analysis are tools you want in your toolbox for general purpose engineering. Systems programming will help you understand how code actually executes on your system, the various levels of virtualization involved, and is basically what you need to be able to mod a compiled executable.

I recommend this mostly to expose yourself to different paradigms and ways of thinking about code. Don't waste time on specific frameworks at first, this or that web-hotness is always changing and once you have a strong conceptual understanding of the foundations of programming picking up a new "framework" takes a few weeks of reading a codebase written in it + documentation.

To this end, remember to READ code, especially at first. Then try to use patterns you encounter in your own projects. You won't become better if you just write code, because -- well, you don't know how to write it. Gotta imitate before you innovate =p.

For getting started, I suggest you consider enrolling in Harvard's CS50 course: It's free, and the first course in the series is taught in C and will do a good job familiarizing you with what I consider to be "the basics."

Would definitely be cool. I'm going to go ahead and try this in the coming weeks, my first test-case will by my float status effect for my upcoming tactical elements mod.

Ideally I'll be able to play the characters idle animations but transpose them up by a certain amount by adding a new animation per character of them "floating" up and "floating" down which is essentially the same thing the OP asked for but I'm not gonna do a bunch of work on the animation aspect (Animation will literally just be them moving straight up in idle).

If I get that working I will of course post and update and share my findings, any of these ideas are possible at that point.

Yes, I could probably do that.

You'll need more than one animation though. I would suggest the following at a minimum:

1: Take the animation where Cid changes into the back row as a base (03). Edit that animation in Kimera to look like a "jump" animation and make sure that he jumps really high off screen when it is used.
2: Take the animation where Cid changes into the front row as a base (04). Edit that animation to start up in the sky and "jump" back down to the ground.

That's all you need in theory. We can use a script like the change/row script with the opcodes that change/return model location(don't remember which ones, but they're in my disassembly) to have Cid jump off screen. Then we can flag him as not able to be targeted, and set a jump bit somewhere in his AI battle data. Whenever that bit is set, his just need to write a main-script that enqueues a battle command which uses Throw animation to have him rain down some lances on people by setting the data we want prior to the execution of the command. We can run the return to ground script after a certain number of C or V-Timer ticks (I'm doing this for burn already)

I wouldn't know how to create an entirely new command (I could replace one you don't care about and rename it "jump" on the menu) -- that might be possible too but I haven't looked into doing something like that yet.

Of course it's possible, this is just a program, and we can inject an arbitrary amount of Turing complete code into it so in theory it's possible =p.

I think it's practical as well. I recently hacked the game using DLL-injection to run a new animation script under specific conditions for my burn effect. (Simplest possible script, E8 EC FE =p)

There's really only two steps beyond that needed to do what you're talking about:

1: Someone needs to reverse engineer the structure of the animations themselves in the **da files so that a new "animation" can be created.
2: Someone needs to figure out how the game "looks up" a given animation that appears in an animation script (Where the **da files get loaded and where the pointers to the correct indexes get stored) which is just a matter of doing some more reversing work on the function that runs the animation scripts.

Then you just need to malloc a new struct to holding the custom animation you want (the *da clone data) and rewrite the opcode handler (The animation script doesn't actually think of low indexes as opcodes, so the "byte" of the specific model animation) to look up that index at your memory address instead of where it usually goes.

Depending on generated x86 that could either be super easy (If the opcode/handler for animations is a different function, you can just replace/redirect the function, which is the easiest way) or more difficult (might have to patch the raw ASM to make space for a call to a new function that does what you want).

EDITED to reflect solved problems.

Ok, I have found out how the relevant offsetting/handling of magic actually works. It is handled by the routine at 0x4281B1, corresponding to animation script opcode 0xE8. This explains why only matching command indexes AND model scripts can summon effects. There is a switch 31 in here, and based on the command ID, it fetches the final copy of the (relative animation ID)  and looks up an index in a table; This is an index to another big table of subroutines associated with various "animation" effects. (Mostly, Magic also has a few subs at random places handled by a secondary switch). These subs get passed to 0x4284A7 which actually executes the animations (and hits opengl libraries)

This is possibly the least modular way I can imagine this being implemented. It would still be possible to execute an Enemy Skill or something with a magic animation, but it requires some ugliness. Only way I can think of is to wrap this function and then prior to calling the original, change the Command ID and the Animation Indexes to whatever you want based on their copied values; i.e, if the it's command 0x0D (ES) with Effect ID (0x04), Instead go to the magic case with ID 0x1B and you got Fire. I'll work on a wrapper like this, but this is the actual code (I stepped through the animation frame by frame) so it's gonna work =). Not as elegant as I'd hoped though.

This also means getting burn to display will be a little tricky, as this function doesn't have a "case" for command index 23 at all, meaning I do not think that index can ever display additional effects Even if the particular model animation allows it (I know this, from testing, but now I know the reason). If this function is still called for out of range indexes then that's not too bad, but if it's not it might be annoying.

Moreover, I have found out how the game actually gets "which" script to run. This was hard to reverse as runAnimationScript is constantly running asynchronously for various actors, but basically the block that sets the ptr is at 41FBBB and it's said by taking the commandID (1D) for magic and offsetting from a ptr which is set per actor when a game,the ptr is at 0x8FE2AC, and is different every battle. For command indexes less than 2E, this is the final say on the script being run. This script is iterated over at 0x41FD66, opcode by opcode  and the calls underneath it touch openGL.

UPDATE:Burn effect is now fully functional for both player and enemy characters, and animated =).

Thanks ergonomy_joe! Definitely helpful, I think I mis-reversed the struct initially, +1 is the current opcode, not a ptr to the script -- that had me going down some wild goose-chases. This should help reversing the individual opcodes =)

Ok, some more progress tonight. This is as much of the path as I have figured out between "Command" and "Animation Run"

1:MainActionRoutine calls command specific loading functions which set the MainBattleStructures animation related fields.

2:The function which inflicts damage for most commands calls another function at 0x5DBD40, where it calls a "copy" anim data function at 0x5CAB7C.

3: The function at 0x5CAB7C just copies the animation related data and calls another function at 0x5C7DEA with with the AnimData as args.

4: The function at 0x5C7DEA copies this data into two different arrays of maximum size 0x40(EDIT: 0x40 and 0x80, actually), both of which have element sizes of 0xC: These two arrays are located 0x9AAD70 and 0x9ACB98, and the indexes (maintained separately) at which these structs are enqueued are held at 0x9AEA9C and 0x9AEAA0, and incremented after each copy.

5: The data in these structs is consumed 0x42CBF9, which seems to copy data from a specific "enqueued" animation block into ANOTHER array of structs of size 0x20, which starts at 0xBFB710(CommandID ends up here) and a giant array with elements of size 0x1AEC (haven't found the start of this one yet, but the "Animation Effect ID" form kernel.bin or scene.bin ends up here) The values in these structs are directly referenced by The function ergo_joe linked which runs all the scripts

Some copyceptron right there

Surprisingly, Even though I've traced the animation index and command indexes this far (which is pretty close to the end) I still haven't come across the relative offset math used to fetch actual additional effects. Nor have a found where the game actually says "If the command index is 0x02, run the 'magic cast' animation script -- which is the paydirt.

C is a lovely elegant language with a small set of tools that are unrivaled for close to the metal programming, I don't understand how someone could dislike C =p.

C++ is a bloated monstrosity with such a large language specification and every new programming paradigm that comes into existence quickly thrown on top -_-. I've worked on a few C++ codebases and they shared almost nothing in terms of design patterns, they were such distinct  language subjects they almost felt they were written in different languages.

If you want an IDE for C I suggest CLion.

Pages: [1] 2 3