Backwards compatibility functions, and harm reduction toward legacy content creators

Sort by date Sort by reaction score
clairebun

clairebun

Community Noise Maker
Sonic Team Junior
Some quick background: It's no secret that old content tends to become unplayable on the next major release that comes around, and I have some interest in seeing old levels made playable in the current engine, if only to make it easier to appreciate the past works of previous level artists in our current environment. As a community, we place strong value in the autonomy and creative rights of the original content creators, and to modify and republish an author's work without consent -- even if strictly for conservation/compatibility purposes -- is considered a breach of those rights unless the work is expressedly marked as common use.

I believe there may be an alternative solution which is more in line with our ethics, and this would be to create ingame level "translators", which read level data and automatically convert its properties to match the right format. This might be unfeasible to maintain at the hard code level as it would mean setting up translation tables for every type of SRB2 level format created in the past; however, with lua hooks, all of the heavy lifting could potentially be left up to the community, and this would have the benefit of improving backwards compatibility while also having the potential to sharply reduce the prevalence of bootleg ports.

What's changed between versions
  • Some level header information has become outdated. MusicSlot has been replaced with Music, and many skies and music track names have been internally restructured.
  • Thing type numbers have been reorganized. Additional flags have been added, and this descrepancy causes mapthing options and height values to be misread.
  • Sector and linedef specials have been reorganized.
  • Flats and textures have been reorganized.

How lua could resolve these discrepancies
  • Headers could be read as the level is loading, and use the presence of outdated header items such as "MusicSlot" to automatically identify if a level needs to be converted. Alternatively, a console command or lua function/variable can be used to define which levels need to be converted.
  • Header-defined skies and bgm entries can be modified on level load using lua-defined lookup tables.
  • Thing type numbers can be redefined on level load using lua-defined look-up tables. Flags and height values can be automatically adjusted to reflect discrepancies between 1.x and 2.x.

Current restrictions preventing this
  • The only hooks present for handling items on level load are MapLoad and MapThingSpawn. Both of these hooks are executed after mapthings have spawned their mobjs and linedef/sector specials have been activated.
  • There is no lua hook available for reading level header data prior to execution
  • Linedef specials are read-only variables in lua due to stability issues that would arise from editing them during level runtime.
  • Mapheader data is set to read-only, likely due to implications that would result from them being modified during runtime.

Potential solutions
  • Create a MapRead hook which runs after map data has been read, but before mapthings have had their objects spawned or their sector/linedef specials executed. This may also be a point where mapheader data can be allowed a writable state from within lua.
  • Conditionally allow linedef specials and mapheader data to be read+writable, but only from within the MapRead hook.

Other limitations
  • Certain outdated addons may contain assets (e.g. music, skies) that are placed in previous vanilla asset locations; unless explicit exceptions are made (perhaps via a console variable?) a translation script for these asset types will result in the intended custom assets being incorrectly translated.
  • Textures, flats, and sprites contained in the old file will still suffer from discolorations due to palette differences between current and previous SRB2 versions. I don't know of any solution that wouldn't involve somehow reading which graphical assets have been replaced by X file and flipping its colors using X algorithm mapped to X custom palette.

Potential Advantages
  • A level translator system with customizable lookup tables could allow a large number of levels (particularly OLDC map packs) to become accessible without tampering with the integrity of the original files.
  • This system could extend beyond the translation of SRB2 maps; for example, what would happen if a scripter created lookup tables designed to translate levels made for the original Doom?
  • While it's already possible to change some sector properties in lua, the creation of a MapRead hook and the ability to read+write header and linedef properties before level load has powerful implications on the extent to which innovative game mechanics would be possible through lua; for example, it would be easier to emulate Sonic CD's time travel system by modifying skies, linedef specials, and thing spawns without the help of any explicit scripting / execution instructions from the level itself.

I'm mostly curious if there are any technical limitations I might be overlooking here. But maybe this is also a good window to discuss creative rights as we've currently defined them; this idea mostly came into fruition due to some internal conversation I had with others on the team in regards to what can be done with the intellectual property of someone's wad file. If an external file renders an older addon playable without actually modifying the file itself, then it may work to the benefit of multiple parties.
 
I was actually thinking about this concept a while back, though with no actual coding experience, I can't say anything to help on that front.

Nonetheless, the idea of SRB2's addon library being able to sustain in-between versions is a very nice ideal to have, if it were ever to be reached. Something to consider on the author's rights side might be whether an author specifically wants their addon to be backwards-compatible, for whatever reasons they may have.
 
