Complete Certification Format

pushedx · 07/24/2021, 15:05

Completing a personal milestone by tying up a long-time loose end

It honestly doesn't feel like it, but it's been exactly 10 years since I first released the

project. For anyone that doesn't know or remember, the community was working together in hopes of getting leaked JSRO files fixed and working. Working JSRO files never happened at that time, but VSRO 188 files were released a few months later, and the community finally had what it desired.

Looking back, it was a lot of fun for me, and an enjoyable experience. Nowadays, I see a lot of people talk about the state of the community and just how bad it is. A lot of people feel doing things for the community is a waste because of any number of reasons I won't bother to list. However, I'm of a different opinion. I think the community nowadays is pretty much the same as it was 10 years ago. We're all obviously a lot older and more experienced now, so we might see things differently than we used to, but for the most part, I think the nature of things is the same as it always has been.

I'd like to pre-emptively address the question of "Why come back 10 years later and work on this stuff?" my answer is simple: This is what I find to be fun! That simple answer is what drove me to work on this stuff in the first place, and remains to be my primary motivation. Community recognition, acknowledgment, and thanks are always appreciated and make me feel good, but the work itself is what is truly fulfilling.

With that out of the way, I'm going to post my now fully completed certification format, and then talk about a few things I've learned recently re-reversing it. I should note, this is just an initial information thread. An updated tools thread might come later. I have revamped a lot of my old code to be more modern and streamlined, but I'm also working on a lot of things at once, so I'd like to organize the project better for community consumption first, and that takes time.

Just to note, the comments about offsets and sizes are all code generated! I did not manually type all of that out.

Native.cs

Spoiler

Code:

using System.Runtime.InteropServices;

namespace Common.Certification
{
    /// <summary>
    /// 0x41 bytes
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 65)]
    public struct NativeServiceType
    {
        public byte id; // 0x0 (0x1 bytes)
        public unsafe fixed byte name[64]; // 0x1 (0x40 bytes)
        // End @ 0x41
    }

    /// <summary>
    /// 0x41 bytes
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 65)]
    public struct NativeOperationType
    {
        public byte id; // 0x0 (0x1 bytes)
        public unsafe fixed byte name[64]; // 0x1 (0x40 bytes)
        // End @ 0x41
    }

    /// <summary>
    /// 0x123 bytes
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 291)]
    public struct NativeGlobalService
    {
        public byte operation_type; // 0x0 (0x1 bytes)
        public unsafe fixed byte name[32]; // 0x1 (0x20 bytes)
        public unsafe fixed byte query[256]; // 0x21 (0x100 bytes)
        public ushort global_manager_node_id; // 0x121 (0x2 bytes)
        // End @ 0x123
    }

    /// <summary>
    /// 0x122 bytes
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 290)]
    public struct NativeGlobalOperation
    {
        public byte id; // 0x0 (0x1 bytes)
        public byte operation_type; // 0x1 (0x1 bytes)
        public unsafe fixed byte name[32]; // 0x2 (0x20 bytes)
        public unsafe fixed byte query[256]; // 0x22 (0x100 bytes)
        // End @ 0x122
    }

    /// <summary>
    /// 0x6 bytes
    /// June 2021: Formerly 'srUnknown', this is the launcher's notice information as seen via SMC
    /// July 2021: u3-u6 have been reversed as a memory pointer assignment (GlobalManager)
    ///         0046909A | 894F 02 | mov dword ptr [edi+0x2], ecx | set u3-u6 in srNotice as a ptr to the global operation
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 6)]
    public struct NativeNotice
    {
        public byte global_operation_id; // 0x0 (0x1 bytes)
        public byte operation_type; // 0x1 (0x1 bytes)
        public uint mem_ptr_to_global_operation; // 0x2 (0x4 bytes)
        // End @ 0x6
    }

    /// <summary>
    /// 0x22F bytes
    /// July 2021: u1-u4 have been reversed as a memory pointer assignment (GlobalManager)
    ///         0046909A | 894F 02 | mov dword ptr [edi+0x2], ecx | set u3-u6 in srNotice as a ptr to the global operation
    /// July 2021: u6-u7 is actually a WORD that represents the current_capacity (observed through smc)
    /// July 2021: u5 has been reversed as the operational state flag (0 = check, 1 = open) (GatewayServer)
    ///         00412D53 | 8038 01 | cmp byte ptr [eax], 0x1
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 559)]
    public struct NativeShard
    {
        public ushort id; // 0x0 (0x2 bytes)
        public byte global_operation_id; // 0x2 (0x1 bytes)
        public byte operation_type; // 0x3 (0x1 bytes)
        public unsafe fixed byte name[32]; // 0x4 (0x20 bytes)
        public unsafe fixed byte query[256]; // 0x24 (0x100 bytes)
        public unsafe fixed byte query_log[256]; // 0x124 (0x100 bytes)
        public ushort max_capacity; // 0x224 (0x2 bytes)
        public ushort shard_manager_node_id; // 0x226 (0x2 bytes)
        public uint mem_ptr_to_global_operation; // 0x228 (0x4 bytes)
        public byte operational_state; // 0x22C (0x1 bytes)
        public ushort current_capacity; // 0x22D (0x2 bytes)
        // End @ 0x22F
    }

    /// <summary>
    /// 0x47 bytes
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 71)]
    public struct NativeNodeType
    {
        public int id; // 0x0 (0x4 bytes)
        public byte operation_type; // 0x4 (0x1 bytes)
        public unsafe fixed byte name[32]; // 0x5 (0x20 bytes)
        public unsafe fixed byte wip[16]; // 0x25 (0x10 bytes)
        public unsafe fixed byte nip[16]; // 0x35 (0x10 bytes)
        public ushort machine_manager_node_id; // 0x45 (0x2 bytes)
        // End @ 0x47
    }

    /// <summary>
    /// 0x28 bytes
    /// July 2021: u1-u4 have been reversed as a memory pointer assignment (GlobalManager)
    ///     004691E9 | 8946 14 | mov dword ptr [esi+0x14], eax | node data - mem_ptr_to_service_type
    /// July 2021: u5-u8 have been reversed as a memory pointer assignment (GlobalManager)
    ///     004691FC | 8946 18 | mov dword ptr [esi+0x18], eax | node data - mem_ptr_to_node_type
    /// July 2021: u9-u12 have been reversed as a memory pointer assignment (GlobalManager)
    ///     0046922A | 894E 1C | mov dword ptr [esi+0x1C], ecx | node data - mem_ptr_to_global_service
    /// July 2021: u13-u16 have been reversed as a memory pointer assignment (GlobalManager)
    ///     00469262 | 894E 20 | mov dword ptr [esi+0x20], ecx | node data - mem_ptr_to_global_operation
    /// July 2021: u17-u20 have been reversed as a memory pointer assignment (GlobalManager)
    ///     00469297 | 894E 24 | mov dword ptr [esi+0x24], ecx | node data - mem_ptr_to_shard
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 40)]
    public struct NativeNodeData
    {
        public ushort id; // 0x0 (0x2 bytes)
        public byte operation_type; // 0x2 (0x1 bytes)
        public byte global_operation_id; // 0x3 (0x1 bytes)
        public ushort associated_shard_id; // 0x4 (0x2 bytes)
        public int node_type_id; // 0x6 (0x4 bytes)
        public ushort service_type_id; // 0xA (0x2 bytes)
        public ushort certification_node_id; // 0xC (0x2 bytes)
        public ushort port; // 0xE (0x2 bytes)
        public int node_icon; // 0x10 (0x4 bytes)
        public uint mem_ptr_to_service_type; // 0x14 (0x4 bytes)
        public uint mem_ptr_to_node_type; // 0x18 (0x4 bytes)
        public uint mem_ptr_to_global_service; // 0x1C (0x4 bytes)
        public uint mem_ptr_to_global_operation; // 0x20 (0x4 bytes)
        public uint mem_ptr_to_shard; // 0x24 (0x4 bytes)
        // End @ 0x28
    }

    /// <summary>
    /// 0x11 bytes
    /// July 2021: p_label is actually a byte, followed by two DWORDs (0 = check wip, 1 = check nip for 0x2001 processing) (GlobalManager)
    ///     0046BD46 | 807D 08 00 | cmp byte ptr [ebp+0x8], 0x0
    /// July 2021: link_state observed by moving around the icons (0 - gray, 1 - white, 2 - blue, 3 - red)
    /// July 2021: connection_session reversed and found to be checked above the log message "server cord already established : discarding session: %d"
    ///     0046BDCA | 8B45 0D | mov eax, dword ptr [ebp+0xD] | nodelink::connection_session (GlobalManager)
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 17)]
    public struct NativeNodeLink
    {
        public int id; // 0x0 (0x4 bytes)
        public ushort child_node_id; // 0x4 (0x2 bytes)
        public ushort parent_node_id; // 0x6 (0x2 bytes)
        public byte p_label; // 0x8 (0x1 bytes)
        public uint link_state; // 0x9 (0x4 bytes)
        public uint connection_session; // 0xD (0x4 bytes)
        // End @ 0x11
    }

    /// <summary>
    /// 0x121 bytes
    /// June 2021: Created (naming convention taken from the database) (GlobalManager)
    ///     00491E66 | 75 5C | jne 0x491EC4 | _SecurityDescriptionGroup
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 289)]
    public struct NativeSecurityDescriptionGroup
    {
        public byte nID; // 0x0 (0x1 bytes)
        public unsafe fixed byte szName[32]; // 0x1 (0x20 bytes)
        public unsafe fixed byte szDesc[256]; // 0x21 (0x100 bytes)
        // End @ 0x121
    }

    /// <summary>
    /// 0x144 bytes
    /// June 2021: Created (naming convention taken from the database) (GlobalManager)
    ///     00491F17 | 75 5A | jne 0x491F73 | _SecurityDescription
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 324)]
    public struct NativeSecurityDescription
    {
        public int nID; // 0x0 (0x4 bytes)
        public unsafe fixed byte szName[64]; // 0x4 (0x40 bytes)
        public unsafe fixed byte szDesc[256]; // 0x44 (0x100 bytes)
        // End @ 0x144
    }

    /// <summary>
    /// 0x5 bytes
    /// June 2021: Created (naming convention taken from the database) (GlobalManager)
    ///     00491FC0 | 75 4E | jne 0x492010 | _SecurityDescriptionGroupAssign
    /// </summary>
    [StructLayout(LayoutKind.Sequential, Pack = 1, Size = 5)]
    public struct NativeSecurityDescriptionGroupAssign
    {
        public byte nGroupID; // 0x0 (0x1 bytes)
        public int nDescriptionID; // 0x1 (0x4 bytes)
        // End @ 0x5
    }
}

Before I start, I'd like to shout out @

for his

project (which was released 5 years ago).

While I did not look at the details of it until after I had already updated most of my work, I saw he made some advancements on things I had initially missed, such as the SMC security stuff that is a part of the certification format, but not included in any "packt.dats". I personally wouldn't go the DB route for trying to manage certification stuff nowadays, but it's still cool to see people trying new and interesting things.

I guess that leads us into the first set of changes from the original certification reversing. At the end of certification data, there's another group of SMC related security data. This data is optional, and not included in any "packt.dat", but GlobalManager will try to parse and load it if it exists.

After I realized I had missed that data, I then saw I had originally misparsed the certification data itself. Luckily, the error was such that it didn't cause any problems, but in my new updated tools, I've finally fixed that. To quickly summarize how it should parse: the first byte is 1 if there's certification data and 0 if not for 0xA003. Then, for each group of certification data (the structs listed above) parse 1 dummy byte, and then 1 byte to know if there's certification data for that group.

In my original tools, I read the wrong data type at each location, but the total number of bytes read was still correct, so that error would only result in the non-existent security data at the end from not being parsed. It's funny it worked out that way, but I can't complain.

Next, I had a few wrong data types (such as in NativeNodeLink), and DaxterSoul had those fixed as well, but nothing ended up breaking as a result just due to what was wrong and how the data after it wasn't being used for static certification. Another lucky break. I went through and track down all the correct data types of each field by checking memory accesses across the modules.

That leads me into the last big thing to complete the certification format. As it turns out, Joymax used an old school method of sending placeholder data to reserve memory, so server modules can then fill it out with their own values at runtime without having to allocate a different certification object. Typically, network protocols are designed in such a way to minimize the size of data passed around, but for something like server certification, where it only runs once per server startup, it makes for a simpler design.

The reason why my original certification worked despite all the extra unknown stuff, was because all of the unknown stuff was pretty much runtime data! By reversing each of them now, I've gotten a better understanding of how certification data is stored in memory and how the server modules use it. I know 10 years ago I was certainly aware of this approach, but it never dawned on me at the time it would be used in this type of scenario.

I probably need to cleanup a few naming conventions, but for now I'll leave things as they were, since Joymax uses inconsistent names for things as well. Fixing the parsing bugs and making a new, simpler API to work with certification data is certainly more useful than simply knowing 100% of the format, but I wanted to share it anyways to complete the puzzle.

I think the biggest surprise for me is the runtime data stuff. There are lookup pointers, which make sense, and also other misc data (in NativeNodeLink and NativeShard for example) that is only set in certain modules. I actually had 2 unknown fields I had been trying to reverse the past week before I could make this thread: NativeNodeLink::connection_session and NativeShard:: operational_state

