1165 replies to this topic

[Argent77]

What exactly do you want to have improved? Cloning an existing effect (or any other kind of removable structure) is just a matter of selecting "Copy" followed by "Paste" from the popup menu. That's just two clicks (or four clicks if you count the right clicks as well) instead of 50.

[The Imp]

Ahh... it's done via right click.. nver mnd ..

[Sam.]

This isn't a particularly high priority, but I was just reminded of how poor NI's support of PLT files is.  They are not editable at all, nor are they even displayed properly.  At the very least, could we get a "Raw" edit tab?

 

Some relevant topics:

PLT file format on IESDP

PLT files -> IESDP Archive Forum

*.PLT Intensity -> IESDP Archive Forum - Best info of the three?

 

 

Edit:  On a side note, Notepad++ has a feature that when you highlight a word (or variable), every instance of that word is also highlighted.  That would be a VERY useful feature for NI's new script editor interface.

 

Edit2:  Updated broken links

Edited by Sam., 15 March 2021 - 07:37 PM.

[Argent77]

This isn't a particularly high priority, but I was just reminded of how poor NI's support of PLT files is.  They are not editable at all, nor are they even displayed properly.  At the very least, could we get a "Raw" edit tab?

PLT is probably one of the few remaining parts of NI that hasn't been changed since it was implemented by the original author.

I've never really worked with the format before, but I'll look into it eventually. Maybe I can implement some improvements.
 

 

Edit:  On a side note, Notepad++ has a feature that when you highlight a word (or variable), every instance of that word is also highlighted.  That would be a VERY useful feature for NI's new script editor interface.

I'll add it to my (ever-growing) to-do list.

[Creepin]

This isn't a particularly high priority, but I was just reminded of how poor NI's support of PLT files is.  They are not editable at all, nor are they even displayed properly.  At the very least, could we get a "Raw" edit tab?

While we're at it, could I ask for an "export as bmp" option for PLT files as well? NI already know how to read PLT, seeing as how it draws them in its own interface, so extracting such picture as a BMP should not be that hard to add I hope. So far I had to printscreen NI with PLT in question opened, put the whole screen in photoshop and cut away everything but the picture

[Argent77]

I've looked into the PLT file format (@Sam. thanks for the links) and it appears  the format hasn't been properly implemented into NI in the first place. For example, the available PLT_*.BMP files that can be used to recolor the PLT preview are completely unrelated (and are actually part of a riddle on WK Level 4).

I would have to reimplement large parts of the PLT viewer to account for the features this format is offering. I can't say yet when I have the time for such a big task.
 

[Argent77]

Update: NearInfinity v2.1-20170529

Changes:

• Added a "Properties" feature to PVRZ resource viewer (thanks winterheart).
• New export option for PVRZ resources: to PVR (uncompressed).
• Image to PVRZ converter accepts PVR input files which will be compressed directly without reencoding. (Useful if you want to preserve pixel encoding type that are not supported by NI.)
• Paste operations (from a preceding copy/cut action) will insert removable structures at current selection as opposed to being simply appended as done in previous versions.
• Fixed a bug that prevented new or changed CRE script names from being cached after refreshing the resource tree.
• Fixed erroneous warnings about missing 2DA resrefs triggered by script compiler.
• Marked opcode 322 (AoE evade check) as deprecated.
• General code cleanup and optimizations (thanks winterheart)

[Argent77]

A first work-in-progress preview of the new PLT resource viewer:

Spoiler

(There is still a lot to do though.)

[Creepin]

A first work-in-progress preview of the new PLT resource viewer

That there is so damn impressive, thank you for tackling PLT!

*me wonders if that "export" button allows export as an actual pic, and - if one allowed to dream - padded with appropriate offset*

[Argent77]

@Creepin, @Sam. (and everyone else): Can you test the PLT viewer of the attached NI snapshot? Does it work correctly, or do you have suggestions how to improve it further?

 

Attached Files

•  NearInfinity-wip.zip   3.4MB   133 downloads

[Creepin]

That is so cool, thanks Argent77! I just loved how you could test various colour combinations from within NI. And offset too, you're making a job of paperdoll aligning so much easier! However, seeing how easily you've defeated NI I can't help but wish for more   Could IE export paperdoll BMPs in the same way it does export PLTs now? That is, as a single picture with offsets? PLT export will be of huge help when working with vanilla, and the same help would be really handy when working with 1PP, which deals in BMPs exclusively. Oooh, and did I mentioned how cool it would be to be able to test weapon paperdolls against body paperdoll to check for alignment and possibly adjust it right away?

 

