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
1
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: https://cdn.discordapp.com/attachments/690633787121467433/723059028770553856/unknown.png

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.


2
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...

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

https://github.com/FFT-Hackers/SisterRay


4
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.

Thanks!

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.

6
Hey DLPB, I see you've decided to try and continue your slanderous behavior in this thread. Please stop lying to your users and the rest of the community. The screenshot I posted comes from an import tracer. Aali.dll is a (forward-linked) dependency of your DLL, and this is in violation of the GPL. You are not using it as a module, you are linking with it. Since GPL propagates through linking and is a contaminating license, this means that DDraw.dll, and all future versions of DDraw.dll, are GPL'd software and any copyright holder (myself, Nax, TO) among others can easily have the source seized by the court and made public at any time. Again, let me reiterate, Due to GPL being a contaminating license, all future versions of this project are GPL'd and by not releasing them under the terms of the license, you are in violation of the GPL.

You can't lie about no peace offering being made when it was done so in the public record.

So, DLPB, You must remove all code in violation of the GPL (which includes DDraw.dll, both in its current an all future versions) from any distribution channel to remain in compliance with the GPL. This is the position you are in and it is a serious one. I advise you treat it as such.

This is my peace-offering: Publicly apologize to the people in this community that you have wrongfully slandered. Immediately (in accordance with moderator judgment) remove Reunion from distribution as currently implemented. Then, out of respect for the people who love your work, I will not strike you (although I very clearly could) for future versions of your code provided that when you repost your code, it includes a link to the full source for your fork of the Aali driver, and that any other DLL's included on it have no static or dynamic linking, or otherwise prohibited relationships with a modification of  Aali's source, which I will verify.

The next time you mention me or TrueOdin, or any other member of this community in a slanderous way, I will copyright strike you, and have your code force-ably seized by law enforcement and any references to it scrubbed as a copyright holder.

Consider this a notice.

7
@Ver Greeneyes

What it comes down to is this >

https://stackoverflow.com/questions/1394623/can-i-dynamically-call-a-lgpl-gpl-software-in-my-closed-source-application

That and many other discussions are the grey area QP says does not exist.

In order to wage a petty disruptive campaign, QP is arguing that 2 external functions in aali.dll that are called by ddraw - mean there is a violation.  And what are those 2 functions?  1. To call a function to display txt to screen. 2. Code to report kernel2.bin text ID.

Yeah - that's what he's fuming about.  Yawn.

LGPL is a different license than GPLv3. So that link is completely irrelevant. That grey area does not exist under GPLv3 as evidenced by my link to the section on static/dynamic linking, as well as the explicit clarification on the wiki regarding the amendments made to v3 to address ambiguities that existed in the verbiage of v2's clause. Also, it applied to proprietary applications which do not distribute the source as opposed to distributing the binary (running code on a serve and distributing the output is a completely different thing than linking)

Continue your provocations and protestations if you like, unfortunately for you the facts -- and the law pertinent are both clear and verifiable.

8
Tell yourself whatever you need to tell yourself. You publicly slandered TrueOdin and myself without cause for theft while indisputably in defiance of the terms of the terms of copyright with which Aali released his driver, you refused my peace offering simply out of stubbornness, which would have allowed you to continue distributing DDraw.dll as a closed source application, in-spite of contamination making all future versions of it in violation of GPLv3 absent the source code being released.

Your incoherent rambling and desperate protestations(about gplv2 nonetheless, gplv3 was amended specifically to address the ambiguity you are trying to claim) to the contrary will not change these facts, which are now a part of public record, open for anyone to review.

9
I have consulted with my lawyer. If you repost the offending material, i.e opt to continue distribution of material while in violation of the terms of the licensing agreement (which you will not be permitted to do on qhimm, precisely because you are in fact in violation of GPLv3) you will be receiving a formal legal notice.

10
DLPB, stop lying to people immediately before you get yourself into more trouble than you are already in. Your DLL is not separate, and this is not debatable. There is no legal grey area here.

Import tracing reveals that DDraw.dll has a forward linked dependency on Aali.dll, nothing else you say on the matter is relevant since anyone can independently verify this and it's impossible for this to be the case if you aren't linking.

From GNU.org: https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic

It doesn't matter if you link statically or dynamically (Also, you have admitted to linking in this thread which is admissible evidence lol), this propagates GPL and makes the entire combined work GPL in perpetuity. Even if you remove the references now DDraw.dll is still GPL'd code and you cannot distribute it unless it is open source under the terms and conditions set forth by the GPL3 license agreement.

Since it's clear you have no understanding of GPL, let me address the nonsense you have been sending people in private messages. https://cdn.discordapp.com/attachments/707501179831189505/707588532494925834/Screen_Shot_007.PNG

Wrong, the terms of the GPL do not require that both executables "communicate with each either" (This could actually be fine if the communication involves only module style data exchange and not linking, which constitutes sharing of protected material under GPL) -- and it isn't the case that the GPL'd dll needs to "communicate" back. Just think about this rationally, why would a copyright holders right to control distribution of derived works be conditional on whether or not the derived work called some other persons code?

There is no ambiguity on linking being allowed when you are distributing the binary, which is a form of the material protected by GPL. You are not linking and then running your code on a server, distributing effectively only the "output" of the combined derived work -- there is some ambiguity regarding whether this is allowed or not but since you are distributing the binary that is irrelevant in your case.