NativeNodeLink::connection_session took some time, because I didn't quiet understand how the server modules use the NodeLink data. I do now though, but it was really easy to determine once I saw the values in memory and the server logs when I was restart connections in different modules.

As it turns out, NativeShard:: operational_state is only updated in GatewayServer, so I had set HWBPs on the data in all modules and tried to track it down. It took some time, but I finally noticed it when on the title screen requesting server stats, as I had been only testing data while logged into the server.

Since certification stuff has been working the entire time, despite the flaws, and it's not too hard to make simple tools to build certs for you, there's not much that changes from knowing the exact format. It's nice to have though, but besides just having wanted to complete this task, my real focus was trying to understand the server modules and why various certification issues exist.

For example, it's known that you need to use a tool like ForceBindIP if you want to use multiple modules on the same physical machine. My question is "why?". Why do the server configs have support for a "certification_ip_bind", yet don't bind to that IP? How can you fix the server modules so you don't have to use ForceBindIP and can just use a correct certification architecture?

I finally have the answers to all those questions and more, but they're best for another thread

That about wraps up this thread though. No promises or timelines on updated tools that make use of this stuff. Long ago I wrote a tool to create a VSRO dev server setup (as in, not meant to be run as a commercial project) using a single button click, and I'd like to remake that, as the old version was limited and for older windows/mssql versions.

That means finishing up some other tools and putting everything together in a nice package, which just takes time and a lot of testing. I needed to solve some of the cert stuff and module issues to know why the 2nd gameserver setups were so convoluted, so now that it's figured out, I can get back to doing some of the other stuff I wanted.

Mc-Diesel · 07/24/2021, 15:18

Great As Always

DaxterSoul · 07/24/2021, 19:09

Quote:

Originally Posted by pushedx

I personally wouldn't go the DB route for trying to manage certification stuff nowadays, but it's still cool to see people trying new and interesting things.

Ye the database approach was chosen because the strings list of the certification binary has been found and we wanted to match the original as close as possible. "Precompiling" the certification packet has always seemed weird to me. It also didn't allow for changing Shards Name and MaxUser from SMC.

There is/was actually a whole closed source project dedicated to replacing original modules that started with trying to replace AgentServer. The reason for doing so, was that we could avoid using a filter altogether.
Rather than having to deal with a thousand connections on both sides (AgentServer and SR_Client) we'd only need to deal with a handful of connections to the modules and the thousand clients. This means that GObj messages (spawn, walk, attack, etc.) for example are only received once from the GameServer together with a list of players that should receive the real message.
Another reason was that we'd be able to communicate with ShardManager & GameServer using the existing connection to

with them through real or custom messages.

When the framework to communicate and fully certify with other modules was ready it became surprisingly easy to build other modules as well. All you had to do was reverse engineer and recreate a few application specific message handlers.
AgentServer, Certification, GatewayServer, DivisionManager, FarmManager, DownloadServer, custom modules like BillingManager, even ServiceManager (SMC). All of their messages parsed, handlers reverse engineered and rewritten within a year.
But just because you implemented all features does not mean it's stable and unfortunately that's the boring part nobody wanted to do

.

Replace.Certification has been created as an isolated version of this for the community very early in the process thus it hasn't really seen much love ever since.

SilkroadSecurityApi also started showing some flaws you'd only see when talking with genuine server modules. For example server cord sessions marked as "trusted" or messages with ID 0x1001 are excepted from CRC, Seq. and encryption/decryption.

pushedx · 07/25/2021, 04:22

Quote:

Originally Posted by DaxterSoul

Ye the database approach was chosen because the strings list of the certification binary has been found and we wanted to match the original as close as possible. "Precompiling" the certification packet has always seemed weird to me. It also didn't allow for changing Shards Name and MaxUser from SMC.

Interesting, I didn't know that project was trying to match the original certification. I did know what slyz.exe was doing was merely trying to emulate certification though, and since I was emulating what slyz.exe was trying to emulate, it'd never actually be like Joymax's certification since there's features that I never knew about that are supported. Looking more into how sever modules actually use certification, I noticed how certification is more "dynamic" than you'd expect from what typically might be perceived as a "static" licensing protocol (which is how I initially perceived since from slyz).

In terms of simplicity and ease of use though, the approach I used for my old certification builder (unreleased) and new stuff is more just along the lines of having a few simple config files (well they could be json nowadays) where you just define the basis of your server architecture, then the certification API does the rest automagically. But hindsight is 20/20, looking at things nowadays, everything is much more clear and obvious than it was back then for me. Of course, I did original cert work before we had working modules, and then left shortly after VSRO files were released, so I never re-visited certification by reversing real modules until now.

