Jump to content

Sam.

Modders
  • Content Count

    140
  • Joined

  • Last visited

About Sam.

  • Birthday 06/25/1991

Profile Information

  • Gender
    Male
  • Location
    USA

Contact Methods

  • Website URL
    http://classicadventuresmod.com/
  1. Sam.

    New engine

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

    Addressing the Recent Downtime

    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...
  3. Sam.

    Addressing the Recent Downtime

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

    how to edit MOS v2?

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

    how to edit MOS v2?

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

    Mod metadata source - brainstorming

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

    Can't decompress area bif

    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?
  8. Sam.

    BAMU File Format

    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.
  9. Sam.

    Mod metadata source - brainstorming

    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...
  10. Sam.

    Mod metadata source - brainstorming

    Where does the key "Information" point to for a mod that has a readme, a forum, and a website all hosted online, and not necessarily at the same base URL? Also, if you mandate everyone conform exactly to "an industry standard", you must point to strict documentation of that standard. Preferably, the standard and documentation would be rigorously maintained by a recognized authority. Ideally, the format chosen would be established and widespread enough to be *natively* supported by many programming languages, and IMO be human-readable.
  11. Sam.

    Read ini file > assign variable values

    Isn't it more elegant to format your INI file as valid WeiDU variable assignments and INCLUDE it?
  12. Sam.

    BAMU File Format

    Thanks for looking.
  13. The EEs have 32-bit bitmaps that have a Windows BMP Version 5 header, which is not documented in the IESDP. A decent explanation of the BMP file format (I generally find it more useful than what is already in the IESDP) can be found here, and a breakdown of the Bitmap V5 Header can be found here. For reference, I'll provide an overview of the structure along with values from a file (1CHELMX6.bmp) that is typical of those found in the EEs: ;;;;; 32-bit Windows 5.x BMP ;;;;; http://www.fileformat.info/format/bmp/egff.htm https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/ns-wingdi-bitmapv5header BMP Version 5 (Microsoft Windows 5.x) Offset Type Size Data Description Typical Example From EE 0 WORD 2 FileType File type, always 4D42h ("BM") BM 2 DWORD 4 FileSize Size of the file in bytes 120458 6 WORD 2 Reserved1 Always 0 0 8 WORD 2 Reserved2 Always 0 0 10 DWORD 4 BitmapOffset Starting position of image data in bytes 138 14 DWORD 4 Size Size of this header in bytes 124 18 LONG 4 Width Image width in pixels 160 22 LONG 4 Height Image height in pixels 188 26 WORD 2 Planes Number of color planes 1 28 WORD 2 BitsPerPixel Number of bits per pixel 32 30 DWORD 4 Compression Compression methods used 3 34 DWORD 4 SizeOfBitmap Size of bitmap in bytes 120320 38 LONG 4 HorzResolution Horizontal resolution in pixels per meter 2834 42 LONG 4 VertResolution Vertical resolution in pixels per meter 2834 46 DWORD 4 ColorsUsed Number of colors in the image 0 50 DWORD 4 ColorsImportant Minimum number of important colors 0 54 DWORD 4 RedMask Mask identifying bits of red component 0x00FF0000 58 DWORD 4 GreenMask Mask identifying bits of green component 0x0000FF00 62 DWORD 4 BlueMask Mask identifying bits of blue component 0x000000FF 66 DWORD 4 AlphaMask Mask identifying bits of alpha component 0xFF000000 70 DWORD 4 CSType Color space type 1934772034 (sRGB) 74 LONG 4 RedX X coordinate of red endpoint 0 78 LONG 4 RedY Y coordinate of red endpoint 0 82 LONG 4 RedZ Z coordinate of red endpoint 0 86 LONG 4 GreenX X coordinate of green endpoint 0 90 LONG 4 GreenY Y coordinate of green endpoint 0 94 LONG 4 GreenZ Z coordinate of green endpoint 0 98 LONG 4 BlueX X coordinate of blue endpoint 0 102 LONG 4 BlueY Y coordinate of blue endpoint 0 106 LONG 4 BlueZ Z coordinate of blue endpoint 0 110 DWORD 4 GammaRed Gamma red coordinate scale value 0 114 DWORD 4 GammaGreen Gamma green coordinate scale value 0 118 DWORD 4 GammaBlue Gamma blue coordinate scale value 0 122 DWORD 4 Intent Rendering intent for bitmap 0 126 DWORD 4 ProfileData Offset to profile data 0 130 DWORD 4 ProfileSize Size of embedded profile data 0 134 DWORD 4 Reserved3 Always 0 0
  14. BAMWorkshopII supports an unpaletted BAM format (BAMU) and has the following to say about it: "Beyond Infinity" sounds suspiciously like GemRB. Was this format ever implemented anywhere, or does any further documentation about it exist? Looking at a BAMU, the Header looks like: Offset Size (data type) Description 0x0000 4 (char array) Signature ('BAMU') 0x0004 4 (char array) Version ('V1 ') 0x0008 2 (word) Count of frame entries 0x000a 1 (unsigned byte) Count of cycles 0x000b 1 (unsigned byte) The compressed colour index for RLE encoded bams (ie. this is the colour that is compressed) 0x000c 4 (dword?) Unknown field. One observed value is 0xFF0000FF 0x0010 4 (dword) Offset (from start of file) to palette 0x0014 4 (dword) Offset (from start of file) to frame entries (which are immediately followed by cycle entries) 0x0018 4 (dword) Offset (from start of file) to frame lookup table Note I’m unsure what the 4 bytes at 0x000c are for. Any ideas? OffsetToPalette is usually/always 0, and no palette appears to be stored in the file. Otherwise, Frame Entries, Cycle Entries, and Frame Lookup Table sections are the same as in BAM V1, except that frames do not have RLE. Frame data is stored as 24bpp in the RGB order, and has no scanline padding.
  15. Sam.

    Duplicate Items ?

    Some legacy mods set the storage capacity to 0 which makes them "truly unlimited", but that has been shown to cause problems like you describe in the past. The better practice for "truly unlimited" storage is to set the capacity to one less than the maximum possible value of the field (a signed integer?), but 999 should be perfectly fine. If you are on a classic game, there might have been a TobEX component that had something to do with containers (I can't remember for sure). If you're on the latest version of an EE game, try to reproduce the behavior without mods installed, and if you can report it to BeamDog. Other than that, I'm not sure what to suggest.
×