Re: [hlcoders] Where to place / Editing Entity's Client-Side (Let's try this again)

[Jonas 'Sortie' Termansen]

Well, doesn't the client load the prop_static entities and the like?

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Problems with shader samples in the SDK?

[Jonas 'Sortie' Termansen]

Are lightmaps actually being built for the material/shader in VRAD?
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Steam Gamestart menu

[Jonas 'Sortie' Termansen]

On Source, user created code is first run quite a while after the game has 
started launchng, hell even quite a while after your dlls are loaded. I once 
did this by exiting the game in the first called usercode, and then launchng 
another executable. I think the same is possible with GoldSrc.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Duke Nukem Forever Whiteboard in Source?

[Jonas 'Sortie' Termansen]

You might also want to have a look at produceral textures, and perhaps 
how the AVI code available on the wiki is done.


On 2010-10-04 06:28, Joel R. wrote:

You'd first have to know the size of the board.  Then just use a ray trace
to capture where on the board you are clicking and convert to 2D
coordinates.  Then using a RenderTarget for the board texture, you should be
able to edit the image directly pixel by pixel.  I don't remember the exact
functions anymore, but it is possible.


On Sun, Oct 3, 2010 at 2:23 PM, Trevor 'Drak'  wrote:

   

I'm sure most of you have seen the DNF game play videos. If not, you're
crazy and need to watch this: http://www.youtube.com/watch?v=SDjJRRbOvzU
Skip to about 4 minutes for the gameplay. As you can see there is a
whiteboard that you can draw/erase (change colors?) and it's pretty darn
realistic.

Soon as I saw this awhile back from a different video, I attempted to
replicate it with in Source.
All I managed todo was create a 3D VGUI Screen (assuming this is the best
way) with a whiteboard background. And then looked within the Alien Swarm
SDK
to see how the radar, where you can draw on it, was done. Pretty
unsuccessful. Got nowhere close. I skipped and tried figuring out how I
could change my mouse cursor on the screen to a pen, or eraser and such.
Unable to figure it out.

Would anybody know how to even get something close to this, or just point
in any direction that could possibly lead me into figuring it out?
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
   



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Engine API?

[Jonas 'Sortie' Termansen]

Searching through the code is exactly how I program for Source. Any respectful 
IDE has a function that allows you to search the entire source code (including 
headers). You then enter what you might be looking for, and soon you find some 
sample code related to what you want to do, or at least a header file that 
exposes an engine interface. With some proper guessing and trial anf error, you 
can usually find what you want. Sadly there is no real documentation available, 
but usually when we learn about some feature, we document it on the wiki.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] how to create a mod with non steam HL with no errors , and that language use hl non steam

[Jonas 'Sortie' Termansen]

I find it ammusing that you follow the trend and use a more
complicated vocabulary as well which will probably leave the op quite
confused when he runs this through google translate.

   


#ifdef __INTELLIGENCE__

I just wrap my posts in ifdefs if I don't want some people to read them. 
And when I don't want anybody to read them at all, I encode them in EBCDIC.


#endif

I don't think this guy even has a codebase, at least that's how I 
understand his post, that he is looking for a Non-Steam Half-Life SDK. 
He sounds like he is able to make Steam-based Half-Life mods and has 
found some Non-Steam mods, and that he is now confused how to do it. 
Though, this HL.dll thing sounds weird to me. Do we have the source code 
for that?


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Alien Swarm

[Jonas 'Sortie' Termansen]

On 2010-07-21 17:45, Tom Edwards wrote:

That simply isn't true. If another user of the computer owns HL2 then the GCFs 
will be there, and I expect most of them will be there if the HL2 demo is 
installed too.

Requiring HL2 to be installed makes your whole effort redundant anyway! It's 
already on Source 2009 (though evidently not exactly the same version since it 
won't mount GCFs).

   
HL2 is on the Source 2009 engine, indeed, but HL2 mods are not. Our 
project is simply porting HL2 mods to this engine.


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Alien Swarm

[Jonas 'Sortie' Termansen]

A friend of mine and I have begun work on reimplementing HL2 on the AlienSwarm 
engine. We have set up a SVN, got first person working, and we about to 
reimplement GCF loading through hllib. We have confirmed that GCF support is 
gone. If anyone is interested in helping out on our project cleverly called 
LiveSwarm, feel free to email me. Our results will be released to the 
community. :)
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Playing bik files mid level

[Jonas 'Sortie' Termansen]

You should find the vgui code that the bik system is based upon. It creates a 
panel with a special bik material. Though, bik support in the source engine is 
horribly hacked together, and has lots of limitations. 

Sent from my endlessly awesome Nokia N900, take that damn iPhone owners on this 
list!
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] (no subject)

[Jonas 'Sortie' Termansen]

On 2010-07-12 18:48, adam chance wrote:

When I Build my Mod (Debug), I get this error:

2>.\Debug_episodic/Server.dll : fatal error LNK1120: 1 unresolved externals

What do I do?
   


You have a linker error. It means that you are using a function defined 
in a header file, but it cannot find the declaration anywhere, for 
whatever reason. This is very basic C++, look it up and learn to figure 
out linking errors.


You need to find the missing function(s) (usually written to the next 
line(s) in the output) and make sure it is properly linked against. This 
is often caused by declaring linking incorrectly, or forgetting to 
include an external library. Anyway, this can be caused by all sorts of 
things.


We need the name of missing symbol/external (function or variable 
written to the output), otherwise we cannot help you on this list.


Good luck!
Jonas 'Sortie' Termansen

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source 2007 no longer working!

[Jonas 'Sortie' Termansen]

You guys simply have to edit sourcesdk\bin\version>\bin\GameConfig.txt and add your mod data to it. Then it will be 
fully moddable. Reseting the Source SDK game config does not always 
handle all mods and games correctly.


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Error: SetupArrayProps_R: array prop '(null)' is at index zero.

[Jonas 'Sortie' Termansen]

> Shouldn't hl2 be added to the search paths too?
>
>
That depends on your gameinfo.txt. I don't even think you need to add 
these search paths - I don't really know what they do, considering the 
.gcf's are mounted. This works just fine for me.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Error: SetupArrayProps_R: array prop '(null)' is at index zero.

[Jonas 'Sortie' Termansen]

> Right, if you have a mod based on the 2007 engine you need these lines in 
> your gameinfo.txt now:
>
> SteamAppId 218
> ToolsAppId 211
> AdditionalContentID 420
>
>
> You cannot have SteamAppId 420 in there.
>

It is worth noting that AdditionalContentID is implemented in the Mod 
Code, not in Steam or the Source Engine. I had not updated to the newest 
SDK code available and AdditionalContentID did not work for me. If you 
still have issues after adding AdditionalContentId, then you are not 
running the newest SDK code. To work around this, you can either update 
to the newest SDK Code (2007), or add this to your code:

 // Add the Search Paths required.
 filesystem->AddSearchPath("episodic", "GAME");
 filesystem->AddSearchPath("ep2", "GAME");

 // Mount Additional GCFs.
 if( filesystem->MountSteamContent(-420) != FILESYSTEM_MOUNT_OK )
 {
 return false;
 }

After the filesystem is initialized in gameinterface.cpp and 
cdll_client_init.cpp.

This fixes missing textures/models/scripts/resources/content. It also 
mounts shared Ep1 content.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] HTTP-Request?

[Jonas 'Sortie' Termansen]

Yeah, use an external library. Unless, that is, you want to get 
throat-deep in the mysteries of TCP/IP socket programming, HTTP parsing, 
and various other stuff.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

[Jonas 'Sortie' Termansen]

On 2010-06-17 16:24, Adam Buckland wrote:
> You say that, I'm not sure it's that the lighting 'sucks', but more
> that it's a pain in the arse for modders because they don't have
> server farms to compile lightmaps unlike Valve.
>
What do you mean? I have an Intel Core i7 920 (8 cores @ 2.66Ghz). 
Combined with heavily optimized maps, that's practically a server farm. ;)

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

[Jonas 'Sortie' Termansen]

> Elan Ruskin gave a good talk on porting to consoles at GDC08. The
> slides are on Valve's website. There's something in there that may
> help you here:
>
> #ifdef __GNUC__
> #define MAXSI_THREADED_VARIABLE __thread
> #else
> #define MAXSI_THREADED_VARIABLE __declspec( thread )
> #endif
>
> You may wish to use another define for windows rather than an else
> statement in case you wish to port it somewhere else in the future.
>

Of course. I should have noted that the examples I showed was not the 
actual code. I try to be very religious about my #ifdefs. But if I port 
this to another platform and try to compile, I will just get compiler 
errors that are easy to track back to this #ifdef. Then in this case it 
will be rather easy to fix it. But thanks a lot for pointing this out 
anyways, I tried to make a point about proper #ifdefs in my original 
post, but I cut it because it didn't feel relevant. I will check out the 
slides, though.

Thanks,
Jonas 'Sortie' Termansen.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Engine 2!!!

[Jonas 'Sortie' Termansen]

I'd like to share a few experiences about porting code and writing 
portable code. Scroll down, if you just want my thoughts on how portable 
the Source Engine is.

Recently I've been porting my in-development digital distribution 
platform to GNU/Linux for the fun of it. Naturally, most of my code 
didn't work right out of the box. But it is worth that several 
subsystems actually worked at the first attempt, or with an edit or two. 
For instance, my string system and parser classes/functions compiled 
right away.

However, stuff like accessing the filesystem, multithreading, user 
interfaces, networking, and so on didn't work because it relied on the 
Windows API. The interesting part here is that POSIX does things 
differently; but almost in the same manner as Windows. That means for 
each Windows API call you use, there is often one or more POSIX calls 
that does the same thing (if you add a little abstraction, that is).

Now, some of you heavily suggested the use of #ifdefs all around the 
code. You should not use #ifdefs each time you rely on platform specific 
behavior, but only in shared function calls or in headers. For instance, 
if you have to open a file. On Windows you can call the CreateFile 
function, while POSIX supports the open function. That means for each 
file opening, you need to write something like.

#ifdef linux
int FileHandle = open(Path, Flags);
#elif defined(WIN32)
HANDLE FileName = CreateFile(...)
#endif

Naturally, this isn't very pretty. And if this was used all over the 
Source Engine you would spend a lot of time writing #ifdefs and checking 
platform specific documentation. However, I am not saying #ifdefs are a 
bad idea. But instead of using them all over your code, you should move 
them to a shared class or function that simply implements all this once. 
In my code, I declared an abstract baseclass called MaxsiFileSystem that 
implements all the common functions to access the local filesystem. So 
now when I wish to open a file for reading, I would call:

MaxsiHandle FileHandle = FileSystem()->OpenFile(Path, MAXSI_FILE_READ | 
MAXSI_FILE_SEQUENTIAL);

This additional layer of abstraction makes it very easy to add support 
for new platforms as you just have to define a new child of the abstract 
baseclass. I have also added such a layer for my Window System. This 
means I call my own APIs in my actual code, and then it redirects it to 
the Windows API or GTK+ depending on your platform.

You might also have noticed I implemented a FileSystem() function, in 
the same manner I have implemented a WindowSystem() function that 
returns the window system in use by the current function/class. This 
makes it easy to simply swap the window system on the fly. For instance, 
my source mod links against my distribution platform (LGPL) and my mod 
then implements some of these interfaces. It could implement the 
MaxsiWindowSystem class using VGUI and then my programs could be 
natively drawn ingame with mininal work.

Other porting issues includes how the VS compiler breaks a lot of the 
C99 standard. To counter this, I have simply declared a lot of macros in 
my header files that replaces platform specific behavior. #defines are 
very powerful for this. For example, to declare a thread-specific 
variable, I would use this header define:

#ifdef __GNUC__
#define MAXSI_THREADED_VARIABLE __thread
#else
#define MAXSI_THREADED_VARIABLE __declspec( thread )
#endif

And then use the MAXSI_THREADED_VARIABLE macro to declare each threaded 
variable. My experience is also that the GNU Compilers throw much more 
errors and warnings than the Visual Studio compiler - and it is often 
right to do so. Visual Studio teaches you to write bad 
standards-breaking code, even if you just compile using MinGW you will 
get to fix a lot of issues that makes your code rather non-portable. 
(Like avoiding Microsoft-specific extensions to the C Library, in some 
cases.) But Microsoft did break the standard enough that you might need 
to use some of the above methods for porting, just to get your code 
compiling using MinGW.


Now to return to the Source Engine. In my experience a lot of stuff in 
the SDK code is already defined using interfaces, classes, and such. 
That means the actual porting issues have been outsourced to the Engine. 
This, in turn, means that the SDK code will be rather easy to port 
compared to the Engine. Fortunately, as the Source Engine already is 
highly modular using interfaces, it is easy to just swap a DX renderer 
with OpenGL. As such, they already have the framework to make their code 
work on new platforms - all they have to do is implement their 
interfaces using the local system calls. If you start to do this on the 
low-level interfaces and move upward, then soon your program starts 
working in all its glory.

As for a Steam Client for GNU/Linux. It exists. I lost the link, but it 
seems that Valve uploads nightly builds of their Steam Client, and each 
day it works just a b

Re: [hlcoders] VS2010 "vprojtomake" Utility Update

[Jonas 'Sortie' Termansen]

Your tool seems truly interesting, I didn't know such a tool existed in 
the first place, but it could be useful for a few things of mine. I use 
VS2008 though (and MinGW :D) and I can't open the solution files. Though 
I have experience backporting VS2008 projects to VS2005 using notepad, 
so I guess I'll be able to come up with some VS2008 files soon.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Steam 2010 mod support and Source for the Mac

[Jonas 'Sortie' Termansen]

1nsane wrote:
> Also this, apparently:
> http://www.reddit.com/r/linux/comments/butl8/steam_for_linux_testapp_thingy/
>

Indeed, from the looks of 
 it has 
a version number which currently is

"version" "1272069501"

Which if you interpret it as a timestamp you get the date Sat, 24 Apr 2010 
00:38:21 GMT, which strongly suggests that Valve is doing nightly builds of 
their Linux port.


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Steam 2010 mod support and Source for the Mac

[Jonas 'Sortie' Termansen]

 From what I heard at 
, 
they have found a bash script in the mac beta that adds future support 
for Linux. And they have also released .so files for Linux in Left 4 
Dead once, and so on. There is some evidence but nothing I would 
consider valid proof of a Linux client coming in the near future.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Source Profiling

[Jonas 'Sortie' Termansen]

Iain Breen wrote:
> Hi list,
>
> how can I bring up the profiling tools ala the screenshot here:
> http://source.valvesoftware.com/programming.php
>
> Is that available to SDK users or just engine purchasers?
>

It's done through the console. Enable cheats using sv_cheats 1 and use 
stuff like +showbudget, cl_showfps 2, net_graph 1 (not sure about that 
one), shift+f1 should also enable some debug stuff. There's plenty of 
stuff around, try developer 1 too. +showtexturebudget is also useful. 
Read the wiki for more information.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] VS2010

[Jonas 'Sortie' Termansen]

Well, what I would like to see is a MinGW port of the Source SDK - I 
just ported my own software project to it, so I think I have the 
experience to do it, but the Souce SDK is a very, very big project and 
unless Valve carefully followed the C++ standard it's gonna be 
difficult. Though, since there are Linux server files, at least 
Server.dll must follow the C++ standard to some extend. Somehow I don't 
feel comfortable being forced to use Visual Studio. I do realize, 
though, a MinGW port is not going to happen unless I do it myself and I 
don't have the time for that.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] VSP problem revisit

[Jonas 'Sortie' Termansen]

Do you use a NULL pointer after the static cast or do you print a NULL pointer?
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Steam 'Connect'

[Jonas 'Sortie' Termansen]

I am very interested in this.

In theory the users of my (alpha-state) digital distribution platform would be 
able to validate their accounts, which would make it more secure for my systems 
(previously I just scanned the working dir for the username). But would it be 
more secure for the users? Say I have a website where people have to login with 
their account, how can they be sure I do not receive the password, but only 
Valve does? If Valve makes this system public, wouldn't that mean more people 
would enter their password on fake websites? Or perhaps the user is required yo 
enter the password on a valve site, which is more secure.

If anyone has more information on this, I would like to know. :-)

