Author Topic: Technical discussion of bases  (Read 49611 times)

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #20 on: May 27, 2016, 04:08:10 AM »
Actually, I'm quite impressed with Codewalker's efforts.  Though I must admit I don't partake in the fruits of his labor.  While there are many parts of the game I love dearly, and getting bases working would certain be near the top of my list, the one thing I would miss most is combat.  And, I believe Codewalker has already stated combat will never be available.  Feel free to tell me I'm wrong about combat, Codewalker.  And for that reason alone, I don't avail myself to Paragon Chat.

Depends on what you mean by "combat."  Combat as in a reasonable replica of the way combat worked in City of Heroes?  I don't think that is doable even if Codewalker wanted to do that within the implementation limits of Paragon Chat.  I mean, technically speaking there's always a way: you could implement a mapserver as an XMPP server module that Paragon Chat could connect to, but that would be doing it just to prove you could do it: it would be intrinsically harder to make Paragon Chat support combat that way than it would be to recreate functioning game servers.

I think - but I have to point out I don't think this is a specific priority of Codewalker's - it is possible to create a semblance of combat in PC.  Something that, say, a PnP GM could use to visualize combat in a manner congruent with using Paragon Chat as a graphical replacement for tabletop wargaming.  I think one day we could "see" combat, but I don't think we will "do" combat in Paragon Chat.

Ironically, given the subject of this thread, if there is anything related to combat I think might be doable in Paragon Chat, it might be some simplified version of base raids.  Simplified people vs geometry combat in small instance room just *might* be within the limits of what Paragon Chat could do, for a number of reasons.  For example, message frequency might be tunable faster in base rooms with small numbers of people.  For another thing, geometry doesn't move.  Moving thing vs stationary thing combat is a somewhat less intractable problem than moving thing vs moving thing.

It goes without saying (but I feel compelled to keep saying) this is just informed speculation.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical discussion of bases
« Reply #21 on: May 27, 2016, 04:24:17 AM »
There are different levels of combat as well. Combat that only affects things locally on a solo instance is an entirely different beast than combat that other people can join in or witness via XMPP. And that might be enough for some people, so who knows. There are benefits to having a real powers system even if the numbers don't work over the XMPP portion, such as being able to toggle on defensive powers to activate their FX without me having to hardcode every one of them.

So who knows. But it's a long way off and there are several things that are more easily reachable and have more tangible benefits that have a higher priority. Base building is of course a huge one, not only because a number of people enjoy it, but because it allows the creation of new locations for hangout / RP / pen and paper gaming purposes.

Tahquitz

  • Titan Staff
  • Elite Boss
  • ****
  • Posts: 1,859
Re: Technical discussion of bases
« Reply #22 on: May 27, 2016, 05:25:25 AM »
You want the -offline command line parameter. Once I have some time to work on the options panel UI (or find a helper who knows C/Win32), it'll also be a checkbox you can tick.

That would do the trick.  :D
"Work is love made visible." -- Khalil Gibran

LadyVamp

  • Elite Boss
  • *****
  • Posts: 539
Re: Technical discussion of bases
« Reply #23 on: May 27, 2016, 12:19:38 PM »
I wasn't actually expecting an answer but thanks.  Combat for me would be both private mission and street fighting like we used to do in coh.  XMPP could handle messages about how much dmg was dealt in an attack just as it could handle messages about what attack was executed and how defense and dmg resist affected it.  The clients involved would be responsible for rendering the graphics and playing the sounds.

We used to do basically that all the time in AD&D in college over aim with our friends from high school.  So it is doable but how much work would be involved is another matter.  And, your right, Codewalker.  There is easier, low hanging fruit to go after that were also very important parts of the game itself.

There's also message brokering services available today that could handle passing messages too.  I wonder how well one of those, say rabbittmq for example, might do keeping the clients together.  It's just a thought.  Not a suggestion.  I'm sure Arcana will jump in with an answer shortly.

Anyways, good work, Codewalker.  Keep up the good work.  Who knows, maybe you'll be the one to bring back our beloved game.  If nothing else, I wouldn't be surprised if some gaming company started talking to you about building their next mmo.  That, sir, is likely the price you'll pay for succeeding here.

