StepMania beta 4a is annoying

It's fine, I got Simply Love. Even though it's a little gay.

Lolz.

Glad to spread the love~

Hopefully this isn't considered thread hijacking, but considering how slow this board section seems to be, this is still on the front page and I'm not even sure where the forum rules are (if there is any) I figure this is the best place to start.

I understand where Kyzentun is coming from on trying to get themers to do a better job scripting things. After all, the themers absolutely expect a stable, predictable scripting environment. So why shouldn't the developers expect the same courtesy of the themers? I've also seen the long epic about the history of theme development and it sort of reminds me of games with similar issues (Garry's Mod and its Steam workshop probably play host to some of the most terribly cobbled together junk I've ever seen, even if the various addons there work the majority of the time). However, I don't feel like this is the correct way to handle crappy coding issues.

First off, you shouldn't be punishing your end users because they picked a theme they like and it happens to have a handful of scripting errors here or there. That isn't their fault and you shouldn't expect them to fix the errors on their own, because they are end users. The waiei theme I used to enjoy has one error that occurs on button click events (so it seems anyway) which from my perspective had absolutely no effect on the theme's visual appearance, functionality, or anything else in particular. If it were, it would be prudent to send users their way to complain about fixing it. If the theme were unstable enough, then I doubt anyone would use it very long at all, including myself. There is plenty of crappy themes out there but often enough there are people who still choose to use them because they are more comfortable for them to use. To the end user, dumping errors on screen is just creating an issue where to them there was never one at all. If you have a bone to pick with themers over bad development practices, this is, in my opinion, absolutely the worst way to go about it. Upsetting your user base for the sake of it is bad practice in itself.

Would you be happy if your Linux distro dumped seemingly benign syslog errors on your desktop just because one of many thousands of developers involved made a minor mistake? I sure wouldn't.

Maybe I should bring this suggestion to github, but to me the proper solution would be to make this kind of behavior toggle on for new themes. Pardon my ignorance as I'm not a theme developer, but perhaps implementing a version tag that developers can specify which version(s) of stepmania the themes officially support would be an appropriate way to do that. So, for example, if a theme states it supports SM5 beta 4a and up, and there are errors, dump these messages to screen. Force themers to use best practices from now on. Make the tag optional so older content will continue to function as it used to. But then in this way for themes that don't apply the tag you can warn the end user both on the forums when issues come up and maybe even ingame (on load) that the theme is not supported and you can't guarantee proper behavior. To me this seems like the proper solution as you are then focusing on improving new content and you don't even have to approach the topic of dealing with legacy content anymore. Otherwise users are just going to circumvent the issue by downgrading and staying on older versions of Stepmania if it means they can keep using their old, seemingly buggy themes that to them did not seem to have issues before.

If this seems like a ranty post, I'm just going to say that I agree with the intent of the change and agree that something should be done. But I'd hope the developers reconsider this stance and take on a different approach. If I were privvy with C/C++ I'd probably contribute a proper implementation for the above concept but I don't have the luxury of time to learn, and I doubt the dozens if not hundreds of themers lost in the last decade will come around to make the changes you expect of them.

Thank you.

The primary problem with providing a way to turn it off is that everybody will turn it off, new themers won't know it exists, and themes will never improve in quality. Providing an off switch is as good as removing it entirely.

PS: Waiei stuck in a version check screen to disable it on newer versions.

I think you missed part of what I was getting at. I said add a warning ingame. Something so blatant that the themers can't ignore it but it won't necessarily hurt user experience (ya know, until their game crashes because the theme is junk). But more to this point:

Themers won't know it exists

It seems like that's something that wouldn't be a big deal if documentation were improved. I mean if you're going to make improvements to the theme engine at all and you want to improve consistency, you can't just let ignorance go but then also expect those same ignorant individuals to make improvements anyway. You could even generate a warning for something like this in lieu of an ingame warning of sorts that says "maybe you should specify version=xyz?" for non-conforming themes.

PS: Waiei stuck in a version check screen to disable it on newer versions.

Mhm, I had to downgrade to beta 3 to use it. Since it looks like they just have a null reference somewhere it might be an easy fix, but I really can't know for sure.

In any case I'm glad to see stepmania is still seeing improvements. I've been playing it for years off and on and that probably won't change. But this approach to getting theme quality to improve just seems too broad to me.

The biggest reason I haven't written more documentation to expand the Docs/Themerdocs/Examples folder is that nobody has come forward with a review of any of it. If nobody is going to point out the confusing parts in what I've written, I don't know if I'm getting through or not. I've even posted links to the documentation and explicitly asked people to point out confusing parts in threads on ZIV where people asked for theme help, and no response.


waiei's version check just relies on Branch.AfterTitleMenu going to ScreenCaution on the newer versions. Circumvent that, and you can get to Select Music.

So let's see what kinds of errors they have (keep in mind that every one of these means that the theme code was interrupted in the middle of whatever it was doing. If it was doing something important, that important thing is unfinished or not done):
00:16.930: WARNING: Error playing command:/Themes/waiei/Graphics/ScreenSelectMusic BannerFrame/default.lua:72: attempt to call method 'setanimate' (a nil value)
Calling a function that doesn't exist. This probably got renamed to "animate".

00:16.936: WARNING: Error playing command:/Themes/waiei/BGAnimations/ScreenSelectMusic decorations/default.lua:118: calling 'y' on bad self (number expected, got nil)
Passing nil as a coordinate for a position.
Actual line: InitCommand=cmd(x,THEME:GetMetric("ScreenSelectMusic","BannerFrameX");y,THEME:GetMetric("ScreenSelectMusic","BannerFrameY"));
From waiei's metrics.ini: BannerFrameY=
Come on guys, if you're going to use the value of a metric, you should probably set it to something.

00:17.037: WARNING: Error playing command:/Themes/waiei/Graphics/MusicWheelItem Song NormalPart.lua:185: attempt to index local 'params' (a nil value)
Code:

		InitCommand=cmd(playcommand,"Set");

		SetMessageCommand=function(self,params)

			--self:Load( THEME:GetPathG("_MusicWheel","BannerFrame color"));

			if col~="" then

				self:diffuse(col_t[1],col_t[2],col_t[3],col_t[4]);

			else

				if params.HasFocus then

					self:diffuse(col_t[1],col_t[2],col_t[3],col_t[4]);

				else

					self:diffuse(Color("White"));

				end;

			end;

		end;

For those that don't know lua, they've created SetMessageCommand in their actor, and made it rely on having a parameter table passed when it runs. Then when THEY choose to run it in their InitCommand, they don't pass any parameter table.
MusicWheelItems actually need a Set command for the music wheel to set them, the mistake here is not providing the parameters when calling it from InitCommand.

00:17.147: WARNING: Error playing command:/Themes/waiei/Graphics/MusicWheelItem Song NormalPart.lua:100: attempt to index local 'song' (a nil value)
This is also in a MusicWheelItem SetCommand. MusicWheelItems load up the actors for every type of item, not just the particular type they happen to display at one moment. So checking whether the parameters like the Song or Course are nil is necessary. (this is really the big one, there are multiple Song and Course nil errors reported for every item on the music wheel)

00:17.204: Dialog: "Error playing command:/Themes/waiei/BGAnimations/ScreenSelectMusic decorations/scorelist.lua:44: attempt to index upvalue 'EXF_Metertype' (a nil value)
The "in" transition layer is part of the screen, so it's loaded at the same time as the rest of the screen. All lua code at global scope in a screen's lua files runs before any InitCommand. waiei has the code to set EXF_Metertype inside the InitCommand for their "in" transition layer, but scorelist.lua sets a local variable that depends on the InitCommand having run first. Since the InitCommand doesn't run first, scorelist's EXF_Metertype variable ends up nil, completely breaking whatever advanced feature they were trying to use it for, even if an error weren't visibly displayed.

00:17.209: WARNING: Error playing command:/Themes/waiei/Graphics/ScreenSelectMusic GrooveRadarP2/default.lua:71: attempt to index a nil value
The current song is changed before the current steps are changed, so when responding to the song being changed, the steps might be nil.
Side note: I'm playing as Player 2 alone, and some of these errors are for Player 1's groove radar. Players that aren't joined also have no steps set.
This is probably the second biggest one, lots of things checking the current song/steps without realizing they're sometimes nil.

I think that's actually all the types of errors encountered before trying to pick a song. None of these are hard to fix, they should all be a trivial (<5 minutes each) problem for a competent themer. Waiei is still actively working on their theme, so I don't understand why they prefer to disable it entirely on newer versions rather than spend a few minutes fixing mistakes.

Well to be honest with you, that's not the first place I would have looked for the documentation. I probably would start here on the website. However, looking in the docs directory I don't think the lua examples themselves would even be my starting point. No, I'd say this guide would be it. While it seems like it covers the various components of a theme individually quite well, I think part of the problem with it is it isn't so much of a guide as it is a reference. It also seems to make assumptions the themer is going to know what some things are (such as, what constitutes a 'Screen'). If I were to write something like that out and call it a guide, I think I would introduce the various pieces serially so someone reading it could see how all the pieces fit together easily. The examples would probably be easier to follow if there were also a good API reference to follow, although I assume it might even be possible to deduce that from the SM source code...somewhere.

The other files under docs seem similar in the detailed but non-inclusive way the guide is. So if there was anyone who would have been willing to give you input, perhaps they just didn't know where to start.

Per the waiei theme errors I agree they don't seem that serious for them to fix. But again, simply using the theme I didn't encounter any noticeable interruptions and if I had I'd be asking about that instead, and you would still be telling me its their fault (rightfully so). From a user perspective, it wasn't visibly broken until the error spam started happening on screen. For an SM5 theme it should probably be fixed, but for older stuff or less than competent themers I still think it could be handled differently without encouraging laziness as it is now.

I started writing a new version of the themeguide once, and ran out of steam in roughly the same place, so I didn't commit the new version.

The API reference is in Docs/Luadoc/Lua.xml. Open that in something besides Chrome and it shows all the lua functions for every class.