Remember, remember!
The fifteenth of September,
The commit we know a lot;
I know of no reason
Why four-one-two revision
Should ever be forgot!
HELLO WORLD!
As some of the
FOnline fans around here have already been aware, the
Rotators team started working on one of the older SDK versions, with aim to improve and stabilize it for long-running servers.
According to our own experience, and those of other developers, drastic engine changes - being often more than required and also great in terms of features - have been added too quickly in the past. This left long-running servers lagging behind, unable to adapt and update, and up to this day stuck in the middle of nowhere. In most cases, the line has been drawn at revision 412 and there's hardly a
FOnline server developer left for whom this version doesn't ring a bell.
This version is the starting point for our project, currently known as
FOClassic.
This is for the second time that
Rotators attempt to improve
FOnline by introducing their own changes.
For the record, the first attempt at this was our
FOnline: 2238 server, which was originally based on
FOnline: The Life After content.
It didn't end quite as planned, but it was still an achievement that paved the way for other developers, allowing them to create or improve their vision of the
Fallout universe - or at least a part of it.
Today, instead of forcing our own vision of that universe, we -
Rotators - want to continue helping the server developers by providing them with tools, rather than a product.
Comparing the current situation to the times when we were working on
FOnline: 2238, now we have much more freedom in regard to introducing engine changes. Our aim is to revive some old, dusty features and engine parts and also to eliminate certain problems and limitations that have been hindering the implementation of various new, fresh features on
FOnline servers out there.
Let's hope that our third attempt at revolutionizing the engine will be based on equal rights among all developers, allowing all of us to improve it as we see fit.
ROADMAP
2077 (complete)
The first release should contain all changes required to break compatibility with saved server state.
No features allowed -- while some groundbreaking changes are to be expected, the update is still supposed to be as close to r412 as possible, to make the transition for developers as smooth as it gets.
Note that under "features" we consider those things which were not required for the release. Some of the changes can be seen as improvements, but in most cases they had been added only for a smoother preparation process. Everything else is considered necessary for a first release and was (or will be) added easily without affecting scripts/extensions too much, i.e. without really affecting anything "outside" the core engine.
- V13
After the initial release, it's time to make things usable again.
It's been quite a few years since r412 has been released, and back then the usual server code was growing with workarounds, undocumented implementations, more or less dirty hacks and things we usually don't talk about at parties. The main goal of this milestone is to help cleaning up all that mess, either by injecting their code into the engine, or exposing the data which they require in order to work.
While the main goal of this stage is to help servers with migration to FOClassic, some features still might be occasionally added here and there, but nothing that might slow down the migration itself.
At the moment of writing this announcement we know only about one or two servers interested in the migration. We will try to track their progress, and if they don't lose interest in the meantime, we'll keep this stage running until they're fully migrated. If they will have decided to stick with FOnline, or their migration progress will have slowed down the whole FOClassic project, we will proceed with the development - although the changes will be indeed introduced slower than in the SDK, we don't want remain waiting at the same spot forever.
Let's hope there that in the end we will have at least one functional server, which will be able to help the others once this milestone is complete.
- V15
While the devs are busy with new shiny stuff, we have to clean some dust.
And there's a lot of it laying around. The client is still using libraries which were old already many, many years ago; ASCompiler likes to crash linker at least once a day; there are problems with compiling literally *anything* on recent versions of the Visual Studio, a large part of the code is continuously giving us a headache, and so on... Refreshing the development environment needs to be done no matter what - by e.g. migrating to a new VS, using modern version of libraries, replacing deprecated ones with better solutions, restructuring some questionable designs, and basically getting rid of (or fixing) anything that could make our lives easier.
This is a side-milestone: this means that it might be completed before previous ones, but it will certainly not be released before them.
Even if we cannot involve the FOnline community with resolving mentioned issues, most changes in this case will not affect the servers at all, and it would be pretty boring to explain them all in detail anyway. We still consider this milestone worth mentioning, because some of its problems could affect requested improvements and fixes in the future.
Obviously, the decision about migration from
FOnline to
FOClassic, and how that process should look like, is completely up to server developers, but we'd like to say a few words before you start. If you're an active player thinking about posting suggestion on your favorite server(s) forum, you should read this as well.
- There are no real features at the moment of writing this post.
You've read it correctly, there's nothing you can touch at the moment and say "Ooh! Shiny!"
This probably will sound weird completely wrong to some of you, and you might also ask "why advertise this whole thing, when there's nothing to advertise yet?" The answer is simple - at this point, we value clarity over publicity. Being (now ex) server developers, we know how important this can be.
- There could be some introduced problems along the way which normally don't exist in r412.
For example, this can occur due to some internal changes, which we'll continue to introduce in order to bend various engine parts to our liking. This, as we already know, leads sometimes to more or less serious mistakes, and we still have to learn a lot about the engine itself. Some of the engine parts are already known to us from the days long gone. Some of them are new, changed or introduced by us in the past weeks. And then there are those engine parts which can quite surprise us once we discover them, because they were completely unknown to us.
Please bear with us - it's over 100k lines of code (not counting third party libraries), so this may take a bit of time.
- Only Windows binaries are released at the moment.
And that, sadly, includes the client and the mapper. This represents a potential problem for the servers which previously were distributing Linux binaries and would like to continue to do so.
MIGRATION CHECKLIST
Here's a quick list of things which should be done for a (hopefully) flawless migration.
- Upgrade/downgrade your server to SDK r412
That's either the easiest or the hardest step.
Chances are, your server is already using r412, because this revision became the most popular one among the developers. If not, following FOnline changelog should help - alternatively fellow developers from other servers could jump in and help.
- Remove StlPort from includes directories
You might success with using StlPort still in extensions, but there's no way of saying how this is going to affect the overall stability and performance. It might drastically slow down the whole application, crash a well-tested code, or throw errors in places that make no sense.
- Adjust your extensions code
Depends on complexity of your extensions, code doing exactly the same thing could look completely different written "under StlPort", compared to "clean" C++; all differences need to be checked and corrected.
- Remove/disable all features using memory addresses
Everyone who wrote such a feature should be perfectly aware that they will no longer work, but let's remind them once again, just in case.
As for objects structure, it's exactly the same (at least for now) in both public and non-public part. If your code is extending base classes, it's most likely ready to go.
- Fully rebuild ALL extensions
Leave no .obj behind, all of them have to be recompiled. Be aware that we tested everything in Visual Studio 10 (2010) only and that this version of VS is the only one recommended for building extensions.
- Delete all server state files
This includes characters (.client, .client_deleted), maps cache (.fomapb), scripts bytecode (.fosb) and finally - worldsave (.fo). In some cases, files are checked if they have been created by SDK r412 (or earlier) and actively ignored - which might or might not result in server refusing to start. In other cases, files are recreated from scratch.
- Pray to Rat God
Inevitable necessity. We take no responsibility for any damage caused by ignoring this step. You've been warned.
- Start server, connect, walk in circles
First thing you'll notice is a little more verbose initialization sequence - this is a temporary change and shall be either optional or disabled for future releases. That's to ensure you'll always know which one script/location/dialog is causing problems, if there are any such.
"OK, done. Now what?"
First of all, we'd like to see servers extensions cleaned up. Any changes made to FOnline.h should be either ported to
FOclassic.h or added to scripts.
In most cases extensions are needed only to extract/modify raw values from non-public part of a given object. While the implementation itself is often located within extension, it could be as well done in scripts, if they had access to it - and not all servers are aware of the possibilities provided by
asIScriptEngine.
We'll try to sort it out, following the philosophy that if there is a single one server that needs it, the others might benefit from it as well.
Which means that we're going ask servers for their extensions code - either fully or parts required. If you decide to send it to
FOClassic team, be completely aware we might archive it in public repository, making it available for anyone.
This rule exists for a few reasons:
- If you share your extensions completely, but decide that only a part of it needs attention at the given moment, we may come back for the other parts later
- Servers sticking to FOnline r412 could benefit from your code
- We have already been limited by the closed engine development - this means that the closed code made by servers would make the situation even worse
During migration process we're not planning to change objects structure. If server-specific feature requires member(s) "hidden" deep inside non-public part of an object (
CritterCl::strTextOnHead,
Item::Alpha, etc.), we'd rather make a proper script function, than do it in an extensions header. Once the migration is complete, the code can be re-added to
FOClassic.h, if there's still need for that.
LINKS
- https://rotators.fodev.net/foclassic/
Official homepage - place for easy access to documentation, changelog, links to related tools and resources. All those things will be slowly added as the project grows, and - with time - should become a single stop for developers, modders, and maybe even more curious players.
- https://github.com/rotators/foclassic/
If the previous link was the face of the project, this one is its heart.
It's a single most important place, around which everything revolves. Currently there is not much to see in the repository (only some documentation) - it's issues tracker where it's at. This is where all feature requests and bug reports must be placed before they can be even considered. With ST_SPEECH high enough you can try and convince someone to start working on something without creating proper suggestion/report first, but in most cases you'll be sent there even if your wet dream change is dead simple to add.
That way, people who can't or simply don't want to use other ways of communication, are still able to track progress without being left out.
- https://github.com/rotators/foclassic/releases
FOClassic is going to be distributed as single .zip package, containing binaries and core files used by extensions, scripts, and FOClassic applications.
Any optional tools, extensions, scripts, and other goodies (which do not require to be updated together with engine) will become a part of public repository.
- https://discord.gg/MuhRYZF
As most (if not all) servers switched to Discord in past years, we set a small guild for a relaxed talk about the project - but not restricted only to that.
We imagine this place as a continuation of the well-known #fodev channel on ForestNet and maybe some less known server-specific channels, like #modding (Reloaded) or #fodev-classroom (Ashes of Phoenix) on Discord.
- https://rotators.fodev.net/foclassic.tmp/
Here we plan to keep temporary files of all kinds. Starting from verbose servers/clients modified to hunt bugs, experimental/pre-release builds, random screens with WIP features, code snippets, IRC/Discord logs or crash dumps, and so on, and so on... I.e. everything that could be useful at some point in time and easier for us to upload to FOdev instead of using external sites.
Note that all files in that directory are automagically removed after some time. Files which you'd want to look at later, should be saved someplace else or they'll be lost like tears in rain.
ANSWERS TO QUESTIONS NEVER ASKED
- "Why Rotators have access to source and FUNline: BestServerEVER 76 mk 1207 vol.13 (by Przemo) developers don't? That's outrageous! That's unfair!"
First of all, it's a fact that everyone must accept, and second - don't forget that this is not our decision in any way. Since we've been working on the engine for so many years, we may have proved some points that may (or may not) have influenced this decision.
However, not only the Rotators have been granted the access to the engine source. There is one more person that currently enjoys the same privilege - cirn0, the lead developer of Ashes of Phoenix.
Be noted that cirn0 follows his own rules, goals and roadmap when it comes to maintaining the engine used by AoP. That engine can and probably will differ from FOClassic in many areas. Despite the code differences, both projects are being worked on hand in hand, and - in due time - there probably won't be any distinction between them.
We're positive that cirn0 will be more than happy to answer any question about his changes, be it about those already implemented, planned, or still in the testing phase. Please refer to the Ashes of Phoenix forum.
- "Everything looks nice and clean - there's signs of transparency and all that... So. What are you hiding?"
A few things. We will certainly take the advantage of the engine being closed, and follow the FOnline policy to avoid any discussion about the changes which will make lives of third party tools users/authors any easier.
- "I see what you're doing here, but I like the recent FOnline features! There's a lot of cool stuff implemented after r412!"
We plan to backport a small subset of changes from r413+ into FOClassic (mostly things done by Rotators) and a few things which has been rejected in the past. Other than that, we might take some general ideas and features, but - in case of big ones - will try to implement them from scratch. By taking this approach, we should be able to open certain parts of the source for everyone, e.g. AngelScript addons/utils, additional tools handling server content, libraries useful for other applications, etc.
- "That was A LOT of text. Issue tracker? Not much better, I didn't read that much of text since school. Why so much details? Some parts could be cut in half, or skipped altogether! Come on, people!"
We really want to start working on some fun stuff already, but without having to re-live the destiny of the r413+ releases once again. The smoother the migration process for servers goes, the faster we can jump into it. Some of the servers already tried to use newer SDKs in past, and then either had to scrap it all or to freeze their progress. In both cases, they've put effort and time into an unsuccessful migration and will be more cautious about doing it again.
Migration to FOClassic isn't that much different from migration to a post-r412-FOnline, after all. We believe preparing a clear plan before starting, and following it strictly will help the developers to make the decision. And if they decide to stay in shadows and wait until the fun stuff actually gets implemented, they can always go back to this post/issue tracker and collect as much info they need. Or even more.
- "OpenSource when?"
As soon as cvet allows it.
While decision about open-sourcing the FOnline engine (and by extension - FOClassic) is not for us to make, what we can do is to work on the project just like we'd work on it if it was open-source - with a single/funny exception that the source itself is being closed, obviously. When/if we get a green light for open-source, we're ready to practically switch to it in a very short time. A bit more would be needed, if we'd like to merge the public and others, non-public repositories into one preserving their commit history, or adjust various things to be easier to grasp for newcomers.
Either way, we must keep in mind that such day once might come, and try to prepare ourselves beforehand for it.
So, chief, we're not gonna ask about it on our own in other way than this very post alone...
But if you ever get the feeling that FOClassic is ready for such a big step as open-sourcing, just say a word.
