Sam.

Mathematically at least 3 (or you don't form a 2D polygon/shape).

IMO, deleting attachments from old posts is on par with deleting old posts, or even deleting a user account: content is lost and conversations and discussion become much harder to follow. Doing that type of thing is really a shame, and I suspect others agree: I would MUCH rather see the cumulative attachment limit dropped... Admins?

+1

See the readme. That's what he's suggesting. If you traify the mod, it allows it to be easily translated into multiple languages. Best practice is to not update mods during a playthrough. Either continue with the version you already have installed, or if you update it, start a new game.

Is it a WeiDU mod? If yes and if it is in English, all you probably have to do is update the mod's EXE to the latest version of WeiDU and to use ADD_KIT_EE.

Why not?

I vote dracolich.

PVRZ files are compressed graphics textures. For BAM V2 files, the BAM frames are subtextures that have been bin-packed into a single large texture that is a PVRZ file. The PVRZ files are accompanied by the actual BAM/TIS/MOS files that contain pointers into the PVRZ files of where to load the subtextures from the larger graphic. If you rename a PVRZ file to use an unused name, the pointers within the corresponding BAM (etc.) files also need to be updated.

Quoting the IESDP concerning PVRZ files: First, I think this wording is somewhat confusing. When I first read this sentence, I interpreted it as "each PVRZ page is limited to a total of 1024 pixels". Maybe the following would be a bit more clear? Second, looking at the PVR(Z) and IE file formats, I see no reason why textures are limited to 1024x1024 px. The PVR format doesn't even have a field specifying the filesize, which leads me to believe the theoretical maximum texture dimensions should be the largest DWORDxDWORD (width and height of over 4 billion pixels each). Is it the engine that limits the dimension, or is there something else I'm missing?

There is some discussion here that is likely related.

By the file format specs this is certainly possible, and as you point out Beamdog did this with vanilla EE resources. However, AFAIK there is no automated way for modders to achieve the same result. I can think of a couple hack style workarounds to do it, but they wouldn't be elegant or efficient...

Fun!

+1

You'll likely get more of a response if you post a concise list of questions publicly. That way people who may be interested in giving their responses know what may be expected of them.

So who are the Three Gibberlings (in Gibberlings3), and why are there now many more than three?

One of my personal favorites:

This wysiwyg-only interface it really, really difficult to work with. I can't figure out how to un-mangle this post. Given the choice of a pure BBCode interface and a wysiwyg-only interface, I'd happily take the former, even without helper buttons of any sort.

I'm not sure what's wrong with your phone, but if it can't access any SSL websites, that's a huge problem. We will definitely be trying to set up SSL on here. It's crazy to have a site with user accounts and passwords and no SSL. I am indeed blocked from accessing G3 on my phone. I do not have an issue with all sites that use HTTPS/SSL, only some. When I try to navigate to https://www.gibberlings3.net/ I get the the following error message: On my computer I manually downloaded G3's security certificate and emailed it o my cell phone (for reference, it is a Blackberry Bold 9930 running Blackberry OS 7.1 Bundle 2879). I then installed it on my phone and explicitly trusted it. I get the same message as before and am unable to access G3. When looking at the installed security certificate, I see the following along with the other standard information: Edit: This wysiwyg-only interface it really terrible. I can't figure out how to un-mangle this post...

My ancient phone is my primary means of accessing the forums (both SHS and G3). Unfortunately, it isn't compatible with some modern security certificates involved in the process of serving websites and forums as HTTPS. As a result, I have completely lost access to the Beamdog forums with my phone, which has severely impacted my presence there. I'm not sure what will be involved in these forum software upgrades, but I will be VERY, VERY sad if I lose access to G3 and SHS.

With NI you can export it as a PNG, make your edits, then convert it back to MOS V2

In this case, you might be better off using NearInfinity.

Maybe bold the keys to help distinguish them from their values?

A blind guess, but if multiple tools that usually work are throwing errors on this file, then maybe it was corrupted when it was read from the CD? Try copying it off of the CD again, or obtaining it from a different source. Do you have mods installed that might have modified the file(s) involved?

The command-line tool I'm writing uses a modified median cut algorithm I wrote and seems to produce results comparable to ImageMagick without dithering. The quantization algorithm supports the alpha channel, but I haven't really tested how good the results are. I built in the ability to weight the different channels differently, so some tweaking of the default settings may or may not be in order. My tool can read BAM, BAMC, BAMU, and BAMD files and save them as BAM or BAMC files, optionally with quite extensive compression. It can also save files as BAMDs or animated GIFs, and can export and import palettes in a variety of formats including PAL, ACT, BMP, visual BMP, and raw. I natively support GIF and some BMP variants in imports and exports, and use GDIplus for the rest which means BMP, DIB, RLE, JPG, JPEG, JPE, JFIF, GIF, TIF, TIFF, and PNG are also supported, although import isn't as fast. There are a few more things I'm still working on (like importation of animated GIFs), but I'm working towards an alpha release. I hear rumors that Beamdog will be releasing another of their in-house BAM tools soonish. As nice as that sounds, I kind of hope it doesn't render this little pet project of mine obsolete. I have put quite a bit of time into it over the years.

The wikipedia page for INI doesn't mention it, but I'm pretty sure any language relying on Windows API to read INI files will limit the length of a key's value to 65,535 characters. This presumably includes AutoIt (and so BWS) and AutoHotkey. Just a tidbit to keep in mind in the event of rather verbose descriptions...