It’s time to upgrade the old router. I really need updated VPN capabilities, so I can access my network while offsite at hotels, etc. Even if the hotel is not directly blocking VPN ports, IPSec has trouble passing through some routers since it uses ESP, which is a port-less protocol. “IPSec pass-through” is a feature found on some routers, but this would only work for one client on the entire hotel LAN. Basically, the first person to make a connection would be the only one who could use it. I’m looking at using SSL VPN. Since this protocol does use ports (typically 443), it will more than likely be allowed through the public router, with proper address/port translation.
Finally just about finished with the Asset Manager. It’s been partially complete for a while now. Just enough to allow clients to self update from the server when they login.
Now I have an application that can be used for more robust asset revision control. It has the ability to get the latest assets from the server share, and to send the latest to the server. Only the data that needs to be sent over the network will be transferred. There is also the concept of a “live” folder, where the current game resources are held. This can be synchronized with the share folder, when it comes time to release a new game patch. The application can also generate a new file list for the setup program. It can also zip up the asset folder(s) for backup purposes. It’s going to make life a lot easier, especially when the number of assets continue to grow!
The old setup bootstrap used to implement a fairly old Visual C Runtime. This allowed it to run without any dependencies on the platforms that we were targeting. The new bootstrap is compiled using Visual C++ 2017. However, I’ve completely unlinked the requirement for the CRT/MSVCRT from the executable! It’s built using native code, much like a kernel would be built. This way, it will start up on just about any Windows platform, without any problems. The code had to be carefully written, to avoid any use of the common runtime, and the default libraries. In some cases, I had to provide my own implementations of functions like memset(). Now, I can ensure the latest version of the Microsoft Visual C Runtime (MSVCRT) is installed before my main setup program has been started.
I also recently finished a Self Extractor for the game download. It’s basically a .ZIP file appended to a custom extractor; i.e. a redistributable executable and the compressed archive of data in one file. The game used to be distributed as a .ZIP file only, but not everyone knew that you had to extract it, and then run the ‘Setup.exe’ found within the extracted folder. Much better now!
I reached a major milestone today! The game server software suite is working again (now it’s all native 64-bit code) and successfully installed on the new server hardware. Today, I was finally able to login to the game world again for the first time in years! It felt good to see everything work, and to visit a ‘virtual’ place that I haven’t been to in a while.
I made some significant changes to the Gatekeeper code, to make it more robust and CPU friendly. There is more feedback to the system administrator as well. You might ask, “what is the Gatekeeper?” When the servers are down, the Gatekeeper is used to relay a message back to the client. Otherwise, the current authentication server connection details are returned to the client (i.e. the Been There Launcher application).
The only big problem I ran into was getting the packet data alignment and structure padding correct between the Linux and Windows applications. If you don’t already know, let me tell you, it’s a pain to troubleshoot custom network code! Everything else went pretty smooth, it was just a bunch of repetitive work and testing.
Finally finished working on this two-gripper robot. He is one of three in a machine that we recently programmed. I used some game AI on him, lol. He is pretty smart. The customer was pretty impressed.
Ok, so robots are fun to program. However, I’d rather be working on the Orion Engine right now! I do have some time-off coming up. I’m looking forward to digging into the engine code again!
I’ve been pretty busy at work lately, which has hindered my development on the engine some. However, I’m still pushing forward!
The plug-in system (used by the Orion Engine SDK, Orion Script, Orion Genesis, Been There Game, etc.) has been updated. The loader code is more robust now, and better handles invalid/outdated modules. There was a bug where an invalid module that was loaded would cause the application to give a warning and exit without the option to continue.
I’ve also been working on some of the tool applications. I fixed a bug in the OrionResultLookup application. Hexadecimal result strings were not always being properly converted to a signed result code. Thus, not all error codes could be successfully looked up. I also added an option where you can do a reverse lookup, i.e. select a result code such as “OE_S_OK” and the description, value, etc. will be displayed.
The monitor I use for my dev machine (a 52″ LCD Samsung T.V. LOL) started acting up the other day. It wouldn’t turn on, the standby relay just kept clicking. I can’t let this get in the way of development! It turns out, this is a common problem with my particular model of television. After a brief inspection, I found four electrolytic capacitors on the power supply board that had swollen up and leaked their electrolyte. No problem. I found suitable replacements for less than a dollar! Soldered them in and voilà! It works again, and still has a killer picture!
I spent a lot of time trying to figure out why I couldn’t export mesh files with the new 64-bit UNICODE version of the 3ds Max Orion Engine exporter. All of the vertices were coming out all zeros! I thought for sure it was a problem with the recent 64-bit conversion. So, I’ve been chasing around pointers and checking data type sizes, etc.
Well, I finally stepped through the HUGE exporter routine and discovered that the problem was with an attribute sort optimization. In fact the debugger stepped me right up to the very line of code I was working on when I had to stop working on the engine! I remember that small detail now, LOL. That’s why the exporter wasn’t working! It was just hitting some unfinished code is all. By disabling that particular optimization for now, everything seems to be working great again!
I’ve been working on a glitch in the engine that caused the root level bounding volume not to be created, if the node didn’t have any vertices. When merging the bounding volumes in a hierarchy, the top-level node should represent the entire object.
I decided to split the current game databases into two separate servers. I want to make sure we have great performance with all of the constant data that the game servers will be generating.
I’ve also been documenting the network topology that I currently have implemented. It’s a pretty interesting setup that I believe will work quite well. I like the way more servers can be easily added, as demand increases.
I’m going to continue working on the code for the servers this weekend. I want to get my multi-threading ideas in place before I actually bring the game back online. This, along with all the new re-purposed server hardware I’ve been collecting, should make the application run very smooth!
I’ve been going through my notes on the engine this week. There were many little small issues that I was able to mark off the list! The code is running pretty nice. Things are certainly headed in the right direction.
Fixed an issue with the Memory Manager when running on a 64-bit processor. I thought the problem was with some static variables being de-allocated before trying to access them on program exit. You see, this code is one of the last things to run on program exit in a debug build; that way we can report any memory leaks, etc. Turns out I spent a lot of time looking in the wrong place for the problem. The problem ended up being a string that was not initialized with a terminating character. Lol. The 32-bit string functions didn’t care, but the 64-bit versions sure did. Definitely not where I thought I would find the problem. So happy that this issue can be marked off the list now!
I also made the CPUID class in the system driver compatible with 64-bit. This code is a lot cleaner now, and the interface is more generic. I removed the inline x86 ASM code, in favor of the intrinsic __cpuid() and __cpuidex() functions.