FOnline: 2238

Server forecast for Friday 06-Jan-2012: Wipe with heavy data loss

2012-01-04T22:38:00.000+01:00

COMMERCIAL: This server forecast is brought to you by "Rotators", the world leader in donation beggings & solutions!

FORECAST: on Friday, 6th of January, we may count with some heavy wipe followed by data loss on global scale. The wipe will most probably pass the Central and Western Europe at 09:00 PM (21:00), causing complete data loss for everyone. The unstable post-wipe conditions may last for the next two days, but we believe there will be no unexpected data loss during that time.

We advise you to gear up properly, including protective suits and equipment, take a lot of meds with you and go out. There's no need not to enjoy the next few days until the wipe hits us.

Don't forget to let the Brahmin out and burn down your accomodation!

Until our next forecast - have a nice time!

Please read: a personal appeal from the FOnline: 2238 Developer Lisac Twok

2011-12-23T17:51:00.005+01:00

I feel like living the last of my days in a polluted, unclean world, infested with bugs, glitches and crashes.

Imagine the world where every human being on the planet could wipe their virtual reality as they want, whenever they want. Although we're currently far away from that vision, it doesn't mean we have to give up on our dreams! Wipe, my brothers and sisters, wipe is our reality.

With the latest features being tested and discussed, with those last bugs being squashed or pulverised with pulse rifle, with each and every stinking breath of the stuck NPCs that break your quests - we are one step closer to our vision! As I write these words, the critical amount of bits and bytes are being accumulated in Paris, waiting to come into contact with a void function that shall release the Big Bang and bring us the next wipe, the salvation! The last of our days are coming, beware!

Not soon, but very soon, the wipe will bring the end of days as we know it and bring a new life to the brave world that has to be born on the ashes of the old one. Very soon.

Gather your forces. Wake up your sleeping moles. Send a telegram to Rangers. Take your minigun from the rusty tribal chest. Get your granpa stand by your side. Because, very, very soon...

It's about to wipe.

Wanted: Donations - Dead or Alive

2011-11-19T10:55:00.002+01:00

Like the title says, we are in dire need of donations for keeping the server running for the upcoming three months. The deadline is 6th December and the server fundings are currently short for ~80 €. Any amount is greatly appreciated and shall help the developers to concentrate on finishing the new features for the upcoming wipe, rather than to see their efforts being hampered by failing to oblige a quarter invoice for the server maintenance.

As always, Cvet & Rotators are grateful for your donations, as well as for any other great work and feedback provided by the FOnline communities.

Improving the vintage

2011-10-14T13:37:00.000+02:00

Our old and rusty faction terminal, the very first feature of 2238 could use some improvements. While we started the project few years ago, we couldn't hope for client scripts, nor for easy scripting client-side GUI. The only possibility was to use existing dialog functionalities.

Over the time it became obvious, that using such 'interface' is really big pain, and the usability of our game is not up to modern standards by a mile or two. But we have left that part unchanged, as there were other things to do (and still are). The upcoming wipe will not change it drastically, but it will surely improve the way factions are managed.

Multiple bases

There were so many factions created since the last wipe that we've run out of names. Several times. Most of them were only created to alleviate one problem - a faction is meant to have only one base, and all members have access to it, some were created when factions were creating an alliance, and some only because some rich player wanted private workbench and whores.

Of course, not all problems will be fixed immediately, but we're going to allow one faction to own multiple hideouts.

Access

To simplify things, the access will be resolved on per-rank and per-status basis. This means it won't be possible to do it per-player and per-faction (not yet at least), but still, that simple modification should make life of faction leaders much, much easier, and it should increase the importance of proper rank assignment.

Easier status change

We've also added the ability to create list of known factions. Such list is then used to alter the status of all members of said faction at once.It should work well with per-status access for bases. While we still have basic statuses: friend/neutral/enemy/invited, the system should allow for more so we could improve one that. Question is, whether it's gonna be worked on, or whether web-faction-terminal will takeover.

Summary

So why we haven't reworked it from the scratch, possibly creating client-side interface for it? Well, there are few reasons. First of course are, the plans for web faction terminal (which does not rule out easy client-side interface alongside with web interface). The other is that we're still working on GUI internals, our GUI code differs from the default SDK, and we're working on a ways to make them compatible. Sometimes it's good to work on internals first.

Living without client

2011-09-14T00:21:00.000+02:00

Recently I've written about the possibility to test the features by writing code, that test them. As I've started doing some refactoring in our code, I immediately wanted to use that feature. Let's see how it worked out...

Gathering, once again

As we already mentioned, we are changing (again) the way resources will be gathered. This of course required yet-another-refactor of that part of code. Last time I was doing this, it was rather boring task: refactor script of one facility, start server, login, spawn some of those facilities, spawn myself needed item, use it, check. Rinse and repeat (sometimes you may hot-reload the script, but you need to still test it manually).

This time I decided to write set of test cases for every 'use event' that results in resource being acquired. And then, those tests will check the stuff for me, so that I do not even need to fire up the client. Nifty!

class Plant : IFacility
{
    Item@ item;
    uint16 resource;
    uint batch;

    Plant(Item& item, uin16 resource, uint batch)
    {
         item.SetEvent(ITEM_EVENT_USE_ON_ME, "_UseItem");
         item.SetEvent(ITEM_EVENT_SKILL, "_UseSkill");
         item.SetEvent(ITEM_EVENT_FINISH, "_Finish");

        @this.item = item;
        this.batch = batch;
        this.resource = resource;
        this.batch = batch;
    }

    int get_Amount() { return item.Val1; }
    void set_Amount(int val) { item.Val1 = val; }

    bool UseItem(Critter& cr, Item& usedItem)
    {
        uint pid = usedItem.GetProtoId();
        if(pid == PID_KNIFE || pid == PID_COMBAT_KNIFE || pid == PID_LIL_JESUS_WEAPON || pid == PID_THROWING_KNIFE)
        {
             if(IsOverweighted(cr))
            {
                cr.SayMsg(SAY_NETMSG, TEXTMSG_GAME, STR_OVERWEIGHT);
                return true;
            }
            else
            {
                cr.AddItem(resource, batch);
                cr.SayMsg(SAY_NETMSG, TEXTMSG_TEXT, text);
            }
            return true;
        }
        else return false;
    }
}

This is an excerpt from a class that represents plant facility that we may cut with knife to use the needed resources. It's represented in-game as an item, and we are initializing it in item script in following way:

void item_init(Item& item, bool firstTime)
{
    AddFacility(item, Plant(item, PID_FIBER, 2));
}

It uses the pattern I've described in following post. The Plant constructor assigns the events to the item:

// critter uses skill on facility
bool _UseSkill(Item& item, Critter& cr, int skill)
{
    IFacility@ facility = GetFacility(item);
    if(valid(facility)) return facility.UseSkill(cr, skill);
    return false;
}
// critter uses item on facility
bool _UseItem(Item& item, Critter& cr, Item@ usedItem)
{
    if(valid(usedItem))
    {
        IFacility@ facility = GetFacility(item);
        if(valid(facility)) return facility.UseItem(cr, usedItem);
    }
    return false;
}
// :>
void _Finish(Item& item, bool deleted)
{
    IFacility@ facility = GetFacility(item);
    if(valid(facility)) RemoveFacility(item);
}

Testing stuff

First thing we would probably like to test is, whether critter really receives the items if using proper tool on that facility.Let's first prepare a helper that's gonna greatly reduce the amount of repeated code:

void mock_CritterAddItem(Critter& cr, uint16 pid, uint count)
{
    CallExpectation("CritterAddItem_" + pid + "_" + count);
}

class Fixture
{
    Critter@ cr;
    Item@ tool;
    Item@ item;

    Fixture(uint16 tool, string@ script)
    {
        @cr = MockCritter(1);
        Mock("Critter::AddItem", "mock_CritterAddItem");
        @this.tool = MockItem(tool);
        @this.item = MockItem(1); // this pid does not matter
        item.SetScript(script);
    }

    IFacility@ get_Facility() { return GetFacility(item); }
}

And now, the first test:

void test_PlantFruitGivesProperResource()
{
    Fixture fix(PID_KNIFE, "prod_plant_fiber@item_init");
    fix.Facility.Amount = 100;
    ExpectOnce("CritterAddItem_" + PID_FIBER + "_" + 2);

    fix.item.EventUseOnMe(fix.cr, fix.tool);

    VerifyExpectations();
}

The most important part is the mock for Critter::AddItem, which just stores the expectation named in following manner: CritterAddItem_PID_COUNT. In above test function, we're preparing a context consisting of:

critter
knife
item representing the plant

We invoke the event that would be normally invoked when player or npc would use a knife on the plant (EventUseOnMe). The call process normal behavior, but when it encounters call to Critter:AddItem it calls our mock instead. So we expect that our function is gonna call this function with PID_FIBER and 2 as parameters. Looking into the code of Plant::UseItem, we see that indeed it should work. Plant::batch is equal to 2, so it's gonna execute exactly what we wanted. Running the test confirms that. Yay!

Code is already bugged

Oh great:( I'm writing some code snippets that already contain bugs. So what? Let's fix them, but first let's write a test that confirms them, check if it fails, and then fix the bug and re-check the test:

void test_PlantFruitEmpty()
{
    Fixture fix(PID_KNIFE, "prod_plant_fiber@item_init");
    fix.Facility.Amount = 0;
    ExpectNonce("CritterAddItem_" + PID_FIBER);

    fix.item.EventSkill(fix.cr, -1);

    VerifyExpectations();
}

Since there are gonna be no timeouts on characters, the facilities itself should somehow limit the amount of resources that we can obtain (and they will be regenerated over time). We've already had implemented some Amount property in our Plant class, but the code didn't care about it. And this test proves that - we expect that AddItem is not gonna be called with PID_FIBER (and whatever count) at all, but it is, because we do not check for amount left in UseItem method. Let's fix it:

            // ...
            else
            {
                if(this.Amount > 0)
                {
                    cr.AddItem(resource, batch);
                    cr.SayMsg(SAY_NETMSG, TEXTMSG_TEXT, text);
                }
            }
            // ...

And let's run the test again. It succeeds! We've fixed a bug, we tested it. Without doing manual labor.

The method I'm describing here, really makes me happy developer, as I do not need to spend time on manual testing, and also I am preparing more and more tests that's gonna test whether existing features are still working in the future (you know, some change in other area of code can really break the other part of code, in an unexpected way, better catch at least some of such bugs).

There is still one bug left in the code (probably much more, I wrote this post without compiler). I'm leaving it for readers to find out and write test code that proves it!

Walking the way of bombs

2011-09-09T11:04:00.017+02:00

It isn't exactly news that various towns in the wasteland are racked with the crazy nature of suicide bombers. In real life and in FOnline: 2238. This particular way of entertainment is in almost all cases only entertaining for a very small minority of people and due to this, discussions internally and externally are kind of an unofficial sporting event by now.

Anyway, to make it short: In the future we want to change the way explosives are working and used in the game, to limit (but not totally remove) the amount of suicide runs. To accomplish this, we internally agreed on the following ideas:

Guards can "sniff" activated explosives (C4, Dynamite, and placed Landmines).
The player can't activate explosives (C4, Dynamite, and placing Landmines) whenever a guard is around or if the player is in guard range. (It simply doesn't work, with an entry in the message log.)
The player can activate explosives (C4, Dynamite and placing Landmines on the ground) whenever a guard is not around or if the player is not in guard range.

The few rules should result in harder suicide runs, without making them impossible, because the players action now will be as the following:

The PC has to activate the explosives far away from guard NPCs,
then the PC has to run up to their targets (NCR bazaar....),
and then hopefully explode there before a guard can kill the bomber and take the explosives (disarming them).

These simple changes should make the game better than with the current system (guard NPCs attack players with active explosives), which is pretty much useless, as especially dynamite can be triggered in around one second and nobody is able to react on it this fast.

Of course, the subject is still open for discussion and suggestions in the forum (for example, there were ideas about involving demolition expert profession in this process). Also we aren't quite sure about when exactly we are able to take this over into the game. It probably won't happen before the next wipe, but I'll hope we can push it afterwards.

Testing your server scripts

2011-09-06T13:37:00.006+02:00

I've finally gotten around the way to unit test FOnline scripts. I'm happy about it, though it's still a prototype, and I've only written few tests just to try it out.

Why test your code and why should we care? Well, it's very popular approach nowadays, to write a code that tests your code, just to be sure everything works as expected (and it's hard to keep track of everything with large codebase). It's common misconception that's not feasible for games, after all, how can you test something as complex as interactive program - and even worse - with multiple players?

The answer is that you're not writing a code to test your whole game. You're not gonna write a bot that plays it, does all the quests and check if everything still works (and even looks for holes in the walls, though that'd actually be cool). You write the code to test only portions of it, the small pieces, the units. Hence the name: unit testing. There's of course lots of materials on it over the internet, so we're not going to dive into the details, I just describe what were the problems, and how we solved it, so that we can finally try unit tests.

Isolating the code

When you look at the code you'd like to test, first thing that come to mind is that it's probably too complex and involves too much dependencies to be easily testable. Let's look at the example:

bool critter_use_item(Critter& cr, Item& item, Critter@ targetCr, Item@ targetItem, Scenery@ targetScen, uint param)
{
   bool isPlayer=cr.IsPlayer();
   bool useOnSelf=(not valid(targetCr) && not valid(targetItem) && not valid(targetScen))

   // Radio
   if(FLAG(item.Flags,ITEM_RADIO) && useOnSelf)
   {
       if(isPlayer) EditRadioSettings(cr,item);
           return true;
   }
   // ...
}

Say we need to test that when player uses the radio item, he can edit its settings. Unfortunately, to invoke critter_use_skill int this context we need:

player
item

OK, we may easily spawn radio, but how can we spawn player? Scripting subsystem does not allow us to do this. We could just spawn critter, but then we see script cares about IsPlayer() condition. And then, how do we test whether player actually saw the edit radio interface or not? There is that elusive EditRadioSettings function being invoked there, maybe we could somehow detect that it's been called? But how?
Due to above limitations, unit testing your code seems just not feasible. Surely, there must be some solutions, we just need to go out and learn how the world is doing this.

Mocks

The concept is simple. If you need to provide something for the tested code, that's not the part of the test itself but constitutes to the test context, provide a mock. A substitute for real object, a substitute for a function that's gonna allow us to isolate the tested code to the form that may be safely run from within unit test context. As far as above example goes, we would need three mocks:

player - Critter object with overriden IsPlayer() method that's returning true (another mock actually), or with fields set in a way that IsPlayer() is returning true

an item - Item object with fields telling us it's a radio

a function to detect that EditRadioSettings has been called

But we can't do this in AngelScript. Not without any modifications.

Mock library

At first I wanted to write some library that would be able to load the script, compile it and execute test functions providing overriden implementations for functions we wanted to mock. However, the AngelScript engine does not allow to re-register any function, so that once we've got our engine set up, we can't register any mocks. We thought of some workarounds, but after some time I decided to modify the server source directly (its angelscript source, to be precise), I suspected it would be very minor modification - so that maintain costs are minimal in the future (keeping it up to date with every server update).

Tests Runner server

After some fiddling in AngelScript engine code, I found out that I can easily 'redirect' function call to another script function (whether the original call was meant to invoke script function, or native (engine registered) one. Moreover, it turned out that method calls can be simply redirected to function calls (providing the first argument is the object passed), without any extra work! This way call to bool Critter::IsDead() could be handled by bool critter_IsDead(Critter& cr). Nice!
How does it affect our testing capabilities? To put it simply, we ended up with solution that may be used for testing generally, not only for unit tests. Unit tests are designed to test your small pieces of code out there, but hence we are running our tests in full fledged server, we may as well test the system more broadly, we may check how different pieces interact together - whether it works as a whole or not (though I admit, it wasn't my initial goal - I just wanted simple unit testing facility, not integration tests).

But let's get back to the example. Let's start from the last mock we needed, namely, a function substitute for EditRadioSettings. Say, we just want to know, whether the function has been called or not. Let's mock it, and make it so our substitute will indicate that's been called:

void mock_EditRadioSettings()
{
 CallExpectation("EditRadioSettings");
}

For above example to work, we need to know what CallExpectation function is doing. It simply increases the call counter, that's stored in some dictionary under the index that's been passed as argument. Later on, we may check that the counter is equal to 1 - that means our function has been called as expected. With such dictionary at hand, we should also define more helpers: Expect(funcname) and VerifyExpectations(). First one is used to remember the fact, that we want the function funcname to be called, and the latter (called at the end of the test), will check it. In fact, we should have the ability to specify the numbers of the call we're expecting:

ExpectOnce(funcname) - VerifyExpectations will succeed only if function has been called once
Expect(funcname, count) - success only if called count times
ExpectNonce(funcname) - success if hasn't been called at all

Once we've got our mock and our helpers ready, we're gonna substitute our real function:

Mock("EditRadioSettings", "mock_EditRadioSettings")

This function will remember that we want to redirect the call to EditRadioSettings to a function mock_EditRadioSettings.

Ok, what about other mocks? We said that we want an item, and a critter with specific properties and/or we may provide mocks for their methods as well. For this I've implemented simple MockCritter and MockItem functions that spawn the needed objects with only basic properties filled, but for the case of this example, let's assume those are just clean objects - with all properties zeroed out, rest will be handled by method mocks:

bool mock_True()
{
 return true;
}

And now, our test function (with needed mocks) in full glory:

bool mock_True()
{
 return true;
}
void mock_EditRadioSettings()
{
 CallExpectation("EditRadioSettings");
}

void IfPlayerUsesRadioEditRadioSettingsShouldBeCalled()
{
 // prepare
 Critter@ player = MockCritter();
 Mock("Critter::IsPlayer", "mock_True");
 Item@ radio = MockItem();
 radio.Flags = ITEM_RADIO;
 Mock("EditRadioSettings", "mock_EditRadioSettings");

 // call tested function
 critter_use_item(cr, radio, null, null, null, 0);

 // verify
 VerifyExpectations();
}

Voila! Now, when we call critter_use_item, it will first call Critter::IsPlayer(), which returns true, even if our Critter structure might have not indicated this, but our mock did. Later, it will check the flags (we've set it on our mocked item) and call the EditRadioSettings, which in fact calls mock_EditRadioSettings. This sets our expectations counter to 1, which is then verified by VerifyExpectations. And then it announces success - we've got our first trivial unit test passed!

The solution we've got is in very early stage, I'm gonna try and involve it in some of the 2238 code testing. We will see if it turns out to be useful.

Enough of this mockery for now!

Server issues

2011-08-28T19:10:00.003+02:00

We're having some problems with the server. We hope to solve it today, but there's no guarantee.

Thanks for your patience.

Faction data - asynchrony

2011-08-25T15:00:00.004+02:00

This is gonna be another post from the series on new approach to the faction data storage, and most technical one. It's gonna describe process of creating a native extension for FOnline server application, that will allow communication with external database, in our case, CouchDB. It's already implemented and is being tested, so I guess I can safely write about it.
The endeavour was quite an interesting one with lots of crazy ideas, few dead-ends, but eventually the solution turned out to be nice and clean.

So, for those interested in hacking the guts of server application, extending it to perform things you haven't imagine, let's read!

Data synchronization

First, we need to make brief summary, of what we want to accomplish. It's been described in previous posts, basically, we need a way to synchronize some game data (players properties, variables) with the data stored in CouchDB. As with every communication, there are two directions we may want to communicate:

server asks CouchDB for data it needs to synchronize
CouchDB tells server that it may want to synchronize

Since we'd rather extend server application, than to write additional tier for CouchDB that would communicate with server, we of course choose the first approach. The data we need to synchronize are:

factions
players' documents from factions databases

So basically we may need two functions to do this:

GetFactions - gets all factions with their properties
GetPlayerFile - gets player file stored in certain faction database

Let's focus now on the first one.

Main factions database

Info on our fac tions is going to reside in central database, called factions. This database is going to contain documents for each of the registered faction (for simplicity sake, we're not going to write about registering new faction process). Example document:

{

 "_id": "Brotherhood Of Steel",

 "id": 2,

 "database": "brotherhood_of_steel"

}

The _id field is the unique identifier for the document, so it's also the faction name. The id (without leading underscore) is the number assigned during registration process, and is the number any member of that faction carries on his player character, so that game logic may react appropriately. The database field is the name of the faction database, that reside on the same CouchDB server. It needs to be different than the faction name, cause CouchDB does not allow certain characters in database names.

In-game, our factions are going to be represented by following class:

class Faction

{

 int id;

 string name;

 string database;



 Faction(int id, const string& name, const string& database_name)

 {

     this.id = id;

     this.name = name;

     this.database = database_name;

 }



 int get_Id() const { return this.id; }

 string get_Name() const { return this.name; }

 string get_Database() const { return this.database; }

};

And we're storing the objects of that class in some array. So, the only thing we need, is indeed a GetFactions function, that would just fetch data from factions database and fill up our array.

But before we dive into code, let's pause for a moment. It is external storage, it's http protocol. By no means it's going to be fast. We can't just write an extension function that is going to perform http request and return the results so that we can process them further in scripts. It would block the server during the call for at least few miliseconds, but it could even be few seconds, it depends. We need a way for asynchronous calls.

Asynchronicity

What's that, and why it's not The Police album? The principles of asynchronous calls are very simple. The call is being performed, and the function immediately returns to the place from where it's been called, allowing main thread to resume its job without waiting for function results (while the function that's been called asynchronously is being executed in other thread). Great, but we are interested in those results, so we need a way to operate on them. Traditionally, this issue is being solved by callbacks. To put it simply, you are defining another function, that will be called when our function that has been called asynchronously finishes its execution. Such callback takes what's been returned by the asynchronous function as its argument, and perform whatever logic we wanted to be performed on that result in the first place.

But we're not at home still, let's check it. This is going to be our hypothetical extension function, that is going to perform http requets to CouchDB, and return data for further processing (pseudocode, native):

void AsyncGetFactions(callback)

{

 QueueThreadPoolTask(task, callback);

}

void task(callback)

{

 string res = CouchDB::Get("factions");

 callback(res);

}

This is how asynchronous functions look like. They only queue the task to be performed later on other thread. The function is taking a callback as an argument, performs http GET request, and calls the callback to operate on data. But we want our callback to be AngelScript function, what we may do about it? Common solution in FOnline scripting, is to pass the name of the function as string(pseudocode, AngelScript):

AsyncGetFactions("callback");



void callback(const string& result)

{

 // operate on what's been returned. It's JSON, but we're not going to dive into that matter now

}

Familiar? Should be - CreateTimeEvent works this way. We may rework our native extension to something like this:

void AsyncGetFactions(const string& callback)

void AsyncGetFactions(callback)

{

 QueueTask(task, callback);

}

void task(callback)

{

 string res = CouchDB::Get("factions");

 CallAngelScriptFunction(callback, res);

}

The last line uses a function, that would fetch the function from AngelScript engine, knowing its name, and would call it passing our result as argument.

But hey, something is still wrong here. Remember the task is being executed in another thread. Whoops, and a big one. That means our callback function will be executed on that other thread as well, which means simultaneously with whatever other game logic is being executed at that time. This of course may lead to the data corruption, hard to track errors, unexpected behaviour, all that fun. What can we do about it? Traditionally, you may assure that the function that's going to be run in parallel with main code, does not operate on the same variables that the main logic thread does. But that would be very hard to achieve, after all, for our callback we would probably like to reuse whatever code we alredy have in our codebase, and I bet most of it is not thread-safe at all. Is there something that can save our asses in our quest to achieve our goal?

Message passing concurrency

Some clever folks found out, that to avoid problems with multithreaded code, it's best to avoid the code that's simultaneously executed and operates on same set of data - brilliant, isn't it. Instead, it's better to have totally separated units, and only have them communicating between by passing messages to each other.
Notice, that we may safely run our game logic in parallel with CouchDB http request, as those are totally separated. It's when we want to operate on data returned, when we're running into problems. So why not return the data somehow to the server application, and let server logic be the one responsible for reading it and performing the funcionality? That way, the callback logic will be executed by main thread, so no problems here. For that, we need a queue with messages, that we will be using to exchange data between our asynchronous functions, and the server logic. Then we're gonna be able to leave the message (from the other thread), and fetch the message (from main logic thread) to further operate on it (still in main logic thread). That way, the only structure shared between threads will be the queue itself, but it's not a problem to write such thing to be perfectly thread safe:

void PushMessage(msg)

{

 lock(messages);

 messages.push(msg);

 unlock(messages);

}

msg FetchMessage()

{

 lock(messages);

 msg = messages.pop();

 unlock(messages);

 return msg;

}

Above pseudocode shows us, how we can synchronize the reads and writes on our queue, to assure that only one thread is accessing them at a time. The way we do it depends on libraries we're gonna use, I do not want to dive into the details here, but the principles are the same:

lock puts a lock on some structure
unlock takes that lock away from it
there may be only one lock at the structure at a given time, so next call to lock (performed from other thread) is going to be blocked and wait till it's being unlocked

That gives us thread-safety for the queue. Let's use it now:

void AsyncGetFactions()

{

 QueueThreadPoolTask(task, callback);

}

void task()

{

string res = CouchDB::Get("factions");

// iterate over res content, to send message for every faction contained there

for(...)

   PushMessage(new Message(MESSAGE_FACTION, res));

}

And in script:

void UpdateFactions() // we could call it from main@loop() for example

{

 AsyncGetFactions();



 while(true)

 {

     Message@ msg = FetchMessage();

     if(!valid(msg)) break;



     if(msg.type == MESSAGE_FACTION)

         ProcessFaction(msg.res);

 }

}

void ProcessFaction(string res)

{

 // parse our input, determine faction properties, check if already in array

 // if not, add it there, otherwise - update

}

Notice, that we're calling AsyncGetFactions in each loop and after that we're fetching all messages. But the messages won't probably arrive at that moment, for that we will have to wait. And, while we are waiting, there is no point in calling AsyncGetFactions over and over again. We need to orchestrate somehow our calls, we can do this with simple boolean switches:

bool GettingFactions = false;



void UpdateFactions()

{

if(!GettingFactions)

    AsyncGetFactions();



while(true)

{

    Message@ msg = FetchMessage();

    if(!valid(msg)) break;



    if(msg.type == MESSAGE_FACTION)

        ProcessFaction(msg.res);

}

}

It's that simple. But we need a way to notice the game logic about the fact, that our asynchronous extension has finished with getting factions. For this, we will extend it to send yet another message, after all faction messages have been sent:

void task()

{

 string res = CouchDB::Get("factions");

 // iterate over res content, to send message for every faction contained there

 for(...)

   PushMessage(new Message(MESSAGE_FACTION, res));

 PushMessage(new Message(MESSAGE_GET_FACTIONS_DONE));

}

And then in scripts, we will switch our variable:

void UpdateFactions()

{

if(!GettingFactions)

AsyncGetFactions();



while(true)

{

    Message@ msg = FetchMessage();

    if(!valid(msg)) break;



    if(msg.type == MESSAGE_FACTION)

        ProcessFaction(msg.res);

    if(msg.type == MESSAGE_GET_FACTIONS_DONE)

        GettingFactions = false;

}

}

By setting GettingFactions to false, we're indicating that we are no longer running AsyncGetFactions in the background, so we can safely call it again next time. And our loop is chewing whatever messages arrive there all the time. All in parallel, all in thread-safety.

I hope it was interesting read, maybe not too detailed and with lots of pseudocode, but I did want to show the idea, not the implementation specifics.

Tremendous bug!

2011-08-21T18:18:00.006+02:00

It didn't take you long to find out what was wrong in the solution I presented in http://fonline2238.blogspot.com/2011/08/what-would-be-point-of-having.html. In fact, you were faster than me fixing it, after the bug introduced by it occured on 2238 server.

Let's start from beginning. In first iteration of gathering (called production) back then, we needed a notion of facility that player could use to obtain some resource. A facility could be one item (item pretending to be scenery object actually, it had to be item because of the scripting possibilities), or collection of items. So, a barrel in Modoc was one facility and all the plants somewhere on the crop could be one facility as well. And when the player obtained some resources from it, we needed to apply timeout for it (store it on the item somewhere). Also, we needed even more scripting possibilities - rotgut still for example. Perfect situation to use the wrapping pattern:

interface IFacility

{

bool CheckTimeout();

void Use(Critter& cr);

}

class BarrelFacility : IFacility

{

Item@ barrel;

BarrelFacility(Item& item)

{

    this.item = item;

}

bool CheckTimeout()

{

    return item.Val1 > __FullSecond;

}

void Use(Critter& cr)

{

    if(CheckTimeout())

    {

        // give junk

        item.Val1 = __FullSecond + 60; // 60 seconds of barrel cooldown

    }

}

}

Of course above code is simplification, and we needed to wrap the item for other reasons as well - for example having one facility object per many items, but it's not the point of that post to explain all of it.
So, we were adding the BarrelFacility objects in barrel script:

void item_init(Item& item, bool)

{

AddFacility(BarrelFacility(item));

}

And we had that global array of IFacility objects. I didn't implement removal procedure, simply because, all those facilities were in towns and other fixed locations. So, they were destroyed only when server was being shut down, and were created only on server start. Additionaly, because of the fact there was only few of them, and I think I haven't got any unused Item::ValX field, I haven't been storing the index to the array for fast fetch (like I wrote in previous blogpost on that), but I was iterating over whole array to find proper object. It hadn't got big performance impact, but one day we decided we need to change the system: we introduced facilities into encounters. Boom!

Yes, that was it - the IFacility objects were created very often, and never being destroyed. The array was growing and growing, and the fetching procedure was O(n) in complexity instead of O(1). Terrible stuff. When players started to jumping into encounters, after some time the array was so big that every time someone wanted to use facility, the algorithm had to go through thousands of iterations to find proper index in the array. And the appending was quite painful as well - the underlying array object needs to copy all elements on resize, as it does not reserve space up-front.

And that caused a lag. The Lag in fact, it was so big that it had destroyed the fun from early beta days. And we haven't fixed it that fast. To put it simply - I forgot that the objects are never removed, and found that out later... A little embarassing, I know, but now, when looking at it after such amount of time - it's quite funny to recall.

And quite funny story about 2238 development I think.

Wrapping a wrap

2011-08-17T23:55:00.015+02:00

What would be the point of having developer's blog, if there wouldn't be anything on programming. Oh yeah, that's where the things got hot. This is where it works, this is where it fails.

Since launch of the SDK, probably lots of people started struggling with that fancy scripting language - AngelScript. I remember I did. Experienced some successes, failures, helped finding some bugs, worked my way out through this language, started appreciating it, started even liking it (now I see it was indeed quite a good choice). That's why I think we could from time to time talk about scripting in FOnline SDK, talk about the AngelScript, share some common pitfalls, solutions that worked out good, and even the ones that weren't.

Of course basics of angelscripting is required, there won't be any tutorials whatsoever.

Objects

Blah blah blah, everything you can model in your OO language is an object, yeah, we already know that and it sucks (I'm getting a little bit off topic right here). Ok, it does not suck, in fact we're gonna often rely heavily on that fact, and we're gonna put large part of our logic into objects. And we're gonna tie those objects to the in-game objects (critters, items, scenery, maps, locations).

Say we've got a class for objects that are gonna make us some nice abstraction layer over default item functionality:

class SuperFoo

{

 Item@ item;

 SuperFoo(Item& item)

 {

     @this.item = item;

 }



 void Bar()

 {

     item.Val0++;

 }

}

What's going on here? We wrap an item type in some class, and we're adding some useless code to operate on it? Why the hell would we want it? Well, think about the interface you've just gained and you can use throughout your scripts. You may now call: something.Bar() instead of item.Val0++, which shows what you want to do, and not how are you going to do. That's the difference if you want to write good code. Less imperative, less verbosity, less bugs (yes, I know that example suck, and you would want that for far more reasons - think about having some additional data, that's not stored on the wrapped item, but it's one of the class' fields - it's not saved anywhere, but still may be useful).

Wait, did someone say interface?

interface ISuperFoo

{

    void Bar();

}

Oh great, now we've got the interface that allows us to call Bar(). And we don't even know what's called in the implementation class (in fact, we don't care, this is what interfaces are for).

So far so good, but FOnline scripting engine works in a way, that you can attach your functionality to the handlers for default events.

Let's start of course, from creating an object. If we want to attach it to the item, we need to do this in the item_init handler.

void item_init(Item& item, bool firstTime)

{

    SuperFoo@ foo = SuperFoo(item);

}

Yeah, whoops. We're gonna loose the reference to the newly created foo object as soon as we leave the function. Unacceptable, we need to store it somewhere.

Object Managers

This is also common solution. If you've got many objects in your program, you need to manage them somehow, store the references to them, maintain their lifetime, give the references(via interaface) to those interested.
We're gonna use basic generic array type for that.


array<superfoo@> Foos;



ISuperFoo@ GetFoo(const Item& item)

{

 for(uint i = 0; i < Foos.length(); i++)  

 {

     if(Foos[i].item.Id == item.Id)

         return Foos[i];

 }

 return null;

}

void AddFoo(Item item)

{  

 Foos.insertLast(SuperFoo(item));

}

Oh what a horrible piece of code we've just made. Yes, we've got our array, and function to add an object for an item (which we can use in item_init) and get the interface of such object for existing item. But there is that horrible loop in GetFoo, we need to scrap that. The best would be, if we could perform fetch with direct index to our array. We can do that, if we're able to store the index, at which our Foo is located in the array. Let's store it in Item::Val1 field:

void AddFoo(Item& item)

{

    Foos.insertLast(SuperFoo(item));

    item.Val1 = Foos.length() - 1; // here we've got index to our array stored

}

ISuperFoo@ GetFoo(const Item& item)

{

    if(item.Val1 < Foos.length())

        return Foos[item.Val1];

    else

        return null;

}

and our item_init will now look like:

void item_init(Item& item, bool)

{

    AddFoo(item);

}

So, we're now adding our SuperFoo object every time we call item_init, and we can fetch it in any script module (any module that imports this function of course), by obtaining an interface, that's not coupled in any way to the implementation class, nor coupled to the item object. Nifty.

We can use our interface in following manner:

void item_init(Item& item, bool)

{

    AddFoo(item);

    item.SetEvent(ITEM_EVENT_USE, "_FooUse");

}

bool _FooUse(Item& item, Critter& crit, Critter@ onCritter, Item@ onItem, Scenery@ onScenery)

{

    ISuperFoo@ foo = GetFoo(item);

    if(valid(foo)) foo.Bar();

}

The _FooUse function is where this solution shines. We call our method via interface(we may even pass some parameters given to us by the engine), and we do not care of what's going on inside.

Now, there is still something wrong with that solution, first who find out what, gets a candy!

Gathering? Waiting?

2011-08-16T11:57:00.008+02:00

Oh, that's certainly hot topic. Countless debates, unlimited flames, and cause of infinite hate, frustration, suicides, recession.

Changes are iminent, be it cooldown time reduction or even changing approach to whole system. We'd like to present you couple of ideas that you might want to discuss - yeah like it hasn't been done before countless of times! Jokes aside, let's check it out.

Scavenging

During early times of open beta, the gathering for resources worked in slightly different manner. You were looking for various materials on the worldmap, there was a chance for particular resource being generated. After you've acquired it, there was no cooldown. This ended in constant entering/looking around/leaving, which was not only rather boring, but also highly farmable. However, the worldmap and encounters are playing big part in Fallout games, so we could tweak that approach, and use it once again:

attach a chance to various zones to spawn various materials (be it junk, ore or whatever)
disable ability to reroll material spawn when you force-enter from worldmap (that means you need to wander around and wait for next encounter check)

That leaves us with a system in which we still could calculate the average time in which a player is obtaining particular resource: encounter check is being performed every 5 sec, it's easy to calculate values on that.

What are the pros of such approach?

no cooldown - or rather, it's being hidden
corelating materials with encounters, that means, due to the level of difficulty, some zones could spawn high quality resources

How about the cons?

it's all about encounters once again, may be frustrating to look around with no luck

Hunting

Well, but we could as well stay with current cooldowns, but we need a way for players to reduce them. Somewhat entertaining way, though that's subjective. For that, we could add items that reduce timeout - say food. You could obtain food by hunting (encounters again), or you could buy it at traders. That's additional task your player needs to do, but that's optional (well, some may find it mandatory, if they want to have the most out of it).

Pros:

additional activities
a way to reduce cooldown

Cons:

The cooldowns stay (albeit reduced)

That's all for now. I think we don't need to encourage discussion, it's unavoidable!

Bases visibility

2011-08-14T10:08:00.009+02:00

In previous posts I've explained how we're gonna use the documents stored in faction database (a.k.a. files) to remember various info, such as what bases are accessible, and what are not the the given player (whether it's a member or not).

I've focused on synchronization aspect, and I will follow that in this post, as the technical side of it affects how it's gonna work for you.

This is gonna be our hypothetical player's file:

{

"_id": "scypior",

"faction": "The Unity",

"bases": [ "bunker" ]

}

In this case it's of no importance whether this record is stored in The Unity's database and it's record for a member, or whether it's in some other database and we just want to specify the bases this player can access.

With such file, server is gonna synchronize its data in following manner:
- compare the incoming file with previous one, detect if any new base appeared on the list, or if any base got removed from that list
- take the list of new entries in bases list, fetch their location id numbers knowing their names (checking if such base really exist and belong to that faction), mark those locations as visible for given player
- take the list of removed entries, do the above magic for location id and mark those locations as invisible

Notice the difference to the current system, that was caused solely by the technical changes - the visibility is set/unset when the server synchronize the data, while currently, on the following events:
- invited member enters location (visibility set)
- non-member slain in the base location (visibility unset)

The change in first case, may make players happy actually - no more tedious inviting, everything is done automagically. While I certainly do not like when magic happens in game, it's often needed to avoid frustration (and you've got already shattered nerves...), so it's good.

The other case however, might also be liked (oh no, he may come and kill us in our base, better quickly revoke his access!!!), but I very much liked the fact you needed to kill that unwanted player on your own ground to settle things, so I could think of solution for this, if it is really needed.

What are your thoughts on that matter?

Revolutionizing Faction Terminal Data

2011-08-11T22:53:00.013+02:00

This is the second part of the series on crazy ideas for factions terminal. In the previous post I described why the changes were needed, also I've shown why we could be potentially interested in externalizing faction databases and make them sitting on top of CouchDB, thus 'freeing' the data and handing it to the players, while providing html interface for everyone to use.

Let's think now about the faction terminal/database, and the data that lives there. Basically, it's all about players. The main part of it is just a list of players - members, and non-members as well. Currently, each player record (let's call it file for future reference) contains:
- faction to which described player belongs to
- status, i.e. his relation to the faction that owns the database
- rank - call it a 'level of importance' for the faction the player belongs to

Notice how some of that data does not really affect gameworld. For example, the status - if the player is the enemy for your gang, the gameworld (npcs, monsters and other script-driven aspects of the game) does not care about that fact. But should it be the terminal of an NPC faction, then such status matters.

Ok, so what we've got here is some kind of file for a player. Essentially, a document, so it should really be a breeze trying to put that in the CouchDB. Using JSON, as this is the notation used for CouchDB, our file would look like:


{

   "_id": "scypior",

   "faction": "The Unity"  

   "status": "enemy",

   "rank": 4

}*

*Of course the interface will be reponsible for handling this format, the UI layer should look better:)

I think I don't need to get into the details of JSON format, it really looks intuitive.

The first field in our file structure is the _id. It's identified in such way, because this is how CouchDB handle documents, it does not allow you to have more than one document with same id. So, choosing a player name for that field seems like good idea in FOnline case.
The other fields - this is where we are trying to describe the faction the player belongs to, his status within our ranks and his rank in his own structures. For purpose of this example, assume it's record for non-member.

We may fill up our faction database (remember, each faction holds its own database in CouchDB ecosystem) with thousands of files, but what does it really do? Surely, some aspect of it is to store data for players information, but it cannot only serve that case. Game itself might be interested in some of that data. Of course, the most important should be the faction field. Ok, what we should do about it? We need a way for a server to fetch the data it's interested in, and react accordingly. We need synchronization. And we need the server to decide what kind of data it needs.

It definitely needs data describing the faction membership. So how we could work with that data? Surely we cannot just fetch the file document from database, and act upon it. We cannot change the player's faction, just because it was said so in some database, can we? Well, in one case: if the player's faction is the same as the one we're currently grabbing data from, and the document on that player states otherwise. That means someone (someone with permission for that database) has changed the faction on his member hence we need to clear faction on that player (not change it to the one that's in file now).

What about acquiring faction membership? Currently, we need to accept an invitation. This won't change - if player attempts to join some faction, we first are gonna check if his file in that faction database describes his status as invited. Then we can proceed with membership change.

If we're keeping with current system, there is also one field left - rank. As we've said previously, it does not really matter when the database belongs to a gang. After all, those files are read by players, so they might want to set those ranks to any values they want. But say, we're now talking about NPC faction database. The mechanics for reputations in game decrease your reputation with regard to some faction, if you attack its members. The amount of reputation deduced depends on the rank of the victim. So in that case, we should impose restrictions on the values that may be used for members in such NPC faction.

But so far, that's the very same functionality we've already had, let's see how we could implement new functionality.

Multiple bases. Oh yeah, that's something needed. Say, we acquire the base somehow (it doesn't matter how, whether it will be just 'buying' from some NPC (like now), or whether it will be built like a house from resources (not saying something like that is there:) ). Of course we would like to manage the players, that have access to those bases. To recognize a base, we need to name it. Once we've got a name, we may just fill some additional field in the player file, that's showing us to what bases he's got access to:


{

    "_id": "scypior",

    "faction": "The Unity",

    "status": "enemy",

    "rank": 4,

    "bases": [ "dacha", "bunker", "depot" ]

}

Oh great, not only we are stating that player scypior is the enemy, but also we're giving him an access to our bases? Well, our bad. But that's not important here, we've filled that data, and we want the server to react (show the green circles on his worldmap). For this, the data needs to keep up with the standard of course, otherwise, server won't have any idea what we mean. Synchronization procedure in this case might look like this:
- take the bases list
- check if the names of the bases are describing locations that really belong to given faction we're fetching the file from
- take the player that the file describes
- mark those locations as visible for him
Similarily it should work for bases that are no longer visible for him (some kind of blacklist), it needs to be in different list.

Ok, so far - great. But you may ask - I was saying a lots about customization, about freeing the data and handing it to the players. But so far, the data was needed to be laid down in some standard format, otherwise server would have not know what to do with it, and hence, such additional data was useless.

That's true, because players cannot customize the way server works. What they can customize however, is what the terminal is showing and what it does for them, players. I already said that we may put whatever data we want there, display it in the terminal (by customizing some html) - various messages, notes, other info, but that's not very connected to the gameworld. Would be good, if such database would contain info on some gameworld elements that are of interest to us (and within our permissions). Following ideas are hypothetical, but we could just fill the faction database with lots of data and let players decide what to use and how to use.

For example, imagine we would like to know what items are in which base. If the server would tirelessly help us filling it, we could use such info, and make various inventories etc.

But that may be a lots of data to cope with. What do you think? What would be useful to see out there in those terminals? Or maybe it's not needed at all?

PS. Next time, I may describe some inner details of how one can implement communication with such external source, that could be useful for those of you interested in FOnline modding, or maybe I will follow the musings about the customization, we will see...

Revolutionizing Faction Terminal

2011-08-10T08:40:00.010+02:00

Faction management, isn't it the main and central thing of this game? Or wait, shouldn't it be? After all it's common knowledge, that it's been called Faction Mod from the beginning. And one of the first thing implemented, was that 'handy' faction terminal that allowed you to invite other players to the base, build structures of your gang, store data about outer world (other players).

But it has not worked as expected, and many things changed since then. First and foremost, it was build around the standard dialog interface functionality, due to the limitations that was imposed during that time. Because of that, managing faction became tedious and annoying task. Also, it turned out that players do not need all those functionality - not always they need to have four ranks for their members, sometimes maybe they would like to have more than one leader, maybe they would also like to have their radio channel changing randomly automatically. Maybe they also would like to have customized messaging system, in which everyone could post a message on the terminal, to be later read by others. Lots of possibilities, but the main issue was usability. That meant it required changes, or even complete overhaul.

Lots of time has passed, and the engine has grown up to the point almost everything is possible (with varying amount of work). But still, we have not improved that core functionality - chasing other stuff, or simply because of lack of time.

I started to think about the changes quite time ago, and wanted also to expose that stuff to the world by providing web interface for players (along with account management). First, I wanted to put emphasis on that, so that once registered playername always belong to some account, and it cannot be taken after wipe. And on top of that, I wanted to reimplement the very same functionality we've got in faction terminal, but also expose it to the web interface and store data in some persistent, wipe-safe storage (SQL database to be precise).

I started implementing it, but soon I realized it needs some amount of customization, otherwise it might just fail the same way as old system did - providing some useless functionality, being used only partially etc. Of course, I began to think how to inject some flexibility into it - that seemed to be lot of work. Then I stumbled upon something, that entirely changed my ideas and made me to start implementing it almost from a scratch again.

Document databases, namely - CouchDB.

To those interested, CouchDB is non-relational database, that allows you to store your data in form of documents in JSON format (Javascript Object Notation). That means - no relations, only documents. Hey - that sounds good, after all, faction terminal is just a database where you store documents, right? In traditional SQL approach, you would have something like:

table Factions
table Players

connected with relation 1 to many. Then, if you want to fetch all players records stored in faction A, you need to join those 2 tables to prepare output records. Oh nice, this is what the world is doing since ages, it works. But why to impose such rigidness on that, in non-relational database, you would just create database for faction A, and store documents about players there. Nice!

But that's not all. It turned out that CouchDB, because of the fact its protocol is HTTP, is able to serve HTML (and other HTTP content) directly. So I can build web interface (web application) in it, no need for additional tier, no need for additional dependencies. Great? Yeah, I started to love it.

Now, another surprise - it's designed in a way, that each web application is stored in some database, right? And previously, we stated that we will do it the way that each faction would have its own database. That means, each faction could have its own, fully customized web interface (of course, default one is gonna be provided). And it requires only HTML + Javascript knowledge.

Ok, that all sounds fine, but also it feels a bit dangerous. We are allowing players to store the data they want, and we also want to server (gameworld) react to it in proper way. So we need some way of communication, between CouchDB and FOnline server. Seems hard, but part of it already works.

Hopefully, this is the first part of the series about new factions interface. Please note, that's not yet stated when it's gonna be finalized and introduced. To my excuse, I've got real reasons why it's taking so long:)

In next post we will dissect how it might work and how the data will be synchronized, or maybe I'm gonna throw in some technical details, just for fun.

The Vault Dweller dissects FOnline: 2238!

2011-04-19T23:24:00.008+02:00

It took months after the launch of FOnline: 2238 before The Vault Dweller of the NMA decided to try it out. One way or another, his FOnline: 2238 review is finally up on the NMA. The review itself did get old in the meantime, simply because everlasting new features were added recently, while publishing of the review was delayed for the reasons unknown to us - nonetheless, it is good to hear an opinion of such an unbiased reviewer, no matter what.

We appreciate the effort the VD made in order to write this article; the least we can do to show our appreciation is to read it ourselves, as well as to recommend it to you. In the end, we also do hope that our endeavors shall inspire him during his perilous article writing journeys in the days to come.

Development Diary: These damn animations

2011-02-28T21:03:00.010+01:00

So, this one is a small one. Everyone is waiting for the next smaller update-- hey, we too! Anyway, to not abandon this place, here is some insight on what is the reason why it takes and took us so long:

Right now, we are fighting some little ugly problems with the animations of killed critters. That is, flipping around on death, not working flamethrower attack animations and so on and so on. This is, in fact, the last thing we have to do until the next update can get out of the cage. We aren't sure if we can handle the flamer attack animation in the short time, but at least killed critters will stop flipping around while getting killed.

Also as the one or the other might have heard already, we are adding a new armor item. It's a sand colored robe, created by x'il (who also worked on the long hair and bald head dude), some of you might know it already from the Fallout modding community.

The robe will be available for cheap money at most of the traders in the wasteland. Let's not be that blue anymore all together! Switch yer bluesuit to the new sandsuit and be a hipster too!

Additionally and as always, we made lots of map changes, dialog fixes and so on. I'll guess various changes on the maps will be the most obvious ones. You for sure will recognize it in the game after the update has been done.

So far, that's it for now.

Stay tuned for more.

WIP: 3D Model Screenshots

2011-02-14T15:07:00.003+01:00

To post something new in here, we got three screenshots of some of the new work in progress 3d models for you guys. Animations and models are 100% community work.

Update and a new video by Cryofluid

2010-12-17T17:52:00.004+01:00

After weeks of quirky bugs in the town control system, we are happy to notify our faithful community that we finally have managed to squish them. After the server maintenance and the latest restart, as of yesterday, it's not only the town control that has been fixed - the server stability has been vastly improved as well. Due to occasional crashes we had to start an investigation of the problems. The issues have been addressed and certain updates for several OS components were installed, which, in return, have brought some additional stability to the server.

We would also like to use this opportunity to announce the implementation of the first big faction in 2238: the Brotherhood of Steel. Although somewhat 'modest' update with 'only' 6 new quests and a further faction development line depending on the global events, this is the first step into the new direction the development of this game is about to take. You will be, of course, notified abut any changes in good time, so everyone can test the new feature(s) intensively, providing us the valuable feedback needed for the necessary adjustments in the future.

So, there is a reason for celebration, right? Just when we needed it most, Cryofluid stroke again with his new video. There is a bit of everything in it: FOnline 2238 factions history, current relations between new and old gangs on the server, a Christmas note, an homage to a great movie (or maybe two), a parody. Not sure what the hell is that all about? Seek the knowledge. Alternatively, you can always visit www.fonline.fr and browse through the virtual room created by our supporters from France. Anyway, long story short - here's the new video we all have been waiting for:

In other news, the community has been working on various art presentations, inspired by the world of FOnline 2238, but we shall leave this for another update. Merry Christmas and see you again with the next update just before the 2010 ends!

FOnline: 2238 among 100 best indie games 2010

2010-12-01T18:59:00.004+01:00

Even in 2010, FOnline: 2238 has managed once again to find its place among the best indie games of the year. We have made it to the top 100, being placed in the Massively Multiplayer category along with "MoonForge", thus reaching the second voting phase.

Although it already was a great success for this game to be chosen by the players to be the 4th best indie game in 2009, thus winning the unofficial title of the best released indie title in the same year, it would be honour for everyone - the faithful players, the lazy developers, the corrupted game masters, the bizzare community - to confirm how rock-solid FOnline: 2238 is.

Moreover, I would be personally more than happy if all of us could show it to the current game industry that fun and gaming is not always necessarily pegged to shiny graphics, furious action, sheer amount of explosions or unstoppable corporational propaganda channeled through the modern video gaming "journalism". This is a good opportunity to send them a message that the fun factor is determined by players themselves and not by in-the-face served products and biased reviews. Come on you apes, you wanna live forever?! (Jean Rasczak)

You can vote for FOnline:2238 on our ModDB/IndieDB profile pages. There is exactly 12 days, 23 hours, 05 minutes and 47 seconds of time at your disposal (and counting).

As always, thank you for your support.

Community strikes back

2010-11-01T17:19:00.016+01:00

The creativity of our faithful community can't be hindered, it can't be disputed. That very same creativity gave the birth to the new fan video based on the world of FOnline: 2238 - On the Way to Broken Hills by Cryofluid.

It is just too cool not to put it here. Enjoy! (High quality versions can be found here)

Changelog 30/08/2010 and Server Wipe

2010-08-30T22:28:00.000+02:00

The summer is over, bugs have been fixed, features have been added. Also the server has been wiped and it is needed to create new characters to play again. In the following, the new changelog can be seen.

FIXES:
- Many.

FEATURES:
- Repairing cars requires tools and more skill than previously.
- Zooming is now possible by holding the Z key combined with using the scroll wheel on your mouse, or alternatively pressing page up/down.
- ~disbandparty away_team can be used to disband only party members that are outside of your current map (not location).
- Followers will now automatically reload their weapon while they are idle (this assumes they have spare ammo of course).
- Added active Vault City turrets.
- Be sure to visit the arena facility north-west of Hub.
- Having active Stealth Boy in one of active slots gives 60 sneak, while having active motion sensor (in an active slot) gives +2 Perception for the purpose of sneakers detection (it's not capped at 10).
- Get purple robes from the Children of the Cathedral.
- Four new quests (Lorraine in Audytum, Elmer at Necropolis watershed, Iguana Pete at he Hub, BoS Initiate trainer at lost Hills)

CHANGES (WIP):
- TC base countdown time has been changed to 15 minutes.
- Car prices adjusted, now works in a similar fashion to mercenary prices.
- Car left on the worldmap is visible only to its passengers.
- The travelling speed on the worldmap has been decreased.
- It's a lot easier to avoid encounters while in a car. Outdoorsman is not applied while in a car.
- Namecolorizing works only on players sharing the same faction.
- Picking up items from the ground while sneaked demands successful steal test. The weight is checked.
- Looting bodies while sneaked has 50% chance of desneaking.
- Looting containers and bodies by "take all" always desneaks.
- Sneak penalties based on fov: 135, 95, 55, 15 depending on direction.
- Widened the side drawbridges in Gunrunners stronghold, added antiblock to front drawbridge, guards will loot the bodies now.
- Reworked several drugs:
* Jet: +2 AP, -1 Ch, -2 Str, -15% DR
* Psycho: +15% DR, +1 Str, +1 En, -2 Pe
* Buffout: +2 Str, +2 En, -1 Ag
* Mentats: +2 Int, +2 Ch
* Beer: +5% DR, +1 Ch, -2 Pe
* Nukacola: +1 Ag
* Cigarettes: +1 Pe, -1 Ch
* Positive effects of the above drugs last 30 real minutes, after which time they subside with no negative effects, unless the player gets addicted. The addiction lasts for 1 real hour and reduces AP by 1.
* Only one dose of any addictive drug (or beer) is allowed at a time
- Armor Piercing ammo DT divider reduced from 5 to 3.
- Fast Shot trait works only with weapon modes that have aimed shot capability.
- Weapon changes:
* 10mm Pistol increased to 8-15 damage
* .223 Pistol increased to 25-30 damage
* Assault Rifle increased to 14-23 damage, increased to 12 shots per burst and magazine increased to hold the same number of bursts in normal and extended.
* 7.62mm Ammo increased to 12/10 damage mod
* 10mm JHP DR increased to +27
* FN FAL increased to 14-22 damage
* Combat Shotgun increased to 20-28 damage
* H&K CAWs increased to 6 shots per burst, magazine increased to 18
* Jackhammer increased to 20-31 damage, magazine increased to 15
* 10mm SMG increased to 8-15 damage
* p90c increased to 13-19 damage
* Tommy Gun increased to 12 shots per burst, magazine increased to 60
* Grease Gun increased to 12 shots per burst, magazine increased to 48
* Light Support Weapon increased to 22-37 damage
* Plasma Rifle range increased to 30
* Molotov Cocktail increased to 16-24 damage
* Frag Grenade increased to 5AP and 30-50 damage
* Flamer increased to 50-85 damage
* Improved Flamer increased to 70-125 damage

RECOMMENDATIONS:
- Update the game, make sure you receive the new DATs.

EXTRA NOTES:
- Any questions about GMs activity should be asked using overseer2238@gmail.com. The person operating this email (call him/her The Overseer) has access to all logs containing GM activity (logs are also more detailed now). He/she has been chosen from outside the GM team and his/her identity will remain unknown to anyone but the developers team. This email is now the only proper place for objections and inquiries concerning GMs.
- faction008.dat is deprecated at the time of this update. It can be safely deleted.

TO DO:
- Overhaul of the npc factions: Domination Wars, Factions Scenarios.

Changelog 25/03/2010 and Server Wipe

2010-03-25T20:15:00.001+01:00

The third time in 8 months of time, the server has been full wiped, due to client and server improvements and a fresh game economy. Also the game server will be pleased with a big content update, which includes new jobs, quests and other game mechanics. Read the full changelog below:

FIXES:
- Doctors check for poison and radiation level properly.
- Fixed waterpump in scrapheap base.
- Fixed timeouts for 'upgrades'. Check how they behave with deteriorated/broken items.
- Item dismantling not possible during combat.
- Day pass bug - day pass was becoming obsolete after bartering with some trader.
- Fixed many follower-related bugs.
- Fixed Bonus Rate of Fire.
- First aid and Doctor impossible to use during turn-based combat.
- Fixed about 70-80 more larger or smaller bugs.

FEATURES:
- We introduced the first 3d models from Interplay's canned Van Buren. These are among others: Rats, Desert Stalker, Radtoads, Deathclaws, the Venus Mantrap and more.
- There are now a few mining locations, where it's possible to mine ore and minerals.
- Abandoned mines are for sale in certain places.
- It's now possible to trade (give) slaves to other players.
- Random fetcher quests, currently only available from Monte Carlo in Boneyard.
- New quests available in Hub bar, speak to Risto.
- New job available, lifting boxes at local caravans in a number of towns. The job is tough, but the caps are good.
- Certain locations are colored by their function. For example, faction bases are blue.
- Green contours for followers (note: they are still red right after being spawned. Relog helps).
- Some new locations, explore. Smiley
- Some treasures are now hidden in the game world.
- Three new faction bases added (2 generic, 1 via quest).
- One new car is added.
- Added NCR Ranger armor.
- Various encounter and city maps overhauled.
- Added barbers to at least Klamath and Vault City (Changes male hair between short and long. Visual needs to be "refreshed" with armor change.)
- Holodisks can now be used to read and store data.
- Doors can be smashed by producing an explosion at most one hex far from it. Metal doors may require more than one attempt. Doors in towns will regenerate in 30 minutes.
- Various new quests:
* Some basic stuff for starter.
* Abandoned Bunker, Scout in Junktown.
* It came from the desert, Dr. Wong in San Francisco.
* Stranded Rust, Trapper in Klamath.
* The sad wife, Woman in the Hub.
* The Rail Line Gang, Gunther in the NCR.
* Medical investigation, Dr. Andrew in Vault City.
* A Man's Job, Hammilton in the Boneyard.
* Montag's Water Pump, Montag in the Boneyard.

CHANGES (WIP):
- A lot of item prices are adjusted.
- New instanced starting locations.
- Reputation gain for selling items at traders.
- Player can send distress calls only for 10 minutes of encounter map lifetime. Every player who dies on visible encounter forgets the location.
- New/modified TC again. Closely follows this suggestion.
- Added ~timeouts command to toggle showing of nonzero timeouts on the screen.
- Suicide command (works only when you're knocked out): ~cuttheveins .
- Limit for a sum of all profession levels increased to 4.
- Sneaking:
* Sneak penalties for angle are no longer reducing the skill by a percent of total amount, but are substracting 0, 25, 50 or 75 points from it, depending on the look direction (back, back-side, front-side, front resp.).
* When the check for seeing a sneaked opponent is being done, observer's field of view is reduced (for the purpose of checking this one opponent) by 50%, 40%, 20% and 0% depending on the look direction.
* See change for a Ghost perk too.
- Flagging and flag-related issues:
* Flags are retained, but no longer visible for everyone. All flagged individuals are valid targets.
* Stealing: guards won't attack the thief, he will be flagged if he either fails with stealing or is spotted by them, they will say if he is. The victim will be informed in such case in the log.
* Blocking: guards won't attack the blocker, they will be fine with giving warnings and flagging him. "Pushing" option has beed added, temporarily accessible only via alt+click menu (the followers menu). It will move the blocker by one hex from the previous position (one has to be on a hex next to his and the blocker have to be formally flagged as blocking).
* Attacking, holding explosives: same as before.
* Wielding weapons and drugs: guards reaction time increased to 15 seconds.
- Ghost perk: 30% sneak bonus instead of 20%, added everytime the check is made. Can increase the skill above 300%.
- Critical tables reworked again. They are now in the middle of vanilla FO2 tables and pre-wipe tables.
- Slightly decreased impact of luck on aimed critical hit bonus.
- Cumulative timeout for gathering (up to 20 minutes).
- Weakened timeout after first aid, no xp for removing it.
- Tent garbaging delay increased to 4 weeks.
- Gangs with their bases are being removed after 4 weeks of not being used (terminal not accessed by a member).
- Slaves are not counted towards encounter scaling, and other followers have two "free" slots, so each follower above that limit counts as player.
- When entering wasteland from worldmap, player may face random encounters too (with twice as small chance as normal wandering).
- The crafting mechanics have been reworked. This includes shortened timeouts, cumulative timeouts (20 minutes), high/low quality materials and lower prices.

VANILLA INHERITED CHANGES:
- Several improvements to the server performance and stability.

IMPORTANT:
- Use the Updater to get the new client and game files. After the update, you have to login at least once in order to regenerate the default.cache file. If you just see burning people, restart the client.

Jumping into the 3d era

2010-03-06T11:29:00.002+01:00

FOnline: 2238 Announcement, Jumping into the 3d era
(or: how we learned to not be that flat anymore.)

A long time has passed since we released our last developer video and really, it was about time this changed. The new developers video features a topic that we have been working on for some months and we are proud to finally have it in a shape to present it to the public: 3D models.

We decided to move the FOnline engine from a pure 2d to a 2.5d engine, due to the fact that sprite editing is a long and tiresome job. With every change on the player characters, it is nesaccary to edit more than 10.000 single images, even if it's something simple like a different hair color or a new armor type. The use of 3D models helps us in developing more and diversified content in a shorter timer span and still keep the look and feel of the original games.

After the release of the first 3d model converter for the Van Buren models (Van Buren - the code name of the cancled Fallout 3 by Interplay, for the ones who don't know it), we thought it was a great idea to reuse the material we could get out of the tech demo that has been released in 2007. Even if not complete, the build featured character models with already more than 90 animations and a lot customisations for body type or hair and beard styles.

In the third developers video, Anton "Cvet" Tsvetinskiy, FOnline main programmer, is talking about the details of how the new 3d critters are working and will work in the future of FOnline: 2238. Check it out:

Videos & Audio - FOnline: 2238 Game - Mod DB or YouTube.

The first update-wave will introduce 3d models for the animal creatures, such as models for the rats, ants, venus mantrap, thorn slinger, desert stalker or the lovely rad toads. Also a big content update is going to hit the server, which includes new game features and quests for both, PvP and PvE-friends.

In combination with this, the server has to undergo a full wipe. This will happen in approx one or two weeks at most, when the update will be available on the public server.

As an appendix, beside the video, here are some actual ingame screenshots:

- Cvet & Rotators

ModDB awards 2009 - We've made the 4th

2010-02-06T21:29:00.003+01:00

The ModDB awards for the best indie game released and unreleased in the year 2009 are over now and we've made the 4th place! It's not that bad to loose against Natural Selection 2, Overgrowth and 0 A.D. to be honest.

Thank's to everyone who has voted!

Donation info

2010-02-03T13:14:00.002+01:00

Hello,

We decided it's a time to clarify a bit more on the costs of server upkeeping. When we moved, we chose to acquire fairly cheap server, because we knew that server application requirements are not high. We've run into few problems at the beginning, but now we think it serves us pretty well (just to remind, server application unstability is not caused by the hardware).

So, the monthly fee we need to pay for the machine, is 60 euro (including PayPal fees). We've paid for 3 months, and we are running it 2 months already. So far we've gathered 93 euro, so we need a bit more.

That's why we are kindly reminding you to donate few caps from time to time.

New FOnline: 2238 installer released

2010-01-09T18:31:00.002+01:00

No more complicated procedures, no more installation of additional software in order to keep everything in one place and updated - the FOnline: 2238 Client Setup is here at last.

The setup comes with the Launcher application included, which provides viewing changelogs, one-click update to the latest version of the client as well as simple configuring of your game preferences. The setup is extremely easy to use, intuitive and user-friendly, thus we hope our users will find it very useful, especially our new players.

Currently, you can download the installer from ModDB (preferred) or our server:
ModDB
FOnline2238.net

We would like to thank Mr. Wolna for helping us with the launcher.

ModDB awards 2009 - Vote for FOnline in Phase 2

2010-01-06T17:50:00.009+01:00

After passing the initial voting phase, FOnline: 2238 has reached the second voting phase and is competing with other famous indie titles for the title "The Best Indie Game of 2009". We are currently among the Top 100 Mods and Indie games. As always, we count on your support and hope that the word about FOnline: 2238 will be spread throughout the cyber-space in the time to come.

Feel free to visit the ModDB website again and vote for FOnline: 2238 - just click on "Indie Games" in the TOP 100 BEST RELEASED MODS & INDIES and confirm your vote once you see the name. Your votes will have more influence on the final result if you are registered user and if you are logged in when voting. The 2nd voting phase has started!

....Aaaand up

2009-12-27T10:41:00.005+01:00

Hopefully, everything is up and running and it will remain so.

Remember, you need to run Updater even if there is no changelog whatsoever. Client exe needs to be updated.

www.fonline2238.net

Server waking up

2009-12-27T10:19:00.002+01:00

We've finally managed to overcome technical problems. Without diving into details, basically - HDD had given up the ghost. We (I mean, lazy French technicians squad) needed to replace it in the middle of Christmas...

But now we're there again, for now only forum + wiki, but FOnline server is going up in a minutes.

And let's hope it won't happen again. Why should it? In the meantime, check the post beneath this one. And vote.

ModDB awards 2009 - Vote for FOnline

2009-12-26T22:49:00.005+01:00

Traditionally, year's end is the time for ModDB to start their famous 'Mod of the Year' awards. This includes everything concerning the entertainment software released in the 2009 by non-corporate teams: mods, indie games, home-brewed additions and much, much more. Everyone can vote for their favourite piece of entertaining bytes, and we would like to use this opportunity to call our faithful community to join us over at our moddb profile and vote for FOnline: 2238.

The prizes provided for the best titles in 2009 may prove to be an additional motivation for any development team out there, including Cvet and Rotators. We thank you in advance for your support and wish all of us together to achieve something that we can be proud of.

Awards. Awards never change...

Problems with the new server

2009-12-24T20:36:00.004+01:00

Yeah, as you guys could see already, we have some bigger troubles with the server once again. Not the greatest time for this, especially because it's christmas now and time is not available en mass. We hope to get the server running again as soon as possible, but we are very dependent of the support, and the support is a bit... yeah, slow... right now.

That's the status in the moment.

New server, new forum

2009-12-22T23:25:00.003+01:00

Our new server IP is 94.23.237.127, port as usual 2238.

We have set up new domain as well, altogether with our new forum - visit http://www.fonline2238.net/forum/

Thanks to everyone for their donations - moving to a new server and starting our new forum would be impossible without those.

New FOnline: 2238 Forums

2009-12-22T00:05:00.005+01:00

A small announcement beside all the other stuff: We have been working on a new forum now for some time, and now we are ready to release it. The NMA forum will still be open for a while, but soon locked, when we think it's the right time.

The new forum can be found here.

PS. Comments on blog are from now on disabled.

Update for client, but manually (Updater still bugged)

2009-12-11T21:55:00.004+01:00

Since our updater is still buggy and we wait for it to be fixed by the FOnline engine developer, all we can do is to provide you the files which you will have to download and place into your client folder manually. The first mini-update for your client is here (direct link) or here (download page).

Back on old server

2009-11-22T14:04:00.000+01:00

We are back on the old server:

IP: 94.103.87.42
Port: 2238

How to get the client working after wipe

2009-11-21T12:31:00.001+01:00

Hello!

It's been a quite hectic wipe and we were forced to relocate to our backup host (213.170.70.111:2238). Many people have trouble getting the client to work.

If you follow these instructions it should work:

1. Run updater to grab factionXXX.dat files (with ip 94.103.86.46, port 4040)
2. Delete all cache files except default.cache
3. Download http://www.mediafire.com/?fefoztn1wrj which contains the new exe
4. Insert correct IP:Port into config tool (213.170.70.111:2238 right now)
5. Run the game.
6. Login (with default login and password, does not matter) and wait, then go to register

Last step is important, login first, then register. This is because the 2238 content is downloaded then.

Good luck!

The Wipe is upon us.

2009-11-21T01:13:00.004+01:00

The wipe will be happening shortly after this post. A full changelog has been posted over on our NMA subforum.

We thank you for your patience, hopefully you will see just how much work has gone into this series of updates and that will act as some form of explanation for the delay.

Hope you enjoy the changes.

-Solar

Features being added. #2: Its the Economy, Stupid.

2009-11-12T23:39:00.008+01:00

One of the areas of greatest change will be the economic system that operates in 2238. Hopefully the days of near infinite wealth flowing in from exploiting Caravan encounters will be over. Here are some of the aspects that will be changing on the update.

The first difference will be in the Caps. The game world will contain only a finite number of Caps and these will cycle around between Players, NPCs and the Banks. This allows us to control things such as Brahmin and Slave trading, Bank Interest and other Caps based methods of making money to ensure there is no run-away wealth generation from these.

The next difference comes in the Traders. They will no long restock with items, they will begin with inventories partially made up of items and partially made of Caps and from then on no further items will be created by them. Overtime these traders will fill up with player created items and we will have an economy truly driven by the players.

In addition to this Traders will have preferences for items that they specialize in, both in terms of how much they are willing to pay for an item and in deciding what kind of things they will keep in their inventory. It is better to sell your high tech items to Traders specializing in these, rather than your local Bartender, for example. This should help ensure that there is a valid market for each type of item and that Traders have appropriate inventories. (no more Doctors full of Mausers and Radios)

The final area that I will talk about today is how Encounters will change. Essentially, there will be no noticable change to the Encounters except weapons gained from there will be in a bad condition, which has been the case before. In addition to this all Encounters will be "paid" for out of an "Encounter Pot" which has a finite value that is refilled periodically. Therefore if it has been particularly busy and some Caravan Encounters have given up lots of resources, if the "Encounter Pot" is so small that it can not afford to fund any more expensive Encounters, only the cheaper type of Encounter will be available, until these can not be paid for in turn, after which only Encounters which have no equipment to be paid for will be avaialble (Encounters vs Animals, generally).

While Crafting/Trading for Crafted items will be the primary way of arming oneself, Encounters will still be a viable way of making money. Although they should never become the get rich quick features of the past months.

Hopefully this has enlightened you all a little on the direction the economy will be heading in post wipe 2238 :)

-Solar

Features being added. #1: New crafting items

2009-11-11T00:34:00.003+01:00

Well, despite the apparent lack of updates in recent weeks, we have been working away behind the scenes getting several quite large updates to the game ready. I'm sure some of you may even have heard there's a wipe on the way (!) :P.

In the lead up to this great event we will be talking a little bit about some of the new features at different intervals and I thought I would get the ball rolling by posting up a few details about the new crafting system.

One difference comes in the way that raw materials are gathered, or more specifically the timeouts for this. Instead of each facility having a timeout, there will now be a personal timeout that can be seen in your PIPboy. These are generally longer than the old facility ones and are designed, both to give wealth at an acceptable rate and to allow lots of crafting-free time for players to go out into the world and interact with each other.

The other main difference is the amount of items that are craftable. As will be discussed in a later entry, Crafting will be the primary way for items to enter the game world and so Crafting has expanded to reflect this.

Some of the items will have alternative raw materials added at a later date (drugs, advanced armour etc), but for now we will stick with what we have already

Item List

Hopefully the next subject will focus a little more on the large changes to the game's systems, but allow this post to whet the appetite.

- Solar

The Wiki-Boy 2000

2009-11-10T11:02:00.002+01:00

Time for a new and very short blog entry. This time we want to point your eyes to the Wiki-Boy 2000, a wiki about FOnline: 2238. It's still pretty empty right now, but thats the reason why we made this blog post. We would be very happy, if our players would contribute to it, because we (the dev-team) doesn't have very much time free for spending it on the wiki (but this doesn't mean that we don't watch it).

On another note, we want to post some more details about the upcoming game changes soon. Be prepared.

Comic Art Galore

2009-10-21T18:40:00.007+02:00

Kick-started by other FOnline: 2238 related comics, one of our passionate players known by his forum nick as Ewgen Kosec decided to put his in-game impressions onto a blank bitmap background in a rather interesting artistic fashion. All we can say is: more, more!

The Orphans' Chronicles

2009-10-15T18:47:00.005+02:00

Time to honor some community-work! User Cryofluid is posting every now and then new comics of the The Orphans' Chronicles (one of the ingame player-driven factions) on our sub-forum at NMA. It's pretty cool stuff, you should check it out.

Problems with updated client

2009-10-14T18:17:00.005+02:00

Probably most of you have already experienced connectivity problems after the latest client update. The client update was not synchronised properly with the server update due to some technical reasons, which affected your connection to the server in the worst possible fashion - you have probably gotten the "The network reports your client is an incorrect version, please update the client."

Thanks to some of our helpful forum members (gali, He Man, Ca1n) who have kept the executable files from the previous client version, you can revert your executable from:

http://www29.zippyshare.com/v/68455088/file.html From gali
http://rapidshare.com/files/291998867/eXes.rar From He-Man
http://rapidshare.de/files/48508137/FOnline.rar.html From Ca1n

More info about the whole issue on the forum.

We will try to synchronise the updates as soon as possible, so you can keep playing after updating the client using the official updater.

Thank you for your understanding.

Old server back online

2009-10-04T03:03:00.003+02:00

The old server is back online:

IP: 94.103.87.42
Port: 2238

By the way, thanks to all who donated some money!

New (temporary) server data

2009-10-01T10:52:00.004+02:00

Important news for now, we have a new server address:

IP: 213.170.70.111
Port: 2238

Regretably, we had to move to a temporary server because of hosting issues. We will see for how long we stay on this server. The data has been transfered successfully, no characters are lost and world is also preserved as it was on the other server.

Prepare for lags and maybe often server downtimes. This server is just temporary and doesn't have much power.

Another info: The update tool will not work now. But you can grab the latest version of the faction003.dat here.

New big update

2009-09-26T13:15:00.012+02:00

We've got a big update yesterday night and because it is very much, it will be posted here in full too:

FIXES:
- Attacking player that is in 'entering' mode should no longer initiate his combat mode.
- Fixed Hub-stuck-bug (hopefully).
- Many other map fixes and changes.
- Added guards to Frisco tanker.
- Added guards to Gecko Powerplant.
- Added more entry points to Gecko.
- Modoc, Mariposa, Gecko, etc. are bigger now on the borders.

(SMALL) FEATURES:
- It is possible now to buy brahmin caravan cars (Frisco, NCR).
- Brahmin caravans run on water. You can obtain water from water pipes in various towns. Just use empty waterbags on them.
- Disassembling weapons/armors (use your science, similar to how you'd use repair. Bonuses from tools apply.).
- You can now order your slaves, mercenaries to join the town garrison in any town that your faction controls. You can also dictate which laws should be enforced in this town, these laws apply to EVERYONE, even the controlling faction, and the guards won't hesitate to attack even the master. His loyalty lies with the town after joining the guard force.

CHANGES (WIP):
- Dog mercs are a bit stronger again.
- No timeouts for mining spots
- Added 'overweight' limit for gathering resources
- Each resource object acts separately
- Experimental visibility/sneak changes:
a) field of view (press Q to check it), affected by obstacles
b) opponent's sneak skill suffers penalty:
* -90 when directly looking at opponent
* -60 when looking from frontsides
* -30 when opponent is in backside area
* no penalty for 'behind' hexes
c) penalty: 1 point per 200 gram of equipment carried

- Eyeshots are automatically demoted to headshot if target is not in direct line with attacker
- Doubled jet initial effect time.
- Empty hypodermic needles shows after stimpak usage (50% chance).

RECOMMENDATIONS:
- Use updater to get faction002.dat!

VANILLA INHERITED CHANGES:
- Stealing timeout: 30 seconds, lockpick timeout: 2 minutes
- Fixed stealing experience values and dir modifiers
- Demolition expert bonus explosives damage (it's currently not connected to the demolition expert profession though)
- Chance when walking over the mine to avoid explosion: 50% unless you've got light step perk
- Pathfinder perk worldmap speed bonus (25% per level)
- Bonus yielding items such as toolboxes/first aid kits/doctor bags have to be equipped in active slot while using appropriate skill
- Defusing active explosives with traps skill

Remember: The activated FOV (Field of View) is just for testing purpose. It will be tweaked and adjusted and everything else in the next updates. Also we already found some bugs, like chopped trees that turn into caravan cars, etc. We are aware of this too and fix this with the next update(s).

And one important thing too: In case you missed it, we have a PayPal-donation button now on the right side of this blog. If you like FOnline (TLA or 2238), we would be very happy if you could donate some money for keeping the server running.

Powered by Online Quest.

Event: Treasure Hunt

2009-09-16T10:57:00.006+02:00

Yeah, next event announcement (and the first one here, in fact). Like the one before (New Reno Fight Night) is this a kind of fun event because we need more variety in our lifes. Thats why we now make a ....

... Treasure Hunt!

What is this?
The Treasure Hunt is a kind of fun event. You are running around, trying to find NPCs, need to talk to them and run to the next, etc... so it's pretty easy in fact.

Where is it?
The event will start in the Hub and reaches over the whole worldmap. You will move from one location to the next, until you reach the final checkpoint. If you reached the final checkpoint, we are waiting there with beer and booze.

WHEN is it?
The event will be probably next saturday. The time is not set yet and also it is possible, that the event might move a bit when it comes to the starting time. It all depends on wether we can clean up the last unsure things or not. :P

What is the prize?
The first prize will be a shiny new... rusty old car. Additionally the wasteland surivival gear that will be not yet listed in detail. Also you get 10,000 caps!
The second prize gets only 10,000 caps and the third prize 5,000 caps.

How does it work?
Like written above, it is pretty simple: The start is in the Hub. From there you need to talk with a npc. He will tell you to what town you need to move next. There you have to find the next npc, talk to him and he tells you your next target, where you have to find the next npc, etc. The first one who enters the final checkpoint wins, then the second one, the third, etc.

Rules.
In fact, there are not much rules. The only thing that is 100% and for sure not allowed, is to use a car or camp npcs and shot other players there.

UPDATE:
Small update on this. I am sorry to say, but we need to move it into the future.
Reasons for this: We've got not enough time in the last few days to finish it. Also some of the GMs will not be available for the next time. It's not clear yet, when the next date for the event will be.

About red question marks

2009-09-15T10:49:00.011+02:00

A lot people got problems with red question marks in several maps. This was a bug regarding new graphics, but is fixed now. You just need to use the Update Tool to get the new Faction001.dat - then everything should work again. The final patch needed so much time to do because we actually needed to find out first why it didn't worked before.

The situation is clear now and we know how to avoid this in future.

Also the last changes in total:

FIXES:
- A lot map fixes
- Guard script fixes
- Encounters items deterioration revisited
- Fixed geiger counter text messages
- Tracking roll fix:
--- trackerRoll < trackedRoll + 25: tracked gots message that he's followed
--- trackerRoll + 25 < trackedRoll: tracker looses track
- Ghostfarm production facilities fixed
- When you logout on the worldmap with your followers, they shouldn't disappear anymore.
- Production facilities buffer again (it was entirely different issue, should be fixed now)
- Follower corpses are removed now properly after 10 minutes
- TC reward containers should be openable even if someone deliberately locked them.
- Faction001.dat fixed. Use the update tool to update it.
- weakened timeout can be now ended using doctor skill.

(SMALL) FEATURES:
- Added new graphics
- Changed Broken Hills a bit
- Remove flagging in the specific location where the crime was commited based on time, 60 min+5 min*level currently.
- You can only sneak when not seen by other players. (You can enter sneak mode if seen by your teammates.)
- The primitive tool has now its own inventory image.
- The old shovel has now its own inventory image too.

CHANGES (WIP):
- Travelspeed increased on the worldmap.
- Only "good" drugs (stimpaks, radaways) are allowed to be used on others
- Timeouts aren't dropped when player is revived
- Default respawn time for NPCs which don't have it assigned is 10 minutes.
- Lowered the level of dog mercs.

New Update Tool released

2009-09-07T00:43:00.005+02:00

Server has been updated again.

FIXES:
- Fixed breakage count of items in encounters
- A lot map fixes, just like always
- A lot script fixes, just like always²

(SMALL) FEATURES:
- Added a new quest in the north of the wasteland, by RoadWarrior!
- Tracking feature activated

This time you also need to download the new Update Tool. It is needed for easy updating of the client files. You can grab the tool here. Extract the archive into your FOnline client folder and run it.

PS. Update is NOT needed. This tool is for the future updates. And yes, 4040 is correct port.

Client Update #2

2009-09-05T20:49:00.003+02:00

The client has been updated. In order to continue with playing, it is needed to download the new patch. Installation is simple as always: Download the file and copy everything into your FOnline Client folder.

The archive includes also the latest patch. So if you are new to FOnline: 2238, you don't need to download the last patch.

A changelog will follow soon.

Client Update #1 + Server wipe

2009-08-30T05:19:00.006+02:00

For all who still don't know what happened: The server got a full-wipe this night due to a new database system. First it was just planned to wipe everything except the character accounts but well, most people 'required' a full wipe and this was ok too to us, especially because of a shattered economy from bugs and exploits.

With this update, we are also running with the latest engine version again. In the following a list of the actual changes:

FIXES:
- radiation/replication stat bug
- wandering critters shouldn't go too far away from their home positions
- Bags for mercs re-enabled
- Added fixed status to repair table quest.
- unlimited brahmin followers bug fix

CHANGES (WIP):
- player can now obtain many professions, but total level (sum of all acquired professions) can't be greater than 3.
- new encounter maps
- Traders get more money now
- Boosting Ammo produced by 3
- Players can see when someone is searching their pockets with steal (same check as guards)
- Dynamite and plastic explosives lowered on traders.
- various map updates

The most important of this update: You need to download a new *.dat file and copy this file into your FOnline client folder. You can download the file here. Put the faction001.dat file into your FOnline client folder and that's it. The file is only a few kb small, so it is really not a big deal. It is very important that this file is in your client folder or else you will see missing graphics in some maps.

Forum online

2009-08-18T09:55:00.002+02:00

Just a small information: We got a subforum on NMA now. You can register there and give feedback, post ideas or discuss other stuff and so on and so on.

How to check server status?

2009-08-17T23:37:00.004+02:00

Here's the web address where you can check the status of the FOnline: 2238, as well as the FOnline: The Life After server:

Server status

Just click on it and that's it. We hope this will be helpful to everyone.

FOnline: 2238 Manual available

2009-08-17T00:22:00.006+02:00

It's done: a few minutes ago our manual for FOnline: 2238 has been finished and can be grabbed right away! Also a short Additional Notes file for printing is available. The manual is 63 pages blong (4,19mb) and includes practically everything. It was based mostly on the original Fallout / Fallout 2 manuals and adds all new FOnline informations.

You can grab the files here:
FOnline: 2238 Manual
FOnline: 2238 Additional Notes

How to get music in 2238

2009-08-16T14:09:00.004+02:00

You cannot hear any music in the game? Then do the following:

Copy the /music/ folder from your Fallout 2 installation or CD and paste it in your FOnline Client /data/sound/ folder.

That's it. Now you should be able to hear music ingame.

Open Beta Test #3: the first 12 hours

2009-08-16T12:30:00.003+02:00

Finally, the OBT3 has begun.

It arouse a massive interest for the game, resulting with numerous players downloading the client last night and trying to log in. This caused noticeable lags and ruined the game for some players who had less luck than the others - dying in random encounters was just one of the issues.

We are currently working on resolving them. The hardware seems to be quite overloaded, causing the abnormal lag peaks. This is due to the fact that some of our features are very complex, yet they have never been tested massively. This is the perfect opportunity to test them together, so that we may investigate any possible problems that could choke our hardware right now.

Thanks for understanding this delicate matter.

Keep testing, the game needs to be brought to the point where everyone can enjoy it.

FOnline: 2238 starts today!

2009-08-15T16:25:00.012+02:00

Dear wastelanders! Thank you for gathering today, on IRC, on this Blog... Wherever you are! Today the third open beta test is going to start!

FOnline: 2238 is not the only game you will be able to play - our brethren from all over the world, who were working hard on another game, The Life After, will launch their servers today too. Everything you need for playing the game, as well as any news regarding the client and servers will be published on this blog or the official FOnline Homepage.

We still need some time to bring everything in order before launching the game, please be patient.

We apologize for not releasing the 3rd Developers Video before the launching date, it will be recorded soon. To make it up to you, we decided to post this small comic:

FOnline irc data:
Server: irc.forestnet.org
Channel: #fonline

Our irc data:
Server: irc.forestnet.org
Channel: #2238

FOnline developers looking for voice actor!

2009-08-09T19:54:00.010+02:00

As the title says, the FOnline developers are looking for a native English speaking male with a mature, deep, strong voice. The voice will be used for "FOnline: The life After" intro, and if you are really good we would use your talent for our own, "FOnline:2238" intro movie.

Prerequisites:

Voice similar to Ron Perlman (Fallout 1/2/3/Tactics narrator)
Soundproof or low-noise room for recording
Dramatic narration
Native USA citizens have the advantage over others

Everyone interested can post in the comments or mail me at lisac2kATgmailDOTcom, subject "Voice Actor". All other mails will be deleted promptly, be sure to write the subject properly.

Poll #2 finished - what you really want to see in our videos

2009-07-23T10:19:00.010+02:00

Time to vote is up! Our 2nd poll results are (you could choose more options):

What would you like to see in one of our next videos?

Combat presentation: 220 (52%)
A small quest would be good: 115 (27%)
One of the existing factions in game 93: (22%)
Some other new feature (Banks, Mercs...): 139 (32%)
Gangs 79 (18%)

Interesting, 20 votes (4%) expressed negative feelings about videos.

The winner is "Combat presentation" and this is exactly what you are going to see soon. Thank you for your votes and feel free to take part in our next poll about role-playing.

FOnline: 2238 Developers Video #2

2009-07-21T12:23:00.000+02:00

We are proud to present our second video about FOnline: 2238. In this video we will show you the new PPC (Professions, Production and Crafting) system that plays an important role in the game.

Poll #1 Results

2009-07-21T11:05:00.003+02:00

OK, there are two weeks since our first poll hit this blog and here are the results:

Did you already know about the next open beta test on 15-Aug-2009?

Yes, I knew it. 188 (71%)
No, I just heard about it. 63 (23%)
Next open testis what..? 13 (4%)

We are glad to see you are informed about the FOnline project and would like to thank for your kind comments and suggestions. Nothing better than an active community that doesn't lose its attention span each time some bombastic game news pop up.

Thanks to everyone for voting, feel free to vote in our next poll!

FOnline: 2238 Development Team

FOnline: 2238 Developers Video #1

2009-07-10T11:20:00.005+02:00

Here's the first video about FOnline: 2238! Take a short tour through San Francisco with one of the developers and get the first impressions about the game.

Download this video in 640x480

FOnline: 2238 Press Release, 3rd Open Beta Test Announced

2009-07-08T13:25:00.007+02:00

Berlin/London/Novopolotsk/Stockholm/Vienna/Warsaw, 08-Jul-2009

The small indie development group, "Rotators", supported by the main developer of FOnline, A. Cvetinskiy "Cvet", are proud to present FOnline: 2238, the new massively multiplayer game, free of charge, based on the famous award-winning CRPG titles Fallout and Fallout2.

Bringing the single player experience into a massively multiplayer game was not an easy task. Merging the existing features with new ones in order to provide as much game experience as possible, the young developers aimed for the recreation of the Fallout world as we knew it back in the late '90s, keeping the emphasis on the alternative, unique universe and its settings. The game will remind you of Fallout 1 & 2 everywhere you go - the places, the people, the common history and the events that shook the world and keep it trembling.

Humanity, or at least what is left of it, has no time for a break. Faced with constant challenges, surviving in the harsh post-apocalyptic, post-nuclear, barren world, struggling for an uncertain tomorrow, the humans, ghouls and mutants are organizing themselves to push it through. To make it. To stay alive. Each group, each place, each organization with its own agenda, with its own ideology, fighting for their place under the scorching Sun. What they believe may be right or wrong... Who are we to judge, while striving for the same old necessity - survival?

The game adds several unique features regarding the players and their interactions, be it with other players, their respective groups or NPCs. First of all, there are groups: factions, gangs - call them whatever you like, which determine the fate of the world. Some of them are more powerful than others, some are cunning and treacherous, some even hideous. But they are there, conflicting with each other, or aligning with the policies of the greater powers - those who have technological advances, political power, are just plain bigger, or any other advantages over them. Choose your way: join your favorite group and spread their agenda throughout the wasteland. Decide for yourself how to handle the resistance - with good will or stubbornness. Respect the authorities or lead a revolution to throw them off the throne - it is your world, you decide.

If you don't feel like belonging to a group and have your own ideology, then you can take one of the numerous paths the wasteland offers. Some of them are: bounty hunting, brahmin trading, crafting, exploring and trading in general. The brand new system of professions allows you to polish up your skills and learn things you will rarely find in books, giving you a certain advantage over other players. Scavenging, gathering resources and useful items will be an inevitable part of your FOnline: 2238 life. Crafting something useful out of the gathered junk or selling it directly to your favorite vendor are just a small part of the great possibilities this game offers you. And of course, you can just take them off someone else, simply by brutally killing him/her or using more exquisite methods, like stealing. The choice is yours - and so are the consequences.

From the technical point of view, the game will bring back the good old 2D isometric perspective, with english being the only supported language. The engine supports several new features like object opacity and the PNG graphics format. The scripting language being used is the AngelCode Scripting Library (or simply AngelScript) created by Andreas Jönsson. The system requirements for the game can be considered minimal for today's mainstream computing:

MS Windows 2000/XP/Vista
56K or better internet connection
Fallout 2 CD

There are reports the game will run under Linux too (using WINE emulation), but generally we do not support it.

Due to the fact that the game is currently in its early beta stage (remember, the engine development has progressed much further and the engine itself can be considered almost fully functional), it is necessary to test the numerous features and additions. Taking this into account, the decision to organize another open beta test has been made, and the date is August 15th, 2009. We are looking forward to seeing you in the game and hearing your impressions of our creation, so that the next open test can really be a mutual pleasure.

FOnline: 2238 Developers Blog - Finally

2009-07-07T18:00:00.007+02:00

After the months of working on the new MMORPG title, that should bring the Fallout world in a massively multiplayer environment closer to you, we have finally started our developers blog.

The reasons are not trivial and pointless, not this time. Keeping track of the progress, being informed about the latest updates, introducing the new features and more - all of that will be published here. We hope that this step will help us override the distances between the developers and the gamers, and that all of us are going to benefit from this blog.

By modders, for gamers.