Some bugs and issues found when developing Dwarf Campaign Chapter 4

Hello!

I would like to report some bugs and issues that I've found during the development of Dwarf Campaign Chapter 4. I am using the TFT World Editor with the patch 1.28.2.

1. Heroes specified with Items Dropped On Death do not drop those items on death. Maybe it has something to do with them being able to be revived. Anyways, we have to specify a custom Unit Dies trigger to generate the item instead of the normal way. I think it has been like this for years.

2. The World Editor needs to be restarted for custom models to show up correctly (those imported with the Import Manager). This is confusing especially for new people, who do not know this behaviour.

3. Invisible units with the Ghost ability show up visible in the Cinematic Mode. To circumvent this strange bug, we had to use Hide Unit before the cinematic and Unhide Unit after the cinematic.

4. Items and Doodads are missing "Text - Editor Suffix" property. This is a minor inconvenience, but it would be helpful for it to be there. And why not? As it is there for other objects.

I will keep posting bugs and issues as soon as we find more.

Best regards,
Tommi
 

Dr Super Good

Spell Reviewer
Level 59
Joined
Jan 18, 2005
Messages
26,619
2. The World Editor needs to be restarted for custom models to show up correctly (those imported with the Import Manager). This is confusing especially for new people, who do not know this behaviour.
You need to import the assets, save the map and then get the editor to load them. This way they show up without having to restart the editor application. If the editor loads the assets before they are imported and saved into the map it will have failed to load them and so display/cache the asset as missing until restarted.

3. Invisible units with the Ghost ability show up visible in the Cinematic Mode. To circumvent this strange bug, we had to use Hide Unit before the cinematic and Unhide Unit after the cinematic.
One is meant to hide/pause all non cinematic relevant units during cinematics to prevent them potentially interacting in unintended ways.

6. If you specify custom walls in one map by importing ReplaceableTextures\Cliff\Cliff1.blp, the new texture will show up in all maps open at the same time in the editor.
That is due to asset caching that World Edit employs. Same reason why you need to restart the editor for custom assets to show up if you failed to import and save before use.

Once an asset is loaded, it will use that instance of the asset for all references to the asset, even if the asset is physically different for another map (eg a custom tile/cliff texture).
 
8. Dialog button texts are different sizes on different resolutions. I tried 1366x768 (1024x768) and 2560x1440 (1920x1440), and indeed they are in different lengths.
9. It would be nice, if dialog buttons could be resized to be larger. Now they are always the same size.
10. Texts on the Loading Screen are different sizes on different resolutions (their font size differs). I tried 1366x768 (1024x768) and 2560x1440 (1920x1440) resolutions.
 

Dr Super Good

Spell Reviewer
Level 59
Joined
Jan 18, 2005
Messages
26,619
8. Dialog button texts are different sizes on different resolutions. I tried 1366x768 (1024x768) and 2560x1440 (1920x1440), and indeed they are in different lengths.
10. Texts on the Loading Screen are different sizes on different resolutions (their font size differs). I tried 1366x768 (1024x768) and 2560x1440 (1920x1440) resolutions.
You need to explain in what way the sizes are different or incorrect.

Text is meant to be the same physical size across all resolutions (same number of pixels). Only when using displays with different DPI settings should the size of text in pixels change.
 
I mean that here, for example, the text "Temple of the Old Gods" is in different sizes:

1366x768 it looks like this:
totg-1366x768.jpg


And in 2560x1440 (image scaled down to 1366x768) it looks like this:
totg-2560x1440-resized-1366x768.jpg


And finally on 1920x1200 (resized to 1366x854), it looks like this:
totg-1920x1200-resized-1366x854-v2.jpg


We can see that on each resolution the title and subtitle text are of different font sizes.

Best regards,
Tommi
 

Dr Super Good

Spell Reviewer
Level 59
Joined
Jan 18, 2005
Messages
26,619
We can see that on each resolution the title and subtitle text are of different font sizes.
One needs the full scale images to prove that. If they are different fonts then they will have different pixel sizes. As stated above, one expects text to remain the same font/physical size independent of resolution and should only change with display DPI setting.
 

Dr Super Good

Spell Reviewer
Level 59
Joined
Jan 18, 2005
Messages
26,619
Well you can see the relative sizes of the title/subtitle and the description are different.
Possibly. But without the full scale images one cannot tell which is being incorrectly scaled. The pixel height of the text should remain the same as long as the DPI of the display is the same. Different DPI values might use different text sizes as generally higher DPI needs bigger text in order for the text to remain the same physical size.
 
Level 11
Joined
Jun 2, 2004
Messages
849
To the OP, what is your opinion on the expected behavior? The text to stay the same absolute size (ie, 30 pixel tall text is 30 pixels no matter what), or be scaled with the resolution?