Reminds me of the Minecraft launcher. You could choose from previous versions of the game there too. Would be very convenient, if this ever came to fruition. Every version of SRB2, available in one place.
 
GrayAngel said:
Reminds me of the Minecraft launcher. You could choose from previous versions of the game there too. Would be very convenient, if this ever came to fruition. Every version of SRB2, available in one place.
Click to expand...

Just to let ya know, I have 1.09.4, 2.0 and 2.1.25 all in separate folders.

:)
 
It would be really great if we could play maps that were made as far back as being for the final demo versions of the game in the latest version through use of some sort of conversion tool. Aside from the historical relevance to such a tool, it would also be fantastic for nostalgia value, and would open up the outdated releases section to much more active relevance. It would also save a lot of time in regards to maps not needing to be manually ported as much. I can't really think of any negatives if it could be pulled off.
 
This is a really interesting solution to the problem. I'm not a Lua guy myself, so I can't do more than sit by on the sidelines for the technical specifics of this conversation.

Personally, I was hoping for some threshold like "If the changes to the work are JUST for compatibility's sake, then it doesn't count as transgressing the original creator's rights." If the above works, then we don't need to create that threshold.

(says the man who still hasn't ported his own content)
 
CobaltBW said:
Current restrictions preventing this
  • There is no lua hook available for reading level header data prior to execution
  • Linedef specials are read-only variables in lua due to stability issues that would arise from editing them during level runtime.
  • Mapheader data is set to read-only, likely due to implications that would result from them being modified during runtime.

Potential solutions
  • Create a MapRead hook which runs after map data has been read, but before mapthings have had their objects spawned or their sector/linedef specials executed. This may also be a point where mapheader data can be allowed a writable state from within lua.
  • Conditionally allow linedef specials and mapheader data to be read+writable, but only from within the MapRead hook.
Click to expand...

While I do agree that both linedef specials (when at level load, ideally) and level headers should be writable by Lua, the hook you're looking for already exists: MapChange runs when a level change command is sent to the game and provides the new map's number as a parameter, from which its header can be retrieved before it loads. Hopefully that should be enough to make most preparations for a translator?
 
From what I've been able to tell by perusing the source, MapChange seems to trigger too early for it to be effective here.

To explain what I mean, here is the exact point in p_setup when the game seems to go from reading map data to executing from level data:
Code: 
	if (!P_LoadMapFromFile())
		return false;

	// init anything that P_SpawnSlopes/P_LoadThings needs to know
	P_InitSpecials();

	P_SpawnSlopes(fromnetsave);

	P_SpawnMapThings(!fromnetsave);
	skyboxmo[0] = skyboxviewpnts[0];
	skyboxmo[1] = skyboxcenterpnts[0];

	for (numcoopstarts = 0; numcoopstarts < MAXPLAYERS; numcoopstarts++)
		if (!playerstarts[numcoopstarts])
			break;

	// set up world state
	P_SpawnSpecials(fromnetsave);

The LoadMap function of course being where all sector, linedef, thing etc. data is set up based on the map lumps it's reading from.

After that function is run:
  • Slopes are executed
  • Objects are spawned from the mapthings (and executing any checked mapthing flags)
  • Skybox viewpoints are defined
  • Sector and linedef specials are executed
There appears to be no hook before these events and after/during P_LoadMapFromFile() that can be used to change map data before it is executed. MapChange seems to happen too early to account for this.
 
Another thing to consider is that, beyond just levels, is that mods and level packs made for previous versions of SRB2 will commonly use SOC or LUA that is no longer compatible with the most recent version. How best would we work around this?

One also needs to consider how the sprite frames changed their letters for some inexplicable reason.

For file loading, ideally, the best method would be to have an "addold" console command, that converts lumps over when adding the file, as I don't know how else you could detect specific versions... except maybe version strings in the SOC format. Hmm.
 
As a solution to the lua/soc problem, don't change how the lua and socs work anymore, and the sprite names as well. That way, we won't have to make ports of 2.2 mods. I don't see why you can't do that.
 
CobaltBW said:
As a community, we place strong value in the autonomy and creative rights of the original content creators, and to modify and republish an author's work without consent (even if strictly for conservation/compatibility purposes) is considered a breach of those rights unless the work is explicitly marked as common use.
Click to expand...
To be honest we are not entitled to get older version's mod to work for the current version, if somebody wants to play an old mod/map pack so badly they'll just install and older version of SRB2 in a different folder.
 
To play a bit of devil's advocate here:


It's admirable to try to figure out the solution to "people want to play old mods" that doesn't enroach on the creator's right to control derivatives of their work, but that's only one problem with unauthorized ports. The other problem is that the game itself has fundamentally changed, and will continue to fundamentally change (especially now), and those old addons will never work the same regardless. People who created mods for 2.1 designed them to work with how SRB2 played in 2.1, and a bunch of minor changes to how the game physics work (among other things) will cause compatibility issues. Playing those mods in a different client (2.2 vs 2.1) without giving the author, or someone else with permission, the chance to update it for the ideal experience in the new mod can taint people's perceptions of the original mod itself, and by creating a "compatibility layer" over an unmodified addon you wouldn't even have the scapegoat of a half-assed porting job to place the blame on. Those compatibility issues are only going to get worse now that the next major version is apparently throwing out most of SRB2's current gameplay in favor of whatever hot new thing is being cooked up.


For the people arguing "preservation", there's already a perfect solution to preserving the ability to play old mods. Every notable version of SRB2 itself is still available for download from the main site, and if you dig around in files.srb2.org you can even find most of the different patch releases, at least for 2.1. If you really want to play old addons made for that version, you can still do that with the completely authentic original experience by just downloading it and setting it up in a separate folder.
 
fickleheart said:
there's already a perfect solution to preserving the ability to play old mods. Every notable version of SRB2 itself is still available for download from the main site, and if you dig around in files.srb2.org you can even find most of the different patch releases, at least for 2.1. If you really want to play old addons made for that version, you can still do that with the completely authentic original experience by just downloading it and setting it up in a separate folder.
Click to expand...

Agreed, I've been doing this all the time every time I ran out custom levels for the current release. there is one small issue with this solution though, older versions tend to be prone to crashing, lagging and some other issues over time with newer OS updates. usually just switching to OpenGL or Windowed Mode fixes most of them.
 
A good example of the Designed for X Version thing would be my Magmor level that was designed with 2.1's Platform lava in mind from the start. 2.2 only has solid lava (USE solid fof's for this) and liquid lava and as a result I had to make the transparent lava into fully liquid, and the opaque lava into solid just because platform lava doesn't exist anymore.

If backwards compatibility is going to be a thing, old versions of changed actions would need to be brought back
 
fickleheart said:
Those compatibility issues are only going to get worse now that the next major version is apparently throwing out most of SRB2's current gameplay in favor of whatever hot new thing is being cooked up
Click to expand...

I have a vain hope that the non-slope physics will be mostly untouched, and that oldschool flatland maps (no slopes) will be essentially unaffected.

fickleheart said:
If you really want to play old addons made for that version, you can still do that with the completely authentic original experience by just downloading it and setting it up in a separate folder.
Click to expand...
1.09.4 in software with the large faces in the HUD -- this is the game that I played as a 13-year-old. The new changes to OpenGL, 3D models, and skydomes bring the game up to something that feels somewhat modern to me.

I just don't want to spend much time playing the lower-fidelity older releases. This is simply a personal aesthetic preference; I'd rather play flatland SRB2 maps in v2.2's modern engine.
 
BlueZero4 said:
I just don't want to spend much time playing the lower-fidelity older releases. This is simply a personal aesthetic preference; I'd rather play flatland SRB2 maps in v2.2's modern engine.
Click to expand...
Not asking someone to make this or anything, but I had an idea floating around in my head about a series of source code modifications for old SRB2 versions called Nostalgia Edition, which are their respective old versions but with some modern improvements to make playing them on newer PCs possible.
 
BlueZero4 said:
1.09.4 in software with the large faces in the HUD -- this is the game that I played as a 13-year-old. The new changes to OpenGL, 3D models, and skydomes bring the game up to something that feels somewhat modern to me.

I just don't want to spend much time playing the lower-fidelity older releases. This is simply a personal aesthetic preference; I'd rather play flatland SRB2 maps in v2.2's modern engine.
Click to expand...

In my experience there's also a little bit of trouble even properly installing older versions of the game on newer operating systems.
 
A "plug in and play" level converter is a bit overambitious considering both the variety of different assets and resources used in maps as well as major changes between versions making there no guarantee proper equivalents even exist in the newer SRB2 by default. There was a Lumpmod conversion utility bundled with 2.0 that was aimed at easing the port process for creators by automatically converting certain aspects of their level from 1.09. I think there's value in something like that at least.
 
You must log in or register to reply here.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top