Dev Update #6 - MPQ Unity Launch Pt 3

entrailbucket

@KGB said:
Unity is coded in C#. Unfortunately C# is a tremendous memory hog that has never done a good job of clearing up unused RAM. We use it a work for our GUI and when we first created ours it steadily climbed in RAM usage from a few hundred meg to 2 gigs over time getting slower and slower (sound familiar). The garbage collector is supposed to free RAM but it does a lousy job of it. Eventually we had to redo most of our GUI and make everything long lived (ie no creating and destroying things in RAM) which used more RAM initially but stopped the infinite climb of memory due to stuff not being garbage collected when changing pages/screens etc.

Today after doing DDQ + Shield Training (I replayed one the easiest nodes 10 times to complete the Storm quest) my phone was down to 70% battery. A quick look in Android at who used battery said MPQ used 22% in 45 minutes of play time.

It also says the game is using 1 Gig of RAM! That's a HUGE amount of RAM for a simple game like this. Lucky my phone has 6 Gigs but I bet a lot of people who are having really bad experiences (lots of crashes) are on older phones/devices that have only 2 Gigs and their device is running out of RAM really fast.

KGB

Unity is used by a pretty wide majority of all mobile games and apps and almost all AR and VR games and applications. C# is likely used by millions of applications in all sorts of categories.

These things are tools and they're as good as the developers using them. Plenty of applications on other platforms leak memory or hog resources, and plenty of C# or Unity applications run just fine. The absolute last thing we need at this point is to start second-guessing their choice of platform/language.

KGB

@entrailbucket said:

@KGB said:
Unity is coded in C#. Unfortunately C# is a tremendous memory hog that has never done a good job of clearing up unused RAM. We use it a work for our GUI and when we first created ours it steadily climbed in RAM usage from a few hundred meg to 2 gigs over time getting slower and slower (sound familiar). The garbage collector is supposed to free RAM but it does a lousy job of it. Eventually we had to redo most of our GUI and make everything long lived (ie no creating and destroying things in RAM) which used more RAM initially but stopped the infinite climb of memory due to stuff not being garbage collected when changing pages/screens etc.

Today after doing DDQ + Shield Training (I replayed one the easiest nodes 10 times to complete the Storm quest) my phone was down to 70% battery. A quick look in Android at who used battery said MPQ used 22% in 45 minutes of play time.

It also says the game is using 1 Gig of RAM! That's a HUGE amount of RAM for a simple game like this. Lucky my phone has 6 Gigs but I bet a lot of people who are having really bad experiences (lots of crashes) are on older phones/devices that have only 2 Gigs and their device is running out of RAM really fast.

KGB

Unity is used by a pretty wide majority of all mobile games and apps and almost all AR and VR games and applications. C# is likely used by millions of applications in all sorts of categories.

These things are tools and they're as good as the developers using them. Plenty of applications on other platforms leak memory or hog resources, and plenty of C# or Unity applications run just fine. The absolute last thing we need at this point is to start second-guessing their choice of platform/language.

I'm not second guessing. The only choice in Unity is C# so there is no 2nd guess anyway. What I was pointing out is that C# was supposed to be a panacea for development in that it managed memory for you so developers didn't have to worry about it. Unfortunately its not turned out that way in the real world and you often have to code things in specific ways to avoid the pitfalls of the language.

The exact same thing happened to my company when we switched to an all C# GUI. It took a lot of effort to redo a whole bunch of sections of code to get things to where they needed to be (our GUI has to run for many days straight with the user interacting with it so it mattered that it got very slow over time).

KGB

DAZ0273

Can we just now appoint @KGB as forum spokesman on this Unity stuff coz he seems to know what he is talking about. Not that I doubt Entrail either. Or understand anything. But if anything helps both players and Devs should work together, right?

entrailbucket

@KGB said:

@entrailbucket said:

@KGB said:
Unity is coded in C#. Unfortunately C# is a tremendous memory hog that has never done a good job of clearing up unused RAM. We use it a work for our GUI and when we first created ours it steadily climbed in RAM usage from a few hundred meg to 2 gigs over time getting slower and slower (sound familiar). The garbage collector is supposed to free RAM but it does a lousy job of it. Eventually we had to redo most of our GUI and make everything long lived (ie no creating and destroying things in RAM) which used more RAM initially but stopped the infinite climb of memory due to stuff not being garbage collected when changing pages/screens etc.

