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

Pages: [1] 2 3 4
1
Also - you had mentioned in the past that we may be able to enable multiple resolutions via Tonberry...  For example - the enemy textures and worldmap textures don't need more than a 4x bump, but the character textures, battle backgrounds, and others would greatly benefit from being 8x!  Any way for that feature to work?  That way we don't have to have ALL 4x or ALL 8x...

I think so. The difficulty is that each D3D texture can hold two FF8 textures at once, so you run into problems with textures of different size. For example, let's say a D3D surface has an enemy texture that Tonberry finds and replaces with a 1024x1024 texture, but then also holds a character texture that has a 2048x2048 replacement. Do we go back and scale the enemy texture? This takes precious time and will be going on constantly.

What we may be able to do is give a max texture size in the settings, then always scale every texture to that size when replacing. As long as we know ahead of time that a 1024x1024 needs to fill a 2048x2048 space, we should be fine.

2
Hey all,  I'm trying out this tool with a fresh new install of FF8 on my Mac. I'm running the game through Wine and it works just fine... for a while. After some time, usually traversing a few screens, definitely a few screens after playing Triple Triad, the next screen loads up with odd green textures. I'm able to replicate this fairly consistently from the first save in the game, at the Balamb Garden directory, then going to the Cafeteria, playing the lovestruck Trepie, then leaving the cafeteria back into the central ring. Upon entering all the water surfaces are overlaid with green textures.

Sometimes this effect can be negated by minimizing & maximizing the game. Half the time it freezes & crashes after a few seconds.

I'm attaching a report: http://www.chopapp.com/#sspmwbid. I noticed it mention d3d9callback.dll, which was supplied by your tool. Any idea what could be going wrong?

In case you're unfamiliar with Wine, it has the ability to use its own inbuilt DLLs but also to commission native, external DLLs, provided that it's set up right. Am I maybe missing a crucial DLL, or is one of the DLLs maybe the wrong version?

Thanks for any help!

Edit: I forgot to mention the issue goes away after removing d3d9.dll. But then textures revert back to original.

The green textures sound like a classic hash collision--Tonberry thinks the water textures should be replaced with those green textures. Freezing and crashing I'm not sure about, and the report you attached only confirms that it's Tonberry that's causing the problem. Does this only happen when you use Wine to load d3d9Callback.dll? I don't recall Wine causing issues but it's possible.

Has anyone else experienced this issue using Windows or is it isolated to OSX? Unfortunately, I don't have the time or the Macbook to properly support OSX. I can send you a debug build that will write some additional logs and may shed some light on the issue, but I cannot promise anything.

3
Hello Mavirick and JemaheChi,
I've been away for a long time due to my new job; but i keep an eye on Qhimm. If you have any hints about your new hashing algorithm i would be happy to create a "test version" of Berrymapper to test the algorithm.
Anyway, as we have a large number of hashed textures now ( characters, worldmap,GF,weapons, battlefields...) we can define already a close-to-perfect set of key pixels for your algorithm. We could even have different algorithm fit to each type of texture (one for characters, one for objects, one for worldmap).

Thanks Shunsq, I appreciate the support :)

I had a preliminary version back in March and I used a thrown-together hashing tool to confirm that it would work. The issue was that the textures I had to work with (before I lost them all :oops:), even as many as there were, didn't come close to the full set.

Yeah, we have a large number of textures that have been used in different mods, but even if we had them all in one place it wouldn't be enough. The problem is that the textures we don't replace in any mods are as important--perhaps even more so--than the ones we do; without them we could unwittingly end up with tons of unforeseen collisions and then you'd start seeing the replacement textures all over the place, or they would end up behind the scenes in palette textures, masks, etc.

The reason the new hashing algorithm was never released was because I didn't want people to start using it before the pixel set was solid. Each time the hash algo changes in any way, all of the hashmap CSV's for every mod have to be changed. This means a lot of work for modders who have to keep up with each iteration and a lot of confusion for players who wonder why the hashmap for one mod works great while another causes problems. Maybe this decision was a mistake. Maybe, as I mentioned in my last comment, it would be possible to define the pixels used in the hash externally, such that modders and players could have more control over the set.