Personally it'd make most sense to me if the text were always scaled; this makes it so things like button text don't get weirdly small inside the box at high resolutions, and things like map description text don't have problems fitting in low resolutions. There are good arguments for keeping text the same absolute size but I'm not sure they're applicable in this situation; maybe for things like printing. The "correct" behavior is what's expected by the user.
 

Dr Super Good

Spell Reviewer
Level 59
Joined
Jan 18, 2005
Messages
26,619
To the OP, what is your opinion on the expected behavior? The text to stay the same absolute size (ie, 30 pixel tall text is 30 pixels no matter what), or be scaled with the resolution?

Personally it'd make most sense to me if the text were always scaled; this makes it so things like button text don't get weirdly small inside the box at high resolutions, and things like map description text don't have problems fitting in low resolutions. There are good arguments for keeping text the same absolute size but I'm not sure they're applicable in this situation; maybe for things like printing. The "correct" behavior is what's expected by the user.
Higher resolution displays are usually physically bigger. A 1920*1080 display is physically larger than a 1680*1050 display as the DPI is approximately the same between them. You want the text to have same physical height, and hence same pixel height. This is because one can consider the higher resolution display as a book with bigger pages so more text can fit per page than a lower resolution display which can be consider a book with smaller pages and less text per page. In the case of both books, the same sized font is used as that is optimized to be easy to read from the average book reading distance.

If the display DPI is higher, eg Apple Retina display, then the text should still remain the same physical size for readability. To do this it will need to use a pixel wise larger font or render the same font with higher DPI and larger pixel size (depends on the typeface system used). This is DPI awareness.

Then there is another usability feature that should be considered. If display conditions are sub optimal, eg a low DPI TV viewed from very far away, then one should be able to turn on extra large text. Extra large text is similar to DPI scaling except where as the real DPI is low for a huge TV, you want the game to treat it as a high DPI display to make the text larger and more visible. One can considered the effective useful DPI of your display as a function of physical DPI and viewing distance. Further viewing distance and higher physical DPI require pixel wise larger fonts.
 
We've found a quite bad bug in WC3. The targeting circle of Area of Effect abilities, such as Blizzard and Healing Wards, is way off at some cliff levels. We've seen that at the cliff level 12 in our map the targeting circle shows the right area, but at the cliff level 2, the circle is way off. Actually, the target of the ability, such as the healing ward, will be where the invisible cursor is at that time you click on the screen and not where the targeting circle is. We have not yet found a workaround for this bug. It basically renders all area of effect abilities unusable as you cannot target them right at some cliff levels. I think the reason for the bug is that WC3 calculates the cliff levels wrong for the targeting circle.
 

Dr Super Good

Spell Reviewer
Level 59
Joined
Jan 18, 2005
Messages
26,619
That is a very old bug... I was fixing maps with it over 3 years ago.

Target circles use the maximum of water and terrain mesh. If water mesh is specified higher than terrain mesh then targeting circles will float above the terrain mesh even if the water mesh is invisible due to turned off water flag. You iterate every terrain node and make sure that the physical height of the water mesh (factoring in water mesh offset defined by the terrain slk) is lower than the ground mesh.
 

Dr Super Good

Spell Reviewer
Level 59
Joined
Jan 18, 2005
Messages
26,619
Ok. How do we fix the bug then? I think almost all of our map is affected and it is 224x224 in size. Making everything into water is not much an option... unless we want to spend countless hours doing the thing. I hope there would be some easier way to fix the thing.
As I said...
You iterate every terrain node and make sure that the physical height of the water mesh (factoring in water mesh offset defined by the terrain slk) is lower than the ground mesh.
This process took <<1 second for a 480*480 map when I did it for someone in the past. It did take 5 minutes odd to write the Java program to do it though.
 

Dr Super Good

Spell Reviewer
Level 59
Joined
Jan 18, 2005
Messages
26,619
One more bug/issue:
11. If a unit changes owner (at least from Neutral Hostile to Neutral Passive), it will drop the items specified in the Items Dropped on Death. As a workaround, a unit dies trigger can be used instead.
That is working as intended? The item drop system of World Edit works by creating an on death trigger which then creates some items from item pools before destroying itself.
 
Level 11
Joined
Jun 2, 2004
Messages
849
They're saying the items are dropped from perfectly healthy units that just changed owners.

Tested it myself and yes it does drop items when going from Neutral Hostile -> any other owner, but they do NOT drop items if they were owned by anything other than Neutral Hostile. This is due to the Charm ability that Dark Rangers have; Blizz wanted people who charmed creeps to not lose out on items, so they added a special case for Neutral Hostile creeps changing owner.
 
Top