Today after doing DDQ + Shield Training (I replayed one the easiest nodes 10 times to complete the Storm quest) my phone was down to 70% battery. A quick look in Android at who used battery said MPQ used 22% in 45 minutes of play time.

It also says the game is using 1 Gig of RAM! That's a HUGE amount of RAM for a simple game like this. Lucky my phone has 6 Gigs but I bet a lot of people who are having really bad experiences (lots of crashes) are on older phones/devices that have only 2 Gigs and their device is running out of RAM really fast.

KGB

Unity is used by a pretty wide majority of all mobile games and apps and almost all AR and VR games and applications. C# is likely used by millions of applications in all sorts of categories.

These things are tools and they're as good as the developers using them. Plenty of applications on other platforms leak memory or hog resources, and plenty of C# or Unity applications run just fine. The absolute last thing we need at this point is to start second-guessing their choice of platform/language.

I'm not second guessing. The only choice in Unity is C# so there is no 2nd guess anyway. What I was pointing out is that C# was supposed to be a panacea for development in that it managed memory for you so developers didn't have to worry about it. Unfortunately its not turned out that way in the real world and you often have to code things in specific ways to avoid the pitfalls of the language.

The exact same thing happened to my company when we switched to an all C# GUI. It took a lot of effort to redo a whole bunch of sections of code to get things to where they needed to be (our GUI has to run for many days straight with the user interacting with it so it mattered that it got very slow over time).

KGB

Anybody who's ever bought the idea that a new language will solve all your problems was doomed from the start. There is no silver bullet in this industry. I've seen bad code that leaks memory in dozens of languages and development platforms over my 20+ year career, and I've seen good code in platforms that are decades out of date and no longer trendy.

Ground up rebuilds are almost never a good idea, and changing platforms or languages is also almost never a good idea. Every developer who's ever worked for me has said "I can't possibly support this thing, it's terrible! We need to rewrite it all using (whatever the current fad is)!" Everybody is awful at reading code, especially old code, because everybody is awful at documentation.

The problem with a full rebuild is that someone's been fixing bugs and making tweaks to that old code for 10 years. When you rewrite the application, you will make some of the same mistakes the original coders did, and then you'll also make some new ones. Now we've thrown out 10+ years of bugfixes, and we get to make them all over again.

The number of ground up rebuilds I've seen for business critical applications can be counted on one hand. The number of successful ground up rebuilds for business critical applications, that came in on time and on budget, is zero.

DAZ0273

None of this is putting me in a happy place. Fine, you can share it. EntrailKGBucket. You are now both our representative. Ohhh, like that time Prof X and Caliban got merged in that X-Men comic book! I expect this will go similar - I KGB wish to comply but I EntrailKGBucket do not! Meanwhile Kulan Gath is wrecking the game. Sigh

Borstock

Probably reported a hundred times, but on my Android, if I'm playing a match on wifi and walk out of range of the router, when the match ends, the game freezes on the blue screen. Previously, I just had to wait for my data to kick in.

Eta: This is a repeatable error on my phone.

entrailbucket

@DAZ0273 said:
None of this is putting me in a happy place. Fine, you can share it. EntrailKGBucket. You are now both our representative. Ohhh, like that time Prof X and Caliban got merged in that X-Men comic book! I expect this will go similar - I KGB wish to comply but I EntrailKGBucket do not! Meanwhile Kulan Gath is wrecking the game. Sigh

Tl;dr companies that greenlight "let's rebuild The Reason We All Get Paid, from scratch" are either stupid or desperate (and sometimes both).

I am choosing to assume that this particular rebuild is "desperate," because I prefer not to consider the alternative.

LavaManLee

@entrailbucket said:

@DAZ0273 said:
None of this is putting me in a happy place. Fine, you can share it. EntrailKGBucket. You are now both our representative. Ohhh, like that time Prof X and Caliban got merged in that X-Men comic book! I expect this will go similar - I KGB wish to comply but I EntrailKGBucket do not! Meanwhile Kulan Gath is wrecking the game. Sigh

Tl;dr companies that greenlight "let's rebuild The Reason We All Get Paid, from scratch" are either stupid or desperate (and sometimes both).

