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


Jeff Anderson

  • Boss
  • ****
  • Posts: 121
Re: Technical discussion of bases
« Reply #61 on: July 22, 2016, 01:29:59 AM »
Yo COH!!

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical discussion of bases
« Reply #62 on: August 02, 2016, 04:51:23 PM »
Since all but one of my prerelease testers were asleep last night*, I'll just leave these here.








* Not that I blame them. What I wouldn't give for a solid 8 hours...

Ulysses Dare

  • Boss
  • ****
  • Posts: 103
Re: Technical discussion of bases
« Reply #63 on: August 02, 2016, 05:46:06 PM »
Drool.  :o

War-Base

  • Underling
  • *
  • Posts: 11
Re: Technical discussion of bases
« Reply #64 on: August 06, 2016, 08:42:45 PM »
OMG!!!  Is it really possible the base editor might be functional and useable again someday soon?!?!?

That would be a dream come true for me personally!

I used to spend close to 95% of all my logged in game time making bases. The rest of the time I was touring other people's bases or finding clients to make bases for...

Sigh... the good old days...

I want to thank Codewalker and the rest of the crew for all they have done to bring back a huge and important part of many people's life.

If you can make the editor live again, you all won't just be heroes... you will be LEGENDS!

MaidMercury

  • Elite Boss
  • *****
  • Posts: 470