Ahem, sorry, got carried away! Bugs...

- every time I export PLT paperdoll as a PNG, the cursor while within NI window turns into "busy" mode (I used to call it sandglass and now with Win7 how does it called, everrunning circle?) and not reverting back. Exported PNG is fine, though. May be exporting process doesn't stop properly.

- after you view CEFC2INV, then move away, and then view it again, it got some transparent pixels coloured (mainly between left hand and its shadow), same with CEFC3INV. Checked with NI 16.04.17 - these PLTs has got some shading at that place too, so may be it's not actually NI bug but game resource bug. Need some investigation perhaps?

Edited by Creepin, 01 June 2017 - 01:30 AM.

[Argent77]

Yeah, a number of PLTs contain "dirty" pixels on random positions. Busy cursor will be fixed.

 

Could IE export paperdoll BMPs in the same way it does export PLTs now? That is, as a single picture with offsets?

Which BMP files are your referring too? I haven't played the original games for some time. Afaik, there are a number of BAM files in the games that can be used for paperdolls. They can be exported as PNG without further postprocessing. However, you can use a graphics editor to expand canvas size of the graphics based on center point information to fix the offsets yourself.

 

[Creepin]

Which BMP files are your referring too? I haven't played the original games for some time. Afaik, there are a number of BAM files in the games that can be used for paperdolls. They can be exported as PNG without further postprocessing. However, you can use a graphics editor to expand canvas size of the graphics based on center point information to fix the offsets yourself.

Yep, sorry, my mistake - of course I was talking about BAM, not BMP You're correct that exported parts could be seamed together manually, the point of my idea was exactly to relay this work to NI so as to get BMPs done from BAMs with all frames automatically attached to one another. I was mainly referring to paperdoll BAMs having two frames, like CExxxxxx, CHxxxxxx and so on, but this could be extended also to description image BAMs where one had to manually assemble one picture exported as 4 separate part BMPs. By the way, displaying such description images from within NI itself could also benefit from having the whole image shown at once, not 1/4 of it at one time.

[Sam.]

In ToB, switching back and forth between two PLTs seems to randomly select which colors are pre-selected.  Is this intentional?  What does the "default" image look like before paletted gradients are applied?  Note that the debug console is blank.

 

In ToB, MPAL256.bmp only has 120 rows, and selecting an index greater than 119 (it skips from 119 to 200) seems to apply a random color.  I would think the colors/indices you are able to select should be tied directly to the MPAL256.bmp found in that game.  In this case, indices 120 and high should not even appear in the dropdown box.  Note that the debug console is blank.  As the MPAL256.bmp has 256 rows in SoD, everything seems to behave normally here.

 

NI currently allows you to set the 7 colors stored in the CRE file, but do the list of colors that can be set by Effect #7 also play a role here, or do they simply overwrite these 7 CRE colors?

 