- Original meddelelse -
> Valve is currently using Steam login shizzle on a new site which
> they're testing in closed beta (external from Steamcommunity.com ) :)
>
> -ScarT
>
> 2010/3/22, David Kraeutmann :
> > It was never fully implemented.
> > https://steamcommunity.com/openid/login returns main page.
> >
> > On Mon, Mar 22, 2010 at 12:44 AM, David Kellaway
> >  wrote:
> > > It's a real shame the OpenID provider doesn't work properly
> > > (DotNetOpenAuth rejects it because it's not fully compliant with the
> > > spec somehow). It'd be much less of a pain than making peoples'
> > > profiles public, editing them, and digging through the horrible XML
> > > feed.
> > >
> > > Is there anyone at Valve who'd know more about this?
> > >
> > > ---
> > > Dave Kellaway
> > >
> > >
> > > On 21 March 2010 23:06, Stephen Swires  wrote:
> > > > I tried logging into Stack Overflow with that as the OID provider, but 
> > > > it
> > > > wouldn't work. It'd be very cool if it did.
> > > >
> > > > On Sun, Mar 21, 2010 at 9:43 PM, Saul Rennison
> > > > wrote:
> > > >
> > > > > Even better, I bet you could just use: 
> > > > > http://steamcommunity.com/openid/
> > > > >
> > > > > Thanks,
> > > > > - Saul.
> > > > >
> > > > >
> > > > > On 21 March 2010 12:32, Garry Newman  wrote:
> > > > >
> > > > > > Thanks, this is what I ended up doing. It's working great right now.
> > > > > >
> > > > > > garry
> > > > > >
> > > > > > On Sun, Mar 21, 2010 at 12:12 PM, Harry Jeffery
> > > > > >  wrote:
> > > > > > > Prehaps try linking an account on your website to a steam account.
> > > > > > >
> > > > > > > For example:
> > > > > > >
> > > > > > > To verify that they own an account with gmod on it ask them to 
> > > > > > > put a
> > > > > > > small code/id in their steam community profile about-me section
> > > > > > > temporarily. Then you can have your website check it's existence 
> > > > > > > by
> > > > > > > parsing the user's profile in xml:
> > > > > > >
> > > > > > > http://steamcommunity.com/id/profilename/?xml=1
> > > > > > >
> > > > > > > If it exists you can then check if their account posesses the 
> > > > > > > game:
> > > > > > >
> > > > > > > http://steamcommunity.com/id/profilename/games/?xml=1
> > > > > > >
> > > > > > > Of course they would have to temporarily set their profile to 
> > > > > > > public
> > > > > > > for this to work. Just make it a one off thing and you should 
> > > > > > > have a
> > > > > > > pretty good way of verifying that the user owns a copy of gmod
> > > > > > > legitimately.
> > > > > > >
> > > > > > > On 21 March 2010 08:45, Garry Newman  
> > > > > > > wrote:
> > > > > > > > Is there any way that another website can verify a steam login?
> > > > > > > >
> > > > > > > > I'm quite keen to make one of my websites check whether a user 
> > > > > > > > owns
> > > > > > > > GMod before letting them download files (because at the moment 
> > > > > > > > in
> > > > > > > > the
> > > > > > > > comments there's a lot of "does this work on non-steam" - and I
> > > > > > > > don't
> > > > > > > > want to pay to let them download stuff).
> > > > > > > >
> > > > > > > > I'm sure I could manually post to the steam login form and see 
> > > > > > > > if
> > > > > > > > it
> > > > > > > > succeeds - but I'm guessing that if it doesn't, it will 
> > > > > > > > eventually
> > > > > > > > ban
> > > > > > > > my web server's IP.
> > > > > > > >
> > > > > > > > Anyone got any ideas, anyone already done something similar?
> > > > > > > >
> > > > > > > > garry
> > > > > > > >
> > > > > > > > ___
> > > > > > > > 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 li

Re: [hlcoders] Passing data

[Jonas 'Sortie' Termansen]

> Better use CBaseHandle (alias EHANDLE)

I didn't ask the original question, but is this thread-safe? I need to make 
some unusual callbacks from an extermal .dll.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Showing live action videos as TV Commercials

[Jonas 'Sortie' Termansen]

Brent Lewis wrote:
> If a mod includes code from ffmpeg then it's a derivative work, and you have 
> to make the whole of the work (the mod) available as source code - as you 
> said. Not only is our mod a closed source mod, but modders dont have the 
> right to redistribute the modified SDK code - which would have to be 
> included. This is why they are incompatible.
That is 100% correct.

My code, however, does not contain LGPL'd code. It merely links to the 
.dll's I provided.

It is perfectly safe and compatible to link to libavcodec of the FFmpeg 
project when using the code I provided.

The FFmpeg-related code has been in .dlls all the time. The code I use 
is from various public domain tutorials for FFmpeg.

Linking is allowed under the GNU LGPL. Please get your facts straight 
before you email this list, if you have any further license questions 
feel free to contact me personally instead of on this list. Recently 50% 
of the discussion has been license-related nonsense and people don't care.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Showing live action videos as TV Commercials

[Jonas 'Sortie' Termansen]

Brent Lewis wrote:
> Just realized that I can't use it. ffmpeg is GPL, and is not 
> compatible with the license for Source SDK. Since we plan on 
> releasing, we can't use it. But thanks again. I wonder if there's 
> a decoder under the MIT license.
I'm sorry, my naming conventions might have confused you and I wasn't 
too sure myself. ffmpeg is partially GNU GPL and GNU LGPL.

FFmpeg is licensed under the GNU LGPL with optional GNU GPL components. 
These components are disabled in the version I sent you. These builds 
can be used under the GNU LGPL 2.1 or later. I did not build them and I 
do not remember where I got them from, and I am not sure if I have the 
source code for them or not - but I should be able to get it if I want 
to, naturally. For more information see 


You are perfectly safe using FFmpeg for your project as long as you 
redistribute the source code on request.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Mails being denied from Naver.com

[Jonas 'Sortie' Termansen]

Uh, lately when I have been responding to this list, I get a bounce 
email from Naver.com in Korean/English saying my mail was rejected for 
no reason. Do anyone else get this? The offending email is 
jsw1...@naver.com  - I suspect his email 
service thinks of hlcoders as spam. Can anyone remove him from the list 
if other people get this?

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Showing live action videos as TV Commercials

[Jonas 'Sortie' Termansen]

I am perfectly happy being listed as a contributor - but remember to also thank 
the people I thank, as they did all the heavy lifting.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Showing live action videos as TV Commercials

[Jonas 'Sortie' Termansen]

Oh, I forgot to include the ffmpeg include headers. You should be able 
to find them on your own, otherwise I'll send you them! Sorry for this 
unnessary email.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Showing live action videos as TV Commercials

[Jonas 'Sortie' Termansen]

Brent Lewis wrote:
> I hadn't even thought of using ffmpeg. Cool idea. Are you willing to share 
> your source code?
>   
Surely!

I put it under a copyleft license so that you can do what you please 
with it if you send me your improvements or document it on the dev wiki :D

http://www.maxsi.dk/upload/data/sortie/sourceffmpeg.zip

That link should work if my website isn't DDoS'ing :D

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Showing live action videos as TV Commercials

[Jonas 'Sortie' Termansen]

It's possible. You can render an AVI ingame or perhaps use the (broken? 
I never got it working) Bink-subsystem. Personally I am experimenting 
with a ffmpeg system and it is working very, very well, but the 
implementation is not finished enough for proper deployment.

Brent Lewis skrev:
> Well, the title pretty much says it all. I'm thinking of having a TV show 
> commercials - the kind that cant be done with func_camera. I know animated 
> VTF is one route but I dunno if it's efficient to create or store in video 
> memory and render - maybe it is???.  So anyway, is this feasible, and what 
> method would work best? I've seen a youtube player in gmod. How's that work?
> 
> ___
> 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] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

Feel free to contact me if you want to help develop the program to be cross 
platform. My current plan is to use GTK+, but the version I am working on atm 
uses native windows functions. .NET is out of the question and so is Java. So 
far I have a basic UI subsystem set up and am able to execute the tools 
successfully and I am able to catch the console output of the tools (though it 
is buggy and I need to rethink that).

Otherwise cross platformness is the least of my concerns regarding this program 
and it's not really worth discussing.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

I tested this carefully when developing said tool, on my i7 920 it scales 
perfectly to all 8 logical cores.

- Original meddelelse -
> Hammer works fine for me to be honest. I'm not sure if vrad is
> multi-threaded but if it isn't, t should be. An opensource
> multi-threaded vrad would really speed up compile times for i7 users
> like myself. I spend a lot more time compiling the map than setting up
> the compile.
>
> On 18 March 2010 21:54, Tobias Kammersgaard
>  wrote:
> > 30 replies of bashing and license discussion. Effectiving working here bros!
> > The tools aren't really the problem, Hammer is to be honest.
> >
> > - ScarT
> >
> >
> > On 18 March 2010 22:50, Jonas 'Sortie' Termansen  wrote:
> >
> > > David Kraeutmann wrote:
> > > > LGPL is useless for standalone apps. BSD-style licenses are good tho'.
> > > >
> > > That is not true. What if I wanted to copy code from my GPL'd program to
> > > my LGPL library and the code is commited by others?
> > >
> > > If I released my Maxsi Compile tool under the GNU LGPLv3, then you are
> > > allowed to copy its code to GNU LGPLv3 libraries. This would not be
> > > permitted if I released it under GNU GPLv3. All my programs are
> > > currently under GNU LGPLv3 (because of licensing issues with
> > > implementing them in Source, just to be safe) and I frequently move code
> > > between the actual .exe files and my shared library Maxsi Engine. I
> > > would not be able to do that with code commited by others if I released
> > > it under GNU GPLv3 - so that's a bit of a problem. If I am wrong about
> > > any of this, feel free to correct me with properly sourced material.
> > >
> > > Whether to use GPL or LGPL is a matter of strategy and I am leaning
> > > towards GPL here.
> > >
> > > ___
> > > 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] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

David Kraeutmann wrote:
> LGPL is useless for standalone apps. BSD-style licenses are good tho'.
>   
That is not true. What if I wanted to copy code from my GPL'd program to 
my LGPL library and the code is commited by others?

If I released my Maxsi Compile tool under the GNU LGPLv3, then you are 
allowed to copy its code to GNU LGPLv3 libraries. This would not be 
permitted if I released it under GNU GPLv3. All my programs are 
currently under GNU LGPLv3 (because of licensing issues with 
implementing them in Source, just to be safe) and I frequently move code 
between the actual .exe files and my shared library Maxsi Engine. I 
would not be able to do that with code commited by others if I released 
it under GNU GPLv3 - so that's a bit of a problem. If I am wrong about 
any of this, feel free to correct me with properly sourced material.

Whether to use GPL or LGPL is a matter of strategy and I am leaning 
towards GPL here.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] [GoldSrc] AviKit in any mods?

[Jonas 'Sortie' Termansen]

I attempted to work with BINK and Source's implementation of it. Sadly 
there is not enough functions exposed and not enough documentation to 
really use it. Unless you have engine access, there is no real reliable 
way of getting it working in my experience. I recommend using ffmpeg if 
you can get it working; I have a very simple half-done implementation of 
it - but it's not as good as it could be.

