madrussian

Good ideas zapat. Maybe another twist on the long-distance-drive solution is to simply detect enemies along the route via findNearestEnemy or similar and move the reemergence point inward toward the objective accordingly. (And make it a bit random so you can't always know exactly when you are going to encounter pre-objective enemies.) On another note, are the people having crashes all using ACE? If so maybe there's a correlation. I've played this mission quite a bit with no crashes yet (and all w/o ACE).

Hey no problem at all. Feedback is the easy part. :D And glad to see you implementing so many suggestions! Couple more suggestions on KIAs. Hopefully not too hard to do, but when they are dead have "KIA" right on their picture in white. I've seen it in other games and it really adds something. Also, I'm thinking about the idea of maybe leaving the KIA guys in the Squad Structure, so you have to take them out manually and thus really feel it. But then that would make things less streamlined as well, unless you could just drag a new guy directly on top of your KIA guy, who in turn populates the KIA list. So in short, you could allow the user to both: simply drag KIA guy out -or- drag new guy to slot and remove KIA guy that way. That's basically what I was thinking, just would like to know how men killed/remaining. For the fancy version, maybe you can pull up detailed info on both squads, similar to in original GR1. Interested if we can expect to possibly see enemies outside the immediate objective area if we receive such info on the Support section of the Field Intel page? So far I've only seen "weak", etc. Does "weak" always mean "no enemies" in this case? I mean the initial intro. One of your earlier posts seemed to suggest that it was causing the lengthy mission startup. But sounds like if this is the case, simply skipping initial intro removes any additional waiting? Let's see, by "set piece missions", I was thinking something along the lines of one or two, maybe three special missions that fall outside the normal randomized ones. For instance, maybe the final mission could be an all out assault (either attack or defense, perhaps based upon how you did on all the previous missions), where ALL remaining soldiers under your command are involved in a life or death struggle against a formitable rebel force, with no option to retreat. Or maybe the entire platooon retreating is the final mission. A mid-point "set piece" mission might involve a convoy ride, where suddenly you men are being ambushed. I can think of all kinds of special mission ideas that don't involve the normal setup but that would add tremendous variety. The set piece missions would perhaps be more heavily scripted, but could have many random elements in-and-of themselves. I'm thinking also, even after playing the campaign over and over again, once you get somewhat used to the standard random missions, you would still have that "final epic struggle" to look forward to, etc. Maybe you can come up with a "King Nothing's Forgotten Few Custom Campaign Designer's Guide". Half kidding. :D I hear you on the difficulty of MP scripting. Two schools of thought, neither is very pretty. First is start with SP and when you get it finished start over and build up the MP piece by piece. But with this method you're probably so exhausted after the SP that you never start the MP. Second, build it MP from the ground up. Sounds like a wise choice, but you'll likely burn out and never finish any of it! Anyhow, no promises, but I might have a look and if I'm feeling brave maybe even try my hand at an COOP conversion. Because your mission is so close to what I've always been striving to create anyway, why re-invent the wheel from scratch? I did find potentially a new issue: 13. During the planning phase, if you lose the menus (by pressing ESC enough times, etc), there appears to be no way to get the menus back. Even clicking on the map doesn't help. Perhaps a radio option during planning to restore the menu? And a quick question on revive. No revive? I certainly haven't gone into wounded state or seen it happen to any of my men. If that's the case, I wholeheartedly applaud the decision. Imo, that's part of what made Cipher so incredibly successful.

Innovative, polished, and streamlined. Simply amazing King Nothing... well worth the wait. :) To those playing this: I highly recommend deciding from the beginning, absolutely no reloads. Play it through starting at mission 1 and try like hell to stay alive through mission 7. If you can manage this play style, you're in for one totally immersive and death defying experience. A handful of suggestions / other feedback: 1. This is the first mission I can recall where I really cared about my soldier's individual lives. But strangely, once they die, they disappear from the Manage Platoon section. How about a KIA listing to the right of the Reserves list? 2. As it stands, imo right now the soldiers are pretty interchangeable, and while I want drastically want to keep them alive because I have to make them last though 7 missions, there's not much distinguishing them from one another (aside from the abilities). How about reporting how many missions a soldier has survived? For instance, on the Squad Structure page, there's a perfect amount of space to the right of a soldier's name for this. Example: "Torch 6: Feliks Stratvoytova (2 missions completed)". That would go a long way to being able to tell who's been with you since the beginning, and make you feel a greater loss, when you lose them. 3. As it stands, there's no quick way to get the status for Spark squad. How about a Status button on the Spark Control menu? Ideally it might be a fancy dialog, but even a simple solution would work, like upon selection Spark squad leader radios a verbal status, etc. 4. Consider making control of Spark squad radio 0-0-0, as it's probably the most frequently used. Plus in the heat of combat, that makes it quick and easy to issue them commands on the fly. 5. Seems like time of day/weather is getting set moments after everything fades in and you are facing the insertion vehicle, and it's kind of an immersion breaker. Ideally do these transitions while everything is faded to black? 6. Might come in handy, but an option to cancel CAS (once it's already in progress)? 7. I simply love the "fast travel" via ground, where everything cuts to black, time passes, and suddenly you're much closer to the objective. However, you still end up WAY back and still have a long way to go. Any chance of moving this "fast travel" reemergence point in toward the objective significantly? (Imo any amount would improve matters.) 8. The intro is simply awesome! But once you've seen it a couple times... well we all know how that goes. So considering the long mission startup time is due to the intro, how about an option to skip the intro outright? I.e. A small file in the "ArmA 2\userconfig" folder, etc? (Just in case you've never tried pulling in user settings from a hpp file, it's easy and quick, and could explain in a quick PM if necessary.) 9. Seems like there are a significant amount of night missions, which may or may not be everyone's cup of tea. Maybe an option to limit them in some way? 10. So far I've made it to mission 3 (and got cut down in my prime, oh the humanity!!!) Are there any "set piece" missions? For example, a final showdown in the capital Chernogorsk? If not, how hard would it be to integrate something like this in? (i.e. Aside from creating the mission itself.) 11. Are you open to other mission designers creating / releasing missions using your "engine", provided the mission idea is different enough and you get full credits, etc? I'd love to see such a mission from the rebel perspective. 12. This mission is screaming for COOP!!!!!! Torch and Spark, come on! :D (Just so we're on the same page, I do have some concept of what a MASSIVE undertaking that would be.) In any event, keep up the good work! Can't wait to see what's next!

