I like experimenting with ffx.py but unfortunately my additions have maxed it out (error message on rumble-room startup). Is there a workaround to this (e.g. creating a new file to put them in) so I can continue adding attributes and othe things?
The workaround that will likely be used in the next release can be a little tricky. The quickest workaround at the moment if you are just looking to try out your own attributes or whatever is to pick a few existing attributes that you don't use and won't need and delete their code. The space freed up that way can be used for code you are writing.
Obviously, you should back up your ffx.py before doing that.
Thanks for the quick reply Stumpy. How exactly could you work around it other than deleting code from ffx.py?
M25 has tested this more than I have, so he may have some clarifications. But, the basic idea is that you copy the code for a particular attribute into it's own python file and then import ffx into it and import it into ffx. Of course, that circularity can cause trouble, so you can't just import * from both files.
For instance, say you move the code for an attribute called someattrib to a file called someattrib.py.
- Add a from someattrib import * line to ffx.py.
- In someattrib.py, add import ffx and import ff.
- To all of the ffx calls in someattrib.py, you have to add a ffx. prefix.
- To all of the built-in game calls in someattrib.py, you add a ff. prefix.
- The the function in ffx.py that initializes the characters is execInitAttrib. In that function, change the line
| | init = "init%s('%s',%d)"% (attribute, char, update) |
to
| | init = "ff.init%s('%s',%d)"% (attribute, char, update) |
Yes, that's it. Except that you should import and use js. in someattrib.py rather than ff.
Oops. I thought ff was a superset of js.
It is, but I think it is better to be as specific as we can to avoid any name space issues.
Good point. I tested importing ff with the invulnerable attributes and didn't have any trouble, but they are pretty straightforward. It's probably safer to use js, but people may have have keep in mind the need to separately import the common scripting functions that are part of cshelper and so on that are part of the ff name space but not part of js.
Sorry for the 5 year necropost, but I was unaware there was a size limit to ffx.py. Mine is about 864k right now. Any idea what that limit might be?
Actually, thank you for finding a relevant thread to post into. In FFX 3.4, ffx.py was maxed at 1341 ko.
Edit: 3.3, not 3.4, sorry.
I had no idea there was a 3.4.
Neither did I. :huh: The latest version of FFX3 that I ever saw was 3.3.1.0 (of which I modified and called 3.4 :P)
Sorry gents, I meant FFX 3.3, not 3.4.
Hehe. That would start some buzz. ;-)
BTW, someone might be looking to pare down ffx.py a bit. For instance, when testing a new attribute, it is often easiest to put it in ffx.py and debug it and tweak it until it works well in that file. Once it's working, that code can be moved to it's own file and simply imported into ffx.py, preventing ffx.py from bumping into the code limit. To have room to test that code in ffx.py in the first place, some existing FFX attributes might have to be moved to their own files.
I wrote an unsophisticated converter a while back when the FFX team was looking to trim down ffx.py by putting many of the attribute functions in their own files and then importing them.
If anyone finds that they need to trim ffx.py for their own purposes, the process isn't exceptionally complicated and my converter can help speed the process and avoid namespace errors. See this post (http://freedomreborn.net/forums/index.php?topic=56834.msg768681#msg768681) for another mention of it and a link to the converter and brief document file. Also, the discussion earlier in this thread is informative.
I'd rather we did FFX 4.0 instead. ;)
The code base could certainly use some refactoring and cleanup. Mind you, at roughly 90,000 lines of (not really documented) code—around the same as Photoshop 1.0—, it'd probably take a few years full-time for a professional developer...
BTW, nice converter tool! I had missed that thread.
What about using the ffx2 file?
Yes, ffx2.py exists to work around this size limit. Functions inside this file will need to explicitly call the right module, though; the converter will help a lot there.