i am unsure if a thread has been made about this before, but regardless this is something i've been thinking about for a few weeks now and have been meaning to just get out of my system either way.

are mpt hacks allowed in the S3XMODIT format ? and, if otherwise not considered so far, should they be ?

i'm aware that DirectX effects, which is one of many MPT hacks, is considered illegal to the format, as it is something that many players/trackers do not support outside of MPT, but with regards to other hacks, some modern players do support them as features [i've been told, at least, i haven't gotten a chance to test them yet.]

while i personally am somewhat against allowing most MPT hacks, i also don't really mind that they are allowed so long as it is easily understood by all BotBrs what is and isn't allowed within the format.

i'm also aware that this thread is probably at least a little useless, since i figure the idea of the Lyceum author was to specifically distinguish what isn't allowed rather than what is, but i still think a simple sentence such as "Other MPT hacks, such as artist name or invalid pattern sizes, are allowed" would go a long way in making certain everyone is on the same page regarding this.

i want to reiterate i'm not interested in arguing the merits of one side over the other, rather i would just like to make sure everyone is clear on what is/isn't considered illegal in a submission format.

thank you,
-vivian aka dsm5

i'm largely against outlawing most mpt hacks because it can be a "gotcha" for people who don't know what is or isn't an mpt hack. even though you can ask openmpt to check for them, it's not tremendously helpful at doing so, and this seems like it'd punish newer users and create a lot of feel-bad situations. imagine if you're new to .it and scrolling through the effects list. how are you gonna know S9F, :xy, \xy are hacks? how are you gonna know the pattern size limitations? you can be a frequent .it user and still not know these things!

i understand the desire for clarification here, and it's worth talking about 100%, but i also think it's really difficult to define. we don't want these formats absolutely overflowing with un-classic features, either, presumably - so it's hard to just say "yes it is Officially allowed" because that might change the actual scope/trajectory of the usage of hacks versus how it might be if it's unspoken - unspokenness is an implicit form of discouragement i suppose.