lol  :D
No Surrender!

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #24 on: May 27, 2016, 06:59:57 PM »
There's also message brokering services available today that could handle passing messages too.  I wonder how well one of those, say rabbittmq for example, might do keeping the clients together.  It's just a thought.  Not a suggestion.  I'm sure Arcana will jump in with an answer shortly.

Ask and ye shall receive.

One of the bigger fundamental problems with trying to make for-realsies combat work in Paragon Chat is that Paragon Chat is designed to send messages only every second or so, to prevent flooding the XMPP server with a lot of messages.  Particularly because a lot of PC's messages are broadcast messages, meaning when one message is sent the XMPP server has to send a lot of copies of that message to everyone in that channel (metadata, for example, which tells PC servers where things are and what is going on goes to everyone in the same zone).

The problem is that CoH combat really requires much faster updates to work right: at least eight per second minimum would be what I would consider the floor.  And the faster things move, the more you'd need even faster updates for positioning to prevent weird ranging issues: fifteen to thirty per second.  That's a huge flood of XMPP messages being sent to XMPP servers.

Still, in very small rooms (small = few people) the message amplification might not get too bad. But the XMPP system itself would introduce significant lag overhead, which creates other potential problems.  You could decide to bypass XMPP.  Theoretically speaking you could have PC servers negotiate a "combat-enabled instance" and then initiate direct communications between them.  Since there's no central server, you'd have each PC server talking to all the others in the zone.  That's a lot more work than a CoH client does, but it might be doable.  But at this point, you've left the realm of Paragon Chat as an XMPP client.

To make *this* work, in effect every Paragon Chat has to implement a subset of mapserver capabilities: in effect each Paragon Chat server has to be able to become a single player mapserver that can then exchange data from other PC servers so everyone sees the same thing.  You'd need some method of synchronizing all the PC servers together, plus some means of generating reproducible combat.  Remember prediction effects?  Suppose your client thinks you're in range and can attack and your target's client thinks you're out of range and can't?  How do you arbitrate that?  You need a system to authoritatively resolve conflicts like that, because you don't have a central server.

You could design the system so that one player's Paragon Chat becomes a de facto server and everyone else's becomes clients to that server.  But at this point, you've created City of Heroes game servers that happen to also speak XMPP.  We're far away into the realm of "cheating" in the sense that while this works, it isn't really Paragon Chat doing combat, it is Paragon Chat growing a server appendage when no one was looking.  Which is work comparable to, and probably greater than, recreating the game servers in the first place.

Short answer is that how Paragon Chat communicates is part of the problem, but not the only problem.  And the more you drift away from using XMPP, the more you drift away from what Paragon Chat is in the first place.

Azrael

  • Elite Boss
  • *****
  • Posts: 666
Re: Technical discussion of bases
« Reply #25 on: May 27, 2016, 11:08:54 PM »
There are different levels of combat as well. Combat that only affects things locally on a solo instance is an entirely different beast than combat that other people can join in or witness via XMPP. And that might be enough for some people, so who knows. There are benefits to having a real powers system even if the numbers don't work over the XMPP portion, such as being able to toggle on defensive powers to activate their FX without me having to hardcode every one of them.

So who knows. But it's a long way off and there are several things that are more easily reachable and have more tangible benefits that have a higher priority. Base building is of course a huge one, not only because a number of people enjoy it, but because it allows the creation of new locations for hangout / RP / pen and paper gaming purposes.

So, an 'offline' version of 'CoH' might be possible..?  Easier because it's on a local level without have to have a 'server' co-ordinate other players interactions?  I'd be quite happy being able to activate powers locally...and fight mobs 'locally.'  But I'd like to able to have some 'peer to peer' functionality with it so you could at least team up with a combat partner.

As per your timeline in the PC thread.  It makes sense to encroach on all the low hanging fruit 1st.  It's probably easier and quicker to do this relative to combat, AI, mobs etc.  It also builds out basic functionality of the game 1st.  Eg.  Chat.  Trains.  Moving around the zones.  Travel powers.  Costume creator.  Message of the day.  Just being able to invite somebody to a team.  Or having Super Groups.  TP to a base would be a huge...being able to edit the base.  It's a big chunk of the game to many people.  I never went for it a lot.  But I know it meant a lot to many others and some bases were huge and took some...wandering through...

