6 months ago, Dereth Forever was formed due to a lack of progress in other emulators. There was no available source for PhatAC, and ACE was not making any forward progress. AC Emulation was dead. We saw a need, so we stepped up to meet it, but with a different focus: community.
We started with a physics proof-of-concept using Bullet and were the first emulator with scenery generation that matched the live server. Unfortunately, that turned out to only be a “learning experience” as we became convinced that we would have to reimplement the physics system present in the client. We moved on to release the first version of our website, and then proceeded on with the large reverse engineering effort to recreate AC physics. We steadily made improvements to the website and progress in the reverse engineering effort. We revamped the world data store that just would not perform under load and brought world data load times down to single-digit-seconds. Things were looking up.
Then things started to change. ACE recruited a new contributor that started moving them forward at a remarkable pace. PhatAC’s source was leaked/published as “GDL”, and more than a couple C++ developers jumped on board. The foundation that Dereth Forever was founded on was no longer solid ground.
Over the past 4-6 weeks, the leadership of Dereth Forever has had numerous discussions about how to proceed, and our progress has obviously stalled. We took a hard look at the reason we created this group, and made ourselves reevaluate our goals in light of how the AC emulation scene had changed.
Change of Direction
Dereth Forever was founded on the premise of filling a gap. That gap has since closed. However, one of the (rather unexpected) gaps we ended up filling is the need for content creation tools. Server emulation is only half the battle. Rebuilding the content to make Dereth feel like Dereth is big challenge that the other emulators are largely ignoring.
Going forward, Dereth Forever will focus on content creation tools on our website at www.derethforever.com, and will not be pursuing server emulation. As long as we support the website, it will remain closed source. If there comes a time when we are no longer willing to host it, we will release the source for the community to use as they wish. We currently support GDL formats for content, and will support ACE if at some time they create the tools necessary to import and export data.
Dereth Forever is also changing the license on the client reverse engineering library that is 100% ours to be MIT. Unlike the GPL suite of licenses, this means you are free to use our Client RE code for whatever purposes you want as long as you cite the copyright. You don’t have to open your source, you don’t have to give us your modifications, it’s yours to use and edit as you wish.
We also want to thank all of you who have cheered us on and encouraged us over the past 6 months. We’ve always put the community first, and we’re continuing to do that by filling the gap that is – not the gap that was.
This morning we updated the website with a number of new features and bug fixes. Here are the release notes.
“Flags” enums that were previously complex numbers or ugly sets of checkboxes are now much more user-friendly. Simply pick the options you want from the list. Here’s a sample:
The Spells drop-down is now searchable. No more scrolling FOREVER to find the spell you want.
Loading certain creature weenies that were missing base attribute scores no longer crashes. Instead, they will default to 10s for any missing stats.
Content Magi attempting to approve changes to “new” weenies now works.
Emotes are now sorted appropriately on every page refresh.
New Emotes are now added to the end of the current list. You can re-sort by changing the sort order
The Weenie Finder is now used in a few more places allowing for easier searching
We’d also like to give Forge Golem a warm welcome to the team. He’ll really get started in a week or so, but we’re excited to bring him on board as a dedicated website resource. As always, if you find bugs or usability issues that aren’t on the trello board, let a staff member know and we’ll get it logged.
We’re excited to announce that we will be moving our ClientLib project to an LGPL license in the next couple days. For those of you that don’t care about the differences in Open Source licensing (and if you’re not a developer, you probably don’t), you can be confident this is a good thing. If you don’t want to take our word for it, I suggest you go read up on the differences, come back, and keep reading.
What is our “ClientLib” project? Glad you asked. Long story short, it’s all the dat content extraction and reverse engineered client code. Notably, this includes our physics code. It contains a lot of the basic functionality you would want to write meaningful AC websites and perhaps Decal plugins.
What this means for the community is that anybody that uses our ClientLib won’t be required to publish source code as long as no modifications are made to it. So if someone wanted to write decal plugins that pulled data out of the dat files (like, oh, a content editor), they could use our ClientLib. If somebody wanted to write a website and use our ClientLib to help them render stuff with WebGL or ThreeJS, they could use our ClientLib. If people started making mods to our ClientLib, though, they would still be subject to the same restrictions as they would under GPL. In this regard, the licensing is comparable. However, under GPL as it is today, the ClientLib carries with it all the viral aspects of GPL – merely using it or referencing it means your project now carries the GPL license whether you like it or not.
Disclaimer: none of us are lawyers. Our assertions of licensing implications do not constitute any promise or warranty of any sort.
We’re trying to wrap up the first pass of the Content Editing tool, but wanted to call out a feature we decided to add this week. We know that a large part of the remaining AC base is off playing deprecated copies of another unnamed emulator. We also know that you have ways to extract and import data into those worlds. The last thing we want to do is fracture the AC player base over which community to dedicate themselves to when having to create the content, whether that unnamed emulator or Dereth Forever. So the question is, why not both?
We will be adding the ability to import, edit, and export json files from that unnamed emulator into our Content Editing system. In the process, we get a copy of it, of course, and you can help rebuild the world for us as well as have a nice easy to use tool to rebuild worlds in the other emulator. We’re still working on the details of how we will give people sandboxes to play in and not corrupt data in the process, but we’re confident we can reach a solution that benefits everyone.
Today we were able to merge in the code necessary to implement dyeing of clothing and armor. Our newest developer Iron Golem was able to get it working properly and replace a lot of other really bad code in the process. We also have dye failure making your favorite shade of pink, too.
Physics was going great. We got everything loading, were able to see it loading properly with Sharp DX 11, and were excited to be making great progress. We knew it was a risk to use an engine instead of copying the internal physics to the game. We had server-side motion incremental motion mirroring and could have even done some client position validation rather easily.
Then we wanted to add movement mirroring over and around static objects. This was for 2 purposes. The larger purpose was so that we could “move” things on the server. Mainly, monsters. This requires being able to move stuff over objects (cell data) on the ground. This is mainly stuff like tables and chairs, but includes ramps and places in the world where there is more than 1 place you can be, vertically, for the same x and y values. Bullet failed us here. This required custom placement manipulation. We were already doing some of that for movement prediction, but that was movement over ground terrain.
Without fully implementing this movement over stuff, we realized that the only way we could really utilize a third party physics engine was for collision detection. But even then, it was a half-solution. We have to do collision detection for moving over/around cell objects anyway. Bullet doesn’t even get us that.
So, we’re cutting bait on using Bullet as a physics engine. We will continue to use it for the ability to see what’s going on in the engine we’ll end up rolling by hand and utilize the SharpDx11 stuff we already have to render it. This is still a great tool, we just can’t use it in the way we had hoped.
That said, we’re going to go as far as making portals work on the old system. Projectiles and server object pathing will have to wait for the new system to get put into place.
Today, we just PRed the first real integration of physics. It is a huge milestone that allows us start doing collision detections. Although this is obviously far from complete, it gives us a real window into how physics will work in our server.