#7 (0x7) Colour: Set Character colours by Palette Variants: IWD1
Parameter #1:    Gradient Number
Parameter #2:    Location
Description:
Alters the colour of the area specified by the 'Location' field, to the colour gradient specified by the 'Gradient Number' field.
Known values for 'Location' are:
00 Belt Buckle (on armour) or amulets (on robes) - entire body for some animations
01 Minor colour
02 Major colour
03 Skin colour
04 Strap colour (on armour) or minor trimming (on robes - the centre strip down a robe and the hem on some robes)
05 Armor colour (and major trimming on robe - cross trim and cape trim on robe of archmagi)
06 Hair colour
16 Quillons or Crossguard
20 Grip (usually not visible as it's in the characters hand)
21 Blade or major portion of weapon
32 Shield hub
33 Shield interior
34 Shield panelling
34 Helmet misc
37 Shield rim
48 Helm ornamentation - i.e. wings
49 Helm ornamentation - i.e. feathers/horsehair
50 Helm ornamentation - i.e. feathers/horsehair
52 Helm face
53 Helm - the main covering
255 Whole Body (at least in IWD2)

 

I'll keep playing around with it when I have more time.  Great work, tho!

[Argent77]

 I was mainly referring to paperdoll BAMs having two frames, like CExxxxxx, CHxxxxxx and so on, but this could be extended also to description image BAMs where one had to manually assemble one picture exported as 4 separate part BMPs. By the way, displaying such description images from within NI itself could also benefit from having the whole image shown at once, not 1/4 of it at one time.

This use case is a bit too specific. It wouldn't work on the vast majority of BAM files. I might find a good way to implement it eventually, but I consider it low priority atm.
 

In ToB, switching back and forth between two PLTs seems to randomly select which colors are pre-selected.  Is this intentional?  What does the "default" image look like before paletted gradients are applied?  Note that the debug console is blank.
 
In ToB, MPAL256.bmp only has 120 rows, and selecting an index greater than 119 (it skips from 119 to 200) seems to apply a random color.  I would think the colors/indices you are able to select should be tied directly to the MPAL256.bmp found in that game.  In this case, indices 120 and high should not even appear in the dropdown box.  Note that the debug console is blank.  As the MPAL256.bmp has 256 rows in SoD, everything seems to behave normally here.

Yes, that's intentional. I'm using a (hardcoded) small selection of color indices inspired by values from RANDCOLR.2DA and apply them randomly to each color type. I can probably add an option to disable randomization.

 

Unfortunately PLT does not contain a "default" image as it always requires an external color range (i.e. pixel row from MPAL256.BMP) for display. Each PLT pixel definition consists of a color type (hair, skin, metal, shadow, ...) and an "intensity" value which maps to the color of the pixel on the selected MPAL256.BMP row. The pixel row itself must be specified externally. Disabling randomization would simply result in using the first available color range for each type (which is a black/gray gradient), or maybe a "fake" grayscaled gradient.

 

I'll leave the random color selections in for now. They can be useful to get an impression how it would look like in-game (even if you can't select them for party members directly).

 

NI currently allows you to set the 7 colors stored in the CRE file, but do the list of colors that can be set by Effect #7 also play a role here, or do they simply overwrite these 7 CRE colors?

I don't know how opcode 7 is implemented, but I'd guess it remaps color locations based on item type since I haven't seen PLT resources yet that use color type values outside of range 0..7.

[Sam.]

In ToB, MPAL256.bmp only has 120 rows, and selecting an index greater than 119 (it skips from 119 to 200) seems to apply a random color.  I would think the colors/indices you are able to select should be tied directly to the MPAL256.bmp found in that game.  In this case, indices 120 and high should not even appear in the dropdown box.  Note that the debug console is blank.  As the MPAL256.bmp has 256 rows in SoD, everything seems to behave normally here.

Yes, that's intentional. I'm using a (hardcoded) small selection of color indices inspired by values from RANDCOLR.2DA and apply them randomly to each color type. I can probably add an option to disable randomization.

This is what I am seeing:

Note the mismatched numbering and mystery question marks on the left (Tob) vs the right (Sod).  This is intentional?

[The Imp]

  This is intentional?

Yes, because the non-EE BG2 doesn't have those numbers assigned to a thing. Well, unless you install the color extender. 1PP or Infinity anim... or other mod that does that.
Could be that you have the paperdoll exported from another game to this one and that causes the number to show up as it's on a paperdoll even though it's not in the actual in the index of the in game files...

Edited by The Imp, 01 June 2017 - 04:58 PM.

[Sam.]

  This is intentional?

Yes, because the non-EE BG2 doesn't have those numbers assigned to a thing. Well, unless you install the color extender. 1PP or Infinity anim... or other mod that does that.

You don't think it is reasonable to have the dropdown box selections stop when the available options run out?

Edited by Sam., 01 June 2017 - 04:59 PM.

[The Imp]

Well, maybe, but then ... Can you answer this, what number is the letter Ä ... the answer is that like said, it's not a number, but the editor should show it as one as it's in the files. Well if it were...

Edited by The Imp, 01 June 2017 - 05:27 PM.

[Argent77]

Note the mismatched numbering and mystery question marks on the left (Tob) vs the right (Sod). This is intentional?

The question mark indicates an entry taken from RANDCOLR.2DA.

Enhanced Editions (and certain mods) define many more color ranges which even overlap the range of random color definitions from RANDCOLR.2DA. I decided to prefer fixed color ranges over random color definitions when both are defined, so you won't see random color entries in EE games. I can drop RANDCOLR.2DA support though if it's too confusing.

Edited by Argent77, 02 June 2017 - 04:21 AM.