Fortunately, FatedCourage has done an incredible job collecting textures from a playthrough of the entire game, and as of today he's gotten all of them to me: a grand total of 293,848 textures collected through Tonberry's debug feature. Obviously a ton of these will be duplicates, but through the same analysis I did earlier this year we should be able to start making headway on a good pixel set. Stay tuned.

4
Thanks for the answer mavirick; yes, Tonberry does debug all kinds of textures so it was looking promising at first. Besides of the d3d9Callback.dll, does berrymapper needs to be optimized too for FFVII?

Basically, the method I've tested as a replacement for the hashing algorithm involves finding the set of the most "important" or "telling" pixels to differentiate between textures in the game, then packing their values into any good hashing algorithm. The one I've been using is Murmur2 because it's super fast and collision resistant, but really any hashing function will do.

You're basically trying to solve an optimization problem: maximize the speed of the hash (which is effectively the number of different pixels you use) while also minimizing the number of collisions (which show up as glitching textures in game). Obviously you could use every pixel and have zero collisions but it would be too slow, or use only one pixel and it would be very fast but have a ton of collisions. Theoretically, there is a perfect set of the minimum number of pixels needed to result in 0 collisions. This pixel set is based on the full texture set used by the game, and is--for all intents and purposes--impossible to find. But you can try to get close. Omzy hacked out a pretty good hashing process for FFVIII using some good ole' fashioned trial and error and that's the one we have today, but his process is virtually useless for other games (like FFVII).

TL;DR
All this is to say that yes, everything would have to change for FFVII--because the game uses a totally different texture set, Tonberry would need to hash a different pixel set. Berrymapper just uses the same hashing process as Tonberry to generate the hashes for the replaced and replacement textures. If the new hash function is completed it will come with a new Berrymapper as well. To make Tonberry game-independent, it would have to take the pixels used in the hash as an input (probably just a plaintext file), and the same goes for Berrymapper.

5
I just tried using Tonberry v2.04 and Berrymapper with FFVII steam version, the debug mode works great and I pulled off Cloud's avatar, the picture is now 4x the size (512x512px) *.png file and the texture path is "textures\cl\cloud\cloud_0.png".

hashmap.csv:
Code: [Select]
cloud_0,18446744073709551615
objmap.csv:
Code: [Select]
cloud_0,4294967295,4294967295
Unfortunately when loading my save file, Cloud's avatar remains unreplaced and several fields layers are red or missing:

[img...]

Sorry I never answered this 5way, I've been stretched thin on other projects for the past few months.

I'm pretty sure the problem you had with FF7 is the hashing function Tonberry uses (which is optimized for FF8) and especially the few hardcoded hashes used mostly for menu textures and the like. Many of the menu textures hash to the same thing and differ only by color (which Omzy's original hash function ignores) so there had to be special accommodations programmed directly into d3d9Callback.dll. It could also have to do with the texture size and resize code.

