Mod Added Area Compatability for BG2 and BG2EE in 2019?

[cmorgan]

Rechecking on this...

As I understand it,

We currently (2018-2019) ship mods with new areas for BG2 using .tis files.

EE games accept the old .tis format, so older mods do not *need* to update, and current folks don't *have* to update anything - mod added areas can be created in DLTCEP and edited in either NI or DLTCEP, and will work.

There is one "bug", reported to the EE folks but with no action as of this post - in an EE game referencing a mod area with the old .tis format, the area shows black lines between each of the tiles in the mod added area. In addition, old tilesets are noticeably slower on the EE platform.

On BGEE, SoD, and  BG2EE the new .tis format separates out and uses additional files in. pvrz  format - to avoid the black lines around each tile and improve performance on EE games, converting the .tis to a new format utilizing separate graphic files with extension .pvrz and installing both the converted .tis and the related .pvrz takes care of the problem.

 

THE CURRENT BEST WAY (my opinion) of making sure your area is updated to the new .tis format and its accompanying .pvrz files is to build the old area (or use the existing old area) as usual, and then use tile2ee  and Argent77's work to convert the old area directly on install. His tool added to your mod's folder in the way specified by the documentation, and the related Weidu library, can modify the appropriate files based on the install.

If you are more adventurous and want to be really efficient, follow Argent77's advice - build and convert any new areas to EE format for distribution, and then modify his example found in     ..\tile2ee-0.3b\weidu\example_tile2ee.txt    to run it only if it is on a BG2 based install  and ship his tile2ee tool with your mod. Basically, new modders probably expect a BGEE, BG2EE, or EET install, so only manipulate stuff if it is not in that format.

THE HACKY WAY for single area additions on limited cross platform options, and ancient old wheezing retired modders slowly moving into the light of day, can be adjusted for in old code with the following:

  As of January 1, 2019:

1. The easiest way to generate PVRZ-based TIS from the old tileset variant is with Near Infinity.
2. Using NI v2.1-20180615+ place all area files (are, tis, wed)  in the override folder.
3. Select Export... => as PVRZ-based TIS. 
4. Direct the output to a new folder, as the old .tis will be overwritten.
5. The converted .tis will have additional files like marea00.prvz, marea01.prvz, marea02.prvz <<not typos

PVRZ filename scheme is made up from the TIS filename minus second letter, followed by a two-digits pvrz index (e.g. AR1234.TIS -> A123400.PVRZ, A123401.PVRZ, ...), so you have to rename all your PVRZ files accordingly if you rename your TIS. For example, in my C-AR01.tis conversion, I ended up with C-AR01.tis, CAR0100.pvrz, CAR0101.pvrz, CAR0102.pvrz.

In folder  ../mymod/areas

• myarea.are
• myarea.mos
• myarea_old.tis (renamed original myarea.tis so that you can have 2 same-name .tis in same directory)
• myarea.wed
• myareaht.bmp
• myaream.bmp
• myareasr.bmp
• myarea_ee.tis (renamed converted myarea.tis so that you can have 2 same-name .tis in same directory)
• marea00.PVRZ (added with conversion to ee format .tis)
• marea01.PVRZ (added with conversion to ee format .tis)
• marea02.PVRZ (added with conversion to ee format .tis)

In .tp2 (or as is more fashionable now in a .tph file called from the .tp2)

/* resources : area creation */
PRINT ~Installing New Area~
COPY ~mymod/areas/myarea.are~ ~override~
COPY ~mymod/areas/myarea.mos~ ~override~
COPY ~mymod/areas/myarea.wed~ ~override~
COPY ~mymod/areas/myareaht.bmp~ ~override~
COPY ~mymod/areas/myaream.bmp~ ~override~
COPY ~mymod/areas/myareasr.bmp~ ~override~
  
ACTION_IF GAME_IS ~soa tob bgt~ THEN BEGIN
  PRINT ~Installing BG2 Area resources~
  COPY ~mymod/areas/myarea_old.tis~ ~override/myarea.tis~
END

ACTION_IF GAME_IS ~bgee bg2ee eet~ THEN BEGIN
  PRINT ~Installing BG2EE Area resources~
  COPY ~mymod/areas/myarea_ee.tis~ ~override/myarea.tis~
  COPY ~mymod/areas/marea00.pvrz~ ~override~  
  COPY ~mymod/areas/marea01.pvrz~ ~override~ 
  COPY ~mymod/areas/marea02.pvrz~ ~override~ 
  /* add area to cheat console in BG2EE/EET for testing/jumping about */
  /* lua table operation: table.insert (table, [pos,] value) with default being n+1 at end */
  APPEND ~BGEE.LUA~	~table.insert(cheatAreas, {"myarea", "my_area_name_in_game"} )~
END

APPEND ~mastarea.2da~
  ~myarea  value~
  UNLESS ~myarea~
  

The line APPEND ~BGEE.LUA~    ~table.insert(cheatAreas, {"myarea", "my_area_name_in_game"} )~ is not needed - but if you want to leverage the new cheatbox on EE games to provide quick movement to your area for testing, it saves having to build some test scripts or dealing with MoveToArea() typing.

Am I missing anything on this?  Are there other concerns?

 

Edited January 3, 2019 by cmorgan
Mike1072's logic cleanup, Argent77's post

[Mike1072]

It's .pvrz (not .prvz).  I can't speak to best practices on .tis/.pvrz, but you can simplify the logic to reduce code duplication. 

