Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002090Zandronum[All Projects] Bugpublic2015-02-03 00:002018-09-30 23:01
ReporterRusselCS 
Assigned ToTorr Samaho 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version2.0-beta 
Target Version2.0Fixed in Version2.0 
Summary0002090: Oddities with SKININFO and larger scaled player classes.
DescriptionThere's a lot of details to this one, so I'll get right to it.

First off, Zandronum 2.0's handling of SKININFO isn't the same as that in Zandronum 1.3's. Skins that previously worked fine in 1.3 are now scaled down in 2.0, printing an error to the launch console that the skin is too big.

This sounds alright at first, I mean I know you guys are creating more "proper" skin sizes, but what if people have intentionally low-res sprites to work with, and thus have to bring up the scale to put them on par with the world around them? This, of course, causes a lot of skins for Megaman 8-Bit Deathmatch to get scaled down when they previously were not.

In addition to this, skins created using S_SKIN and any existence of SKININFO lumps after the first one ignore this behavior completely, making it seem like more of either some workaround for a previous issue or a bug that shouldn't be there to begin with.

I've included some test wads in the attached zip that contain a player class scaled to 2.5 along with two skins for said class. One skin, designed as a legitimate work to go with Megaman 8-Bit Deathmatch, and the other, a joke skin that technically should be resized or not downloaded at all.
Steps To ReproduceThese steps will produce different effects in Zandronum 1.3 for Windows and Zandronum 2.0 alpha r150118-1152:

1) Load ClassScaleTest.pk3 followed by SkinScaleTest.pk3 offline.
2) If running with the 2.0 alpha:
 -- Should produce two console errors talking about skin downsizing.
 -- If the error message mentions the frame M10W, then the Rosalina skin
 -- will not show up and the castle skin will be tiny.
3) Swap the SkinScaleTest.pk3 file for SkinScaleTest_nobug.pk3 and run again.
4) The following should happen regardless of version:
 -- There will be no error and no scaling. Rosalina will be scaled properly
 -- and the castle skin will be too huge to see.
Additional InformationI've determined why skins are rerendered in size like this, but a class' base scale should at least be taken into account when resizing sprites if this feature isn't removed entirely for the sake of compatibility.

Thank you for listening.
Attached Fileszip file icon ClassScaleTest.zip [^] (153,031 bytes) 2015-02-03 00:00

- Relationships

-  Notes
User avatar (0011597)
RusselCS (reporter)
2015-02-03 00:43

Edward-San told me to point this out because it's relevant.

<LegoCS> p sure some of the functionality is intended though because of a exploit where you can make a skin from another mod wayyy larger than it should be if you wanted to.
<LegoCS> Like the joke skin I have in that test set can be renamed to replace a skin of...say...Strife Guy.
User avatar (0011626)
Torr Samaho (administrator)
2015-02-08 12:13

There was a bug in the SKININFO parser that led to different problems in 1.3 and 2.0. Please test if this fixes the issue.
User avatar (0011634)
RusselCS (reporter)
2015-02-08 19:46
edited on: 2015-02-08 19:47

Hrmm...
This fixes the actual bug I presented in the post where it will allow all of the skins to scale properly and independent of one another, but it doesn't fix the reason I made the ticket in the first place.

Since that version doesn't fix the issue this ticket was intended for, would it be possible for an actor flag to be put in place to allow a playerclass to bypass the skin parser's check? Given that this change causes a good number of skins to get scaled down in ways the creators never intended, it causes issues with a good number of mods, including and especially Megaman 8-Bit Deathmatch.
This flag would both allow mods a workaround for skins they want to be large and prevent people from exploiting the skin replacement ability I mentioned in the previous note in other mods.
Alternatively a max height/radius scale to which skins can go without being downsized as that would be more flexible.

If this is too big of a suggestion to just be in a note, does it warrant its own ticket?

User avatar (0011635)
Torr Samaho (administrator)
2015-02-08 20:10

I think the main point of this ticket where the differences in 1.3 and 2.0. If the underlying bug is fixed now, but you still think that the behavior of the size check should be adjusted, please open a new suggestion ticket (not a bug, since from what I can tell the size checking code works as intended). There we can discuss this in detail.
User avatar (0011636)
RusselCS (reporter)
2015-02-08 20:20

Alright, I'll create a new ticket. This can be closed, then. Thanks a bunch.
User avatar (0011637)
Torr Samaho (administrator)
2015-02-08 20:33

Ok. I pushed the fix to 1.4 and 2.0. Once it's confirmed to work, we can close this.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2015-02-03 00:00 RusselCS New Issue
2015-02-03 00:00 RusselCS File Added: ClassScaleTest.zip
2015-02-03 00:08 Dusk Target Version => 2.0
2015-02-03 00:43 RusselCS Note Added: 0011597
2015-02-08 11:10 Torr Samaho Assigned To => Torr Samaho
2015-02-08 11:10 Torr Samaho Status new => assigned
2015-02-08 12:13 Torr Samaho Note Added: 0011626
2015-02-08 12:14 Torr Samaho Status assigned => needs testing
2015-02-08 19:46 RusselCS Note Added: 0011634
2015-02-08 19:47 RusselCS Note Edited: 0011634 View Revisions
2015-02-08 20:10 Torr Samaho Note Added: 0011635
2015-02-08 20:20 RusselCS Note Added: 0011636
2015-02-08 20:33 Torr Samaho Note Added: 0011637
2015-03-29 20:20 Dusk Status needs testing => resolved
2015-03-29 20:20 Dusk Fixed in Version => 2.0
2015-03-29 20:20 Dusk Resolution open => fixed
2018-09-30 23:01 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker