MantisBT - Zandronum
View Issue Details
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.
TagsNo tags attached.
Relationships
Attached Fileszip ClassScaleTest.zip (153,031) 2015-02-03 00:00
/tracker/file_download.php?file_id=1404&type=bug
Issue History
Date ModifiedUsernameFieldChange
2015-02-03 00:00RusselCSNew Issue
2015-02-03 00:00RusselCSFile Added: ClassScaleTest.zip
2015-02-03 00:08DuskTarget Version => 2.0
2015-02-03 00:43RusselCSNote Added: 0011597
2015-02-08 11:10Torr SamahoAssigned To => Torr Samaho
2015-02-08 11:10Torr SamahoStatusnew => assigned
2015-02-08 12:13Torr SamahoNote Added: 0011626
2015-02-08 12:14Torr SamahoStatusassigned => needs testing
2015-02-08 19:46RusselCSNote Added: 0011634
2015-02-08 19:47RusselCSNote Edited: 0011634bug_revision_view_page.php?bugnote_id=11634#r6601
2015-02-08 20:10Torr SamahoNote Added: 0011635
2015-02-08 20:20RusselCSNote Added: 0011636
2015-02-08 20:33Torr SamahoNote Added: 0011637
2015-03-29 20:20DuskStatusneeds testing => resolved
2015-03-29 20:20DuskFixed in Version => 2.0
2015-03-29 20:20DuskResolutionopen => fixed
2018-09-30 23:01Blzut3Statusresolved => closed

Notes
(0011597)
RusselCS   
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.
(0011626)
Torr Samaho   
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.
(0011634)
RusselCS   
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?
(0011635)
Torr Samaho   
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.
(0011636)
RusselCS   
2015-02-08 20:20   
Alright, I'll create a new ticket. This can be closed, then. Thanks a bunch.
(0011637)
Torr Samaho   
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.