UT 2k3/2k4 RainbowSix mute would like some testers

[Kyle Kellahshehskee]

InvasionPro configs listed...body movement sounds...?

Meowcat wrote:

I'm working on a fix now.

SWEET!

Seriously, I can't help but think that making YARM friendly to Invasion-muts as being a huge bonus for the mod and those that take it out for a whirl. I'd go so far as to state in the Read Me that it's "Invasion-muts friendly" because if you read up on muts like InvasionPro, there are a ton of muts that don't work with it. This way, people get their cake and eat it too.

Meow, if you'd like, I'll post up my config files for InvasionPro (and, if time permits, other Invasion-type-muts) here for others to use, should they so wish. Setting up the config is VERY counterintuitive. I have to give credit where it's due, as it's clear from InvasionPro's team that they went to great lengths to create a thorough write up for their release, but it misses some very important points that have been a huge headache for me to stumble through. The most obvious one being that the config SHOULD be manually setup before the gametype is even fired up in UT2K4. And that this newly altered config SHOULD be BACKED UP before the gametype is started, because once it has been activated in the game, the config file's structure changes RADICALLY (causing confusion), and just about as unfriendly a structure to make changes with as one could imagine. By backing up the altered config BEFORE trying it out, one's preserving the ease to modify it later. IP's Read Me says nothing about such a simple step that will save a TON of grief later.


Also, I'm still waiting to hear from several highly regarded modders who created some fantastic realism mods for other titles such as OFP and Combat Mission Shock Force. I'm hoping that if I get the OK from them, that we can use their highly regarded sound effects in YARM. If I don't hear from them by Sat. morning, I'm planning on then downloading one bullet fly-by to send your way, and several body movement sounds so that I can cobble them together so that when a bot/player leans we can hear their equipment shifting/rubbing, and this sound would also greatly enhance movements such as going prone/standing. Now I already know from what you've written earlier that it's possible to make bullet fly-by's a client-side option, is it just as possible to assign sound effects to the leaning/proning/crouching actions? If not, then I won't bother wasting my time downloading the needed files/cobbling them together. Let me know.

Yours!



~P.S.
I'm blown away by Epic's generosity in making the Unreal Engine 3 an open source engine. What a potentially HUGE boon to all PC gamers, and to "little" but determined and envisioned game creators. Wow!

 

[meowcat]

See my previous post EDITs. The crash is due to the way InvasionPro is coded, not YARM. I may add an ugly "fix" in the future but no guarantees. Do other Invasion mutators crash with YARM (like Satore)?

 

[Kyle Kellahshehskee]

Meowcat wrote:

The crash is due to the way InvasionPro is coded, not YARM

Sheesh! Not good news, but if InvasionPro can be saved through your "ugly fix" then that's another selling point for YARM, as far as I'm concerned.

In regards to whether or not I've tried other Invasion gametype muts, the answer's "Yes." But I didn't get any of the other two to work properly (thus they potentially could work with YARM, but since I couldn't get them to work for me, I can't say one way or the other), plus (if I'm not mistaken), InvasionPro was released after MonsterManager and Satore. IP's Read Me makes reference to the two, saying that they're not compatible with it, and I'm sure that I read on a forum posting that it addresses issues the other two don't.

So, I'm assuming that if InvasionPro's fixed, the other two might be addressed as well. I can't say for certain. We can hope!

 

[Kyle Kellahshehskee]

Possible to assign body movement sounds...?

Meow,

Do you want me to gather up/create sound effects that can be assigned to body movements such as leaning and going prone? Again, I don't know if this is possible to do with UT2K4's engine, so if you could just give me a quick "Yay" or "Nay" it'd be greatly appreciated.

I might get started on them earlier than what I planned; tonight maybe.

Yours,
Kyle

 

[meowcat]

I would like to add movement sounds (I loved them in the old RainbowSix game). Rather than spending "credits" downloading them, if you were even able to come up with methods for making appropriate sounds (eg: brushing jeans together, jingling change in a pocket) I could try and record them on my end. I'd like to stay away from using any other mod's/game's/person's work as much as possible (Grobut's AK/Bizon skins, and SI's code parts being exceptions) so if I can record them myself I will. I use the freeware program Audacity for all of my recording/editing.

 