For the most part, if Tonberry can pull the texture into the debug folder then it can also replace it. If (and it's looking like the ball may get rolling again) we get a new hashing algorithm working in FF8 then we can look into applying the same process to FF7.

6
Really pumped to see some activity around here. These tex look gorgeous!

I believe all mavirick and the crew needs is a playthrough of the game with debug on. With all the textures collected from that, it should help them finish. I have done this playthrough with the intent to send it to him. But...it came to about 80GB... And that's without world map textures. Not sure on a proper way to send something that massive. Feels almost easier to mail an external hard drive with all that on it. :-P

Fated, I had no idea! To be honest I'd been concerned with the filesize as well... when I lost the textures I'd collected it was 20-30gb and I was devastated. With 80gb from a complete playthrough we should be able to generate a really good set of pixels to hash using my new method! At least, it's enough to test out and see what we can do.

Have you tried throwing the textures in an archive (I'd try 7-zip or rar) to see how much space you can save? I have 65GB on my Google Drive, so maybe there's a way I could give you access to that briefly... The HDD-by-mail is actually not a bad option, though depending on where you're mailing it from we could rack up some shipping costs. Any have any other suggestions?

EDIT: You could also split up the archive into separate pieces and use FTP to get it to me. I'd be willing to set up a client and leave my PC running, you could send the pieces at your leisure. It also looks like MEGA is offering 50GB of storage for free, so you could compress it down to that size or split it into two chunks and switch them out after I download it. off course, this is all assuming you don't have a hard cap on your uploaded data...

7
It's really a shame, because this is the graphic I made for the new Tonberry for whenever we get an actual release with the new hash algorithms.

I lost all my textures when I uninstalled/reinstalled the game :( They were in my tonberry directory and uninstalling the game wiped the whole directory instead of just deleting the game files. I tried to recover them but I guess the reinstall recycled the memory so they were all corrupt.

What I really need is the tonberry dump from an entire playthrough. It would be a ton of images and the playthrough would be frustrating cause debug mode slows things down, but the texture analysis algorithms are written and with a large enough texture set I could generate a near perfect hash. The only thing thing to solve would be hardcoding some pixels in for the animated textures like characters blinking. One solution might be a way to designate additional pixels to look at for certain textures, so that modders could fix collisions without having to generate a whole new hashing algorithm.

8
For FF7 are only the backgrounds and the Menu textures interesting. The rest can be replaced directly.
It's all polygons yes, the only textures for field and battles models are eyes, mouth, Barret's tatoo, Cloud's belt and such. You can change/replace them using Kimera.

So am I correct in assuming Kimera cannot replace backgrounds and menu textures?

The only issue I foresee is using custom textures through previous mods in conjunction with Tonberry: if Tonberry is using a hashing algorithm based on FFVII vanilla textures but then gamers start throwing different combinations of modded textures at it, modders will not be able to predict and reproduce (and thereby try to circumvent) collisions. Someone's custom texture could very well hash to the same thing as a vanilla texture, which would cause Tonberry to try to replace it and things would start getting weird. Ideally, you'd use Tonberry for everything or not at all--additional textures won't slow it down significantly.

Obviously this is all further down the line, just something to think about. If Tonberry is to be used with FFVII, its addition to the game needs to be worth the slowdown (which admittedly should be very minor for modern computers) and the effort required to adapt existing texture mods to use it.

EDIT: As an additional and probably far-fetched thought, it's possible that the D3D9Callback interceptor could be modified to catch FFVII's calls to fill in polygons. If those could be replaced with calls to apply a texture to the same polygon... well, that would be very interesting indeed.

9
I tried a few times and got nothing. Hard to say... Yeah. I opened them all up. Unsupported got FMV shots, and nomatch2 had more eyes in it. But no character or enemy textures in any.

Hm... is it possible that there aren't any character textures? I haven't played in a long while, but just looking back at screenshots it appears almost as if the characters are just polygons filled with solid colors. Lighting and shaders gives it the gradient look, but I'm not seeing any actual textures:




I'm not entirely sure that using solid colors instead of wrapped textures would change the way Tonberry works, but it's a possible explanation.

10
I tried it for you. It does pull textures like the backgrounds, text, battle effects and icons, and also character portraits. Doesn't pull any textures from the character models in or outside of battle though. It does give me their creepy little eyes, though.

Hm, that's interesting that you don't get character models... Doesn't seem right to me. I don't know why they would work any other way. It's also kind of a deal-breaker if there's no way around it. Did you have all the debug directories working? They could be an unsupported size or something.

That actually sounds very plausible. Though, I'd be uploading for days. And I'd feel sorry for the person having to sift through all that. Er... I'm a very determined person when it comes to anything I take part in. Perhaps too much at times. ...I also lead a very boring life.  8-)

There wouldn't have to be any sifting, necessarily, just some code to remove any duplicates from the set and then pixel analysis on what's left over. And as far as your determination goes, I'm certain I'm not alone in saying that we're thankful for it around here ;)

11
Mavirick, would it possible to have a Tonberry texture support for FFVII steam version since the game works in a similar way ? How much work would it take ?

Yes, I believe so. The FFVII Steam release uses DirectX 9 so I think you could use the exact same D3D9Callback.dll. There is some question as to whether the textures are the same size and are handled the same way (they are written to the GPU upside down in Tonberry, don't ask me why), but assuming they are mostly similar to FFVIII then the same process could be used: use Tonberry debug mode to find in-game textures, upscale them or repaint them, use hash of in-game texture to replace with new texture. I don't own the Steam version of FFVII, but if someone wanted to try Tonberry 2.04 with it I'd be interested in their findings. You'd want to empty \textures, tonberry\hashmap, and tonberry\objmap, set debug_mode=yes in tonberry\prefs.txt, and create a proper tonberry\debug folder structure for saving images.

The biggest problem would be the hashing algorithm, which Omzy wrote and then reinforced by a set of handchosen pixels that seemed to reduce collisions to an acceptable level. This algorithm would probably not work very well with FFVII and its entirely separate set of textures, which would mean tons of collisions and general misery for modders. In a perfect world, you'd want to do what the eventual plan for FFVIII is:

  • Use Tonberry with debug mode on to collect a large majority of in-game textures. The more textures the better--the best way to do this would be to crowdsource it, assigning people different areas to run around and then send all the collected textures to one person. One diligent speedrunner could also collect most of them in a reasonable amount of time, assuming he had the harddrive space (likely 100+GB of images), and if I've learned anything from qhimm it's that you should never underestimate the patience of a determined modder (I'm looking at you, FatedCourage :P).
  • Run some analysis on the set of in-game textures to find an ideal set of pixels for hashing. I've developed a process that I think does an excellent job of this, and was able to reduce collisions among the FFVIII textures I'd collected to ~2% (versus the 20+% in the current hash algo). However, the new hash algorithm was never completed/implemented for a variety of reasons, not the least of which was the release of The Witcher 3  ::)
  • Use pixels from analysis to create an (almost-)optimal hashing algorithm that can replace every texture in the game with whatever modders want without any significant collisions. Use the existing Tonberry structure with hashmaps and a directory for replacement textures.
  • Release the collection of in-game textures with their hashes (or an app for generating the hashes, like BerryMapper) and let modders go to town.
  • Release an updated Tonberry that uses the new hashing algorithm.

There are several other improvements in development (if a somewhat delayed development) for Tonberry, including logic that can search for 1-4 objects in all four corners of a texture so that modders like FatedCourage don't have to trawl the game for every possible combination of character textures to include in the hashmap. The important thing, I think, is that the replacement strategy that Omzy came up with and the texture cache that JeMa and I developed are both iron tight. They can and should be used for other games.

12
Hello everyone I am trying to install mods to play FF8 with, however I got several warnings of virus and medium threat after downloading Tonberry Enhanced 2.04. I was wondering if there should be any concerns? Also I don't understand if I should download this version 2.04 or the older versions such as 1.5 to run modded FF8.

I've modded skyrim plenty of times but this is my first time modding FF8 and I am very confused, any help is greatly appreciated!

You should have no concern with viruses. If AV programs are flagging Tonberry files as dangerous, my guess would be it's because of the D3D9 injector, which simply intercepts calls to your graphics card and replaces textures with the modded files.

Don't worry about earlier versions--everything you need should be included in the Tonberry 2.04 download.

13
I figured it would work fine for other players indeed. And yes I do mean crash right away at start. DId it with blank tonberry and tonberry with mods (e.g. seed reborn) and even with debug on in tonberry and renaming directories to match I get 0 output.

When I start the game in full screen and press play I get a black screen quarter of the screen and 0.1 second later in full screen  and it stays black, nothing happens, it has crashed instantly and the popup is hidden behind it to which you need to alt tab. When you press 'ok' on that popup with 'unknown exception' you can get the windows crash that asks to close it etc which also has 0 information. And this happens only in full screen regardless of anything else as long as tonberry is there. In windowed mode it runs just fine with everything working..

I'm not really sure what to tell you besides to try completely removing Tonberry and starting over. Make sure you're using v2.04, that the Steam overlay is disabled, and that at the very least both collisions.csv and hash2map.csv are in FFVIII\tonberry\, even if you have no texture packs enabled. If you continue to have issues I will send you a modified version that will log startup events from within Tonberry so I can see where and why this is happening.

14
Heya all,

Got a problem with this mod that causes me unable to play the game in full screen. I have tonberry installed with mods and they work (seed reborn etc so easy to check). But when I start the game in full screen setting from the settings it will crash with a 'an unknown exception has occurred.' I have tried all setting combinations, steam cloud/overlay on and off and every resolution with and without mods but it keeps crashing on full screen. Related to that setting option only. Also noticed this did not happen with 1.5 but did crash from 1.6 and onwards. Any help on fixing this? Without tonberry it won't crash in full screen so it is related to this. I have no idea how to go with this.

Kind Regards

Fullscreen works fine for me, and I'm assuming there are lots of other fullscreen players. What do you mean when you say "with and without mods?" Is it crashing as soon as you start up or only after a while of playing? I'm not sure what fullscreen would change that would cause Tonberry to crash, but if you're getting "unknown exception" then that does sound like it's coming from d3d9Callback.dll.

15
Hi there, am I doing something wrong?
I extract Tonberry into the FF8 root folder on my steam path: E:\GAMES\Steam\steamapps\common\FINAL FANTASY VIII
I put the hashmap for Tripod in to: E:\GAMES\Steam\steamapps\common\FINAL FANTASY VIII\tonberry\hashmap
I try running the VC redist but it tells me there is a newer version installed, and when I launch from steam nothing happens...
Windos 7 Pro SP1 64bit, 16GB ram, nVidia Gfx.

I don't see any log files anywhere and nothing in the event viewer to tell me what went wrong :) - and the game does play fine normally - this is the first time I'm patching it on Steam.


Hi Skillster, I'm sorry you're having trouble. Is FFVIII totally failing to launch, or is it just Tonberry that's not working?

Is your Windows installed on the E drive? If so (or if it's anything other than C) you need to set drive_letter to the appropriate value in \FINAL FANTASY VIII\tonberry\prefs.txt.

Have you put the Tripod textures in \FINAL FANTASY VIII\textures\?

16
I've decided to finally release a new version of this mod. So I now present v1.1. This version should fix almost all disappearing objects in the game. A tradeoff is still a few textures reverting. But no where near as bad. There are three ways this might happen... One, certain areas where you go into battle. Afterwards, they might revert. Please let me know the areas where this happens so I can fix it. Two, using the Magical Lamp to fight Diablos. Since you can fight him at almost any time and in any area the textures are numerous and will take quite some time to collect. Three, a certain party combination in a certain area I missed. Again, let me know about it.

Things I've added:

-A couple altered costumes. (Some still need some tweaking.)
-The rest of the weapons for the Student Uniform battlers. (Nothing will revert back now.)
-Tweaked textures.
-Changed the gunblade texture for certain moments. (Consistency mostly.)

And most likely some other things I'm forgetting at the moment. :P

You no longer need the objmap for this mod. You can either delete it or move it to the disabled folder. But I'll leave the 1.0 version up for those who still want to use the objmap if they still feel unsatisfied.

Really, really impressive work Fated. I look forward to trying this out!

17
I suspect there's lots of neat things that could be done with this approach for other games, so long as they use Direct3D 9. It's possible that the same approach could be used with newer versions of D3D as well, although the callback interceptor would have to be rewritten and that could take quite a bit of work. Obviously newer games would be more difficult: textures are larger, which means they're harder to hash distinctively, and much more numerous per scene, which slows things down quite a bit. But if your PC is substantially faster than the requirements for the game it should be possible.

As far as I know, nothing like this has ever been done--generally textures are replaced at the source whereas Tonberry replaces textures as they're actually set to the device stage for the GPU to render, hence the need for a good hashing algorithm. Omzy deserves a lot of credit for dreaming this up and figuring it out.

18
People (particularly those who only chime in once a blue moon to ask "when do you think xxx will be finished, I can't wait...") need to understand that modding any game of this caliber won't happen over night. It takes years of work to finish some projects, and equally as much patience to wait for them. FF7 modding started 10+ years ago, way before my time began here to know exactly when it did, but it still has projects being worked on. Everything we experience along the way is what keeps me going and digging for more. If you keep that in mind, then you'll always feel happy to be here knowing there is always something new ready to be discovered and modded.
Yeap I started mine back like two or so years ago and still not finished with the project as some bugs that where fixed persisted and forbid some pc's go down so sometimes you have to start over that is why you want to get external hard drives or cloud storage.

Thanks for the encouragement guys, it means a lot.

When I first found the mods here for FF8, I tried to register a new account and found out that "mavirick" had already been taken. Turns out I had come here for FF7 graphics mods in 2008 and totally forgotten. All I remember is that FF7 has always been my favorites and it was awesome getting to play it for the umpteenth time with better graphics.

I plan on sharing the github for Tonberry (after I clean up the code a little bit), and the same approach may be applicable to the Steam version of FF7. If the same D3D9Callback interceptor could be used, all it would require is one speedrun to collect a bunch of textures, my same program for finding crucial coordinates for hashing, and building a hash table for all the beautiful textures modders have already created.

19
This makes me a sad Panda.  Currently, we can't have a Shiva, Blinking Eyes, and Tonberry animation (irony).  I know I've been MIA lately, but that is due to some new opportunities that have dropped in my lap.  I'm not done modding FF8 by any means.  If we can make exceptions for those files individually, then maybe it's not a huge deal, but it would still be nice to have a 'complete' model.  Trust me, mavirick - Fated has done a BEAST of a job finding all of those hashcodes, and I don't think any other modder out there would have had the patience for it, IMO.  I know I wouldn't.  Please keep up your amazing work.  Just don't feel rushed -- that's the benefit/pitfall of the free modding community... it's all on your own time ;)

Oh don't worry, I'm not done here either. I only mean that things are moving slower on my end. Up until the 2.04 release I was spending a ton of time on Tonberry because there were bugs and people's games were crashing and I didn't like that one bit >:( I also had JeMa to work with and to bounce ideas off of up until ~2.03, but he has had some stuff come up that is going to keep him from contributing for the foreseeable future. That combined with the fact that a stable Tonberry takes the pressure off me just means that you shouldn't expect the new version to be available next week ;)

JeMa did ask me to apologize for his withdrawal, however unneeded the apology may be. He's the reason development progressed past 1.06 and his significant contribution should be recognized; without him we wouldn't be where we are today.




20
Tonberry does work great. I have managed to solve almost all of the glitches on my end. Except for the codes that are literally shared. Like a Zell code being the same as a spacesuit, a few world map objects, and a special one with the Squall student uniform and the square soft logo in the beginning. You'll only see it if you reset the game at times.

Animations would benefit a few things. But I'm no artist, so I can't contribute there. So I can understand why you'd hold off until more people are onboard.

I think the only really relevant thing for you would be blinking eyes (which is, inconveniently, one of the most troublesome parts of the new hashing algorithm). The shared codes problem would be solved off course but as you say, it doesn't appear to by that big of an issue.

I am still collecting textures though. So once I near the end, do you still want those sent to you?

Yes, please. All textures help. In a perfect world I would have every texture in the game and then I could make the algorithm optimal, perhaps even eliminating all collisions besides the few basically-impossible ones like all-black-except-for-a-few-dots, e.g. the twinkling stars.

Edit: on an unrelated note, why is it that when I type "off course" it is sometimes corrected to "off course" ??
Edit 2:-o I am trying to write "of"

21
If you're referring to character texture replacement... That's on a different thread, now. As for everyone else, I can't speak for them. We all have personal lives, so they're probably busy with that.

Tonberry is at a pretty stable state right now with all requested features implemented, no known bugs, and is running as efficiently as possible (as far as I can tell). I don't have much else to work on :P

The new hashing method along with selective object replacement (i.e. if it finds a match for an object but not the whole texture then it replaces the object and simply upscales the rest of the texture to 1024x1024 without changing it) is 80-90% complete but, truth be told, it doesn't seem like there's all that much modding demand for it. FatedCourage has done an excellent job wrestling with the character collisions and the other mods (read: Mcindus') work almost flawlessly. The glitches are minor at worst. Besides disappearing characters and the occasional background collision, none of the current mods will be much improved by the new hashing algorithm, and in fact Tonberry will necessarily be a bit slower.

The new hashing method would open up a lot of possibilities for new mods (e.g. animated textures), but until modders start probing in that direction (and I get a whole lot more textures to finalize the hashing coordinates) I have to say I don't feel the same urgency as I did with the current version of Tonberry.

22
well try it later today (2am here) and see if it happens again ill keep you posted :D

EDIT: you know, i feel stupid now, as i went to get the new version realized it had on the known issues as the issue i was having, i apologize fatedcourage for polluting your thread about a known issue :(

UPDATE: ok, seems to have fixed it just like he reported, thanks for the help fated and yet again sry for not noticing it sooner :D

You shouldn't feel stupid, this was not a part of the Known Issues list until the release of 2.04. Yes, I added it on there with the strikethrough :P There had been some discussion of the Limit Break problem in several different places but we can't expect everyone to go digging through dozens of comments just to see if someone else has had this issue. Normally I would have added it to the Known Issues bit earlier but since I don't own that thread it's not easy for me to update the first post...

In any case, I'm glad 2.04 seems to have fixed this issue for you  ;D

23
Download Tonberry Enhanced v2.04 Here

I'm excited to release Tonberry Enhanced v2.04, which should hopefully clear up the issues people have been having with 2.03 and earlier versions. This includes all necessary .dll's, an empty debug directory structure, and the minimum necessary hashmap .csv's. To find hashmaps for individual mods, see Mcindus' post on the first page (first comment).

What's new?:
2.04:
  • Persistent textures - modders now have the ability to designate textures as "persistent," meaning they will never be removed from the cache. This feature should be used primarily for the core textures, such as those replaced by SeeDReborn.
    • To mark a persistent texture, simply precede the name of the texture with a bang/exclamation mark (!) in the relevant hashmap or objmap .csv. For example:
      • !sysfld00_13,8637763346649579509
    • Please be aware that filling the cache with persistent textures will lock it in place and all subsequent textures will fail to be replaced, so use this feature with discretion.

  • Significant performance improvements - although dampened in part by the increased complexity of the persistent textures, Tonberry should be running faster than ever due to some major cache optimizations and an improvement to the way we handle the core (SeeDReborn) textures.

  • No hard limits on cache_size - the cache size no longer has a hard minimum size of 100. You can now set it to 0 to disable the cache and texture replacements altogether, although Tonberry will still be touching each in-game texture and checking for replacements (that never exist). This feature should be entirely ignored by average players but could be helpful for modders. Note that you can also set your cache_size too high and cause memory overflow exceptions! If you do not have LargeAddressAware enabled for your FF8 executable, your cache_size should be no larger than 250.

  • Actually disabled textures - before, textures that were disabled with a star/asterisk (*) were not handled any differently; Tonberry would simply fail to load the replacement texture when it looked for a .png file beginning with the asterisk character. Now these textures are actually excluded from the internal hashmap, which should yield a slight increase in performance and keep these textures out of your \tonberry\debug\noreplace folder. If for some reason you want these textures to show up in your debug\noreplace folder, simply change the asterisk to any other character--just so long as the texture name in the .csv does not match any file in your \textures folder.

Known issues:
  • The game crashes when using Squall's limit breaks around some enemies (especially Tonberry in the Centra Ruins) while both RebirthFlame and LunarCry are enabled. Fixed...? I have not been able to replicate this crash since using 2.04. While I never isolated the cause of the crash in earlier versions, I believe 2.04 to have fixed the problem. If this is not the case, please let me know.

  • If the cache has been full and you've been playing for some time without seeing any text (dialog, menus, etc), the cache will dispose of the high resolution font textures and you will start to see text with mixed high-res/low-res characters. Fixed! The persistent textures feature should allow these textures to be kept in the cache indefinitely (see "What's new?").

  • Some users are experiencing random crashes when using Tonberry with Project Eden. If you are having this or any other issue please post here with details so I can look into it. Until more is known about the crash, my best advice would be to save frequently. Fixed! This exception was caused by memory overflow errors; make sure your cache_size in \tonberry\prefs.txt is 250 or less.

  • The overlay is still not supported by Tonberry and should be either disabled or circumvented using Mcindus' GeDoSaTo configuration.



While Mcindus and other modders should weigh in on exactly which textures should be persistent, in the meantime this is the SeeDReborn_hm.csv I've been using to test the persistent portion:

Code: [Select]
start00_13,18407996689093672857
start01_0,17754410698961239961
magita_0,15996785876420001791
!sysfld00_13,8637763346649579509
!sysfld01_13,18410706480546952703
!sysfld01_13,18410706480580507135
!iconfl00_13,17292482743138735965
!iconfl00_13,17292623961730439001
!iconfl00_13,17292623961730700665
!iconfl00_13,17292482743138997597
!iconfl00_13,17292623961596221273
!iconfl01_13,6318371992938829623
!iconfl01_13,15546067051815065015
!iconfl01_13,15546067051817164215
!iconfl01_13,6318371992938829735
!iconfl01_13,15546067051816113975
!iconfl01_13,6318371992938829607
!iconfl02_13,9070099529679074665
!iconfl02_13,9070099529679066473
!iconfl02_13,9079106728933889869
!iconfl03_13,18121884401087167930
!iconfl03_13,18121884401086577978
!iconfl03_13,17257784389123030461
!iconfl03_13,18121884401086578106
!iconflmaster_13,15435299784218115583
!iconflmaster_13,15507357378256043519
!face_b00_13,12373840744287225834
!face_b01_13,11207991935878756332
!gf_big00_13,18129762662332643306
!gf_big01_13,10743326825426753480
mag00_13,18437446603385071613
mag01_13,18446734040665948111
mag02_13,18437446053629263869
mag03_13,18446734100795486141
mag04_13,18437446053629263851
mag05_13,18446576801913237501
mag06_13,18437446053629259769
mag07_13,16226826136128831453

24
If anyone is having trouble with certain character replacements, it may be due to the objmap.csv file I accidentally included in the Tonberry 2.03 release. This file was from an early pre-release version of Rebirth Flame and contains different texture names than the newer versions. If both objmap.csv and RebirthFlame_obj.csv contain duplicate hash codes, the former will take precedence and prevent the latter from loading.

If you have a file called 'objmap.csv' in your \tonberry\objmap directory, it should be deleted!

Edit: no longer an issue with Tonberry v2.04

25
I've went and fought against the Tonberry and every Limit Break I use(Lion Heart, Blasting Zone, Fated Circle) does indeed cause a crash. It's like when those Grendels use Breath and causes my game to crash.

Okay well I've also been using this opportunity to test out the new persistent section of the cache and the optimizations I've made along the way, so maybe this means the other changes fixed this bug without my realizing it. 2.04 should be released by tonight or tomorrow :)

Edit: I did manage to replicate the crash using 2.03, so I believe 2.04 should fix this issue. Unfortunately I'm not quite ready to release 2.04 yet--still a few kinks to iron out--but it should be out soon. Stay tuned.

Edit2: It seems I accidentally included the objmap.csv from FatedCourage's early version of Rebirth Flame in the 2.03 release. I'm sorry I didn't catch this before, but this file will cause problems for character textures if used in conjunction with Rebirth Flame.

If you have a file called 'objmap.csv' in your \tonberry\objmap directory, it should be deleted!

Pages: [1] 2 3 4