I was thinking of the interview you guys did in massively.  I seem to recall that AI pathfinding was consigned the status of most difficult thing to do.  Part of the charm of CoH for me...was the way the mobs animated and behaved along their 'paths' in the zones.  It never got old playing cat and mouse with them.  I have vivid and fond memories of street sweeping in Steel Canyon. 

The private map feature and being able to summon NPCs is something I'm looking forward to.  Patiently.

Azrael.

Quote
You could design the system so that one player's Paragon Chat becomes a de facto server and everyone else's becomes clients to that server.  But at this point, you've created City of Heroes game servers that happen to also speak XMPP.

Micro server?  I'd be happy if there was no 'central' server.  But 'one' just hosted locally and the 'rest of the team' was peer to peer functionality.  Ie.  To get an instance.  And a team of '8' is 'all' you need to replicate CoH combat experience on a map or for street sweeping.  Would that being easier in terms of combat traffic and 'server' stress?  (Ie.  without having to deal with thousands of others the same server?)

Well.  Who knows what form the pass off to real time combat server functionality might take.  But I guess that 'real time' combat won't be in Paragon Chat? 

I guess we're quite a while off this but Paragon Chat has given us quite a lot so far.  And as I look at the timeline for its development, it's going to restore a lot more 'CoH' functionality in the interim as I've mentioned above.  The timeline gives us things to look forward to before we get to the business end of SCORE's plan which seems to point to something 'after' Paragon Chat to give us 'what we really want.'
« Last Edit: May 27, 2016, 11:13:59 PM by Azrael »

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #26 on: May 27, 2016, 11:56:42 PM »
I'd be quite happy being able to activate powers locally...and fight mobs 'locally.'

When Codewalker talks about having "a real powers system" I believe he means something that can read the embedded powers data within the client and use that to fill power trays, allow people to activate powers, and have power activation "do" what the powers database says to do.  But I think most of that is to give him a general framework to allow users to instantiate the effects associated with those powers.  In other words, the animations associated with the powers, the visual FX auras, and perhaps even the projectiles.  But to fight things you need more than "a real powers system" in the sense Codewalker mentions: you also need a combat engine that can track, evaluate, and apply power effects.  In some ways that's actually easier than the general powers engine.  But in two distinct ways it is potentially a lot more difficult.  Unless you are shooting at target dummies, combat all but requires that you either shoot at another player who is themselves moving and acting and that requires distributed synchronization, or you are shooting at an NPC which requires implementing AI to make it anything other than a destructible mayhem mission mailbox.

You could say that when it comes to everything except what Paragon Chat already does - seeing, chatting, zoning - City of Heroes is fundamentally two big things glued together.  There's a component I'll call the reality engine, and a component I'll call the action engine.  The reality engine in a sense executes the rules of the world and updates the world's state moment by moment.  It is the software that applies gravity to objects that should be affected by gravity (i.e. things without the boolean FLY set).  It is the thing that updates all attributes of all entities based on all other attributes.  In other words it is what updates your health because of your regeneration.  It updates your position based on your velocity and the surrounding geometry.  It enforces geometry: it prevents you from walking through walls.  Some of this stuff is implemented partially in the City of Heroes game client itself, but all of it would have been implemented in the CoH mapservers.  Paragon Chat doesn't have this engine, of course, so Paragon Chat recreates bits and pieces of this functionality on a case by case basis.  That's how movement powers work, for example.  How movement works at all, really.  Paragon Chat also has a sense of gravity.  It doesn't do a lot else at the moment.

The action engine is conceptually the thing that takes user inputs and ultimately resolves them into things the reality engine can handle.  It converts keypresses into commands.  It converts power tray clicks into power executions.  It also does things like convert "execute power Blaster.Ranged_Attack.Power_Bolt" into a set of distinct actions.  It tells the animation engine to execute an animation, it spawns sound and visual effects and projectiles.  It tells the combat part of the reality engine to roll some dice and perform a set of attribmod actions if those random rolls succeed.  The attribmods modify the attributes of the target of the power as they are defined to.  All of this converts a mouse click into numbers the reality engine can crunch by figuring out which power is being executed, reading and interpreting its definition, and performing the required actions.  At the moment Paragon Chat pretends to do this on a case by case basis for things like movement powers, but it is all a fake.

