1153 replies to this topic

[Creepin]

I am not sure this works as intended:

 

Spoiler

This is how WPHDDINV.BAM looks like with "Single frame BAM output" filter applied,

 

and this is how the same bam looks like when both "Center BAM Frames" and "Single frame BAM output" filters applied.

 

Or it's not a bug and filters are working exactly as they are supposed to?

[Argent77]

The output filter works as intended (just try it out with one of the many split item description images, e.g. CAMUL02.BAM).

In you case the center location of the BAM frames doesn't produce a seamless image. I'd guess the game engine does some internal calculations to render the image. You could manually adapt the Y value of the frame center location, but that would require some trial and error. It's probably easier to export the BAM frames as graphics and manually assemble them in a graphics editor.
 

[Creepin]

Thank you for prompt reply Argent77, I'll adjust it manually then

[Argent77]

Update: NearInfinity v2.1-20171124

Changes:

• Added option to scale the default font sizes of UI controls (Options > Change Global Font Size), which should improve usability on high DPI monitors.
• Switched color selection control, as used by creature colors or effect opcode 7 (Set Color), from slider to list.
• Area Viewer: Use individual color shades for different region types (trap, info, travel).
• BAM Converter: Resize filter supports scaling along individual axes.
• Improved description of PRO area flag labels regarding target selection.
• Improved icon display of SPL and ITM resources in Viewer tabs.
• Reference search should ignore empty CRE script names.
• Fixed a bug that prevented BALDUR.SAV files from being compressed if they contained empty files.
• Various internal fixes and optimizations.

 

The new option "Change Global Font Size" (found under Options menu) has been added to help users on monitors with 4k or higher resolutions. I didn't have the opportunity to test NI with these resolutions yet, so any feedback is highly appreciated.

[Vlad]

I don't know what you did to the code, but it is now damaging saved games. In the previous versions of yours, it was impossible to compress the saved game files at all. Now it's possible, but it is still killing some areas in the saved game. 

 

[EDIT] See the attached save. You won't be able to see it in the game because you don't have my files, but maybe you can see the code. The completely broken area is TT7005. Also, TT7001 makes problems. I didn't test other areas in this save, but may be they are too.

Attached Files

•  000000001-Quick-Save.zip   1.05MB   115 downloads

Edited by Vlad, 01 December 2017 - 02:43 PM.

[Argent77]

I couldn't reproduce the issue with the attached save in latest NI version (v2.1-20171124). The content of the BALDUR.SAV is identical with the original after a recompress operation. The file TT7005.ARE doesn't show any signs of corruption in NI either.

However, I'm using a different compression rate as the game. Maybe this is something the game chokes on. Could you test recompressing the save again with the attached NI version?
 

Attached Files

•  NearInfinity-sav-test.zip   2.85MB   165 downloads

[Vlad]

Nothing works. After re-compressing, the area is downloaded but in a couple of seconds freezes. Any attempt to move to another area is freezing on the save game screen. Any saved game re-compressed behaves similar. At some point it starts freezing (when attacking enemies or moving to another area etc.)

 

[EDIT] You may try to revert to original code to solve the problem. The original release 1.32 and even the release 1.33 from 2012 were very stable with no major issues.

Edited by Vlad, 02 December 2017 - 03:08 AM.

[Argent77]

There must be something else interfering. The NI version attached to my previous post produces a BALDUR.SAV that is bit-exact with the file from your attached save.

[Vlad]

I've decompressed and compressed the save game with NI 1.33 - no problems. Did the same with the version you attached, and the saved game started again to freeze. I don't know but there must be some explanation. Maybe you're right - the problem is in somewhere else.

[Argent77]

The only notable difference between older and newer releases is a new Java I/O API I'm using to perform read and write operations on files. I haven't heard of any compatibility issues with the new API though.

If you want to check if it makes a difference, you could try your luck with NI v1.36-20160214 (last release with the old I/O API and Java 6 compatibility).

[Sam.]

It would be super awesome if the Convert image to MOS dialog could handle multiple input files at a time (or even just a whole folder of images).  The same probably goes for the image to TIS converter.  Any chance that could happen?

[Roxanne]

It would be super awesome if the Convert image to MOS dialog could handle multiple input files at a time (or even just a whole folder of images).  The same probably goes for the image to TIS converter.  Any chance that could happen?

You mean like this tool?

http://www.shsforums...tis#entry590082

[Argent77]

It would be super awesome if the Convert image to MOS dialog could handle multiple input files at a time (or even just a whole folder of images).  The same probably goes for the image to TIS converter.  Any chance that could happen?

I'll add batch functionality to my todo list, but I can't promise anything.

For now I agree with Roxanne. tile2ee is the tool of choice for batch converting MOS files. For TIS conversion I would still recommend NI though, as it uses information from WED files to optimize texture layout.

[Sam.]

It would be super awesome if the Convert image to MOS dialog could handle multiple input files at a time (or even just a whole folder of images).  The same probably goes for the image to TIS converter.  Any chance that could happen?

You mean like this tool?

http://www.shsforums...tis#entry590082

 

 

It would be super awesome if the Convert image to MOS dialog could handle multiple input files at a time (or even just a whole folder of images).  The same probably goes for the image to TIS converter.  Any chance that could happen?

I'll add batch functionality to my todo list, but I can't promise anything.

For now I agree with Roxanne. tile2ee is the tool of choice for batch converting MOS files. For TIS conversion I would still recommend NI though, as it uses information from WED files to optimize texture layout.

