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

  • Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Here's a CTD bug report. Maybe someone else could duplicate it to confirm?

Playing INVASION gametype. I believe that while I was playing the COD mut that I had the NOT DEAD YET perk selected. When I got to a health of "6" I went prone, and then when I reached 0 the game CTD. Here's the report:

UT2004 Build UT2004_Build_[2005-11-23_16.22]

OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel Unknown processor @ 2996 MHz with 2047MB RAM
Video: Radeon X1950 Pro (6822)

MonsterController DM-DE-GRENDELKEEP.MonsterController (Function SkaarjPack.MonsterController.FindNewEnemy:0065) Runaway loop detected (over 10000000 iterations)

History: FFrame::Serialize <- AActor::processState <- Object MonsterController DM-DE-GRENDELKEEP.MonsterController, Old State State SkaarjPack.MonsterController.Hunting, New State State SkaarjPack.MonsterController.Hunting <- AController::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=0) <- TickLevel <- UGameEngine::Tick <- Level Grendelkeep <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free
 

Corporal_Lib [BR]

Brazilian Graphic Designer & Gun Nut {=)
Sorry for the late comment, but this week was tiresome, and I´ve tested just a lil the new YARM monday night (could have tested more, if it was out sunday, as monday was Saint Mary holyday down here in Brazil) and played a little more tonight... cutting the crap and going straight to business, here are my impressions:

medkit and ammo box cascading bug fix : outstanding job! fixing this issue made possible to play OSM maps throughly!!! Thanks a lot meow, we can now have a next gen INF COOP guys! A Pitty there are just a few OSM maps available =/