I can generally get the weapon direction for any desired turret, with a bit of help from UNN's thread here. However, it appears this technique may not work in certain cases. Normally, to get a turret's weapon direction, you simply get the "body"/"gun" values from CfgVehicles, and use them to compute the weapon's direction (via animationPhase... detailed in UNN's thread). Normally, this technique works like a charm. However, with Mi17_rockets_RU, the rockets ("57mmLauncher") are fired from the pilots seat (driver). They are NOT in a turret and thus do not have "body"/"gun" values. (Also, as expected, you can't simply use weaponDirection, because it's not a weapon of the main gunner, the Crew Chief in this example.) I'm pretty stumped here. Any ideas on how to get weapon direction is this case? :)

Let's see... I have indeed been using the assignedVehicleRole/crew method to determine which turret fired. However, unfortunately as for determining weapon direction, it seems that the weaponDirection command still only operates on the main gunner. So I suppose for turrets, we are indeed stuck with the animationPhase method to determine direction, until BIS gives us something like a turretDirection command. Anyhow, thanks again guys. btw- Seems I'm still stumped on getting weapon direction for driver seat weapons. Are they really all bore-sighted 100% straight forward? Anyone know for sure? Any insight from BIS devs?

Thanks for the responses guys. Seems like perhaps a reasonable assumption. Anyone know if in real life rocket tubes are 100% straight with the vehicle? Seems like maybe they might want them pitched slightly downward instead? I could make an assumption one way or the other here, but it's very hard to test this ingame without a precise way (direct or indirect) to calculate weapon direction. When I check the weaponDirection spec, it looks like: Please correct me if I'm wrong or there's another way of doing it, but seems pretty clear that weaponDirection only accepts a vehicle and a weapon, and not a turret path? And the comments on the spec page below the command certainly appear to support this assumption, and point me to your thread UNN regarding the animationPhase method. :confused: So indeed the only way I've ever been able to get a turret direction is via the animationPhase method (and yes it works perfectly after a calculation to get [x,y,z] direction, but it's always been a bit unwieldy). Is there really another more direct and convenient way??? And if it turns out there is no other way and BIS is reading this, we could really use a new turretDirection command, that accepts all possible turret paths including [-1] for the driver seat!!! :D Again, many thanks guys for your comments and info. :)

Gotta love Rummy. :p Ooooh CarlGustaffa, I think you may be onto something. Appears based on your observations, there are multiple knowsAbout thresholds (at least since Arma2). Who knew?

Something new just dawned on me! :don 13: It appears that a unit can consider another unit "known" (in terms of countUnknown), but still not "know about it" (in terms of knowsAbout). So it's interesting that groups indeed share "known/unknown" info (detected via countUnknown) with other same-side units, as detailed above in #4. But apparently, it's kind of a low-level system thing. They still won't react until their knowsabout level to another unit surpasses a certain threshold. In other words, the two systems ("known vs unknown" and "knowsAbout") apparently run separately, and only when a positive for each system is in place, does a unit react. All the while, same-side units will go on continuing to silently inform one another of everything that is "known/unknown" to them, all without informing on "knowsAbout". In the mean time, "knowsAbout" must be gleened individually by each group and is shared only by units within the same group. The only exception to this "knowsAbout" part would be scripter intervention via the reveal command. Thoughts?

Hey thanks for the responses! :) I've done some extensive additional testing on this issue... The results encompass far more than just this topic specifically: Here's the new thread. EDIT: OK guys, I think I've made sense of all this. Thanks again for the insight so far... every little piece of info has helped me figure out what to look for. Advise reading through the entire 1st post on that other thread and then come back for my conclusion on this issue: In the beginning, I made the claim that "Unknowns always end up Enemy", or something to that effect. It's a bit more complicated than that. In the other thread I talk in length about a Troop Marker System I have developed to gain insight into exactly what's going on. With this system, I can see visually via marks on the map, exactly who the player knows about and who he doesn't, all in real time. First off, some terminology. As far as I can tell, there are two main types of Reveals: 1. Silent Reveal - One unit is revealed to another and no one says anything audible. 2. Audible Reveal - One unit is revealed to another and it gets announced verbally. Note that in simply playing the game, you would probably only be aware of Audible Reveals. However, there are Silent Reveals going on all the time though, behind the scenes, and you can track them via countFriendly, countEnemy, and countUnknown. My Troop Marker System tracks (among other things) Silent Reveals and visually displays the results on the map via markers. (Note I am not using any mods except CBA and a small mod that adds some simple markers to MarkersCfg.) Turns out there are a LOT of reveals that go on silently, and you only audibly hear a small fraction of them. That's a good thing too, because otherwise it would overwhelm you're radio! :D What my research has proven to me is that vehicles and unmounted footmen of same-side friendlies start out and remain as known. Now, people have made claims that unknowns have turned out to be friendlies. I have come up with two distinct cases where that can happen: 1. When a friendly same-side footmen dismounts, he remains unknown for a brief moment. That's when he might get audibly revealed as unknown. After that brief moment though (weather audibly revealed or not), no matter where he is or if anyone can see him, he will become known to the player!!! :eek: 2. My testing has revealed that friendly NON-same-side units go by a different set of rules. That may be the source of some of the claims that unknowns end up as friendlies. Now, in extensive testing, I have never had an AI audibly reveal a civilian. I know some of you claim you've seen it happen, and it probably has. But I did run a test with a gigantic civilian army coming over the hill towards my group (me the player and a single AI). He silently revealed everyone, one at a time. But none of those was audible. And we talking ~30 foot civs and ~30 civ vehics. So if it happens, it's hardly ever, and possibly, it has to do with dismounting per previous point about same-side friendlies. So after everything I've seen, I'll no longer claim that "Unknowns always turn out to be Enemy". But I will say with high confidence that an extremely high percentage of Unknowns turn out to be enemy. Those that don't are the rare exception. In any event, I hope that BIS views this as a real issue worthy of some kind of resolution. :)

I just made what appears to be a terrible discovery. Please someone tell me it isn't so! :eek: So I was messing around with knowsabout when I noticed these three count commands (way back from OFP apparently): Kind of intriguing... so I set about to doing some experimentation. In the editor I created one West soldier as the player and put one other West man in his group, way on the other side of the map (just so the player unit would have someone to reveal targets to). I created three target soldiers (one East, one West, one Civ). Then I wrote a small script to try and determine the knowsabout value the moment a target is revealed (changes from a "Unknown" to an "Enemy", etc): MRU_Hint = compile preprocessFile ("Library\MRU_Hint.sqf"); MRU_HintS = compile preprocessFile ("Library\MRU_HintS.sqf"); _TEST = { sleep 3; _lowestEnemyKA = 0; _lowestDist = 0; while {true} do { _countFriendly = player countFriendly [Loon]; _countEnemy = player countEnemy [Loon]; _countUnknown = player countUnknown [Loon]; _playerKnowsaboutSubject = player knowsabout Loon; _dist = player distance Loon; if ( (_countEnemy == 1) and (_lowestEnemyKA == 0) ) then { _lowestEnemyKA = _playerKnowsaboutSubject; _lowestDist = _dist; }; sleep 0.01; // Simple Hint: ["_countFriendly","_countEnemy","_countUnknown","_playerKnowsaboutSubject","","_lowestEnemyKA","_lowestDist"] call MRU_HintS; }; }; [] spawn _TEST; // Note - Script changes slightly based on the subject of the test Test 1 - The Enemy East unit Enemy unit is placed at a great distance away from the player. As expected, he starts out being registered by the countUnknown command. (Note if you don't add a minor delay prior to detection like my sleep 3, then for a split second he'll be registered by countEnemy due to initialization etc, prior to being registered by countUnknown.) As this point, I the player (again a West unit), place my crosshairs on the man and perform a series of manual "Reveal target"s on him (remapped to make things easier). The moment the knowsabout get's bigger than zero, my player unit correctly verbally identifies that enemy man as "Unknown". As I continue to perform manual "Reveal target" and edge ever closer, the knowsabout value gets bigger, again as expected. At a knowsabout value of 0.225002 (probably 0.225 due to rounding errors), and (incidentally) a distance of 295.806m, two things happen simultaneously: 1. The player unit correctly verbally identifies that enemy man as Enemy 2. The enemy man is no longer registered by countUnknown, and is now registered by countEnemy. Everything good so far! Test 2 - The Friendly West unit This time, the friendly unit starts out and continues to be registered by countFriendly, even though he's extremely far away and knowsabout is 0. Just to be sure I restart the mission with the friendly unit all the way across the map, with plenty of hills, etc in between. Same result, registered by countFriendly, even though the player unit has no way of knowing about him. :confused: Then I restart the mission with the friendly unit in view but very far away, and as with the Enemy East unit test, I do a series of manual "Reveal target"s as I get closer and closer. Only this time, when the knowsabout value gets bigger than 0, it jumps straight to 1.6, and most importantly the player unit does not verbally announce anything! No announcement of Unknown or Friendly... nothing! :butbut: Test 3 - The Friendly Civ unit Results are identical to the Friendly West unit test, except for that if the Civ unit starts out of view, he is registered by countUnknown, until the knowsabout value goes above 0, at which point he's registered by countFriendly. Again though, no verbal announcements are made at any point as to his Unknown or Friendly status. :confused: Conclusion: Anyone verbally announced as "Unknown" is the enemy. Kill them!!! In any event, I'm really hoping I've missed something here and it's not really this way. Maybe someone can manage to disprove some of my apparent results? :) That or perhaps BIS can start looking into a fix for this. After all, what's the use of having an "Unknown" status anyway, if you automatically know they are all really Enemy? Edit - Updated Conclusion: Based on my own tests (originally provided above in detail) and anecdotal evidence provided by others on this thread, I am revising my conclusion slightly: Anyone verbally announced by the player unit as "Unknown" is the enemy. Kill them!!! Hopefully we can get some resolution here...