I am choosing to assume that this particular rebuild is "desperate," because I prefer not to consider the alternative.

I'm guessing it has to be desperate. I honestly don't even remember the language the original code was in but I imagine it wasn't something common and it was very difficult to hire people with the knowledge to help keep it going.

Krazy

@Borstock said:
Probably reported a hundred times, but on my Android, if I'm playing a match on wifi and walk out of range of the router, when the match ends, the game freezes on the blue screen. Previously, I just had to wait for my data to kick in.

Similar problem when loading, put your phone in "Airplane mode" (disable data/wifi) start MPQ up.
Watch the game load to 42% (then it stalls)
Disable "Airplane mode" (enable data) and wait... (5+ minutes)
Pre-Unity you would wait about 5 seconds and the percentage would resume going up, and MPQ would finish loading.
Pre-Unity would also display something like "Check internet connection" while it was stuck.

In short, the retry logic for "Check network connectivity" appears to be broken.
Not high on the priority list, but definitely an easy to reproduce item (on Android)
Your only option is to force kill MPQ.

KGB

@LavaManLee said:

@entrailbucket said:

@DAZ0273 said:
None of this is putting me in a happy place. Fine, you can share it. EntrailKGBucket. You are now both our representative. Ohhh, like that time Prof X and Caliban got merged in that X-Men comic book! I expect this will go similar - I KGB wish to comply but I EntrailKGBucket do not! Meanwhile Kulan Gath is wrecking the game. Sigh

Tl;dr companies that greenlight "let's rebuild The Reason We All Get Paid, from scratch" are either stupid or desperate (and sometimes both).

I am choosing to assume that this particular rebuild is "desperate," because I prefer not to consider the alternative.

I'm guessing it has to be desperate. I honestly don't even remember the language the original code was in but I imagine it wasn't something common and it was very difficult to hire people with the knowledge to help keep it going.

I suspect it was done in 3 different languages, one for PC/Steam, one for Apple and one for Android. So they had 3 code bases they had to maintain in 3 languages. It's easy to see how that gets labor intensive when you need to make changes, especially if a developer leaves who is say maintaining the Steam version of the code. You get 'stuck' because you can't update the other 2 versions until you get a new developer up to speed on the Steam code base.

Hence the desire to go to 1 code base for 3 platforms.

KGB

P.S. EB, I agree with you 100% on the number that came in on time/budget. It's always zero. But you can put our company on the list of ones that managed to do it. In many cases obsolete hardware or operating systems forces the issue (it did for us).

Bustapup

Some of u guys need to relax and give the Devs a break about this engine. They're trying to make it better for us in the long run and these are teething problems. The fact they're communicating with us actively about this is already more than what a lot of gaming communities get and it sounds like they're fire fighting a thousand issues right now that won't all be fixed in a day.

The game has had the same restrictive engine since launch and if these early issues are a step on the path to eventually being able to> @Chrynos1989 said:

@BriMan2222 said:
Okay, so pvp is completely broken now. I'm in slice 2 and my alliance mates across all slices are reporting the same issue, the game will only show you teams worth a few points as if you've climbed really high and broken mmr, except this is happening almost immediately.

It was a slog to climb to 500 points because the game will only show me 5 point teams and an occasional double digit team.

I guess everyone will have to go for 50 wins, because nobody is climbing over 1200 with things how they are.

Yup, if they can‘t fix or restart the event (2nd most likely not possible), it’s 50 wins

I WAS getting this but I'm not anymore...its gone back to the usual meta teams

entrailbucket

@LavaManLee said:

@entrailbucket said:

@DAZ0273 said:
None of this is putting me in a happy place. Fine, you can share it. EntrailKGBucket. You are now both our representative. Ohhh, like that time Prof X and Caliban got merged in that X-Men comic book! I expect this will go similar - I KGB wish to comply but I EntrailKGBucket do not! Meanwhile Kulan Gath is wrecking the game. Sigh

Tl;dr companies that greenlight "let's rebuild The Reason We All Get Paid, from scratch" are either stupid or desperate (and sometimes both).

I am choosing to assume that this particular rebuild is "desperate," because I prefer not to consider the alternative.

I'm guessing it has to be desperate. I honestly don't even remember the language the original code was in but I imagine it wasn't something common and it was very difficult to hire people with the knowledge to help keep it going.

Oh I'm sure it was a complete disaster, regardless of language or platform. What little we know of it was completely insane, like there was an entire employee whose job it was to code up new events by hand. Every power had (at least) two implementations -- one for normal cases and one for when Thanos's purple CD was out.

I'm still not sure I'd have signed off on a rebuild! The bar for this sort of thing needs to be very, very high. There's a reason your bank still has a 50+ year old mainframe running COBOL somewhere in its basement, and that reason is not "nobody ever considered rebuilding it!"

DeNappa

The graphics lag, stuttering and battery usage is just. so. bad.

It is a shame because if you put that aside for a moment you CAN see the work they put in. Most shizzle DOES actually work. Which, for such a fundamental engine overhaul, is not unimpressive.

Tpsimoes

@KGB said:

@entrailbucket said:

@KGB said:
Unity is coded in C#. Unfortunately C# is a tremendous memory hog that has never done a good job of clearing up unused RAM. We use it a work for our GUI and when we first created ours it steadily climbed in RAM usage from a few hundred meg to 2 gigs over time getting slower and slower (sound familiar). The garbage collector is supposed to free RAM but it does a lousy job of it. Eventually we had to redo most of our GUI and make everything long lived (ie no creating and destroying things in RAM) which used more RAM initially but stopped the infinite climb of memory due to stuff not being garbage collected when changing pages/screens etc.

Today after doing DDQ + Shield Training (I replayed one the easiest nodes 10 times to complete the Storm quest) my phone was down to 70% battery. A quick look in Android at who used battery said MPQ used 22% in 45 minutes of play time.

It also says the game is using 1 Gig of RAM! That's a HUGE amount of RAM for a simple game like this. Lucky my phone has 6 Gigs but I bet a lot of people who are having really bad experiences (lots of crashes) are on older phones/devices that have only 2 Gigs and their device is running out of RAM really fast.

KGB

Unity is used by a pretty wide majority of all mobile games and apps and almost all AR and VR games and applications. C# is likely used by millions of applications in all sorts of categories.

These things are tools and they're as good as the developers using them. Plenty of applications on other platforms leak memory or hog resources, and plenty of C# or Unity applications run just fine. The absolute last thing we need at this point is to start second-guessing their choice of platform/language.

I'm not second guessing. The only choice in Unity is C# so there is no 2nd guess anyway. What I was pointing out is that C# was supposed to be a panacea for development in that it managed memory for you so developers didn't have to worry about it. Unfortunately its not turned out that way in the real world and you often have to code things in specific ways to avoid the pitfalls of the language.

The exact same thing happened to my company when we switched to an all C# GUI. It took a lot of effort to redo a whole bunch of sections of code to get things to where they needed to be (our GUI has to run for many days straight with the user interacting with it so it mattered that it got very slow over time).

KGB

Probably something is preventing the Garbage Colector to work as expected, although its very common to occur that with high memory comsuption processes ... They could try using parallel and concurrent garbage collection...

revskip

Since we are supposed to be putting on a happy face for the rollout here are my notes for the most recent update:

The handwarmer the app provides will be very nice in the winter time. Hopefully the cooler weather then will help with the battery drainage.

Matchmaking updates are sweet. Got my 50 wins in record time, 6 points a clip. As a bonus I can no longer see who is hitting me since the devs didn't want me to feel bad and retaliate. So no reds popping up. As a 2nd bonus I can no longer see the dudes I usually like to play against and instead now get to beat up on seals and the occasional walrus without getting to the 3rd turn. All of which is awesome since I can't see how long my shields would be up for anyway.

They have really stepped up the speed of the PvP matches too. Thankfully PvE is much closer to the fantastic pace it has been on lately. Each clear takes an extra 15 seconds after clicking the go button and then another 15 seconds or so waiting for blue screens after the match to add some tranquility to the open and close.

You can really see how much effort they saved on testing these great changes, morale has never been more discussed among the players I interact with. And CS has also pitched in on the speed front, my outstanding ticket has now hit the amount of PTO I'm sure those braves souls are receiving from BCS, about 6 weeks worth.

Opening tokens is a fun new pace also. Managed to watch nearly a full episode of the new season of Quarterback on Netflix while working through my daily hoard. Sometimes the buttons even work.

Can't wait to see what new fun things they have planned for the next hotfix!

KGB