Tony "omega" Sergi skrev:
> You actually shouldn't need to even use avikit.. since the engine has
> loading of avi's AND bink videos.
> preferably you would want to use bink anyway as you wouldn't need to worry
> about codecs.
>
> loading a bink video actually returns a material anyway, and there is an
> actual 'bik' shader for drawing on objects.
> i've never used the shader myself though, i just know it exists.
> -Tony
>
>
> On Fri, Mar 19, 2010 at 3:19 AM, Jonas 'Sortie' Termansen
>> wrote:
>> 
>
>   
>> I have success implementing the free software ffmpeg library in Source.
>> There is nothing like watching a 720p HD xvid on an ingame surface. :D
>> It's not very well implemented though and I don't have any sound
>> support. I'd gladly share the source code with you. ffmpeg is very fast
>> and it provides all the codecs itself and supports most formats VLC do
>> (because it is used by VLC).
>>
>> Rodrigo 'r2d2rigo' Diaz skrev:
>> 
>>> AVIkit was used in a demo MOD from the creator of the library, but AFAIK
>>>   
>> he
>> 
>>> didn't release the source code. I tried to add it some time ago, but
>>>   
>> finally
>> 
>>> dropped the idea.
>>>
>>> 2010/3/18 kevin bowen 
>>>
>>>
>>>   
>>>> Just wondering if anyone has implemented AVIkit and is willing to part
>>>> 
>> with
>> 
>>>> the code :) or if AVIkit has been used in any open source mods (rebirth
>>>> 
>> and
>> 
>>>> arrangemod have the lib's included but don't actually call the
>>>> 
>> functions).
>> 
>>>> I'd do it myself but it would literally take years (I'm a moron), it'd
>>>> 
>> be
>> 
>>>> easier just to ask for it here just incase any devs have a dead hl1 mod
>>>> with
>>>> the code already laid out :)
>>>>
>>>> I've scoured the internet and all I could find was this on a russian HL
>>>> coding site which seems to use the code but I'm not sure if it's an
>>>> 
>> entire
>> 
>>>> replacement for avikit.cpp or if it fits in there somehow (again I'm a
>>>> moron
>>>> when it comes to this)
>>>>
>>>>
>>>>
>>>>  ///
>>>> // Only setup the avi if it's actually a video screen
>>>>
>>>> if (isVideoScreen && replacement[0] != '\0') {
>>>>char *error_msg = NULL;
>>>>long xres = 0;
>>>>long yres = 0;
>>>>float duration = 0.0f;
>>>>
>>>>movie = new AVIKit( absolute_replacement, false );
>>>>if (movie->getError( &error_msg ) != AVIKIT_NOERROR) {
>>>>gEngfuncs.Con_DPrintf( "SetupAvisFromEntities: Error opening %s:
>>>> %s\n", absolute_replacement, error_msg );
>>>>delete movie;
>>>>break;
>>>>}
>>>>movie->getVideoInfo( &xres, &yres, &duration );
>>>>gEngfuncs.Con_DPrintf( "SetupAvisFromEntities: Opened %s: %ld x %ld
>>>> 
>> (%f
>> 
>>>> secs)\n", replacement, xres, yres, duration );
>>>>gEngfuncs.Con_DPrintf( "Video screen at (%d %d %d), with extents (%d
>>>> 
>> %d
>> 
>>>> %d)\n",
>>>>(int)origin[0], (int)origin[1], (int)origin[2],
>>>>(int)extents[0], (int)extents[1], (int)extents[2] );
>>>>
>>>>// Create the OpenGL texture
>>>>GLuint texnum;
>>>>glGenTextures( 1, &texnum );
>>>>
>>>>if (!AddComplexAvi( movie, texnum, origin, angles, extents,
>>>> 
>> &error_msg
>> 
>>>> )) {
>>>>gEngfuncs.Con_DP

Re: [hlcoders] [GoldSrc] AviKit in any mods?

[Jonas 'Sortie' Termansen]

I have success implementing the free software ffmpeg library in Source. 
There is nothing like watching a 720p HD xvid on an ingame surface. :D 
It's not very well implemented though and I don't have any sound 
support. I'd gladly share the source code with you. ffmpeg is very fast 
and it provides all the codecs itself and supports most formats VLC do 
(because it is used by VLC).

Rodrigo 'r2d2rigo' Diaz skrev:
> AVIkit was used in a demo MOD from the creator of the library, but AFAIK he
> didn't release the source code. I tried to add it some time ago, but finally
> dropped the idea.
>
> 2010/3/18 kevin bowen 
>
>   
>> Just wondering if anyone has implemented AVIkit and is willing to part with
>> the code :) or if AVIkit has been used in any open source mods (rebirth and
>> arrangemod have the lib's included but don't actually call the functions).
>> I'd do it myself but it would literally take years (I'm a moron), it'd be
>> easier just to ask for it here just incase any devs have a dead hl1 mod
>> with
>> the code already laid out :)
>>
>> I've scoured the internet and all I could find was this on a russian HL
>> coding site which seems to use the code but I'm not sure if it's an entire
>> replacement for avikit.cpp or if it fits in there somehow (again I'm a
>> moron
>> when it comes to this)
>>
>>
>>
>>  ///
>> // Only setup the avi if it's actually a video screen
>>
>> if (isVideoScreen && replacement[0] != '\0') {
>>char *error_msg = NULL;
>>long xres = 0;
>>long yres = 0;
>>float duration = 0.0f;
>>
>>movie = new AVIKit( absolute_replacement, false );
>>if (movie->getError( &error_msg ) != AVIKIT_NOERROR) {
>>gEngfuncs.Con_DPrintf( "SetupAvisFromEntities: Error opening %s:
>> %s\n", absolute_replacement, error_msg );
>>delete movie;
>>break;
>>}
>>movie->getVideoInfo( &xres, &yres, &duration );
>>gEngfuncs.Con_DPrintf( "SetupAvisFromEntities: Opened %s: %ld x %ld (%f
>> secs)\n", replacement, xres, yres, duration );
>>gEngfuncs.Con_DPrintf( "Video screen at (%d %d %d), with extents (%d %d
>> %d)\n",
>>(int)origin[0], (int)origin[1], (int)origin[2],
>>(int)extents[0], (int)extents[1], (int)extents[2] );
>>
>>// Create the OpenGL texture
>>GLuint texnum;
>>glGenTextures( 1, &texnum );
>>
>>if (!AddComplexAvi( movie, texnum, origin, angles, extents, &error_msg
>> )) {
>>gEngfuncs.Con_DPrintf( "SetupAvisFromEntities: Error adding movie:
>> %s\n", error_msg );
>>delete movie;
>>}
>>} else if (isVideoScreen) {
>>gEngfuncs.Con_DPrintf( "SetupAvisFromEntities: Video screen didn't
>> have a movie specified!\n" );
>>}
>>
>>//Setting up the texture:
>>
>>movie->getVideoInfo( &data->width, &data->height, &data->total_length );
>>glEnable( GL_TEXTURE_2D );
>>glBindTexture( GL_TEXTURE_2D, data->texture_index );
>>glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
>>glTexImage2D( GL_TEXTURE_2D, 0, 3, data->width, data->height, 0, GL_RGB,
>> GL_UNSIGNED_BYTE, tmpbuffer );
>>
>>//Updating the texture each frame:
>>
>>// Calculate the frame needed
>>int frame = i->movie->getVideoFrameNumber( i->current_time );
>>
>>// If the frame has changed, re-upload it
>>if (frame != i->current_frame) {
>>i->current_frame = frame;
>>i->movie->getVideoFrame( (char*)i->buffer, frame );
>>
>>// If the video isn't a power of two on all sides, we need to resize
>> it... 
>>if (i->resized_buffer) {
>>gluScaleImage( GL_RGB, i->realwidth, i->realheight,
>> GL_UNSIGNED_BYTE, i->buffer, i->width, i->height, GL_UNSIGNED_BYTE,
>> i->resized_buffer );
>>// ... and update the OpenGL texture ...
>>glEnable(GL_TEXTURE_2D);
>>glBindTexture( GL_TEXTURE_2D, i->texture_index );
>>glTexSubImage2D( GL_TEXTURE_2D, 0, 0, 0, i->width, i->height,
>> GL_RGB, GL_UNSIGNED_BYTE, i->resized_buffer );
>>} else {
>>// ... and update the OpenGL texture ...
>>glEnable(GL_TEXTURE_2D);
>>glBindTexture( GL_TEXTURE_2D, i->texture_index );
>>glTexSubImage2D( GL_TEXTURE_2D, 0, 0, 0, i->width,
>> i->height, GL_RGB, GL_UNSIGNED_BYTE, i->buffer );
>>}
>>}
>>
>>// If this is a complex movie, draw the polygons
>>if (i->texture_type == AVI_TEXTURE_USER) {
>>
>>glEnable( GL_TEXTURE_2D );
>>glBindTexture( GL_TEXTURE_2D, i->texture_index );
>>glDisable( GL_BLEND );
>>glBegin( GL_QUADS );
>>
>>// Top left
>>glColor3f( 1.0f, 1.0f, 1.0f );
>>glTexCoord2f( 0.0f, 1.0f );
>>glVertex3f( i->vertexes[0].x, i->vertexes[0].y, i->vertexes[0].z
>> );
>>
>>// Bottom left
>>glColor3f( 1.0f, 1.0f, 1.0f );
>>glTexCoord2f( 0

Re: [hlcoders] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

Thanks Cory for your suggestions, they are quite useful!

I have been thinking the UI through and done some concept art in paint. I 
realized you never use/need to change most settings in VBCT. Instead I have 
been focusing on those that you really do need and designed them to be useful. 
None of this is implemented yet but I managed to get the batch compiling 
working perfectly yesterday. What I propose is this:

- To make things simpler I will make the main screen only contain this: 1) a 
dropdown list of all mods in gameconfig.txt for both ep1 and orangebox, 2) a 
dropdown list of all .vmf files in mapsrc for the mod, 3) a dropdown list of 
all configuration, 4) a big Compile Map button and Cancel Compile, 5) a 
progress bar and the option to watch the compile output, and 6) various buttons 
to show the user friendly advanced buttons. 
- Most of the time you just want to compile a single map for instant testing 
ingame. So instead of having to browse for a map manually, I will make the 
program scan all mapsrc\ folders and make it default to the most recently saved 
.vmf file, as this is most likely the one you want to compile.
- I will also show all recent .vmf files newer than their .bsp counterpart 
under the title "You probably want to compile these:"
- The user is also likely to the same compile flags for most compiles. So I 
will use configurations such as Debug (HDR only), Release (LDR+HDR), Final 
Release (Both -final) and so on. The user will be able to edit this list.
- The program will assume all the default values for which mod to use, what map 
to compile, and with what configuration. This will allow the mapper a one click 
compile in most cases, as well as allowing him to easily change it.
- The user will be able to add maps to the compile queue while compiling other 
maps and be able to watch the progress for them seperately.
- It will be possible to change what tools will be called and add new ones.
- And there will be a progress bar showing how the compile comes along in the 
Win7 superbar.

And more, there are just some of my ideas for the ideal interface, and it isn't 
hard to make.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] I intend to make free software alternative to VBCT

[Jonas 'Sortie' Termansen]

> GPL is far too restrictive. Use LGPL or BSD3.

The LGPL is just the GPL with the right to link to the object file. Do you 
intend to link to my program? Otherwise it wouldn't matter as the Maxsi Engine 
library I use and develop is under the GNU LGPLv3. I am open to release it 
under the GNU LGPLv3 if you can find a good reason to (if you want to use it 
for your own tools, you should make your own software free sofware! This is for 
the greater good of the community) BSD is out of the question as a strong 
copyleft is required for my software; I do not want propertiary spin-offs.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

Thanks, Tom!

I had completely forgotten about that good, I think I genereated batch 
files with it once. But the OB-era games broke them (unless you knew how 
to set the working dir and what it should be for the compile tools).

Unfortunately the last release was from 2004 according to the website - 
I am not sure how up to date it is with the newest OB-era compile 
options (nor even the Ep1-era such as HDR/LDR vrad). But judging from 
the modular design of it, I might just need to edit some files. The main 
sad thing, though, is that this is properitary software. I would like to 
have a free software alternative that reflects the openess we should 
have as a modding community. We tend to get too worked up on 
copyrighting our works that we forget to think about the good of the 
community as a whole.

The main reason I am interested in this, though, is because I want to 
practice designing a better UI for the compile tools to make them more 
user-friendly - and to replace properitary software, of course. I have 
experience so I don't see this as a hard task.

Tom Edwards wrote:
> Are you aware of Nem's Batch Compiler? You need to manually set BinRoot 
> to get the OB tools working, but otherwise it's very good. Way better 
> than VBCT in my opinion.
>
> http://nemesis.thewavelength.net/index.php?c=1
>
> On 17/03/2010 3:29, Jonas 'Sortie' Termansen wrote:
>   
>> Hi, my name is Jonas 'Sortie' Termansen and I intend to make a free
>> software alternative to VBCT released under the GNU General Public License.
>>
>> VBCT ('Valve' Batch Compile Tool) was developed by qUiCkSiLvEr and it is
>> one of the most useful tools I have used for modding. It's a batch
>> compile tool that allows me to compile maps outside of Hammer, which is
>> much faster.
>>
>> Unfortunately the VBCT development has come to a halt and the developer
>> has been recently employeed full time. There has been no new release of
>> VBCT since early 2009. And the developer didn't want to make his source
>> code available when I asked him.
>>
>>
>> My vision is to create an user-friendly general purpose batch compile
>> tool for Source Mods. It should be written in pure C++ and licensed
>> under a free software license such as the GNU GPL. It should be
>> developed in union with the modding community.
>>
>> I will start hacking the basics together as soon as I have sent this
>> email and commit the sources to the Maxsi Distribution SVN later on.
>> <http://www.maxsi.dk/upload/data/sortie/MaxsiCompile-1.0.zip>
>>
>>
>> Feel free to contact me via the following services if you are interested
>> in the project and would like to be part of its development. I would
>> also like to hear on this list what features you would like from the
>> ideal batch compile tool for Valve's Map.
>>
>> SteamId: Sortie
>> MSN: Sortie at Maxsi dot dk
>>
>> Also, Valve broke batch compiling when they released the OB engine,
>> though a workaround is known. I have created a simple GPL-licensed batch
>> system that programmers should have no trouble using if they set it up
>> properly. It's not my actual batch compile tool, but only a proof it's
>> possible.
>>
>> http://www.maxsi.dk/upload/data/sortie/MaxsiCompile-1.0.zip
>>
>> About me:
>> I am a highly skilled programmer with years of experience writing native
>> C++ programs. I am currently working on a free software digital
>> distribution platform platform for mods called Maxsi Distribution. I am
>> involved with the development of City17: Episode One part time. I
>> currently study high level Physics, Math, and Chemistry at my high
>> school and intend to study Computer Science later on.
>>
>> ___
>> 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] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

I would like to get in touch with people interested in developing this 
tool with me, but also your feedback on how you would like the tool to 
be? What features?

I am thinking firefox tabbed browsing, progress bars on the build steps, 
error reporting. Being able to switch between maps log output using 
tabs, being able to set custom compile flags.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

Gladly! VBCT is a really great program but it has a few bugs regarding 
seperate LDR and HDR builds and custom map preprocession (I am working 
on a great tool for that, it filters visgroups so you can use the same 
.vmf for multiple maps.) But most of all, I think the user interface is 
way too complicated and puzzling, even for me. VBCT makes things harder 
than they have to. But the largest issue is that the current version of 
the program is unmaintained and no one is able to improve it.

So I propose a better designed UI that is simple and logical yet 
flexible, better support for customizing the tool's build steps, and 
general better robustness and reliabillity.

Alexander Hirsch wrote:
> Completely derailing this thread ^^
>
> I don't know what a batch processing tool would need more than
> compiling all maps in a folder (maybe selected with regular
> expression) with specific flags and reporting any errors while doing
> this, possibly stopping the process upon one error.
>
> While I in general support the idea of such a tool, I don't understand
> what else it should feature to require a good amount of work.
> Could you explain what the old tools were missing or what features I
> was missing in my close-minded thinking? I don't really map often...
> just a few dev-maps.
>
> On Wed, Mar 17, 2010 at 5:59 PM, ZuM  wrote:
>   
>> +2.
>>
>> I mean, come on he is wanting to help in creating a tool that has the
>> potential to be useful and you come trolling like that? I mean, you must
>> have something to do other than that, and also, the suggestions you made to
>> him maybe should also apply to you Nick.
>>
>>
>> 2010/3/17 Olly 
>>
>> 
>>> +1 removal
>>>
>>> On 17 March 2010 16:48, Keeper  wrote:
>>>
>>>   
 Can we please get this guy off of the coders list?

 The point of the coders section is to discuss things related to using the
 SDK.  That's what Jonas did.  Just because you don't like the tools and
 
>>> the
>>>   
 method at which VALVe has done things, shouldn't give you the right to
 troll
 their mailing list and bash them every chance you get.

 I think the fact that somebody wants to pick up an orphaned utility and
 help
 the community out is a good thing.

 Oh, and programming during high school doesn't equate to being a
 loner/loser
 as you seem to suggest...

 -Original Message-
 From: Nick [mailto:xnicho...@gmail.com]
 Sent: Wednesday, March 17, 2010 12:20 PM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] I intend to make a free software alternative to
 VBCT

 Why? Valve doesn't much like open source, or linux. Valve doesn't want
 to release hammer as open source. Why not work on OpenSource projects
 that for an OpenSource friendly engine? You are in highschool right,
 why not spend time with your friends or if you have no friends join a
 club or sports team?

 Just a suggestion..


 ___
 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] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

Please do not respond to these things. That's what he wants you to.

Rodrigo 'r2d2rigo' Diaz wrote:
> And there comes the usual anti-Valve bashing in their own mailing list...
>
> 2010/3/17 Nick 
>> Why? Valve doesn't much like open source, or linux. Valve doesn't want
>> to release hammer as open source. Why not work on OpenSource projects
>> that for an OpenSource friendly engine? You are in highschool right,
>> why not spend time with your friends or if you have no friends join a
>> club or sports team?
>>
>> Just a suggestion..
>> 

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] I intend to make a free software alternative to VBCT

[Jonas 'Sortie' Termansen]

Hi, my name is Jonas 'Sortie' Termansen and I intend to make a free 
software alternative to VBCT released under the GNU General Public License.

VBCT ('Valve' Batch Compile Tool) was developed by qUiCkSiLvEr and it is 
one of the most useful tools I have used for modding. It's a batch 
compile tool that allows me to compile maps outside of Hammer, which is 
much faster.

Unfortunately the VBCT development has come to a halt and the developer 
has been recently employeed full time. There has been no new release of 
VBCT since early 2009. And the developer didn't want to make his source 
code available when I asked him.


My vision is to create an user-friendly general purpose batch compile 
tool for Source Mods. It should be written in pure C++ and licensed 
under a free software license such as the GNU GPL. It should be 
developed in union with the modding community.

I will start hacking the basics together as soon as I have sent this 
email and commit the sources to the Maxsi Distribution SVN later on. 
<http://www.maxsi.dk/upload/data/sortie/MaxsiCompile-1.0.zip>


Feel free to contact me via the following services if you are interested 
in the project and would like to be part of its development. I would 
also like to hear on this list what features you would like from the 
ideal batch compile tool for Valve's Map.

SteamId: Sortie
MSN: Sortie at Maxsi dot dk

Also, Valve broke batch compiling when they released the OB engine, 
though a workaround is known. I have created a simple GPL-licensed batch 
system that programmers should have no trouble using if they set it up 
properly. It's not my actual batch compile tool, but only a proof it's 
possible.

http://www.maxsi.dk/upload/data/sortie/MaxsiCompile-1.0.zip

About me:
I am a highly skilled programmer with years of experience writing native 
C++ programs. I am currently working on a free software digital 
distribution platform platform for mods called Maxsi Distribution. I am 
involved with the development of City17: Episode One part time. I 
currently study high level Physics, Math, and Chemistry at my high 
school and intend to study Computer Science later on.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Steam 2010 mod support and Source for the Mac

[Jonas 'Sortie' Termansen]

Jeffrey "botman" Broome wrote:
> I'm not so sure that a Mac port makes sense financially.  According to NPD 
> (October 2009)...
>   
The indie game Overgrowth (sequel to Lugaru) supports Windows, Mac, and 
Linux. While most of thier points to do so don't apply to a large game 
studio like Valve, some do, and I am fairly sure Valve has a few reasons 
of their own. I highly suggest indie programmers read this:

http://blog.wolfire.com/2008/12/why-you-should-support-mac-os-x-and-linux/

Plus, a proper port is a one-time-task, and then if you design all new 
features with cross-platformness in mind, your games would be a cross 
platform for a long time. Of course, crossplatformness is expensive, but 
lets be honest, Valve couldn't be richer and they are known for their 
very very successful high-risk projects.

I think Valve wants Steam to be >the< platform for game distribution in 
the future, so they have to go crossplatform to make sure this happens.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Steam 2010 mod support and Source for the Mac

[Jonas 'Sortie' Termansen]

I am not sure what you mean. Code has to be recompiled for all platforms 
(unless they are enough alike). From my understanding Mac OS X can't use 
Windows binaries, so they have to be compiled (does OS X use .so dynamic 
link libraries like other unix-alike systems?).  And hacking? Huh?

Matt Lima Faiotto wrote:
> I do agree that Mac Support does make sense, as it really doesn't require 
> you to recompile almost every component, keeping most of their application 
> safe from hacking.
>   

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Steam 2010 mod support and Source for the Mac

