Are "we" looking into the possible opportunities here?

 

- e.g. possibly permanently fixing our network issues (smooth 18+ player raids)

 

As most would probably agree, HEAVILY constrained by rules/guardrails established by our current Developers, Kyp and the crew.

 

- donation driven "new content", created by Ai , e.g. we donate/pay token cost. (alongside server cost)

 

it really looks like vibe-coding / ai slop is going to disappear rather faster then we might guess.

 

obviously any commercial exploitation is off the table permanently with EA perhaps looming over our shoulders.

 

ugh, people's thoughts?

 

I've seen YT videos of : reference assets > blender > working game > multiplayer game.  workflows of 3-4 hours..

 

/flame suit on

I would not recommend trusting LLMs with touching C++ networking code (or any C++ with untrusted inputs). Could be good to help find bugs, but I think the latest shiny thing is also supposed to be super expensive to run.

I will say this:

We have been using some AI to look at some very old issues from around the time we first got a working multiplayer build, but so far it hasn't yielded much from the game client except a few switches that were designed for the 56k internet days and that sort of thing.

What i'll say about AI as a whole, however, is don't overestimate it as many business leaders are. The biggest thing that can make it work usefully is not just having it and a monkey with a typewriter who can generate code, i.e., vibe code. Prompt Engineering will become its very own discipline if we insist on this foolishness. You can indeed design great programs, but AI is programmed for a couple of things:

• Risk Aversion for the company that makes it and following relative institutional norms.
• It has a general desire to agree with the user to exploit some psychological human quirks that make us like things, the better for someone's stock price, you see?
• It will *always* take the fastest path to reward, and while it *might* solve a problem, it could create 30000 others. This is where the prompt engineering comes in.

On 9/12/2026 at 10:33 AM, Kyp said:

I will say this:

We have been using some AI to look at some very old issues from around the time we first got a working multiplayer build, but so far it hasn't yielded much from the game client except a few switches that were designed for the 56k internet days and that sort of thing.

What i'll say about AI as a whole, however, is don't overestimate it as many business leaders are. The biggest thing that can make it work usefully is not just having it and a monkey with a typewriter who can generate code, i.e., vibe code. Prompt Engineering will become its very own discipline if we insist on this foolishness. You can indeed design great programs, but AI is programmed for a couple of things:

• Risk Aversion for the company that makes it and following relative institutional norms.
• It has a general desire to agree with the user to exploit some psychological human quirks that make us like things, the better for someone's stock price, you see?
• It will *always* take the fastest path to reward, and while it *might* solve a problem, it could create 30000 others. This is where the prompt engineering comes in.

 

Out of curiosity, what issues are you trying to solve? If it's base Westwood client/server packets I have a repo where I did a bunch of netcode RE with the help of the old server source a while back that I never really did much with. Got bored and wandered off once I realized the proxy was going to be a lot more work, but I've got implementations for a lot of the Auxdata packets and a bunch of test packets.

At the time we were just asking it to finalize and look over aux packets for anything we might have missed or left unused, I believe, but right now there's some work towards the graphics and client in order to potentially create some better developer tools (or more at some point)

Well, I've attached the repo here. Had to strip out a bunch of test replays to fit the forum limit, but otherwise this is what I've got. rs_packet_logging/src/packets/auxdata is where all the aux structs are defined. mod.rs has all the general stuff like the Flags definition. I tried to add comments for any inconsistencies I found while working on it. It's far from a complete project, so it's pretty scattered, but maybe it'll prove useful.

main.zip