[Silver_Ibex]

@MeowCat: While playing your Shipment map I have noticed the weapon pickups tend to get shot out of place often, and sometimes this leaves bots running in place over the misplaced guns trying to pick them up.
I think I have a fix for this problem, only have character dropped guns be Projectile targets.
In WeaponPickup_yarm.uc defprops set the bProjTarget=False

Then in the Gun_yarm.uc

function DropFrom(vector StartLocation)
{
    local int m;
	local Pickup Pickup;

    if (!bCanThrow || !HasAmmo())
        return;

    ClientWeaponThrown();

    for (m = 0; m < NUM_FIRE_MODES; m++)
    {
        if (FireMode[m].bIsFiring)
            StopFire(m);
    }

	if ( Instigator != None )
	{
		DetachFromPawn(Instigator);
	}

	Pickup = Spawn(PickupClass,,, StartLocation);
	if ( Pickup != None )
	{
    	Pickup.InitDroppedPickupFor(self);
	    Pickup.Velocity = Velocity;
//----------------------------------------------------------------------------------------------
	    Pickup.bProjTarget=True;//Ibex added this so only dropped guns will bounce when shot
//----------------------------------------------------------------------------------------------
        if (Instigator.Health > 0)
            WeaponPickup(Pickup).bThrown = true;
    }

    Destroy();
}

 

[meowcat]

Cool! Thanks Ibex (that is a lot simpler/more elegant than the "auto location reset" code I was working on). Will definitely be going into the next release

 

[Kyle Kellahshehskee]

SOUNDS like you have a PM to read/listen to...

Meow,

Check your PM. I attached a link to some sound effects work for your scrutiny and consideration.

I hope you like them.

Yours,
Kyle

 

[Silver_Ibex]

Cool! Thanks Ibex (that is a lot simpler/more elegant than the "auto location reset" code I was working on). Will definitely be going into the next release

@meowcat: in the WeaponPickup class you will also want to put at the top of the function TakeDamage

if (bProjTarget == False) return; //This stops blasts from bouncing it when still an Inventory base pickup

 

[Kyle Kellahshehskee]

Random cover, bots & YARM Dom., items instead of...

Meow,

A little feedback from last night's very late session...

Far too many of the maps available for UT2K4 have wide-open areas with virtually no concealment or cover; is there a way to come up with generic piles of "stuff" that could be randomly placed on a map so that concealment/cover are more available? The one nice aspect of this is that it would add another level of randomness and tactical considerations while playing. Maybe the cover-clusters could be randomly assigned to positions centered on item-pickup points?

AI seems to struggle with YARM Domination. They frequently miss seeing the touch zone even if they go right by it, nor do they pursue smart strategies, such as going after Yellow-untouched zones first because it's highly likely there's little/if any resistence around those regions. By taking unclaimed Yellow zones first, they're guaranteed to be drawing points as they then later pursue the enemy's controlled zones.

Several times last night I got cut down by enemies "hiding" behind the glow effects of control-zones. Again, if it's possible to replace these zone effects with something else (like things worth defending such as wounded people, high-technology item, super deadly top secret weapon, intel artifact, etc.), then we'd increase the level of immersion while also denying bots/other players from taking advantage of a universal all-encompassing glowing effect that surrounds the entire region. If they take advantage of limited cover/concealment that's there because of the item that's being defended, that's fine because it's believable, otherwise it's frustrating.

If such a path is pursued, maybe make the wounded "people" killable, meaning that if the defender is using them as cover and the person gets "killed" by incoming rounds that THAT control-zone is then respawned to a new random location as a PENALTY against BOTH teams for not being careful enough about their tactics.

That's it for now.

Bye!

 

[meowcat]

@ Silver_Ibex: I went even simpler than that, instead I just turn on bProjTarget in the InitDroppedPickupFor function my pickup class, works A.Ok (I turned it off in the default properties).