[Jonas 'Sortie' Termansen]

Well, Mac support makes a lot of sense really. According to wikipedia 
Windows covers 88% of all desktop computers, and Mac OS X 6%. GNU/Linux 
only is only 1%. If you look at this pie chart 
http://en.wikipedia.org/wiki/File:Operating_system_usage_share.svg you 
can clearly see that if Valve supports Windows and Mac, they support 
almost every desktop computer able to run their games. I am really glad 
Valve are expanding the market for digital distribution to other 
platforms as well - personally I see Steam-like systems as the future of 
gaming. So whether how much I would like a linux port, I can perfectly 
see why they should focus on a Mac OS X port first.

As for the whole no gaming on GNU/Linux thingey - the main reason 
developers don't make games for the platform is because gamers don't use 
it, and the main reason gamers doesn't use the platform is because the 
huge games don't get ports for the platform. If Valve shipped their 
Source games for GNU/Linux-based operating systems I am sure it would 
cause more gamers to use the platform, including myself.

Again, I am really glad Valve is doing a Mac OS X port of Steam and 
Source and I appreiciate their efforts put into this.

Harry Jeffery wrote:
> I'd love valve to support linux tbh. Most linux users are tech savvy
> and as many of them are or have been programmers they all respect
> software licenses. On windows most people are sick of paying for games
> and pirate games loads. Either way, thanks for the info about the Mac
> port, even though I do not think very much of Apple.
>
> On 10 March 2010 19:55, Adam Buckland  wrote:
>   
>> Is OpenGL being brought to the PC as an option/as standard? Or is it
>> just on the Mac
>>
>> The only reason I ask is due to shaders, which are currently written
>> in HLSL for DirectX
>>
>> On 10 March 2010 19:50, Alfred Reynolds  wrote:
>> 
>>> The Orange Box era engine will be supported for mods on OSX.
>>>
>>>   
 -Original Message-
 From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-
 boun...@list.valvesoftware.com] On Behalf Of Jorge Rodriguez
 Sent: Wednesday, March 10, 2010 11:38 AM
 To: Discussion of Half-Life Programming
 Subject: Re: [hlcoders] Steam 2010 mod support and Source for the Mac

 It's not a question of how easy it is to port to Linux, it's a question
 of
 what kind of market there is for video games on Linux, and the answer
 to
 that is "not big."

 Alfred, what engine would that be available on? Will the OSX support be
 backported to Orange Box or would it require an update to whatever
 engine
 Portal 2 is being developed on (which I presume is based on the L4D2
 engine?)

 --
 Jorge "Vino" Rodriguez
 ___
 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
>>>
>>>
>>>   
>>
>> --
>>
>> Bucky
>>
>> ___
>> 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] Steam 2010 mod support and Source for the Mac

[Jonas 'Sortie' Termansen]

Jorge Rodriguez wrote:
> Just because they port to Mac doesn't make it easy to port to Linux. Mac is a 
> huge untapped market for games, but Linux not so much. I wouldn't count on a 
> Linux port any time soon.
Personally, the only thing keeping me from switching to Ubuntu full time 
is the lack of Steam/Source support (Wine didn't work for me), so I can 
continue modding on the platform. Ubuntu offers all the software I 
already use, or similar software, except Steam/Source. I agree that 
porting to Linux is not an easy task - but neither is porting to Mac. 
And GNU/Linux is also a very untapped market for games.

Still, this isn't a discussion of whether there should be a Linux port 
or not, I am simply asking if it is planned, and to voice my opinion 
that I want it.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Steam 2010 mod support and Source for the Mac

[Jonas 'Sortie' Termansen]

Tom Edwards wrote:
> Two questions for Valve:
>
> * Will there be a Mac SDK release?
> * Will we be able to fill in Steam's new "detail view" for our mods?
>   Getting Steam to display our news feeds would be particularly useful.
>   
Futher questions:

* Since Mac OS X is unix-alike and OpenGL is cross-platform, is a 
build for GNU/Linux operating systems such as Ubuntu considered?
* Will mods be supported natively on the Mac OS X platform with 
custom dynamic link libraries? (Of course rebuilt to run on Mac OS X)


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Accessing Accumulation buffer in GoldSrc

[Jonas 'Sortie' Termansen]

VAC isn't anti DLL -- It only gets triggered if you replace existing 
DLLs. It is perfectly safe to use DLLs that isn't provided by Valve.

Replacing opengl.dll will get you VAC-banned, though.

I don't get why you are interested in modern effects, while you work 
with an engine that is 12 years old.

kevin bowen skrev:
> Oh wow, so I figured out that Paranoia uses gl accum, but with the
> opengl.dll, WHICH SETS VAC OFF. is there any way to add motion blur without
> dlls? besides the fake way with the models and transparency. Can I also just
> get a confirmation that you can't add anything that looks good, like the
> mechmod water shader, bloom, tronglow, and motion blur without getting
> banned by vac?
>
> On Sat, Feb 27, 2010 at 10:18 AM, kevin bowen 
> wrote:
>
>   
>> I'm pretty new to this, but someone posted on this mailing list in 2003
>> that they used the accumulation buffer to create motion blur. I found
>> http://forums.inside3d.com/viewtopic.php?t=1533 which uses it for quake,
>> but I'm not really sure how to go about adding it to HL. I would prefer to
>> do it this way than adding unneccessary dll's that just set off vac. If
>> anyone could explain/help me out with this that'd be awesome, 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] How can I disable rendering?

[Jonas 'Sortie' Termansen]

How about using the Shift+F1 debug shortcut (at least, that's what I 
think it is, try a few combiantions if it doesn't work) to disable 
rendering of most stuff? The logic code still runs, but the stuff isn't 
rendered. This menu allows you to control exactly what groups of 
entities are rendered, allows you to enable/disable debug stuff, and 
even disable/enable the AI. I use it quite often to pinpoint what groups 
of entities are eating the precious CPU/GPU cycles.

Saul Rennison skrev:
> Each entity has a think function, so I presume the think function for each
> AI is NPCThink :P
>
> Thanks,
> - Saul.
>
>
> On 15 February 2010 14:09, Colm Sloan  wrote:
>
>   
>> I'm trying to run lots of AI tests comparing the performance of different
>> algorithms. I want to disable rendering so I can have a lot more entities
>> in
>> play. How can I do this?
>>
>> Also, I was wondering where the main loop is for AI. I'm aware of the
>> functions CAI_BaseNPC::NPCThink and CAI_BaseNPC::RunAI which I have used a
>> lot but I'm looking for the 'for' or 'while' that surround these and is
>> responsible for updating every NPC at the the highest level.
>>
>> Thanks for any help :)
>> ___
>> 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] Initialization Sequence

[Jonas 'Sortie' Termansen]

The first function called in client.dll that you should override is

CHLClient::Init() in cdll_client_int.cpp

(The actual first function called is CreateInterface but I wouldn't go 
no-where near that function, it's better to do stuff in CHLClient::Init())

Sadly, it is not possible to do anything before IDirect3DDevice9 is 
initialized (Doesn't that happen when the Window opens? It is at least 
impossible to do anything before the Window opens).

The CHLClient::Init() is the first function called, but it is not called 
until a few moments after client.dll is loaded into memory. If you need 
something to be called early on (note the environment is not entirely 
safe at this point), you can create a class with a constructor and 
globally instance one copy of this class; the constructor will then be 
called when client.dll is loaded into memory.

The good thing abourt using CHLClient::Init() is that you can return 
false, if you don't want the game to launch (note this makes hl2.exe 
quite unstable, it might also be wise to call a function that terminates 
the process, like PostQuitMessage(0) or something).

I hook into CHLClient::Init() with my Maxsi Distribution system to 
initialize it at run-time.

Like Tom said, _DllMainCRTStartup() is also called, but I wouldn't touch 
that either - The Windows environment is also very unstable at this time.

What is it that you are trying to do?

Brent Lewis skrev:
> I'd like to know what places in the client.dll are called as part of the 
> initialization phase. I'd rather not have to set breakpoints at every 
> function header in every file to see what's going on when the game starts. 
> Any info available on this?
>
> I'd like to know this partly for curiosities sake, but I'd also like to do 
> some work before the  IDirect3DDevice9 gets created.
> 
> ___
> 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] How to find SteamID

[Jonas 'Sortie' Termansen]

Just wondering, what are you trying to do that requires the Steam Id 
outside a steam game?

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Happy 40 years since the Unix Epoch!

[Jonas 'Sortie' Termansen]

That's right! It has been 40 years!

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Engine Crash After CBoundedCvar_Interp::GetFloat()

[Jonas 'Sortie' Termansen]

Any access to a memory location just above 0x is usually caused 
by accessing a class member where the memory location of the class is 
0x, meaning that a null-pointer to a class was used somewhere.

Minidumps, such as the one you attached, cannot be used without a .pdb 
symbol debug file and  the sourcecode for your mod. In this case, you 
only supplied .mdmp files, which are largely useless without the .pdb 
file and source code.

Minidumps and stack traces are also sometimes not working as intended, 
without all the memory required included, and sometimes the source coded 
needed is not under your control. In that case, you might need to try 
other debugging methods.

If you use a reposity versioning software, you can try revert to older 
versions of your mod and see what you changed that could possibly cause 
the crash.

You could install the source code and debugging on another computer 
suffering from the issue and try it. If it happens for some people, but 
not all, and it doesn't seem fairly 'random' it could be caused by 
missing content or other things. Try make sure they have disabled all 
firewalls/antivirus programs and other stuff, they sometimes mess things 
up, though it's hardly the case here.

Since the issue seems to have something to do with floats, perhaps it is 
caused by a class with a poorly implemented networking table or something.

In short, it could be almost anything, you either need to provide more 
useful information or try harder. Because this error is specific to your 
mod, people on this list probably cannot help because your bug is too 
specific and special so that we most likely have no experience with it. 
Of course we might be able to, but it would be better if you could fix 
it yourself and perhaps explain the crash here so people can find it 
here later.

Skillet skrev:
> A few players have been reporting crashes upon attempting to connect to a
> server or create their own.  Oddly, at least one reports having been able to
> connect and play with no problems then suddenly getting this crash
> constantly.  From the dumps they all seem to be happening in the same place
> but I'm stumped as to why.  The errors are always "Access violation reading
> location 0x00ed" and the call stacks all look generally like so:
>
>   
>>engine.dll!0d7bd953()
>> 
>  [Frames below may be incorrect and/or missing, no symbols loaded for
> engine.dll]
>  client.dll!CBoundedCvar_Interp::GetFloat()  Line 113 + 0x19 bytes
> C++
>
>
> http://www.distraction-mod.com/skillet/crashdumps/plr1_hl2_3943_crash_2009_12_26T20_13_43C0.mdmp
> http://www.distraction-mod.com/skillet/crashdumps/plr1_hl2_3943_crash_2009_12_26T21_5_41C0.mdmp
> http://www.distraction-mod.com/skillet/crashdumps/plr1_hl2_3943_crash_2009_12_26T21_18_10C0.mdmp
> http://www.distraction-mod.com/skillet/crashdumps/plr2_hl2_3943_crash_2009_12_28T15_34_37C0.mdmp
> http://www.distraction-mod.com/skillet/crashdumps/plr2_hl2_3943_crash_2009_12_28T15_35_36C0.mdmp
>
> This is an OB based mod.  I tried messing with my cl_interp and related
> convars to see if I could reproduce the crash but with no success.  Perhaps
> someone with engine access can help?
>
> 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] Bug with Outlined Text in VGUI?

[Jonas 'Sortie' Termansen]

To me it looks like a bug in the antialiasing code/functions.
> I took a picture to explain the issue better what I mean, it is not ideal
> being a jpeg, but I zoomed in on a tga of the text and noted that you have
> outline then a blurred edge of the text which is causing the background to
> bleed in a little. It happens more extremely when we are displaying red text
> with our game timer it seems to be a slightly larger gap then. Oddly it
> isn't noticeable unless you have a color behind it that is similar to the
> text or if you have really bright color values behind it, like on our timer
> when players look at the bright areas of the skybox.
>
> http://img51.imageshack.us/img51/8326/weirdtext.jpg
>
> Chris
>   

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] SVN GPL Question

[Jonas 'Sortie' Termansen]

I'm a bit surprised that no one even bothered to check the Free Software 
Foundation's very brilliant and well-documented FAQ for this.

:

"Can I apply the GPL when writing a plug-in for a non-free program?

If the program uses fork and exec to invoke plug-ins, then the 
plug-ins are separate programs, so the license for the main program 
makes no requirements for them. So you can use the GPL for a plug-in, 
and there are no special requirements.

If the program dynamically links plug-ins, and they make function 
calls to each other and share data structures, we believe they form a 
single program, which must be treated as an extension of both the main 
program and the plug-ins. This means that combination of the GPL-covered 
plug-in with the non-free main program would violate the GPL. However, 
you can resolve that legal problem by adding an exception to your 
plug-in's license, giving permission to link it with the non-free main 
program."

That said, you MAY use the GPL for your plugin, IF you add an exception 
to its license granting the Source Engine permission to link to your 
plugin (see the faq above on how to do this, I only included the short 
answer).

As for the Source Code of the Source SDK that you use. You are not 
required to redistribute the libraries or the .cpp files. I don't know 
about the .h files, though. However, if you design your project so that 
it can be distributed without the Source SDK (but requires it to 
compile), then it is perfectly fine.

You are allowed to use non-GPL libraries from GPL programs/libraries. 
And if you grant an exception to the Source Engine, then everything 
would be perfectly fine.

Of course, switching to the LGPL would make things much more easier and 
allow all programs to link to your plugin library, so I would consider 
the LGPL instead of the GPL. However, if you really want to use the GPL, 
the instructions above should apply.

I had a little trouble understanding what you meant with the first 
question, but I hope I got it right.

Thanks, and happy coding!

- Sortie

hl2li...@afksoftware.com skrev:
> I am working on a plugin development team.  Since our plugin is open  
> source, I was wondering if it is a nono to include in our trunk the  
> EP1-SDK and the OB-SDK files?
>
> iirc, you can't gain access to the sdk unless you purchase games.
>
> Is this assumption correct?
>
> Thanks,
> Keeper


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Inherited gamerules not transfering CNetworkVars

[Jonas 'Sortie' Termansen]

How can that possibly work, or compile? The pEnt is defined in _DEBUG 
but you assert it in the non-_DEBUG build. Doesn't that throw a warning?
> void CNewGameRules::CreateStandardEntities( void )
> {
> #ifndef CLIENT_DLL
> CGameRules::CreateStandardEntities();
>
> g_pLastCombineSpawn = NULL;
> g_pLastRebelSpawn = NULL;
>
> #ifdef _DEBUG
> CBaseEntity *pEnt =
> #endif
> CBaseEntity::Create( "new_gamerules", vec3_origin, vec3_angle );
> Assert( pEnt );
> #endif
> }
>   


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] SDK Skeleton release

[Jonas 'Sortie' Termansen]

Nice! I used notepad to change a few settings in the .sln and .vcproj 
files and make -2005 versions that can be opened with VS2005. I didn't 
test if they compile correctly - but unless Tom did any nasty setting 
fixes in his -2008 versions, it should work fine. My version contains 
both the 2005 and 2008 solution files.

http://www.maxsi.dk/upload/data/sortie/sdk_skeleton_b1_2005.zip

Tom Edwards wrote:
> I've made a minimum implementation of the SDK. Its purpose is to split what's 
> required to compile and run away from the non-essential code that Valve has 
> added to even the scratch SDK. It's a great place to start if you're working 
> on a TC.
>
> http://steamreview.org/external/vdc/sdk_skeleton_b1.zip
>
> This is a test release that I'd be grateful for your feedback on. I'm 
> particularly interested to hear from anyone using VS2008, since I only have 
> VCE. If anyone would be kind enough to backport the projects to VS2005 I 
> would be very grateful for that too. :-)


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Compile problems for teamplayer_roundbased

[Jonas 'Sortie' Termansen]

Try using

void SetTimerInHUD( CBaseEntity *pTimer )
{
  if ( pTimer )
  {
m_iTimerToShowInHUD = pTimer->entindex();
  }
  else
  {
m_iTimerToShowInHUD = NULL;
  }
}

