Tutorial em Espanhol-Como trancar uma porta
O tutorial ensina como trancar uma porta e esta dividido em duas partes.
Parte 1
Parte 2
Post por Matheus Willian
Tutorial por xomux1234
Você está em: Home » Arquivos de janeiro 2011
News from Epic Games - January 2011 UDK Beta released
January 21, 2011 – Epic Games, Inc. has released the January 2011 UDK Beta, the latest version of the Unreal Development Kit (UDK), the free edition of Unreal Engine 3 that provides access to the award-winning toolset used in blockbuster video games, 3D visualizations, digital films and more.
Epic is committed to providing the UDK community with regular software releases at no charge, and the latest beta is available now at www.udk.com/download.
We’re very pleased to have released UDK with iOS support. UDK users are invited to check out our new iOS Development forum. Here, you can take advantage of free tutorials, documentation and help from other mobile developers.
Have a UDK project you want to show off? Share it with the community in the Works in Progress forum or the Released Projects forum.
It’s easy to sign up as a commercial UDK developer online. Our FAQ can help you determine which type of license is right for you.
Upgrade Notes
PhysX is now enabled for iOS development!
Rendering
· There is a new Colorize post process.
· You can now force depth of field.
The new Min Blur Amount post process setting can be used to force in-focus pixels to be blurred.
· Various image reflection quality and performance improvements have been made.
· Optimizations have been made to particle emitters, as well as memory improvements.
Mobile
· PhysX is now supported on iOS.
Rigid body physics, fracturable meshes and ragdolls are among supported features.
Note: Cloth, fluids and soft bodies remain disabled on iOS for performance reasons.
· Upgraded to iOS SDK 4.2
· The latest version of UDK Remote supports ping functionality, so it knows when it is talking to a PC.
· The latest version of UDK Remote's text entry box has been fixed on older versions of iOS.
Unreal Editor
· UDK now has a mesh selection preview.
You can now highlight sections of a mesh simply by selecting the corresponding material property.
· UDK now supports editor map favorites.
You can now star maps that you work with frequently and they'll persist in the editor's toolbar.
· Move to End of Track has been added to Unreal Matinee.
· The functionality of the individual translation and rotation track selections in the Matinee curve editor has been improved.
· A box for selecting subgroups within the matinee curve editor was added.
· The rotation widget now draws how many degrees have been rotated in the viewport.
· Kismet undo is now able to undo shortcut key-inserted sequence actions.
· An option to preserve degenerate triangles has been added to the FBX importer.
· Various fixes were made to the FBX importer, including rotations in Matinee, LODs, lightmaps, tangents on movement curves and auto tangents on cameras.
· When importing atop an existing object in an unloaded package, there will now be a confirmation screen instead of clobbering the existing object.
· The AnimSet Searcher now searches all AnimSets that are currently loaded.
· You can now double click on colors in the material editor to open a color picker.
· The new Align to Floor editor lets you snap actors using their pivot point.
· There is now a map check warning for combat volumes and triggers that aren’t referenced.
· You can now re-order properties in the favorites panel.
· A confirmation dialog is now displayed when baking instanced mesh paint data back to the mesh asset.
· The group selection dialog now defaults to listing just the groups in the current package.
· Properties for Location, Rotation and Scale3D are now displayed in real time in the property windows when objects are modified outside of them.
· Ctrl-Shift-A can now be used to select all Kismet actions.
Miscellaneous Enhancements
· Various improvements were made to Unreal Frontend including key bindings, map sorting and new cook/make buttons.
· The Bink player has been upgraded to version 1.99a.
· A new network profiling tool captures server information primarily for outgoing bandwidth as it relates to data transmission and network events.The network profiler takes into account all actors types, RPCs and properties that are replicated during a data stream and then summarizes replication counts and sizes.
UDN Pages
New:
· http://udn.epicgames.com/Three/HotSpotReportGeneration.html
· http://udn.epicgames.com/Three/DungeonDefenseDeveloperBlog.html
· http://udn.epicgames.com/Three/NetworkProfiler.html
Updated:
· http://udn.epicgames.com/Three/Scaleform.html
· http://udn.epicgames.com/Three/TextureStatsBrowserReference.html
· http://udn.epicgames.com/Three/CommandLineArguments.html
· http://udn.epicgames.com/Three/ContentCooking.html
· http://udn.epicgames.com/Three/WaypointsTechnicalGuide.html
· http://udn.epicgames.com/Three/NavMeshConstraintsAndGoalEvaluators.html
· http://udn.epicgames.com/Three/NavigationMeshReference.html
· http://udn.epicgames.com/Three/CustomLighting.html
· http://udn.epicgames.com/Three/MobileInputSystem.html
· http://udn.epicgames.com/Three/LevelEditorUserGuide.html
· http://udn.epicgames.com/Three/ContentBrowserDatabase.html
· http://udn.epicgames.com/Three/GameplayDebugging.html
· http://udn.epicgames.com/Three/UDKProgrammingHome.html
· http://udn.epicgames.com/Three/MobileMenuTechnicalGuide.html
· hhttp://udn.epicgames.com/Three/MobileHome.html
· http://udn.epicgames.com/Three/ContentBlog.html
· http://udn.epicgames.com/Three/UDKLevelCreationHome.html
· http://udn.epicgames.com/Three/ColorGrading.html
· http://udn.epicgames.com/Three/DevelopmentKitContentCreation.html
· http://udn.epicgames.com/Three/UnrealFrontend.html
· http://udn.epicgames.com/Three/KismetReference.html
· http://udn.epicgames.com/Three/ScaleformTechnicalGuide.html
· http://udn.epicgames.com/Three/UnrealiPhonePackager.html
· http://udn.epicgames.com/Three/AppleiOSProvisioningPortal.html
· http://udn.epicgames.com/Three/MobilePreviewer.html
· http://udn.epicgames.com/Three/DistributionAppleiOS.html
· http://udn.epicgames.com/Three/FullScreenMovieApple_iOS.html
· http://udn.epicgames.com/Three/DevelopmentKitProgramming.html
· http://udn.epicgames.com/Three/MobileKismetReference.html
· http://udn.epicgames.com/Three/DesigningForMobile.html
· http://udn.epicgames.com/Three/UnrealOnMobile.html
Community Links
UDK Forums: www.udk.com/forums
UDK Developers on LinkedIn: www.linkedin.com/groups?gid=2493123
UDK on Facebook: www.facebook.com/pages/UDK/183744733429
Epic Games on Twitter: www.twitter.com/EpicGames
Unreal Engine on Twitter: www.twitter.com/UnrealEngine
Anyone who has played a first person shooter game knows the importance of sprinting and crouching – in some cases, it’s the difference between getting shot and not. In theory, setting up a sprint or crouch function in the UDK is quite simple – you basically need to change the speed/height of the pawn while a key is pressed (or on a toggle if the player desires)
Fortunately, the UDK already includes a “crouch” function, which is horribly (in my opinion) bound to ‘C’ – I know, most people like this, I prefer Left CTRL. So to fix it in my bindings, I needed to change
.Bindings=(Name="LeftControl",Command="GBA_Jump")
to read
.Bindings=(Name="LeftControl",Command="GBA_Duck")
For sprinting, this is a little more involved, as most games employ a mechanic that allows a player to tire when running – additionally, a player cannot fire while running as they’d spray bullets everywhere. In effect, this is really simple to do, and involves adding the following to your Pawn class (which I assume you have already extended from UTPawn)
//Sprint handling variables
var float SprintSpeed;
var float WalkSpeed;
var float Stamina;
var float SprintTimer;
var float SprintRecoverTimer;
var float Empty;
var bool bSprinting;
exec function startSprint()
{
GroundSpeed = SprintSpeed;
bSprinting = true;
if(GroundSpeed == SprintSpeed)
{
StopFiring();
setTimer(SprintTimer, false, 'EmptySprint');
}
}
exec function stopSprint()
{
GroundSpeed = WalkSpeed;
}
simulated function EmptySprint()
{
Stamina = Empty;
GroundSpeed = WalkSpeed;
bSprinting = true;
setTimer(SprintRecoverTimer, false, 'ReplenishStamina');
}
simulated function ReplenishStamina()
{
Stamina = 10.0;
bSprinting = false;
}
defaultproperties
{
GroundSpeed=200.0
AirSpeed=200.0
//Overrides for Zombies game
WalkSpeed=280.0
SprintSpeed=500.0
SprintTimer=6.0
SprintRecoverTimer=4.0
Stamina=6.0
Empty=1
}
This relies on a key binding change in the DefaultInput.ini file, where you can add this line:
.Bindings=(Name="LeftShift",Command="StartSprint | OnRelease StopSprint")
Once compiled, you can hold the Left Shift key to sprint, or Left Control to crouch. This example is pretty noticeable, mainly as I don’t have any animations for my first person weapons, but if you do, just change the SprintSpeed and WalkSpeed properties to whatever you like and see the difference.
So, it’s been nearly a week since I did anything productive in the UDK, mainly due to the great Steam Treasure Hunt, so I thought that tonight would be a good time to get back into it. Leaving off from last time, I had a semi-effective aiming system that would leave a player zoomed in, but not looking down the sights of the weapon.
Here’s a quick look at it in action:
As with the other videos, I have not yet developed any decent models or textures, but they will come in time – probably when I have an “art department” to do them for me.
For the curious ones among you, this is how I did it – taken directly out of my ZombiesWeapon.uc file:
//-----------------------//
// HUD DRAWING FUNCTIONS //
//-----------------------//
simulated function DrawWeaponXhair(ZombiesHUD HUD)
{
local vector2d CrosshairSize;
local float x, y, ScreenX, ScreenY, ScaleX, ScaleY, StartX,
OldOrgX, OldOrgY, OldClipX, OldClipY;
local ZombiesHUD H;
H = HUD;
if(H != none)
{
if( !(bZoomedIn))
{
//We're firing from the hip, as inaccurate as that is...
CrosshairSize.Y = CrosshairCoordinates.VL * H.Canvas.ClipY/720;
CrosshairSize.X = CrosshairSize.Y * CrosshairCoordinates.UL / CrosshairCoordinates.VL;
ChangeVisibility(true);
x = H.Canvas.ClipX * 0.5;
y = H.Canvas.ClipY * 0.5;
ScreenX = x - (CrosshairSize.X * 0.5);
ScreenY = y - (CrosshairSize.Y * 0.5);
if(CrosshairImage != none)
{
//Draw the crosshair
H.Canvas.SetDrawColor(255,255,255,200);
H.Canvas.SetPos(ScreenX, ScreenY);
H.Canvas.DrawTile(CrosshairImage, CrosshairSize.X, CrosshairSize.Y,
CrosshairCoordinates.U, CrosshairCoordinates.V,
CrosshairCoordinates.UL, CrosshairCoordinates.VL);
}
}
else
{
//We are zoomed in. Are we looking down the sights, or is it a sniper
if(bIsScoped)
{
//We're holding a sniper rifle, and can see some distance
//We need to make the rifle invisible in this view,
//as opposed to aiming down the sights...
ChangeVisibility(false);
// the sniper overlay is a special case that we want to ignore the safe region
OldOrgX = H.Canvas.OrgX;
OldOrgY = H.Canvas.OrgY;
OldClipX = H.Canvas.ClipX;
OldClipY = H.Canvas.ClipY;
H.Canvas.OrgX = 0.0;
H.Canvas.OrgY = 0.0;
H.Canvas.ClipX = H.Canvas.SizeX;
H.Canvas.ClipY = H.Canvas.SizeY;
bDisplayCrosshair = false;
ScaleY = H.Canvas.ClipY/768.0;
ScaleX = ScaleY;
StartX = 0.5*H.Canvas.ClipX - 512.0*ScaleX;
if ( (Instigator == None) || (Instigator.PlayerReplicationInfo == None)
|| (Instigator.PlayerReplicationInfo.Team == None)
|| (Instigator.PlayerReplicationInfo.Team.TeamIndex == 0) )
{
H.Canvas.SetDrawColor(48,255,0);
}
else
{
H.Canvas.SetDrawColor(64,64,255);
}
// Draw the crosshair
// Draw the 4 corners
H.Canvas.SetPos(StartX, 0.0);
H.Canvas.DrawTile(HudMaterial, 512.0 * ScaleX, 384.0 * ScaleY, 2, 0, 510, 383);
H.Canvas.SetPos(H.Canvas.ClipX*0.5, 0.0);
H.Canvas.DrawTile(HudMaterial, 512.0 * ScaleX, 384.0 * ScaleY, 510, 0, -510, 383);
H.Canvas.SetPos(StartX, H.Canvas.ClipY*0.5);
H.Canvas.DrawTile(HudMaterial, 512.0 * ScaleX, 384.0 * ScaleY, 2, 383, 510, -383);
H.Canvas.SetPos(H.Canvas.ClipX*0.5, H.Canvas.ClipY*0.5);
H.Canvas.DrawTile(HudMaterial, 512.0 * ScaleX, 384.0 * ScaleY, 510, 383, -510, -383);
if ( StartX > 0 )
{
// Draw the Horizontal Borders
H.Canvas.SetPos(0.0, 0.0);
H.Canvas.DrawTile(HudMaterial, StartX, 384.0 * ScaleY, 1, 0, 3, 383);
H.Canvas.SetPos(H.Canvas.ClipX - StartX, 0.0);
H.Canvas.DrawTile(HudMaterial, StartX, 384.0 * ScaleY, 4, 0, -3, 383);
H.Canvas.SetPos(0.0, H.Canvas.ClipY*0.5);
H.Canvas.DrawTile(HudMaterial, StartX, 384.0 * ScaleY, 1, 383, 3, -383);
H.Canvas.SetPos(H.Canvas.ClipX - StartX, H.Canvas.ClipY*0.5);
H.Canvas.DrawTile(HudMaterial, StartX, 384.0 * ScaleY, 4, 383, -3, -383);
}
// restore the canvas parameters
H.Canvas.OrgX = OldOrgX;
H.Canvas.OrgY = OldOrgY;
H.Canvas.ClipX = OldClipX;
H.Canvas.ClipY = OldClipY;
}
else
{
//We're looking down the sights (maybe with a red-dot or an ACOG)
H.Canvas.SetDrawColor(255,0,0,200);
H.Canvas.SetPos(ScreenX, ScreenY);
H.Canvas.DrawTile(CrosshairImage, CrosshairSize.X, CrosshairSize.Y,
CrosshairCoordinates.U, CrosshairCoordinates.V,
CrosshairCoordinates.UL, CrosshairCoordinates.VL);
//Wonder if we can just move the model here?
PlayWeaponAnimation('Aim-Idle', 10000);
}
}
}
}
The few niggles with the old system finally got to, and wore me down. After spending a bit of time on a few improvements, I now have lights with a persistent state, so you can leave your light on and switch weapons without artifacts being left behind – and it’s really dead simple.
Two lines in the code are identical:
bLightEnabled = false;
These two lines need to be deleted, and the following block added:
simulated state WeaponPuttingDown
{
simulated function BeginState( Name PreviousStateName )
{
local UTPlayerController PC;
PC = UTPlayerController(Instigator.Controller);
if (PC != None && LocalPlayer(PC.Player) != none )
{
PC.EndZoom();
}
Flashlight.Destroy();
TimeWeaponPutDown();
bWeaponPutDown = false;
}
simulated function EndState(Name NextStateName)
{
Super.EndState(NextStateName);
if (SkeletalMeshComponent(Mesh) == none || WeaponEquipAnim == '')
{
Mesh.SetRotation(Default.Mesh.Rotation);
}
}
simulated function Activate();
/**
* @returns false if the weapon isn't ready to be fired. For example, if it's in the Inactive/WeaponPuttingDown states.
*/
simulated function bool bReadyToFire()
{
return false;
}
}
During the development, there was a slight issue where the light wouldn’t turn on until you had switched away, and then back to your weapon – This was a simple matter of the Flashlight object not being spawned, and the addFlashlight function has been modified accordingly:
simulated function addFlashlight()
{
if(bLight)
{
PlayWeaponAnimation('reload', 1.0);
WorldInfo.Game.Broadcast(self, "Light removed");
Flashlight.Destroy();
bLight = false;
}
else
{
PlayWeaponAnimation('reload', 1.0);
WorldInfo.Game.Broadcast(self, "Light added");
Flashlight = Spawn(class'ZO_WATT_Light', self);
Flashlight.SetBase(self);
Flashlight.LightComponent.SetEnabled(bLightEnabled);
bLight = true;
}
}
I managed to surprise myself at how simple this was after walking away from it for a little bit and coming back with a set of fresh eyes.
Last night I made a rudimentary flashlight that was either on or off, pretty simple really. Tonight, this has expanded into the ability to attach or remove a flashlight from a gun, and then turn it on or off if it is attached. This also works between guns, so one of your guns might have the light attached, and the other might not. As is my normal, i have created another video that shows this in action.
There are a couple of minor changes in the script from last night, mainly in the Weapon class, as shown here:
simulated function toggleFlashlight()
{
if(bLight)
{
bLightEnabled = !bLightEnabled;
WorldInfo.Game.Broadcast(self, "Weapon sent trigger");
FlashLightToggled();
// if we are a remote client, make sure the Server Set's toggles the flashlight
if( Role < Role_Authority )
{
ServerToggleFlashlight();
}
}
}
simulated function addFlashlight()
{
if(bLight)
{
PlayWeaponAnimation('reload', 1.0);
WorldInfo.Game.Broadcast(self, "Light removed");
bLight = false;
}
else
{
PlayWeaponAnimation('reload', 1.0);
WorldInfo.Game.Broadcast(self, "Light added");
bLight = true;
}
}
So, as you can see, not a lot different, but it makes a sizeable difference to the way that the game is played. The only things that really remain to be seen from a functional point of view are the implementation of some animations – which knowing me will be very rough ones; and turning the light off when the weapon is put away, otherwise an artifact of the old light is left in place, and a player could quite easily light up a room in this way.
Last night I had a bit of a talk about how someone had made a gun you can attach a silencer and scope and everything else to, and that their source code was available. In the short time that I’ve been awake this morning, I’ve managed to adapt this into my own application. I have used their guns, as quite simply everything was already set up, animated and textured, which for someone who is more of a coder than an artist is probably a good thing.
Anyhow, here is the result of what I got up to:
Having had a look at how PROOF had his code set up, it appears that the only lines I may have been missing came from my weapon class under the addFlashlight function:
simulated function addFlashlight()
{
if(bLight)
{
WorldInfo.Game.Broadcast(self, "Light removed");
PlayWeaponAnimation( 'SupOFF', 2.0 );
SkeletalMeshComponent(Mesh).DetachComponent(SlincerAttachment);
Flashlight.Destroy();
bLight = false;
}
else
{
WorldInfo.Game.Broadcast(self, "Light added");
PlayWeaponAnimation( 'SupON', 2.0 );
SkeletalMeshComponent(Mesh).AttachComponentToSocket(SlincerAttachment,SlincerSocket);
Flashlight = Spawn(class'ZO_WATT_Light', self);
Flashlight.SetBase(self);
Flashlight.LightComponent.SetEnabled(bLightEnabled);
bLight = true;
}
}
It all looks very simple, but was definitely the source of a few hours of head scratching to make it all happen. Big thanks to PROOF at unreal-level.ru for releasing his code to the public domain, as it has definitely pointed me where I need to be pointed for this one. Next on the list is to actually make my own guns with various attachments – so stay tuned!
Ever played a game of Unreal Tournament? Notice how the bots manage to shoot and kill you? Pretty essential behaviour for a game really – being able to kill, and be killed by, your enemies. For a while developing my game I had enemies who could be killed, but couldn’t use the weapons that I had provided them. As it turns out, this was an issue with my Weapon class, only pawns that were controlled by my PlayerController:
simulated function StartFire(byte FireModeNum)
{
local PlayerController plr;
plr = PlayerController(Instigator.Controller);
if(plr == none || bIsReloading) //You can't shoot while reloading
return;
if(DuraCount > 0)
{
super.StartFire(FireModeNum);
}
}
After a helpful post on the UDK forums by Blade[UG], I was pointed in the right direction, which was as simple as creating a new weapon specifically for bots, extending UTWeapon, rather than my ZombiesWeapon class. This weapon doesn’t have any extra functions happening in it, only the setting up of the models. In order to assign the correct weapons to our pawns, we need to do the following in our GameInfo class:
function AddDefaultInventory( pawn PlayerPawn )
{
local int i;
//Is the pawn a "Human" or a "Zombie"
if (PlayerPawn.IsA('ZO_PAWN_Base') )
{
//Humans get a gun and a knife (and fists)
DefaultInventory[0]=class'ZO_WEAP_Pistol';
DefaultInventory[1]=class'ZO_WEAP_Knife';
DefaultInventory[2]=class'ZO_WEAP_Fists';
}
else
{
//Zombies don't get a "weapon" per-se, they do get fists though... woo
DefaultInventory[0]=class'ZO_WEAP_ZFists';
}
for (i=0; i{
// Ensure we don't give duplicate items
if (PlayerPawn.FindInventoryType( DefaultInventory[i] ) == None)
{
// Only activate the first weapon
PlayerPawn.CreateInventory(DefaultInventory[i], (i > 0));
}
}
PlayerPawn.AddDefaultInventory();
}
Once this is done, I simply re-compiled the game and gave it a bit of a test. The only issue that I’m having at the moment is that the Zombie likes to try and attack you from far away, while only using their fists. Also, I’m able to headshot them from sniper distance while using a pistol, which hardly seems fair…