In the real game clicking on fly in your power tray causes the game to look up what Inherent.Flight.Fly does, and it sets your FLY boolean to true, and that's it.  Fly doesn't "do" much besides that, because the reality engine can take over: the reality engine sees your entity is flagged with FLY and doesn't apply gravity to you (technically, Fly also sets certain inertia attributes so you decelerate to a stop in a specific way if you aren't actively sending movement commands).  WASD sends acceleration inputs into the reality engine and that causes the reality engine to adjust your velocity and position in specific ways.  All of this is sort of "automatic" behavior built into the engines.  Whoever made the "Fly" power didn't have to write any code to make Fly do anything.  The game engines just processed the bits of data inside the Fly power, and flight emerges as a behavior.

In Paragon Chat, because these general purpose engines don't exist everything has to be done ad hoc.  Within the game client itself implicitly is a complete description of how every single power, including travel powers, should work but Codewalker has to basically hard code their behavior for each one he implements by hand, because Paragon Chat can't use any of that information.  *If* Codewalker makes more generic processing engines that can understand the powers database, and builds enough of the "reality engine" to understand that information, he can start leveraging the powers database itself rather than having to replicate each power's behavior manually.  Instead of implementing each and every possible toggle aura, he can implement a generic "how to turn on auras" behavior and let Paragon Chat's action engine figure out on its own how to tell Paragon Chat's reality engine which aura to turn on and how.

That is of course much harder than implementing a single power by hand, but collectively it is easier to implement generic engines than implementing every power by hand.  Codewalker is implementing things like travel powers by hand for two reasons I presume: first its better in the short term to get these critical powers working as fast as possible with short cuts, and save building more generic engines for less high priority powers.  And second, doing the work of implementing these powers by hand can greatly inform how you will ultimately want to create generic engines rather than attempting to do so completely from scratch.

All of this is the long way around to saying that when Codewalker talks about implementing "a real powers system" that doesn't necessarily mean getting combat of any kind to work.  Its really more of a statement about creating something that can understand the language of the powers database, so Paragon Chat can leverage that information to understand what powers are intended to do and translate that into things it knows how to do.  Even if it knows nothing about how to make combat work, it can still do all the other things the powers database tells it to do: play animations, spawn visual effects, etc.

LadyVamp

  • Elite Boss
  • *****
  • Posts: 539
Re: Technical discussion of bases
« Reply #27 on: May 28, 2016, 11:53:23 PM »
Ask and ye shall receive.
I figured you would respond whether I said so or not.  :)
One of the bigger fundamental problems with trying to make for-realsies combat work in Paragon Chat is that Paragon Chat is designed to send messages only every second or so, to prevent flooding the XMPP server with a lot of messages.  Particularly because a lot of PC's messages are broadcast messages, meaning when one message is sent the XMPP server has to send a lot of copies of that message to everyone in that channel (metadata, for example, which tells PC servers where things are and what is going on goes to everyone in the same zone).
Now that would be a problem.  When I was watching the traffic with wireshark, I noticed a lot of extra traffic going on between some server at ncsoft and the game client during combat. Too bad I didn't save the dumps.  They might have been helpful here.  Especially if I had recorded what activities were going on at certain times in the streams.
No Surrender!

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #28 on: May 29, 2016, 12:12:13 AM »
Now that would be a problem.  When I was watching the traffic with wireshark, I noticed a lot of extra traffic going on between some server at ncsoft and the game client during combat. Too bad I didn't save the dumps.  They might have been helpful here.  Especially if I had recorded what activities were going on at certain times in the streams.

It is safe to assume that a lot of that was happening in the last couple of months of the game's existence.  A lot of what we know emerges from a lot of break-neck activity then.  A lot of demorecord stuff was happening.   I was the one telling people to demorecord their bases, for example.  Free camera mode emerges as part of that (I recall it was Black Pebble that clued us into that one).  I'm aware of a couple efforts to look closely at the mechanics of how the game worked right up to shutdown, which I may have had a small hand in.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical discussion of bases
« Reply #29 on: May 29, 2016, 02:50:46 AM »
Now that would be a problem.  When I was watching the traffic with wireshark, I noticed a lot of extra traffic going on between some server at ncsoft and the game client during combat. Too bad I didn't save the dumps.  They might have been helpful here.  Especially if I had recorded what activities were going on at certain times in the streams.

Saving them would have just been a waste of disk space. The mapserver protocol is encrypted, and the encryption key is negotiated dynamically -- a unique key is used for each session. The negotiation occurs using Diffie-Hellman key exchange, in which the keys are not sent directly but rather mutually agreed upon in a way that both ends can mathematically arrive at the same answer, but an eavesdropper cannot.

Since the keys are different each time and can't be recovered from the trace, Wireshark dumps are useless. Unless you have a huge distributed network at your disposal, then you could probably bruteforce one key every 3-4 years and decrypt part of a single session (each time you zone a new connection is established and new key negotiated), if you already know what the protocol looks like and can recognize that you've guessed the correct key.

Azrael

  • Elite Boss
  • *****
  • Posts: 666
Re: Technical discussion of bases
« Reply #30 on: May 29, 2016, 02:48:36 PM »
Quote
When Codewalker talks about having "a real powers system" I believe he means something that can read the embedded powers data within the client and use that to fill power trays, allow people to activate powers, and have power activation "do" what the powers database says to do.  But I think most of that is to give him a general framework to allow users to instantiate the effects associated with those powers.  In other words, the animations associated with the powers, the visual FX auras, and perhaps even the projectiles. 

Well, I'm looking forward to having the 'powers' in the trays again.  Just having the 'hard coded'(?) travel powers in the trays is exciting. 

Quote
Codewalker is implementing things like travel powers by hand for two reasons I presume: first its better in the short term to get these critical powers working as fast as possible with short cuts, and save building more generic engines for less high priority powers.  And second, doing the work of implementing these powers by hand can greatly inform how you will ultimately want to create generic engines rather than attempting to do so completely from scratch.

I see.  Paragon Chat is a learning process of restoring 'CoH' functionality in a 'server' context stopping just shy of 'combat.'  It will restore 'most' functionality upto that point.  But no further.  Codewalker must know the client inside out by now.  But the server aspects.  Ie mechanisms and systems to activate the functionality of the client is another matter.  In that regard, Paragon Chat's timeline sets expectations (tempered to a degree...) and seems like it can be a graduated learning process of adding peripheral and basic functionality while in the context of running 'a' server.  While PC won't do combat...all those steps leading up to the 'passover' which surely be invaluable.  Ie.  Getting super bases back will be massive.  Just being able to 'join team' or have a 'Supergroup' are the things we used to do - those were still part of the 'game.'  Having a 'message of the day.'  To me, it's all part of the jigsaw.  Each piece is important.  I wasn't big into Supergroups...but from reading Codewalker's technical response...you can read a map but there's a list of caveats to actually wandering around one at the moment.  But it's doable?  In time?  And it will give the Paragon Chat community 'something more' to do.


Quote
Even if it knows nothing about how to make combat work, it can still do all the other things the powers database tells it to do: play animations, spawn visual effects, etc.

To be able to play animations and spawn visual effects would be nice. 

From my time of doing 3D I recall 'nulls' as being objects that can be used as 'reference' points to enable certain functionality.  Almost like a 'target' object. 

What I'm getting at.  Could 'nulls' or invisible target objects be put e.g. as a 'zero' reference point say...10-100 yards of a player character alt in Paragon Chat.  ie.  It would give you something ie.  AN invisible target 'dummy' to aim your projectile powers at.  Or even, on private maps where 'soon' you will be able to 'summon NPCs' could you use them as a 'target dummy' for a 'play animations, spawn visual effects etc.' thing?  The null or NPC summon would be fixed reference point relative to you?

Quote
Simulated attack powers, possibly usable on target dummies

From the Paragon Chat timeline.

Though it's someway off!  But it would be nice to have target dummies in the Super bases.  Like a 'danger room...'

Quote
Handoff to realtime communication service for more demanding activities, such as PVP Arena matches

Which seems to indicate PVP arena matches...that some kind of 'realtime' com' service is needed so there isn't spaghetti rubber banding during combat.  What I like about this part of the timeline is that it gives some hope of 'combat' in the future.  For PVP first.  You could team up with someone and have them be the baddy in combat while you play the hero and swap.  *Imagines dressing an alt like a Troll... 

If there will be 'summon' NPC on these private maps, a side thought, will there be 'Be_NPC' also?  Will the Superbases be like these private maps also with summon NPC functionality?

Azrael.

Quote
The action engine is conceptually the thing that takes user inputs and ultimately resolves them into things the reality engine can handle.  It converts keypresses into commands.  It converts power tray clicks into power executions.  It also does things like convert "execute power Blaster.Ranged_Attack.Power_Bolt" into a set of distinct actions.  It tells the animation engine to execute an animation, it spawns sound and visual effects and projectiles.  It tells the combat part of the reality engine to roll some dice and perform a set of attribmod actions if those random rolls succeed.  The attribmods modify the attributes of the target of the power as they are defined to.  All of this converts a mouse click into numbers the reality engine can crunch by figuring out which power is being executed, reading and interpreting its definition, and performing the required actions.  At the moment Paragon Chat pretends to do this on a case by case basis for things like movement powers, but it is all a fake.

It's a convincing fake so far. :)  There's only one Mona Lisa but that doesn't stop people having prints on their wall...

All that in a 'second,' eh? 

The breakdown of the 'reality' engine and the 'action' engine helped me to understand a little bit more of the functionality of what the server does.  And what anyone trying to 'simulate' it is up against.  A decent post that.
« Last Edit: May 29, 2016, 03:16:40 PM by Azrael »

LadyVamp

  • Elite Boss
  • *****
  • Posts: 539
Re: Technical discussion of bases
« Reply #31 on: May 29, 2016, 07:53:41 PM »
It is safe to assume that a lot of that was happening in the last couple of months of the game's existence.  A lot of what we know emerges from a lot of break-neck activity then.  A lot of demorecord stuff was happening.   I was the one telling people to demorecord their bases, for example.  Free camera mode emerges as part of that (I recall it was Black Pebble that clued us into that one).  I'm aware of a couple efforts to look closely at the mechanics of how the game worked right up to shutdown, which I may have had a small hand in.

Took many pictures of my base just in case I had a chance to rebuild it some day.  too bad it's in my personal wiki and cannot be shared with anyone without a bit of work on my part.
No Surrender!

LadyVamp

  • Elite Boss
  • *****
  • Posts: 539
Re: Technical discussion of bases
« Reply #32 on: May 29, 2016, 08:23:58 PM »
Saving them would have just been a waste of disk space. The mapserver protocol is encrypted, and the encryption key is negotiated dynamically -- a unique key is used for each session. The negotiation occurs using Diffie-Hellman key exchange, in which the keys are not sent directly but rather mutually agreed upon in a way that both ends can mathematically arrive at the same answer, but an eavesdropper cannot.

Since the keys are different each time and can't be recovered from the trace, Wireshark dumps are useless. Unless you have a huge distributed network at your disposal, then you could probably bruteforce one key every 3-4 years and decrypt part of a single session (each time you zone a new connection is established and new key negotiated), if you already know what the protocol looks like and can recognize that you've guessed the correct key.

I figured they might try something like that but encryption over udp can be a bit rough.  Most of the advanced modes like CBC over udp could easily get out of sync real fast.  Drop a single packet and all future packets are garbage.  The channel would be worthless until a rekey was done.  They can't be decrypted without the missing dropped packet.  And udp can't do anything about missing packets beyond detect them.  The higher level protocols would have to handle that.  The other part is how often they rekeyed.  Changing from zone to zone would be the obvious place, but I'm willing to bet rekeying happened inside single zones as well.  I'd be willing to bet rekeying happened with every dopped packet in fact.  Encryption happens to be one of my hobbies from college.