i myself don't have the heart to police most hacks; they are usually accomplishing something that's already doable in some slightly more roundabout way. (you could argue against S9F in tinymod because a duplicate reversed sample would take up space, but i'd personally just rather see a creative use of an effect!)

however, it clearly makes sense to ban DirectX effects (which is already clarified on the lyceum). it also seems too cheaty to submit a compressed .itz/etc especially in tinymods, and i would vote to ban that too. but the effect commands? i do not care. compatibility flags? maybe within reason; but i probably don't care either. in both of those cases, you're simply committing to the possibility that the voter (in an xhb) might not hear things exactly as you wrote them. that's your own risk to take!

afaik all mpt hacks (other than opl and plugins) are permissible in s3xmodit, because some people would just use openmpt or any players that "tolerate mpt hacks"

as you may not know, I have been using mpt hacks since :>
from 4 channels+ .mod; Zxx usage in s3m and xm; s9f in it and s3m and artist name, and it's safe

also, I'm only sensitive to people using less than 32 rows and 200+ rows in .it, but that doesn't really crucial, imho.

so yeah, if you want to use mpt hacks, then go ahead

I've seen MPT hacks in my long history of being in various compos... and this is coming from someone who's participated in about 17-18 years worth of those now! Needless to say, compatibility varies, but OpenMPT is a platform incompatibility case, and on Schism Tracker's end I am aware of a filter revision at some point in its development. Nevertheless, I do keep up to date on Schism Tracker for these cases, mostly so that I can still guarantee some playback consistency.

personally, i feel like mpt hacks just allow for more creative/unique tracking, and disallowing them is bound to be unfun for everyone involved due to how popular openmpt is and how minor most* mpt hacks are

* keep in mind i'm still aware that stuff like directx/vst plugins are not allowed. those are a big hack, and should not be allowed for obvious reasons

also, i feel like anyone who uses mpt hacks would really appreciate them being allowed just because they're so damn convenient! i wouldn't want to expand/collapse my patterns just because they go outside of the "allowed" (will touch on this later) range, as it's simply just an inelegant solution. it makes my patterns look weird

and speaking of pattern lengths..

@Collidy i don't really understand the sensitivity to patterns outside of 32-200 rows, since disallowing that would essentially forbid the essence of some entries (example where short patterns initialize notes or change how the main bigger pattern ends up playing - i feel it would lose some sort of charm if it just used break commands) - it might not be something you use, but others might really benefit from it, so calling it out is a bit iffy imo

i'll finish off with something not everyone might agree with but considering that it's no mystery that openmpt is the most popular tracker for the dos module formats and the fact that it plays back any module made in other trackers just fine, i feel like anyone using a different tracker or player to listen to entries is essentially signing up to hearing some of them being played back incorrectly. that's actually why i always render my own entries - i don't want someone else rendering them in a different tracker/player where it might sound different to what i intended people to hear

(note on "allowed": the 32-200 row restriction to me seems to only exist due to possible tracker programming complications with lower or higher row counts, an issue that simply doesn't exist today, and as such i view it only as a guideline that can be disregarded by anyone as many times as they please)

Well since we're talking about the s3xmodit format and not the openmpt format, I think it's always better not to rely on hacks, at least to ensure compatibility with MS DOS.

That being said, I agree with damifortune's post. Since hacks are usually used to perform tasks you could do relatively easily without hacks , I consider this as a minor mistake and it don't change my vote on entries

Yes for me the existence of an openMPT format kind of moots the whole question. Although it's true that it's rare. Maybe some people with the badge could make a little push for more MPT battlez/.

doesnt bother me (enough). there is so much you can do that its trivial to allow a hack if there would have otherwise been another way to do it within the spec anyway

It does bother me, personally, but I am a minority in this situation. I strive not to include them in the modules I make, but early modules of mine definitely have them to varying degrees, before I knew what MPT hacks were. Most of the breaking changes (more than 16 samples in an instrument in .xm, stereo samples in .xm, .s3m with FM and sample instruments on the same channel, more than 16 channels of .s3m being used to play samples, to name a few) warn you now when saving. I think sagamusix (the current maintainer of OpenMPT for the past 15-ish years) is very open to tweaks like this, I've been submitting bug reports for a while now and they nearly always get a response.

If you want to start caring, and need a legal method for reversing a sample, by the way, you can do so with a bidi loop and a sample offset command pointing to the end of the sample in the relevant formats. I do this now instead of using S9F for compatibility reasons.

However I do agree with everyone that many of these hacks are well-established and are probably not worth banning outright.

speaking as a rare endangered xm user, this is something that i think is an unfair advantage in some ways. certain older player software obviously cant emulate it properly, and the whole point of s3xmodit being that it is a DOS module is still very important.

if someone can show me mpt hacks working in vanilla impulsetracker, i’ll be sold, but until then im against it

iirc there are some IT hacks which are sort of just UI hacks, i.e. impulse tracker can play them back okay, but you wouldn't be able to make a module that does that using impulse tracker. but most of them are not like that

I just thought about something, it has been discussed on Discord but I found no mention of it on the lyceum. An option would be to add on the s3xmodit (and tinymod, amigamod) format page: "all entries made with OpenMPT must be saved using compatibility export".

I think this would fix the issue regarding involuntary usage of hacks. Then I guess at this point our options are:
- A) forcing compatibility export on entries made with OpenMPT (meaning it would now be impossible to use OpenMPT hacks on s3xmodit entries)
- B) nothing changes regarding the format rules, we fully accept usage of hacks on s3xmodit (and related) formats and we add mention of this on the lyceum
- C) nothing changes regarding the format rules, usage of hacks is tolerated (so people shouldn't downvote entries using it) but not recommended
- D) nothing changes regarding the format rules, the botb community is divided about hacks, maybe we will decide on a clear answer in the future. Meanwhile hacks are tolerated (so no downvoting here too!)

if you have to, just list every single hack possible, and what happens when you try to play it in the "canonical" player for that format (note there may be multiple players with different behavior like the impulse tracker SB/GUS/wav writer drivers)

compatibility export isn't really that much help here, it doesn't erase your S9F commands, it allows the perfectly-valid S3M OPL instruments...

since there are lots of minor things that either no one attempts to use or don't affect sound/playability you could ignore those, even if they are hacks or prevented by compatibility export.

"no plugins" is already 99% of the way there and i think every other relevant hack has already been brought up here, so just having some information about the tradeoff is more than enough for any hypothetical person who cares about this but is more interested in reading the BOTB lyceum than reading tracker docs or just doing their own tests

actually, the lyceum already says to always use compatibility export for IT/XM - although this doesn't describe the actual culture and practice of botb, so i don't think it carries much weight. maybe it was hard to find because folks expect it to be on the format pages instead of the tracker page?

I'm going to rename this thread with a more descriptive title so people (me) can find it later when they search for it.

previous title was "question regarding the s3xmodit format"

@Jangler: my mistake, I only looked at the s3xmodit (format) page indeed!

However seeing how this is phrased on the MODPlug Tracker page, I think it's also possible to see the "IT/XM compatibility notes" and "MOD compatibility notes" sections as recommendations to ensure full compatibility with these formats but not actual rules for the s3xmodit botb format. I guess the fact you can save your modules with no error by using Ctrl+S probably adds to the confusion (especially if you've never heard about OpenMPT hacks).

I imagine this plus the fact that a lot of people probably don't read the MODPlug Tracker page (because they experiment or read the official doc, as said coda) explains why so few people use compatibility export when submitting their entry.