LoS feature itself works fine, but players can move through walls (with spamming key presses or dragging their token). Will assume problem is tied with file size.

Added the file in drive: https://drive.google.com/file/d/1O4fVdVbCiOWn12kd1o_WNeLmTiky0umE/view?usp=sharing

Reference to forum: https://www.fantasygrounds.com/forums/showthread.php?69484-Player-token-moving-through-walls

Hey there, thank you for this export. I am just getting into DD and working on a project and came across something that you may or may not have the ability to do anything about. But maybe we can get something changed.

In the Forgotten Adventures asset pack, there is door frames that can be placed separately from doors. They are in the portal tool, so you end up with in effect, two doors. I endedup remaking my map to not use them but would love to see support for door frames.

Anything I can do to help let me know.

Thanks

Keep it command-line only and operating system agnostic Allow a configuration file to be specified ( -c , or look for a default "uvtt2fgu.yaml") Config file specifies

• source directory (default pwd)
• img output directory (default pwd)
• xml output directory (default pwd)

Runs over all .dd2vtt files and convert them Default to check modified dates on output files to determine whether to overwrite them Force (-f) overrides modified check Add a remove (-r) option that removes the .dd2vtt file once processed

Reasoning: Can put the executable or script file in a directory and run it with a click. Can export all .dd2vtt files into a single folder and then run the script to process changed ones. With a cron job you could set up a "process queue" folder, using the -r parameter to keep the folder clean

When i create a simple figure with some walls and maps the image is not at the same place than the walls and lights. I haven't that problem with 1.0.1.1. Thanks.

The default Pillow jpeg settings default to quality 75 and don't use the optimize setting. This PR adds the defaults

        self.jpgQuality = 90
        self.jpgOptimize = True
        self.jpgSubsampling = 2

which results in the following improvements:

Original:

With higher quality settings:

Obviously this does increase file sizes; so I've added this as configuration that can be overridden if the user wishes.

From the FGU forums: https://www.fantasygrounds.com/forums/showthread.php?68774-A-new-Dungeondraft-to-Fantasy-Grounds-Unity-conversion-tool&p=621360#post621360

I don't know if you can differentiate types of vision blocks, but if you enable vision blocking for an object within Dungeondraft, the resulting object gets a hard wall where a terrain wall would be more suitable because the players can't see the object within the wall otherwise.

Love the script Imagix, use this for tons of my Sunday games.

I was working with getting a JPG/XML export setup in the .conf file set in &Appdata& and the script generated a 0kb jpg with no xml.

With the conf file:

[default]
xmlpath=!PATH!\ExportedMaps
writepng=False
jpgpath=!PATH!\ExportedMaps

#jpgQuality=75
#jpgSubsampling=2
#jpgOptimize=True

force=True
``
--CMD--
PS !PATH!> ./uvtt2fgu.exe ./SuperCave.dd2vtt
Traceback (most recent call last):
  File "uvtt2fgu.py", line 617, in <module>
  File "uvtt2fgu.py", line 611, in main
  File "uvtt2fgu.py", line 451, in processFile
  File "uvtt2fgu.py", line 418, in writeJpg
  File "PIL\Image.py", line 2172, in save
  File "PIL\JpegImagePlugin.py", line 655, in _save
ValueError: Invalid quality setting
[23088] Failed to execute script uvtt2fgu
----

The error is generated and just the 0kb jpg exists. The error can be avoided by removing the comments in the above. However I wouldn't expect that I have to set those flags as those are the default values that are used without a config.

The underlying jpg library has some additional controls that can adjust the quality of the jpg generated. Provide configuration parameters to allow them to be used.

Fixes #25

The code retrieving the data from the config file wasn't defaulting to valid values, but would default to None, causing errors later. Specifying the three configuration parameters manually would workaround the issue.

Attempting to convert a dd2vtt file with too large of an image file may result in an error message such as: PIL.Image.DecompressionBombError: Image size (458752000 pixels) exceeds limit of 178956970 pixels, could be decompression bomb DOS attack.

There should be a command-line parameter/config file parameter for changing this limit.

According to Smiteworks, the pixel coordinate values are floating point, but are only supposed to be 1 decimal point of precision (as opposed to whatever a float can do).