instead. Somehow it looks like you are accessing a null pointer like a 
class, and then accessing a member of that null-pointer-class, thus try 
are trying to access location 0x0304, which is so close to null that 
this is probably what is happening. Therefore, there might be a bug in 
your zero-detection code, so try using the secure method above and see 
if that fixes the error.

Or! Another plausible explation is that the current class (this->) is 
infact NULL, and the function that calls this function accesses a 
null-pointer, thus m_iTimerToShowInHUD refers to an illegal position.

If this is the case, the error might not be in the calling function, it 
could happen way down the stack sometimes. Go through the entire stack 
using the debugger or a minidump and see if you find anything nasty.

. Sortie.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] vgui::TextEntry problems

[Jonas 'Sortie' Termansen]

Of course your code crashes. Let me tell you what is happening in it.
> char *m_pTextUser = "";
> char *m_pTextPass = "";
>   
Here you initialize two strings to the value "". This means that both 
strings already point to a string. This string is null-terminated, and 
because the string is empty, the string is only one byte long and that 
byte is zero.

> int nLena = m_pUser->GetTextLength() + 1;
> int nLenb = m_pPassword->GetTextLength() + 1;
>   
Here you get the length of the username and the password and add one.

> m_pUser->SetText("terrorcell");
>   
Here you copy the text "terrorcell" into the m_pUser entity, which then, 
probably makes a local copy of "terrorcell".

> m_pUser->GetText(m_pTextUser, nLena);
> m_pPassword->GetText(m_pTextPass, nLenb);
>   
And here is your crash. Remember that the strings that both m_pTextUser 
and m_pTextPass point to, they are both 1 byte long. However, by calling 
this command with nLena, is telling the command that the string is nLena 
bytes long, while it only is 1 byte long. Now, the command tries to copy 
the string into m_pTextUser, and copies more bytes into the string than 
it can handle. The moment the program realizes that, the code crashes.

Instead you should either get a pointer to the username and the 
password, or allocate a new string and copy the contents into that. So 
what you should do instead is.

m_pUser->SetText("terrorcell");

// Allocate new strings
int nLena = m_pUser->GetTextLength() + 1;
int nLenb = m_pPassword->GetTextLength() + 1;
char *m_pTextUser = new char[nLena];
char *m_pTextPass = new char[nLenb];

// Copy the strings
m_pUser->GetText(m_pTextUser, nLena);
m_pPassword->GetText(m_pTextPass, nLenb);

// Display the strings.
Msg(m_pTextUser);
Msg(m_pTextPass);

// Do not forget to deallocate your new strings
// when you are done using them!
delete[] m_pTextUser;
delete[] m_pTextPass


That said, you should go get a C++ book and read about how pointers, 
C-style strings and other basic C++ stuff works. It doesn't look like 
you know what you are doing.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] How safe is it to travel into "The Void"

[Jonas 'Sortie' Termansen]

In portal, I once made a portal into the void using Hammer. That was 
interesting.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting the SteamID or CommunityID if the player in a Singleplayer game?

[Jonas 'Sortie' Termansen]

We know that the system isn't reliable and can be hacked. The only 
secure way to prevent this, is by signing the binaries to detect if they 
have been tampered with. The int hash system is a pretty good idea - but 
it's not worth the effort - we only want to prevent Joe Average from 
playing any leaked version.

Plus this is meant to be a reusable system - part of a content 
distribution platform - so it has to be user-friendly and I think it's 
too complicated to tell people to SHA-1 Hash their usernames and convert 
it to int's. Instead, we should focus on releasing stuff, not preventing 
a release!

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting the SteamID or CommunityID if the player in a Singleplayer game?

[Jonas 'Sortie' Termansen]

Heimo Stieg skrev:
> You have also other options:
> Check the steam account name( just check the folders )
> Read the steamid out of the registry or the log files
> BIOS or motherboard serial number ( use WMI for that )
Kyle '1/4 Life' and I decided on detecting the Steam Account Names using 
the current working directory using the command _getcwd() and then 
parsing the string to isolate the Steam Username and then comparing it 
to a list of usernames. Quite simple, really. It's easy to hack using a 
hex editor, but we decided it's reliable enough for our needs.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Getting the SteamID or CommunityID if the player in a Singleplayer game?

[Jonas 'Sortie' Termansen]

Kyle Gospodnetich skrev:
> Hey everyone. I'm having a little trouble getting a unique identifier 
> for players playing our singleplayer game. What I'm basically trying to do is 
> identify the player's SteamID/CommunityID/Other static unique 
> identifier and compare it to a list of developers (From there, running 
> code if they're not a dev) as a form of leak protection.
>   
Hi Kyle "1/4 Life" Gospodnetich.

I believe the technology I am providing for your team this month will be 
able prevent leaks. You don't need to worry about this.

However, on the topic of preventing leaks via game code. If people get 
hold of your game, they can replace your client.dll and server.dll and 
play the game regardless. This is not reliable. I think you should focus 
more on only giving your mod to trusted people and making sure the 
connection to its storage is fully encrypted. If you do care enough 
about preventing leaks, that is.

- Jonas "Sortie" Termansen

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Huge SDK/Hammer Problems

[Jonas 'Sortie' Termansen]

>
> Also, I forgot to add - every now and again my camera view glitches out 
> and thinks it's in shift-z fullscreen mode. E.G it's still only 1/4 of 
> the screen but the centre of where I was facing is now in the middle of 
> the whole screen. I have to hit shift-z a few times and it's annoying as 
> hell.
>   
Wasn't that a bug in the Steam Community? It happens when people talk to 
you on Steam Friends. They fixed that about a month or two ago, didn't 
they. Weird you still have it. Or is it another bug?

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Huge SDK/Hammer Problems

[Jonas 'Sortie' Termansen]

>
> Also, I forgot to add - every now and again my camera view glitches out 
> and thinks it's in shift-z fullscreen mode. E.G it's still only 1/4 of 
> the screen but the centre of where I was facing is now in the middle of 
> the whole screen. I have to hit shift-z a few times and it's annoying as 
> hell.
>   
Wasn't that a bug in the Steam Community? They fixed that about a month 
or two ago, didn't they. Weird you still have it.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Avi Materials

[Jonas 'Sortie' Termansen]

You are doing something wrong. I have been really toying with this, and 
I have had some of the bugs you have mentioned, but I have also fixed 
them. The problem is that produceral materials needs to be redrawn. 
Although as long as stay ingame it doesn't 'need' to be redrawn, but you 
cannot be sure the memory of the produceral texture is overriden. This 
happens when you alt-tab the game or something nasty.

The avi system you are using are a bit flawed in the first place. I've 
been experimenting with using ffmpeg instead - and I got it successfully 
working ingame. Although it's hardly finished and is still very very 
buggy and experimental, it is able to playable all sorts of videos. I 
need to add a few other features to it, but if you are interested, mail 
me and I'll provide you with the WIP code. I'll post it on the Wiki once 
it's working correctly.
> Hello,
>
>  
>
> I've tried to utilize the IAvi Interface to create a material for an avi
> file.
>
>  
>
> I've the following code running when my entity is created on the client.
>
>  
>
> The avi is a valid file because it complains if it can't find the file. The
> file I am passing in for now was created in the engine itself using
> startmovie blah avi
>
>  
>
> if(updateType == DATA_UPDATE_CREATED)
>
> {
>
>   m_hAviMaterial =
> avi->CreateAVIMaterial(m_strAviMaterial,m_strAviMaterial,"GAME");
>
>  
>
>   if ( m_hAviMaterial != AVIMATERIAL_INVALID )
>
>   {
>
> m_flAviFrameCount = avi->GetFrameCount(m_hAviMaterial);
>
> m_pAviMaterial = avi->GetMaterial(m_hAviMaterial);
>
> SetNextClientThink(CLIENT_THINK_ALWAYS);
>
>   }
>
>  
>
>   if(m_pAviMaterial)
>
> m_pAviMaterial->AddRef();
>
> }
>
>  
>
> Then in my DrawModel function I do.
>
>  
>
> if(m_pAviMaterial)
>
>   modelrender->ForcedMaterialOverride(m_pAviMaterial);
>
>  
>
> int val = BaseClass::DrawModel(flags);
>
> modelrender->ForcedMaterialOverride(0);
>
> return val;
>
>  
>
> This does not work so to speak because I get a material on my model that is
> pink checkerboard partially and the rest has no alpha. When I brought up the
> console I got some artifacts from other textures showing on my model. These
> artifacts seemed to be the memory for the main menu texture, and also one of
> our mods hud textures as well as some random pixels.
>
>  
>
> I've also tried forcing the frame to some constant value every think and it
> doesn't help.
>
>  
>
> Has anyone had any success with using this?
>
>  
>
> Thanks
>
> Chris
>
> ___
> 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] Adding keybindings

[Jonas 'Sortie' Termansen]

/scripts/kb_act.lst

If this file isn't in your mod - you need to extract it using GCFScape 
from one of the game .gcf files.

Welcome to the list!
> Hi everyone
> this is the first time that I use this mailing list and I am very new to the 
> source engine therefore I dont know much about the structure of the source 
> engine.
> My question is how to add entrys in the key bindings table in the options 
> menu.
> I use the hl2mp source codes.
>
> Thanks
>
> Tobias
>   


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Possable Improvements to the Source SDK

[Jonas 'Sortie' Termansen]

There are lots of problems with compiling inside Hammer. Compiles are 
often slowed down because of Hammer using a lot of memory, plus Hammer 
is frozen while the Compile is going on. And when you finally get 
ingame, Hammer is still using the memory, and depending on your 
computer, the game will run slower than it would with Hammer closed. I 
don't recommend compiling with Hammer open and esspecially not testing 
with Hammer open.

If you want to compile outside Hammer, I suggest you get a copy of VBCT 
by Quicksilver 

It's an excellent tool - although it still isn't fully polished - I 
actively use it for compiling and it has a lot of useful features. I 
just wish it was Open Source so I could polish it a bit more. ;)//
> I hear your pain, bro.
>
> Thanks,
> - Saul.
>
>
> 2009/8/30 Jorge Rodriguez 
>
>   
>> This is only slightly off topic, but:
>>
>> Every version of Hammer (even back to Worldcraft and before) I've ever
>> worked with, the build window always stops updating about 20 or 30 seconds
>> into the process. All of Hammer then freezes up until the build is
>> completely done, so progress isn't visible. Does this happen to anybody
>> else?
>>
>> --
>> Jorge "Vino" Rodriguez
>> ___
>> 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] Source control solution?

[Jonas 'Sortie' Termansen]

Any links to said VS Plugins?
> I used CVS for 8 years and my last job and it was hellish. We use SVN
> for our mod and I would never consider going back to CVS.
>
> There are also some very nice SVN plug-ins for Visual Studio which
> make it even easier to work with as well as the excellent TortoiseSVN.
>
> - Jed
>
> 2009/8/24 Bob Somers :
>   
>> For the love of god do not use CVS. If you're going to go with
>> centralized version control (which is conceptually easier to grok)
>> then stick with SVN. There's a free book on the web if you're having
>> problems learning how to use it. With TortoiseSVN, I've found it very
>> easy to work with once you have the basic concepts down.
>>
>> http://svnbook.red-bean.com/
>>
>> There's also the distributed version control systems like Git and
>> Mercurial, but those are going to more conceptually complicated to
>> understand at first. I'd stay stick with Subversion. Reading through
>> the book will help you get comfortable with it.
>>
>> --Bob
>>
>>
>>
>> On Mon, Aug 24, 2009 at 3:12 AM, Olly wrote:
>> 
>>> SourceSafe is a bit different to SVN, but SVN is alot like CVS (as well as
>>> most new version control systems). You should try to get some more knowledge
>>> of SVN because its probably the best solution (and sounds like you are using
>>> it wrong).
>>> But SourceSafe is horrible, I used to use it at work, and it got corrupt so
>>> many times.
>>>
>>> 2009/8/24 DAV 
>>>
>>>   
 Hi,

 I am looking for a free source control solution.
 I am very used to MS Source Safe (use it at work).

 Recently I tried SVN in xp-dev.com but didn't like it. Mainly because of
 not
 being possible to checkout a single file from svn using tortoise and it is
 very confusing (at least for me).

 How about CSV?
 Anyone knows of a free CSV server?

 I could also use a source control server that doesn't require a 'install'
 since the server a rent doesn't allow me to install software.
 But if the install process is just to copy some files to it then it is ok.

 Ideias, sugestions?

 Thanks,
 Davide (DAV)
 Email: d...@davlevels.com
 Azure Sheep: http://mods.davlevels.com/azuresheep/
 Point of View: http://mods.davlevels.com/pointofview/
 DAV Levels: http://www.davlevels.com/
 ___
 To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders


 
>>> --
>>> Sent from Olly's SEGA Game Gear
>>> ___
>>> 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] Where to begin?

[Jonas 'Sortie' Termansen]

Source should do the trick with the gameplay and networking. You don't 
need that much Engine Access to to optimations, though, all you need is 
a clear understanding of the engine. Unfortunately Source isn't 
cross-platform, so you are required to use Windows (which the vast 
majority of gamers use anyways). But you might be better off with 
another engine.
> I want to write a mech (giant robot) combat game with networked
> multiplayer play as well as a story mode. The game will be a mix of
> RPG and FPS gameplay. I probably want this game to be cross-platform,
> so that it can be played by people who use other operating systems.
> DirectX isn't exactly cross-platform (to my knowledge), and I probably
> wouldn't sell the game (at least not initially) so a commercial
> license probably isn't worth it. I worry that having limited access to
> the game engine may pose problems with optimizations and improvements
> down the road (purely a hunch).
>
> Anyone have any strong opinions on Irrlicht? I was able to get it up
> and running fairly quickly, and playing around with the engine has
> been pretty straightforward so far. Also, it's pretty fast (in my
> limited usage of it). Thoughts?
>
> On Fri, Aug 21, 2009 at 11:54 AM, Jonas 'Sortie'
> Termansen wrote:
>   
>> It really depends on what you are trying to do. What are you trying to
>> do? Are you trying to make a FPS, a RTS, a RPG, or a MMO? Or do you just
>> want to make some DirectX rendered stuff, or a 2D game? Source can do
>> some of these things, but not all. Perhaps if you told us your game
>> idea, we might be able to figure out if Source is the engine of your
>> choice or maybe even help you find a better engine. It also sort of
>> depends if you want your game to rely on your users owning another
>> Source game or if you are commercial and can afford a Source License.
>> 
>>>> Noted. Thanks, Tom. I think I'll look elsewhere for this project, and
>>>> come back to the Source engine when I have an idea that's more clearly in 
>>>> the style of HL2/CSS.
>>>> 
>> ___
>> 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] Where to begin?

[Jonas 'Sortie' Termansen]

It really depends on what you are trying to do. What are you trying to 
do? Are you trying to make a FPS, a RTS, a RPG, or a MMO? Or do you just 
want to make some DirectX rendered stuff, or a 2D game? Source can do 
some of these things, but not all. Perhaps if you told us your game 
idea, we might be able to figure out if Source is the engine of your 
choice or maybe even help you find a better engine. It also sort of 
depends if you want your game to rely on your users owning another 
Source game or if you are commercial and can afford a Source License.
>> Noted. Thanks, Tom. I think I'll look elsewhere for this project, and
>> come back to the Source engine when I have an idea that's more clearly in 
>> the style of HL2/CSS.

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] My harddrive died overnight. No warning. I lost tons of data.

[Jonas 'Sortie' Termansen]

*To unsubscribe, edit your list preferences, or view the list archives, please 
visit:

http://list.valvesoftware.com/mailman/listinfo/hlcoders

If that isn't helpful, please tell us and we'll help you get off the list. (Or 
can some administrator simply remove him permanently so he doesn't spam again 
like he's done a few thousand times before)
*

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Creating a physics entity?

[Jonas 'Sortie' Termansen]

How about simply reading how they wrote the Rollermine in the code?
> Greetings,
> I have been a fan of the game and level design in general for some time.
> I am getting my feet wet in regards to HL2 coding. My current project
> necessitates the creation of some new spherical entities similar to the
> roller mines. That is, they need to be able to roll at will, but must also
> be able to be lifted with the physics cannon. I have been looking through
> the SDK docs and searching the web, and haven't found any clear and
> explanatory tutorials on the usage of the physics system. I'm not asking
> anyone to go through the effort of teaching me how to use it, but I was
> hoping that someone could refer me to a good learning resource for the
> physics system.
>
> Thanks in advance for any advice,
> Drew
> ___
> 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] Bug in sending "attached" particles to the client (A FIX)

