Re: [hlcoders] Removing an entity for real
Hallo, Wednesday, December 17, 2003, 03:44, Charlie Cleveland [EMAIL PROTECTED] wrote: I've tried UTIL_Remove, tried MakeDormant(), tried manually setting FL_KILLME and/or FL_DORMANT, and also the mysterious REMOVE_ENTITY, but nothing seems to work. Maybe the engine is deleting my C++ classes, but recycling the pevs at it's own discretion? I believe the engine holds an internal array of pevs... probably MAX_ENTS large. So when you delete an entity, all it really does is set a flag or so to mark this entity slot as free (for recycling it later, as you say). Maybe the engine doesn't check any those flags before calling into AddToFullPack, so you get it for all entities, not just for those actually sitting around in the world. -- Sebastian Steinlechner [EMAIL PROTECTED]//www.resourcecode.de In the beginning the Universe was created. This had made a lot of people very angry and been widely regarded as a bad move. - Douglas Adams ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Removing an entity for real
On Wed, 17 Dec 2003 16:01:26 -0500, mike [EMAIL PROTECTED] wrote: thats how pools work... Of course. Still, AddToFullPack shouldn't be called for entities that don't need adding, as they do not exist anyway. At least they do not have a representative in the world, while their pev might still sit around. -- Sebastian 'ttt' Steinlechner ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Visual Studio.NET Debug
Hallo, Sunday, October 19, 2003, 16:57, Jonathas Costa [EMAIL PROTECTED] wrote: I am trying to debug HL SDK 2.3 in VisualStudio.NET, but still nothing. I tried Pink and Mazor tutorials, but in .NET I don't find where to put the additional dlls. Debugging works fine for me without explicitly setting those dlls. Just run hl.exe from the debugger and it will load the correct debugging dlls. -- Sebastian Steinlechner [EMAIL PROTECTED]//www.resourcecode.de In the beginning the Universe was created. This had made a lot of people very angry and been widely regarded as a bad move. - Douglas Adams ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] m_iPrimaryAmmoType outside of weapon code possible?
On Sat, 2003-09-20 at 15:24, Tuomo Virtanen wrote: Is it even possible to use m_rgAmmo[m_iPrimaryAmmoType] outside of weapon code like in multiplay_gamerules.cpp the reason for this is because i need to use the values that it holds for something else also That's perfectly fine if you have a pointer to the player. m_rgAmmo is of course bound to a specific player (otherwise all players would have the same ammo count). So make sure you get a pointer to the correct player (quite likely you have one already), then you can use it. Sebastian ttt Steinlechner ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] (no subject)
Hallo, Saturday, August 2, 2003, 18:06, Marco Leise [EMAIL PROTECTED] wrote: btw... I am a C++ noob, is there a Delphi version? I use Delphi 7. This would be cool, cause i am much more familiar with Delphi than any other language. I simply quote botman: There isn't one and it would be difficult to convert it from C++ to Pascal. I doubt anyone has the desire to do this. That's exactly what applies here. -- Sebastian Steinlechner [EMAIL PROTECTED]//www.resourcecode.de In the beginning the Universe was created. This had made a lot of people very angry and been widely regarded as a bad move. - Douglas Adams ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Java and Half-Life
Hallo, Friday, August 1, 2003, 18:02, Joan M. Davis [EMAIL PROTECTED] wrote: Nope, not in DllMain. The code exists in a new class that I created. However, the class is never instantiated; thus, the JNI_CreateJavaVM() is never invoked. For some reason, the existence of the method causes the error in Half-Life. That's the confusing part. Maybe you need some library or dll for the java stuff which windows can't find upon loading your code. Then hl can't get a handle to your dll and bails out with the error. -- Sebastian Steinlechner [EMAIL PROTECTED]//www.resourcecode.de In the beginning the Universe was created. This had made a lot of people very angry and been widely regarded as a bad move. - Douglas Adams ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] FW: Half-Life: fun with MODs
Hallo, Wednesday, July 30, 2003, 11:20, Steve Rukuts [EMAIL PROTECTED] wrote: Of course people can do that. It's an issue with all software you download, regardless of whether it's a mod for a game or a text editor or something. Software like that can potentially contain malicious code. That's exactly what I was going to say, you'll always want to be sure from where you download mods etc., just as with any other software you download. Of course this is a security risk, but not a risk that can be dealt with somehow. You'll just have to believe the mod authors, just as you believe Microsoft (uhoh, bad example?). The liblist.gam overflow is also not something serious. Why fiddle around with liblist.gam when you can erase the complete harddisk via a call in the dlls? In addition, all these security risks are local risks, i.e. you have to actually download and run something before anything can happen to your computer. However, there are two more advisories that were released. And those two are indeed serious security risks, as they are remotely exploitable: 1: http://www.pivx.com/luigi/adv/hlbof-client-adv.txt 2: http://www.pivx.com/luigi/adv/hlbof-server-adv.txt -- Sebastian Steinlechner [EMAIL PROTECTED]//www.resourcecode.de In the beginning the Universe was created. This had made a lot of people very angry and been widely regarded as a bad move. - Douglas Adams ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] FW: Half-Life: fun with MODs
Hallo, Wednesday, July 30, 2003, 23:21, Michael A. Hobson [EMAIL PROTECTED] wrote: Games that use byte-code script interpreters which run a mod's code in secure sandboxes in Java fashion -- with no actually machine contained in the mod -- cannot be used to implement trojan mods. However, virtually any mod comes with an installer executable so that additional files all go in the right places. No need to mess up the computer with the mod itself, just put some evil code in the installer. -- Sebastian Steinlechner [EMAIL PROTECTED]//www.resourcecode.de In the beginning the Universe was created. This had made a lot of people very angry and been widely regarded as a bad move. - Douglas Adams ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Mouth movement for voice
Hallo, Wednesday, February 26, 2003, 22:52, botman [EMAIL PROTECTED] wrote: I think I remember a post by Yahn on the topica.com discussion from a few years ago where someone asked about how to override the engine audio output and Yahn posted some code that showed how it might be done. That's correct. I was unable to find the mail in the archives (I'm quite sure it's there, though), but I found the code that belonged to that very mail on my harddisk: http://www.resourcecode.de/files/soundsystem.cpp -- Sebastian Steinlechner - mailto:[EMAIL PROTECTED] - www.resourcecode.de ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Bugtraq: hl exploits
Hallo, Friday, January 10, 2003, 20:44, botman [EMAIL PROTECTED] wrote: Thanks botman, I was unsure whether it would be a good idea to post the urls here, so you decided it for me... http://online.securityfocus.com/archive/1/306120/2003-01-07/2003-01-13/0 Actually, this advisory isn't researched to the end. The main problem lies in cl_dll's text_message.cpp. Looking at CHudTextMessage::MsgFunc_TextMsg() it's clear to see that there are MANY potential buffer overflows. e.g., READ_STRING is able to return a char array as long as 2048 chars, however, MsgFunc_TextMsg() does only declare an array of 128 chars, where the string returned by READ_STRING is copied into via strcpy without any checks. -- Sebastian Steinlechner - mailto:[EMAIL PROTECTED] - www.resourcecode.de ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Saving and the HLSDK
Hallo, Monday, December 30, 2002, 09:48, Ryan Professional Victim Desgroseilliers [EMAIL PROTECTED] wrote: In any case, saving cannot realistically be implemented for some entities, such as the introductory camera sequence's particle systems, due to significant portions of the code having to be entirely client-side. If I could spirit the problem away with a few save/restore macros, I obviously wouldn't have asked the question in the first place, and would simply have done that. Yes, that's a problem I ran into with Poke646. As everything happening on the client (e.g. TriAPI) cannot be saved directly, one has to find some way to save and restore them on the server, which often is a pain in the ass. I did not think of intercepting the saving code, but now that you mentioned it, I had a look at the code again. Unfortunately, the only thing happening serverside in a save/restore is that DispatchSave() is called with the entity that should be saved. The engine gets the address of DispatchSave() via the function pointers that are provided within GetEntityAPI(). So, it seems to me that there is really no way of disabling saves, as it's the engine that initiates them - once it calls DispatchSave() for each entity, it's already too late. And I doubt that the hllauncher uses server commands to communicate with the engine, but instead will directly call into the save/reload functions - so no way of preventing them from getting called. -- Sebastian Steinlechner - mailto:[EMAIL PROTECTED] - www.resourcecode.de ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] FGD's and coding
Hallo, Sunday, November 24, 2002, 10:45, Paul Bean Jr. [EMAIL PROTECTED] wrote: Howdy, I'm really interested in how FGD's work and such, I want to know the real deal, is their some design documents, or tutorials that are written on them [...] Well, I wrote a tutorial about it, but unfortunately it's in German. You might give it a try with a translator, though: http://www.resourcecode.de/?tutorial=1id=16 I guess the file format changed a bit with later editors like Hammer. But the basics remain the same. -- Sebastian Steinlechner - mailto:[EMAIL PROTECTED] - www.resourcecode.de ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] detecting mapchange client-side
Hallo, Wednesday, November 13, 2002, 18:56, Cortex [EMAIL PROTECTED] wrote: I finally got it to work !! I use the method that is used in the new (SDK 2.3) overview code. It checks at each call of Reset if the name of the map has changed (using gEngfuncs.pfnGetLevelName()). If it has changed, I delete my rain until I get a new message from the server. You could also use void TeamFortressViewport::Initialize( void ); in vgui_teamfortressviewport.cpp. A comment above this function says it's called everytime the map changes. Works fine for me. -- Sebastian Steinlechner - mailto:steinlechner;gmx.net - www.resourcecode.de ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Particle System
As long as you make sure that you're careful about allocating memory, you should be fine. My particle engine utilizes two lists per system, one for particles to be displayed and one for trash particles to be reused. Eventually what I might want to do is simply have an engine list for the trash particles, so that all the systems can dip into the same pool. Anyway, though, the current system is plenty fast. That's (almost) exactly how my particle system works, two linked lists. I thought about using arrays, too, but that's just a waste of memory I guess. In addition, if a particle burns out, what do you do? In a linked list, you just move the particle over to the list of particles to reuse. Then you adjust the next-pointer of the previous particle and you're fine. Now with an array, you would have to set this array position to NULL or so, then if you want to create a new particle, you'd iterate through the array, searching for a place that is NULL. Now do this if you have, say, 1 particles. I guess that'll be slow, won't it? Just in case you're interested, here's mine: http://www.resourcecode.de/stuff/particles_eng.html cya, TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] vehicles
I guess you have to do the following: Do a traceline straight down to the ground at the front and at the back. Then see whether there's any difference in trace length (forget about a few tenths, it's only whole units that make a difference). If there is, use some triangle maths to calculate the angle of the slope. Once you got it, use this new angle to correct the vehicle's acceleration. --- TheTinySteini - www.resourcecode.de - www.poke646.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Semi-transparent TGAs in VGUI?
In Photoshop, you have to create a new channel. This will then be the alpha channel. Just paint into it in grayscale. White will be completely opaque, black completely transparent. Works fine for me. But it seems like HL scales the images down to 256 colors before displaying them, just like sprites can only have 256 colors. If it could allow for 16 bit colors, that would help a lot. Oh well... I don't know the name for the TGA format, but in my graphics software, I just create a mask using the background and save it in 24 bit format (I think it then becomes 32 bit because of the mask?) and it works properly. I use Corel Photopaint though which isn't very popular and you may have to do it differently in Photoshop. It is not like sprites though where the last colour in the palette is rendered transparent. Rob Prouse http://www.tourofdutymod.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client-side prediction
I haven't tried adding other (non-player) entities to see if hey have an entity_state_s associated with them. Now I have. It doesn't look like they do, or at least it's not coming through HUD_TxferPredictionData. Probably the latter? Actually, you can access an entity_state_s for other entities (that's about the only way to get their origin, e.g. to attach a sprite to them). But those are not predicted, afaik. So all the data stays the same until the next update from the server arrives. That's why tossing a grenade still looks a bit jerky in internet games, I guess. TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Scope Sprites
You can also check if the currententity is the viewmodel on the model rendering code and just return when it goes to draw it. Ah, cool, I did not think of that. Speaking of the viewmodel, is there any information on when it is actually drawn? I played around a bit with rendercycles some time ago and ran into serious color-shifting troubles when I drawed some triapi in the second rendercycle. World drawing was only enabled for the first cycle. It seemed to pick up the viewmodel's colors. So, is there any further information on rendercycles/viewports? Thanks, TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Scope Sprites
Actually, there IS a drawback in my code. As the weapon model is rendered
AFTER triapi (or with depthfunc disabled), it shows in front of the
polygons. I tried to get a viewmodel pointer clientside and set its
renderamount to 0, but that did not work. I got it to be halfway
transparent, but it never disappeared completely. So what you have to do is
to set the viewmodel to NULL either serverside or clientside (the first way
definitely works - I haven't tried the second yet).
Cool :)
good coded LOL
- Cortex : mapper coder www.hlalbator.fr.st
- Original Message -
From: Sebastian Steinlechner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 29, 2002 9:30 PM
Subject: Re: [hlcoders] Scope Sprites
Yes, it does... here's how I did it, I'm calling this from
HUD_DrawTransparentTriangles (well, not exactly this, it's somewhat
different in Poke646, but the idea maths is the same):
--- snip ---
#define SCOPE_DISTANCE 10
#define M_PI 3.14159265358979323846
extern vec3_t v_angles, v_origin;
void CSniperScope::DrawScope( void )
{
if( !fActive )
return;
cl_entity_t *player;
// make sure the player is up and running
player = gEngfuncs.GetLocalPlayer();
if ( !player )
return;
// load sniper scope sprite if necessary
if ( hsprSniperScope == 0 )
{
char sz[256];
sprintf( sz, sprites/scopeborder.spr );
hsprSniperScope = SPR_Load( sz );
}
vec3_t viewAngles, v_up, v_right, v_forward;
gEngfuncs.GetViewAngles( viewAngles );
AngleVectors( viewAngles, v_forward, v_right, v_up );
// the sprite's origin
vec3_t org = v_origin + v_forward * SCOPE_DISTANCE;
// adjust size to fov (simple triangular maths)
float fovadjust = tan( gHUD.m_iFOV / 360.0 * M_PI );
float size = (SCOPE_DISTANCE + 1.0) * fovadjust; // little bigger than
necessary
// use this to overlap the triangles a bit
float pixel = size / 256.0;
float r, g, b, brightness;
r = g = b = brightness = 1.0;
vec3_t temporg;
// now set up triapi code
gEngfuncs.pTriAPI-RenderMode( kRenderTransTexture );
gEngfuncs.pTriAPI-CullFace( TRI_NONE );
for( int i = 0; i 4; i++ )
{
if ( !gEngfuncs.pTriAPI-SpriteTexture( (struct model_s
*)gEngfuncs.GetSpritePointer( hsprSniperScope ), i ))
{
return;
}
gEngfuncs.pTriAPI-Color4f( r, g, b , brightness);
gEngfuncs.pTriAPI-Begin( TRI_QUADS );
gEngfuncs.pTriAPI-Brightness( 1 );
gEngfuncs.pTriAPI-TexCoord2f( 0, 1 );
switch( i )
{
case 0: temporg = org + (v_right * -size); break;
case 1: temporg = org; break;
case 2: temporg = org + (v_right * -size) + (v_up * -size); break;
case 3: temporg = org + (v_up * -size); break;
}
gEngfuncs.pTriAPI-Vertex3fv( temporg );
gEngfuncs.pTriAPI-Brightness( 1 );
gEngfuncs.pTriAPI-TexCoord2f( 0, 0 );
switch( i )
{
case 0: temporg = org + (v_right * -size) + (v_up * size); break;
case 1: temporg = org + (v_up * size); break;
case 2: temporg = org + (v_right * -size) + (v_up * pixel); break;
case 3: temporg = org; break;
}
gEngfuncs.pTriAPI-Vertex3fv( temporg );
gEngfuncs.pTriAPI-Brightness( 1 );
gEngfuncs.pTriAPI-TexCoord2f( 1, 0 );
switch( i )
{
case 0: temporg = org + (v_up * size); break;
case 1: temporg = org + (v_right * size) + (v_up * size); break;
case 2: temporg = org; break;
case 3: temporg = org + (v_right * size) + (v_up * pixel); break;
}
gEngfuncs.pTriAPI-Vertex3fv( temporg );
gEngfuncs.pTriAPI-Brightness( 1 );
gEngfuncs.pTriAPI-TexCoord2f( 1, 1 );
switch( i )
{
case 0: temporg = org; break;
case 1: temporg = org + (v_right * size); break;
case 2: temporg = org + (v_up * -size); break;
case 3: temporg = org + (v_right * size) + (v_up * -size); break;
}
gEngfuncs.pTriAPI-Vertex3fv( temporg );
gEngfuncs.pTriAPI-End();
}
}
-- snap --
cya,
TheTinySteini
- Original Message -
From: Cortex [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 29, 2002 7:56 PM
Subject: Re: [hlcoders] Scope Sprites
I don't understand how you got it to work using TriApi ! How did you get
the
coordinate of the polys you had to display ? It has to depend from the
view
angles, don't they ?
___
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] 1000+ are nice?
yeah i guess they are, but by the time CZ comes out Unreal2 with its 5000+ tri models and 100,000 wpolys (that's on a geforce2 even) will be out too... Actually, you can't tell me there are really 100,000 polys on the screen. But it looks like. I guess the biggest thing why the HL engine is outdated is the fact that it does not support LOD. Take Serious Sam as an example. There you can define that e.g. stairs automagically reduce their poly count when you move away from them. You don't really notice it, and it saves a lot of polygons. Same with models. Though you can implement a simple lod for player models in HL (just as HolyWars did, IIRC). And HL still supports full software rendering. You can image that eats a hell lot of cpu time. Even if you are in hardware mode. I might be wrong with that, but that's how I see it. cya, TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Playing with the view model rendering
Never mind, as per usual I worked it out right after mailing the list ;P Did you get the viewmodel to disappear? Cause I had that problem some time ago, wanting to change the viewmodels rendermode to TransAdd or TransTexture and then setting amount to zero, so it disappears. But it did not work the way I expected. It was still visible... cya, TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] TriAPI weirdness
Hello, Now here's something I can't explain. I messed around a bit with those triangles and came across a weird bug. I'm displaying triangles using TRI_TRIANGLES_FAN and kRenderNormal in a second rendercycle. The triangles do not have a texture, they are colored simply by calling Color4f. Works fine, until... ... I pick up a weapon. Look at what happens: http://gymnasium.sarstedt.org/rpg.jpg http://gymnasium.sarstedt.org/satchel.jpg http://gymnasium.sarstedt.org/egon.jpg Simply by switching between the weapons, the color changes! Why? It should be a greenish triangle, but it changes to orange or black!? Would be nice if someone could clear things up. cya, TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] TriAPI weirdness
are you drawing it in the transparent triangles or the normal triangles call? try moving it from one to the other Normal triangles. Transparent triangles does not seem to be called in a second rendercycle... I don't know why, but perhaps that's why overview rendering is done from normal triangles, too. cya, TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Modeling Rendering in the Customize Menu
you cant directly (onto the hl shell or vgui menus) but you could do what dc did which was make a map which is a black box, then create a temp model using the efx api, set the view to directly infront of it and then draw the vgui menu onto the screen, if the view is real close then it looks like its drawn onto the screen. Actually, instead of using a black box, you could turn of rendering of the world using pparms-onlyClientDraw. Have a look at view.cpp. Sorry for hijacking this question, but is there a good way for drawing triapi triangles directly on the screen? I.e. without z buffer checking so you don't run in a wall and that hides your triangle? cya Sebastian Steinlechner ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Screenshot format
Its just that i was taking some shots yesterday, and half of them ended up as .bmp files in the halflife directory and then the other half as tga files in the mods dir?! The only thing i can think of was that half way though i binded mouse3 to screenshot and used that instead of f5. There are two commands. screenshot saves as .tga in your mod directory, I guess. And there's another one which I can't remember now. That one saves a .bmp, directly into your hl root. cya, TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] TGA Files in Menus
Hi, Getting back to the original question (TGAs showing up with only 256 colors). I tried it myself and I got only 256 colors, too. It looked ok, but having at least 16bit would be muuuch better. So, why does HL reduce the color depth? To me that does not make any sense, does it? cya, TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] TGA Files in Menus
A question just out of curiosity: How large may those tga images be? Are there the same restrictions (256*256) as there are with textures or can they be any size you want? TheTinySteini You need to use a 32-bit TGA 24bit color and 8bit alpha HL will change the color to 16bit and use the alpha for transparanticy(sp?) -Ms ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Counting players
Now I presume I can just set edict-free to true when a bot disconnects to rectify this (as UTIL_PlayerByIndex will ignore it then), but I don't want to just do that without knowing if that's going to have more far flung implications. Is this safe to do? IIRC, when clients disconnect, the edict is left in place but pev-classname is set to NULL. This was discussed quite some time ago, perhaps someone can remember? TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] HLTV overviews
As i recall... you put NOCLIP on, fly _above_ the level look down, and set a special CVAR that changes how HL renders the level... so there is no perspective... then just take a screenshot. You'll have to alter it in a paint program afterwards Suitable vague explanation, but i can't remember the specifics :) IIRC, you have to join a hltv server for the command to work correctly. Otherwise you'll just get a green screen, but can't see the level. TheTinySteini ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