Oh, GPL contaminates so this applies to future versions of DDraw.dll even if you attempt to remove the linkage dependency. Oh and I don't want your source code, as evidenced by the peace offering made earlier in this thread (before you doubled down like an idiot and attempted to further slander me in your spreadsheet and in private messages), you would have been allowed (at least, I would not have struck you) to redistribute DDraw.dll after all linking dependencies were removed without open sourcing it, even though it would still be a violation of the terms and conditions of GPL due to license contamination.

I urge you to reflect on the seriousness of your current situation and comply with the law, one way or another.

11
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 https://github.com/FFT-Hackers/IDA-Tools

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.

12
Hey DLPB, I see you've decided to try and continue your slanderous behavior in this thread. Please stop lying to your users and the rest of the community. The screenshot I posted comes from an import tracer. Aali.dll is a (forward-linked) dependency of your DLL, and this is in violation of the GPL. You are not using it as a module, you are linking with it. Since GPL propagates through linking and is a contaminating license, this means that DDraw.dll, and all future versions of DDraw.dll, are GPL'd software and any copyright holder (myself, Nax, TO) among others can easily have the source seized by the court and made public at any time. Again, let me reiterate, Due to GPL being a contaminating license, all future versions of this project are GPL'd and by not releasing them under the terms of the license, you are in violation of the GPL.

So, DLPB, You must remove all code in violation of the GPL (which includes DDraw.dll, both in its current an all future versions) from any distribution channel to remain in compliance with the GPL. This is the position you are in and it is a serious one. I advise you treat it as such.

This is my peace-offering: Publicly apologize to the people in this community that you have wrongfully slandered. Immediately (in accordance with moderator judgment) remove Reunion from distribution as currently implemented. Then, out of respect for the people who love your work, I will not strike you (although I very clearly could) for future versions of your code provided that when you repost your code, it includes a link to the full source for your fork of the Aali driver, and that any other DLL's included on it have no static or dynamic linking, or otherwise prohibited relationships with a modification of  Aali's source, which I will verify.

The next time you mention me or TrueOdin, or any other member of this community in a slanderous way, I will copyright strike you, and have your code force-ably seized by law enforcement and any references to it scrubbed as a copyright holder.

Consider this a notice.

13
General Discussion / Re: There's a FF7 Disassembly?
« on: 2020-05-05 06:03:14 »
https://github.com/FFT-Hackers/FF7-Disassembly

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.

14
I didn't want to return to this - but I think you all should know that sl1982 is currently trying (on behalf of True Odin and Quantum Pencil) to force me into releasing my source for ddraw.dll - which they've been after since the very start.

The charge is that aali.dll "links" to ddraw or vice versa.  It does not. Aali.dll is a completely separate entity and is called from ff7.exe loadlibrary - which is easy to prove.

Rest assured that even if this were not the case, I'd rather burn my eye balls out with a white hot poker than give my source to bandits that want to pass it off as their own.  Which would mean I'd be forced to leave Qhimm's.

This is the latest evidence I have of how those two have acted with absolute contempt from the beginning and will stop at nothing.  I've got better things to be doing than this rubbish - I actually give a damn about the game and improving it.  If True Odin and QP want to create a proper community that will have one modding solution we can all enjoy, I invite them to work with The Reunion and not against it.  Attempts to get away with doing large chunks by forcing me to release my source are not going to work.

Aali.dll source will be uploaded as sl1982 has requested - within 3 days.

I provided proof that you are in fact linking to Aali.dll from DDraw.dll. I uploaded visual proof that anyone can easily check, and described exactly how any interested party could check. Set a breakpoint on loadlibraryW and inspect the argument when running the game with reunion or just use software such as https://github.com/lucasg/Dependencies and inspect the dependencies (this intercepts import calls)

This is not a matter of debate, it's unbelievably clear that you are linking Aali.dll from DDraw.dll as part of R06e that you have distributed.

I have contributed to this driver during its lifetime as GPL'd software, which makes me a copyright holder. Release the source, or remove the offending code (which is not just Aali.dll), without a reupload until you have a version of DDraw.dll version that does not link with the driver (I will be able to check) or I will file a strike. I have warned you.

15
We are not cloning your project. By the way, you're guilty of flagrantly violating copyright law, as long as you refuse to open source this project. I provided undeniable proof (and easily verifiable proof) in the thread you just linked, ironically enough. Funny for a guy accusing others of stealing his work.

https://cdn.discordapp.com/attachments/567178858126639105/706944549519491152/ddraw_links_with_aali.PNG

That's your "dll" clearly linking with Aali.dll, a modified GPL piece of source code by your own admission. You can moderate this if you want, if you do l I will repost the proof again the next time you mention me or TrueOdin or appropriate action is taken by qhimm for your flagrant violation of GPL.

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

Glad to be a part of this project =)

17
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.

18
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

19
No problem, any time =)

Make some cool 4x cut animations for sephiroth =D

20
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.

EDIT
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

21
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.

22
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:

https://en.wikipedia.org/wiki/Pascal_(programming_language)

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

23
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.

https://aplawrence.com/Unixart/C_is_for_Crap.html
https://www.radford.edu/ibarland/Manifestoes/whyC++isBad-printable.shtml


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.

24
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 =)

25
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.

Pages: [1] 2 3