Interesting Beagle... good to hear that you are experiencing AI identifying friendlies as unknowns. That wasn't part of my testing, but it does make me feel a bit better about all this for now. In any event, I did repeat my results several times before posting this find. Read back through exactly what I did, try it exactly as written, and see if you don't agree. Note I was using exactly one AI in the player group, and placed him all the way on the other side of the map, just so I (the player) could "Reveal target"s to him. Thus no AI was identifying anyone as part of any of my testing. So, there is a chance it's just like in dwringer's theory, where "the player is only allowed to call out unknown enemy targets", which imo would be a signifigant issue. This whole thing needs some more investigation for sure. If someone can prove my claim wrong with a very specific controlled method, I'll definitely revisit my test cases and have yet another look. On this type of thing, indeed I hope somehow I'm proven wrong. Cheers. :)

Thanks for weighing in guys. :) Well if indeed AIs can still identify unknown civs (and I haven't tested that), that's something, but then we're left with: 1. Any target player identifies as Unknown is actually Enemy and should be shot on sight! 2. Friendlies are never announced as anything? (i.e. not by player or AI?) ...If confirmed, both of these are still very bad imo. Another test I ran in the mean time: Test 4 - Empty vehicle Yet another distinct result. If placed out of view, upon startup empty helo is registered with countUnknown. Upon the player seeing it, as with the civ man, empty helo then registers with countFriendly. However, where as at this point the civ man was not announced at all, the empty helo is announced... but only via chat message!!! (i.e. Empty helo not verbally announced.) This is truly fascinating stuff. :D edit: btw - I wonder if the issue goes all the way back to OFP? Curious what you guys think? I suppose that might be happening (no current test to prove it though). Might be kind of cool actually, in situations such as jumpy soldiers in the middle of the night, etc. But to get very specific here, my discovery seems to be simply that the player can glean info he shouldn't be able to glean on who is Enemy based on the "Reveal target" mechanism... specifically the inferences he can make based on what his unit (and quite probably the AI) announces verbally.

There are several very useful commands, if only I could get them working on the Main Map: However, they all require a Control as an input, which I'm assuming in many cases would be a custom dialog with an embedded map, etc. But it seems like these commands should work on the Main Map as well? For instance, to latch onto the main display, you can use something like this: Is there something similar to "find" the Main Map for use with these powerful map commands? ------------------------------------------ SOLVED: To get the default Main Map control: _defaultMainMapCtrl = (findDisplay 12) displayCtrl 51; Best of all it actually works with all those powerful ctrlMap commands. Thanks Das Attorney and PVPscene, wouldn't have gotten it without you guys! btw- In future BIS games, the display and control IDs for the main map might change, but the method used to get them should be the same (see detection script in post below).

Nailed it!!! For those who just want to know how to get the control for the default Main Map (which incedentially works with all the ctrlMap commands), just check the bottom of this post. For those interested, here's how I figured it out: After cracking open PVPscene's MapReplacement code and having a look, I found the place where he latches onto his replacement map: At this point it occurred to me that displayCtrl is the key, and the default Main Map is really just a control inside of a display (display #12 to be exact). So, I then cracked open ui.pbo to try and locate idc #12, hoping to find the control of the main map inside, (doing a find in files on "idc = 12;"). Unfortunately, it's just not in there (or else I simply couldn't find it). Not to be deterred, I thought up a brute force approach of locating the default Main Map inside "display #12". The idea was to check every idc against (findDisplay 12), and try ctrlMapScale on all valid Controls. Here's the script: waitUntil {!(isNull (findDisplay 12))}; BUB_TestedMapControls = []; BUB_TestedMapScales = []; _testMapControl = { _id = _this select 0; BUB_TestedMapControls = BUB_TestedMapControls + [_id]; _displayCtrl = (findDisplay 12) displayCtrl _id; _scale = ctrlMapScale _displayCtrl; BUB_TestedMapScales = BUB_TestedMapScales + [_scale]; }; _misses = 0; _hits = 0; _i = 0; while { true } do { _displayCtrl = (findDisplay 12) displayCtrl _i; _typeName = typeName _displayCtrl; if ( (str _displayCtrl) == "NO CONTROL" ) then { _misses = _misses + 1; } else { _hits = _hits + 1; [_i] spawn _testMapControl; }; hintSilent format ["_i: %1\n\n_displayCtrl: %2\n_typeName: %3\n\n_hits: %4\n_misses: %5\n\nBUB_TestedMapControls: %6\nBUB_TestedMapScales: %7", _i, _displayCtrl, _typeName, _hits, _misses, BUB_TestedMapControls, BUB_TestedMapScales]; _i = _i + 1; sleep 0.001; }; breakOut "ExitOut"; Turns out there are 32 unique and valid controls inside of (findDisplay 12). And #51 is the Holy Grail! :D To get the default Main Map control: _defaultMainMapCtrl = (findDisplay 12) displayCtrl 51; Best of all it actually works with all those powerful ctrlMap commands. btw- Thanks Das Attorney and PVPscene, wouldn't have gotten it without you guys! :)

Hey PvPScene, I sent you a PM on that. Sounds interesting, and I'll definitely check it out! Specifically I'm interested to know if MapReplacement retains the default map features, like moveable waypoints for the player group (when shown), which I need for my mission. In the mean time, can anyone say with certainty that there is any way to get these ctrlMap commands working on the default main map? Hunches are welcome too. :)

Based on doing some extensive work in the anim configs before, my guess is what you are after is possible, but *extremely* time consuming. Start out by checking out CfgMovesBasic and CfgMovesMaleSdr.

Hey thanks Das Attorney. I just fired up a quick mission and tried to trap a mouse press on the Main Map using findDisplay 12 like this: And guess what? It worked!!! You the man! Btw- Now I wonder how UNN ever figured that out in the first place?!? :D Now I'm off to try it with those ctrlMap commands... EDIT: Just tried: And... No dice. :confused: Hmmm... Now I'm wondering if there is an equivelent "find control" method similar to (findDisplay 12) to access the Main Map for these commands???

OK, I figured out how to make WPs show up on the map and hide them, which is via showWaypoint. (Tried that before but I must have borked something up.) Still stuck on two things: 2. Make these now map-visible WPs non-moveable. 4. Show WPs on the map for friendly groups other than the player group. Any suggestions?

Hey guys, I just discovered that in ArmA 2, upon adding waypoints to the player group via addWaypoint, these waypoints show up on the map and are actually moveable via the mouse. Extremely nifty! I'm attempting a Total War style mission system (with distinct "turns" and strategic map/action phases, etc), and this built in ability to easily modify WPs would really come in handy. However, I'm running into some issues here: Any help or insight is much appreciated as always. :)