Re: Technical discussion of bases
« Reply #65 on: August 07, 2016, 12:44:59 AM »
I use to enjoy being invited to see other SG's.  :roll:
( wasn't always that way in earlier issues.)

Nyx Nought Nothing

  • New Efforts # 11,000!
  • Elite Boss
  • *****
  • Posts: 796
  • Ha!
Re: Technical discussion of bases
« Reply #66 on: August 07, 2016, 03:47:27 AM »
Since all but one of my prerelease testers were asleep last night*, I'll just leave these here.* Not that I blame them. What I wouldn't give for a solid 8 hours...
So far so good. Onward and upward!

dphender

  • Underling
  • *
  • Posts: 9
Re: Technical discussion of bases
« Reply #67 on: August 07, 2016, 11:50:24 PM »
Looks Great! It's amazing work your doing!

saipaman

  • Elite Boss
  • *****
  • Posts: 921
Re: Technical discussion of bases
« Reply #68 on: August 10, 2016, 04:18:18 AM »
Here is another teaser:


War-Base

  • Underling
  • *
  • Posts: 11
Re: Technical discussion of bases
« Reply #69 on: August 14, 2016, 06:58:59 PM »
*drool*

Now you guys have my full attention...

Will there be a way to import demorecords into the editor through PC?  I think I have demos about 30 of my bases I would love to be able to work on again... 

Are these bases in the pictures edited conversions from demos, or are they all built new from scratch?

The progress and potential of what you guys are doing is simply amazing!




(By the way, for anyone else that that wants to know or remembers me... Yes, I am the same War Base from the BaseBuilders Inc. chat group, winner (and co-winner) of the PERC base-building contests - I am occasionally sort of bad with replies to private messages, so just throwing it out there in case anyone else was curious...)

Ulysses Dare

  • Boss
  • ****
  • Posts: 103
Re: Technical discussion of bases
« Reply #70 on: August 14, 2016, 08:16:30 PM »
(By the way, for anyone else that that wants to know or remembers me... Yes, I am the same War Base from the BaseBuilders Inc. chat group, winner (and co-winner) of the PERC base-building contests - I am occasionally sort of bad with replies to private messages, so just throwing it out there in case anyone else was curious...)

Hey WB! Long time no see.

saipaman

  • Elite Boss
  • *****
  • Posts: 921
Re: Technical discussion of bases
« Reply #71 on: August 14, 2016, 09:40:58 PM »

Are these bases in the pictures edited conversions from demos, or are they all built new from scratch?


The base in the picture above was loaded from a demo.

Pengy

  • Badge Badger
  • Elite Boss
  • *****
  • Posts: 1,132
Re: Technical discussion of bases
« Reply #72 on: August 15, 2016, 12:14:58 AM »
Paragon Chat can't provide Personal Items yet, and standard items you place don't produce or consume resources. But it can load bases with all that stuff:



That base is loaded from a demo. There is a crafted generator and teleporters, and they even give the appearance of producing and consuming power. There's a Longbow Flier in there somewhere, too.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical discussion of bases
« Reply #73 on: August 15, 2016, 02:04:29 PM »
Will there be a way to import demorecords into the editor through PC?  I think I have demos about 30 of my bases I would love to be able to work on again... 

There already is. In the current (unfinished) prototype that people are testing, demorecords are actually the only way to save a base between sessions.

Even once PC is able to remember bases on its own, demos will of course still be supported as a means of importing ones that were saved before the shutdown.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical discussion of bases
« Reply #74 on: August 15, 2016, 07:40:44 PM »
Arcana, if you're still reading this thread, I saw something that reminded me of an earlier discussion.

In another thread there was discussion was about re-engineering things and how closely you had to get to the original implementation versus designing something that works completely differently and making it protocol-compatible. I grumbled something about the protocols in COH using a lot of implementation details in them that makes it difficult to do the latter. SG bases turn out to be a good example of this.

Bit of necessary backstory: The COH world graph consists of two things: Groupdefs - or defs for short, and Refs. Defs at the lowest level represent a single mesh, but more often reference other defs in a hierarchical manner, building up a complex object from smaller pieces, which is where the 'group' part of the name comes from. Defs are defined both in map files as well as the object library - a shared repository that contains every static 3D object in game. The defs from map files are typically more complex and might be things like a big group that instances many buildings from other defs that come from the object library.

But defs only define what groups look like, they don't actually place them anywhere. Map files also contain a list of Refs - references to specific defs with instructions on where to place them. In zone maps there are only a handful of top-level refs that point at the defs defined in that same file. One common thing to see is a ref to "grp_Geometry", the customary name of the Groupdef that all of the zone geometry is under.

When I say things like "the server just sends a map filename for the client to load", that's actually a gross simplification to keep conversations manageable. What actually happens is that the server first sends a list of files to load defs from - first all of the various object library files it depends on*, then the map itself. Then it sends the list of top-level refs that point to some of the defs just loaded.

And that's just to get a normal map loaded, that's not even the point to my story.

As I mentioned, bases work quite differently. They use a similar mechanism, but instead of the final filename in the list being the zone map, it's an empty filename followed by a compressed base structure. The client uses that structure and builds a number of defs in memory, parented by "grpbase_0" -- the 0 is presumably to identify the base so that multiple bases can be loaded during a base raid. It also adds a grpbase_0 ref to the global list of refs in memory. In theory, that means all you have to do is send a compressed base (in binary format) and the client will do all of the work of generating the geometry for it, just like when playing back a demorecord.

When I first started working on bases in Paragon Chat, I wasted a good day's worth of time on a real headscratcher of a problem. The base was being sent correctly, I verified that it was being received and the geometry was being generated in client memory, but when I actually zoned in it was an empty map. I tried all sorts of different things to try to make it work, or even do something different like crash just to see if I was on the right track.

Finally, I managed to piece together what was happening. After sending the file names (or base), it still expects a list of refs. When an empty list didn't work, I had previously tried changing that to send simply "Base" (the name I was using internally in Paragon Chat to represent the base) with no success. Only once I started watching the ref list memory area did I realize that when I was sending a "Base" ref, or no ref at all, the client was checking it against the list it already had. It then deleted the "grpbase_0" ref it had created earlier because it wasn't on the list of refs sent by the 'server'. In the end I had to modify Paragon Chat to nearly perfectly duplicate how the client was generating groupdefs from the base data in order to make it successfully load.

In hindsight I should have realized that sooner, since the normal map load procedure involves sending all of the refs as well. However, in the early days I was just duplicating the packet captures I was going by and since the map file already had the list in it, I never thought to try something different. Had I done so I would have realized just how tightly coupled the protocol is to the implementation behind it.

That's just one example, but I've run into the same thing numerous times. Even sending costumes correctly requires building up a single-instance list of costume parts in a particular order and then transmitting numeric indices into that list.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #75 on: August 15, 2016, 10:36:11 PM »
Well, I was always told that the base code was something really ugly that the devs always wanted to refactor but never had the resources (or the priority) to tackle.

To me, the interesting part of learning bits of implementation was trying to figure out just exactly what the devs were thinking when they did something.  Like some of the attribute packing can be attributed to memory compression from the early days.  Some not.  Sequence bits kept getting redefined for what appeared to be no good reason, probably because of the way they decided to handle def files associated with animation.  I have no idea what the devs were thinking here, except it is possible the base implementer said "I'm not 100% sure how the object defs work precisely, so I'm going to make my own geometry system and tack it onto the end of it."

Its the only explanation for the reward system random number generator fiasco, so I would have to go with that by default.


You sure rewriting the combat engine wouldn't be easier at this point?  :p

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Technical discussion of bases
« Reply #76 on: August 16, 2016, 05:05:40 AM »
I have no idea what the devs were thinking here, except it is possible the base implementer said "I'm not 100% sure how the object defs work precisely, so I'm going to make my own geometry system and tack it onto the end of it."

Most of the editor UI itself is clientside and needs to know the structure of the base, so it makes some sense to only send the "source" of the base rather than the geometry generated from it.

It would mean that the client and server would need to independently generate the same geometry (for collisions). However, as there is strong evidence from debug information left in the client exe that the client and server were built from the same source tree with a number of files shared in a 'Common' folder tree, it wouldn't have been difficult for them to keep those in sync.

From what I've seen of the base infrastructure, it certainly is a little odd in places and definitely looks like a rush job to get it working before the CoV release. Once you're past the initial shock of those differences from how everything else works, I'd say it's not nearly as scary as we were led to believe. No more so than anything else in the game, anyway.

You sure rewriting the combat engine wouldn't be easier at this point?  :p

Possibly. A combat engine itself wouldn't be too hard -- it's mostly just an attribute state machine. The hardest part would be implementing all of the 'special' attributes that do things like spawn pets. I consider AI pathing to be an order of magnitude harder than a combat engine.

However, working on Paragon Chat has given me some very interesting ideas and changed my perception of exactly what needs to be part of the core mapserver. While the mapserver itself I'd say absolutely has to run synchronously on a fixed 30hz clock - there's just too much that assumes that clientside to make it practical to do anything else - most things other than physics can get away with being 'close enough'. I used to think that combat absolutely had to be part of that loop, but now I'm not so sure. Since the combat clock is much slower, a separate process running on that clock, or even (gasp!) asynchronously and feeding event data to a mapserver running in a separate thread, process, or even machine on a low-latency network would probably be indistinguishable to anyone not doing demorecord analysis, and maybe even stand up to that as well.

Combine that with some ideas I have for mapserver to mapserver synchronization - also inspired by this XMPP experiment and much easier if all the mapserver is doing is entity tracking, sequencers, physics and client communication - and you have some very interesting scalability potential.

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #77 on: August 16, 2016, 08:27:46 PM »
However, working on Paragon Chat has given me some very interesting ideas and changed my perception of exactly what needs to be part of the core mapserver. While the mapserver itself I'd say absolutely has to run synchronously on a fixed 30hz clock - there's just too much that assumes that clientside to make it practical to do anything else - most things other than physics can get away with being 'close enough'. I used to think that combat absolutely had to be part of that loop, but now I'm not so sure. Since the combat clock is much slower, a separate process running on that clock, or even (gasp!) asynchronously and feeding event data to a mapserver running in a separate thread, process, or even machine on a low-latency network would probably be indistinguishable to anyone not doing demorecord analysis, and maybe even stand up to that as well.

Combat itself doesn't in general have to be either fast or synchronous in my opinion, but there are a lot of weird corner cases that might arise in certain places.  Range effects in particular would get hinky (i.e. in-range/out-of-range detection would require some more sophisticated kind of interpolative handlng).  From my experience, most players can't tell the difference in how combat clocking works down to about 500 milliseconds.  They are more sensitive to things happening in the right order than at the right time.

Nyghtshade

  • HERC Advisor
  • Elite Boss
  • *****
  • Posts: 881
Re: Technical discussion of bases
« Reply #78 on: August 16, 2016, 09:19:36 PM »
If we are at some point in the future able to load our bases into Paragon Chat from a demo-record file, then will other players be able to enter the base and walk around in it as well, or will the base(s) be just a sort of solo-instance?

Arcana

  • Sultaness of Stats
  • Elite Boss
  • *****
  • Posts: 3,672
Re: Technical discussion of bases
« Reply #79 on: August 17, 2016, 12:07:54 AM »
If we are at some point in the future able to load our bases into Paragon Chat from a demo-record file, then will other players be able to enter the base and walk around in it as well, or will the base(s) be just a sort of solo-instance?

I can't speak for Codewalker but I believe it is fair to say that any feature Codewalker adds to Paragon Chat will always have the specific intent of functioning within the parameters of Paragon Chat.  Which is another way of saying I don't believe Codewalker would add a feature to Paragon Chat that wouldn't work as a multiuser experience.  If it could only work single user and there was no likely path to making it work in a shared chat context, I don't think Codewalker would focus on that feature, or if he absolutely had to scratch that itch he'd more likely backport it to Icon.

Short version: if Codewalker adds it to Paragon Chat, and you can see it, everyone else will (eventually) be able to see it also.