Uru redefined! Proposal list - add your own thoughts.

[D'Lanor]

How recent was that quote from chip? Was this about Havok or PhysX? The switch to PhysX improved performance in MOUL considerably, although by no means as much as Cyan had hoped. Hence their rather lame workaround with the child age instancing.

[Tsar Hoikas]

To be honest, you're not going to fix *everything* by hacking on the pipeline and physics implementations... I'm sure there is a lot of room for improvement in those areas, but the actual physical models might be in need of a good tweaking. The more complex a model is, the longer it takes for the physics to be calculated for it.

That's why you shouldn't make everything solid by setting it to use a static triangle mesh, after all. It's slow as molasses running uphill in siberia.

It would also be interesting to see about offsetting some of the physics calculations to the PPU/nvidia GPU. It's a fairly difficult process to get right... I have access to the PhysX Developers' Documentation, and it goes in depth on many things to consider. You might actually end up making the game slower.

[Kenguin]

I think there's one reason why Cyan didn't do what you suggest:
Plasma's concept: Client is god

So... the reason that cyan made the client god is because the client is god? That doesn't really answer my question.

But say they did want to add some filters, there's another problem (this would be faced by us if we try to add filters to what can be done):
How do you tell the difference between a cone-kick and a cone being warped around by a player using Plasma's physics (without adding huge load on the network and server)?

Lontahv is right. There is no way to differentiate between "good" and "bad" game messages. They are identical. If you go blocking specific types of message you most likely end up with a crippled game.

This isn't really as impossible as you guys are making it. Every other multiplayer game out there has the server filter out bad client behavior. Half-life 2 even has a full-blown server-side physics simulation in multiplayer games and it generally runs a lot smoother than uru.

There are three levels of filtering you could accomplish, depending on how much development effort you wanted to put in:

1. Basic permissions. A client should only be able to affect itself, and the state of client-manipulable objects. It shouldn't be able to move other clients around, or things like kerath's arch. This would also apply to the vault at large -- the variables that the client can affect should only be those that it would need to affect given the age it's currently in. If the server saw a message that affected anything else it would drop it.
2. Area of influence. A client shouldn't be able to move objects or manipulate switches and such further away than a certain distance from the current position of the client. This will avoid warping cones around that are too far away, messing with distant puzzle state, etc. This may require putting new information into uru levels (or devising a method to automatically extract them), such as "area of influence" for state variables, and so on.
3. Server-side simulation. Try to re-create the client's movements on the server and if they aren't possible (going through walls, flying, moving faster than the maximum running speed, setting nonsensical states in the vault), then drop the messages. This is what games like Half-life 2 do.

I'm not saying there's not a lot of work to be done to get these things working right, but it's also not impossible. Yes, it will probably increase server memory and processor requirements, because you have to load and process more information about the levels, but from what i've heard, the server isn't a bottleneck at the moment.

There is one architectural problem though: keeping client-server sync. If the server can "reject" client messages, you probably want the client to know so it can adjust and show the player what's really happening. Most online games accomplish this through server-is-god with client prediction (ie, the client approximates its position, but when the server sends an update, it "snaps" back to that state). Given the complex state system of Uru, and the "client-is-god" design methodology, this may not be possible. So the server filtering system needs to be loose enough such that all legitimate clients will never run up against the filter, and it will only impede obvious hack attempts.

By writing an application firewall that runs on a different server and filters traffic in real-time.
If it can keep up with the traffic then it won't be a bottleneck.

You train it in two ways:
- analyze normal traffic and set it as baseline;
- analyze abnormal traffic and store a signature of such events.

You then add rules for processing traffic accordingly.

This isn't different from current NIDS we use in IT security.

I don't think an IDS system like you describe will work properly for this application. You need to know a lot about the internal setup and state of the game in order to filter messages with any accuracy. A pattern/traffic analysis system will not be sufficient for something this complex.

Another question is, how does security fit into open source? How do other open source projects cope with that when any security implementation can be grabbed from the source by those seeking to circumvent it?

The mantra in computer security is "security through obscurity isn't security at all." This means if the only reason you're secure is because they don't see your source code, then it's only a matter of time before someone figures it out and hacks you anyway. The solution is to use algorithms and techniques that are guaranteed to be secure even if someone knows exactly what you're doing. These are usually more difficult to implement, but they're worth it.

Anyway, when uru was closed source, it definitely was a "security through obscurity" situation. Now that it's going to be opened, that's why this is going to be a much more important issue. We don't want the many internet griefers out there disrupting our experiences because of a weak client-server model.

I feel like this whole thing is a topic that needs its own thread.

[Chacal]

I don't think an IDS system like you describe will work properly for this application. You need to know a lot about the internal setup and state of the game in order to filter messages with any accuracy. A pattern/traffic analysis system will not be sufficient for something this complex.

The system I describe would work properly for this application. An application firewall is used for filtering abnormal traffic at the Application layer in the OSI or TCP/IP model, as opposed to firewalls that operate at the network or transport layer. This type of firewall will completely unwrap the packets and analyze the payload, i.e. the data sent between client and server. It goes without saying that such a firewall must be stateful. This allows analysis of behavior as I described. This is possible because the internal setup and state of the game, as you mentioned, is fully known.

This makes it possible to distinguish between normal and abnormal behavior.

Note that the NIDS example I gave was just that, an example. Most NIDS do not operate at the application layer. They do, however, analyze behavior.

[Jahmen]

Uh well OK about all the Technical stuff as to what can, might, could be done with Plasma for security to custom T-shirts. I think this thread ran a ground in technical babble.
RECAP:
1. Improve KI's functionality, texting, talk, etc... Yes we all want that!
2. improved Avatars hair, looks with options for better clothes, shoes etc... Want this also!
3. Additions & improvements to Kadish, Cleft-Volcano, Teledahn, Descent & Ae'gura City. Cyan Content! Not happening!
4. Puzzels solves being rewarded with more content to play than token stones. Though I did like the Yeesha Pages for relto.
5. New Ages that allude to the D'ni history and social structure themes, but depart into other directions of fantasy.

I'm thinking it is more about New Age content, Ideas and directions Fan Created Ages might go in than technical ins and outs of what can and can't be done. Maybe some talk about what the limitations Cyan might, can and will impose on Fan Created Art and how much code and tools and how fast or forth coming it will be given to MOOSE.

[Chacal]

We're not very good at keeping threads on-topic.

[Tsar Hoikas]

We're not very good at keeping threads on-topic.

The Moderator (as seems to be one of my many new roles) doesn't mind. Topics shift and flow, although this thread might benefit from some splitting...

[Yali]

3. Additions & improvements to Kadish, Cleft-Volcano, Teledahn, Descent & Ae'gura City. Cyan Content! Not happening!

I'm not so sure about that. Uru is being handed over to the fans. If anything, I suspect Cyan is encouraging us to expand their vision, because they simply can't.

[Trylon]

3. Additions & improvements to Kadish, Cleft-Volcano, Teledahn, Descent & Ae'gura City. Cyan Content! Not happening!

I'm not so sure about that. Uru is being handed over to the fans. If anything, I suspect Cyan is encouraging us to expand their vision, because they simply can't.

Yeah, why let those areas go to waste by keeping them static?
If additions are made in a way that repects the original age, design and background, I'm all for it.

[Jojon]

In Siberia hill runs up molasses...err...or sumt'n....

Anyway, one tiny request for the KI and KI-mail: all times displayed as cavern- AND local time, with some little markup token that allows you to type a local time into a message and have it automagically converted. Maybe even a countdown timer element.

Depending on licenses, I hope any servers with... ehm.. "extended material" won't be too secret... :P