My issue was I had 70 PNG files that I wanted to convert directly to MOS V2, which looking at tile2ee I don't think it can do.  I ended up writing an automation script to control NI's interface to automate the conversion, but it took a bit of fiddling because I couldn't detect the Class of the java GUI elements.  Both MOS and PVRZ are lossy formats compared to PNG, and as a general rule the fewer transcodings between lossy formats you have to perform the better your final result will be.  Thus my interest in direct PNG->PVRZ batch processing (but I suppose it's possible NI converts the PNGs to MOS V1 internally as part of the process anyway).

[Argent77]

Yeah, tile2ee is only able to convert between MOS or TIS formats.

You don't need to worry too much about PVRZ quality loss. The texture formats DXT1/DXT5 are nearly lossless. Except for very special pixel patterns you won't see artifacts even after converting back and forth hundreds of times. Btw, NI converts PNG directly into PVRZ without (lossy) intermediate steps.

If all your PNG files are less than 1024x1024 pixels and you're up for a challenge, you could write a WeiDU mod to generate MOS V2 files with help of the command line tool "PVRTexTool" from the PowerVR SDK. The tool converts graphics files into the PVR format, which can be compressed by WeiDU's zlib compression functions into PVRZ format. The associated MOS V2 file can be generated with WeiDU commands as well. I made a related mod recently, which involves operations for compressing/uncompressing PVRZ and converting PVR files via PVRTexTool.

Edited by Argent77, 10 December 2017 - 09:21 AM.

[Sam.]

If all your PNG files are less than 1024x1024 pixels and you're up for a challenge, you could write a WeiDU mod to generate MOS V2 files with help of the command line tool "PVRTexTool" from the PowerVR SDK. The tool converts graphics files into the PVR format, which can be compressed by WeiDU's zlib compression functions into PVRZ format. The associated MOS V2 file can be generated with WeiDU commands as well. I made a related mod recently, which involves operations for compressing/uncompressing PVRZ and converting PVR files via PVRTexTool.

If I understand correctly, a PVRZ file can store a number of textures up to dimensions of 1024x1024, and multiple MOS V2 files can refer to textures within the same PVRZ file.  This means that instead of 70 MOS V2 files referring to 70 PVRZ files, I could have all of the textures within a single PVRZ file thus freeing up 69 PVRZ pages for other mods to use.  If this is indeed the case I would probably be interested in such a project, except I would quickly hit the WeiDU filesize limit making the entire project rather pointless...

[Argent77]

If all your PNG files are less than 1024x1024 pixels and you're up for a challenge, you could write a WeiDU mod to generate MOS V2 files with help of the command line tool "PVRTexTool" from the PowerVR SDK. The tool converts graphics files into the PVR format, which can be compressed by WeiDU's zlib compression functions into PVRZ format. The associated MOS V2 file can be generated with WeiDU commands as well. I made a related mod recently, which involves operations for compressing/uncompressing PVRZ and converting PVR files via PVRTexTool.

If I understand correctly, a PVRZ file can store a number of textures up to dimensions of 1024x1024, and multiple MOS V2 files can refer to textures within the same PVRZ file.  This means that instead of 70 MOS V2 files referring to 70 PVRZ files, I could have all of the textures within a single PVRZ file thus freeing up 69 PVRZ pages for other mods to use.  If this is indeed the case I would probably be interested in such a project, except I would quickly hit the WeiDU filesize limit making the entire project rather pointless...

A PVRZ file, as used by the EE engine, is basically a canvas that may contain one or more graphics regions, where each region is referenced by associated TIS/MOS/BAM V2 files. The automation I talked about earlier does only work if you place one graphics per PVRZ file - a limitation of the PVRTexTool. PVRZ slots aren't really scarce (engine supports PVRZ files from MOS0000.PVRZ to MOS99999.PVRZ), so using one PVRZ texture per MOS file is fine.

PVRTexTool syntax is straightforward. For example, to convert a PNG into PVR with BC1 (DXT1) pixel encoding, call

PVRTexToolCLI.exe -i source.png -o target.pvr -f BC1,UBN,lRGB -potcanvas +

"-potcanvas +" is optional. It expands the canvas size to be a power of 2.

 

WeiDU's COMPRESS_xxx routines can turn the PVR into PVRZ. A MOS V2 is basically just a header with (in this case) a single PVRZ reference block.

[Sam.]

On items, I think it would be appropriate to edit the "Equipped appearance" as a string which does not currently appear to be an option.  Also, YW should probably be "Wings, Male" and ZW should be "Wings, Female".  Both originate from 1pp: Attachable Wings.

[Creepin]

On items, I think it would be appropriate to edit the "Equipped appearance" as a string which does not currently appear to be an option.

I second that! It's not THAT difficult to edit equipped appearance field in the "raw" tab, but I'd feel much safer doing it within "edit" tab of NI.

[Argent77]

On items, I think it would be appropriate to edit the "Equipped appearance" as a string which does not currently appear to be an option.  Also, YW should probably be "Wings, Male" and ZW should be "Wings, Female".  Both originate from 1pp: Attachable Wings.

It is possible, but only indirectly. Right-click on the field and select "Edit as hex". Right-click again and select (the now available) "Edit as string". I'll see if I can expand the datatype for "Equipped appearance" to allow setting custom strings.

I don't know what YW stands for. In BGEE it doesn't seem to work. The only item with YW appearance is WING01B.ITM, which isn't used by the game. ZW doesn't look gender-specific. It can also be used by both male and female characters.