It was probably overkill for them to even do encryption like that for game data.  The login info certainly should have been.  But the rest was probably more expensive than what they gained from it.  I know a few years ago, they got really upset when I told them I was watching game traffic with wireshark.  Wanted me to prove I held valid licenses.  They got real quiet about it when I gave them the 12 codes I had dating all the way back to issue 2 plus all the add-ons.  And even the 1st code which was bad and the one they sent me to replace it.

But you're probably right.  Keeping the dumps probably wouldn't yield anything useful.  It was just a thought.  Even if the data wasn't encrypted, unless you knew what to look for, it would all be meaningless, random (likely binary) data anyway.

No Surrender!

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical discussion of bases
« Reply #33 on: May 30, 2016, 02:47:53 AM »
It's ECB mode, which doesn't require the packets to be received in order.

That is normally vulnerable to replay attacks, and repeated patterns can sometimes be detected, but it's less of an issue with the mapserver protocol than most. The UDP layer does its own sequence tracking and will ignore duplicate packets or packets with wildly wrong sequence numbers. Because the data is tightly packed as variable-length values into a bit stream (and not byte aligned), the exact position relative to byte boundaries can and does vary based on header information, which is constantly changing. That makes repeated patterns harder to detect as there are 8 different possible variations depending on how they straddle the byte boundaries.

It's not quite as bulletproof as block chaining, but for the type of data being sent it is good enough and holds up surprisingly well.

I've not found any evidence of key renegotiation within a stream. Given that the game is heavily instanced, the boundary of changing between maps (which initiates a new connection) was probably seen as a good enough interval for rekeying.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #34 on: May 31, 2016, 08:59:01 PM »
Saving them would have just been a waste of disk space. The mapserver protocol is encrypted, and the encryption key is negotiated dynamically -- a unique key is used for each session. The negotiation occurs using Diffie-Hellman key exchange, in which the keys are not sent directly but rather mutually agreed upon in a way that both ends can mathematically arrive at the same answer, but an eavesdropper cannot.

I suppose someone could have been hopeful that the DH prime leaked one day, or that Cryptic was dumb lazy foolish enough to use 512 bit DH in their implementation.

Incidentally, Diffie-Hellman exchange is on my top ten list of most beautiful mathematical algorithms.

Azrael

  • Elite Boss
  • *****
  • Posts: 666
Re: Technical discussion of bases
« Reply #35 on: May 31, 2016, 10:27:21 PM »
I suppose someone could have been hopeful that the DH prime leaked one day, or that Cryptic was dumb lazy foolish enough to use 512 bit DH in their implementation.

Incidentally, Diffie-Hellman exchange is on my top ten list of most beautiful mathematical algorithms.

A shame no server source code 'leak...'

Azrael.

LadyVamp

  • Elite Boss
  • *****
  • Posts: 539
Re: Technical discussion of bases
« Reply #36 on: May 31, 2016, 11:19:12 PM »
It's ECB mode, which doesn't require the packets to be received in order.

That is normally vulnerable to replay attacks, and repeated patterns can sometimes be detected, but it's less of an issue with the mapserver protocol than most. The UDP layer does its own sequence tracking and will ignore duplicate packets or packets with wildly wrong sequence numbers. Because the data is tightly packed as variable-length values into a bit stream (and not byte aligned), the exact position relative to byte boundaries can and does vary based on header information, which is constantly changing. That makes repeated patterns harder to detect as there are 8 different possible variations depending on how they straddle the byte boundaries.

It's not quite as bulletproof as block chaining, but for the type of data being sent it is good enough and holds up surprisingly well.

I've not found any evidence of key renegotiation within a stream. Given that the game is heavily instanced, the boundary of changing between maps (which initiates a new connection) was probably seen as a good enough interval for rekeying.

Very interesting.  ECB is usually not used due to being weak compared to other encoding schemes yet strong enough to survive what most companies could throw at it.  One of the spy agencies could break it but unless it contains terrorist data (perhaps 2 terrorists met on a private map to discuss operations) unlikely they'd be interested in taking a shot at breaking it.  And if it did, they'd not share their findings (too bad) though I don't know how useful it would be here either.

