Resizing existing sprites

[Ralzar]

Note that all XML files in my mod increase each sprite by the same amount, which seems like a really redundant way to do this compared to simply having a size value declared together with the sprite archive number in EnemyBasics.cs

I confirm that a custom implementation of MobilePersonAsset is something you should consider. It would allow you to make all kinds of customizations and not only be limited to a fixed scale.
Xml files are retrieved with load order to serve a specific need; i would rather not break compatiblity by adding other ways to resize billboards. Maybe i can add a scale property to Archive.xml, which would serve as a base for additional scales defined in Archive_Record-0.xml. Would this work for you?

Honestly, I don't know enough coding to feel I can answer that competently

PS: I noticed that you have files for specific frames in your repository. This should't be needed, all frames have the same size so only Archive_Record-0.xml is actually read.

Hm, I'm having problems making this work correctly. I just attempted it with the Werwolf.

If I understand you correctly, I should be able to simply have:
264_0-0.xml
264_1-0.xml
264_2-0.xml
264_3-0.xml
etc
?

This mostly works, but I see the werewolf pop down to regular size mid-attack. Maybe because EnemyBasics.cs defines attack frames?

Code: Select all

PrimaryAttackAnimFrames = new int[] { 0, 1, -1, 2, -1, 2 }

[squerol]

Maybe because EnemyBasics.cs defines attack frames?

Code: Select all

PrimaryAttackAnimFrames = new int[] { 0, 1, -1, 2, -1, 2 }

So are attack frames of enemies editable? For example when hit collisions actually happens, etc?

[Ralzar]

Maybe because EnemyBasics.cs defines attack frames?

Code: Select all

PrimaryAttackAnimFrames = new int[] { 0, 1, -1, 2, -1, 2 }

So are attack frames of enemies editable? For example when hit collisions actually happens, etc?

I think yes, but I'm not sure what defines when attack hits.

[TheLacus]

If I understand you correctly, I should be able to simply have:
264_0-0.xml
264_1-0.xml
264_2-0.xml
264_3-0.xml
etc
?

This mostly works, but I see the werewolf pop down to regular size mid-attack. Maybe because EnemyBasics.cs defines attack frames?

Code: Select all

PrimaryAttackAnimFrames = new int[] { 0, 1, -1, 2, -1, 2 }

Enemies are implemented by DaggerfallMobileUnit, which reads custom scales for individual records and store them inside MobileUnitSummary.RecordSizes. Xml files for frames different than zero are never read, so they can't have any effect here.

If there are specific frames with unexpected size there may be a bug somewhere. I don't see anything suspicious in the code, can you tell me which record(s) are affected by the issue?

[Ralzar]

I'll try to recreate the test I did and see if I can identify the exact frames.

[BadLuckBurt]

I'll try to recreate the test I did and see if I can identify the exact frames.

Dump all the textures with Daggerfall Imaging and add the Dimensions column in Windows Explorer while in Details view. I think some frames just have different dimensions

[Ralzar]

I'll try to recreate the test I did and see if I can identify the exact frames.

Dump all the textures with Daggerfall Imaging and add the Dimensions column in Windows Explorer while in Details view. I think some frames just have different dimensions

Right, so since the method suggested by TheLacus only defines the size in the first frame, if some of them have different sizes it might bug out?

I'd agree, if not for the fact that the xml fils I created to resize the sprites are all identical. They all say to set size to 1.2. No consideration is taken for image size/dimansions.
So if that gets done through some kind of cascading effect or done for each individual frame should not produce this bug. But what do I know?
I'll test when I get home.

[BadLuckBurt]

Right, so since the method suggested by TheLacus only defines the size in the first frame, if some of them have different sizes it might bug out?

I'd agree, if not for the fact that the xml fils I created to resize the sprites are all identical. They all say to set size to 1.2. No consideration is taken for image size/dimansions.
So if that gets done through some kind of cascading effect or done for each individual frame should not produce this bug. But what do I know?
I'll test when I get home.

If only the 0-frame XML is being read and one of the other frames has a different height it would produce this bug so Im not sure I follow your logic. Anyway, if they are all the same height, its a bug. If they are not, then it would seem the XMLs for the other frames should be read but TheLacus knows more than I do.

There was also a bug with a female spellcaster I believe where she went really tiny for 1 frame but that has since been fixed I believe. This might be similar to that

[Ralzar]

There was also a bug with a female spellcaster I believe where she went really tiny for 1 frame but that has since been fixed I believe. This might be similar to that

Yeah, I reported that bug and this looked pretty much identical to that.

[Ralzar]

Tested a bit now. Could not reproduce the bug so will chalk this down to user error on my part.

I'll test a bit more to be sure, but I assume I managed to delete an xml file I should not have.