[Jonas 'Sortie' Termansen]

Sounds reasonable - but perhaps it'd be more useful to also have it on 
the pages about the particles, so people interested in particles will 
see the fix instead of having to dig through the bug list? But I guess 
this discussion should be moved to the wiki, not.
> OK, I posted my fix for the particle dispatch (as requested) in the
> Programmers portion of the SDK Known Issues Fixed entry on the Development
> Wiki. However, noting that the SDK issues list and fixed list are completely
> out of date and should be entirely scrapped. I am totally in favor of doing
> this myself and building a new fixed issues list, properly, by having
> multiple pages for each version of the SDK instead of one big long nasty
> page with outdated information from 4 years ago. All in favor?
>
> Link:
> http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List_Fixed#Server_Dispatching_an_Attached_Particle_Effect
>
> Jonathan White
> GoldenEye: Source
> ___
> 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] Bug in sending "attached" particles to the client (A FIX)

[Jonas 'Sortie' Termansen]

Did anyone post this on the wiki? The information will be much more 
available there compared to this list's thousands of emails.
> Hi Jonathan,
>
> I'm not really friendly with particle behaviours meaning that I can't really
> test that your fix is working but looking at your explaination I feel
> confident. I would have like having an answer from Valve in order to be sure
> this origin is not set in any other location but nothing for few days.
>
> Anyway, I wanted to thank you for sharing this fix with the hlcoders list.
> It is really a very nice attitude that I sincerelly appreciate. Thank you.
> Keep up the good spirit.
>
> J.
>
> 2009/8/5 Jonathan White 
>
>   
>> When trying to dispatch a particle effect from the server to the client
>> using DispatchParticleEffect( const char *pszParticleName,
>> ParticleAttachment_t iAttachType, CBaseEntity *pEntity, const char
>> *pszAttachmentName, bool bResetAllParticlesOnEntity ) I noticed that it
>> wasn't working at all, meaning the client never received the dispatch. My
>> first intuition was that it was being suppressed by prediction, but that
>> quickly resolved to not being the case.
>>
>> I finally resolved that it was because when you dispatch an effect, the
>> recipient list is calculated based on whoever is in PAS range. Well, the
>> origin for the effect is never initialized when you try to dispatch an
>> effect that originates from an attachment point on an entity! The following
>> is a fix to this problem:
>>
>> particle_parse.cpp, Lines 196 - 219
>> In Function: void DispatchParticleEffect( const char *pszParticleName,
>> ParticleAttachment_t iAttachType, CBaseEntity *pEntity, int
>> iAttachmentPoint, bool bResetAllParticlesOnEntity )
>>
>> OLD FUNCTION:
>> void DispatchParticleEffect( const char *pszParticleName,
>> ParticleAttachment_t iAttachType, CBaseEntity *pEntity, int
>> iAttachmentPoint, bool bResetAllParticlesOnEntity )
>> {
>>CEffectDatadata;
>>
>>data.m_nHitBox = GetParticleSystemIndex( pszParticleName );
>>if ( pEntity )
>>{
>> #ifdef CLIENT_DLL
>>data.m_hEntity = pEntity;
>> #else
>>data.m_nEntIndex = pEntity->entindex();
>> #endif
>>data.m_fFlags |= PARTICLE_DISPATCH_FROM_ENTITY;
>>}
>>data.m_nDamageType = iAttachType;
>>data.m_nAttachmentIndex = iAttachmentPoint;
>>
>>if ( bResetAllParticlesOnEntity )
>>{
>>data.m_fFlags |= PARTICLE_DISPATCH_RESET_PARTICLES;
>>}
>>
>>DispatchEffect( "ParticleEffect", data );
>> }
>>
>> CORRECTED FUNCTION:
>> void DispatchParticleEffect( const char *pszParticleName,
>> ParticleAttachment_t iAttachType, CBaseEntity *pEntity, int
>> iAttachmentPoint, bool bResetAllParticlesOnEntity )
>> {
>>CEffectDatadata;
>>
>>data.m_nHitBox = GetParticleSystemIndex( pszParticleName );
>>if ( pEntity )
>>{
>>data.m_vOrigin = pEntity->GetAbsOrigin();
>> #ifdef CLIENT_DLL
>>data.m_hEntity = pEntity;
>> #else
>>data.m_nEntIndex = pEntity->entindex();
>> #endif
>>data.m_fFlags |= PARTICLE_DISPATCH_FROM_ENTITY;
>>}
>>data.m_nDamageType = iAttachType;
>>data.m_nAttachmentIndex = iAttachmentPoint;
>>
>>if ( bResetAllParticlesOnEntity )
>>{
>>data.m_fFlags |= PARTICLE_DISPATCH_RESET_PARTICLES;
>>}
>>
>>DispatchEffect( "ParticleEffect", data );
>> }
>>
>> Note the addition of data.m_vOrigin, that is what the recipient list filter
>> uses to calculate the PAS recipients and must be initialized even if the
>> particle effect isn't ultimately going to use it.
>>
>> Jonathan White
>> GoldenEye: Source
>> ___
>> 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] Checking to see if an object/world vector is in a visible leaf?

[Jonas 'Sortie' Termansen]

The only reliable way to do this is to find out exactly what leaves the 
projector projects into and then see if any of them is in the PVS. After 
searching the code, I found that there are some lists of all shadows in 
the game, and that each leaf has a handle per shadow (projectors?).

Try search clientleafsystem.cpp for more information, I'd gladly help in 
more detail, but try and search it and see what comes up, you might need 
to make some new functions, but it's possible.
> Problem with this: the light won't draw if it is out of PVS, even if 
> surfaces it shines on are in.
>
> Testing the PVS of the entity and the end of a traceline down AbsAngles 
> to a maximum of m_flFarZ /should/ overcome that...most of the time
>
> Kyle Gospodnetich wrote:
>   
>> HLCoders wrote:
>>   
>> 
>>> After a very quick search in some header files, I think these two 
>>> functions might interest you.
>>>
>>> bool IVRenderView::AreAnyLeavesVisible( int *leafList, int nLeaves );
>>> int IEngineTrace::GetLeafContainingPoint( const Vector &ptTest ) = 0;
>>>
>>> I haven't tested them, but if they work like I think they do, this is 
>>> how you'd do it. I think this is client-side too.
>>>
>>> bool ShouldDraw( const Vector &ptTest )
>>> {
>>> int LeafNum = enginetrace->GetLeafContainingPoint(ptTest);
>>> return render.>AreAnyLeavesVisible(&LeafNum,1);
>>> }
>>>   
>>> 
>>>   
 Is it possible to check if an object or vector is within a visible 
 (currently being rendered) visleaf? I need to occlude an entity that 
 isn't normally occluded, and this is the best way I can think of doing 
 it. Any help is much appreciated. I can't find any examples of this in 
 the code.

 -Kyle '1/4 Life' G.

 ___
 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
>>>
>>>
>>>   
>>> 
>>>   
>> It works!
>>
>> Here, let me give back to the community:
>> If you want projected textures to occlude properly, head into 
>> c_env_projectedtexture.cpp and add:
>>
>> ...
>> public:
>> DECLARE_CLIENTCLASS();
>>
>> boolShouldDraw( const Vector &vecOrigin );
>> ...
>>
>> ...
>> bool C_EnvProjectedTexture::ShouldDraw( const Vector &vecOrigin )
>> {
>> int LeafNum = enginetrace->GetLeafContainingPoint(vecOrigin);
>> return render->AreAnyLeavesVisible(&LeafNum,1);
>> }
>> ...
>>
>> Change
>>
>> if ( m_bState == false )
>> {
>>
>> To
>>
>> if ( m_bState == false || !ShouldDraw( GetAbsOrigin() ) )
>> {
>>
>> in UpdateLight()
>>
>> And finally:
>>
>> void C_EnvProjectedTexture::Simulate( void )
>> {
>> //UpdateLight( false );
>> UpdateLight( true );
>>
>> BaseClass::Simulate();
>> }
>>
>> ___
>> 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] Awkward crash dumps

[Jonas 'Sortie' Termansen]

Yeah, if the callstack does not include any of the .dll's then it's a 
system-level (or lower) crash. Your code can cause it though, and it's not 
easy detecting exactly what caused it. The easiest way to debug such 
mysterious errors is to debug them the moment they begin to crash, and not 
keep implemting new features with new bugs, it just makes it hard to find 
out what's causing the first bugs.

If you cannot fix the bugs by debugging, you migth need to strip your 
features out one by one by reverting to the valve-stock-code. It's a 
nightmare, but it's not that bad, I've done it several times.

And an army of testers are the best thing in the world!

- Original Message - 
From: "Jorge Rodriguez" 
To: ; "Discussion of Half-Life Programming" 

Sent: Friday, August 07, 2009 5:00 PM
Subject: Re: [hlcoders] Awkward crash dumps


> On Fri, Aug 7, 2009 at 5:58 AM,  wrote:
>
>> * A crash where the call stack ONLY shows a memory address? Not even any
>> mention of a dll. This is our most common crash, and happens 1-2 times a 
>> day
>> on each server.
>>
>
>
> These are usually crashes dealing with the user's hardware. Video card
> drivers or operating system failures of some kind. Sometimes something 
> that
> you do in the mod's programming can screw up the engine and make it crash
> though, good luck finding that.
>
> As for a Linux client, I would find that rather surprising if you had one.
>
> -- 
> Jorge "Vino" Rodriguez
> ___
> 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] Cryptic crash in engine.dll

[Jonas 'Sortie' Termansen]

Are you combining Ep2 (OB) or newer compile tools with the Ep1 engine? (Or 
something nasty like that).

- Original Message - 
From: "Minh" 
To: "Discussion of Half-Life Programming" 
Sent: Thursday, August 06, 2009 5:05 PM
Subject: [hlcoders] Cryptic crash in engine.dll


> Has anyone encountered the following crash in the engine.dll ?
>
> CColorMeshData *CModelRender::FindOrCreateStaticPropColorData(
> ModelInstanceHandle_t handle )
> {
> ..
> ..
>Assert( modelloader->IsLoaded( instance.m_pModel ) && (
> instance.m_pModel->type == mod_studio ) );
>studiohwdata_t *pStudioHWData = g_pMDLCache->GetHardwareData(
> instance.m_pModel->studio );
>
>
>
> It is happening to me constantly whenever i change resolutions on a
> certain level. It only happens on some of my levels and I can't seem to
> find the cause of it. I thought it had something to do with the number
> of static props but I ended up removing all static props from my level
> and it still gives me the same crash. Anyone have any experience with
> this crash?
>
> ___
> 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] whats happening with this engine

[Jonas 'Sortie' Termansen]

Sorry, but you need to use a bit more punctuation in your mails, you don't 
use periods to stop your sentences making them really hard to read.

Sorry for spamming your mailbox on another spam topic on this list. Sorry!

- Original Message - 
From: "cathal mc nally" 
To: 
Sent: Wednesday, July 29, 2009 12:58 AM
Subject: Re: [hlcoders] whats happening with this engine


Hehe this all seems like an over grown Kettle of Fish
Well heres my take on itYup the tools are old looking and all but the engine 
works fine I only played Halflife for the first time there last Easter i 
have only been a member of steam Since christmasBasically Hl2 and both 
episodes blew me awayIm a gamer at heart and i have played lots of games in 
my time but no other Engine has grabbed me by the "balls" like this one did
I think that Alternative to Hammer you speak of is hereIts really only good 
for making structures and PrefabsIts called MicroBrushSeems hard to use but 
then again everything is on a first 
tryhttp://www.intercomm.com/shrinker/projects/Microbrush/
Well anyway i wanted to finish on a simple hard fact
VALVe dont Hire Zed outZED hires them outZing!!


Send instant messages to your online friends http://uk.messenger.yahoo.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] Material Previewer

[Jonas 'Sortie' Termansen]

I imagine supporting some material proxies might be tough, or at least to 
support them in the exact same way as the engine.

- Original Message - 
From: "Jed" 
To: "Discussion of Half-Life Programming" 
Sent: Tuesday, July 14, 2009 2:12 AM
Subject: Re: [hlcoders] Material Previewer


And I thought I was special...

If I had to choose I would use the source as reference and try to
implement my own solution in CG or something like that.

For the most part, the shaders are pretty simple and you'll get the
same of near enough the same results with your own. A lot of the
techniques on how stuff comes together is mentioned in a lot of
SIGGRAPH papers so you should be able to emulate it well enough. I
think isolating yourself from Source itself will solve any future
compatibility problems as well.

VTFLib already has code to create/parse VMTs so that wouldn't be an
issue and of course it reads the VTF files. So you'ld just need to
write your shaders really.

- Jed

2009/7/13 Brent Lewis :
>
> For some reason clicking reply in hotmail caused this email to go straight 
> to jed. *shrugs* Second try:
>
> OK. I found the shader source code in the GCF. But I see there are many 
> files. And I also noticed there is C++ code related to the shaders.
>
> Which is more sensible, trying to emulate the shaders by reverse 
> engineering the code, or should I just look at the VMT commands in the VDC 
> and implement the features based on their description? While I want to 
> make things easier on myself, I don't want to sacrifice accuracy and worry 
> that my implementation may produce different results than Valves.
>
>
>> Date: Sun, 12 Jul 2009 19:53:32 +0200
>> From: j...@wunderboy.org
>> To: hlcoders@list.valvesoftware.com
>> Subject: Re: [hlcoders] Material Previewer
>>
>> I looked into the viewport back in the day when the HLMV source was
>> out there (I was trying to improve it as I did with JHLMV). As you
>> say, it was basically a viewport linked into the engines rendering
>> system.
>>
>> I think you might be better off trying to emulate some of the stock
>> shaders yourself than link into the Valve stuff. Abstracting from that
>> will at the least give you some autonomy/portability and lessen the
>> chance of a Valve update borking your appl. That's was the reason we
>> developed HLLib/GCFScape/VTFLib.
>>
>> - Jed
>>
>> 2009/7/12 Rodrigo 'r2d2rigo' Diaz :
>> > Model Viewers always had their own rendererers, AFAIK. So you will need 
>> > to
>> > code your own...
>> >
>> > 2009/7/12 Brent Lewis 
>> >
>> >>
>> >> Some people have requested I put a material editor into DuctTape. I'm
>> >> thinking the smartest way to do this would be to actually get the 
>> >> source
>> >> engine to render it, like as is done in the engines "-tools" mode. I'm
>> >> guessing that the half life model viewer uses a view port via the 
>> >> engine...
>> >> so how can I do the same?
>> >>
>> >> Thank,
>> >> coder0xff
>> >> ___
>> >> 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] Access reception to hlcoders forum

[Jonas 'Sortie' Termansen]

But the hash is part of the file - the hash can simply be recalculated and 
replaced and without being signed, the file cannot be known if it's intact.

- Original Message - 
From: "Dave Gomboc" 
To: 
Sent: Tuesday, July 07, 2009 11:01 PM
Subject: Re: [hlcoders] Access reception to hlcoders forum


> >
>> Checksums really don't provide security against tampering, as they are
>> too easy to manufacture. They're more often used to detect casual
>> corruption errors like those that could be introduced during network
>> transmission.
>>
>> --Bob
>>
>
> I'm not sure what your definition of "easy to manufacture" is, but I'm not
> aware that the frequently-used SHA-1 would qualify as such.  Finding a
> collision has been proven to be possible faster than via brute force 
> attack,
> but I would think that doing so with contrived data that must also serve 
> as
> a working substitute for the original data would still be pretty difficult
> (as of July 2009, anyway).  Also, there's better checksums than SHA-1 that
> could be used in its stead.
>
> Dave
> ___
> 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] Access reception to hlcoders forum

[Jonas 'Sortie' Termansen]

You can't really rely on the .dem file being intact unless it has been 
signed with a public key, or something smart that the game doesn't do.

- Original Message - 
From: "Bob Somers" 
To: "Discussion of Half-Life Programming" 
Sent: Tuesday, July 07, 2009 7:56 PM
Subject: Re: [hlcoders] Access reception to hlcoders forum


