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
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
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 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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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.
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
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
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
, 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
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
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
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,
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
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
27 matches
Mail list logo
