Legacy:EricBlade/Developer Journal

Wow, I've been working so much on DeadAwake that I forgot to actually come over here and write. Though I really haven't been doing much coding, lately. We need to get the levels that are built into a beautiful shape, so I'm helping with that. Learning to model (some things have come out surprisingly well, and some things have come out very very surprisingly horrible).. and I've learned quite a bit about some shortcuts to use in the editor that I never learned during reading all the tutorials.. maybe one day I won't be so horrible at actually building geometry..

05/01/06[edit]

Happy May! All month long is my birthday! :D

Today's early morning revelation: BeamEmitters are teh evil. 2 dimensional objects in 3-d space. Every use of them I've seen thus far looks like what happens with the monsters in Duke 3d. Apparently xEmitters are supposed to be far more useful, but I don't have those. And after the experiences I've had with fixing DE's Uscript, I'm not certain I ever want to mess with something they've had their hands in again. I wanted to play with the "TrailEmitter", I do have a UC code for it, and it does appear to be compiled into my Engine.u , but Ued can't find it when i bring up the list of emitters to play with under Emitter properties. So, that's no fun. I still have yet to look at this MeshEmitter thingee, but perhaps I will when I get around to making some nice gibs. This game needs gibs. Big time. All we have right now are limbs that fall off, and exploding heads. Need more gore. Zombies are gory, and gross. We need more.

04/28/06[edit]

Woo! My first major mod is released. A gametype addition based on the Land of the Dead Invasion game type, which adds support for fully functioning interaction with the player (previously, Level.Game.Broadcast and PlayerController.ClientMessage had no function, since there was no support for them in the HUD class), and a ton of options for server control over the Invasion options that are normally left to the level designers. Of course, had I known more about UScript when I started working on it, I would've made it extend the standard game, and then built DM, CTF, and IN gametypes on top of it, so that everyone could use it ... but by the time I realised I should've done that, I was pretty much to the "done" phase, about a month ago, and since then i've been squashing the little annoying critter bugs that showed up.

Does this now make me somewhat of an accomplished coder? :D

Guest: yep, it means from now on you can't write anymore code because you have to spend all your time answering all our annoying questions :-)

04/27/06[edit]

Aha! After I was writing the diatribe below for today, I read my previous entry about the rockets not doing karma appropriately, and suddenly it occured to me. If I'm throwing a rocket blast at the base of a bunch of trashcans, Visible* iterator won't contact with the second row of trash cans, because there are static meshes blocking visibility from the point of impact. Mediocre solution: use CollidingActors for HurtRadius() instead of VisibleCollidingActors().

Unfortunatly, this gives us a new problem: how to avoid hitting things on the opposite side of a wall, or floor/ceiling ? I saw some things somewhere in the Collision section that might be useful for that, although the math involved on it is currently beyond my recollection (ah, the years that have gone by since school...) .. however, I may be able to get away with simply checking to see if the hit actor is in the same zone as the explosion, and hopefully we wouldn't end up with any noticeable problems there, as long as the levels are reasonably zoned.

Spent the last day and a half re-implementing a flame thrower mod, and the results are fairly satisfying. It feels to me like it's going to have a ton of tuning work to get it down perfect for damage rate, and things like that. Took me a long time to get it so that we weren't spawning 2 fire objects per second, and to modify the fire scaling code that I had built using Vital's PMT as an inspiration and base for, so that it wouldn't absolutely totally suck down CPU. It's still pretty intensive, as it would appear that Radius iterators do not deal in collision area, but only in point locations .. if i could work in collision area, i could increase the collision size of the fire emitter as we increase the area that the emitter is emitting within, and it would become more efficient, and probably better on the visuals too.

Of course, along with this, I screwed together some more emitter work, learned more about various emitter settings, and managed to tweak out the rocket launcher smoke trails so that they don't look quite so ugly as they did before. Now, if only I could figure out why they have a green glow on their outer radius, i'd be about 99% done with that piece of work.

On the bright side, we're down to somewhere around 5 known bugs that deal directly with the code that I've implemented so far, a handful of design problems in Epic or Digital Extreme's code, and all the bugs that I knew of in the original game that don't (a) involve the aforementioned design problems or (b) involve an object that was never designed to work in netplay, that shockingly, doesn't work in netplay are fixed.

04/24/06[edit]

Well, I've found an absolutely fundamental flaw in the UT base code for dealing with Projectiles. I didn't bother to check and see if this is still the same in 2k4, but it appears to be how it works in 2k3 as well as the standard Projectile base code, and LOTD.

Here's a conversation that I had with someone on my messenger, that describes it:

Eric: that's because the way projectiles work in UT, is that a projectile doesn't actually do damage.. it explodes, and does damage

jason: interesting

Eric: so, it does damage to a radius around where it hits. now, this doesn't take into account things that are visible in the world, it takes into account the actual Location of an item

Eric: the Location of an item is normally somewhere close to it's center.

Eric: so, it would do damage to the center of something, from the location at which it hit.

jason: ah

Eric: so, pointing a shotgun at it's skull, the explosion of the bullets would rip it's legs off, because the explosion would be affecting an angle straight down from the point of impact

jason: and you fixed this how?

Eric: by making projectiles do damage to what they hit where they hit, like trace bullets do

04/15/06[edit]

Well, I did not win a trip to Vegas today. Better luck next time.

Today's adventure was attempting to fix the FastWeaponSwitch/FastReload bug. Unless someone has some sort of bright idea on how to fix it the -proper- way (and no, i don't mind overloading an assload of code to do it, but i'd prefer not to re-write the entire goshdarned inventory system!) I think i'm going to let that one pass us by. It does at least, after overriding quite a bit of code, manage to notify the weapon that is being switched from that it needs to be PutDown(). The -proper- way would be to actually play the DeSelect animation. However, without rigging Select/DeSelect to timers and all sorts of nasty stuff, I don't see much of a way to do that. :|

04/12/06[edit]

Things are progressing pretty nicely. I've figured out a bit about BeamEmitters .. started in on MeshEmitters, but their very strange behavior compared to Mesh and SpriteEmitter was baffling enough for me to move on to other things I'd been wanting to tackle.

Namely, the fact that projectile explosions do not impart Karma impulses. I figured a simple override of Explode(), add some KAddImpulse() goodness, and i'd be all set. Not so.

First, we end up finding that we need to create our own HurtRadius function to be called instead of Actor::HurtRadius(). OK, we override that, override BlowUp() to call our new one.. throw some KAddImpulse() goodness in, and.. nothing. Increase the blast radius to around double the normal amount, to see what's going on .. I'm throwing these explosive devices at a pile of KActors, you see, and this time, I get the one that I hit moving (expected), along with one about a foot away from it, even though there were three others in the way first. Huh?

As I increase the size of the radius, objects farther away start getting Impulses, but objects closer stop. Apparently VisibleCollidingActors with a Radius specified doesn't actually give you a radius, it operates in the circumference of the circle defined by the radius from the blast. So, I move to RadiusActors. Same result. I move the blast radius to equal close to the area of the room. I shoot at the center, and I hit one object that's near a wall.. everything else, nada.

This engine is so full of things that so desperately appear to me to be bugs, I can't believe that it actually was sold to other people in the condition that it is in. Either that, or i'm totally missing something incredibly obvious.

04/06/06[edit]

I wish there were an "Edit This Page" link on the top, as well as the bottom, now that this page is large :)

I've spent the last couple days playing with menus, and emitters. I've never looked at the original Unreal code, and hardly at any of the newer UT2k3 or 2k4 code except for some very specific low-levelish things, so I don't know how they do their menus, but.. inspired by the original Unreal's amazing tech demo display when you loaded it's main menu, I decided that maybe having something showing instead of just a static background for the menu would be a cool thing. So, I spent some time farking around with the main menu, built a transparent and animated texture for the background of the main menu, and found that after closing all the other menus (why does Unreal open everything that looks like a menu, then use page flipping between them? is this a trick from 1998 to make things appear faster?) i had an actual LEVEL sticking through all that muck. So, I threw in some zombies, and some of the neat effects that i've been working on, and coded up some camera movement stuff. The other guys thought it was way cool :)

Also, as I've found Emitters to be incredible pains in the butt, I thought I'd share a little bit of my work with them with the rest of the community here, and maybe I can inspire others to share some of theirs as well.

EricBlade/Emitters

3/30/06[edit]

Replicating Karma sucks. The simulations are so radically different from each other on different machines, that it seems completely impossible that the server and clients could be using the same input data, unless the Karma system involves an assload of randomness. Seriously. Create a ball. Put it in a room with a few player starts, join 3 people into the game. Replicate the kicking of the ball, and watch as all 3 clients, plus the server, have the ball run entirely different simulations. It's horrible. Once you start replicating the Karma state from the server, to the clients, then you have something that moves in vaguely the same direction, but at about a quarter the speed it normally would, and it's constantly flipping back and forth between a couple of frames of animation, as it does it.

wow, we need a/some modeler(s), and textures. The textures that came with LOTD are ok, but 256x256 just doesn't seem to give the quality that i'm looking for. I dumped in a couple of much higher quality textures, and they just look incredible. Unfortunatly, the digital camera here is not so high a quality, it's one of the old Sony ones that uses a damn floppy disk for storage. Not sure what it's resolution is, but it's probably not good. So, I guess I need to learn how to make something look good in photoshop for Tiling purposes. I've got a couple awesome surfaces, but they don't tile very well right now :(

DeadAwake will definitely have a lot more blood than the original game. We've got some very awesome blood splats for use in Projectors, and such. Hopefully I can figure out some ways of modding the stock emitters that came with the game, as well, to improve the blood effects. Zombie games need lots of blood, right? Also, I need to look into how the corpses were done in the original game, and improve upon that, too. In a zombie outbreak, there'd be a lot more corpses that didn't get turned, I'd expect.. I'm thinking that instead of using a pawn that is stuck in a 1 frame animation (i think that's how it's done for the dead bodies in the game), it might be better to just throw in ragdolls .. maybe? I can't think of any other Engine games that would have corpses placed haphazardly on a level, so maybe that wouldn't be the way to do it. hmm.

3/26/06[edit]

Well, all that stuff is settled and taken care of. Now, I've moved onto WeatherEffect. Mostly have it working, all zoned off and pretty, and good stuff here. We've got some kick ass rain happening on a way souped up version of the original CH01 single player level (Jack's House) that came with the game. Now, the next interesting question, and I'd appreciate it if anyone might have any insight:

How do scale an Emitter's output, so I don't kill performance on slower computers?

This works for placed Emitters:

function PostBeginPlay() {
    Emitters[0].MaxActiveParticles *= Level.Game.EmitterDetail;
}

(obviously it's not exactly like that, but that's the meat of it)

However, it only works for emitters placed in the level. Emitters spawned within the game (such as from the EnableWeatherEffects() functions), it has absolutely no effect on. To make it affect those, I need to set it on a Timer. This does decrease the number of

particles, however it leaves us with a bunch of loose particles hanging in mid-air, since the emitter has already started. Setting

bDisabled = true, then running the timer, then setting bDisabled = false, results in the Emitter returning to it's original settings. (I imagine that MaxActiveParticles is reset by the function that restarts the emitter) oooh. That gives me a thought. Maybe bDisabled = true, setTimer(0.1), in the timer do bDisabled = false; then do the MaxActiveParticles.. maybe it won't have a chance to spawn all the spare ones before it gets throttled.

Nope, that doesn't do it.

Also, for the placed emitters, would it be better to have several small emitters placed at like windows and doors, or just have one big emitter around the entire house? I've currently got one emitter, with a SphereRange=(Min=1200,Max=1200), which seems like that would be better performing than having several small emitters.

3/16/06[edit]

OK, I've spent the last day and a half trying to figure out just what the hell went wrong in my custom Decoration class. I don't override any code in the base, except to record takedamage() in my debug setup. (or at least i didn't, when it mysteriously stopped working) As far as I can remember, it stopped working as I was working on getting sane defaultproperties, as the defaults for Decoration have virtually everything turned off for some reason. Here's what happens:

I load a level with a nice Decoration in it (in my test case, it's an ATM Machine, although i initially found it had stopped working with a bookcase and a coffee table). I go running full tilt into the ATM machine, and *poof* it disappears.

I reset all the default properties back to normal, recreated it, reloaded the level, and exact same thing.

Here are my default properties, with all the ones that i had changed before the issue started commented out:

     StaticMesh     = StaticMesh'DOTZSIndustrial.Outdoor.WoodenBox'

DrawType = DT_StaticMesh

//bBlockActors = true

//bBlockKarma = true

//bBlockPlayers = true

//bCollideActors = true

//bProjTarget = true

bStatic = false

bStasis = false

//bDamageable = true

//bPushable = true

//PushSound = Sound'DOTZXActionObjects.Crate.CratePush'

//FragType = class'Engine.Fragment'

//FragSkin = Texture'SpecialFX.Particles.rockchunks02'

I have now overridden every function in Decoration, along with a few in Actor, so that I can figure out what the heck the chain of execution is (it really pisses me off that this engine has no apparent way to actually just get a text string of the current execution chain, however it sure can give it to you when you breathe too hard and crash the editor!). Here's what's happening:

 Bump(mypawn) is getting called 4 times
 FellOutOfWorld() is called
 Destroy() then
 Destroyed()

w.t.f?

Yay, Figured it out. It was bCollideWorld. Seems to be an editor issue with this, though, in that if we build all with a decoration with bCollideWorld turned on, the editor takes a trip and crashes.

03/19/06[edit]

Anyone versed in Karma?

Is it possible, that Karma might actually be disabled at the engine level?

Just for grins, I wanted an object that I could just kick around, like the computers in Postal 2.. but in Land of the Dead.

So, I pull out my Postal 2 resources, load up the editor, and take a look at the computer in the RWS office. Looks like it's a "KActor", pretty much all default properties (looks like RWS may have added some extra stuff to KActor), so I go back to LOTD-Ed, and load up my test level with all my test stuff in it, and place a KActor, using the static mesh of, a hanging light. Put the light just off the

ceiling, start it up, run into it, and bounce right off, no affect. It's acting like PHYS_None.

Now, can someone correct me if I'm wrong here:

If I give something a nice set of Karma properties (like KActor defaults to), set it's default physics to PHYS_KARMA, and set KStartsEnabled = true, and place it in the middle of open space, the first thing it should do, is fall straight to the nearest floor/other solid object? Right?

I do this, and it just sits there just like any other object placed in the middle of space with phys_none.

Ugh?

SuperApe: Wish I was more competent with Karma, but isn't there a KWake() function that wakes up Karma objects? (evidentally only after it has come to rest, like on the floor) This from Karma Functions And Events:

native final function KWake();: "Wakes up" the actor. This causes the Karma physics to begin simulating after the object has been deemed to be "at rest."

EricBlade: thanks for the help, pretty sure that's not it,though. The object was just sitting there, floating in mid air, even with KStartsEnabled on, even when i shot it, or ran into it with my pawn :(

SuperApe: I only mention it because "floating in mid air", to me, doesn't seem like the Karma object ever came to rest.

EricBlade: Not even sure what the heck I'd do with that.. subclass kactor, and throw in a KWake in the PostBeginPlay?

SuperApe: Perhaps just try it on the floor first.

EricBlade: woot woot, i needed two things, apparently. (1) smeshes designed for use with karma (2) HighDetailOnly = false in the Karmaparams

03/21/06[edit]

Yesterday's experiment: Getting player to display on camera-texture-clients in single player mode.

Success: Not easily feasible as far as I can tell. Pfhoenix actually gave me a useful hint as to where to look to try to make this work, and managed to simultaneously educate me as well.

Today's first experiment: Download a couple of useful LWO files from turbosquid, and try and import them.

Success: For some reason my UEd doesn't import LWO files. The only file format supported for SMesh in is 3DS apparently.

Figured out the Karma stuff, at least to an initial degree. woot. Now, must find a way to get karma collision information on all the existing models in the game :-S i bet that's gonna be a task!

03/22/06[edit]

w00tness. Severed Karma Heads! with baseball bats, golf clubs, and shovels as our primary weapons, i can see a definite severed zombie head soccer type game in the near future. Just need to make a gametype and some GoalVolumes.

Now, is it possible to make Karma objects actually deal properly with hitting a player? Or is that because the player isn't drawn in single player, that a karma object can fall right through your head, and land at your feet, and you'll suddenly be walking on it? i know that a moving normal actor will not affect a karma actor that is at rest, so that will be an interesting thing to attempt to simulate. I heard of someone on here doing it by spawning a karma actor and attaching it to the player pawn, but i'm curious as to if it stayed attached where it was placed, or if it started simulating.. and how would i make an invisible karma actor, anyway? well, i guess they are already invisible if you don't give them a smesh.. hmm.. *thinks* any thoughts?

eh, n/m, that was waaaaay easier than i thought. In the Pawn's bump(), have it KApplyImpulse to any karma actors that it comes in contact with. not difficult at all. i probably need some sort of foot weapon, to come from underneath it though to get it some lift.

Legacy:EricBlade/Developer Journal

Contents

1/24/07[edit]

12/21/06[edit]

11/29/06[edit]

05/30/06[edit]

05/01/06[edit]

04/28/06[edit]

04/27/06[edit]

04/24/06[edit]

04/15/06[edit]

04/12/06[edit]

04/06/06[edit]

3/30/06[edit]

3/26/06[edit]

3/16/06[edit]

03/19/06[edit]

03/21/06[edit]

03/22/06[edit]

Navigation menu

Views

Personal tools

Navigation

Search

Tools