The Singularity already happened a long time ago. This is all simply one big sim of humanity's past.

Wow! Keep going TRexian! :) Next request: Optional parameter for a single group to storm (and/or occupy) multiple buildings. OK, now I'm getting greedy. :D But in reality that would add a ton of new dynamics and would probably make things that much more terrifying. Can you imagine a group of say 10 or 11, splitting up (without leaving the physical group) and storming 3 or 4 different buildings? Might be worth the effort!

So I have always assumed that building positions are in no particular order to begin with? However what you are saying implies there is some implicit order of building positions? I do wish there was a way to distinguish between indoor and outdoor building positions. Well Tophe's has them moving around in the building. I was thinking of more along the lines of a group moving into individual positions and then staying in place. That would probably be useful, in terms of mixing things up. I am interested to see your wrapper! If we had an occupy function though, we'd probably get a few more people creating different wrappers... I'd definitely give it a shot. :) btw- Good to hear you were able to implement optional leader takeover! Yeah I can see that both ways. Probably doesn't matter much, but again, maybe shuffle the unit array before sending them in, for more variety?

Wow! Guess I'll see for myself when I get a chance to fire it up, but from your description it more or less sounds like they really storm the building! Couple of other quick suggestion I can think of: 1. How about shuffling the order of building positions upon each call, so we don't start to recognize the sequence that particular buildings get stormed? 2. Maybe an optional parameter that upon sending the men into the building, they stay there and occupy it indefinitely? Perhaps for indefinite occupation, another function call causes them to exit? Regarding having the leader go in too, there are plenty of times where I only have one man in a group, for instance when creating a bunch of small groups in DAC and then releasing them from DAC. Many of those groups end up with only 1 man, and it would be nice to have him go in too. Maybe make it an optional parameter? Because I can also see how if you do have a group with more than one, that the leader might indeed want to "order his men in" and keep himself out of danger, etc. In any event, optional seems best to me. :) btw- Thanks for putting this together. I think it's really going to come in handy.

Very nice! IIRC, in Tophe's the AI were just placed into a building and were restricted simply to that building. This appears much more versatile! So when you say "trail through the building", do the AI go to the building positions in order, or is it random? Also, any chance of getting the leader to enter the buildings too? That would be really useful, but harder to get it scripted I assume.

http://www.cnn.com/2010/WORLD/asiapcf/11/23/nkorea.skorea.military.fire/index.html?hpt=T1&iref=BN1 Holy Mother of God, this doesn't sound good. I hope it doesn't escalate any further.