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
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
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
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
Hello all.
So I'm trying to create a custom player by deriving it from CSDKPlayer, like so:
class CMyPlayer : public CSDKPlayer
{
// player things
};
I've got both the server and client players skeleton class build, I've
linked the class to the player entity with LINK_ENTITY_TO_CLASS, and
The official way to do this with the template is to copy all the SDK stuff
and rename it to what you want
On Sun, Aug 30, 2009 at 1:31 AM, Bob Somers magicbob...@gmail.com wrote:
Hello all.
So I'm trying to create a custom player by deriving it from CSDKPlayer,
like so:
class CMyPlayer :
So just do a global find/replace on CSDKPlayer to CMyPlayer?
--Bob
On Sat, Aug 29, 2009 at 5:35 PM, Stephen Swiresstephen.swi...@gmail.com wrote:
The official way to do this with the template is to copy all the SDK stuff
and rename it to what you want
On Sun, Aug 30, 2009 at 1:31 AM, Bob
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 don't have an SDK with me but there should be a set of macros used
to declare a factory for new entities.
On Sunday, August 30, 2009, Bob Somers magicbob...@gmail.com wrote:
So just do a global find/replace on CSDKPlayer to CMyPlayer?
--Bob
On Sat, Aug 29, 2009 at 5:35 PM, Stephen
After looking on the SDK do you have
DECLARE_CLASS(CMyPlayer, CSDKPlayer);
In the header declaration.
On Sunday, August 30, 2009, Jonathan Murphy nuclearfri...@gmail.com wrote:
I don't have an SDK with me but there should be a set of macros used
to declare a factory for new entities.
On
Yep. It also looks like LINK_ENTITY_TO_CLASS is the macro that creates
the factory.
--Bob
On Sat, Aug 29, 2009 at 6:06 PM, Jonathan Murphynuclearfri...@gmail.com wrote:
After looking on the SDK do you have
DECLARE_CLASS(CMyPlayer, CSDKPlayer);
In the header declaration.
On Sunday,
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
Issue solved. Here's the fix for the sake of the mailing list archives.
On first glance it looks like the assertion is raised because the
factory does not exist. Actually, it's raised because a factory for
that entity *already* exists.
This is because CSDKPlayer and C_SDKPlayer are linking
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
34 matches
Mail list logo