@ Kyle:
1. Yeah fixing the bots in Dom is one of my slightly higher priorities (both TeamAIs always select the same points, so I need to adjust that algorithm).
2. I could generate some "random cover object" code, but this will be pretty low priority for now (though the code itself would be very easy by using pathnodes to find valid "in level" locations then firing random traces to locate places to place objects). The harder part is spending the time to create cover static meshes (crates, rocks, etc.) that would make sense in the levels (I suppose I could always use the "camouflage" deco mesh set for each level).
3. I will try to come up with a better zone pattern for now (rather than the translucent effect). If i have time to come up with a custom meshes of high value objects I will add them as an optional setting. I don't want to make anything too specific right now because the Game Types currently work with (and sort of make sense in) vanilla UT2k4 as well.

 

[Kyle Kellahshehskee]

A static mesh that makes sense & is TACTICAL...?

Meow,

It's funny that you posted what you did in your reply to my post. We were thinking about the same things, and as I was working in the basement, I whipped up in 15 min. the following image that I hope does a good job of explaining one aspect of using a specific type of static mesh instead of the glowing ring effect. So...

A static mesh that makes sense anywhere & is TACTICAL...?

What do you think? Good thoughts I hope!

Back to work I go-go.

 

[Kyle Kellahshehskee]

More thoughts on missile crates control zones...

Time for bed and thus no time for me to write up anything more regarding the image here; chances are that the commentary already surrounding the images is more than sufficient already.

Good night!

 

[Kyle Kellahshehskee]

Invisible "fog" as darkness?

Heh! I apologize for the spelling errors in the image above. Hey, I was tired!


Meow,

I've brought up in the past some concern that UT2K4's bots aren't affected by the level of darkness or shadow that may be surrounding a target. Is it possible to simulate darkness for bots by assigning an invisible-to-players "fog" to shaded zones. I'm assuming, of course, that regular fog DOES affect the bots' visual capabilities.

If this special "fog" behaves similarly to real fog, then one could run a close parallel to how shadows affect one's ability to see; that is, the closer one gets to someone in shadow, the greater the odds are of being able to finally recognize him.

Just a concept that crossed my mind a few times on my way to/from work.

Yours,
Kyle

 

[meowcat]

Hi Kyle,
1. Thank you for posting the pics for the crates. I can probably toss in a rough version of this in the next release (I think there are a few default UT2k4 static mesh models I can work from or borrow as placeholders until custom meshes are made).

2. By default the bot's vision is unaffected by fog distance. Mysterial (works for Epic) fixed this in his SuperBots mutator (of which I borrowed some code and acknowledged in the YARM reademe). The YARM Bots use that bit of code (along with all of the rest I added). Shadows are more difficult, and could be probably done one of two ways. The first involves updating the 'visibility' variable in each pawn at a set frequency (every tick is too high, but 1-3 Hz is not too bad) like FragHouse's Tactical Shadows mutator does. It iterates through all the nearby lights for each pawn and recalculates how "light" the area is. The second involves placing "shadow zones" in each map and would be the easiest and most efficient way to designate how dark an area was and change a pawn's visibility variable upon entering and exiting. Of course the downside is that all the maps would have to be custom.

