Re: [hlcoders] Possable Improvements to the Source SDK

[Saul Rennison]

Good response, Tony. Just wondering if you're in a position to answer  
any other of the questions?

Thanks,
- Saul.

On 30 Aug 2009, at 03:00, Tony Sergi  wrote:

> I'm going to answer one of the things directly right now;
> I already made it super easy to add new weapons as it is (with the  
> template)
> You copy and paste 2 files, rename the class and edit the attributes  
> in the .txt file, edit the enum and the alias table.
>
> And if you want a custom ammo type, you just copy and paste another  
> ammo type in sdk_gamerules.cpp and you're done.
>
> It's kind of faster to add 5 new weapons at once than it is to just  
> add one, too actually.
>
> -Tony
>
> ___
> 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] Creating a Custom Player Class

[Bob Somers]

Issue solved. Here's the fix for the sake of the mailing list archives.

On first glance it looks like the assertion is raised because the
factory does not exist. Actually, it's raised because a factory for
that entity *already* exists.

This is because CSDKPlayer and C_SDKPlayer are linking themselves to
the "player" entity, with the LINK_ENTITY_TO_CLASS() macro, which
creates the factory. When you do this in your derived class, it can't
create the factory because CSDKPlayer already did.

The solution?

Comment out the LINK_ENTITY_TO_CLASS() macro in both CSDKPlayer and
C_SDKPlayer (sdk_player.cpp and c_sdk_player.cpp).

Now only your derived player class will create the factory and
happiness will ensue.

--Bob





On Sat, Aug 29, 2009 at 6:11 PM, Bob Somers wrote:
> Yep. It also looks like LINK_ENTITY_TO_CLASS is the macro that creates
> the factory.
>
> --Bob
>
>
>
>
> On Sat, Aug 29, 2009 at 6:06 PM, Jonathan Murphy 
> wrote:
>> After looking on the SDK do you have
>>
>> DECLARE_CLASS(CMyPlayer, CSDKPlayer);
>>
>> In the header declaration.
>>
>> On Sunday, August 30, 2009, Jonathan Murphy  wrote:
>>> I don't have an SDK with me but there should be a set of macros used
>>> to declare a factory for new entities.
>>>
>>> On Sunday, August 30, 2009, Bob Somers  wrote:
 So just do a global find/replace on CSDKPlayer to CMyPlayer?

 --Bob



 On Sat, Aug 29, 2009 at 5:35 PM, Stephen Swires 
 wrote:
> The official way to do this with the template is to copy all the SDK stuff
> and rename it to what you want
>
> On Sun, Aug 30, 2009 at 1:31 AM, Bob Somers  wrote:
>
>> Hello all.
>>
>> So I'm trying to create a custom player by deriving it from CSDKPlayer,
>> like so:
>>
>> class CMyPlayer : public CSDKPlayer
>> {
>>   // player things
>> };
>>
>> I've got both the server and client players skeleton class build, I've
>> linked the class to the player entity with LINK_ENTITY_TO_CLASS, and
>> setup a simple send/recv table that just networks one boolean
>> temporarily.
>>
>> Lastly, I edited the _client.cpp file to instantiate a an instance of
>> my CMyPlayer class instead of CSDKPlayer when creating new players.
>>
>> However, now when I run the mod I break at an assertion:
>>
>> File: game\server\util.cpp
>> Line: 144
>> Assertion Failed: FindFactory(pClassName) == NULL
>>
>> I looked into it a bit and it looks the server keeps a dictionary of
>> entity factories for producing entities of certain types. My guess is
>> that it can't find a factory to build my custom player class. I tried
>> looking for an example of building a CEntityFactory for it, but
>> couldn't find anything. Is this something I need to build myself and
>> call InstallFactory(), or should one of the macros be creating that?
>>
>> Lastly, am I doing something horribly wrong? i.e. should not be
>> subclassing CSDKPlayer? Thanks.
>>
>> --Bob
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
>
> --
> - Stephen Swires
> ___
> 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


>>>
>>> --
>>> Programmer for Resistance and Liberation
>>> http://www.resistanceandliberation.com
>>> Programmer for Red Tribe
>>> http://www.redtribe.com
>>>
>>
>> --
>> Programmer for Resistance and Liberation
>> www.resistanceandliberation.com
>> Programmer for Red Tribe
>> www.redtribe.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] Possable Improvements to the Source SDK

[Tony Sergi]

I'm going to answer one of the things directly right now;
I already made it super easy to add new weapons as it is (with the template)
You copy and paste 2 files, rename the class and edit the attributes in the 
.txt file, edit the enum and the alias table.

And if you want a custom ammo type, you just copy and paste another ammo type 
in sdk_gamerules.cpp and you're done.

It's kind of faster to add 5 new weapons at once than it is to just add one, 
too actually.

-Tony

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

Re: [hlcoders] Creating a Custom Player Class

[Bob Somers]

Yep. It also looks like LINK_ENTITY_TO_CLASS is the macro that creates
the factory.

--Bob




On Sat, Aug 29, 2009 at 6:06 PM, Jonathan Murphy wrote:
> After looking on the SDK do you have
>
> DECLARE_CLASS(CMyPlayer, CSDKPlayer);
>
> In the header declaration.
>
> On Sunday, August 30, 2009, Jonathan Murphy  wrote:
>> I don't have an SDK with me but there should be a set of macros used
>> to declare a factory for new entities.
>>
>> On Sunday, August 30, 2009, Bob Somers  wrote:
>>> So just do a global find/replace on CSDKPlayer to CMyPlayer?
>>>
>>> --Bob
>>>
>>>
>>>
>>> On Sat, Aug 29, 2009 at 5:35 PM, Stephen Swires 
>>> wrote:
 The official way to do this with the template is to copy all the SDK stuff
 and rename it to what you want

 On Sun, Aug 30, 2009 at 1:31 AM, Bob Somers  wrote:

> Hello all.
>
> So I'm trying to create a custom player by deriving it from CSDKPlayer,
> like so:
>
> class CMyPlayer : public CSDKPlayer
> {
>   // player things
> };
>
> I've got both the server and client players skeleton class build, I've
> linked the class to the player entity with LINK_ENTITY_TO_CLASS, and
> setup a simple send/recv table that just networks one boolean
> temporarily.
>
> Lastly, I edited the _client.cpp file to instantiate a an instance of
> my CMyPlayer class instead of CSDKPlayer when creating new players.
>
> However, now when I run the mod I break at an assertion:
>
> File: game\server\util.cpp
> Line: 144
> Assertion Failed: FindFactory(pClassName) == NULL
>
> I looked into it a bit and it looks the server keeps a dictionary of
> entity factories for producing entities of certain types. My guess is
> that it can't find a factory to build my custom player class. I tried
> looking for an example of building a CEntityFactory for it, but
> couldn't find anything. Is this something I need to build myself and
> call InstallFactory(), or should one of the macros be creating that?
>
> Lastly, am I doing something horribly wrong? i.e. should not be
> subclassing CSDKPlayer? Thanks.
>
> --Bob
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>


 --
 - Stephen Swires
 ___
 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
>>>
>>>
>>
>> --
>> Programmer for Resistance and Liberation
>> http://www.resistanceandliberation.com
>> Programmer for Red Tribe
>> http://www.redtribe.com
>>
>
> --
> Programmer for Resistance and Liberation
> www.resistanceandliberation.com
> Programmer for Red Tribe
> www.redtribe.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] Creating a Custom Player Class

[Jonathan Murphy]

After looking on the SDK do you have

DECLARE_CLASS(CMyPlayer, CSDKPlayer);

In the header declaration.

On Sunday, August 30, 2009, Jonathan Murphy  wrote:
> I don't have an SDK with me but there should be a set of macros used
> to declare a factory for new entities.
>
> On Sunday, August 30, 2009, Bob Somers  wrote:
>> So just do a global find/replace on CSDKPlayer to CMyPlayer?
>>
>> --Bob
>>
>>
>>
>> On Sat, Aug 29, 2009 at 5:35 PM, Stephen Swires 
>> wrote:
>>> The official way to do this with the template is to copy all the SDK stuff
>>> and rename it to what you want
>>>
>>> On Sun, Aug 30, 2009 at 1:31 AM, Bob Somers  wrote:
>>>
 Hello all.

 So I'm trying to create a custom player by deriving it from CSDKPlayer,
 like so:

 class CMyPlayer : public CSDKPlayer
 {
   // player things
 };

 I've got both the server and client players skeleton class build, I've
 linked the class to the player entity with LINK_ENTITY_TO_CLASS, and
 setup a simple send/recv table that just networks one boolean
 temporarily.

 Lastly, I edited the _client.cpp file to instantiate a an instance of
 my CMyPlayer class instead of CSDKPlayer when creating new players.

 However, now when I run the mod I break at an assertion:

 File: game\server\util.cpp
 Line: 144
 Assertion Failed: FindFactory(pClassName) == NULL

 I looked into it a bit and it looks the server keeps a dictionary of
 entity factories for producing entities of certain types. My guess is
 that it can't find a factory to build my custom player class. I tried
 looking for an example of building a CEntityFactory for it, but
 couldn't find anything. Is this something I need to build myself and
 call InstallFactory(), or should one of the macros be creating that?

 Lastly, am I doing something horribly wrong? i.e. should not be
 subclassing CSDKPlayer? Thanks.

 --Bob

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


>>>
>>>
>>> --
>>> - Stephen Swires
>>> ___
>>> 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
>>
>>
>
> --
> Programmer for Resistance and Liberation
> http://www.resistanceandliberation.com
> Programmer for Red Tribe
> http://www.redtribe.com
>

-- 
Programmer for Resistance and Liberation
www.resistanceandliberation.com
Programmer for Red Tribe
www.redtribe.com

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

Re: [hlcoders] Creating a Custom Player Class

[Jonathan Murphy]

I don't have an SDK with me but there should be a set of macros used
to declare a factory for new entities.