New parkour movements: wow, now the pawn can climb almost every struture in the maps, since they have some edges to grab after a long jump or wall walking, quite parkour indeed, but I still can´t low slide, I sprint and hold the crouch, but the pawn crouchs without sliding =(
And there´s this 3D curved arrow visible while rolling and wall walking, is it a coding or animation indicator that wasn´t made invisible or was it on purpose???
Is there a way to enable mirroredgeme permanently (as the freeaim: once toggled on, it remains on even after restarting the game) or we just have to toggle it on by console everytime then???

the AK107 and P90: Loved both new "toys"! the P90 is superb, really a spray n pray weapon, just good to slain close formation of enemy bots lol, the recoil is nice and so is the model, but... where are the new firing sounds? chuckus didn´t sent you his sound minimod?
The kobra worked just fine in the Ak107, a nice detailed model, has the 3 round burst, but I would suggest toning down a bit the recoil, as the Ak107 features a double spring bolt system to reduce dramatically the recoil, just like the An94 Abakan, read at this article how it works:
http://world.guns.ru/assault/as07-e.htm
Overall a nice adittion... could we have acogs (for M16A4 nad M14), PSO-1s and 1P29 (for aks) on the next release???

The MP5´s don´t have recoil: actually, since the new models were introduced at the previous version, they don´t have recoil kick, just like the halo smg, or at least it is too sutile to be noticed... could you increase it (a little more kick than the P90 would be ideal, as it fires a heavier round)???

yarm class loadout config: how can we re-config the loadout of each yarm class? The "no class weapon" option just makes all bots use the same configured replacement for UT2K4 weaponry... I just prefered to be able to change their loadout (or at least trade the fictional guns - halo rifle, smg, carbine and the ma5b - for the SA80, MP5´s or Bizon and CAR-15... speaking of which, are you going to replace that old model of CAR-15 with a brand new one, with and without a M68CCO aimpoint on top (like this pic ->
ARMS16Ainst.jpg
) on the next release??? ;D

At least but not last (lol): tactical reload - could it be implemented? so when you reload a weapon with a round still on the chamber, you get the +1 in the number of rounds (i.e: 31 rounds loaded in a M16A4 after a tactical reload... 'dry reloads' keeps the 30) or it would need further coding (as presently the ammo counter just displays the overall rounds for that weapon)???

Well, that´s it, another kick as RC, and it just keeps improving, outstanding job, Meow, keep it comin´;D

@kyle: the "not dead yet" perk has this bug with regeneration on: you get stuck in the ground, thou your health is fully replenished after regen, so you don´t die to respawn but keeps "glued to the ground" until some bot finish you off or harakiri yourself with a nade ;P ... but it didn´t CTD me once =/
 
Last edited:

meowcat

take a chance
Jun 7, 2001
803
3
18
@ Kyle & Corporal_Lib: Thank you again for the great feedback (especially the crash details)! Here is just a quick response:

1. Invasion and Not Dead Yet Perk Crash: I think I know how to fix the regen/health crash bug with the not dead yet perk. I will include it for the next release (I have too many features in the mod so I miss the simple things like this and weapon icons for the P90 and AK107). It looks to only occur when the timing of things is just right.

2. Parkour Moves: The arrow things are on because bClimbDebug is set to true in either [yarm.yarmPawn] or [yarm.yarmPlayer] section the of the yarmConfig.ini file. In this case I accidentally left it true in the [yarm.yarmPlayer] section. Just set it to false and save the file. Right now the parkour movements are only active in that test pawn class. Once I get a few levels made (and further tweak my existing MP levels) I will add the capability to the normal YARM pawns as a configurable option (a couple different "levels" of capability to allow Server admins to decide how much special movement for the game being played).

3. AK107, P90, MP5: Yeah I can readjust those numbers. Should be in the next release

4. Loadouts: You can adjust the default loadout in the YARM Weapons mutator confg options (just change out the DefWeapon slots to either 'none' or what you want everyone to start with, weapons in Slot 0 and 1 are always given to the player if "no class weapon" is true. Any other loadout options beyond that will have to wait until later. I'll see about the CAR-15 (since its already ingame), hopefully I will get to it.

5. Tactical Reload: My pal Postal over on the WOD forums had recommended this to me all along (beginning back in 2001-2002 with the C4 Weapons mutator for UT). I remember having some problems with the proper replication and syncing-up of the client and server and abandoned the idea for the time. I may get to this, but don't expect it for a while. The code got a little messy so I will have to tackle this sometime later.

Right now I'm working on some simpler (easier to place in maps) AI code for SinglePlayer enemies. I'm aiming to have it match the functionality of the Unreal AI which I already had made back in 2006-2007 in my first SP map attempts. This time though it should be easier to adapt for enemies that are not as intelligent as humans (eg: wild dogs, attack drones, unreal monsters etc.).
 

meowcat

take a chance
Jun 7, 2001
803
3
18
@ TurdDrive: Thanks for the feedback! At this point it was a choice of style/expediency. Since I use Milkshape3d to model and LithUnWrap to create the UV maps, I lose all smoothing groups once I've finished UV mapping and reimport to MS3d from LithUnwrap, so I have to reassign all of the smoothing groups. I was not yet ready to add all of those little details (nevermind having to take up additonal texture space to allow for variation on the surfaces facing the camera to prevent the 'patterning' problem). I may get to it, but it won't happen anytime soon.
 

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Grenade effects, stumbling % from blood loss...

Meow,

I just want to state that the parkour moves are amazingly immersive. They practically look like motion captured animations (are they?). I appreciate the quick external views we get too, whenever we climb an obstacle. A nice touch in my opinion, and one that doesn't ruin gameplay, since the player's immobilized during the execution of the animation anyway. Might as well do it with STYLE, which you accomplished with room to spare!

I apologize for not responding to a couple of your questions/statements earlier, so I hope that I get them all now.

In regards to mounting underbelly grenade launchers, well, they DO have their drawbacks. When I used them in INF, I held my breath each and every time I reloaded, since I was completely vulnerable. Also, the grenade travels substantially slower than any round fired in the game, another big minus. I've been waxed many a time by bots and humans as I peeked out from behind cover thinking I was going to get him before he got me. If a stamina system is integrated, then having the grenade rounds will be quite a hit on the player's/bot's speed and whatnot till the load is lightened. When I played INF, the drawbacks were so severe on a M206 attachment that I probably only used it 25% of the time. But the stamina system is another vital tool to "balancing" this weapon's advantages out.

To me, the effects of the M67 are too limited. Bots/humans should have a greater chance of being knocked down even if they survive the shrapnel, with ringing in the ears that lasts a good several minutes. The same holds true for the H&K grenade launcher (although does it fire 20mm or 40mm grenade shells?).

I like your idea of having the player's screen getting an "exhaustion ring" around it when the player has overexerted his body. I have no doubt that you'll handle it as deftly as you did the blood spatter effects when the player's injured.

In my opinion, a bleeding/bandaging system would add a LOT to what's happening in the game. I've already mentioned this, but do so again because I feel that strongly about it. I would certainly assign more severe slowdown penalties than what's found in the BloodLossLite mutator I referenced earlier. If it's possible, I'd also assign a "stability loss" factor, so that those who go up a slope have to REALLY struggle to do so, and those that are going down a slope have a greater chance of stumbling and falling. That would ratchet up the drama and sense of human vulnerability a LOT in the game.

I still cannot get the crosshairs to stay disabled during an entire game. They keep popping up, oftentimes after each and every respawn. This is with my crosshairs set to "none" or whatever in the standard UT GUI, and after entering the appropriate codes. This one "little" item drives me up a wall though. Maybe I should start dressing as Spider-Man when I play?

;-D

Keep up the great work. Thanks again for it! Check your PM for more.

Good night all!

Kyle
Oct. 18, 2009
 

Silver_Ibex

Member
Feb 27, 2001
654
0
16
5. Tactical Reload: My pal Postal over on the WOD forums had recommended this to me all along (beginning back in 2001-2002 with the C4 Weapons mutator for UT). I remember having some problems with the proper replication and syncing-up of the client and server and abandoned the idea for the time. I may get to this, but don't expect it for a while. The code got a little messy so I will have to tackle this sometime later.

Why not somthing like the following?

Code:
//Ibex added +1 bullet to mag feed guns. so you keep the one in the chamber if you reload before empty.
// put in the weapon default properties 1 more then a regular magazine holds
// for example a gun with a magazine that holds 30 rounds, would get      //ClipCount=31
//FullClip=31

//Can play animations for inserting individual bullets here, or other effects.
// Server-side only, so should call a replicated function here and play animations
// in it, rather than in this function itself.
function InsertBullet(){
	local int ClipSize;

	If (ClipCount > 0) 
		ClipSize = FullClip;
	else { 
		ClipSize = FullClip;  
		ClipSize --; //no round in chamber so lose the extra one
	}
    ClipCount = Min(ClipSize, AmmoAmount(0));//don't overfill the clip//if none in the chamber then we dont get the extra round

}

would that work online?

Also how about a check to only drop empty mags

Code:
// $$$$$$$$$$$$$$$$$$$$$$$$$
// RELOADING
// $$$$$$$$$$$$$$$$$$$$$$$$$

/*So reloading can be bound to a key. Exec functions in weapons can only be
* called for the currently held weapon, which is perfect for this purpose. */
// replicated to the server
exec function Reload(){
    if(!AllowReload())
        return;
    if(bAimMode || bHighAimMode) ResetPVO();

    if(WeaponAttachment_yarm(ThirdPersonActor)!=none && ClipCount <=0){ //Ibex added check to only drop empty mags
         WeaponAttachment_yarm(ThirdPersonActor).DropMag(FirstPersonView());
    }
    if(yarmPawn(Instigator)!=none){
         yarmPawn(Instigator).PlayWeaponReload();
    }
    //ServerReload();
    ClientReload();
    GotoState('ReloadingWeapon', 'Begin');
}

function ServerReload(){
    if(WeaponAttachment_yarm(ThirdPersonActor)!=none && ClipCount <=0){ //Ibex added check to only drop empty mags
         WeaponAttachment_yarm(ThirdPersonActor).DropMag(FirstPersonView());
    }
    if(yarmPawn(Instigator)!=none){
         yarmPawn(Instigator).PlayWeaponReload();
    }
    GotoState('ReloadingWeapon', 'Begin');
}
 
Last edited:

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Read the PM before downloading...

Meow,

PLEASE read my email BEFORE attempting to download the file that's supplied in the link embedded there! It's VERY important!

It's 9:07 PM my time, so give me 15 min. to write it (just in case you check this thread before I'm done composing it).

Yours,
Kyle
Oct. 22, 2009
 

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Bots frequently get "stuck" in a crouch-up-exhausted-breathing sound loop.

Frequently, a bot's weapon is pointing at or nearly at the ground. I believe that this occurs exclusively while crouching and/or crouch-walking.

Zombie mut working now (the one with the better looking zombies I referenced earlier).

Prohibit reloading while RUNNING and/or apply a severe penalty for doing so, maybe a 50% chance of dropping the magazine. Should take longer to reload while walking with a 25% chance of dropping the magazine.

Enable head to be rotatable at the neck, ala OFP and ArmA. VERY immersive and VITALLY useful!

Is it possible to be able to see the lower half of our avatar's body; "true view"?

Needed cams: winter environments, ACU, MultiCam and "merc-chic."

Corpses should stay present for 3 min. and weapons for 4 min. If possible, have the corpses be removed without any flashy effects, and when the player isn't looking (I'm pretty sure from something that I read years ago that this is doable). It'd be ideal to allow this to be a configurable mut through the GUI, so that if one has a system that can handle longer timespans (even corpses that stick around till the match's end) then they can do so.

