Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-30 Thread Doeke Wartena
yes, only a batch compiler solves it. If you wonder it's still compiling or
not go to your task manager and look at mem usage.

About improving hammer, in hammer 3.5 i was able to use the camera when the
texture editor was open. This allowed me to rotate around a object for
example and select all faces. In the hammer of now as soon as i click on the
camera button my texture editor closes which makes certain tasks harder.
It would be really nice if that gets back like how it was.

And for another improvement, it would be nice to have clones. This way i can
make a pilar for example, change the shape and the texture of the original
later and it will be applied to all.

for the rest hammer is a nice program and it does his job, althought making
it open source would be nice.


 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?
___
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

2009-08-29 Thread 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 jscarsbr...@gmail.com

 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

2009-08-29 Thread 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.comwrote:

 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

2009-08-29 Thread 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 paulpelo...@gmail.com

 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



Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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

2009-08-29 Thread 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 saul.renni...@gmail.comwrote:

 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 paulpelo...@gmail.com

  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

2009-08-29 Thread 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 paulpelo...@gmail.com

   
 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

2009-08-29 Thread 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 jscarsbr...@gmail.com

   
 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 

Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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 paulpelo...@gmail.com

   
 
 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


   


___
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

2009-08-29 Thread 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 paulpelo...@gmail.com

   
 
   
 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


   
 


 ___
 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

2009-08-29 Thread 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 jscarsbr...@gmail.com:
 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 paulpelo...@gmail.com



 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 

Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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 jscarsbr...@gmail.com

 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 jscarsbr...@gmail.com
 
 
  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 

Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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 harry101jeff...@googlemail.com

 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 jscarsbr...@gmail.com:
  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 paulpelo...@gmail.com
 
 
 
  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, 

Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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 jscarsbr...@gmail.com:
   
 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 paulpelo...@gmail.com



 
 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. 

Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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 jscarsbr...@gmail.comwrote:

 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 jscarsbr...@gmail.com:
 
  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 paulpelo...@gmail.com
 
 
 
 
  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 

Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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 harry101jeff...@googlemail.com

   
 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 jscarsbr...@gmail.com:
 
 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 paulpelo...@gmail.com



   
 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 

Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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 
 jscarsbr...@gmail.comwrote:

   
 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 jscarsbr...@gmail.com:

   
 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 paulpelo...@gmail.com




 
 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
 
 

Re: [hlcoders] Possable Improvements to the Source SDK

2009-08-29 Thread 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

2009-08-29 Thread 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 bs.v...@gmail.com 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

2009-08-29 Thread 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 bs.v...@gmail.com 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

2009-08-29 Thread Saul Rennison
I hear your pain, bro.

Thanks,
- Saul.


2009/8/30 Jorge Rodriguez bs.v...@gmail.com

 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

2009-08-29 Thread 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 jscarsbr...@gmail.com
Sent: Sunday, August 30, 2009 9:18 AM
To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
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 bs.v...@gmail.com 
 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

2009-08-29 Thread 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 http://qsextreme.com/vbct/

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 bs.v...@gmail.com

   
 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

2009-08-29 Thread Jonathan Murphy
Lol, obvious troll, nice one Joshua.

On Sunday, August 30, 2009, Jonas 'Sortie' Termansen hlcod...@maxsi.dk 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 http://qsextreme.com/vbct/

 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 bs.v...@gmail.com


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

2009-08-29 Thread Joshua Scarsbrook
How.

Thanks
Vbitz

Jonathan Murphy wrote:
 Lol, obvious troll, nice one Joshua.

 On Sunday, August 30, 2009, Jonas 'Sortie' Termansen hlcod...@maxsi.dk 
 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 http://qsextreme.com/vbct/

 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 bs.v...@gmail.com


   
 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

2009-08-29 Thread 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] Possable Improvements to the Source SDK

2009-08-29 Thread 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 to...@valvesoftware.com 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