On Sunday, August 30, 2009, Bob Somers  wrote:
> So just do a global find/replace on CSDKPlayer to CMyPlayer?
>
> --Bob
>
>
>
> On Sat, Aug 29, 2009 at 5:35 PM, Stephen Swires 
> wrote:
>> The official way to do this with the template is to copy all the SDK stuff
>> and rename it to what you want
>>
>> On Sun, Aug 30, 2009 at 1:31 AM, Bob Somers  wrote:
>>
>>> Hello all.
>>>
>>> So I'm trying to create a custom player by deriving it from CSDKPlayer,
>>> like so:
>>>
>>> class CMyPlayer : public CSDKPlayer
>>> {
>>>   // player things
>>> };
>>>
>>> I've got both the server and client players skeleton class build, I've
>>> linked the class to the player entity with LINK_ENTITY_TO_CLASS, and
>>> setup a simple send/recv table that just networks one boolean
>>> temporarily.
>>>
>>> Lastly, I edited the _client.cpp file to instantiate a an instance of
>>> my CMyPlayer class instead of CSDKPlayer when creating new players.
>>>
>>> However, now when I run the mod I break at an assertion:
>>>
>>> File: game\server\util.cpp
>>> Line: 144
>>> Assertion Failed: FindFactory(pClassName) == NULL
>>>
>>> I looked into it a bit and it looks the server keeps a dictionary of
>>> entity factories for producing entities of certain types. My guess is
>>> that it can't find a factory to build my custom player class. I tried
>>> looking for an example of building a CEntityFactory for it, but
>>> couldn't find anything. Is this something I need to build myself and
>>> call InstallFactory(), or should one of the macros be creating that?
>>>
>>> Lastly, am I doing something horribly wrong? i.e. should not be
>>> subclassing CSDKPlayer? Thanks.
>>>
>>> --Bob
>>>
>>> ___
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>>
>>
>>
>> --
>> - Stephen Swires
>> ___
>> 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
>
>

-- 
Programmer for Resistance and Liberation
www.resistanceandliberation.com
Programmer for Red Tribe
www.redtribe.com

___
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

[Joshua Scarsbrook]

How.

Thanks
Vbitz

Jonathan Murphy wrote:
> Lol, obvious troll, nice one Joshua.
>
> On Sunday, August 30, 2009, Jonas 'Sortie' Termansen  
> wrote:
>   
>> 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
>>
>>
>> 
>
>   


___
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

[Jonathan Murphy]

Lol, obvious troll, nice one Joshua.

On Sunday, August 30, 2009, Jonas 'Sortie' Termansen  wrote:
> 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
>
>

-- 
Programmer for Resistance and Liberation
www.resistanceandliberation.com
Programmer for Red Tribe
www.redtribe.com

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

Re: [hlcoders] Creating a Custom Player Class

[Bob Somers]

So just do a global find/replace on CSDKPlayer to CMyPlayer?

--Bob



On Sat, Aug 29, 2009 at 5:35 PM, Stephen Swires wrote:
> The official way to do this with the template is to copy all the SDK stuff
> and rename it to what you want
>
> On Sun, Aug 30, 2009 at 1:31 AM, Bob Somers  wrote:
>
>> Hello all.
>>
>> So I'm trying to create a custom player by deriving it from CSDKPlayer,
>> like so:
>>
>> class CMyPlayer : public CSDKPlayer
>> {
>>   // player things
>> };
>>
>> I've got both the server and client players skeleton class build, I've
>> linked the class to the player entity with LINK_ENTITY_TO_CLASS, and
>> setup a simple send/recv table that just networks one boolean
>> temporarily.
>>
>> Lastly, I edited the _client.cpp file to instantiate a an instance of
>> my CMyPlayer class instead of CSDKPlayer when creating new players.
>>
>> However, now when I run the mod I break at an assertion:
>>
>> File: game\server\util.cpp
>> Line: 144
>> Assertion Failed: FindFactory(pClassName) == NULL
>>
>> I looked into it a bit and it looks the server keeps a dictionary of
>> entity factories for producing entities of certain types. My guess is
>> that it can't find a factory to build my custom player class. I tried
>> looking for an example of building a CEntityFactory for it, but
>> couldn't find anything. Is this something I need to build myself and
>> call InstallFactory(), or should one of the macros be creating that?
>>
>> Lastly, am I doing something horribly wrong? i.e. should not be
>> subclassing CSDKPlayer? Thanks.
>>
>> --Bob
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>
>
> --
> - Stephen Swires
> ___
> 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] Creating a Custom Player Class

[Stephen Swires]

The official way to do this with the template is to copy all the SDK stuff
and rename it to what you want

On Sun, Aug 30, 2009 at 1:31 AM, Bob Somers  wrote:

> Hello all.
>
> So I'm trying to create a custom player by deriving it from CSDKPlayer,
> like so:
>
> class CMyPlayer : public CSDKPlayer
> {
>   // player things
> };
>
> I've got both the server and client players skeleton class build, I've
> linked the class to the player entity with LINK_ENTITY_TO_CLASS, and
> setup a simple send/recv table that just networks one boolean
> temporarily.
>
> Lastly, I edited the _client.cpp file to instantiate a an instance of
> my CMyPlayer class instead of CSDKPlayer when creating new players.
>
> However, now when I run the mod I break at an assertion:
>
> File: game\server\util.cpp
> Line: 144
> Assertion Failed: FindFactory(pClassName) == NULL
>
> I looked into it a bit and it looks the server keeps a dictionary of
> entity factories for producing entities of certain types. My guess is
> that it can't find a factory to build my custom player class. I tried
> looking for an example of building a CEntityFactory for it, but
> couldn't find anything. Is this something I need to build myself and
> call InstallFactory(), or should one of the macros be creating that?
>
> Lastly, am I doing something horribly wrong? i.e. should not be
> subclassing CSDKPlayer? Thanks.
>
> --Bob
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>


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

[hlcoders] Creating a Custom Player Class

[Bob Somers]

Hello all.

So I'm trying to create a custom player by deriving it from CSDKPlayer, like so:

class CMyPlayer : public CSDKPlayer
{
   // player things
};

I've got both the server and client players skeleton class build, I've
linked the class to the player entity with LINK_ENTITY_TO_CLASS, and
setup a simple send/recv table that just networks one boolean
temporarily.

Lastly, I edited the _client.cpp file to instantiate a an instance of
my CMyPlayer class instead of CSDKPlayer when creating new players.

However, now when I run the mod I break at an assertion:

File: game\server\util.cpp
Line: 144
Assertion Failed: FindFactory(pClassName) == NULL

I looked into it a bit and it looks the server keeps a dictionary of
entity factories for producing entities of certain types. My guess is
that it can't find a factory to build my custom player class. I tried
looking for an example of building a CEntityFactory for it, but
couldn't find anything. Is this something I need to build myself and
call InstallFactory(), or should one of the macros be creating that?

Lastly, am I doing something horribly wrong? i.e. should not be
subclassing CSDKPlayer? Thanks.

--Bob

___
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] Possable Improvements to the Source SDK

[Harry Pidcock]

Joshua can you please edit your messages so people may understand correctly 
what you are doing.

People will generally ignore your messages if they are too hard to 
interpret.

--
From: "Joshua Scarsbrook" 
Sent: Sunday, August 30, 2009 9:18 AM
To: "Discussion of Half-Life Programming" 
Subject: Re: [hlcoders] Possable Improvements to the Source SDK

> A proper complete source document buld is done but it crashes some
> places and the html set is 151mb or 172,208,128 bytes, that is bigger
> then most mods it is as big as sourceforts or hl2dmpro or garrysmod 9
> but it is some nice documets on the coding. i am now compressing it to
> only 17mb though. if valve says yes then i will put it somewere.
>
> Matt Hoffman wrote:
>> It worked fine on my Intel/Geforce XP build, but does the problem you
>> describe on my AMD/ATI Win7 build.
>>
>> On Sat, Aug 29, 2009 at 4:04 PM, Jorge Rodriguez  
>> wrote:
>>
>>
>>> 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
>
>



>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.71/2334 - Release Date: 08/29/09 
> 17:51:00
> 

___
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

[Saul Rennison]

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

Re: [hlcoders] Possable Improvements to the Source SDK

[Joshua Scarsbrook]

A proper complete source document buld is done but it crashes some 
places and the html set is 151mb or 172,208,128 bytes, that is bigger 
then most mods it is as big as sourceforts or hl2dmpro or garrysmod 9 
but it is some nice documets on the coding. i am now compressing it to 
only 17mb though. if valve says yes then i will put it somewere.

Matt Hoffman wrote:
> It worked fine on my Intel/Geforce XP build, but does the problem you
> describe on my AMD/ATI Win7 build.
>
> On Sat, Aug 29, 2009 at 4:04 PM, Jorge Rodriguez  wrote:
>
>   
>> 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] Possable Improvements to the Source SDK

[Matt Hoffman]

It worked fine on my Intel/Geforce XP build, but does the problem you
describe on my AMD/ATI Win7 build.

On Sat, Aug 29, 2009 at 4:04 PM, Jorge Rodriguez  wrote:

> 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

Re: [hlcoders] Possable Improvements to the Source SDK

[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

Re: [hlcoders] Possable Improvements to the Source SDK

[Joshua Scarsbrook]

Well unreal 3 is not source good but it is not half bad
finaly i got the doc genned
for only the files valve added documentation too
400mb for 40files
the html was only 1mb though.
anyway valve sould put this with the sdk so it still needs hl2 to work

Matt Hoffman wrote:
>>> We'll see how pretty Episode 3 is when it's released. It will blow UE3 out
>>> of the fucking water.
>>>   
>
> (I still dunno how to do a quote :p)
>
> Why wait for Ep3 when Ep2 already blows UE3 out of the water? If you look at
> most UT mods you can recognize them in a snap as a Ut mod for one reason.
> Their bump/normals look incredibly fugly/odd and I can tell almost any UE3
> mod from it. It's also very brown and generic, least as far as Gears of War,
> UT3, etc. Mirrors Edge is an exception but it's also liscenced from Unreal
> and not made by them.
>
> On Sat, Aug 29, 2009 at 3:36 PM, Joshua Scarsbrook 
> wrote:
>
>   
>> Well the doc is almost done.
>> Lighting RENDER, not really just real time
>> the compile map is good and a bar is not too hard to make since valve
>> was so kind as to give us the source for the compile apps
>> added stuff. we need the maps to work for alot of people, i have seen
>> ugly custom texture problems
>> and the wiki, working on it right now
>> and finaly  adding directx 10 to source would be wonderful but i think
>> that thay are doing that for ep3 and lfd2
>>
>> Thanks for all the coments
>>  Vbitz
>>
>> p.s. i have alot of stuff to work on and you are almost the first to
>> complain on my grammer, no offence
>> p.s.s. thunderbird likes my spelling and sending it to word would take
>> to long
>>
>> Harry Jeffery wrote:
>> 
>>> Well please run a spellcheck on it, format it into neat paragraphs and
>>> get someone to proof read it before you post it.
>>>
>>> That first message here nearly killed me.
>>>
>>>
>>>   
> The lighting is not as it is seen inside the engine when you use that
>
>   
>>> That's probably because your computer really wouldn't be able to
>>> calculate the lightmaps in realtime. What do you think vrad spends
>>> those minutes doing?
>>>
>>>
>>>   
> The progruss bar needs to show total progruss
>
>   
>>> Once you know the process of compiling a map you can easily tell how
>>> far through you are. I can at least. No need for a progress bar.
>>>
>>>
>>>   
> Profiles are to test weather the map will work without added stuff.
>
>   
>>> Why would you even want the map to work without added stuff? That's
>>> what modding is about. ADDING STUFF.
>>>
>>>
>>>   
> Players fitting under the leage is something that needs alot of testing
>
>   
>>> normaly
>>> Err no, It's like 58 or 64 units isn't it? It can be measured in hammer
>>>   
>> easily.
>> 
>>>   
> finaly the wiki needs more coding documatasion
>
>   
>>> Sure it does, but that's not valve's no.1 priority. Why don't you go
>>> out there, learn the source engine and add some useful stuff to it
>>> yourself?
>>>
>>>
>>>   
> also thay do not keep braking ours, thay use a seprate copy that has
>   
>> direct links with true engine heders.
>> 
>>> Well actually wait what??? Nope, we have the same thing they do.
>>> We just don't get access to the engine itself. We have everything we
>>> need to make a game like TF2/L4D without engine access anyways.
>>>
>>>
>>> Tony,
>>> I for one am actually satisfied with the source SDK, you're doing a
>>> great job. The only thing I'd like in future is for valve to add more
>>> functionality to the engine itself. Dynamic model scaling, DirectX 10
>>> support and other stuff that would put the engine at a commercial and
>>> featurewise par with UE3 and thus earn more licenses and more money
>>> for valve in future and give valve greater resources to keep improving
>>> the engine.
>>>
>>> 2009/8/29 Joshua Scarsbrook :
>>>
>>>   
 Hi

 Well the only other engine i liked is irrlicht but source is much beter
 for indie projects. i hope valve does not mind that i am making my own
 help file for the sdk, it will take forever to make but it will be
 preaty cool, it is working right now. with the ok from valve i will put
 it on the Valve Devlopers Wiki.

 Hope theres no repeat of last time
 Thanks Vbitz


 Logan Baldock wrote:

 
> Meh, I like it the way it is actually. I got into modding using the
>   
>> same
>> 
> methods that are there right now, and it just works. Unlike some other
> engines.
>
>
>   
>> You also have to take into account VALVe's priorities are:
>>
>>1. VALVe
>>2. Everyone else
>>
>> The Source SDK is basically just ripped from their *src/* folder which
>> contains the engine, VPhysics, Havok, etc. They aren't going to
>> 
>> re-organise
>> 
>>>

Re: [hlcoders] Possable Improvements to the Source SDK

[Joshua Scarsbrook]

Well dinamic prop scaling works well for cubes but valves phys is a 
little ficle with different scales
DirectX 10 is well worth it but it needs be put in something like a mod 
to the lost coust first
Unreal Engine 3 is a really good engine from what i have seen but source 
is valves thing and having a powerful engine is not what thay want. 
there main goal for the engine is making good games not flashey ones
Anyway the SDK we use is powerful and the first cs was made with the 
goldsrc version.
Valve has alot on there plate right now and my ideas where some things 
for when thay get some extra time.
And the Doc is done :)

Thanks
Vbitz

Saul Rennison wrote:
>> Dynamic model scaling
>> 
>
> http://developer.valvesoftware.com/wiki/Prop_scalable
>
>
>   
>> DirectX 10 support
>> 
>
> The shader system supports it... it just doesn't implement it. What
> improvements would this bring that would be worth the money it would cost to
> implement?
>
>
>   
>> featurewise par with UE3
>> 
>
> I'm pretty darn sure that that isn't VALVe's main goal. The engine is purely
> for their game-creating needs, they've only had a handful of licensees IIRC.
> Doesn't Source Engine have a greater MOD community than UE3? It definately
> had a bigger fan-base / players.
>
>
>   
>> and thus earn more licenses and more money for valve in future and give
>> valve greater resources to keep improving the engine.
>> 
>
> We'll see how pretty Episode 3 is when it's released. It will blow UE3 out
> of the fucking water.
>
> Thanks,
> - Saul.
>
>
> 2009/8/29 Harry Jeffery 
>
>   
>> Well please run a spellcheck on it, format it into neat paragraphs and
>> get someone to proof read it before you post it.
>>
>> That first message here nearly killed me.
>>
>>
>> 
 The lighting is not as it is seen inside the engine when you use that
 
>> That's probably because your computer really wouldn't be able to
>> calculate the lightmaps in realtime. What do you think vrad spends
>> those minutes doing?
>>
>> 
 The progruss bar needs to show total progruss
 
>> Once you know the process of compiling a map you can easily tell how
>> far through you are. I can at least. No need for a progress bar.
>>
>> 
 Profiles are to test weather the map will work without added stuff.
 
>> Why would you even want the map to work without added stuff? That's
>> what modding is about. ADDING STUFF.
>>
>> 
 Players fitting under the leage is something that needs alot of testing
 
>> normaly
>> Err no, It's like 58 or 64 units isn't it? It can be measured in hammer
>> easily.
>>
>> 
 finaly the wiki needs more coding documatasion
 
>> Sure it does, but that's not valve's no.1 priority. Why don't you go
>> out there, learn the source engine and add some useful stuff to it
>> yourself?
>>
>> 
 also thay do not keep braking ours, thay use a seprate copy that has
 
>> direct links with true engine heders.
>> Well actually wait what??? Nope, we have the same thing they do.
>> We just don't get access to the engine itself. We have everything we
>> need to make a game like TF2/L4D without engine access anyways.
>>
>>
>> Tony,
>> I for one am actually satisfied with the source SDK, you're doing a
>> great job. The only thing I'd like in future is for valve to add more
>> functionality to the engine itself. Dynamic model scaling, DirectX 10
>> support and other stuff that would put the engine at a commercial and
>> featurewise par with UE3 and thus earn more licenses and more money
>> for valve in future and give valve greater resources to keep improving
>> the engine.
>>
>> 2009/8/29 Joshua Scarsbrook :
>> 
>>> Hi
>>>
>>> Well the only other engine i liked is irrlicht but source is much beter
>>> for indie projects. i hope valve does not mind that i am making my own
>>> help file for the sdk, it will take forever to make but it will be
>>> preaty cool, it is working right now. with the ok from valve i will put
>>> it on the Valve Devlopers Wiki.
>>>
>>> Hope theres no repeat of last time
>>> Thanks Vbitz
>>>
>>>
>>> Logan Baldock wrote:
>>>   
 Meh, I like it the way it is actually. I got into modding using the same
 methods that are there right now, and it just works. Unlike some other
 engines.

 
> You also have to take into account VALVe's priorities are:
>
>1. VALVe
>2. Everyone else
>
> The Source SDK is basically just ripped from their *src/* folder which
> contains the engine, VPhysics, Havok, etc. They aren't going to
>   
>> re-organise
>> 
> the entire code base just to suit 20 people who want to save 1 hour per
>   
>> week
>> 
> with the improvement it results in.
> Thanks,
> - Saul.
>
>
> 2009/8/29 Paul Peloski 
>
>
>
>   
>> The SDK is improving all the time, but only to

Re: [hlcoders] Possable Improvements to the Source SDK

[Matt Hoffman]

>>We'll see how pretty Episode 3 is when it's released. It will blow UE3 out
>>of the fucking water.

(I still dunno how to do a quote :p)

Why wait for Ep3 when Ep2 already blows UE3 out of the water? If you look at
most UT mods you can recognize them in a snap as a Ut mod for one reason.
Their bump/normals look incredibly fugly/odd and I can tell almost any UE3
mod from it. It's also very brown and generic, least as far as Gears of War,
UT3, etc. Mirrors Edge is an exception but it's also liscenced from Unreal
and not made by them.

On Sat, Aug 29, 2009 at 3:36 PM, Joshua Scarsbrook wrote:

> Well the doc is almost done.
> Lighting RENDER, not really just real time
> the compile map is good and a bar is not too hard to make since valve
> was so kind as to give us the source for the compile apps
> added stuff. we need the maps to work for alot of people, i have seen
> ugly custom texture problems
> and the wiki, working on it right now
> and finaly  adding directx 10 to source would be wonderful but i think
> that thay are doing that for ep3 and lfd2
>
> Thanks for all the coments
>  Vbitz
>
> p.s. i have alot of stuff to work on and you are almost the first to
> complain on my grammer, no offence
> p.s.s. thunderbird likes my spelling and sending it to word would take
> to long
>
> Harry Jeffery wrote:
> > Well please run a spellcheck on it, format it into neat paragraphs and
> > get someone to proof read it before you post it.
> >
> > That first message here nearly killed me.
> >
> >
> >>> The lighting is not as it is seen inside the engine when you use that
> >>>
> > That's probably because your computer really wouldn't be able to
> > calculate the lightmaps in realtime. What do you think vrad spends
> > those minutes doing?
> >
> >
> >>> The progruss bar needs to show total progruss
> >>>
> > Once you know the process of compiling a map you can easily tell how
> > far through you are. I can at least. No need for a progress bar.
> >
> >
> >>> Profiles are to test weather the map will work without added stuff.
> >>>
> > Why would you even want the map to work without added stuff? That's
> > what modding is about. ADDING STUFF.
> >
> >
> >>> Players fitting under the leage is something that needs alot of testing
> >>>
> > normaly
> > Err no, It's like 58 or 64 units isn't it? It can be measured in hammer
> easily.
> >
> >
> >>> finaly the wiki needs more coding documatasion
> >>>
> > Sure it does, but that's not valve's no.1 priority. Why don't you go
> > out there, learn the source engine and add some useful stuff to it
> > yourself?
> >
> >
> >>> also thay do not keep braking ours, thay use a seprate copy that has
> direct links with true engine heders.
> >>>
> > Well actually wait what??? Nope, we have the same thing they do.
> > We just don't get access to the engine itself. We have everything we
> > need to make a game like TF2/L4D without engine access anyways.
> >
> >
> > Tony,
> > I for one am actually satisfied with the source SDK, you're doing a
> > great job. The only thing I'd like in future is for valve to add more
> > functionality to the engine itself. Dynamic model scaling, DirectX 10
> > support and other stuff that would put the engine at a commercial and
> > featurewise par with UE3 and thus earn more licenses and more money
> > for valve in future and give valve greater resources to keep improving
> > the engine.
> >
> > 2009/8/29 Joshua Scarsbrook :
> >
> >> Hi
> >>
> >> Well the only other engine i liked is irrlicht but source is much beter
> >> for indie projects. i hope valve does not mind that i am making my own
> >> help file for the sdk, it will take forever to make but it will be
> >> preaty cool, it is working right now. with the ok from valve i will put
> >> it on the Valve Devlopers Wiki.
> >>
> >> Hope theres no repeat of last time
> >> Thanks Vbitz
> >>
> >>
> >> Logan Baldock wrote:
> >>
> >>> Meh, I like it the way it is actually. I got into modding using the
> same
> >>> methods that are there right now, and it just works. Unlike some other
> >>> engines.
> >>>
> >>>
>  You also have to take into account VALVe's priorities are:
> 
> 1. VALVe
> 2. Everyone else
> 
>  The Source SDK is basically just ripped from their *src/* folder which
>  contains the engine, VPhysics, Havok, etc. They aren't going to
> re-organise
>  the entire code base just to suit 20 people who want to save 1 hour
> per week
>  with the improvement it results in.
>  Thanks,
>  - Saul.
> 
> 
>  2009/8/29 Paul Peloski 
> 
> 
> 
> 
> > The SDK is improving all the time, but only to the extent necessary
> for
> > Valve to make awesome games. While an XML-based weapon system might
> be what
> > *you* need, or maybe what *you think the community needs*, it's not
> what
> > Valve needed. I suggest if that if you have list of massive
> improvements
> > that *you get to work on them*, or pick an engine th

Re: [hlcoders] Possable Improvements to the Source SDK

[Joshua Scarsbrook]

Well the doc is almost done.
Lighting RENDER, not really just real time
the compile map is good and a bar is not too hard to make since valve 
was so kind as to give us the source for the compile apps
added stuff. we need the maps to work for alot of people, i have seen 
ugly custom texture problems
and the wiki, working on it right now
and finaly  adding directx 10 to source would be wonderful but i think 
that thay are doing that for ep3 and lfd2

Thanks for all the coments
 Vbitz

p.s. i have alot of stuff to work on and you are almost the first to 
complain on my grammer, no offence
p.s.s. thunderbird likes my spelling and sending it to word would take 
to long

Harry Jeffery wrote:
> Well please run a spellcheck on it, format it into neat paragraphs and
> get someone to proof read it before you post it.
>
> That first message here nearly killed me.
>
>   
>>> The lighting is not as it is seen inside the engine when you use that
>>>   
> That's probably because your computer really wouldn't be able to
> calculate the lightmaps in realtime. What do you think vrad spends
> those minutes doing?
>
>   
>>> The progruss bar needs to show total progruss
>>>   
> Once you know the process of compiling a map you can easily tell how
> far through you are. I can at least. No need for a progress bar.
>
>   
>>> Profiles are to test weather the map will work without added stuff.
>>>   
> Why would you even want the map to work without added stuff? That's
> what modding is about. ADDING STUFF.
>
>   
>>> Players fitting under the leage is something that needs alot of testing
>>>   
> normaly
> Err no, It's like 58 or 64 units isn't it? It can be measured in hammer 
> easily.
>
>   
>>> finaly the wiki needs more coding documatasion
>>>   
> Sure it does, but that's not valve's no.1 priority. Why don't you go
> out there, learn the source engine and add some useful stuff to it
> yourself?
>
>   
>>> also thay do not keep braking ours, thay use a seprate copy that has direct 
>>> links with true engine heders.
>>>   
> Well actually wait what??? Nope, we have the same thing they do.
> We just don't get access to the engine itself. We have everything we
> need to make a game like TF2/L4D without engine access anyways.
>
>
> Tony,
> I for one am actually satisfied with the source SDK, you're doing a
> great job. The only thing I'd like in future is for valve to add more
> functionality to the engine itself. Dynamic model scaling, DirectX 10
> support and other stuff that would put the engine at a commercial and
> featurewise par with UE3 and thus earn more licenses and more money
> for valve in future and give valve greater resources to keep improving
> the engine.
>
> 2009/8/29 Joshua Scarsbrook :
>   
>> Hi
>>
>> Well the only other engine i liked is irrlicht but source is much beter
>> for indie projects. i hope valve does not mind that i am making my own
>> help file for the sdk, it will take forever to make but it will be
>> preaty cool, it is working right now. with the ok from valve i will put
>> it on the Valve Devlopers Wiki.
>>
>> Hope theres no repeat of last time
>> Thanks Vbitz
>>
>>
>> Logan Baldock wrote:
>> 
>>> Meh, I like it the way it is actually. I got into modding using the same
>>> methods that are there right now, and it just works. Unlike some other
>>> engines.
>>>
>>>   
 You also have to take into account VALVe's priorities are:

1. VALVe
2. Everyone else

 The Source SDK is basically just ripped from their *src/* folder which
 contains the engine, VPhysics, Havok, etc. They aren't going to re-organise
 the entire code base just to suit 20 people who want to save 1 hour per 
 week
 with the improvement it results in.
 Thanks,
 - Saul.


 2009/8/29 Paul Peloski 



 
> The SDK is improving all the time, but only to the extent necessary for
> Valve to make awesome games. While an XML-based weapon system might be 
> what
> *you* need, or maybe what *you think the community needs*, it's not what
> Valve needed. I suggest if that if you have list of massive improvements
> that *you get to work on them*, or pick an engine that already has the
> features and tools you need.
>
> Paul
>
> On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook 
>
>   
>> wrote:
>>
>> Hi Tony
>>
>> I think that the source sdk is a bit out dated; I think that with the
>> realece of hl2ep3 or just after it, there needs to be a massive
>> improvement in the source software development kit. For one there needs
>> to be a weapon generator that uses tags and xml to define a weapon a
>> basic weapon to speed up development of new weapons.  For two there
>> needs to be a technical improvement to hammer. Hammer as said by many
>> members of the community is out dated and needs to be improved; a simple

Re: [hlcoders] Possable Improvements to the Source SDK

[Saul Rennison]

>
> Dynamic model scaling

http://developer.valvesoftware.com/wiki/Prop_scalable


> DirectX 10 support

The shader system supports it... it just doesn't implement it. What
improvements would this bring that would be worth the money it would cost to
implement?


> featurewise par with UE3

I'm pretty darn sure that that isn't VALVe's main goal. The engine is purely
for their game-creating needs, they've only had a handful of licensees IIRC.
Doesn't Source Engine have a greater MOD community than UE3? It definately
had a bigger fan-base / players.


> and thus earn more licenses and more money for valve in future and give
> valve greater resources to keep improving the engine.

We'll see how pretty Episode 3 is when it's released. It will blow UE3 out
of the fucking water.

Thanks,
- Saul.


2009/8/29 Harry Jeffery 

> Well please run a spellcheck on it, format it into neat paragraphs and
> get someone to proof read it before you post it.
>
> That first message here nearly killed me.
>
>
> >>The lighting is not as it is seen inside the engine when you use that
> That's probably because your computer really wouldn't be able to
> calculate the lightmaps in realtime. What do you think vrad spends
> those minutes doing?
>
> >>The progruss bar needs to show total progruss
> Once you know the process of compiling a map you can easily tell how
> far through you are. I can at least. No need for a progress bar.
>
> >>Profiles are to test weather the map will work without added stuff.
> Why would you even want the map to work without added stuff? That's
> what modding is about. ADDING STUFF.
>
> >>Players fitting under the leage is something that needs alot of testing
> normaly
> Err no, It's like 58 or 64 units isn't it? It can be measured in hammer
> easily.
>
> >>finaly the wiki needs more coding documatasion
> Sure it does, but that's not valve's no.1 priority. Why don't you go
> out there, learn the source engine and add some useful stuff to it
> yourself?
>
> >>also thay do not keep braking ours, thay use a seprate copy that has
> direct links with true engine heders.
> Well actually wait what??? Nope, we have the same thing they do.
> We just don't get access to the engine itself. We have everything we
> need to make a game like TF2/L4D without engine access anyways.
>
>
> Tony,
> I for one am actually satisfied with the source SDK, you're doing a
> great job. The only thing I'd like in future is for valve to add more
> functionality to the engine itself. Dynamic model scaling, DirectX 10
> support and other stuff that would put the engine at a commercial and
> featurewise par with UE3 and thus earn more licenses and more money
> for valve in future and give valve greater resources to keep improving
> the engine.
>
> 2009/8/29 Joshua Scarsbrook :
> > Hi
> >
> > Well the only other engine i liked is irrlicht but source is much beter
> > for indie projects. i hope valve does not mind that i am making my own
> > help file for the sdk, it will take forever to make but it will be
> > preaty cool, it is working right now. with the ok from valve i will put
> > it on the Valve Devlopers Wiki.
> >
> > Hope theres no repeat of last time
> > Thanks Vbitz
> >
> >
> > Logan Baldock wrote:
> >> Meh, I like it the way it is actually. I got into modding using the same
> >> methods that are there right now, and it just works. Unlike some other
> >> engines.
> >>
> >>> You also have to take into account VALVe's priorities are:
> >>>
> >>>1. VALVe
> >>>2. Everyone else
> >>>
> >>> The Source SDK is basically just ripped from their *src/* folder which
> >>> contains the engine, VPhysics, Havok, etc. They aren't going to
> re-organise
> >>> the entire code base just to suit 20 people who want to save 1 hour per
> week
> >>> with the improvement it results in.
> >>> Thanks,
> >>> - Saul.
> >>>
> >>>
> >>> 2009/8/29 Paul Peloski 
> >>>
> >>>
> >>>
>  The SDK is improving all the time, but only to the extent necessary
> for
>  Valve to make awesome games. While an XML-based weapon system might be
> what
>  *you* need, or maybe what *you think the community needs*, it's not
> what
>  Valve needed. I suggest if that if you have list of massive
> improvements
>  that *you get to work on them*, or pick an engine that already has the
>  features and tools you need.
> 
>  Paul
> 
>  On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook <
> jscarsbr...@gmail.com
> 
> 
> > wrote:
> >
> > Hi Tony
> >
> > I think that the source sdk is a bit out dated; I think that with the
> > realece of hl2ep3 or just after it, there needs to be a massive
> > improvement in the source software development kit. For one there
> needs
> > to be a weapon generator that uses tags and xml to define a weapon a
> > basic weapon to speed up development of new weapons.  For two there
> > needs to be a technical improvement to hammer. Hammer as said by many
> > members 

Re: [hlcoders] Possable Improvements to the Source SDK

[Saul Rennison]

>
> The progruss bar needs to show total progruss

I'm sure you can figure out how much it's done. But an ETA would be
welcomed.

The lighting is not as it is seen inside the engine when you use that

I'm pretty sure there's a *Ray-traced* option in L4D which is exactly what
it says on the tin.

Players fitting under the leage is something that needs alot of testing
> normaly

There is *definately* a page on either VDC or *interlopers.net* which shows
exactly what I said in my previous email.

thay use a seprate copy that has direct links with true engine heders.

VALVe creates Counter-Strike: Source, L4D, TF2, etc. the same as we create
our mods. The only advantage they have is that they can branch the engine
off and have free rein over the engine code.


Thanks,
- Saul.


2009/8/29 Joshua Scarsbrook 

> Hi
> I welcome what you have said. for one the weapons defs are used to make
> premade code that can then be changed
> The progruss bar needs to show total progruss
> The lighting is not as it is seen inside the engine when you use that
> Profiles are to test weather the map will work without added stuff.
> Players fitting under the leage is something that needs alot of testing
> normaly
> finaly the wiki needs more coding documatasion.
> although valve considers themselfs first thay put alot of work into the sdk
> also thay do not keep braking ours, thay use a seprate copy that has
> direct links with true engine heders.
> also $100 bills out of the dvd drive would be useful but counterfiting
> using a dvd drive say using lightscrube is like  making a map that is
> designed on the desktop, cool but near impossable
> Thanks for the feedback so far
>
> Thanks
> Vbitz
>
> Saul Rennison wrote:
> >> For one there needs to be a weapon generoratoe that uses tags and xml to
> >> define a weapon a basic weapon to speed up development of new weapons.
> >>
> >>
> > This would sacrifice flexibility over speed. I couldn't give a toss about
> > how long it took, as long as it works and I can do what I want with it.
> >
> >
> >
> >> a simple improvement would be to add a progress bar to the run map
> window
> >>
> >
> > *BuildFaceLights: 1...2...3...*etc. I'd call that a progress bar...
> >
> >
> >
> >> also there needs to be a lighting render button to give a preview of the
> >> dev
> >>
> >
> > There already is in the 3D camera drop-down with *Wireframe*, *Textured*,
> > etc.
> >
> > say like a dev mode, which does not load custom content.
> >
> > I don't understand what you mean by "profiles". Why wouldn't you want
> custom
> > content to load?
> >
> > Another thing would be to add crash tracking in the engine
> >
> > All crashes generate an MDMP file for you to debug with in Visual Studio
> /
> > view with *windbg* (I think)
> >
> > A micro-engine in hammer to test whether a player can fit under a league
> is
> >
> >> also a importing thing
> >>
> >
> > There is a page on VDC which shows what dimensions players can fit under
> /
> > in.
> >
> > inbuilt documentation to help newcomers to mapping
> >
> > There is an entire HTML documentation for mapping in L4D... I'm sure
> they'll
> > do it for their future multiplayer games, rather un-necessary for
> > singleplayer. Plus there are hundreds of tutorials all over the internet.
> I
> > like *interlopers.net* best for help and assistance.
> >
> > make the skeathup plug-in more available though it is hidden in the
> source
> >
> >> sdk gcf
> >>
> >
> > I thought it was in the *sourcesdk content* folder somewhere? Corerct me
> if
> > I'm wrong.
> >
> > Valve Developers Wiki is out of date and both need an improvemt
> considering
> >
> >> the amount of people that use them
> >>
> >
> > It's a wiki you're free to help and edit.
> >
> > it is too hard to change basic game play rules and they should be in a
> >
> >> collective header file
> >>
> >
> > I find that the Source SDK is nicely organised into folders and filters
> in
> > Visual Studio. It's a very steep learning curve but you soon get the hang
> of
> > where things are and what calls what, etc.
> >
> > Thanks,
> > - Saul.
> >
> >
> > 2009/8/29 Joshua Scarsbrook 
> >
> >
> >> Hi Tony
> >>
> >> I think that the source sdk is a bit out dated; I think that with the
> >> realece of hl2ep3 or just after it, there needs to be a massive
> >> improvement in the source software development kit. For one there needs
> >> to be a weapon generator that uses tags and xml to define a weapon a
> >> basic weapon to speed up development of new weapons.  For two there
> >> needs to be a technical improvement to hammer. Hammer as said by many
> >> members of the community is out dated and needs to be improved; a simple
> >> improvement would be to add a progress bar to the run map window, also
> >> there needs to be a lighting render button to give a preview of the dev.
> >> In addition, there needs to be profiles added to the engine, say like a
> >> dev mode, which does not load custom content. Another thing would be to
> >> add crash

Re: [hlcoders] Possable Improvements to the Source SDK

[Harry Jeffery]

Well please run a spellcheck on it, format it into neat paragraphs and
get someone to proof read it before you post it.

That first message here nearly killed me.


>>The lighting is not as it is seen inside the engine when you use that
That's probably because your computer really wouldn't be able to
calculate the lightmaps in realtime. What do you think vrad spends
those minutes doing?

>>The progruss bar needs to show total progruss
Once you know the process of compiling a map you can easily tell how
far through you are. I can at least. No need for a progress bar.

>>Profiles are to test weather the map will work without added stuff.
Why would you even want the map to work without added stuff? That's
what modding is about. ADDING STUFF.

>>Players fitting under the leage is something that needs alot of testing
normaly
Err no, It's like 58 or 64 units isn't it? It can be measured in hammer easily.

>>finaly the wiki needs more coding documatasion
Sure it does, but that's not valve's no.1 priority. Why don't you go
out there, learn the source engine and add some useful stuff to it
yourself?

>>also thay do not keep braking ours, thay use a seprate copy that has direct 
>>links with true engine heders.
Well actually wait what??? Nope, we have the same thing they do.
We just don't get access to the engine itself. We have everything we
need to make a game like TF2/L4D without engine access anyways.


Tony,
I for one am actually satisfied with the source SDK, you're doing a
great job. The only thing I'd like in future is for valve to add more
functionality to the engine itself. Dynamic model scaling, DirectX 10
support and other stuff that would put the engine at a commercial and
featurewise par with UE3 and thus earn more licenses and more money
for valve in future and give valve greater resources to keep improving
the engine.

2009/8/29 Joshua Scarsbrook :
> Hi
>
> Well the only other engine i liked is irrlicht but source is much beter
> for indie projects. i hope valve does not mind that i am making my own
> help file for the sdk, it will take forever to make but it will be
> preaty cool, it is working right now. with the ok from valve i will put
> it on the Valve Devlopers Wiki.
>
> Hope theres no repeat of last time
> Thanks Vbitz
>
>
> Logan Baldock wrote:
>> Meh, I like it the way it is actually. I got into modding using the same
>> methods that are there right now, and it just works. Unlike some other
>> engines.
>>
>>> You also have to take into account VALVe's priorities are:
>>>
>>>    1. VALVe
>>>    2. Everyone else
>>>
>>> The Source SDK is basically just ripped from their *src/* folder which
>>> contains the engine, VPhysics, Havok, etc. They aren't going to re-organise
>>> the entire code base just to suit 20 people who want to save 1 hour per week
>>> with the improvement it results in.
>>> Thanks,
>>> - Saul.
>>>
>>>
>>> 2009/8/29 Paul Peloski 
>>>
>>>
>>>
 The SDK is improving all the time, but only to the extent necessary for
 Valve to make awesome games. While an XML-based weapon system might be what
 *you* need, or maybe what *you think the community needs*, it's not what
 Valve needed. I suggest if that if you have list of massive improvements
 that *you get to work on them*, or pick an engine that already has the
 features and tools you need.

 Paul

 On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook >>>

> wrote:
>
> Hi Tony
>
> I think that the source sdk is a bit out dated; I think that with the
> realece of hl2ep3 or just after it, there needs to be a massive
> improvement in the source software development kit. For one there needs
> to be a weapon generator that uses tags and xml to define a weapon a
> basic weapon to speed up development of new weapons.  For two there
> needs to be a technical improvement to hammer. Hammer as said by many
> members of the community is out dated and needs to be improved; a simple
> improvement would be to add a progress bar to the run map window, also
> there needs to be a lighting render button to give a preview of the dev.
> In addition, there needs to be profiles added to the engine, say like a
> dev mode, which does not load custom content. Another thing would be to
> add crash tracking in the engine, the report bug system is not
> implicated enough and most map devs will understand technical details. A
> micro-engine in hammer to test whether a player can fit under a league
> is also a importing thing. A defeat visleef system would be a very
> powerful improvement to show things the player would be seeing and only
> that. The hammer editor is treated very much like a cad program and
> should be made easier to understand and with inbuilt documentation to
> help newcomers to mapping, the doc would be placed as tooltips and info
> in the entries window. In addition, it would be important make the
> s

Re: [hlcoders] Possable Improvements to the Source SDK

[Heimo Stieg]

Valve won't have a problem with that ( as long as everything is correct )

That's what the wiki is for...

Joshua Scarsbrook schrieb:
> Hi
>
> Well the only other engine i liked is irrlicht but source is much beter 
> for indie projects. i hope valve does not mind that i am making my own 
> help file for the sdk, it will take forever to make but it will be 
> preaty cool, it is working right now. with the ok from valve i will put 
> it on the Valve Devlopers Wiki.
>
> Hope theres no repeat of last time
> Thanks Vbitz
>
>
> Logan Baldock wrote:
>   
>> Meh, I like it the way it is actually. I got into modding using the same 
>> methods that are there right now, and it just works. Unlike some other 
>> engines.
>>   
>> 
>>> You also have to take into account VALVe's priorities are:
>>>
>>>1. VALVe
>>>2. Everyone else
>>>
>>> The Source SDK is basically just ripped from their *src/* folder which
>>> contains the engine, VPhysics, Havok, etc. They aren't going to re-organise
>>> the entire code base just to suit 20 people who want to save 1 hour per week
>>> with the improvement it results in.
>>> Thanks,
>>> - Saul.
>>>
>>>
>>> 2009/8/29 Paul Peloski 
>>>
>>>   
>>> 
>>>   
 The SDK is improving all the time, but only to the extent necessary for
 Valve to make awesome games. While an XML-based weapon system might be what
 *you* need, or maybe what *you think the community needs*, it's not what
 Valve needed. I suggest if that if you have list of massive improvements
 that *you get to work on them*, or pick an engine that already has the
 features and tools you need.

 Paul

 On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook >>> 
   
 
> wrote:
>   
> Hi Tony
>
> I think that the source sdk is a bit out dated; I think that with the
> realece of hl2ep3 or just after it, there needs to be a massive
> improvement in the source software development kit. For one there needs
> to be a weapon generator that uses tags and xml to define a weapon a
> basic weapon to speed up development of new weapons.  For two there
> needs to be a technical improvement to hammer. Hammer as said by many
> members of the community is out dated and needs to be improved; a simple
> improvement would be to add a progress bar to the run map window, also
> there needs to be a lighting render button to give a preview of the dev.
> In addition, there needs to be profiles added to the engine, say like a
> dev mode, which does not load custom content. Another thing would be to
> add crash tracking in the engine, the report bug system is not
> implicated enough and most map devs will understand technical details. A
> micro-engine in hammer to test whether a player can fit under a league
> is also a importing thing. A defeat visleef system would be a very
> powerful improvement to show things the player would be seeing and only
> that. The hammer editor is treated very much like a cad program and
> should be made easier to understand and with inbuilt documentation to
> help newcomers to mapping, the doc would be placed as tooltips and info
> in the entries window. In addition, it would be important make the
> skeathup plug-in more available though it is hidden in the source sdk
> gcf. In addition, improvements need to be made to the documentation of
> the source sdk, such as a separate wiki that contains a detailed
> expiation of what each coding file does. With all of this said I think
> that the source sdk and Valve Developers Wiki is out of date and both
> need an improvemt considering the amount of people that use them. Also
> worth noting, that it is too hard to change basic game play rules and
> they should be in a collective header file. What I propose is both
> employees of valve and the coumumatiy surrounding them do this as to
> continue communality support for years to come. Though these
> improvements would require a lot of development, I think that they would
> appeal to the entire communality.
>
> Thanks,
>
> Vbitz
>
> ___
> 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] Possable Improvements to the Source SDK

[Joshua Scarsbrook]

Hi

Well the only other engine i liked is irrlicht but source is much beter 
for indie projects. i hope valve does not mind that i am making my own 
help file for the sdk, it will take forever to make but it will be 
preaty cool, it is working right now. with the ok from valve i will put 
it on the Valve Devlopers Wiki.

Hope theres no repeat of last time
Thanks Vbitz


Logan Baldock wrote:
> Meh, I like it the way it is actually. I got into modding using the same 
> methods that are there right now, and it just works. Unlike some other 
> engines.
>   
>> You also have to take into account VALVe's priorities are:
>>
>>1. VALVe
>>2. Everyone else
>>
>> The Source SDK is basically just ripped from their *src/* folder which
>> contains the engine, VPhysics, Havok, etc. They aren't going to re-organise
>> the entire code base just to suit 20 people who want to save 1 hour per week
>> with the improvement it results in.
>> Thanks,
>> - Saul.
>>
>>
>> 2009/8/29 Paul Peloski 
>>
>>   
>> 
>>> The SDK is improving all the time, but only to the extent necessary for
>>> Valve to make awesome games. While an XML-based weapon system might be what
>>> *you* need, or maybe what *you think the community needs*, it's not what
>>> Valve needed. I suggest if that if you have list of massive improvements
>>> that *you get to work on them*, or pick an engine that already has the
>>> features and tools you need.
>>>
>>> Paul
>>>
>>> On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook >> 
>>>   
 wrote:
   
 Hi Tony

 I think that the source sdk is a bit out dated; I think that with the
 realece of hl2ep3 or just after it, there needs to be a massive
 improvement in the source software development kit. For one there needs
 to be a weapon generator that uses tags and xml to define a weapon a
 basic weapon to speed up development of new weapons.  For two there
 needs to be a technical improvement to hammer. Hammer as said by many
 members of the community is out dated and needs to be improved; a simple
 improvement would be to add a progress bar to the run map window, also
 there needs to be a lighting render button to give a preview of the dev.
 In addition, there needs to be profiles added to the engine, say like a
 dev mode, which does not load custom content. Another thing would be to
 add crash tracking in the engine, the report bug system is not
 implicated enough and most map devs will understand technical details. A
 micro-engine in hammer to test whether a player can fit under a league
 is also a importing thing. A defeat visleef system would be a very
 powerful improvement to show things the player would be seeing and only
 that. The hammer editor is treated very much like a cad program and
 should be made easier to understand and with inbuilt documentation to
 help newcomers to mapping, the doc would be placed as tooltips and info
 in the entries window. In addition, it would be important make the
 skeathup plug-in more available though it is hidden in the source sdk
 gcf. In addition, improvements need to be made to the documentation of
 the source sdk, such as a separate wiki that contains a detailed
 expiation of what each coding file does. With all of this said I think
 that the source sdk and Valve Developers Wiki is out of date and both
 need an improvemt considering the amount of people that use them. Also
 worth noting, that it is too hard to change basic game play rules and
 they should be in a collective header file. What I propose is both
 employees of valve and the coumumatiy surrounding them do this as to
 continue communality support for years to come. Though these
 improvements would require a lot of development, I think that they would
 appeal to the entire communality.

 Thanks,

 Vbitz

 ___
 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:
htt

Re: [hlcoders] Possable Improvements to the Source SDK

[Joshua Scarsbrook]

Hi
I welcome what you have said. for one the weapons defs are used to make 
premade code that can then be changed
The progruss bar needs to show total progruss
The lighting is not as it is seen inside the engine when you use that
Profiles are to test weather the map will work without added stuff.
Players fitting under the leage is something that needs alot of testing 
normaly
finaly the wiki needs more coding documatasion.
although valve considers themselfs first thay put alot of work into the sdk
also thay do not keep braking ours, thay use a seprate copy that has 
direct links with true engine heders.
also $100 bills out of the dvd drive would be useful but counterfiting 
using a dvd drive say using lightscrube is like  making a map that is 
designed on the desktop, cool but near impossable
Thanks for the feedback so far

Thanks
Vbitz

Saul Rennison wrote:
>> For one there needs to be a weapon generoratoe that uses tags and xml to
>> define a weapon a basic weapon to speed up development of new weapons.
>>
>> 
> This would sacrifice flexibility over speed. I couldn't give a toss about
> how long it took, as long as it works and I can do what I want with it.
>
>
>   
>> a simple improvement would be to add a progress bar to the run map window
>> 
>
> *BuildFaceLights: 1...2...3...*etc. I'd call that a progress bar...
>
>
>   
>> also there needs to be a lighting render button to give a preview of the
>> dev
>> 
>
> There already is in the 3D camera drop-down with *Wireframe*, *Textured*,
> etc.
>
> say like a dev mode, which does not load custom content.
>
> I don't understand what you mean by "profiles". Why wouldn't you want custom
> content to load?
>
> Another thing would be to add crash tracking in the engine
>
> All crashes generate an MDMP file for you to debug with in Visual Studio /
> view with *windbg* (I think)
>
> A micro-engine in hammer to test whether a player can fit under a league is
>   
>> also a importing thing
>> 
>
> There is a page on VDC which shows what dimensions players can fit under /
> in.
>
> inbuilt documentation to help newcomers to mapping
>
> There is an entire HTML documentation for mapping in L4D... I'm sure they'll
> do it for their future multiplayer games, rather un-necessary for
> singleplayer. Plus there are hundreds of tutorials all over the internet. I
> like *interlopers.net* best for help and assistance.
>
> make the skeathup plug-in more available though it is hidden in the source
>   
>> sdk gcf
>> 
>
> I thought it was in the *sourcesdk content* folder somewhere? Corerct me if
> I'm wrong.
>
> Valve Developers Wiki is out of date and both need an improvemt considering
>   
>> the amount of people that use them
>> 
>
> It's a wiki you're free to help and edit.
>
> it is too hard to change basic game play rules and they should be in a
>   
>> collective header file
>> 
>
> I find that the Source SDK is nicely organised into folders and filters in
> Visual Studio. It's a very steep learning curve but you soon get the hang of
> where things are and what calls what, etc.
>
> Thanks,
> - Saul.
>
>
> 2009/8/29 Joshua Scarsbrook 
>
>   
>> Hi Tony
>>
>> I think that the source sdk is a bit out dated; I think that with the
>> realece of hl2ep3 or just after it, there needs to be a massive
>> improvement in the source software development kit. For one there needs
>> to be a weapon generator that uses tags and xml to define a weapon a
>> basic weapon to speed up development of new weapons.  For two there
>> needs to be a technical improvement to hammer. Hammer as said by many
>> members of the community is out dated and needs to be improved; a simple
>> improvement would be to add a progress bar to the run map window, also
>> there needs to be a lighting render button to give a preview of the dev.
>> In addition, there needs to be profiles added to the engine, say like a
>> dev mode, which does not load custom content. Another thing would be to
>> add crash tracking in the engine, the report bug system is not
>> implicated enough and most map devs will understand technical details. A
>> micro-engine in hammer to test whether a player can fit under a league
>> is also a importing thing. A defeat visleef system would be a very
>> powerful improvement to show things the player would be seeing and only
>> that. The hammer editor is treated very much like a cad program and
>> should be made easier to understand and with inbuilt documentation to
>> help newcomers to mapping, the doc would be placed as tooltips and info
>> in the entries window. In addition, it would be important make the
>> skeathup plug-in more available though it is hidden in the source sdk
>> gcf. In addition, improvements need to be made to the documentation of
>> the source sdk, such as a separate wiki that contains a detailed
>> expiation of what each coding file does. With all of this said I think
>> that the source sdk and Valve Developers Wiki is out of date and both
>> n

Re: [hlcoders] Possable Improvements to the Source SDK

[Logan Baldock]

Meh, I like it the way it is actually. I got into modding using the same 
methods that are there right now, and it just works. Unlike some other 
engines.
> You also have to take into account VALVe's priorities are:
>
>1. VALVe
>2. Everyone else
>
> The Source SDK is basically just ripped from their *src/* folder which
> contains the engine, VPhysics, Havok, etc. They aren't going to re-organise
> the entire code base just to suit 20 people who want to save 1 hour per week
> with the improvement it results in.
> Thanks,
> - Saul.
>
>
> 2009/8/29 Paul Peloski 
>
>   
>> The SDK is improving all the time, but only to the extent necessary for
>> Valve to make awesome games. While an XML-based weapon system might be what
>> *you* need, or maybe what *you think the community needs*, it's not what
>> Valve needed. I suggest if that if you have list of massive improvements
>> that *you get to work on them*, or pick an engine that already has the
>> features and tools you need.
>>
>> Paul
>>
>> On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook > 
>>> wrote:
>>>   
>>> Hi Tony
>>>
>>> I think that the source sdk is a bit out dated; I think that with the
>>> realece of hl2ep3 or just after it, there needs to be a massive
>>> improvement in the source software development kit. For one there needs
>>> to be a weapon generator that uses tags and xml to define a weapon a
>>> basic weapon to speed up development of new weapons.  For two there
>>> needs to be a technical improvement to hammer. Hammer as said by many
>>> members of the community is out dated and needs to be improved; a simple
>>> improvement would be to add a progress bar to the run map window, also
>>> there needs to be a lighting render button to give a preview of the dev.
>>> In addition, there needs to be profiles added to the engine, say like a
>>> dev mode, which does not load custom content. Another thing would be to
>>> add crash tracking in the engine, the report bug system is not
>>> implicated enough and most map devs will understand technical details. A
>>> micro-engine in hammer to test whether a player can fit under a league
>>> is also a importing thing. A defeat visleef system would be a very
>>> powerful improvement to show things the player would be seeing and only
>>> that. The hammer editor is treated very much like a cad program and
>>> should be made easier to understand and with inbuilt documentation to
>>> help newcomers to mapping, the doc would be placed as tooltips and info
>>> in the entries window. In addition, it would be important make the
>>> skeathup plug-in more available though it is hidden in the source sdk
>>> gcf. In addition, improvements need to be made to the documentation of
>>> the source sdk, such as a separate wiki that contains a detailed
>>> expiation of what each coding file does. With all of this said I think
>>> that the source sdk and Valve Developers Wiki is out of date and both
>>> need an improvemt considering the amount of people that use them. Also
>>> worth noting, that it is too hard to change basic game play rules and
>>> they should be in a collective header file. What I propose is both
>>> employees of valve and the coumumatiy surrounding them do this as to
>>> continue communality support for years to come. Though these
>>> improvements would require a lot of development, I think that they would
>>> appeal to the entire communality.
>>>
>>> Thanks,
>>>
>>> Vbitz
>>>
>>> ___
>>> 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] Possable Improvements to the Source SDK

[Matt Hoffman]

I don't think that's quite true Saul. Our copy seems to differer from theirs
because they keep breaking ours and not theirs. :p


On Sat, Aug 29, 2009 at 2:54 PM, Saul Rennison wrote:

> You also have to take into account VALVe's priorities are:
>
>   1. VALVe
>   2. Everyone else
>
> The Source SDK is basically just ripped from their *src/* folder which
> contains the engine, VPhysics, Havok, etc. They aren't going to re-organise
> the entire code base just to suit 20 people who want to save 1 hour per
> week
> with the improvement it results in.
> Thanks,
> - Saul.
>
>
> 2009/8/29 Paul Peloski 
>
> > The SDK is improving all the time, but only to the extent necessary for
> > Valve to make awesome games. While an XML-based weapon system might be
> what
> > *you* need, or maybe what *you think the community needs*, it's not what
> > Valve needed. I suggest if that if you have list of massive improvements
> > that *you get to work on them*, or pick an engine that already has the
> > features and tools you need.
> >
> > Paul
> >
> > On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook <
> jscarsbr...@gmail.com
> > >wrote:
> >
> > > Hi Tony
> > >
> > > I think that the source sdk is a bit out dated; I think that with the
> > > realece of hl2ep3 or just after it, there needs to be a massive
> > > improvement in the source software development kit. For one there needs
> > > to be a weapon generator that uses tags and xml to define a weapon a
> > > basic weapon to speed up development of new weapons.  For two there
> > > needs to be a technical improvement to hammer. Hammer as said by many
> > > members of the community is out dated and needs to be improved; a
> simple
> > > improvement would be to add a progress bar to the run map window, also
> > > there needs to be a lighting render button to give a preview of the
> dev.
> > > In addition, there needs to be profiles added to the engine, say like a
> > > dev mode, which does not load custom content. Another thing would be to
> > > add crash tracking in the engine, the report bug system is not
> > > implicated enough and most map devs will understand technical details.
> A
> > > micro-engine in hammer to test whether a player can fit under a league
> > > is also a importing thing. A defeat visleef system would be a very
> > > powerful improvement to show things the player would be seeing and only
> > > that. The hammer editor is treated very much like a cad program and
> > > should be made easier to understand and with inbuilt documentation to
> > > help newcomers to mapping, the doc would be placed as tooltips and info
> > > in the entries window. In addition, it would be important make the
> > > skeathup plug-in more available though it is hidden in the source sdk
> > > gcf. In addition, improvements need to be made to the documentation of
> > > the source sdk, such as a separate wiki that contains a detailed
> > > expiation of what each coding file does. With all of this said I think
> > > that the source sdk and Valve Developers Wiki is out of date and both
> > > need an improvemt considering the amount of people that use them. Also
> > > worth noting, that it is too hard to change basic game play rules and
> > > they should be in a collective header file. What I propose is both
> > > employees of valve and the coumumatiy surrounding them do this as to
> > > continue communality support for years to come. Though these
> > > improvements would require a lot of development, I think that they
> would
> > > appeal to the entire communality.
> > >
> > > Thanks,
> > >
> > > Vbitz
> > >
> > > ___
> > > 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] Possable Improvements to the Source SDK

[botman]

I think that it needs to make $100 bills shoot out of the DVD drive.

I think that would appeal to the entire community.

:)

On 8/29/2009 4:37 PM, Joshua Scarsbrook wrote:
> Hi Tony
>
> I think that the source sdk is a bit out dated; I think that with the
> realece of hl2ep3 or just after it, there needs to be a massive
> improvement in the source software development kit. For one there needs
> to be a weapon generator that uses tags and xml to define a weapon a
> basic weapon to speed up development of new weapons.  For two there
> needs to be a technical improvement to hammer. Hammer as said by many
> members of the community is out dated and needs to be improved; a simple
> improvement would be to add a progress bar to the run map window, also
> there needs to be a lighting render button to give a preview of the dev.
> In addition, there needs to be profiles added to the engine, say like a
> dev mode, which does not load custom content. Another thing would be to
> add crash tracking in the engine, the report bug system is not
> implicated enough and most map devs will understand technical details. A
> micro-engine in hammer to test whether a player can fit under a league
> is also a importing thing. A defeat visleef system would be a very
> powerful improvement to show things the player would be seeing and only
> that. The hammer editor is treated very much like a cad program and
> should be made easier to understand and with inbuilt documentation to
> help newcomers to mapping, the doc would be placed as tooltips and info
> in the entries window. In addition, it would be important make the
> skeathup plug-in more available though it is hidden in the source sdk
> gcf. In addition, improvements need to be made to the documentation of
> the source sdk, such as a separate wiki that contains a detailed
> expiation of what each coding file does. With all of this said I think
> that the source sdk and Valve Developers Wiki is out of date and both
> need an improvemt considering the amount of people that use them. Also
> worth noting, that it is too hard to change basic game play rules and
> they should be in a collective header file. What I propose is both
> employees of valve and the coumumatiy surrounding them do this as to
> continue communality support for years to come. Though these
> improvements would require a lot of development, I think that they would
> appeal to the entire communality.
>
> Thanks,
>
> Vbitz
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

-- 
Jeffrey "botman" Broome

___
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

[Saul Rennison]

You also have to take into account VALVe's priorities are:

   1. VALVe
   2. Everyone else

The Source SDK is basically just ripped from their *src/* folder which
contains the engine, VPhysics, Havok, etc. They aren't going to re-organise
the entire code base just to suit 20 people who want to save 1 hour per week
with the improvement it results in.
Thanks,
- Saul.


2009/8/29 Paul Peloski 

> The SDK is improving all the time, but only to the extent necessary for
> Valve to make awesome games. While an XML-based weapon system might be what
> *you* need, or maybe what *you think the community needs*, it's not what
> Valve needed. I suggest if that if you have list of massive improvements
> that *you get to work on them*, or pick an engine that already has the
> features and tools you need.
>
> Paul
>
> On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook  >wrote:
>
> > Hi Tony
> >
> > I think that the source sdk is a bit out dated; I think that with the
> > realece of hl2ep3 or just after it, there needs to be a massive
> > improvement in the source software development kit. For one there needs
> > to be a weapon generator that uses tags and xml to define a weapon a
> > basic weapon to speed up development of new weapons.  For two there
> > needs to be a technical improvement to hammer. Hammer as said by many
> > members of the community is out dated and needs to be improved; a simple
> > improvement would be to add a progress bar to the run map window, also
> > there needs to be a lighting render button to give a preview of the dev.
> > In addition, there needs to be profiles added to the engine, say like a
> > dev mode, which does not load custom content. Another thing would be to
> > add crash tracking in the engine, the report bug system is not
> > implicated enough and most map devs will understand technical details. A
> > micro-engine in hammer to test whether a player can fit under a league
> > is also a importing thing. A defeat visleef system would be a very
> > powerful improvement to show things the player would be seeing and only
> > that. The hammer editor is treated very much like a cad program and
> > should be made easier to understand and with inbuilt documentation to
> > help newcomers to mapping, the doc would be placed as tooltips and info
> > in the entries window. In addition, it would be important make the
> > skeathup plug-in more available though it is hidden in the source sdk
> > gcf. In addition, improvements need to be made to the documentation of
> > the source sdk, such as a separate wiki that contains a detailed
> > expiation of what each coding file does. With all of this said I think
> > that the source sdk and Valve Developers Wiki is out of date and both
> > need an improvemt considering the amount of people that use them. Also
> > worth noting, that it is too hard to change basic game play rules and
> > they should be in a collective header file. What I propose is both
> > employees of valve and the coumumatiy surrounding them do this as to
> > continue communality support for years to come. Though these
> > improvements would require a lot of development, I think that they would
> > appeal to the entire communality.
> >
> > Thanks,
> >
> > Vbitz
> >
> > ___
> > 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] Possable Improvements to the Source SDK

[Paul Peloski]

The SDK is improving all the time, but only to the extent necessary for
Valve to make awesome games. While an XML-based weapon system might be what
*you* need, or maybe what *you think the community needs*, it's not what
Valve needed. I suggest if that if you have list of massive improvements
that *you get to work on them*, or pick an engine that already has the
features and tools you need.

Paul

On Sat, Aug 29, 2009 at 3:37 PM, Joshua Scarsbrook wrote:

> Hi Tony
>
> I think that the source sdk is a bit out dated; I think that with the
> realece of hl2ep3 or just after it, there needs to be a massive
> improvement in the source software development kit. For one there needs
> to be a weapon generator that uses tags and xml to define a weapon a
> basic weapon to speed up development of new weapons.  For two there
> needs to be a technical improvement to hammer. Hammer as said by many
> members of the community is out dated and needs to be improved; a simple
> improvement would be to add a progress bar to the run map window, also
> there needs to be a lighting render button to give a preview of the dev.
> In addition, there needs to be profiles added to the engine, say like a
> dev mode, which does not load custom content. Another thing would be to
> add crash tracking in the engine, the report bug system is not
> implicated enough and most map devs will understand technical details. A
> micro-engine in hammer to test whether a player can fit under a league
> is also a importing thing. A defeat visleef system would be a very
> powerful improvement to show things the player would be seeing and only
> that. The hammer editor is treated very much like a cad program and
> should be made easier to understand and with inbuilt documentation to
> help newcomers to mapping, the doc would be placed as tooltips and info
> in the entries window. In addition, it would be important make the
> skeathup plug-in more available though it is hidden in the source sdk
> gcf. In addition, improvements need to be made to the documentation of
> the source sdk, such as a separate wiki that contains a detailed
> expiation of what each coding file does. With all of this said I think
> that the source sdk and Valve Developers Wiki is out of date and both
> need an improvemt considering the amount of people that use them. Also
> worth noting, that it is too hard to change basic game play rules and
> they should be in a collective header file. What I propose is both
> employees of valve and the coumumatiy surrounding them do this as to
> continue communality support for years to come. Though these
> improvements would require a lot of development, I think that they would
> appeal to the entire communality.
>
> Thanks,
>
> Vbitz
>
> ___
> 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] Possable Improvements to the Source SDK

[Saul Rennison]

>
> For one there needs to be a weapon generator that uses tags and xml to
> define a weapon a basic weapon to speed up development of new weapons.
>
This would sacrifice flexibility over speed. I couldn't give a toss about
how long it took, as long as it works and I can do what I want with it.


> a simple improvement would be to add a progress bar to the run map window

*BuildFaceLights: 1...2...3...*etc. I'd call that a progress bar...


> also there needs to be a lighting render button to give a preview of the
> dev

There already is in the 3D camera drop-down with *Wireframe*, *Textured*,
etc.

say like a dev mode, which does not load custom content.

I don't understand what you mean by "profiles". Why wouldn't you want custom
content to load?

Another thing would be to add crash tracking in the engine

All crashes generate an MDMP file for you to debug with in Visual Studio /
view with *windbg* (I think)

A micro-engine in hammer to test whether a player can fit under a league is
> also a importing thing

There is a page on VDC which shows what dimensions players can fit under /
in.

inbuilt documentation to help newcomers to mapping

There is an entire HTML documentation for mapping in L4D... I'm sure they'll
do it for their future multiplayer games, rather un-necessary for
singleplayer. Plus there are hundreds of tutorials all over the internet. I
like *interlopers.net* best for help and assistance.

make the skeathup plug-in more available though it is hidden in the source
> sdk gcf

I thought it was in the *sourcesdk content* folder somewhere? Corerct me if
I'm wrong.

Valve Developers Wiki is out of date and both need an improvemt considering
> the amount of people that use them

It's a wiki you're free to help and edit.

it is too hard to change basic game play rules and they should be in a
> collective header file

I find that the Source SDK is nicely organised into folders and filters in
Visual Studio. It's a very steep learning curve but you soon get the hang of
where things are and what calls what, etc.

Thanks,
- Saul.


2009/8/29 Joshua Scarsbrook 

> Hi Tony
>
> I think that the source sdk is a bit out dated; I think that with the
> realece of hl2ep3 or just after it, there needs to be a massive
> improvement in the source software development kit. For one there needs
> to be a weapon generator that uses tags and xml to define a weapon a
> basic weapon to speed up development of new weapons.  For two there
> needs to be a technical improvement to hammer. Hammer as said by many
> members of the community is out dated and needs to be improved; a simple
> improvement would be to add a progress bar to the run map window, also
> there needs to be a lighting render button to give a preview of the dev.
> In addition, there needs to be profiles added to the engine, say like a
> dev mode, which does not load custom content. Another thing would be to
> add crash tracking in the engine, the report bug system is not
> implicated enough and most map devs will understand technical details. A
> micro-engine in hammer to test whether a player can fit under a league
> is also a importing thing. A defeat visleef system would be a very
> powerful improvement to show things the player would be seeing and only
> that. The hammer editor is treated very much like a cad program and
> should be made easier to understand and with inbuilt documentation to
> help newcomers to mapping, the doc would be placed as tooltips and info
> in the entries window. In addition, it would be important make the
> skeathup plug-in more available though it is hidden in the source sdk
> gcf. In addition, improvements need to be made to the documentation of
> the source sdk, such as a separate wiki that contains a detailed
> expiation of what each coding file does. With all of this said I think
> that the source sdk and Valve Developers Wiki is out of date and both
> need an improvemt considering the amount of people that use them. Also
> worth noting, that it is too hard to change basic game play rules and
> they should be in a collective header file. What I propose is both
> employees of valve and the coumumatiy surrounding them do this as to
> continue communality support for years to come. Though these
> improvements would require a lot of development, I think that they would
> appeal to the entire communality.
>
> Thanks,
>
> Vbitz
>
> ___
> 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

[hlcoders] Possable Improvements to the Source SDK

[Joshua Scarsbrook]

Hi Tony

I think that the source sdk is a bit out dated; I think that with the 
realece of hl2ep3 or just after it, there needs to be a massive 
improvement in the source software development kit. For one there needs 
to be a weapon generator that uses tags and xml to define a weapon a 
basic weapon to speed up development of new weapons.  For two there 
needs to be a technical improvement to hammer. Hammer as said by many 
members of the community is out dated and needs to be improved; a simple 
improvement would be to add a progress bar to the run map window, also 
there needs to be a lighting render button to give a preview of the dev. 
In addition, there needs to be profiles added to the engine, say like a 
dev mode, which does not load custom content. Another thing would be to 
add crash tracking in the engine, the report bug system is not 
implicated enough and most map devs will understand technical details. A 
micro-engine in hammer to test whether a player can fit under a league 
is also a importing thing. A defeat visleef system would be a very 
powerful improvement to show things the player would be seeing and only 
that. The hammer editor is treated very much like a cad program and 
should be made easier to understand and with inbuilt documentation to 
help newcomers to mapping, the doc would be placed as tooltips and info 
in the entries window. In addition, it would be important make the 
skeathup plug-in more available though it is hidden in the source sdk 
gcf. In addition, improvements need to be made to the documentation of 
the source sdk, such as a separate wiki that contains a detailed 
expiation of what each coding file does. With all of this said I think 
that the source sdk and Valve Developers Wiki is out of date and both 
need an improvemt considering the amount of people that use them. Also 
worth noting, that it is too hard to change basic game play rules and 
they should be in a collective header file. What I propose is both 
employees of valve and the coumumatiy surrounding them do this as to 
continue communality support for years to come. Though these 
improvements would require a lot of development, I think that they would 
appeal to the entire communality.

Thanks,

Vbitz

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