Establish an .ini file for heavily played maps that are set in cold seasons/climates, and setup a config that generates "cold breath" whenever the avatar or bots "breathe."

ERROR REPORT Oct. 24, 2009, I believe that this was generated only due to my using the GREAT real time shadows mutator entitled "jcbShadows-v17a" which is available from here:
http://www.discoverthat.co.uk/games/utmods.htm
And now the two CTD reports that I got...
UT2004 Build UT2004_Build_[2005-11-23_16.22]

OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel Unknown processor @ 2995 MHz with 2047MB RAM
Video: Radeon X1950 Pro (6822)

General protection fault!

History: FActorSceneNode::Render <- UShadowBitmapMaterial::Get <- FD3DRenderInterface::SetProjectorMaterial <- FD3DRenderInterface::SetMaterial <- ATerrainInfo::Render::RenderProjectors <- ATerrainInfo::Render <- RenderLevel <- DM-Aeris.myLevel <- FLevelSceneNode::Render <- FPlayerSceneNode::Render <- UGameEngine::Draw <- UWindowsViewport::Repaint <- UWindowsClient::Tick <- ClientTick <- UGameEngine::Tick <- Level Aeris <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free

And AGAIN...
UT2004 Build UT2004_Build_[2005-11-23_16.22]

OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel Unknown processor @ 2995 MHz with 2047MB RAM
Video: Radeon X1950 Pro (6822)