I do know joymax parses/builds these things piece by piece nowadays, but back then, I did not know they used stream operators to serialize data. That was actually a surprise to me (as I've seen in code from devkit and other places). Since the complete certification format was never known, it was far easier to just build it into a single file that can be more easily debugged, but nowadays I totally agree that it doesn't make sense to precompile it anymore. In any case, as you know and showed with that funny video, their whole design is highly exploitable once you understand how it works.

Quote:

There is/was actually a whole closed source project dedicated to replacing original modules that started with trying to replace AgentServer.
...
But just because you implemented all features does not mean it's stable and unfortunately that's the boring part nobody wanted to do .

That's an interesting point to bring up, because it overlaps a lot of what I've been thinking about lately. Prepare yourself for some tl;dr

I think this is where I currently have the biggest perspective difference from everyone else. I actually started thinking about this a lot more over the past few months. In June I spent a lot of time reversing GlobalManager to get an idea of what it does and what it should do if I were to replace it. It's as as you said, once you understand the module design (RTTI greatly helps, as I never correctly used that information in the past), everything just starts to make more sense and it's easy to understand and get through the other smaller modules.

So, with custom: certification, globalmanager, farmmanager, agentserver, downloadserver, and gatewayserver, the bulk of understanding SRO as a game falls to shardmanager/gameserver, which are pretty hefty, but honestly since they're 32-bit modules and the size of them is only 5mb/9mb respectively, I feel confident they can be complete reversed. When I started reversing Path of Exile, the client exe was barely 7mb, and by the time the 32-bit client was de-serviced recently, it was nearly 33mb. I had massive parts of that game reversed, so looking at SRO now, all this seems very feasible.

However, what's the point? We know how so much of this stuff works now; we know most file formats, network protocols, server architecture, and client gui stuff (thanks to florian0's SRO_DevKit). We also know all there's a ton of flaws and exploits, and that all these implementations were conceived over 20 years ago (since SRO had to be fully coded before it was released in 2005, and that probably took 5 years give or take). We also know, C++ is freaking hard (not to mention modern C++20 is just so different than C++98, which is what I grew up on).

To take a small detour, I don't think most people actually remember my original security api/proxy work was all C++. The sr33/edx33 line of tools were what I initially built up around, but as time went on and I kept trying to fix stability issues and random bugs, I finally gave up and just switched to using C#. Using C#, I could write a fraction of the code, it was far easier for people to understand so they could rewrite themselves if they needed more performance, and best of all it was stable and worked (which is why I guess people still use the code despite its age and design flaws).

The reason why I bring this up is exactly what you said: "But just because you implemented all features does not mean it's stable". MMO coding is hard. C++ is hard. Trying to achieve binary compatibility with file formats, network protocols, and client/server changes is hard. Even if you were to somehow achieve all that, then guess what, you're still going to be left with what Joymax had, which is a highly flawed and exploitable codebase that needs a lot of fixes. These fixes, will require breaking binary compatibility, there's no way around it.

Updated certification stuff is nice in knowing what was previously unknown, and to help simplify some tools to build new certs to get a VSRO server up and running (as I was starting from scratch again), but the reality is, certification is just one massively exploitable security flaw, and anything "new", should not be using it as it was.

Case in point, I think the SRO_DevKit is an awesome project, but it's still just a modding project. It's always going to have its limitations because it's trying to achieve binary compatibility with an old client. However, now that we know so much more about how the client works and what it does, why aren't we rewriting the client?

Silkroad has had clientless bots since literally the beginning. A clientless bot means you don't need a client, so if you don't need a client, that means you can then use a custom client. If you know you can use a custom client, and a lot of what it needs to handle (thanks to extensive packet documentation you've maintained, for example) what exactly is the technical challenge preventing such a task? Basically nothing once VSRO files were released.

Continuing along my line of thought, if we have most of the client/server reversed and have custom modules for everything, and have a good understanding of game/shard, we've pretty much reached top-tier emulator project status. But the whole point of an emulator is to have access to something otherwise inaccessible.

ISRO/TRSRO are alive and running. VSRO 188 preserves the essence of Silkroad and allows anyone to at least play a version (there are others ofc). MeGaMaX has provided an alternative ISRO experience for years now. Silkroad has not gone anywhere after all this time despite being proclaimed "dead" since 2011, so what exactly are we all working towards?

In my eyes, the next phase of Silkroad development is literally destroying everything that makes Silkroad Silkroad, and rebuilding something up from the modernization of a lot of interesting ideas for the time it came out. However, as I've just mentioned, there's little technical obstacles remaining anymore. What does remain, is the game design side of things, and I mean real game design and not the game design gamers partake in when they wish drop rates were different or there was more new areas/skills/mobs (content).

That's why I'm of the opinion that if Silkroad source were to ever be released, nothing would change for the game. How many people in the community have the experience required to run a mmo (just look at the perception of a lot of pserver networks right now)? How many people have advanced C++ skills to actually work on a mmo project? How many people are good enough at reversing/debugging to fix exploits, crashes, and modernize an old code base? And even if someone checked all those boxes, who is going to then just manage and provide everything for the community? Not going to happen, there's only so much everyone who is capable could do, even if they all did try to achieve such a feat.

I say all that to come to this one point: why don't we make things how we want them to be as opposed to just accepting things for how they are?

Approaching things from that different perspective, now ask yourself the following question, what do we really need to reverse from Silkroad? I think the answer is "nothing". Do I care how the servers handle fortress war if I'm replacing the server and client and might not even have that feature anymore? Do I need to know the exact damage calculations for skills using pk2 data if I'm replacing pk2s and doing my own balance numbers? Do I need to solve all of the exploits for agent server packets being propagated through the network if I rewrite a new protocol that works differently?

We have the blueprints for a successful game, we have access to client/server modules to reverse "mmo technology stuff", and we all know how the game works since we've played it one time or another, and of course have an interest in it to some degree, since we take time to talk about it or even play it.

I know what I'm talking about sounds crazy to a degree, or too much unfeasible work, but I really think we've all (including myself) underestimated what we really have with VSRO files, and then have overestimated what it would take to really get what we want simply because we've been approaching things from the wrong perspective.

Having 100% exploit free, stable VSRO 188 files isn't going to solve any real problems if all anyone ever wants to do is change rates, maybe add a few basic features, but keep the gameplay the same. "Rebalancing" isn't really a viable change either. Simply adding new content to the game, isn't going to magically make people want to play the game as it was either, when it's so boring and bad people feel the need to bot the entire time just so its bearable.

I think that's why so many people view the pserver scene as they do right now. Everything has been stale for a long time now, because people just want to hold on to what Silkroad was rather than trying to explore what it can be in a modernized form. I'm not saying it's easy, but I feel like too many people are worried about "preserving" Silkroad when in reality, that no longer needs to be done.

But, this is all just thinking aloud right now, and more about transitioning SRO development into more generic game development. The real challenge isn't actually doing any of the things I'm talking about, rather just reaching community consensus on "what to fix" when it comes to Silkroad, because gamers don't really know what they want, and few have the ability to use the right words in describing why they want the things they do.

What I've seen over the years is that simply talking about ideas leads people to come to conclusions on whether they like it or not before actually giving it a try, and once someone has made a decision to not like something, it's often hard to convince them otherwise. 10 years ago, I could understand why people would resist the idea of change and innovation, but nowadays? I see no reason why most are content with 10 years ago Silkroad.

notHype* · 07/25/2021, 05:17

Quote:

Originally Posted by pushedx

Nowadays, I see a lot of people talk about the state of the community and just how bad it is. A lot of people feel doing things for the community is a waste because of any number of reasons I won't bother to list. However, I'm of a different opinion. I think the community nowadays is pretty much the same as it was 10 years ago. We're all obviously a lot older and more experienced now, so we might see things differently than we used to, but for the most part, I think the nature of things is the same as it always has been.

Dead wrong. It's not an opinion to have - it's a fact. You can see this by simply checking into the state of private servers and the actual community nowadays - how they communicate regarding servers, seeing all of the massive deals etc.

This community is hopeless - and over the last 10 years, not only has it shrunk (obviously), but along with it brought a trend of decreasing intelligence and reasoning, stability, loyalty, and more.

Overall the community is and has been on a downward spiral for years. Back in the early 10s' PSRO era, the community was simply better in practically every way you could view it. Something unique that I notice from that time period is the work ethic and loyalty of players was significantly higher - server jumping was not so normalized and frequent. Players would often stay in their private servers for months if not years, putting in hard and tireless work into their sets/weapons only for a server to slowly, eventually die out. Nowadays it's basically a trend to jump from one server to the next - certain unions/players hired to play for a certain amount of time until they quit and move on for the next "hyped up (aka corrupt) project." It's a daily occurrence for me to see counters drop from 3000-4000 to 1000-1500 after the "final fortress war."

I love the fact that people are still dedicating time to developing and bettering this game, but it will never change the fact that it is not driven by desire to grow, learn, and flaunt your achievements; it is purely a drive for money - a business. Business. This is all psro is nowadays for ~98% of teams. Even for players it is the same: a business opportunity, a quick buck off of a side hustle. For that reason, I'll never believe in the betterment of this community, on the side of the players nor the administration. It's a lost cause. If there is no more money around, this community shrinks by ~75%. It's the reality, a fact... not something theoretical. It pains me to say it but it's the truth.

sarkoplata · 07/26/2021, 20:06

My eyes literally teared up seeing you post here again. Thought it was a 10 year old thread being bumped, couldn't believe my eyes. Welcome back!

*Silverlight* · 07/28/2021, 15:36

Quote:

Originally Posted by notHype*

Dead wrong. It's not an opinion to have - it's a fact. You can see this by simply checking into the state of private servers and the actual community nowadays - how they communicate regarding servers, seeing all of the massive deals etc.

This community is hopeless - and over the last 10 years, not only has it shrunk (obviously), but along with it brought a trend of decreasing intelligence and reasoning, stability, loyalty, and more.

Overall the community is and has been on a downward spiral for years. Back in the early 10s' PSRO era, the community was simply better in practically every way you could view it. Something unique that I notice from that time period is the work ethic and loyalty of players was significantly higher - server jumping was not so normalized and frequent. Players would often stay in their private servers for months if not years, putting in hard and tireless work into their sets/weapons only for a server to slowly, eventually die out. Nowadays it's basically a trend to jump from one server to the next - certain unions/players hired to play for a certain amount of time until they quit and move on for the next "hyped up (aka corrupt) project." It's a daily occurrence for me to see counters drop from 3000-4000 to 1000-1500 after the "final fortress war."

I love the fact that people are still dedicating time to developing and bettering this game, but it will never change the fact that it is not driven by desire to grow, learn, and flaunt your achievements; it is purely a drive for money - a business. Business. This is all psro is nowadays for ~98% of teams. Even for players it is the same: a business opportunity, a quick buck off of a side hustle. For that reason, I'll never believe in the betterment of this community, on the side of the players nor the administration. It's a lost cause. If there is no more money around, this community shrinks by ~75%. It's the reality, a fact... not something theoretical. It pains me to say it but it's the truth.

In a reality of infinite truths I can't say that you are right or wrong. There is assertiveness in your statements and we could agree with many of your points but silkroad is more than just a community or a game for any dev who started his development journey with silkroad.

We are not talking about investing our time into the betterness of the community, or working for the purpose of opening a server that will have 3k players which could earn you a bunch of dirty money. Pushedx is not driven by money but by curiosity and passion for a codebase that seems silly but represents an Alice's Wonderland rabbit hole.

I always lurked around the big players and toyed with their releases and findings, so it makes me super happy to see that one of the big legends has decided to make an appearance here again.

Welcome back pushedx, I hope that you continue to have fun with these files and also making new findings. The drama that kept this place busy is gone, but with fewer drama the mood is more chill to work at your pace and not become a hype machine.

notHype* · 07/28/2021, 19:09

Quote:

Originally Posted by *Silverlight*

In a reality of infinite truths I can't say that you are right or wrong. There is assertiveness in your statements and we could agree with many of your points but silkroad is more than just a community or a game for any dev who started his development journey with silkroad.

We are not talking about investing our time into the betterness of the community, or working for the purpose of opening a server that will have 3k players which could earn you a bunch of dirty money. Pushedx is not driven by money but by curiosity and passion for a codebase that seems silly but represents an Alice's Wonderland rabbit hole.

I always lurked around the big players and toyed with their releases and findings, so it makes me super happy to see that one of the big legends has decided to make an appearance here again.

Welcome back pushedx, I hope that you continue to have fun with these files and also making new findings. The drama that kept this place busy is gone, but with fewer drama the mood is more chill to work at your pace and not become a hype machine.

Of course. The community of developers that you describe are not the ones targeted by my post, yet it’s so rare to actually see people as you described: in Silkroad for the learning opportunities, the interest of learning about the game, tinkering with what we have to modify it, etc.

However it doesn’t change the fact that, unfortunately, the mass of current developers and administrators are not just keen on innovating and having a passion for Silkroad, rather just viewed as easy money for them on a high-profit return project.

But respect to pushedx and even yourself Silverlight, I know that both of you are not in it for the profits, and there are more who are like you. What I said was never about either of you, just showing the sad truths of the scene.

pushedx · 07/29/2021, 16:20

Quote:

Originally Posted by notHype*

What I said was never about either of you, just showing the sad truths of the scene.

It's not that I disagree with you, but my point would be that it's been a truth of the scene from the very start, so nothing has really changed. It's a human nature thing that has nothing to do with SRO specifically. One of the main divisions of the world is between the "haves" and "have-nots". People like having things others don't. Most don't have any issue hording something and if they can't make use of it or profit from it, then no one else should be able to either (crab mentality). We've all seen people flaunt/brag/boast about exclusive things in all parts of life.

When a "have-not" becomes a "have", they face a decision:
1. to perpetuate the cycle by keeping things to themselves
2. break the cycle by allowing more "have-nots" to become "haves"

Most of the time, it's #1. They find some excuse to go back on everything they've ever complained about others doing in the past. They say things like "the community is selfish, greedy, undeserving" blah blah, and maybe they are right, but it doesn't matter because it's their decision. Whether it was luck or skill, they found themself in the position to make a difference, so whatever they choose, is how people are going to judge them.

Back in the day, there was 1 main public PK2 extractor, the VB6 ExtractPK2.exe. While it was released for free (I don't think it was initially leaked into the wild, but I can't be sure), it was closed source, and the devs (I don't want to drop the wrong names, so I won't drop any names) didn't want to share info on PK2s or the tool itself. They were content on being the one community with that tool, which is fine and all, but obviously the tool was limited, and wasn't getting any new features or improvements.

That was my motivation in learning the PK2 format and why I developed my first set of PK2 back near the end of 2007. However, I didn't just stop at an extractor, I also created a PK2 editor. I don't know if many remember, but back in the day before me, people did PK2 edits like "pink mobs" via hex editors and simple tools to change the file bytes. The age of real PK2 editing started after I released those tools.

I mention that story because it's just one of many and it illustrates my point. There aren't many, but there are people such as myself, who go from being a "have-not" to a "have", and rather than simply keep everything for ourselves, we desire to change the status quo. Pretty much all of my SRO work has been me shaking up the status quo from the very start. In a way, I am selfish, because I seek to destroy the natural order of things, so I don't personally hold it against anyone who disagree with how I do things.

And you know what? A LOT of people did not like me back then, because I took away their "haves" with my own, and they were no longer special and had anything exclusive. Sucks for them though, most of them faded away into insignificance, but I never cared because while it was their right to horde and monopolize, it was my right to distribute and normalize. I think a lot of people don't really know or remember how things really were back then, but everything I've said previously isn't just misguided optimism about the SRO community, but rather the same things I've seen from the very start having been a part of it.

There's a catch to all of this though, and it's something I don't think people nowadays really understand. When everyone becomes a "have", the cycle restarts and they all become "have-nots". When someone then does something new and interesting, they're the new "haves" and everyone else wants what they don't have (just another human nature thing). It's a vicious, never ending cycle.

As a result, I don't blame anyone for the perceived "toxic" state of the community, but it's the same as it's always been. People have had the same complaints since the very beginning, just different terms were used. Back in the day, it was all about the perceived "elitism" of certain devs in the community and them not wanting to help anyone else and only keeping things to themselves. Furthermore, people have been lying/cheating/stealing/scamming long before SRO days and long after. People trying to take credit for others' work or reselling it as their own, has been a problem with the internet for ages.

I myself wanted to make a difference, so I spent my own time and put in a lot of work to become that change. As a result, I've had a massive impact on the community, so it's possible for people to have a positive effect. I know personally, it'll never change though, because what we're trying to change is human nature, so I'll always remain positive about the community because I get it. I do a lot of things for fun, because I'd rather not deal with trying to do it for money. Others are different, so to each their own. At some point people will either be motivated to learn and be able to do things for themselves like I did, or not, and just be content with paying others for it. There's no right or wrong answer to this.

With that said, things won't change on their own though, so people not wanting to do anything for the community because the community doesn't reflect what they want isn't ever going to help. But, even if everyone gave away everything in existence and helped each other, there's no ending the "have"/"have-not" cycle, so what would really be accomplished? I don't think I've ever done a single project "for the community" with the expectation of anything back. Most of my posts are either too long for anyone to read, or too complicated/advanced for most to even understand, but I don't let that get in the way of being myself.

I don't really have any grand purpose in saying any of this though. There's lots of people who have done great things over the years, so I'm only talking about me in context of my own experiences with the community and why I still want to do things, despite the perceived state. If there was something more fun for me to do right now, or a game I think I'd enjoy more, I certainly wouldn't be sticking around here for no reason. I'm here because I want to be, and I'd only really ask everyone else to do the same.