It wouldn't have the problem of missing data packets as each packet stands on its own.  Dupes can be safely ignored too.  Quite smart on their part.  I doubt they had any key leaks either and probably used a 1024 dh key since that was the standard for a long time.

Would be interested to know the key space and algorithm used
No Surrender!

LadyVamp

  • Elite Boss
  • *****
  • Posts: 539
Re: Technical discussion of bases
« Reply #37 on: May 31, 2016, 11:31:31 PM »
I suppose someone could have been hopeful that the DH prime leaked one day, or that Cryptic was dumb lazy foolish enough to use 512 bit DH in their implementation.

Incidentally, Diffie-Hellman exchange is on my top ten list of most beautiful mathematical algorithms.

I would bet the library they used to do the encryption wouldn't have that problem.  And if they put that much thought into securing their communications, they likely used 1024.  Computers of 10 years ago could handle that and still haul pretty good.

Oh and thank you for stating mathematics and not computer science.  I hate it when programmers think encryption, keys, and digital signatures are computer science related items.  Never can get them to understand computers just make the math go faster.
No Surrender!

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #38 on: June 01, 2016, 12:35:17 AM »
I would bet the library they used to do the encryption wouldn't have that problem.  And if they put that much thought into securing their communications, they likely used 1024.  Computers of 10 years ago could handle that and still haul pretty good.

Well, CoH development was started back in 2001 (and possibly back to 1999).  In 2001, there were people implementing 512 bit DH.  Heck, I saw people still implementing Cisco VPNs with DH group 1 just ten years ago, which uses 768 bit DH mod.  That's easily crackable today.

Quote
Oh and thank you for stating mathematics and not computer science.  I hate it when programmers think encryption, keys, and digital signatures are computer science related items.  Never can get them to understand computers just make the math go faster.

Well, technically speaking no algorithm is specific only to digital computing but there are algorithms I consider to be "computer" algorithms contextually rather than "mathematical" algorithms even if they aren't unique to computing.  For example, I call Diffie-Hellman a mathematical algorithm because I conceptualize the algorithm in terms of pure mathematics.  But I would be comfortable calling, say, LFSR a "computer algorithm" because its really only encountered as a digital circuit implementation.

I'm not fond of the term "computer science" in general.  First of all, there's no computer non-science: there's no generally accepted computer art major or computer fiction major per se.  Also, computers are a technology: it is almost nonsensical to talk about computer science as a science: we don't talk about "bridge science" or "skyscraper science" or "hammer and chisel science."  50% of computer science is mathematics, and 99.9% of the rest is computer engineering.  The 0.1% that is actual computer "science"?  Things almost no one learns or is taught.  Like scalability issues due to memory error rates due to cosmic ray bit flipping.  That's arguably computer science.  Quicksort is not science, it is math.  There are no scientific principles involved in devising, analyzing, or implementing sorting algorithms.

There are times I wonder if I chose EE as a major instead of computer science in part because I hated the nomenclature.

LadyVamp

  • Elite Boss
  • *****
  • Posts: 539
Re: Technical discussion of bases
« Reply #39 on: June 01, 2016, 03:16:21 AM »
Well, CoH development was started back in 2001 (and possibly back to 1999).  In 2001, there were people implementing 512 bit DH.  Heck, I saw people still implementing Cisco VPNs with DH group 1 just ten years ago, which uses 768 bit DH mod.  That's easily crackable today.

Granted but if their security group was worth a darn, they'd upgrade the software to take advantage of new capabilities or at least plug the holes.  But then I seem to remember some turd brain taking over their servers as admin and rebooting the one I was on as we were completing the 8 mission posi tf on the 8th mission right before you kill the bad guy...urm I mean arrest the bad guy.

Wonder whatever happened to that turkey.

I digress.  Let's put this discussion back on the bases.  That too was one of the more interesting things, and I never got to build out the rodent consortium base completely to my satisfaction.  The ultra tech equipment with the stone walls and floors and wood or stone ceilings and dark lighting was nice.  Gave the base that, "we mice carry our ultra tech but never let go of our rodent, dark hole loving roots," feeling I was trying to create.
« Last Edit: June 01, 2016, 03:21:22 AM by LadyVamp »
No Surrender!