General protection fault!

History: UShadowBitmapMaterial::Get <- FD3DRenderInterface::SetProjectorMaterial <- FD3DRenderInterface::SetMaterial <- RenderStaticMesh <- FDynamicActor::Render <- RenderLevel <- DM-Aeris.myLevel <- FLevelSceneNode::Render <- FPlayerSceneNode::Render <- UGameEngine::Draw <- UWindowsViewport::Repaint <- UWindowsClient::Tick <- ClientTick <- UGameEngine::Tick <- Level Aeris <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free


By the way, are there any muts that easily enable bloom effects and real time shadows while being stable? If so, please feel free to direct links my way.

Thanks!
:)
 

meowcat

take a chance
Jun 7, 2001
803
3
18
@ Silver: Cool, I'll give tha code a go when I can test it on my LAN (as that had been the problem in the past))
@ Kyle:
1. Sounds like the Yarm Bots code, I have not seen that bug yet though, but I will be on the lookout for it.
2. The bot's weapon should be pointing at the ground if the bots are dashing (that is the animation).
3. Which Zombie mute? YARM Zombies of ZoN?
4. I could prohibit reloading while dashing/sprinting, but I won't be imposing any penalty while running or walking (though I suppose I could slow it down a bit while moving). I seem to remember being able to reload my M16 (6867381 iirc) about as fast while walking as standing still/crouching/prone (but that was over 2 years ago now). Of course if magazine retention was not a concern, then there would not have been much of a difference as that was what I seem to recall slowing me down the most (the rapid fire from the 300 during quals was not bad though as we only had to stuff the magazines into our cargo pockets).
5. Which neck rotation do you mean? In first person view (can result in very nasty wall camera clipping if not careful), or of the player models?
6. True View: Not going to happen without some major changes to the pawn and weapon code (it requires some significant rework of the first person camera view position code). I may also have to increase the collision cylinder radius to prevent camera/wall clipping (nevermind the extremely nasty playermodel clipping itself).
7. I already have some snow camos in the player texture package (I think) and will be adding these as selectable camos next release. I could probably add ACU and MultiCam.
8. I can work on the corpse code a bit, but a big limitation is the engine hard coded limit on Karma objects. For UT2kx it is something like 200. Each skeletal ragdoll has about 12-13 karma objects, so the maximum number of bodies would be something like 15. I have not actually tested this, but I do know that too many ragdolls will slow things down quite a bit (and they do not replicate).
9. I could do that (that was one of those hit list items I added as a "nice to have" several years ago. I will see about it (though lower on the priority list). Also, with the SP/Coop portion, I will probably end up doing this by Zone or Volume instead (using on e of the other unused variables in the class to hold the "temperature")
10. I don't play with any special shadows involved (slows down my development comp too much) so I can't say that I've encountered that issue before.
 
Last edited:

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Meow,

I'll start getting into more of a habit of numbering my observations if there's more than a few of them to post. Doubtless, this would make it easier for everyone to follow what's being commented on. :)

In regards to the bots running with their weapons pointing down; the only reason why I bring it up at all is that frequently the firearms look like they're clipping through a lot of ground terrain. Maybe elevate the positioning of the barrel's end a bit, or have the weapon strongly pointed to the left as we see from our avatar's position while we're sprinting.

Sorry to hear that coding True View is such a pain in the butt. You'd think it would be just as simple as slapping a body under the player's "eyes." But I read a commentary with screenshots not too long ago regarding a well known bug in a major game that was modded for WWII scenarios (Quake II, maybe?). Anyway, it was showing the view from the player's vantage point and he's crouching behind a pile of rubble, and then it showed what the opposition sees, and it was just the top inch or so of the HELMET, while it was clear from the screenshots that what the player was seeing should've exposed everything from the top of his helmet to the bottom of his lower lip. CRAZY stuff that these oddities can even happen!

The zombie mut I was using was Zombies of Nightmare. Maybe they started working because I dumped in MonsterManager 1.8 (but haven't fooled around with it other than putting it "on" in the GUI). So, I don't know if you changed something on your end that had them showing up and moving about, or if MonsterManager automatically did this. Whatever the case, I wasn't forced to stare at completely stationary default UT2K4 bots as the first several times I tried using ZoN with YARM.

There's no question that the error reports that were generated didn't occur when the real time shadowing mut was off. Those CTD errors only happened when the mut was on, which is a SAD thing as that mut adds a ton to the game graphics-wise.

By the way, I also turned on a bloom mut, and it made the weapons and the avatar's arms about 50% translucent. So I'm not going to bother with that one.

Yeah, I'd put the cold-breath-cloud very low on the priority list too. But I'll start making a list of maps that it would be suitable for, and send it in if it should ever be implemented.

The corpse-time-removal limit is pretty important. Due to the slower movement speeds, it's much harder to get to the weapons before they "shrink away," and the nature of the combat is so brutally fast that one has to take the time to use the terrain wisely, or one will be wiped out before they get to the weapons.

Do you think that there's a chance to have body movement sounds integrated into the game? The FFUR 2007 mod for OFP did a GREAT job at this, and it's hard for me to imagine that Thunderbird would say "No" if he was nicely asked to use these sounds in YARM. I've lightly assisted him in the past, and, if you'd like, I could send him a PM about this, that's if you're interested? Let me know.

That document that I'm writing for you is nearly "done," but after I took a very badly needed nap yesterday, I was able to read it with a rested mind, and the typos! I'm not hitting the keys that I think I am when I'm working on it at night or the early morn. So, hopefully, just a few more days and it'll be on its way to you, and written in SENSIBLE English to boot.

Good night all!
:)
 

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Just got home an hour ago, so this is a super duper quick comment...

I forgot to mention that what I meant by "being able to look around" with one's head is that in OFP and ArmA, one could assign a key to allow the player's head to look around independent of the body's movement or torso direction. Just like in real life, one's body could be moving straight while one's looking over one's right shoulder, left shoulder, or up above. It feels incredibly natural to do (as it should), and is certainly a lifesaver if one remembers to use one's neck to look around; an action that is usually impossible in most FPS. I hope that this clears up what I stated earlier.

Good night!
 

meowcat

take a chance
Jun 7, 2001
803
3
18
@ Kyle: How is it different then strafing sideways or looking up while moving (ie: does the weapon still stay pointed in the same direction as the player's movement). From a gameplay perspective, what does it add to the player's abilities? (I'm just trying to make sure I understand the purpose of the movement).

Next release (hopefully about two weeks from now) will feature the Multicam camo pattern as a selectable uniform. I may have another weapon or two added (compound bow with first person model instead of the third-person-only test compound bow now in YARM, katana sword just 'cause everyone else has one now). Also, grenade secondary fire will probably be switched to a melee punch/swing. Basic code to identify "cold" maps has been added. I may or may not have the breath code implemented next release.
 
Last edited:

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Meow,

In Operation Flashpoint, one could move one's head INDEPENDENT of one's body/weapon. OFP had "vector aiming," sort of, but anyway, your body AND your weapon could be aiming at 12 and your head could be sweeping between 6 and 3. One could incline one's head the normal human range as well.

Now, let's say you're head's looking at 2:30, and you see an enemy; one could rotate your body from 12 to 2:30 by turning one's mouse to KEEP LOOKING at 2:30 as one STOPS PRESSING DOWN on the head-movement key; the effect is that one's body will reposition itself to the position that the mouse is trying to hold (which is where one's head was looking when the head-look key was being held).

Ahhh! This is hard to precisely described, but it worked easily and naturally in OFP. One key, while held down, allowed one to look a full and natural range. When released, if one worked one's mouse towards where one was looking when the mouse was held down, one's body rotated to the new position.

Make sense? I tried! lol

I think that this video from ArmA does a pretty good job of illustrating the "head looking" thing, but sadly, all of the looking is done from THIRD person view. Ah well, better than nothing.
http://www.youtube.com/watch?v=GLzLv_u0QaU&feature=related

While you're at it, pay attention to the sonic snaps of the passing rounds. Oh, if only this could be folded into YARM too...!

Another update right around the bend? YES! Looking forward to that, especially the new MultiCam.

Hey, SUPPOSEDLY "Out of Hell" is being released sometime tonight. Not that I want to derail this thread, but Chicken+Ribs Combo has spent over five YEARS working ALL ON HIS OWN on this horror-related TC for UT2K4, and I hope that you don't mind me plugging it here. To be THAT devoted is amazing. Trust me, I'm not trying to derail this thread, but I find it impossible to avoid bringing it up. Guys like you two are VERY rare indeed!

Here's the link to the TC's download page. He states that he's uploading it now, and that it SHOULD be out before the witching hour. Keep refreshing that download page till it's up. I am!
http://www.outofhell.net/Download.html

Happy Halloween all, and good night!

Oh, and BOO!
 

meowcat

take a chance
Jun 7, 2001
803
3
18
Hey Kyle, I think I get the idea about the head movement (definitely sound more realistic), the video helped. Is it a gameplay enhancing feature though? Also, if you find a snap/hissing sound in the default UT2k4 sound packages (or even a sound that could be shortened to make the sound), I think I've got away to make it a completely optional clientside effect (my favorite kind), which I have no problem with adding.

No problem about mentioning OoH. I really loved the style and artwork of C+R's mod and it does a great job of setting the atmosphere.

Also, a few screenshots of my 4 hour katana (about how much time it took to model, skin, animate, and get in game) and the multicamo uniform [EDIT] and the progress on the CH46 Helicopter:
<-> <->
 
Last edited:

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Niiiiiice work on the MultiCam!

And that katana! Y'know, it takes those Japanese sword masters a whole year to fashion just one blade. But you, you're so amazing you did it a mere four hours. I bet that once wind of your powerful skills reach those masters, they're going to use their swords and commit seppuku. ;)


Being able to scan one's head around is an ENORMOUS gameplay asset and enhancement. I can't tell you the number of times that it saved my skin because I was able to hit the dirt or rush behind cover just in time to avoid a bitter end.


In regards to the sonic snaps of the passing rounds... I'm working on getting to you something quite useful. I just hope it pans out, and I'll promptly let you know of the results as soon as I get them myself.
 

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Infinite bot spawn error detected...

Meow,

Here's a new CTD report:
UT2004 Build UT2004_Build_[2005-11-23_16.22]

OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel Unknown processor @ 2995 MHz with 2047MB RAM
Video: Radeon X1950 Pro (6822)

mute_YarmBots DM-DogTown.mute_YarmBots (Function Engine.Mutator.AlwaysKeep:0000) Infinite script recursion (250 calls) detected

History: FFrame::Serialize <- UObject::processEvent <- (AssaultAttachment DM-DogTown.AssaultAttachment, Function Engine.Actor.PreBeginPlay) <- ULevel::SpawnActor <- (AssaultAttachment) <- UObject::processEvent <- (InvasionPro DM-DogTown.InvasionPro, Function UnrealGame.DeathMatch.PendingMatch.Timer) <- AActor::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=0) <- TickLevel <- UGameEngine::Tick <- Level Dm-DogTown (Ophidic Version) <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free
 

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
Another one.

This time without the YARM bots mut. I'm trying out YARM with the Invasion Pro gametype. Sadly, they don't look compatible! :(

UT2004 Build UT2004_Build_[2005-11-23_16.22]

OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel Unknown processor @ 2995 MHz with 2047MB RAM
Video: Radeon X1950 Pro (6822)

mute_YarmWeapons DM-DogTown.mute_YarmWeapons (Function yarm.mute_YarmWeapons.CheckReplacement:0000) Infinite script recursion (250 calls) detected

History: FFrame::Serialize <- UObject::processEvent <- (AssaultRifle DM-DogTown.AssaultRifle, Function Engine.Actor.PreBeginPlay) <- ULevel::SpawnActor <- (AssaultRifle) <- UObject::processEvent <- (InvasionPro DM-DogTown.InvasionPro, Function UnrealGame.DeathMatch.PendingMatch.Timer) <- AActor::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=0) <- TickLevel <- UGameEngine::Tick <- Level Dm-DogTown (Ophidic Version) <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free
 

Kyle Kellahshehskee

[^..^]Kyle
Mar 3, 2004
228
0
0
Metro Detroit, Michigan
YARM muts conflicting with popular Invasion-muts...

Meow,

I'm completely convince that over the last several days that I've "mastered" using some of the most popular mutators related to the Invasion gametype, such as InvasionPro v.1.2.

Simply put, I don't think with the current setup that it's possible to play these popular Invasion-muts with any of the YARM mutators activated. I can only imagine how many more people would get hooked onto YARM if they could reliably use it with InvasionPro... :)

Here's the latest Critical Error report that I got. I was only try to run the one COD mut with InvasionPro v.1.2. The map loaded, and then I established my avatar's capabilities through the GUI, started the match, and when the countdown got to "0" the game CTD. :(

UT2004 Build UT2004_Build_[2005-11-23_16.22]

OS: Windows XP 5.1 (Build: 2600)
CPU: GenuineIntel Unknown processor @ 2995 MHz with 2047MB RAM
Video: Radeon X1950 Pro (6822)

mute_YarmCODMW DM-collude-LE.mute_YarmCODMW (Function yarm_CODMW.mute_YarmCODMW.CheckReplacement:0000) Infinite script recursion (250 calls) detected

History: FFrame::Serialize <- UObject::processEvent <- (AssaultRifle DM-collude-LE.AssaultRifle, Function Engine.Actor.PreBeginPlay) <- ULevel::SpawnActor <- (AssaultRifle) <- UObject::processEvent <- (InvasionPro DM-collude-LE.InvasionPro, Function UnrealGame.DeathMatch.PendingMatch.Timer) <- AActor::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=0) <- TickLevel <- UGameEngine::Tick <- Level DM-Collude <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free


Do you know if this would be a small fix to avoid such a large consequence, or...?

If it helps, I was solely using the creatures from Shaun Goeppinger's amazing Invasion-related website, found here:
http://www.shaungoeppinger.com/monsters.html

Playing Invasion with the default monsters gets "old" very quickly, and the packages of stunning addons that Goeppinger supplies makes that virtually impossible. Likewise, playing InvasionPro without YARM gets "old" pretty quickly; oh the "heavenly" state that would be created if the the muts would just get along! I'd love to go hunting through some mysterious and strange maps only to encounter Goeppinger's horrific beasts made out of more than 300 polygons! :)

Once word of YARM gets out, and if it could work with muts like InvasionPro, well, watch out! :lol:
 
Last edited:

meowcat

take a chance
Jun 7, 2001
803
3
18
I've downloaded Invasion Pro. I'm working on a fix now. Just so you know though, since InvasionPro uses a custom controller and pawn class, YarmWeapons (when the UseYarmPlayers option is selected) will override and disable some of the clientside functionality of the gametype (though they appear to be some HUD items and the hiding of weapon bases which is already handled by the YARM weapons mutator anyways).

[EDIT] nuts, the replacement error has to do with the fact that I am replacing the pawns for the bots and the InvasionPro bot code overrides the method for setting the pawn class (which changes the pawn class name to a non yarm pawn type which then starts the whole pawn switch code loop again). So the problem is with the InvasionPro bots, not YARM. if you have no bots, then there is no problem. Any fix to this will be hacky (e.g.: bruteforce changing the pawn class via the mutator rather than the bot's own function) and specific to only that particular gametype. I have to consider whether or not I will implement this....
 
Last edited: