RE: [hlcoders] Making Usable Ladders
Yes in vbsp/textures.cpp:
// Handle ladders.
if ( ( propVal = GetMaterialVar( matID, %compileLadder
) ) StringIsTrue( propVal ) )
{
textureref[i].contents |= CONTENTS_LADDER;
}
That's where the custom compile flags are handled.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Josh Ferguson
Sent: Tuesday, February 01, 2005 12:41 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Making Usable Ladders
Correct, I knew about that...but how does the texture set the
CONTENT_LADDER flag on that brush? Does it happen when the
material is compiled with the $compileladder flag?
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Debug info ?
Yes, and the getpos command will dump this out at the console in a format that can be pasted back in as a command to teleport you to the current position. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Speyrer Sent: Wednesday, January 12, 2005 12:03 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Debug info ? cl_showpos 1 will show both your position (x y z) and your view angles (pitch yaw roll) -- David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of r00t 3:16 Sent: Tuesday, January 11, 2005 8:55 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Debug info ? When in developer mode is there a command to show you which way you are looking ? eg: x y z ? Which would show in the console or whatever? r00t 3:16 CQC Gaming www.cqc-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Keybind / prone
This won't work because you aren't debouncing the key. Two commands get
processed in a row and you prone/unprone because you haven't checked to
see that the user has released the key before you attempt to change
states.
We do this (normally called debouncing keys) in the game code using bit
fields. Look at the code for buttons pressed/released.
I don't have any of the code in front of me so I can't point you at
anything specific, but that's most likely to be the problem.
Also:
mv-m_nOldButtons != IN_PRONE;
Is not going to do anything.
You probably mean:
mv-m_nOldButtons = ~IN_PRONE;
Which would mask off the IN_PRONE flag.
Jay
wrote:
Not really.
Because what he said doesn't work.
I currently have
(disregard all the junk im trying to test stuff )
if ( mv-m_nButtons IN_PRONE )
{
if ( m_bToggleProne bInProne )
{
DevMsg(2,Will Unprone Here\n);
m_bToggleProne = false;
FinishUnProne();
mv-m_nOldButtons != IN_PRONE;
}
else
{
player-m_Local.m_bGoneProne = true;
player-m_Local.m_flPronetime = GAMEMOVEMENT_PRONE_TIME;
FinishProne();
m_bToggleProne = true;
DevMsg(2, Will prone here);
mv-m_nOldButtons != IN_PRONE;
}
}
You would think that would work ?
Well it scrolls the console forever
Will Unprone Here
Will prone here
Will Unprone Here
Will prone here
etc etc etc
As soon as I push the g button (that is what I have bound
to prone )
The above scrolls forever...
I would imagine because my prone does not have a KeyUp(in_prone);
this could be causing some issues.
As the flags need to be reset... KeyUp from what I can
tell does this
for you
Maybe Yahn or someone at valve can shed some light on this.
Maybe because this movement type I shouldn't add it this way.
r00t 3:16
CQC Gaming
www.cqc-gaming.com
- Original Message -
From: Hasan Aljudy [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Sunday, January 09, 2005 2:02 AM
Subject: Re: [hlcoders] Keybind / prone
Wasn't this answered by someone already? put an else if
On Sun, 9 Jan 2005 01:22:30 -0500, r00t 3:16
[EMAIL PROTECTED]
wrote:
Well that isn't the problem really.
The prone code is being called etc ..
The problem is the toggle on / off part.
On key press it prones
On key press again it unprones.
Funny part though DOD has a prone from the looks of the code :P
r00t 3:16
CQC Gaming
www.cqc-gaming.com
- Original Message -
From: Hasan Aljudy [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Sunday, January 09, 2005 1:06 AM
Subject: Re: [hlcoders] Keybind / prone
I think you don't need to do all this .. simply put it in a
ConCommand
static ConCommand prone(prone, CC_Player_Prone);
right above
it declare void CC_Player_Prone( void ) { [...] }
I'm not sure if this will work in multiplayer but by
looking at
some code, I *think* it will.
On Sat, 8 Jan 2005 23:40:35 -0500, r00t 3:16
[EMAIL PROTECTED]
wrote:
Could I remove the flag with
mv-m_nButtons = ~IN_PRONE; ?
r00t 3:16
CQC Gaming
www.cqc-gaming.com
- Original Message -
From: Tony omega Sergi [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Saturday, January 08, 2005 11:17 PM
Subject: RE: [hlcoders] Keybind / prone
Heh.
If (blah !prone)
{
}
ELSE -- VERY IMPORTANT!!
if (blah prone)
{
}
you're calling both functions TWICE if the button is down.
You also need to remove the button from
mv-m_nButtons WHEN
a toggle is set, or else it will just keep getting called.
-Original Message-
From: r00t 3:16 [mailto:[EMAIL PROTECTED]
Sent: January 8, 2005 11:12 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Keybind / prone
arggg...
Ok maybe im an idiot and missing the obvious but I can not
for the life of me get a working toggle for prone.
if ( ( mv-m_nButtons IN_PRONE ) !bInProne ) {
// go prone ...
GoProne();
bInProne = true;
DevMsg(2, go prone here); }
if ( ( mv-m_nButtons IN_PRONE ) bInProne ) {
// go unprone ...
GoUnProne();
bInProne = false;
}
Now becaue Prone(); ( NOTE Duck() is in
CGameMovement::PlayerMove()
This is where I also put Prone(); PlayerMove is
called from
some
Think()
function (haven't traced this)
Now because the above code gets often as soon as I set
bInProne = true; The GoUnProne(); is then a true
statement so
it also executes.
r00t 3:16
CQC Gaming
www.cqc-gaming.com
- Original Message
RE: [hlcoders] Movetypes and CollisionTypes
COLLISION_GROUP_NONE is the default collision group. These collide with everything. Other collision groups have special rules. E.g. COLLISION_GROUP_DEBRIS doesn't collide with other COLLISION_GROUP_DEBRIS. In the end, collision group is simply an id. The behavior of it is controlled by the mod's implementation of gamerules' ShouldCollide() function. In there you specific whether any pair of collision groups collides with each other. So you can make it do anything you want. If you don't want an entity to have any collision, you set the solid flag FSOLID_NOT_SOLID. AddSolidFlags( FSOLID_NOT_SOLID ); -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hasan Aljudy Sent: Friday, January 07, 2005 8:37 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Movetypes and CollisionTypes I don't know what's the deal with collision groups, but it seems when you put COLLISION_GROUP_NONE in a traceline it hits everything :/ On Fri, 07 Jan 2005 18:09:35 -0800, SuicideCommando [EMAIL PROTECTED] wrote: I'm trying to model bullets as projectiles. I based my bullet class off of CBaseEntity. I can get them to move correctly, but I'm having trouble with the collisions. I set the bullets as SetMoveType( MOVETYPE_FLYGRAVITY, MOVECOLLIDE_FLY_CUSTOM ); SetCollisionGroup(COLLISION_GROUP_NONE); thinking they would fly as projectiles, but not have any collisions set up. Instead, they fly straight thru the ground on the test map, but stick to objects (the hills and rocks). Anyone know why it's doing this? thanks, suicide ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Using a prop_physics with a preferred orientation?
It depends on what you want to have happen. If you want to pop the box back to some orientation, then you can just save the angles and teleport the object when it comes to rest. Otherwise you may be able to achieve something like what you want using a ragdoll constraint (with no translational constraint) or a phys_keepupright (like the turrets in HL2) that tries to keep the local up (0,0,1) vector pointing in a specific direction in worldspace by exerting procedural torque. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Flanagan Sent: Thursday, January 06, 2005 8:27 AM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Using a prop_physics with a preferred orientation? I'd like to make a box using a prop_physics, but I'd also like to make sure that it always lands with the same side facing upwards. Is there a way to set angles so that when it lands it saves them, or possibly a way to fix it after it lands so that the side I want is facing up? I've subclassed CPhysicsProp and set everything up to work how I'd like it to, except for this orientation thing. Anyone have any pointers? Thanks ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Possible bug with ragdoll
This is just status from the ragdoll separation solver. It only prints in developer 2. There are a bunch of messages like these in developer 2 mode that are only useful to a programmer working on that part of the code. You can safely ignore this message. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of r00t 3:16 Sent: Sunday, January 02, 2005 10:42 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Possible bug with ragdoll This is on the lastest updated sdk with no changes. This scrolled in the console forever. I used a frag while standing near a wall and killed myself with the frag and the ragdoll separation flags below was printed in the console forever. Ragdoll separation flags: 0007 (21655) Ragdoll separation flags: 0007 (21670) Ragdoll separation flags: 0007 (21684) Ragdoll separation flags: 0007 (21700) Ragdoll separation flags: 0007 (21715) Ragdoll separation flags: 0007 (21730) Ragdoll separation flags: 0007 (21745) Ragdoll separation flags: 0007 (21760) Ragdoll separation flags: 0007 (21775) Ragdoll separation flags: 0007 (21789) Ragdoll separation flags: 0007 (21805) Ragdoll separation flags: 0007 (21820) Ragdoll separation flags: 0007 (21835) Ragdoll separation flags: 0007 (21850) Ragdoll separation flags: 0007 (21865) Ragdoll separation flags: 0007 (21880) Ragdoll separation flags: 0007 (21895) Ragdoll separation flags: 0007 (21910) Ragdoll separation flags: 0007 (21925) Ragdoll separation flags: 0007 (21940) Ragdoll separation flags: 0007 (21955) Ragdoll separation flags: 0007 (21970) Ragdoll separation flags: 0007 (21985) Ragdoll separation flags: 0007 (22000) Ragdoll separation flags: 0007 (22015) Ragdoll separation flags: 0007 (22030) r00t 3:16 CQC Gaming www.cqc-gaming.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] new movements
All of the code for player movement is in the SDK. Take a look at game_shared/gamemovement.cpp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Ettinger Sent: Monday, January 03, 2005 8:02 PM To: hlcoders@list.valvesoftware.com Subject: [hlcoders] new movements Hello All, Are the basic movements of strafing and forward/backward built into the engine? Is it possible to add a fundamentally new movement, e.g. rotate about an axis passing through center of player and orthogonal to player's plane (if one were floating in space rather than standing)? I've been trying to step through the basic movements and run up against engine stuff which is not exposed in the source code. Or am I missing something obvious? Many thanks in advance ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Objects, Physics, and Gravity Concepts
The easiest way to do this is to turn bullets into projectiles. In HL2 they are a single raycast. But in your mod you could decide how fast they travel and sweep a ray over each tick from the previous position to the current position of the projectile. You could add gravity easily enough. This will still approximate the motion in each tick with a line, but you could subdivide further if you really need more curvature. If the linear speed is high enough compared to gravity or the tick rate is high enough there won't be much error with one segment per tick. // simplest per-frame integration function Vector newPosition = oldPosition + velocity * dt; Velocity += gravity * dt; UTIL_TraceLine( oldPosition, newPosition, ... Or you could even use vphysics objects if you want to spend a bit more memory CPU on each bullet. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Menard Sent: Monday, January 03, 2005 8:17 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Objects, Physics, and Gravity Concepts Not that I'm personally facing this problem, but wouldnt you be able to do a simple distance check and have the hitscan move down depending on how far it traveled and the gravity. The only problem I could see with this is that hitscan is a line and it would actually modify the trajectory of the bullet out of the barrel but there must be some way around it. Just providing a few suggestions. If you can't fix the bug, you might still have something relativly convincing... On Mon, 3 Jan 2005 15:19:37 -0500, r00t 3:16 [EMAIL PROTECTED] wrote: Thanks botman I will probably get this book :P r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Jeffrey botman Broome [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Monday, January 03, 2005 3:04 PM Subject: Re: [hlcoders] Objects, Physics, and Gravity Concepts r00t 3:16 wrote: But suppose you wanted it so players who shoot weapons had to compensate for distance, aiming a little ahead of a running player etc. Is the source engine able to do this? I think it probably depends on how fast you want the bullets to move through the air. If you make bullets a true entity (with gravity and collisions, etc), then you have to update their location as they move through the world (applying gravity, checking for collisions, etc.). Calculating the height change due to gravity over a given period of time is pretty straight forward high school physics (use google.com if you want the math). The real issue is that things that move VERY fast through the world don't get their position updated often enough to follow the path of a true parabola. You get something like this (excuse the ASCII graphics)... Game Ticks (StartFrame) at the 'v's v v v v x--x /\ / \ /\ / \ /\ / \ /\ x x The 'x' object follows the path of a parabola but because you are not ticking the engine at 1000's of times per second, you wind up with discrete locations along the curve (at the points in time where you can calculate where the entity will be at that time). If you are only checking for collisions at these points in time (or doing line/hull checks from the previous point in time to the current point in time), you will miss hitting entities that don't lie along your discrete path (like at the top of the arch in this case). You can modify the calculations so that you do your own stepping between discrete points in time to create a true parabolic curve and do your own collision checking to see if an entity was collided with, but this can be somewhat time/CPU consuming. There's a pretty good O'Reilly book called Physics for Game Developers... http://www.oreilly.com/catalog/physicsgame/ ...if you are really serious about creating realistic physics in games, you should definitely get that book (I hope your math skills are REALLY strong). :) -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your
RE: [hlcoders] Is Per-Entity Gravity Possible ?
To be clear: The per-entity gravity mentioned below only applies to
entities with movetypes that are simulated by the game (e.g.
MOVETYPE_STEP, etc)
For anything MOVETYPE_VPHYSICS, you run the Havok code for gravity (in
vphysics).
The only in-between case is players - where you have to do both or
change the player movement code to use only one of the systems (you can
do whatever you want here in your mod).
So, for MOVETYPE_VPHYSICS entities you can simply add a controller to
them to get whatever gravity you'd like. There's a built in controller
that gets put on everything by default. But you could write your own
gravity controller and then do:
pEntity-VPhysicsGetObject()-EnableGravity(false);
To turn off the default one.
To write the controller you should just use something like the constant
force controller.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Yahn Bernier
Sent: Friday, December 17, 2004 8:58 AM
To: [EMAIL PROTECTED]
Cc: Brian Jacobson
Subject: RE: [hlcoders] Is Per-Entity Gravity Possible ?
Correct, you'd have to convert gravity to a vector, which
should be doable. Brian was going to do this at one point
for kicks, not sure if he has any suggestions on what the
biggest issues will be. My gut is that the FL_ONGROUND
assumptions about the z axis in the movement code would take
a bit of time to unwind, but you do have all of that code in
the SDK at this point, so this should be very possible.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Xas
Sent: Friday, December 17, 2004 1:09 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Is Per-Entity Gravity Possible ?
For what I found, gravity is used as a float, not a
vector...=20 Even if we can found a vector gravity in low
level include, it seems = that it have not been generalized
(in sense that I can easily decide that my world has a
gravity like (-1, = 5,
64))
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de
Michael = Hobson
Envoy=E9 : vendredi 17 d=E9cembre 2004 09:51 =C0 :
[EMAIL PROTECTED] Objet : [hlcoders] Is
Per-Entity Gravity Possible ?
Yahn or Alex:
Do we have sufficient low-level access to Havok in order to
allow = per-entity gravity magnitude and direction vectors ?
{OLD}Sneaky_Bastard!
email: [EMAIL PROTECTED]
Michael A. Hobson
icq:#2186709
yahoo: warrior_mike2001
IRC: Gamesurge channel #wavelength
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Is Per-Entity Gravity Possible ?
Excellent!!! This is just what I need! So with VPHYSICS controllers, we can effectively extend Havoc/VPhysics, if we want to? That's got to be the most low-level access offered by any game engine SDK *EVER*. Thanks a whole bunch :D Yes - you can write your own code that gets called each time the rigid body is integrated. You can set a priority on that controller relative to other controllers so they can layer correctly in that case. There is some limited support for controllers on players already, so perhaps they will do what you want by default. You should also take a look at trigger_vphysics_motion - which implements a controller only when the physics are exactly touching a volume (defined by any brush model, could also be a prop or procedural if you write your own entity) as calculated by vphysics havok. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] QAngle arithmetics
QAngles represent an euler angle sequence in degrees. They have the same convention as Half-Life (and Quake). There are routines in mathlib that convert them to/from matrices and basis vectors. Those routines should give you a precise specification of the euler sequence, but it's the usual pitch, yaw, roll sequence. The first element is pitch, second is yaw, third is roll. They were designed to use primarily for simple AI - where you mostly just change one of the rotations. Note that the axes aren't set up so that angle.x is a rotation around the local x axis. (pitch is rotation around y axis, rotation around the x axis is roll). QAngle is not a term that's used outside of the Source codebase. The name was chosen to describe an euler sequence that uses the conventions of Quake. The RadianEuler type is an x/y/z sequence in radians. So that's a bit simpler mathematically. We use those in most of the animation system - and a similar representation for angular velocities/impulses in physics (AngularImpulse - although it's kept in degrees to make it easy to generate from AI code). The X, Y, Z axes are forward, left, up in an entity's local frame or east, north, up in world space. This is a right handed coordinate system. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hasan Aljudy Sent: Friday, December 17, 2004 5:48 PM To: hlcoders Subject: [hlcoders] QAngle arithmetics What mathematical object does QAgnle represent? Is there a good on-line source for the math of these angles? I tried google, but I don't know exactly what I should be looking for .. and searching qangle doesn't return much. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player Animations
The thirdperson view uses a set of cvars for the relative position. Set cam_idealyaw 0 to get it behind the model. It's probably set to 90 (default) which is the sideways view you mention. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Lewis Sent: Thursday, December 16, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: [hlcoders] Player Animations I tried switching the view mode to thirdperson and discovered that the player animations are stuck in the 'scarcrow' reference pose. Also, I noticed that the third person view is positioned to look sideways to the player rather than from behind. My questions are: * Is anyone else seeing this? (Maybe I changed something I shouldn't have) * What's the magic to get the upper body animation to play a sequence (like shooting) while the lower body continues to run/walk/idle. Right now, if you set an upper body sequence (such as ACT_RANGE_ATTACK_SMG1), it competes with the lower activity (ACT_RUN_RIFLE) causing severe jittering. * I also noticed that the player animation doesn't adapt to moving sideways or backwards like it does in the model viewer. What needs to be done to fix this? I think my problem is that I don't fully understand what's the distinction between an 'activity' versus a 'sequence' and how the two get merged together. Could someone offer some insight to this? Thanks. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] fopen and player model sequences
Just FYI: Some of the built in engine logs only work in multiplayer. So you need to set maxplayers 1 (run with +maxplayers 4 or something) to get output. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Netcode and Vehicles
So basically what your saying is Vehicle based mods are a no go for the source engine? This is totally not true. The SDK does not currently have an optimized network data model for vehicles, but it's completely possible to optimize (or otherwise redefine) the network data for vehicles in a mod. The current implementation works well for single player games, but it does use a fair amount of bandwidth. It would be straightforward to move much of the data over to the client and out of the network stream. Without doing more analysis of your mod and the current bandwidth usage of vehicles it's hard to say how much you'd need to strip from the stream. I don't have a date for when we'll release an internally developed solution. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] fopen and player model sequences
First, is there a way to re-enable 'fopen()'? Fopen is redefined in the preprocessor settings for the debug build. It's fine to reenable it as long as you realize you won't get the features of the steam filesystem (like searchpaths, support for gcf files, automatic updates, etc). For a log file you probably don't care. This define is a guard to prevent mistakes while we were coding HL2. Also, there is built in logging functionality in HL2. The engine implments these: static ConVar sv_logsdir( sv_logsdir, logs, FCVAR_ARCHIVE, Folder in the game directory where server logs will be stored. ); static ConVar sv_logfile( sv_logfile, 1, FCVAR_ARCHIVE, Log server information in the log file. ); static ConVar sv_logecho( sv_logecho, 1, FCVAR_ARCHIVE, Echo log information to the console. ); static ConVar sv_log_onefile( sv_log_onefile, 0, FCVAR_ARCHIVE, Log server information to only one file ); CON_COMMAND( log, Enables logging to file, console, and udp on | off . ) So you can just do: Log on at the console. And then you can use the Log() command in dbg.h to output logged data. If you need something more than that you can write your own log or hook ours in the debug library. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] GameFrame
Sv_alternateticks 1 cuts the server framerate in half for performance. You'll either get 15ms ticks or 30ms ticks depending on this variable's setting. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Sent: Monday, December 13, 2004 4:24 PM To: [EMAIL PROTECTED] Subject: [hlcoders] GameFrame (In serverplugin) GameFrame states its called about 60 times a second. If I do a Msg(%f,Engine-Time()); from it ..it looks like its firing about 30 times a second. Why would that be? Is there any way to get it to fire when there isnt any players in the server? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] manipulating hull / bbox
That's because the player logic has to run on the client as well (for
multiplayer prediction) so it's a special case.
You'll need to modify the functions in gamemovement.cpp:
const Vector CGameMovement::GetPlayerMins( bool ducked ) const
{
return ducked ? VEC_DUCK_HULL_MIN : VEC_HULL_MIN;
}
You could add this to the movevars and copy it in from the entity - then
SetCollisionBounds() would work - but you'd need to send the hull bounds
over to the client for proper prediction. In the case of ducking, we
want to predict the transitions too, so we implemented the hull size
changes in the shared movement code. You'll probably want to do the
same if your mod is multiplayer.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Hasan Aljudy
Sent: Monday, December 13, 2004 12:20 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] manipulating hull / bbox
Or if your mod has no vphysics at all, you can just skip the shadow
objects and set the size directly in the entity.
Well the problem is, using CBaseEntity::SetCollisionBounds
appears to change the bounding box, (as ent_bbox player
shows) but this box has nothing to do with collision. it can
go through walls, etc.
http://img110.exs.cx/img110/5110/small00068tp.jpg
On Sun, 12 Dec 2004 21:11:45 -0800, Jay Stelly
[EMAIL PROTECTED] wrote:
Vphysics shadow objects are for objects that are controlled by the
game logic. They follow the motion that happened in the game world
and cause the corresponding physical effects. The player
is a special
case that accepts feedback from vphysics.
Anyway, you don't have to have specific bbox objects in your mod if
you don't want to. You can create them dynamically as the players
change size. It's just a little faster if you cache them
so HL2 does.
Or if your mod has no vphysics at all, you can just skip the shadow
objects and set the size directly in the entity.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hasan
Aljudy
Sent: Saturday, December 11, 2004 2:09 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] manipulating hull / bbox
Thanks.
I wasn't trying to just changing the standing/crouhcing
hulls, I was
trying to _add_ more hulls.
I think I've figured it out, it's probably not a clean
way to do it,
but I had to mess with CBasePlayer::SetupVPhysicsShadow and stuff
like that ... but hey, it's working.
Anyway, why is this stuff called shadows? like
m_pShadowCrouch and
m_pShadowStand?
I'm thinking it's the shadow of the player's hull on the physics
engine, or something like that.
On Fri, 10 Dec 2004 16:26:59 -0800, Jay Stelly
[EMAIL PROTECTED] wrote:
The box is trivially changeable from within code. Just
change the
constants VEC_HULL_MIN or VEC_DUCK_HULL_MIN or the code
that uses them.
Also, turn on developer mode (run with -dev or type
developer 1 at the
console) and you can see debug overlays. They do many things
including visualization of entity bounding volumes.
Try ent_bbox
player at the console to see the player box in thirdperson mode.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Hasan Aljudy
Sent: Friday, December 10, 2004 1:59 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] manipulating hull / bbox
ok, I thought so.
for the bbox, I'm not sure, but after several hours of
searching I
found this CBaseEntity::SetSize but I'm not sure it works
the way I
think it does.
is there a coonsole command or someway to display the box
around my
player (assuming I'm in thirdperson mode)
On Fri, 10 Dec 2004 14:22:17 -0500, David Nelson
[EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ] no
there isn't a
model for the player. You can type thirdperson while
playing the game and you won't see anything. You
have to set you own.
David
---Original Message---
From: [EMAIL PROTECTED]
Date: 12/10/04 12:42:22
To: hlcoders
Subject: [hlcoders] manipulating hull / bbox
is it possible to change the size/dimensions of the
player's bounding
box through code?
Also, does the Single Player have a model for the player?
___
To unsubscribe, edit your list preferences, or view the
list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
--
___
To unsubscribe, edit your list preferences, or view the
list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] manipulating hull / bbox
Vphysics shadow objects are for objects that are controlled by the game logic. They follow the motion that happened in the game world and cause the corresponding physical effects. The player is a special case that accepts feedback from vphysics. Anyway, you don't have to have specific bbox objects in your mod if you don't want to. You can create them dynamically as the players change size. It's just a little faster if you cache them so HL2 does. Or if your mod has no vphysics at all, you can just skip the shadow objects and set the size directly in the entity. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hasan Aljudy Sent: Saturday, December 11, 2004 2:09 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] manipulating hull / bbox Thanks. I wasn't trying to just changing the standing/crouhcing hulls, I was trying to _add_ more hulls. I think I've figured it out, it's probably not a clean way to do it, but I had to mess with CBasePlayer::SetupVPhysicsShadow and stuff like that ... but hey, it's working. Anyway, why is this stuff called shadows? like m_pShadowCrouch and m_pShadowStand? I'm thinking it's the shadow of the player's hull on the physics engine, or something like that. On Fri, 10 Dec 2004 16:26:59 -0800, Jay Stelly [EMAIL PROTECTED] wrote: The box is trivially changeable from within code. Just change the constants VEC_HULL_MIN or VEC_DUCK_HULL_MIN or the code that uses them. Also, turn on developer mode (run with -dev or type developer 1 at the console) and you can see debug overlays. They do many things including visualization of entity bounding volumes. Try ent_bbox player at the console to see the player box in thirdperson mode. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hasan Aljudy Sent: Friday, December 10, 2004 1:59 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] manipulating hull / bbox ok, I thought so. for the bbox, I'm not sure, but after several hours of searching I found this CBaseEntity::SetSize but I'm not sure it works the way I think it does. is there a coonsole command or someway to display the box around my player (assuming I'm in thirdperson mode) On Fri, 10 Dec 2004 14:22:17 -0500, David Nelson [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] no there isn't a model for the player. You can type thirdperson while playing the game and you won't see anything. You have to set you own. David ---Original Message--- From: [EMAIL PROTECTED] Date: 12/10/04 12:42:22 To: hlcoders Subject: [hlcoders] manipulating hull / bbox is it possible to change the size/dimensions of the player's bounding box through code? Also, does the Single Player have a model for the player? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] manipulating hull / bbox
The box is trivially changeable from within code. Just change the constants VEC_HULL_MIN or VEC_DUCK_HULL_MIN or the code that uses them. Also, turn on developer mode (run with -dev or type developer 1 at the console) and you can see debug overlays. They do many things including visualization of entity bounding volumes. Try ent_bbox player at the console to see the player box in thirdperson mode. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hasan Aljudy Sent: Friday, December 10, 2004 1:59 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] manipulating hull / bbox ok, I thought so. for the bbox, I'm not sure, but after several hours of searching I found this CBaseEntity::SetSize but I'm not sure it works the way I think it does. is there a coonsole command or someway to display the box around my player (assuming I'm in thirdperson mode) On Fri, 10 Dec 2004 14:22:17 -0500, David Nelson [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] no there isn't a model for the player. You can type thirdperson while playing the game and you won't see anything. You have to set you own. David ---Original Message--- From: [EMAIL PROTECTED] Date: 12/10/04 12:42:22 To: hlcoders Subject: [hlcoders] manipulating hull / bbox is it possible to change the size/dimensions of the player's bounding box through code? Also, does the Single Player have a model for the player? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Using c_baseplayer in a server plugin
However this goes back to the point made before where the implementation might change and you can't rely on it. However there is no useful interface equivalent for entities, so worse come to worst you simply rebuild the plug-in come an update to the base entity. No. CBaseEntity can be changed by the mod's server.dll. So in the worst case every mod has a different data structure for CBaseEntity and your plugin needs a different version of its code to access CBaseEntity for each mod. You can't even count on recompiling to fix compatibility for more than a single mod. You really want to access through something like IServerEntity, or some other interface that the mod implements but can't change. That way you insulate your plugin from changes to each mod's code. You're compatible at the binary level, not at the source level. The same thing is true of user messages. There's no guarantee that each mod implements them the same way. The packets could be different in each mod. You'd be better off using an interface that allows the plugin to ask the mod's server.dll to send the message. HL2DM and CS:S are similar enough right now, but if you want your server plugins to continue to work as numerous third party mods appear, you shouldn't rely on the layout of things that aren't versioned/controlled with interfaces. Things will probably diverge pretty quickly. You should let us know what data you are trying to access in your plugins so we can add it to an interface and implement it in HL2DM CS:S. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] sourcesdk.gcf question
The reason we use the versioned interfaces in the Source SDK is to make it extremely unlikely that any mods will break as we upgrade the engine. We've done lots of engine updates over the years without breaking mods, and the interfaces are a new tool that make it even easier to do this successfully. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of tei Sent: Wednesday, December 08, 2004 9:03 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] sourcesdk.gcf question Ruari O'Sullivan wrote: [...] Hopefully Valve will be looking at an advance access program for modders in the future so we can respond to engine changes when they become necessary, or the first thing you know about a problem with your mod is when it starts segfaulting everywhere from SF to Sydney. -randomnine- Say... a bug on Source able remote root access, Valve fix that bug and update Source, all Source engines update but some mods broke. Humm... Can be interesting If Valve able to test patches before relase, so coders can test before the crash will ocurr (anyway modders will be lazy and will not test) Maybe Steam will support 3th modes update to stable, update to experimental and no updates, so modders will be able to debug against actual versions and future versions. This will also able some dedicated servers to inmediatelly apply updates even if where experimental,.. This its a similiar design decision as Debian has taken with woody, sid, etc.. Humm.. Real World sux :/ Fortunally enough, I dont work on valve, so I dont need to care about this problems. MuAHahahaha! :D ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Attempting to import te_ files to use (te_largefunnel)
te_largefunnel doesn't define a class with those members. They are members of CBaseEntity - declared in BaseEntity.h - so they aren't available (unless you add them) to a class derived from CBaseTempEntity. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Sent: Monday, December 06, 2004 1:41 PM To: [EMAIL PROTECTED] Subject: RE: [hlcoders] Attempting to import te_ files to use (te_largefunnel) Anyone? Someone has to know about this. Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Sent: Monday, December 06, 2004 11:36 AM To: [EMAIL PROTECTED] Subject: [hlcoders] Attempting to import te_ files to use (te_largefunnel) This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] OK I'm importing te_largefunnel.cpp into my project. I'm getting undeclared on variable such as: m_hMoveParent, m_hOwnerEntity among others. I have used grep to search the entire SDK and I'm unable to find where these are defined. Can anyone help me? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] IVEngineServer::PEntityOfEntIndex(int iEntIndex) issue in Plugin
Entity index 0 is the world entity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Sunday, December 05, 2004 10:14 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] IVEngineServer::PEntityOfEntIndex(int iEntIndex) issue in Plugin As far as i know, entityindex 0 is the server, normal players start at 1. GetUserID is the unique userid. When a new player connects, this userid will be incremented. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] sourcesdk.gcf question
Exactly. They are compressed on the wire, but not on disk. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey botman Broome Sent: Sunday, December 05, 2004 1:40 PM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] sourcesdk.gcf question Vyacheslav Djura wrote: P.S. Why VALVe doesn't compress any .gcf files? :-/ This would save a lot of time and money for users with low-bandwidth (dial-up). Respect people who have bought license versions of your game in undeveloped countries which do not have broadband in every house. I believe they ARE compressed WHILE you are downloading them. Once they have been downloaded, they are uncompress to the hard disk for fast access later when they need to be read. No sense waiting for 10,000 textures to uncompress when you are trying to load the game since disk space is SO cheap now adays. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Source SDK
1) I live in Kyiv, Ukraine. I have Half-Life 2 which can't reach my country regarding political situation. How do I get the SDK? I'm not sure I understand the question. I would tell you that you get the SDK through steam, but I assume you already know that. 2) I want to install SDK on multiple computers - what should should I do - buy HL2 for each of the computers and install Steam there? :O Or waste my friends ATI voucher just to download SDK? (internet is 3kb/sec) You don't have to purchase HL2 for each computer, simply use the same steam account on each computer. 3) What if I have slow connection (as I told previously - it is 3kb a second) and I want my friend to download SDK? How to do that? You can use your steam account on any computer. You can use the steam backup feature to move the SDK (or any other steam product) between computers and save download time. You can also just copy the GCF files using other means. Jay ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] New Physics Feature?
I haven't duplicated this experiment, but this is most likely a poor
explanation of a performance tuning parameter. If you're working with
the Source SDK, you can bound the CPU cost per simulation step of
vphysics using a parameter:
physenv-SetPerformanceSettings()
After you initialize your physics environment. Note that there are two
of these in most games (one on the client and one of the server) which
can be tuned independently.
Look at public/vphysics/performance.h
struct physics_performanceparams_t
{
int maxCollisionsPerObjectPerTimestep;
// object will be frozen after this many collisions (visual hitching vs.
CPU cost)
Increasing that value will change the tradeoff. It will cost more CPU,
but allow more interactions per object per step. For HL2 it's set to 6
(the default).
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ChessMess
Sent: Wednesday, December 01, 2004 11:40 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [hlcoders] New Physics Feature?
Original Post: http://www.halflife2.net/forums/showthread.php?t=58378
Source's Awesome (NEW?) Physics Feature!
--
--
I tend to type too much, so if you just want the info, go down to
DISCOVERY below. The rest of this is just back-story.
I'm a real fan of the physics made available in the Source engine.
Ever since I buddied up with a guy at Havok who let me try
out a few of their super secret concepts for the Source
physics engine, I've been playing with the physics like crazy.
Well today I booted up HL DM to play around in my own private
server to experiment with the hundreds of items featured in
DM_overlook.
I decided to stack up some explosive barrels against the
combine retaining wall, then pack as much of the physics
enabled stuff around them, blow them up, and watch my CPU
explode trying to calculate all the trajectories of the
different objects.
Here is a pic of about halfway through the stacking process.
Hunk O Junk
After that, I gravgunned the car and dumpster right up
against the pile. It was around this point that I noticed
something odd. None of the objects were jostling around,
floating or hovering in odd ways.
When I walked into the pile and bumped against it, it didn't
budge, and was solid.
I exploded the barrels with a well-placed magnum shot (could
you imagine how much fun satchel charges would be? Someone make them!)
Most of the outer objects flew off, but I noticed a good
number of the larger tables, etc, hadn't moved an inch. In an
attempt to investigate, I jumped on top of the remaining
pile, only to find it was rock-solid! I threw grenades,
rockets, even launched the dumpster at it from close range.
It didn't budge. I was able to climb all over the structure
without my weight causing any of them to move or jostle at all.
Then, I took the manipulator gun out and tried to pick up a
cabinet that was wedged in tight. It didn't move either.
These objects had become a solid mass that no longer reacted
to physics! Now at first, I thought that Valve, perhaps had
written in coding that would turn off physics for a certain
number of physics-enabled brushes that were touching each
other at the same time. This would be a smart move to save CPU power.
Then I booted up the console and lo and behold:
*DISCOVERY**
The brushes had not suddenly lost their physics-enabled
status, rather, they had become dependant on the other
objects they were resting on or under. The top items could be
removed with the manipulator, but they could also be stepped
on without that strange tipping sensation.
The processes in the console told the story:
Essentially this feature is a structure-building aspect to the coding.
It allows a stable (extremely stable) structure to be created
out of individual, physics enabled objects. These structures
can be dissassembled, but only in a realistic manner, in
which objects are only removed from the top down. Untill they
are freed this 'stasis'
one by one by the gravity gun, the objects function as one
immovable entity.
This melding stasis is initated by a specific script
apparently, and theoretically should be able to be enabled
and disabled via console.
The implications of this script (which I have not heard
mentioned yet) are far-reaching, especially in the
multiplayer mode. A large structure fashioned by players
working together on the same team could serve as a bridge
critical to reaching a mission objective. This script is
special in this case, because as anyone who has stacked
brushes in singleplayer to reach out-of-the-way areas knows,
they are very unstable normally, and it is easy to
destabilize an object stacked upon another object simply by
walking or jumping on it if you don't do it just right.
What I do not know about this script is EXACTLY what
RE: [hlcoders] filesystem_stdio.dll
This is a bug. The fix is included with the next SDK release. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Foss Sent: Tuesday, November 23, 2004 7:22 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] filesystem_stdio.dll aaah, my bad. On Wed, 24 Nov 2004 01:10:26 +1000, Teddy [EMAIL PROTECTED] wrote: Actaully, the hammer reference docs say: Once a map has been compiled and lit by VBSP and VRAD (respectively), the cubemaps can be built. Run the map and allow the any node graphs or other pre-process activities to finish. Then use the buildcubemaps console command to begin building the cubemaps for the level. If you try this, you'll of course get the error: mapname.bsp is not writable!!! Check it out before running buildcubemaps. Valve said the full SDK will have support for cubemaps, what i'm asking is how is this going to work? Teddy http://dystopia-mod.com/ On Tue, 23 Nov 2004 06:46:25 -0800, Andrew Foss [EMAIL PROTECTED] wrote: teddy: cubemaps are generated by the map. env_cubemap (?) entities (yes, more than one. Look at the cbble source) take a screenshot of the area they're in and determine what the cubemap for that area looks like. you want to load hl2 normally and then impulse 82(?) to get the spheres to test the cubemap with. it's in the hammer reference docs, IIRC. On Tue, 23 Nov 2004 20:45:12 +1000, Teddy [EMAIL PROTECTED] wrote: I was trying to find a way to build cubemaps for my maps, I think it will require running the /sourcesdk/hl2.exe file. But when you try to run it, it asks for filesystem_stdio.dll (which i presume is needed to run our mods in non-steam mode). Will valve release this with the Full SDK? Or will we need to run them in some kind of steam development mode? Teddy http://dystopia-mod.com/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Problems with Blood color
As I recall, the blood uses a range of colors in the base palette of your mod - gfx/palette.lmp It looks like it uses 10 colors for one of the particle effects (blood stream), so 245 would use palette entries in the range [245, 254]. So you should either modify the palette lump for your mod (will affect all particle effects as well as blood sprites), choose a starting entry that has 9 reasonable choices beyond it, or don't use the blood stream particle effects in your mod. It looks like the blood sprite effects use a 4 color range - so apply the same logic for those effects. In general, the hardcoded engine particle/sprite effects use small ranges from the palette. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of rat Sent: Sunday, October 17, 2004 1:47 PM To: [EMAIL PROTECTED] Subject: [hlcoders] Problems with Blood color I changed the blood color by changing the original value in the util.h file to a blueish white from the define: #define BLOOD_COLOR_RED (BYTE)245 This seems to work good to a point. For some reason sometimes you still see red on the screen. I did a search on word blood in the sdk and cant see anything really messing around with the color. Can someone point me to what else needs to be changed. I am suspecting that somewhere the color gets a bit of a darker or lighter color randomly that points it back to the original pallet value. The reason I think this is that the original value is in an area that has several shades of red besides it. Thanks, Rick J. Kelley ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
