discussion lose backwards compatibility after 1.8 stable release

Post ideas & suggestions you have pertaining to the game here.
Post Reply
relanat
Militia Captain
Militia Captain
Posts: 601
Joined: Tue Nov 05, 2013 9:56 am

Thu Apr 19, 2018 1:30 am

I've been waiting for the stable release of 1.8 to update a lot of my mods. Most still work but use older code for things like playership screens, dockscreen code, etc.

Would it be a good idea to remove the backwards compatibility code for older game versions in new game versions after 1.8? I'm not talking about 1.8a versions but things that were used in 0.99, 1.2, 1.5, etc. Or maybe 1.6 or 1.7. Where would be a good break point?
An example is stars and planets in GalaxyCompatibility.xml. They are all obsolete="37". The last time I saw &stA-TypeStar; used was in The Network Repaired mod. And that mod doesn't work in current game versions and these type of stars don't show properly either.
The itemPicker Ship Configuration code and images could be removed.
On the hardcoded side of things (of which I am pretty much completely ignorant) deprecated functions could be deleted.
Things like that.

One upside would be a decrease in size and loading time. Part 2 takes quite a while to load. Any streamlining would be a good thing.
The game would be much simpler and smaller in size too if old code, unused images, compatibility files, etc were removed.
There isn't really a loss of anything here. Everything that is done in the older versions can still happen but wouldn't be duplicated, sometimes many times over.

1.8 will also be a very significant upgrade from 1.7. There are many changes included since the last stable version, internally it almost seems like a new game, so possibly this is an opportune time to consider this.

The major downside is all the work it would take to do this. There would need to be a significant gain to make it worthwhile.

Another downside is a lot of existing mods may not work. There would be a lot of updating needed. But a lot of them don't work now (a lot do still work) and, once again, no capability is lost, just changed to newer code.
Modders would need to add older images back into the game to use them. There could be an optional resource library maybe, which contained these older images. Either to be included in the game by the modder or images copied from it. Possibly the multiverse mod section won't have a 5MB limit like xelerus. And this would also seem an opportune time to upgrade mods while changing over to the multiverse.
Or an optional code library. Modders could add the old code into their mods. Same result but shifting the load from the game to the mod.

Also a lot of the newer code is more complex and difficult to understand than previous code. This presents a significant challenge to new modders. But documentation is also progressing very well. It has IMO reached a higher level than ever before.

Any thoughts on what could happen and why this would be a good or bad thing to do?. Anything else that needs to be considered?

PM
Fleet Admiral
Fleet Admiral
Posts: 2342
Joined: Wed Sep 01, 2010 12:54 am

Fri Apr 20, 2018 8:02 pm

I would not mind losing backwards compatibility, especially for old unused 20-facings ships and numerous other sprites.

It would be nice if all ships used procedurally-generated HUG images (with bump maps to give them texture, such as a brick pattern for armor and hexagons for shields). It is weird that earlier ships have custom HUDs, but the new playerships for 1.8 do not. Also, procedural orbs or auras for Sustain/Defend.

As for my mods, I am slowly updating those I plan to keep to 1.8, and remove the rest from Xelerus. (Playership Drones and Star Castle Arcade will probably take the most work, but I plan to get it done eventually.) I probably will not be too eager to think of new mods to create then maintain.
Download and Play in 1.8 Beta...
Drake Technologies (Alpha): More hardware for combat in parts 1 and 2!
Godmode v3 (WIP): Dev/cheat tool compatible with D&O parts 1 or 2.
Download and Play in 1.7...
Star Castle Arcade: Relive classic arcade gaming in a new Transcendence adventure!
Playership Drones v8: Under construction!

User avatar
AssumedPseudonym
Fleet Officer
Fleet Officer
Posts: 1036
Joined: Thu Aug 29, 2013 5:18 am
Location: On the other side of the screen.

Fri Apr 20, 2018 8:35 pm

 George tries to maintain backward compatibility, but — and let’s all be honest — he doesn’t do a good job of it. Every version update, occasionally even between alphas or betas, tends to break something from either the most recent release or some earlier one. While this occasionally applies to vanilla, it’s especially noticeable with mods. Just ask PM how much fixing he has to do to PSD every time George updates, and even I’ve been caught by having a few things break in my mods despite having tried to futureproof.

 As a disclaimer and proverbial grain of salt, I’ll be the first to admit that I’m notorious for not maintaining even a remote semblance of backward compatibility when I update any of my material.

 Given that we already don’t really have it despite George’s efforts, I’m heartily in favor of scrapping backward compatibility. It’s a polite fiction at best right now, anyway. Besides, I’d much rather see George focus on going forward than to try to accommodate outdated and abandoned material, be it his own or anyone else’s.
Image

My mods on Xelerus: Click here!

Of all the things I’ve lost in life, I miss my mind the least. (I’m having a lot more fun without it!)

relanat
Militia Captain
Militia Captain
Posts: 601
Joined: Tue Nov 05, 2013 9:56 am

Thu May 03, 2018 1:29 am

George tries to maintain backward compatibility, but — and let’s all be honest — he doesn’t do a good job of it.
I'll admit I don't know much about game writing/developing/whatever its called, but I'm of the opposite opinion.

I'm quite impressed by how much content still works in older game versions/mods. That's one of the reasons I started this topic. Possibly there is too much effort devoted to backwards compatibility.
When updating the Network Repaired mod all that really needed doing was changing the Adventure code in the initial file. There were a few other things that did need changing to get it to run but not many.
Most of the work was updating code that was still working. eg stargate code to use TopologyCreator code which, with hindsight, I shouldn't have done because it massively increased loading time, system code to have them look like current systems and dockscreen code to the new id format. None of this was critical to having the mod run.
Similarly you can load station mods from many years ago and they can still work. Same with ships.

1.8b1 has quite a few of the compatibility types as "obsolete=xx" which is a step in the right direction. This pushes modders to update to newer code without requiring a massive rewrite.

And bear in mind that changes to the game are made to improve it and often make it easier for modders. unvSetObjectKnown is one example. The new DeviceSlot code is another. unvFindObject A and K criteria make things much easier for me rather than having OnGlobalPlayerEnteredSystem code for every system, etc.

And a lot of the mods push the engine to its limits. Modders are doing things which were never contemplated when the game was written or upgraded. So its not surprising that things get broken out there on the edge.

Post Reply