@Tpsimoes said:

@KGB said:

@entrailbucket said:

@KGB said:
Unity is coded in C#. Unfortunately C# is a tremendous memory hog that has never done a good job of clearing up unused RAM. We use it a work for our GUI and when we first created ours it steadily climbed in RAM usage from a few hundred meg to 2 gigs over time getting slower and slower (sound familiar). The garbage collector is supposed to free RAM but it does a lousy job of it. Eventually we had to redo most of our GUI and make everything long lived (ie no creating and destroying things in RAM) which used more RAM initially but stopped the infinite climb of memory due to stuff not being garbage collected when changing pages/screens etc.

Today after doing DDQ + Shield Training (I replayed one the easiest nodes 10 times to complete the Storm quest) my phone was down to 70% battery. A quick look in Android at who used battery said MPQ used 22% in 45 minutes of play time.

It also says the game is using 1 Gig of RAM! That's a HUGE amount of RAM for a simple game like this. Lucky my phone has 6 Gigs but I bet a lot of people who are having really bad experiences (lots of crashes) are on older phones/devices that have only 2 Gigs and their device is running out of RAM really fast.

KGB

Unity is used by a pretty wide majority of all mobile games and apps and almost all AR and VR games and applications. C# is likely used by millions of applications in all sorts of categories.

These things are tools and they're as good as the developers using them. Plenty of applications on other platforms leak memory or hog resources, and plenty of C# or Unity applications run just fine. The absolute last thing we need at this point is to start second-guessing their choice of platform/language.

I'm not second guessing. The only choice in Unity is C# so there is no 2nd guess anyway. What I was pointing out is that C# was supposed to be a panacea for development in that it managed memory for you so developers didn't have to worry about it. Unfortunately its not turned out that way in the real world and you often have to code things in specific ways to avoid the pitfalls of the language.

The exact same thing happened to my company when we switched to an all C# GUI. It took a lot of effort to redo a whole bunch of sections of code to get things to where they needed to be (our GUI has to run for many days straight with the user interacting with it so it mattered that it got very slow over time).

KGB

Probably something is preventing the Garbage Colector to work as expected, although its very common to occur that with high memory comsuption processes ... They could try using parallel and concurrent garbage collection...

Under Windows (can't speak for Android or Apple's O/S) the garbage collector runs quite infrequently (think minutes). In a game where players open/close menus and play whole matches in a handful of seconds imagine how much stuff gets allocated between the times the garbage collector runs. What's even worse is that Windows (again can't speak for the other O/Ss) contains no way to truly free heap memory back to general usage by any program. So even after stuff gets garbage collected on the heap it still remains in the memory space for your program. The reason is obvious when you think about it, all the allocations of 100 or 50 or 1000 bytes here and there massively fragments memory so even if you free 50 bytes and another 50 bytes its unlikely you have 100 bytes in a row in RAM free so the next time you ask for 100 it gives you a fresh 100 in a row and on and on it goes until your app uses gigs of RAM.

Ultimately when we went back through our GUI we had to allocate everything once and never release. The only memory you could re-use was stack memory for functions. That fixed things for us.

KGB

KGB

@revskip said:
They have really stepped up the speed of the PvP matches too. Thankfully PvE is much closer to the fantastic pace it has been on lately. Each clear takes an extra 15 seconds after clicking the go button and then another 15 seconds or so waiting for blue screens after the match to add some tranquility to the open and close.

You can really see how much effort they saved on testing these great changes, morale has never been more discussed among the players I interact with. And CS has also pitched in on the speed front, my outstanding ticket has now hit the amount of PTO I'm sure those braves souls are receiving from BCS, about 6 weeks worth.

Opening tokens is a fun new pace also. Managed to watch nearly a full episode of the new season of Quarterback on Netflix while working through my daily hoard. Sometimes the buttons even work.

I see the same on my S9+ only it's a 2-3 second delay each time.

From a programming standpoint it SCREAMS that they are reloading assets (along with anything else post processing that might need to be done after loading like rotations, image resizing etc) on every click. As in going to the disk and reloading the asset and doing post processing. It would explain why things are SO slow on so many of our phones/PCs because older hardware will be much slower to do this over and over again. I suspect if they loaded once and kept a flag on whether it was loaded & processed things would speed up dramatically.

I'd love to get a peek at some of the code.

KGB

Hellblazer666

Jesus Christ scrolling/Token opening is so damn slow on this. It’s the speed of the Aim Soliders. The old engine was much faster in that regard

entrailbucket

@KGB said:

@Tpsimoes said:

@KGB said:

@entrailbucket said:

@KGB said:
Unity is coded in C#. Unfortunately C# is a tremendous memory hog that has never done a good job of clearing up unused RAM. We use it a work for our GUI and when we first created ours it steadily climbed in RAM usage from a few hundred meg to 2 gigs over time getting slower and slower (sound familiar). The garbage collector is supposed to free RAM but it does a lousy job of it. Eventually we had to redo most of our GUI and make everything long lived (ie no creating and destroying things in RAM) which used more RAM initially but stopped the infinite climb of memory due to stuff not being garbage collected when changing pages/screens etc.

Today after doing DDQ + Shield Training (I replayed one the easiest nodes 10 times to complete the Storm quest) my phone was down to 70% battery. A quick look in Android at who used battery said MPQ used 22% in 45 minutes of play time.

It also says the game is using 1 Gig of RAM! That's a HUGE amount of RAM for a simple game like this. Lucky my phone has 6 Gigs but I bet a lot of people who are having really bad experiences (lots of crashes) are on older phones/devices that have only 2 Gigs and their device is running out of RAM really fast.

KGB

Unity is used by a pretty wide majority of all mobile games and apps and almost all AR and VR games and applications. C# is likely used by millions of applications in all sorts of categories.

These things are tools and they're as good as the developers using them. Plenty of applications on other platforms leak memory or hog resources, and plenty of C# or Unity applications run just fine. The absolute last thing we need at this point is to start second-guessing their choice of platform/language.

I'm not second guessing. The only choice in Unity is C# so there is no 2nd guess anyway. What I was pointing out is that C# was supposed to be a panacea for development in that it managed memory for you so developers didn't have to worry about it. Unfortunately its not turned out that way in the real world and you often have to code things in specific ways to avoid the pitfalls of the language.

The exact same thing happened to my company when we switched to an all C# GUI. It took a lot of effort to redo a whole bunch of sections of code to get things to where they needed to be (our GUI has to run for many days straight with the user interacting with it so it mattered that it got very slow over time).

KGB

Probably something is preventing the Garbage Colector to work as expected, although its very common to occur that with high memory comsuption processes ... They could try using parallel and concurrent garbage collection...

Under Windows (can't speak for Android or Apple's O/S) the garbage collector runs quite infrequently (think minutes). In a game where players open/close menus and play whole matches in a handful of seconds imagine how much stuff gets allocated between the times the garbage collector runs. What's even worse is that Windows (again can't speak for the other O/Ss) contains no way to truly free heap memory back to general usage by any program. So even after stuff gets garbage collected on the heap it still remains in the memory space for your program. The reason is obvious when you think about it, all the allocations of 100 or 50 or 1000 bytes here and there massively fragments memory so even if you free 50 bytes and another 50 bytes its unlikely you have 100 bytes in a row in RAM free so the next time you ask for 100 it gives you a fresh 100 in a row and on and on it goes until your app uses gigs of RAM.

Ultimately when we went back through our GUI we had to allocate everything once and never release. The only memory you could re-use was stack memory for functions. That fixed things for us.

KGB

Memory management under Unity is slightly complicated but not actually all that complicated if you've done stuff like this:

https://embrace.io/blog/garbage-collector-spikes-unity/

We have no way of knowing what the actual problem is here. I wouldn't even try to diagnose this without loads more information, but in my professional opinion, they've screwed something up.

KGB

@entrailbucket - That's exactly the kind of stuff we ended up doing in C#.

Another thing I just confirmed from playing earlier today. It appears there is a sound effect that gets played on a timer that isn't being cleared (yes I play with sound - LOL) when a battle ends/character dies. Go into the Shield Training and play the last node on the right for day 1. The one with the AIM Mecha in it. There is a timed beep sound that plays every 5-10 seconds (I think I remember it playing when his CD moved in the old app). Play a turn or so until you hear it play once. Then win/lose/exit the battle. Now listen carefully and it will continue to play over the background music every 5-10 seconds or so. It does this forever until you close the app. Then it's gone. I'll post this in the bug forum.

KGB