COPY ~mymod/areas/myarea.are~ ~override~
     ~mymod/areas/myarea.tis~ ~override~
     ~mymod/areas/myarea.mos~ ~override~
     ~mymod/areas/myarea.wed~ ~override~
     ~mymod/areas/myareaht.bmp~ ~override~
     ~mymod/areas/myaream.bmp~ ~override~
     ~mymod/areas/myareasr.bmp~ ~override~

ACTION_IF GAME_IS ~soa tob bgt~ THEN BEGIN
  COPY ~mymod/areas/myarea.tis~ ~override~
END ELSE
ACTION_IF GAME_IS ~bgee bg2ee eet~ THEN BEGIN
  COPY ~mymod/areas/myarea.pvrz~ ~override~
END

APPEND ~mastarea.2da~ ~myarea  value~
  UNLESS ~myarea~

[cmorgan]

Cool, good typo catch and logic - cleaned up initial post.

Edited January 3, 2019 by cmorgan
typo cathc =/= typo catch

[argent77]

There are several issues when using the old TIS format in EE games:
1. Glitches: As you already mentioned above, there may be thin black borders around some or many tiles (depending on zoom, current viewport, renderer, etc.).
2. Performance: Old palette-based tilesets are noticeably slower than PVRZ-based tilesets.

To solve these issues you can either provide two tileset variants (one for original games, another one for EE games), or perform on-the-fly conversion. I have written a tool for this (tile2ee) some time ago. It also contains a small WeiDU library that makes the conversion process much easier to deal with. I'd suggest to include PVRZ-based tilesets in the mod and convert them on-the-fly to palette-based tilesets if a non-EE game is detected.

The easiest way to generate PVRZ-based TIS from the old tileset variant is with Near Infinity. Place all the area files (are, tis, wed) in the override folder, select the TIS in NI and select Export... => as PVRZ-based TIS.

MOS files aren't strictly needed anymore for areas in EE games (afaik since patch 2.0).

Btw, PVRZ files are not a replacement for TIS. They are paired with TIS instead: TIS contains tile definitions (texture indices, tile size and position, ...) while PVRZ contains the actual graphics data.

[cmorgan]

 Way cool. Downloaded tile2ee and began poking about - it looks like a great solution. The weidu library handles all platforms, assuming that it is an old (non-ee) area and running it out.

To get things straight in my head and get things in-game quickly, is the edited code above correct *without* the on-the-fly conversion using tile2ee?

[argent77]

Yes, the code looks fine. Just remember that PVRZ filename scheme is made up from the TIS filename minus second letter, followed by a two-digits pvrz index (e.g. AR1234.TIS -> A123400.PVRZ, A123401.PVRZ, ...), so you have to rename all your PVRZ files accordingly if you rename your TIS.

 

[cmorgan]

Very cool - updating first post.

[jastey]

Totally missed this, and wanted to post a question about exactly this. Very cool!

@cmorgan How about making the first post a tutorial, and the rest of the thread the discussion thread?

[cmorgan]

Sure thing - I will poke about. Having temporary writer's block on the ToB romance on Aran, so distracting myself. Nothing a day or so won't break open - just have to start sketching and making sure it fits the old plans

I need to grab code blocks to describe the "convert New to Old" variant argent77 has suggested as best practice (and he wrote the tool, so I am definitely following his lead on this!!)

[jastey]

13 hours ago, cmorgan said:

I need to grab code blocks to describe the "convert New to Old" variant argent77 has suggested as best practice

This is what @CamDawg did in Amber v5 (and I assume it's best practice):

tp2 (only relevant parts for tis conversion):

ACTION_IF ee_game THEN BEGIN
  COPY ~amber/tilesets~ ~override~ // area tiles (PVRZ)
END ELSE BEGIN
  INCLUDE ~amber/lib/a7_tools.tpa~ // tile2ee macros
  LAF HANDLE_TILE2EE INT_VAR quality_v1 = 9 STR_VAR input_path = ~amber/tilesets~ END
END

The "a7_tools.tpa" is attached to this post.

Description of INT_VAR quality_v1 : Graphics quality when converting into palette-based (V1) format, in range [0..9]. The higher the better and slower. (Default: 4)

 

a7_tools.tpa

[CamDawg]

Until that's done, Amber v5 has a working example of on-the-fly TIS/PVRZ (EE) to TIS (original) conversion.

edit: jastey beat me to the punch. I used NI to generate the TIS/PVRZs which work in EE directly, and convert them for the originals. Since they're all small areas the time factor was immaterial in my testing, so I went with max quality_v1. That may not be the case for something with more and/or larger areas. Since the mos, wed, and are files are needed for both, they're copied over elsewhere in the mod without a game check.

[jastey]

And I really need to tagg @argent77 and say thank you, thank you, thank you for your work on all the tools, in this case tile2ee as well as NI with all the great export possibilities (weidu .d-files from dlgs, pvrz from tis - all available with one click, and so much more.) This is really awesome!

[subtledoctor]

Worth noting, just since this thread seems to be generally about the subject, that different versions of the EE games use different kinds of .pvrz files.  To use mods with new area and similar graphics (UI, stuff like that) on iOS or Android, currently players either 1) find and convert the .pvrz files in a mod, and then install the mod; or 2) install all mods, then convert all pvrz files in their override folder.

[jastey]

1 hour ago, subtledoctor said:

different versions of the EE games use different kinds of .pvrz files

 @subtledoctor please tell us windows-only modders what the best way of integrating tis/pvrz files into mods would be. Probably still what is said in the first post, and the player then use some cool little tool one of you helpful genius' created?

[jastey]

On 1/3/2019 at 3:24 PM, cmorgan said:

APPEND ~mastarea.2da~ ~myarea value~ UNLESS ~myarea~

One more question: when do I append an area to mastarea.2da and what exactly is it for?