RF Online and Emulators - Feedback Highly Encouraged

[Supicioso]

This is a simple thread concerning the current state of RF Online and the emulator that's currently being worked one. I know people have short attention spans so I'll make this brief.

I have 2 questions.

1. Do you still actively play RF Online? Elaborate a bit.
2. What do you think about a complete RF Online emulator?

I'm asking these questions for the a single reason. We are hard at work on an emulator. We're in-game and are currently working on character movement. If enough people are interested, we'll continue to work on it as per our original plans. If not, then we'll simple drop everything and no longer develop it. The files won't be released, and we'll simply let RF continue to fad away.

That is all. Please voice any and all concerns.

[MentaL]

[lifestream]

People do play - but a lot less. id say there is a total of 3000 or so players across retail and private servers.
People would still play but the widespread hacks ( expensive gameguard that still doesn't stop all) + outdated content has made people to lose interest. There is only so much you can dev and add - and there is a very few devs who can do advanced work ( for ex im very close to adding my own models to the game).

Depends how open/editable and what features the emulator has.
Also price - people quite likely will not invest much into starting u pa server - the player numbers and donation income is alot smaller then it was years ago. You already need a gamecp + hosting+domain.

Also how much access hosts/devs have to customize features ( or even inject/add custom modules to certain parts of the emulation).

[Ron]

I'm not so sure about custom features set by the end user. If the source code is released that would be very possible, but at the moment it is a closed source project. The closest thing to custom features would likely be in the form of better support for LUA scripts. RF already has this system but the lack of documentation makes it difficult to work with. Better LUA support would allow for custom events and even new functions available to scripts.

Keep in mind we would be able recode certain things depending on how the client handles certain changes. We could completely rework the chip war system from the ground up in regards to the flow of the event for example. There are a lot of broken mechanics in RF that we would be able to fix to improve upon the game as a whole... a lot of changes that would just not be possible with the official server files.

[Supicioso]

The chances this project goes open source is less likely then an asteroid hitting Maine. I've been around long enough to know that usually does more harm then any kind of good.
With that being said. custom features will likely be doable via extension system like Ron said. I.E LUA or runtime compiled C# scripts.

As per a game control panel, all of that would come with the emulator, since the emulator uses MySQL and not MSSQL. This allows us to modify the code in the feature for use with mono so it can be ran on linux.
Which, would save server owners a LOT of money because windows wouldn't be a requirement.

Pricing will likely be one of the following.
A large one time fee for everything. (This is so there aren't 100 different people trying to run a server saturating what already seems to be a declining player base)
A monthly fee per Zone.

None of this factors in custom features that can't be accomplished with the provided API/Script system. That would be a cost outside of the everything else, as it would take every from primary development.

The goal of this project is to provide an rf solution that's eons better then what's currently available in terms of resource usage and tools.
It's a pretty tall job for only 2 people, which is why I'm asking people please give their input on the matter. We both have things we could do rather then work on something no one's interested in.

[lifestream]

doesn't have to be open source if users can create their own modules ( with documentation).

But cost will be a major factor in its success - of any kind.
Hosting costs with linux or windows are large enough already. So there actually wont be that many that are interested of investing large sums in a scene with small number of players left - out of whom perhaps 1% actually donate.

How much of the emulator would use old files ( dat-s, map files etc) - or those would be recompiled as custom ones as well ( further making it increasingly annoying and more timeconsuming to start working on files).

[Ron]

doesn't have to be open source if users can create their own modules ( with documentation).

But cost will be a major factor in its success - of any kind.
Hosting costs with linux or windows are large enough already. So there actually wont be that many that are interested of investing large sums in a scene with small number of players left - out of whom perhaps 1% actually donate.

How much of the emulator would use old files ( dat-s, map files etc) - or those would be recompiled as custom ones as well ( further making it increasingly annoying and more timeconsuming to start working on files).

Its still pretty early to decide pricing information or whether or not the files themselves would be for sale rather than publicly available binaries. It is still too early in development to decide, but feedback could change what is finally decided.

For simplicity and unless there are any real benefits to justify using a new format to store game data, the old maps and scripts would most likely be reused from the official files. If there is a large performance benefit from using our own way to store the game script data then that'll probably be the way its done. I had an idea to store it all in MySQL tables. The benefit to this would be dynamically reloading data without having to restart the server. You could make changes on the fly without causing server downtime due to restarts, but the tradeoff is higher MySQL activity. Its too early to make optimization calls as we're just trying to get things working right now.

In any case, if we do use our own file format or store information in the database, editors would be included with the files to easily modify the data. Structorian was never a great tool anyway.

[lifestream]

structorian is still a great tool. u cannot beat the speed and visibility in a full table view.. any textbox/dropdown lists etc based editors and even 010 ( unless u run scripts to edit batches of data) fails - the yare extremely slow to find what u need and even actually edit larger amounts of different data..

[Kirito2105]

In RF has always played a lot of people, I do still play on pirate servers.
Honestly if you're grammotno do, you get an awesome project, so how can you except that it is easy to edit, and even modernize and simplify. It will be much easier easier than the current server that require awfully long and tedious tuning.
I hope that you will do with this project, even if you do one, a lot of people will want to buy you this server, a lot of money.
bad english

[Supicioso]

doesn't have to be open source if users can create their own modules ( with documentation).

But cost will be a major factor in its success - of any kind.
Hosting costs with linux or windows are large enough already. So there actually wont be that many that are interested of investing large sums in a scene with small number of players left - out of whom perhaps 1% actually donate.

How much of the emulator would use old files ( dat-s, map files etc) - or those would be recompiled as custom ones as well ( further making it increasingly annoying and more timeconsuming to start working on files).

You're probably seeing the emulator as how the official files are now. That's far from the case. They're already so vastly different you could even call it a different game all together.
The current files uses an insane amount of memory, although that method was faster then reading everything from a hard disk 5+ year ago. It puts all the strain on memory as opposed to disk iops.
But in an age where SSD is getting more and more common that method of doing things is quite ridiculous.

Current plans for offseting the system requirements is lowering the amount of memory and cpu that's required by using mysql to hold majority of the information. The most important factors will be network speed and cpu when the numbers of users are high.

When all's said and done, you could probably run these files off a good VPS server. Though that's just early speculation. There may be a software limitation somewhere down that line that turns it another direction, though that's not likely.