At least in the short term, I would say using the Tactical Shadows mutator would probably be the best. I may contact them (Parser?) to see if I can integrate it into YARM later (I figure in reality it only needs to be applied to human players anyways which is not too bad with only a handful of players playing Coop.

[EDIT] I forgot that I already mentioned the above ^^ earlier. Anyways, I will have a "test" AR/GL combo rifle in the next release (the MA5B with an underslung grenade launcher). We'll see what everyone thinks of that before I bother making an M16/M203 combo. Currently the bots use it just fine (in fact a little too well on higher skills settings). I have the Tactical Reload code in now and working properly, and I've added a configuration variable to adjust how long dropped weapons stay around.

 

[Kyle Kellahshehskee]

More GREAT news for us...!

Thank you for posting the pics for the crates.

Oh, you're WELCOME! You'll see why in a second...

I can probably toss in a rough version of this in the next release

YESSSSSSSSSSSSS!!!

The above part? That's the "why" I mentioned earlier.


I can't wait to try out the crates. I strongly feel that they'll add a much appreciated level of new (and tactical!) depth to the maps that were mostly completely absent before.

If it's not too much trouble, maybe apply a slightly metallic and very short "creak" sound effect whenever a crate gets stepped on. I'd step on my old (mostly plastic) junk chest my parents got me as a kid, but I'm...uh...not so much a kid anymore. And that could lead to disastrous consequences. For the chest. And admittedly, my pride.


If the missile crates-control-zones add a positive level to the game, then perhaps we could later incorporate another type of cover/concealment that are also assigned to other random locations on the map. I have a "runner-up" to the missile crates suggestion that I haven't mentioned before, and if executed properly, I feel it would be just as acceptable in terms of "fitting in" with nearly any map, regardless of its aesthetics, and be generic enough not to too badly sour the flavor of realism-enthusiasts such as ourselves. If time permits, I might do a drawing this weekend. We'll see...


In regards to the bots' vision capabilities and how they're not affected by light levels... If implementing Mysterial's "fog-fixes" isn't too challenging an endeavor, I'm all in favor of it, especially since it gets tiring to start taking rounds on foggy levels and one hasn't even had the chance to see the shooter. The shadow part is frustrating, but in light of other things that could use your time, I'm in favor of putting that lower in priority on the To Do list.

I will have a "test" AR/GL combo rifle in the next release (the MA5B with an underslung grenade launcher). We'll see what everyone thinks of that before I bother making an M16/M203 combo.

Nice! I have a feeling that the MA5B will prove popular enough that grenade launchers will become a common request.

I have the Tactical Reload code in now and working properly, and I've added a configuration variable to adjust how long dropped weapons stay around.

Nice and important additions. We're in for a treat with your next release!

 

[Kyle Kellahshehskee]

Suppression-penalty-effects against bots/humans...

Meow,

Any chance of integrating a suppression-penalty-effect on the bots and players? A while ago, I purchased Battlefield 2 just to play the mod Project Reality. 10 min. into that mod, and I realized what a huge mistake I just made buying that title.

The only good thing was the suppression-penalty-effect, with the screen getting so blurry the closer one moved one's eyes towards the main source of the incoming rounds that one's "fear" made it extremely challenging to hit the target. It forced the player to seek cover and/or seek an alternate outflanking path to address the suppressor. The SLX mod for OFP forced the player to breathe in utter panic, which affected one's stamina and caused one's scope to wobble, making it extremely challenging to follow through with an effective shot due to terror.

Personally, I prefer SLX's approach, as the "auto-blurring" in Project Reality is just too over the top, while SLX's wobbly scope kept the visuals intact while making it unlikely that one could eliminate one's suppressor by just standing still ala Rambo. If the incoming rounds were really heavy in SLX, the player's/bots' bodies would also be forced to the ground into the prone position.

Could bots be caused to panic, suffer a to-hit-penalty against their suppressing enemy, and seek the closest shelter possible and then try to outflank the suppressor after they've recovered from their terror?

This would add an enormous tactical effect to the mod, of that I'm sure.

Time for bed!
Kyle
Nov. 13, 2009

 

[meowcat]

Bot code already takes into account the last time they took damage, and this affects their accuracy (as to whether or not its actually noticeable in game is a very different story). I might be able to adjust their code a bit to seek cover (I'd already done this in a previous SP trial map), but remember there is no map designated cover points in normal maps (AA had path nodes that could be set as "cover" which I assume greatly helped in simplifying the bot AI code) so there is no super efficient way to search for cover (and for anyone else reading this, no, iterating through all the nearby path nodes and doing traces back to the shooter is a crappy kludge though it does work). Arrgh I wish bot code was not such a pain to test and troubleshoot (though its about 100x easier in UT2k4 than in UT)

As for player effects for near misses, I might be able to, but it'd get tricky and ugly for the effect it produced (traces only register hits to objects, not near misses). About the best way to go about it I suppose would be to occasionally send out an invisible projectile with the shot that grew in size as it traveled, touching any players along the way and triggering the effect on them. I'll consider it (may toss in a test case), but no guarantees.

 

[Kyle Kellahshehskee]

Suppression-penalty effects...bots too...?

Meow;

(traces only register hits to objects, not near misses). About the best way to go about it I suppose would be to occasionally send out an invisible projectile

Hah-hah! Man, one thing my years of working with other coders has taught me is that the (potential) solution has to be as simple as possible, and it helps if the solver has a touch of "madness" to figure out how to get the job done in a virtual reality whose hidden rules are, well, pretty crazy in and of themselves. Bizarre and brilliant train of thought there Meow. Bravo!

I just want to make sure that I'm understanding UT's effects-on-AI limitations here: bots can't be affected by this invisible projectile as well as players? Bear with me here...

Let's say an invisible round that's 2 m. in diameter is emitted with every third real-damage-inducing-round, and that this special invisible round is not generated till the sixth round emitted at a target from a target within 1.5 seconds time. Now, why start it with the sixth round, and not with the third? This is to give players/bots the opportunity to quickly respond to the first burst of three rounds directed their way without having to immediately deal with suppression-penalty effects. It is only with the second burst set (six rounds) that the 2 m. wide invisible specialized suppression round is emitted, and if it "strikes" the target, bot or not, it receives an aiming penalty that lasts for a full second (this round would be able to "pass through" all cover that's thinner than a meter's thickness; just because you're behind cover doesn't mean that one's immune from the terrors of suppression). This aiming-penalty grows with each second the target is exposed to every incoming third round being sent its way by EVERY shooter.

Thus if there are TWO shooters sending rounds at the SAME target, then that's easily six rounds within 1.5 seconds, and due to the greater volume of incoming fire, that target WOULD be affected by suppression-penalty effects that would STACK up. Thus, the more people you have directing their suppressing fire on the same target within the allotted time frame of 1.5 seconds, the more terror effects that target will suffer. Perhaps a net effect on a target that's receiving rounds from three shooters could be that they're forced to go prone; which is potentially good in the sense that they're definitely a smaller target, but is potentially bad in the sense that he's definitely moving much slower.

After a certain number of suppression-penalty effects have been stacked, it'll take TIME for them to fully wear off. What this figure is is beyond me at this point (three seconds, maybe?), but in any case, I'd imagine that even if one has evaded anymore incoming suppression-rounds, and is attempting to find adequate cover and/or to outflank one's shooter(s), that the fear would be quite substantial and thus need time to be "flushed" from one's active memory.

Is this doable, or...?

 

[Kyle Kellahshehskee]

The underbelly grenade launcher should probably be...?

Meow,

I have no doubts that once people get a taste of your work on the grenade launcher for the Halo assault rifle, that they will be badly desiring to have versions of their firearms that are equipped with them.

Especially if the bots can use them. Around here, that "little" miracle wasn't accomplished in INF, so it's hard for me to imagine players wanting such a possible feature to be left in the dust; especially if it's already working.

If you do decide to proceed with incorporating underbelly grenade launchers, I'm wondering if time would be better spent avoiding the modeling/texturing/coding of a M203, and rather go instead with the soon to be massively integrated in real life HK M-320. If you're really ambitious, perhaps the M203 could be relegated to firearms for OPFOR that don't have the funds/access to the snazzy M-320. But it's clear that the M-320 is going to be rolled out in a major way, so the mod might be better served if it's jumped on right away.

An image of it in action can be found here:
http://www.defenselink.mil/dodcmsshare/photoessay/2009-07/hires_090701-A-3108M-007.jpg
and a series of shots found here:
http://www.defenselink.mil/PhotoEssays/PhotoEssaySS.aspx?ID=1302

The chief advantage of this design is that they'll be able to launch grenade rounds that are lengthier in size.

FYI: I'm about a third of the way through my next proof-of-concept drawing. It'll be posted as soon as it's done.

Good night!
Kyle
Nov. 13, 2009