> Checksums really don't provide security against tampering, as they are
> too easy to manufacture. They're more often used to detect casual
> corruption errors like those that could be introduced during network
> transmission.
>
> --Bob
>
>
>
> On Mon, Jul 6, 2009 at 4:43 PM, Matt Hoffman 
> wrote:
>> Don't think they have a checksum?
>>
>> On Sun, Jul 5, 2009 at 3:55 PM, Saul Rennison 
>> wrote:
>>
>>> won't modifying DEM files raw screw up the checksum? :\
>>>
>>> Sent from my iPhone
>>>
>>> On 5 Jul 2009, at 23:41, Tom Leighton 
>>> wrote:
>>>
>>> > The STEAM id's are indeed in the demo files aswell, in plain text,
>>> > which
>>> > is why you should never rely on demos to be entirely secure on their
>>> > own, and 100% proof someone's a hacker.
>>> >
>>> >
>>> >
>>> > Harry Jeffery wrote:
>>> >> Yeah - I thought that when I found out about how demos are stored.
>>> >> Very easy to incriminate an opposing team in CSS if you're desperate
>>> >> to win.
>>> >>
>>> >> 2009/7/4 Matt Hoffman :
>>> >>
>>> >>> Demo's look easy to fake. I was poking around in one the other day
>>> >>> and found
>>> >>> the server name/player names as strings.
>>> >>>
>>> >>> I was unable to test it, but I wonder if you can change the
>>> >>> strings and save
>>> >>> and have the differences in game... Make it easy to be an imposter
>>> >>> and
>>> >>> incriminate someone else. ;)
>>> >>>
>>> >>> On Fri, Jul 3, 2009 at 3:40 PM, Harry Jeffery <
>>> >>> harry101jeff...@googlemail.com> wrote:
>>> >>>
>>> >>>
>>> >>>> IIRC .dem files are just logs of the packets received and sent.
>>> >>>>
>>> >>>> Thats why going to a tick in a CSS demo is a bit glitchy - it has
>>> >>>> to
>>> >>>> roll forwards to that tick so that everything is correct - it's
>>> >>>> mere
>>> >>>> updates not exactly where everything was each tick.
>>> >>>>
>>> >>>> 2009/7/3 Joel R. :
>>> >>>>
>>> >>>>> I think he is trying to learn how to remove speed hackers by using
>>> >>>>>
>>> >>>> recorded
>>> >>>>
>>> >>>>> demos. In any case, he definately needs some work on that
>>> >>>>> engrish.
>>> >>>>>
>>> >>>>>
>>> >>>>> On Fri, Jul 3, 2009 at 7:38 AM, botman 
>>> >>>>>
>>> >>>> wrote:
>>> >>>>
>>> >>>>>> Jonas 'Sortie' Termansen wrote:
>>> >>>>>>
>>> >>>>>>> Engrish anyone?
>>> >>>>>>>
>>> >>>>>>> Trinitron, I have no idea what you are talking about. This
>>> >>>>>>> isn't a
>>> >>>>>>>
>>> >>>>>> 'forum',
>>> >>>>>>
>>> >>>>>>> it's a mailing list. But if you want to see the previous
>>> >>>>>>> mails, there
>>> >>>>>>>
>>> >>>>>> should
>>> >>>>>>
>>> >>>>>>> be some website where you can browse them.
>>> >>>>>>>
>>> >>>>>>> But what I understood was, you want the current .dem format?
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>> There is a searchable archive of the hlcoders email list here...
>>> >>>>>>
>>> >>>>>> http://www.mail-arch

Re: [hlcoders] Could not load library client Error

[Jonas 'Sortie' Termansen]

(Ep1 maps works in OB according to my experience)

- Original Message - 
From: "Mark Chandler" 
To: "Discussion of Half-Life Programming" 
Sent: Tuesday, July 07, 2009 4:37 PM
Subject: Re: [hlcoders] Could not load library client Error


> Are you compiling the map for the right engine version as ep1 maps dont
> work in ob and ob maps dont work in ep1.
>
>
> Mark
>
> ___
> 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] Hopwire Vortex issues - Need a little help

[Jonas 'Sortie' Termansen]

Well, you don't check if pRagdollPhys is a NULL-pointer.

- Original Message - 
From: "Kyle Gospodnetich" 
To: "Discussion of Half-Life Programming" 
Sent: Sunday, July 05, 2009 3:25 AM
Subject: [hlcoders] Hopwire Vortex issues - Need a little help


> Hello everyone. I'm working on a new weapon for a little project of
> mine, and I decided that the hopwire's vortex effect would be perfect
> for it's secondary attack. The problem is, when the hopwire goes off, it
> crashes if a player is too close to it. This problem is only present on
> the orange box engine, as a clean EP1 engine compile seems to work just
> fine. According to the dumps, this is the line that's crashing.
>
> grenade_hopwire.cpp
>// Ragdolls need to report the sum of all their parts
>CRagdollProp *pRagdoll = dynamic_cast< CRagdollProp* >( pEnt );
>if ( pRagdoll != NULL )
>{
>// Find the aggregate mass of the whole ragdoll
>ragdoll_t *pRagdollPhys = pRagdoll->GetRagdoll();
>for ( int j = 0; j < pRagdollPhys->listCount; ++j )
>{
>m_flMass += pRagdollPhys->list[j].pObject->GetMass();
>}
>}
>else
>{
>// Otherwise we just take the normal mass
>>>m_flMass += pPhysObject->GetMass();
>}
>
> It's giving a negative mass. What's weird is, even if I hard code the
> mass ( m_flMass = 1; ) , it still crashes with a negative mass.
>
> ___
> 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] Access reception to hlcoders forum

[Jonas 'Sortie' Termansen]

Engrish anyone?

Trinitron, I have no idea what you are talking about. This isn't a 'forum', 
it's a mailing list. But if you want to see the previous mails, there should 
be some website where you can browse them.

But what I understood was, you want the current .dem format?

- Original Message - 
From: "Trinitron" 
To: 
Sent: Friday, July 03, 2009 6:14 AM
Subject: [hlcoders] Access reception to hlcoders forum


> Hello Valve.
> I would like to get access to viewing of this forum as I consider that 
> here
> I at last will find answers to the questions. I wish to create the program
> which could find out use of program SpeederXP.
>
> As far as I know, for this purpose it is necessary to know format 
> structure
> ".dem" file. I have a description ".dem" file with old link: "
> www.planetquake.com/demospecs/dem"
>
> But I as believe that studying only is not enough this structure of a 
> file.
>
> Stay TunedSergey
> ___
> 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] Funky 3D view angles in Hammer, Model Viewer, and Model Browser.

[Jonas 'Sortie' Termansen]

It's happening for almost everyone.

It happens when Steam tries to play a sound, like recieving a message or a 
friend coming online, while the GameOverlayUI.exe process is running. It 
automatically goes away after 10 seconds, any other *fixes* is just pure 
luck. The fix I found is to launch the Source SDK Hammer and then close the 
GameOverlayUI.exe process using Windows Task Manager.

You can reproduce the bug by opening the OB Hammer, start mapping and have 
someone say hello.

- Original Message - 
From: "James K" 
To: "Discussion of Half-Life Programming" 
Sent: Sunday, June 28, 2009 3:52 AM
Subject: [hlcoders] Funky 3D view angles in Hammer, Model Viewer,and Model 
Browser.


> I'm sure a lot of people have noticed this. Whenever I first start hammer
> and load a map the 3D view is all screwed up and has a very odd camera 
> angle
> that doesn't go away without hitting CTRL+Z about 6 times. This 
> happens
> in pretty much anything with a 3D view in the SDK. What's the deal? Is
> anybody working on a fix?
> ___
> 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] Request to Valve: Increase the model precache limit.

[Jonas 'Sortie' Termansen]

Access to the Source Code is actually very useful, even if you don't modify 
it. You have access to much better debugging of engine specific bugs, you 
have better documentation (the source code itself) and you can see how Valve 
did stuff. All these things and more makes development and debugging much 
easier.

- Original Message - 
From: "Nick" 
To: "Discussion of Half-Life Programming" 
Sent: Saturday, June 27, 2009 11:09 PM
Subject: Re: [hlcoders] Request to Valve: Increase the model precache limit.


> You pay for the license and you don't even modify the actual game
> engine? And your mod would benefit the most from altered game engine?
>
> YOU FAIL, BADLY.
>
> On Sun, Jun 14, 2009 at 9:19 AM, Garry Newman 
> wrote:
>> I wouldn't mind this. But there's a lot of things I wouldn't mind
>> increasing, like max edicts, and whatever causes the string table 
>> baseline
>> overflow.
>> Maybe I should bite the bullet and try to ship with my own engine 
>> binaries?
>> I really don't want to, especially just to increase these variables.. but
>> maybe it's the only way.
>>
>> garry
>>
>>
>> On Sun, Jun 14, 2009 at 9:26 AM, Harry Pidcock  wrote:
>>
>>> At the moment the maximum model precache limit in the engine is 1024,
>>> whereas with soundprecache we can load up to 8192.
>>>
>>> If you try to load more than 1024 models into the engine(throughout the
>>> entire game session) the server will crash.
>>>
>>> Games like Garry's Mod will crash regularly due to it's sandbox nature.
>>> 1024
>>> models is hardly enough.
>>>
>>> I suspect this is due to the server and client having statically sized
>>> arrays rather than having dynamically expanding CUtlVectors or 
>>> something.
>>>
>>> Please look into this,
>>> Haza.
>>>
>>>
>>> ___
>>> 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] Source SDK Beta Concluded

[Jonas 'Sortie' Termansen]

> What if you just add "tf" as a game path in your gameinfo.txt?
>

I think that'd work too - at the cost of longer loading times due to 
additional search paths.

> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com
> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Jonas 
> 'Sortie'
> Termansen
> Sent: Thursday, 18 June 2009 6:59 PM
> To: Discussion of Half-Life Programming
> Subject: Re: [hlcoders] Source SDK Beta Concluded
>
> Workaround for fixing Hammer's model browser:
>
> Using GCFScape, extract platform/resource/mdlpickerscreencaps.res from
> "multiplayer ob binaries.gcf" in your SteamApps folder. Copy
> mdlpickerscreencaps.res into the Resource/ folder of the game or mod you 
> are
>
> working on. If Hammer mounts content from the folder you copied it into, 
> the
>
> Hammer model browser should be fine.
>
> - Original Message - 
> From: "Mike Durand" 
> To: "Discussion of Half-Life Programming" 
> 
> Sent: Wednesday, June 17, 2009 8:06 PM
> Subject: Re: [hlcoders] Source SDK Beta Concluded
>
>
>> It was 'mdlpickerscreencaps.res'. We'll be fixing it for Ep2 and Portal
>> soon, but copying the file to the 'hl2/platform/Resource' directory 
>> should
>
>> get you going until then.
>>
>> -Mike
>>
>> -Original Message-
>> From: hlcoders-boun...@list.valvesoftware.com
>> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Jonas
>> 'Sortie' Termansen
>> Sent: Wednesday, June 17, 2009 10:17 AM
>> To: Discussion of Half-Life Programming
>> Subject: Re: [hlcoders] Source SDK Beta Concluded
>>
>> Which file is it?
>>
>>> Aw man I fixed this ages ago in my working copy, had I known that was 
>>> the
>>> problem I could have sent you guys that resource file a long time ago.
>>> Sorry
>>> guys :/
>>>
>>> Anyways for Portal and Ep2 it will probably work if you find the
>>> appropriate
>>> resource file in the TF2 cache and copy it into your Portal/Ep2
>>> directory.
>>>
>>> -- 
>>> Jorge "Vino" Rodriguez
>>> ___
>>> 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
>
>
> __ Information from ESET Smart Security, version of virus 
> signature
> database 4166 (20090618) __
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
> __ Information from ESET Smart Security, version of virus 
> signature
> database 4166 (20090618) __
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.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] Source SDK Beta Concluded

[Jonas 'Sortie' Termansen]

Workaround for fixing Hammer's model browser:

Using GCFScape, extract platform/resource/mdlpickerscreencaps.res from 
"multiplayer ob binaries.gcf" in your SteamApps folder. Copy 
mdlpickerscreencaps.res into the Resource/ folder of the game or mod you are 
working on. If Hammer mounts content from the folder you copied it into, the 
Hammer model browser should be fine.

- Original Message - 
From: "Mike Durand" 
To: "Discussion of Half-Life Programming" 
Sent: Wednesday, June 17, 2009 8:06 PM
Subject: Re: [hlcoders] Source SDK Beta Concluded


> It was 'mdlpickerscreencaps.res'. We'll be fixing it for Ep2 and Portal 
> soon, but copying the file to the 'hl2/platform/Resource' directory should 
> get you going until then.
>
> -Mike
>
> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com 
> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Jonas 
> 'Sortie' Termansen
> Sent: Wednesday, June 17, 2009 10:17 AM
> To: Discussion of Half-Life Programming
> Subject: Re: [hlcoders] Source SDK Beta Concluded
>
> Which file is it?
>
>> Aw man I fixed this ages ago in my working copy, had I known that was the
>> problem I could have sent you guys that resource file a long time ago.
>> Sorry
>> guys :/
>>
>> Anyways for Portal and Ep2 it will probably work if you find the
>> appropriate
>> resource file in the TF2 cache and copy it into your Portal/Ep2 
>> directory.
>>
>> -- 
>> Jorge "Vino" Rodriguez
>> ___
>> 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] Source SDK Beta Concluded

[Jonas 'Sortie' Termansen]

Which file is it?

> Aw man I fixed this ages ago in my working copy, had I known that was the
> problem I could have sent you guys that resource file a long time ago. 
> Sorry
> guys :/
>
> Anyways for Portal and Ep2 it will probably work if you find the 
> appropriate
> resource file in the TF2 cache and copy it into your Portal/Ep2 directory.
>
> -- 
> Jorge "Vino" Rodriguez
> ___
> 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 Beta Concluded

[Jonas 'Sortie' Termansen]

Actually, a null pointer crash could mean a lot of things. Perhaps the code 
wasn't supposed to fail, becaues a null pointer would have ruined 
everything, so the bug is in a completely other place.

- Original Message - 
From: "Harry Jeffery" 
To: "Discussion of Half-Life Programming" 
Sent: Tuesday, June 16, 2009 8:08 PM
Subject: Re: [hlcoders] Source SDK Beta Concluded


Okay, good luck with it. My crash dump suggests a null pointer.
Someone forgot to check the pointer before using it methinks. Although
I could be bad at analysing crash dumps too.

2009/6/16 Mike Durand :
> I'm working on a fix right now. In the mean time please uncheck the "Use 
> VGUI Model Browser" checkbox in the Hammer General options.
>
> Sorry for the inconvenience.
>
> -Mike
>
> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com 
> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Matt Hoffman
> Sent: Tuesday, June 16, 2009 8:25 AM
> To: Discussion of Half-Life Programming
> Subject: Re: [hlcoders] Source SDK Beta Concluded
>
> Will our VGUI model browser be fixed?
>
> On Mon, Jun 15, 2009 at 11:59 PM, Tony Sergi 
> wrote:
>
>> When it comes to the source code.. No, I haven't submitted any of my 
>> fixes
>> yet. I haven't had time to finish that off.
>>
>>
>> -Tony
>>
>> -Original Message-
>> From: hlcoders-boun...@list.valvesoftware.com [mailto:
>> hlcoders-boun...@list.valvesoftware.com] On Behalf Of Joel R.
>> Sent: June-16-09 6:41 AM
>> To: Discussion of Half-Life Programming
>> Subject: Re: [hlcoders] Source SDK Beta Concluded
>>
>> Is there a changelog of changes to the SDK? I'm sure something was 
>> changed?
>>
>> On Mon, Jun 15, 2009 at 4:31 PM, Matt Hoffman
>> wrote:
>>
>> > >>Am I the only one that finds it ironic that you hate that the map
>> > >>sources are being released because people will "fix" them, but in
>> > >>the same email ask when the model sources will get releases so you 
>> > >>can
>> "fix"
>> > >>them? :)
>> >
>> > There is a difference between "fixing" the maps
>> > (arena_2fort_night_fixed_pro_b3) and my fixing of the characters. As
>> > it stands, the scout has been fixed. This fixing is not editing the
>> > model reference, It's re-compiling the characters with facial flexes
>> > so that I can do custom animations, *cough* machinima *cough* etc.
>> >
>> > The price I pay to not make 2bit machinima.
>> >
>> > On Mon, Jun 15, 2009 at 2:09 PM, Mike Durand > > >wrote:
>> >
>> > > Don't forget to do a 'Refresh SDK Content' from the SDK launcher.
>> > > Once
>> > you
>> > > do that they should show up for you.
>> > >
>> > > -Mike
>> > >
>> > > -Original Message-
>> > > From: hlcoders-boun...@list.valvesoftware.com [mailto:
>> > > hlcoders-boun...@list.valvesoftware.com] On Behalf Of Harry Jeffery
>> > > Sent: Monday, June 15, 2009 1:53 PM
>> > > To: Discussion of Half-Life Programming
>> > > Subject: Re: [hlcoders] Source SDK Beta Concluded
>> > >
>> > > Yeah, I'm loving the idea of releasing official map sources. =]
>> > >
>> > > Just cant find them. They're not in the mapsrc folder and the search
>> > > for .vmf returns nothing but prefabs.
>> > >
>> > > 2009/6/15 Saul Rennison :
>> > > > *shock horror*
>> > > >
>> > > > That's going to be absolutely amazing for all the TF2 mappers out
>> > there!
>> > > > Grats to the Valve team :)
>> > > >
>> > > > 2009/6/15 Mike Durand 
>> > > >
>> > > >> Hi All-
>> > > >>
>> > > >> Just wanted to give you a heads-up that the SDK Beta is over and
>> > > >> has
>> > > been
>> > > >> rolled into the Source SDK. Here are the release notes:
>> > > >>
>> > > >> -Added source files for ten shipping TF2 maps:
>> > > >> arena_lumberyard
>> > > >> arena_ravine
>> > > >> cp_badlands
>> > > >> cp_dustbowl
>> > > >> cp_granary
>> > > >> cp_gravelpit
>> > > >> ctf_2fort
>> > > >> pl_badwater
>> > > >> pl_goldrush
>> > > >> tc_hydro
>> > > >>
>> > > >> -Updated shadercompile binaries and added missing
>> > > >> DLL
>> > > needed
>> > > >> for shader compilation.
>> > > >>
>> > > >> -Mike
>> > > >> ___
>> > > >> To unsubscribe, edit your list preferences, or view the list
>> > > >> archives, please visit:
>> > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> > > >>
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > Thanks,
>> > > > - Saul.
>> > > > ___
>> > > > 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, pleas

Re: [hlcoders] Implementing head tracking

[Jonas 'Sortie' Termansen]

If you have any intelligence,

To unsubscribe, edit your list preferences, or view the list archives, 
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




- Original Message - 
From: "Joost van kempen" 
To: 
Sent: Sunday, June 14, 2009 5:01 PM
Subject: Re: [hlcoders] Implementing head tracking


>
> fuck this spam coder shitt get me off of it! ASAP!!
>
>> From: koribar...@hotmail.com
>> To: hlcoders@list.valvesoftware.com
>> Date: Sun, 14 Jun 2009 10:59:45 -0400
>> Subject: Re: [hlcoders] Implementing head tracking
>>
>> Probably because they're to lazy :P
>>
>> --
>> From: "Garry Newman" 
>> Sent: Sunday, June 14, 2009 10:58 AM
>> To: "Discussion of Half-Life Programming" 
>> 
>> Subject: Re: [hlcoders] Implementing head tracking
>>
>> > Woah! Why do people buy TrackIR if it's that simple?
>> > garry
>> >
>> > On Sun, Jun 14, 2009 at 3:39 PM, Harry Jeffery <
>> > harry101jeff...@googlemail.com> wrote:
>> >
>> >> http://www.youtube.com/watch?v=qWkpdtFZoBE
>> >> The code is on his site.
>> >>
>> >> 2009/6/14 Brent Lewis :
>> >> >
>> >> > I assume you guys are talking about head tracking for that cool 3D
>> >> > effect
>> >> like (jump to about 2:30) :
>> >> >
>> >> > http://www.youtube.com/watch?v=Jd3-eiid-Uw
>> >> >
>> >> > I was pretty intrigued by that whole thing. I'm curious though -
>> >> > doesn't
>> >> it require making a skewed frustum? I wouldn't have guessed the engine
>> >> allowed that much control over the rendering.
>> >> >
>> >> > I hope it works well for you. Good luck!
>> >> >
>> >> >> Date: Sun, 14 Jun 2009 09:44:51 -0400
>> >> >> From: steven.j.hender...@gmail.com
>> >> >> To: hlcoders@list.valvesoftware.com
>> >> >> Subject: Re: [hlcoders] Implementing head tracking
>> >> >>
>> >> >> To answer your specific questions:
>> >> >>
>> >> >> 1) We didn't find a place to just drop in our tracking device and 
>> >> >> have
>> >> >> it called every frame.  We had to modify quite a few methods in
>> >> >> in_main.cpp to tell the engine to either use our tracker (if 
>> >> >> enabled)
>> >> >> or fall back to the mouse.  Not a lot of code per se, just lots of
>> >> >> modification to exiting conditional statements.
>> >> >>
>> >> >> 2) When you position the player, you are moving the feet of the
>> >> >> player's model.  You will have to figure out the transformation 
>> >> >> from
>> >> >> the feet to the eyes (based on the model's eye height) to figure 
>> >> >> out
>> >> >> how to put the "camera" where the tracker is.  Also, changing the
>> >> >> player's orientation doesn't change the view orientation.  We found
>> >> >> that we had to change the player's orientation (angles) as well as 
>> >> >> the
>> >> >> engine's **ViewAngles** to get the behavior we need.
>> >> >>
>> >> >> Steve
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Sun, Jun 14, 2009 at 9:23 AM, Jan Frederick 
>> >> >> Eick
>> >> wrote:
>> >> >> > Hi there!
>> >> >> >
>> >> >> > For an experiment we are trying to implement headtracking. I'm a 
>> >> >> > bit
>> >> >> > lost in the source right now. I read the tutorial about 
>> >> >> > implementing
>> >> >> > a
>> >> >> > 3rd person view.
>> >> >> > This intent raises some questions.
>> >> >> >
>> >> >> > 1) the new "input device" (the tracking system) - is there a 
>> >> >> > method
>> >> >> > which gets called every frame in which we could fetch the data of
>> >> >> > the
>> >> >> > tracking device?
>> >> >> >
>> >> >> > 2) where is the difference in "changing the position of the 
>> >> >> > camera"
>> >> and
>> >> >> > "changing the position of the player"?
>> >> >> >
>> >> >> > I hope you guys get what I'm trying to express ;)
>> >> >> >
>> >> >> > Greets
>> >> >> >
>> >> >> > ___
>> >> >> > 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] Hint to new feature?

[Jonas 'Sortie' Termansen]

Third Party Games?

Someone wasn't around in the first versions of Steam.

- Original Message - 
From: "Harry Jeffery" 
To: "Discussion of Half-Life Programming" 
Sent: Saturday, June 13, 2009 12:39 PM
Subject: Re: [hlcoders] Hint to new feature?


Probably for steamworks mods only (insurgency, zp:s, etc.)

I look forward to steam3 and whatever new features and compatibilities
it has to offer.

2009/6/13 Yaakov Smith :
> From SDK Beta Gameinfo.txt (Scratch mod):
>
>
>
> "GameInfo"
>
> {
>
> // This is what shows up in the 'Third Party Games' area of
> the Steam games list.
>
>
>
> Is this a hint to new organisational features for steam?
>
> ___
> 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] Why did VALVe remove almost everything we gotinthenew SDK beta update?

[Jonas 'Sortie' Termansen]

Disregard my last email. I mixed up height2ssbump.exe with 
normal2ssbump.exe.

- Original Message - 
From: "Jonas 'Sortie' Termansen" 
To: "Discussion of Half-Life Programming" 
Sent: Saturday, June 13, 2009 11:34 AM
Subject: Re: [hlcoders] Why did VALVe remove almost everything we 
gotinthenew SDK beta update?


>I refreshed my Source SDK Content and I got the normal2ssbump.exe back
> yesterday, I don't know about the new update though.
>
> - Original Message - 
> From: "James K" 
> To: "Discussion of Half-Life Programming" 
> 
> Sent: Saturday, June 13, 2009 3:07 AM
> Subject: Re: [hlcoders] Why did VALVe remove almost everything we got
> inthenew SDK beta update?
>
>
>> Aww, another update and still no normal2ssbump :(
>>
>> James
>>
>> On Fri, Jun 12, 2009 at 7:08 PM, Jonas 'Sortie' Termansen
>> >> wrote:
>>
>>> Indeed, and all Europeans have to pay the same price in EUR too.
>>>
>>> - Original Message -
>>> From: "Yatin Vadhia" 
>>> To: "Discussion of Half-Life Programming"
>>> >> >
>>> Sent: Saturday, June 13, 2009 1:03 AM
>>> Subject: Re: [hlcoders] Why did VALVe remove almost everything we got in
>>> thenew SDK beta update?
>>>
>>>
>>> > Or  '99.99 in the UK due to the new rate of VAT applicable for non
>>> > physical products from 1st June.
>>> >
>>> > On 12 Jun 2009, at 23:56, "Adam \"amckern\" McKern"
>>> >  wrote:
>>> >
>>> >> :) I agree Jed - WTF's with 3x the price for us here?
>>> >>
>>> >> 
>>> >> Owner Nigredo Studios http://www.nigredostudios.com
>>> >>
>>> >> --- On Sat, 13/6/09, Jed  wrote:
>>> >>
>>> >> From: Jed 
>>> >> Subject: Re: [hlcoders] Why did VALVe remove almost everything we
>>> >> got in the new SDK beta update?
>>> >> To: "Discussion of Half-Life Programming"
>>> >> >> >> >
>>> >> Received: Saturday, 13 June, 2009, 8:25 AM
>>> >>
>>> >>> What's the deal VALVe? Don't want us to have tools that should be
>>> >>> publicly available?
>>> >>
>>> >> No. Now you have to buy them as DLC via Steam for the low low price 
>>> >> of
>>> >> $59.99 (or $129.99 if you live in Australia).
>>> >>
>>> >> :D
>>> >>
>>> >> ___
>>> >> To unsubscribe, edit your list preferences, or view the list
>>> >> archives, please visit:
>>> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>  Need a Holiday? Win a $10,000 Holiday of your choice. Enter
>>> >> now.http://us.lrd.yahoo.com/
>>> >> _ylc=
>>> >>
>>> X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg-
>>> >> -/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/
>>> >> creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other
>>> >> %26p2=au%26p3=mailtagline
>>> >> ___
>>> >> 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] Why did VALVe remove almost everything we got inthenew SDK beta update?

[Jonas 'Sortie' Termansen]

I refreshed my Source SDK Content and I got the normal2ssbump.exe back 
yesterday, I don't know about the new update though.

- Original Message - 
From: "James K" 
To: "Discussion of Half-Life Programming" 
Sent: Saturday, June 13, 2009 3:07 AM
Subject: Re: [hlcoders] Why did VALVe remove almost everything we got 
inthenew SDK beta update?


> Aww, another update and still no normal2ssbump :(
>
> James
>
> On Fri, Jun 12, 2009 at 7:08 PM, Jonas 'Sortie' Termansen 
> > wrote:
>
>> Indeed, and all Europeans have to pay the same price in EUR too.
>>
>> - Original Message -
>> From: "Yatin Vadhia" 
>> To: "Discussion of Half-Life Programming" 
>> > >
>> Sent: Saturday, June 13, 2009 1:03 AM
>> Subject: Re: [hlcoders] Why did VALVe remove almost everything we got in
>> thenew SDK beta update?
>>
>>
>> > Or  '99.99 in the UK due to the new rate of VAT applicable for non
>> > physical products from 1st June.
>> >
>> > On 12 Jun 2009, at 23:56, "Adam \"amckern\" McKern"
>> >  wrote:
>> >
>> >> :) I agree Jed - WTF's with 3x the price for us here?
>> >>
>> >> 
>> >> Owner Nigredo Studios http://www.nigredostudios.com
>> >>
>> >> --- On Sat, 13/6/09, Jed  wrote:
>> >>
>> >> From: Jed 
>> >> Subject: Re: [hlcoders] Why did VALVe remove almost everything we
>> >> got in the new SDK beta update?
>> >> To: "Discussion of Half-Life Programming"
>> >> > >> >
>> >> Received: Saturday, 13 June, 2009, 8:25 AM
>> >>
>> >>> What's the deal VALVe? Don't want us to have tools that should be
>> >>> publicly available?
>> >>
>> >> No. Now you have to buy them as DLC via Steam for the low low price of
>> >> $59.99 (or $129.99 if you live in Australia).
>> >>
>> >> :D
>> >>
>> >> ___
>> >> To unsubscribe, edit your list preferences, or view the list
>> >> archives, please visit:
>> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >>
>> >>
>> >>
>> >>
>> >>  Need a Holiday? Win a $10,000 Holiday of your choice. Enter
>> >> now.http://us.lrd.yahoo.com/
>> >> _ylc=
>> >>
>> X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg-
>> >> -/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/
>> >> creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other
>> >> %26p2=au%26p3=mailtagline
>> >> ___
>> >> 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] Why did VALVe remove almost everything we got in thenew SDK beta update?

[Jonas 'Sortie' Termansen]

Indeed, and all Europeans have to pay the same price in EUR too.

- Original Message - 
From: "Yatin Vadhia" 
To: "Discussion of Half-Life Programming" 
Sent: Saturday, June 13, 2009 1:03 AM
Subject: Re: [hlcoders] Why did VALVe remove almost everything we got in 
thenew SDK beta update?


> Or '99.99 in the UK due to the new rate of VAT applicable for non
> physical products from 1st June.
>
> On 12 Jun 2009, at 23:56, "Adam \"amckern\" McKern"
>  wrote:
>
>> :) I agree Jed - WTF's with 3x the price for us here?
>>
>> 
>> Owner Nigredo Studios http://www.nigredostudios.com
>>
>> --- On Sat, 13/6/09, Jed  wrote:
>>
>> From: Jed 
>> Subject: Re: [hlcoders] Why did VALVe remove almost everything we
>> got in the new SDK beta update?
>> To: "Discussion of Half-Life Programming" 
>> > >
>> Received: Saturday, 13 June, 2009, 8:25 AM
>>
>>> What's the deal VALVe? Don't want us to have tools that should be
>>> publicly available?
>>
>> No. Now you have to buy them as DLC via Steam for the low low price of
>> $59.99 (or $129.99 if you live in Australia).
>>
>> :D
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>>
>>
>>  Need a Holiday? Win a $10,000 Holiday of your choice. Enter
>> now.http://us.lrd.yahoo.com/
>> _ylc=
>> X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg-
>> -/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/
>> creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other
>> %26p2=au%26p3=mailtagline
>> ___
>> 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] Why did VALVe remove almost everything we got in thenew SDK beta update?

[Jonas 'Sortie' Termansen]

Fix:

Refresh your SDK Content.

The new tools won't be available though, unless somebody managed to get a 
copy while possible. 


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] Why did VALVe remove almost everything we got in thenew SDK beta update?

[Jonas 'Sortie' Termansen]

Hmm, don't we still have the sources for some of the most used compiling 
tools, and probably backups of the tools somewhere. But this whole business 
is weird.

- Original Message - 
From: "Saul Rennison" 
To: "Discussion of Half-Life Programming" 
Sent: Friday, June 12, 2009 11:20 PM
Subject: Re: [hlcoders] Why did VALVe remove almost everything we got in 
thenew SDK beta update?


> "they must just think you had too much stuff in your OB bin folder 
> already"
>
> That's like Valve removing a load of it's APIs because they thought they
> were too many.
>
> 2009/6/12 Andrew Ritchie 
>
>> At the end of the day isn't it Valve who get to decide what tools 
>> "should"
>> be publically available? They might have their reasons or they must just
>> think you had too much stuff in your OB bin folder already.
>>
>> On Fri, Jun 12, 2009 at 10:02 PM, James K  wrote:
>>
>> > About 2 hours ago we got an update to the SDK beta that included new
>> > programs like normal2ssbump.exe and a few others, but then a patch
>> released
>> > minutes after removed that and almost 90% of the stuff in my orangebox
>> bin
>> > folder. What's the deal VALVe? Don't want us to have tools that should 
>> > be
>> > publicly available?
>> > ___
>> > 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
>>
>>
>
>
> -- 
> Thanks,
> - Saul.
> ___
> 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