Re: [hlcoders] Steam 2010 mod support and Source for the Mac
Though it is noted that some if not all of the files are still there, it could be down for massive changes or something On Sun, Apr 25, 2010 at 7:51 AM, Harry Jeffery harry101jeff...@googlemail.com wrote: Yeah, it 404'd before I grabbed a copy. Somewhere there is a Valve employee laughing at us. On 24 April 2010 19:57, Saul Rennison saul.renni...@gmail.com wrote: The steam_client_linux is now officially 404. :( Thanks, - Saul. On 24 April 2010 19:43, Harry Jeffery harry101jeff...@googlemail.com wrote: Awesome, thanks for posting. Evil valve for not telling. On 24 April 2010 17:52, Tom Edwards t_edwa...@btinternet.com wrote: This is the first hard evidence I've seen. Everything else so far (including the L4D Linux binaries) has been either definitely or potentially related to the dedicated server, but I don't see why you'd needt the graphics, friends or skins folders for that. On 24/04/2010 5:05, 1nsane wrote: Also this, apparently: http://www.reddit.com/r/linux/comments/butl8/steam_for_linux_testapp_thingy/ On Sat, Apr 24, 2010 at 11:37 AM, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote: From what I heard at http://www.phoronix.com/scan.php?page=articleitem=steam_linux_scriptnum=1 , they have found a bash script in the mac beta that adds future support for Linux. And they have also released .so files for Linux in Left 4 Dead once, and so on. There is some evidence but nothing I would consider valid proof of a Linux client coming in the near future. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Changing physics entities while holding them with the gravity gun
Could be a problem with the gravity gun code and how it picks up ents. The problem with your code is that you are not telling the gravgun anything has changed On 26/10/2009 3:22 p.m., Bob Somers wrote: Is it possible to alter physics entities while holding them with the gravity gun? In my mod, when a player is holding an object, they can press a button that changes the model of the object they're holding. I've got it working using this: // change the visual model SetModel(path/to/new/model.mdl); // reset the vphysics model, since the size of the object may have changed VPhysicsDestroyObject(); solid_t tmpSolid; PhysModelParseSolid(tmpSolid, this, GetModelIndex()); VPhysicsInitNormal(SOLID_VPHYSICS, 0, false,tmpSolid); It does indeed work, however when the VPhysics model is recreated, although the player still appears to be holding the object, they're not. As soon as they let go, the object is teleported back to lying on the ground where the player was standing when they changed it. Any way to fix this? Thanks. --Bob ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] whats happening with this engine
Worth noting that most of the larger projects where developed by engineers(in garrysmod) aside from source has kinda gone dormant unlike other engines, valve still gets a lot of sales but the engine has gone to sleep On 10/10/2009 10:21 a.m., BananaSandbags wrote: To better iterate on that though, I'm speaking of tiny sales compared to some Large titles, though gmod still does well all on it's own. http://www.garry.tv/wp-content/plugins/quickimg/image/f5db5c01d838401f39fda14271602a26.jpg http://www.garry.tv/wp-content/plugins/quickimg/image/f5db5c01d838401f39fda14271602a26.jpgAnd the demographic isn't that much of a problem, we all know how 13 year olds can be :/. Either way, the gameplay style attracts younger people more often, only because they seem to have a getter imagination than older people do. On Thu, Oct 8, 2009 at 11:42 PM, Cory de La Torregear@gmail.comwrote: Gmod already has tiny sales. If not for the demographic it's targeting 13-15 year olds. On Thu, Oct 8, 2009 at 11:25 PM, Harry Jeffery harry101jeff...@googlemail.com wrote: Cloverfield had great viral marketing. Very good film too. 2009/10/8 Joshua Scarsbrookjscarsbr...@gmail.com: Releasing a Game in secret is also known as viral marketing, but with steam the second it gets out the whole would will know and it will make the g mod sale look tiny On 9/10/2009 11:52 a.m., Adam Buckland wrote: Only the chosen few who believe will be able to play it... On 8 Oct 2009, at 22:48, Garry Newman wrote: I heard they're aiming to raise the bar by not only developing HL3 in secret - but also releasing it in secret. garry On Thu, Oct 8, 2009 at 9:36 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: Well what we want to know is what are the next features that are going to be added to source. Also an company as big as valve is going to tell the world of hl3 at E3. On 9/10/2009 5:31 a.m., botman wrote: On 10/8/2009 11:12 AM, Jorge Rodriguez wrote: This list is for programming in Source, not complaining about Source. Aren't they the same thing? ZING! :) ___ 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 -- Gear Dev ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] whats happening with this engine
Well what we want to know is what are the next features that are going to be added to source. Also an company as big as valve is going to tell the world of hl3 at E3. On 9/10/2009 5:31 a.m., botman wrote: On 10/8/2009 11:12 AM, Jorge Rodriguez wrote: This list is for programming in Source, not complaining about Source. Aren't they the same thing? ZING! :) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] whats happening with this engine
Releasing a Game in secret is also known as viral marketing, but with steam the second it gets out the whole would will know and it will make the g mod sale look tiny On 9/10/2009 11:52 a.m., Adam Buckland wrote: Only the chosen few who believe will be able to play it... On 8 Oct 2009, at 22:48, Garry Newman wrote: I heard they're aiming to raise the bar by not only developing HL3 in secret - but also releasing it in secret. garry On Thu, Oct 8, 2009 at 9:36 PM, Joshua Scarsbrookjscarsbr...@gmail.com wrote: Well what we want to know is what are the next features that are going to be added to source. Also an company as big as valve is going to tell the world of hl3 at E3. On 9/10/2009 5:31 a.m., botman wrote: On 10/8/2009 11:12 AM, Jorge Rodriguez wrote: This list is for programming in Source, not complaining about Source. Aren't they the same thing? ZING! :) ___ 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] Dynamic weapon attachments
Well is the achievement weapons in tf2 not a good example how, it does exactly what you want to do, it uses effects and works with only one model for both world and view. On 7/10/2009 7:30 p.m., Jorge Rodriguez wrote: On Tue, Oct 6, 2009 at 1:18 AM, Minhminh...@telus.net wrote: Imagine trying to make an animation where the player switches the gun from one hand to another, or he holds the gun from a different part of the gun at different part of the animation. This sort of stuff is easy to do when the bones are all animated and exported in their own local space. It gets tricky to do this with third person anims cuz you have to work closely with the code to detach the model from the hand at various points in the animation. ... or you can make a separate bone that's not part of the biped heirarchy that holds the weapon position, and animate it just as you would a weapon in a v model animation. That said you're still right, having w models in the v does put some restrictions on view model dynamics, and there are a lot more problems to solve than if you just have a separate v model. The plus side of it though is you get a lot more of a real feeling in the view without having to do a lot of duplication of work to model and animate things twice. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ShouldCollide()
Well valve should have backwards compatabilty code, try the old version. aside from that Tony may have some sugestions for the older code, since it is defined in a libary then i can not change it. Bob Somers wrote: So I'm looking through some previous source code we've got, and I noticed that gamerules.cpp used to expose a ShouldCollide function with this signature: ShouldCollide( int collisionGroup0, int collisionGroup1, CBaseEntity *pEnt, CBaseEntity *pPass ) but in the newest SDK code it only exposes a function with this signature: ShouldCollide( int collisionGroup0, int collisionGroup1 ) Is there any way to either (1) use the previous function signature, so I have access to the entities being tested for collision or (2) use the newer function signature, but somehow get access to the two entities being tested? Thanks. --Bob ___ 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] Water Buoyancy
Well look at the airboat code, it works on all types of water and it is done using code pPhysAirboat-SetBuoyancyRatio( 0.0f ); PhysSetGameFlags( pPhysAirboat, FVPHYSICS_HEAVY_OBJECT ); well it uses the same code but it is zero Ryan Horton wrote: I'm trying to make certain props float when they otherwise wouldn't / shouldn't (for example, large metal objects) Now, I've gotten this to work to an extent, using IPhysicsObject::SetBuoyancyRatio() However, it seems that the way this works depends upon the material used maybe? So, for example, if I do BigMetalThing-SetBuoyancyRatio( 0.085 ) in one type of water (the murky, poisonous canal water), it floats well, but in a different type of water (clear, plain water), it floats poorly. So I'm wanting to make it so I don't have to save custom buoyancies on a per material basis (assuming the material is what's causing this behavior), how do I go about modifying the 'buoyancy factor' so that all water entities are created equal? Thanks! Ryan ___ 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] Audio Programming-Beat counter
well i would say to calc the audio beat there is a calculus forumla that can be applyed to certin audio files, that would be fastest botman wrote: What a coincidence! I've been doing some research recently on beat tracking also. I'm not sure if it's possible through Source, but here are some resources: http://www.owlnet.rice.edu/~elec301/Projects01/beat_sync/beatalgo.html http://www.gamedev.net/reference/articles/article1952.asp http://werner.yellowcouch.org/Papers/bpm04/ http://code.compartmental.net/tools/minim/manual-beatdetect/ Masataka Goto did a lot of work in psychoacoustics: http://staff.aist.go.jp/m.goto/ His work on beat tracking is here... http://staff.aist.go.jp/m.goto/PROJ/bts.html The best I've seen so far was work done by Eric Scheirer http://en.scientificcommons.org/eric_d_scheirer His Temp and beat analysis of acoustic musical signals can be found here (WARNING!!! Lots of complex signal processing math ahead)... http://www.iro.umontreal.ca/~pift6080/H09/documents/papers/scheirer_jasa.pdf On 9/25/2009 9:26 AM, Charkrid Pornpitackchaikul wrote: Hi guys, I don't have any experience with audio programming. May be someone can point me to the right direction. How can I write a audio beat counting code by Source Audio Engine? What should I look for? I traced the code for quite sometime but I can't find anything that seem like can use for capture/find wave peak data. The thing I want to do is, I want to difference loop mixing together like a DJ mixing with 2 turntables. Appreciate any suggestion. Thanks in advance. :) Charkrid P. ___ 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] Half-Life 1 frame-by-frame gameplay?
I recal a youtube video that rendered hl1 frame by frame, just search youtube for nuclear halflife hammer Olivér Horváth wrote: As far as i know, no one has the full, up-to-date Half-Life 1 1.1.2.1 or even the 1.1.0.8 SDK all-in-all @ SDA. Does the downloadable Half-Life SDK 2.3 has a function that processed each frame? Please let me know it, because I couldn't find (not mentioning that I couldn't compile it dunno why). And is it the same like 1.1.0.8? However it would be a pain in the ass to make a speedrun while alt-tabbing like a maniac cause of break. It would be a dream if the source code would be free and I could just simply put in a readkey : ( 2009/9/22 Heimo Stieg gr...@corona-bytes.net Just hit break in the debugger? Olivér Horváth schrieb: No, I tried it numerous times. The command pause doesn't stops anything, only the entities has no chance to change they speed. You can write messages, look at entities special effects (which is animated, and you will see it animated while in pause mode), and the biggest thing that we would like to allow: the client communicates with the server. I think I wasn't clear or something, so once again: I would like to achieve that there is ABSOLUTELY NO packet send/recieve between the server and client while there's a real breakdown mode. I think that this can't be made with pure commands. I hope that someone, maybe on of the Half-Life 1 maker should read my question, because I don't think that anyone else should know, that there's a possibility of stopping the network data for a period of time and also stop frame processing and advance one frame whenever I want it. By the way, I'm glad that I found a place where I can get answer for this question, and that you answer it. 2009/9/22 Rodrigo 'r2d2rigo' Diaz r2d2r...@gmail.com Huh? In single-player game, pause command stops *everything*, except VGUI interaction. 2009/9/22 Olivér Horváth ol...@cubeclub.hu I think that I tried every console command, but none of them makes the gameplay TOTALLY freeze. This is very essential. The command pause only blocks the players from move, that's all, and everything else still works. I doubt that there would be any command that should TOTALLY blocks client/server communication for a period of time (of course maybe lag should work...). 2009/9/22 Joshua Scarsbrook jscarsbr...@gmail.com Well the easyest way i see to do this is with a little script involving pause and some sort of scripting wait command if that is possable. something with making a command, i have never played hl1 but i am relativly good at hl2 scripting and programming convensions Saul Rennison wrote: Isn't there a command called *singlestep*? If so, then do: bind *key* next 1 singlestep Then press *key* to advance a frame :) Thanks, - Saul. 2009/9/21 Olivér Horváth ol...@cubeclub.hu Wow thanks for the fast response. Well, I already tried every cvar, but none of them makes the gameplay frame-by-frame. using the host_framerate or pause; wait; pause method won't interrupt the server-client communcation. So this is basicly only a visual frame advancing, and we would need real frame advancing. However I don't have the real, full, compilable HL source code, and the downloadable free hl sdk doesn't has the server_frame function or anything that processed in every frame. The best thing should be to have the same DemoPlayer's gui @ HL singleplayer. 2009/9/21 Rodrigo 'r2d2rigo' Diaz r2d2r...@gmail.com Try using the convars host_framerate and pause. 2009/9/21 Olivér Horváth ol...@cubeclub.hu Hello everybody, my nickname is MESHUGGAH, a speedrun fan. We have a (currently in hold) Half-life 1 TAS [tool assisted] speedrun project @ SDA (speeddemosarchive.com) and we have some questions about the HL engine. We would like to achieve a frame-by-frame (frame advancing when you press a specific key) gameplay to abuse every bug and glitch in HL. However the full HL SDK (as far as I know) doesn't gives me possibility to have a custom function that would interrupt everything and making a TOTAL engine-pause whenever there's a frame advance. So my question would be this: Is there any possible way to play the game frame
Re: [hlcoders] In game map editing
Correct, this will allow you to put props on a map, you do need the vmf file, and yes it will save the map. John Brennan wrote: Thanks for the response I appreciate it, but i swear i did an exhaustive search of gmod and facepunch forums before i bugged yah. All i can find is a VMF suite which allows loading of vmfs while in game, but we are both referring to lua code that lets you place props while in gmod and have this update the map vmf am i right? best jb On Tue, Sep 22, 2009 at 11:16 PM, Joshua Scarsbrook jscarsbr...@gmail.com mailto:jscarsbr...@gmail.com wrote: Well jsut look on garrysmod.org http://garrysmod.org. anyway it should be bacic c++ to use it in the sdk alone John Brennan wrote: Hey Josh, forgive me for emailing you directly, but RE: Well this has already been done in an unpolished way using lua. There is a tool made by a comunatiy member that takes a vmf file with the bsp loaded into the engine and saves any new props added to it. This would not be hard to change for all ents. Do you have any idea what this is called/where i can find it? Been looking for a while now. Best jb ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Half-Life 1 frame-by-frame gameplay?
Well for one you will need to use quakeworld engine and for 2 valve uses apis and wrapers, rewriting goldsrc is out of the question. just make a program to render the bsp using blender. Olivér Horváth wrote: :D Thank you for the valuable informations! Now I'm thinking about making a hack... 2009/9/23 botman botman.hlcod...@gmail.com Yes. Get hired on at Valve as a full time employee, walk down the hall, poke your head into one of the Valve old timers' office and say Hey, I have a question about the Quiver engine. :) They read this list. If they are going to answer your question, they will. If not, they won't. I doubt what you want is possible as it would require access to the Half-Life engine source code which was never publicly released (even the NDA released source code early on only covered the AI code that was eventually released publicly without requiring an NDA, as I understand it). You would be better off starting with the Quake source code and trying to implement Half-Life's C++ code on top of it. At least then you'd have access to the engine source code needed to make the kind of change you are wanting. On 9/23/2009 6:58 AM, Olivér Horváth wrote: Is there any way to direct-contact the valve software's Half-Life 1 engine coders? 2009. szeptember 23. 13:57 Olivér Horváth írta,ol...@cubeclub.hu: I searched for it, and found: http://www.youtube.com/watch?v=bqo9o9OzyxA However he probably used pause; wait; pause or host_framerate which already mentioned that it won't help us. I don't have idea why would he used a complex, total frame advancing without client/server communication, when the purpose was to make a video. This is still a visual frame by frame advancing. 2009/9/23 Joshua Scarsbrookjscarsbr...@gmail.com I recal a youtube video that rendered hl1 frame by frame, just search youtube for nuclear halflife hammer Olivér Horváth wrote: As far as i know, no one has the full, up-to-date Half-Life 1 1.1.2.1 or even the 1.1.0.8 SDK all-in-all @ SDA. Does the downloadable Half-Life SDK 2.3 has a function that processed each frame? Please let me know it, because I couldn't find (not mentioning that I couldn't compile it dunno why). And is it the same like 1.1.0.8? However it would be a pain in the ass to make a speedrun while alt-tabbing like a maniac cause of break. It would be a dream if the source code would be free and I could just simply put in a readkey : ( 2009/9/22 Heimo Stieggr...@corona-bytes.net Just hit break in the debugger? Olivér Horváth schrieb: No, I tried it numerous times. The command pause doesn't stops anything, only the entities has no chance to change they speed. You can write messages, look at entities special effects (which is animated, and you will see it animated while in pause mode), and the biggest thing that we would like to allow: the client communicates with the server. I think I wasn't clear or something, so once again: I would like to achieve that there is ABSOLUTELY NO packet send/recieve between the server and client while there's a real breakdown mode. I think that this can't be made with pure commands. I hope that someone, maybe on of the Half-Life 1 maker should read my question, because I don't think that anyone else should know, that there's a possibility of stopping the network data for a period of time and also stop frame processing and advance one frame whenever I want it. By the way, I'm glad that I found a place where I can get answer for this question, and that you answer it. 2009/9/22 Rodrigo 'r2d2rigo' Diazr2d2r...@gmail.com Huh? In single-player game, pause command stops *everything*, except VGUI interaction. 2009/9/22 Olivér Horváthol...@cubeclub.hu I think that I tried every console command, but none of them makes the gameplay TOTALLY freeze. This is very essential. The command pause only blocks the players from move, that's all, and everything else still works. I doubt that there would be any command that should TOTALLY blocks client/server communication for a period of time (of course
Re: [hlcoders] In game map editing
Well this has already been done in an unpolished way using lua. There is a tool made by a comunatiy member that takes a vmf file with the bsp loaded into the engine and saves any new props added to it. This would not be hard to change for all ents. Ryan Sheffer wrote: VMF files just use the standard keyvalues syntax so I don't see a problem. I'm sure Garry has exposed creating and exporting of KV files through lua. On Sun, Sep 20, 2009 at 1:02 PM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: True this has been done using a simple stool, the mesh building is built using a conblocks system and each object is a entiry, i am starting to think that using it in garrysmod would allow saving to a vmf, but i am not completely sure, i have the vmf for the conblocks map already and i think a modded version without the system would work fine Ryan Sheffer wrote: If you could use mesh builder to build the mesh ingame with an interface and such, and once done have the ability to get all vertex positions and export that correctly to a VMF file which you would then compile. Placing entities could be done the same way, in fact this has already been done for garrys mod. A project like this would be a lot of unnecessary work, but would be pretty interesting. On Sat, Sep 12, 2009 at 5:01 PM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: Hi Thanks for the hint about the map, i have seen one made for hl2ep2 as well called cb_conblocks and i finaly got a download link for it. http://solidfiles.com/d/BCs9, this map is just like the portal one but for hl2ep2 Thanks, Vbitz Lech wrote: I believe someone already did something like this for portal: http://www.youtube.com/watch?v=65EDQB4OWcg While I don't know the exact specifics behind what else might be needed or how well it works, you can however see everything from building the map to applying game logic available from right within portal itself. -L On Sat, Sep 12, 2009 at 5:25 PM, Harry Jeffery harry101jeff...@googlemail.com wrote: Or go fullbright and apply a drawdistance of 1024 units to keep the fps friendly. 2009/9/12 Andrew Ritchie gotta...@gmail.com: VMF != BSP You CAN reference brushes and things back to the VMF from a BSP but I'd suggest you go and do a little more reading and file browsing to see why what you are suggesting would require the elimination of seperate file formats and if you want it in real time either an massive overhaul of the RAD calculation or full transition to dynamic lighting. On Sat, Sep 12, 2009 at 11:07 PM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: Well the vmf file contains alot of data and it is easy to draw the brushs but you can still not do lighting without alot of extra work on valves part. from what i know we can have a map load draw brushs and put colsision physics on it, is that not something that can be doen with the sdk, anyway the uses of this are opening map editing to more less knolageable players wanting to make a map. Andrew Ritchie wrote: What would the difference between this and normal hammer be? The only thing you could do was run game logic, you'd still have to run the compilers each time to see the resulting changes. There are rough features in place that make it appear like at some point Source was able to talk back to Hammer, especially with the Source BSP format having precompiled brush data in it. However the advantages of the feature you want and hammer is nothing, except ingame you'd have to reload the map all the time. On Sat, Sep 12, 2009 at 10:45 PM, Matt Hoffman lord.matt.hoff...@gmail.comwrote: Because this totally doesn't go against the BSP/Compile mindset? On Sat, Sep 12, 2009 at 2:43 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: Hi I was wondering if it is possable to make a version of hammer that works ingame and renders the vmf as somesort of mesh and then allows you to edit it using ingame tools. Thanks, Vbitz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http
Re: [hlcoders] How safe is it to travel into The Void
well thanks for the help but i have been into the void with no ill effects once i was done i exited normaly, using garrysmod and entiry debugging, and a overly complex watching station, i was able to get a prop and a entiry to travel down to over -100 z units. Damian Pursey wrote: ^Wow, I just tried that, that's something. Either way, as much as I know about the void, I know it's smart to avoid it. In one map I made, I used a big giant room with black texture on the inside, and invisible on the outside (I don't know if that was necessary or not), then I made another room about 1 unit away from that with a sky texture. Then I used a light_environment and lit the map as if it had a black skybox. I'm not sure what you're trying to accomplish, but it might help. On Sun, Sep 20, 2009 at 7:57 AM, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote: In portal, I once made a portal into the void using Hammer. That was interesting. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ 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] In game map editing
True this has been done using a simple stool, the mesh building is built using a conblocks system and each object is a entiry, i am starting to think that using it in garrysmod would allow saving to a vmf, but i am not completely sure, i have the vmf for the conblocks map already and i think a modded version without the system would work fine Ryan Sheffer wrote: If you could use mesh builder to build the mesh ingame with an interface and such, and once done have the ability to get all vertex positions and export that correctly to a VMF file which you would then compile. Placing entities could be done the same way, in fact this has already been done for garrys mod. A project like this would be a lot of unnecessary work, but would be pretty interesting. On Sat, Sep 12, 2009 at 5:01 PM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: Hi Thanks for the hint about the map, i have seen one made for hl2ep2 as well called cb_conblocks and i finaly got a download link for it. http://solidfiles.com/d/BCs9, this map is just like the portal one but for hl2ep2 Thanks, Vbitz Lech wrote: I believe someone already did something like this for portal: http://www.youtube.com/watch?v=65EDQB4OWcg While I don't know the exact specifics behind what else might be needed or how well it works, you can however see everything from building the map to applying game logic available from right within portal itself. -L On Sat, Sep 12, 2009 at 5:25 PM, Harry Jeffery harry101jeff...@googlemail.com wrote: Or go fullbright and apply a drawdistance of 1024 units to keep the fps friendly. 2009/9/12 Andrew Ritchie gotta...@gmail.com: VMF != BSP You CAN reference brushes and things back to the VMF from a BSP but I'd suggest you go and do a little more reading and file browsing to see why what you are suggesting would require the elimination of seperate file formats and if you want it in real time either an massive overhaul of the RAD calculation or full transition to dynamic lighting. On Sat, Sep 12, 2009 at 11:07 PM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: Well the vmf file contains alot of data and it is easy to draw the brushs but you can still not do lighting without alot of extra work on valves part. from what i know we can have a map load draw brushs and put colsision physics on it, is that not something that can be doen with the sdk, anyway the uses of this are opening map editing to more less knolageable players wanting to make a map. Andrew Ritchie wrote: What would the difference between this and normal hammer be? The only thing you could do was run game logic, you'd still have to run the compilers each time to see the resulting changes. There are rough features in place that make it appear like at some point Source was able to talk back to Hammer, especially with the Source BSP format having precompiled brush data in it. However the advantages of the feature you want and hammer is nothing, except ingame you'd have to reload the map all the time. On Sat, Sep 12, 2009 at 10:45 PM, Matt Hoffman lord.matt.hoff...@gmail.comwrote: Because this totally doesn't go against the BSP/Compile mindset? On Sat, Sep 12, 2009 at 2:43 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: Hi I was wondering if it is possable to make a version of hammer that works ingame and renders the vmf as somesort of mesh and then allows you to edit it using ingame tools. 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
Re: [hlcoders] How safe is it to travel into The Void
Thanks for the help So what you are saying is in mutliplayer games atempt to travel into the void will resalt in well hitting a invisable wall. anyway i can happly get ents to travel down there with no ill effects, i went down to -100 with no effects. so the void is fun to explore but there are still boundrys i will hit, such as objects not being rendered and lighting being messed up. from what you are saying with the code example by changing the floot i can remove void boundrys Justin Krenz wrote: #define MAX_COORD_FLOAT (16384.0f) Anything outside of the coordinates 16384 to -16384 is not going to function properly, and anything outside of this range is going to be clamped to the proper range when networked. Go ahead and play in the void all you want like it's some magical world, but remember that in the end, it's still restricted to the underlying programming. On Sun, Sep 20, 2009 at 2:50 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: well thanks for the help but i have been into the void with no ill effects once i was done i exited normaly, using garrysmod and entiry debugging, and a overly complex watching station, i was able to get a prop and a entiry to travel down to over -100 z units. Damian Pursey wrote: ^Wow, I just tried that, that's something. Either way, as much as I know about the void, I know it's smart to avoid it. In one map I made, I used a big giant room with black texture on the inside, and invisible on the outside (I don't know if that was necessary or not), then I made another room about 1 unit away from that with a sky texture. Then I used a light_environment and lit the map as if it had a black skybox. I'm not sure what you're trying to accomplish, but it might help. On Sun, Sep 20, 2009 at 7:57 AM, Jonas 'Sortie' Termansen hlcod...@maxsi.dk wrote: In portal, I once made a portal into the void using Hammer. That was interesting. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ 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
[hlcoders] How safe is it to travel into The Void
Hi Using Garrysmod and Entiry Infomation Outputs i was able to send a normal prop down to a z of - 16000 aprox without a crash, the map i made is designed to work well with the void, it has a semi sealable leek that is a large door and a area out into the void. All of this has been done in hl2ep2 engine and has worked without a sign of abnormalty, no console spam, so i am asking here, how safe is the Void? i have already found that the crashing that is normal is caused by a complex map, so i do not know alot about the void and i want to know what problems i will encounter, i am thinking that if i travel down to about -10 there could be a buffer overflow and a engine crash but aside from that, what problems will i encounter. Thanks, Vbitz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] How safe is it to travel into The Void
Well for one going into the leak is exploring the source engine and it is fun, for 2 the door will stop the leak from rendering. also i have found render target cameras do not have the rendering problem Matt Hoffman wrote: Erm. Can you explain to me... WHY you want to go into the void? And how do you have a semi-sealable leak? The door won't stop the leak as it's a brush entity... So it's a leak On Sat, Sep 19, 2009 at 10:27 PM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: Hi Using Garrysmod and Entiry Infomation Outputs i was able to send a normal prop down to a z of - 16000 aprox without a crash, the map i made is designed to work well with the void, it has a semi sealable leek that is a large door and a area out into the void. All of this has been done in hl2ep2 engine and has worked without a sign of abnormalty, no console spam, so i am asking here, how safe is the Void? i have already found that the crashing that is normal is caused by a complex map, so i do not know alot about the void and i want to know what problems i will encounter, i am thinking that if i travel down to about -10 there could be a buffer overflow and a engine crash but aside from that, what problems will i encounter. 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
[hlcoders] In game map editing
Hi I was wondering if it is possable to make a version of hammer that works ingame and renders the vmf as somesort of mesh and then allows you to edit it using ingame tools. Thanks, Vbitz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] In game map editing
Well the vmf file contains alot of data and it is easy to draw the brushs but you can still not do lighting without alot of extra work on valves part. from what i know we can have a map load draw brushs and put colsision physics on it, is that not something that can be doen with the sdk, anyway the uses of this are opening map editing to more less knolageable players wanting to make a map. Andrew Ritchie wrote: What would the difference between this and normal hammer be? The only thing you could do was run game logic, you'd still have to run the compilers each time to see the resulting changes. There are rough features in place that make it appear like at some point Source was able to talk back to Hammer, especially with the Source BSP format having precompiled brush data in it. However the advantages of the feature you want and hammer is nothing, except ingame you'd have to reload the map all the time. On Sat, Sep 12, 2009 at 10:45 PM, Matt Hoffman lord.matt.hoff...@gmail.comwrote: Because this totally doesn't go against the BSP/Compile mindset? On Sat, Sep 12, 2009 at 2:43 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: Hi I was wondering if it is possable to make a version of hammer that works ingame and renders the vmf as somesort of mesh and then allows you to edit it using ingame tools. 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] In game map editing
Hi Thanks for the hint about the map, i have seen one made for hl2ep2 as well called cb_conblocks and i finaly got a download link for it. http://solidfiles.com/d/BCs9, this map is just like the portal one but for hl2ep2 Thanks, Vbitz Lech wrote: I believe someone already did something like this for portal: http://www.youtube.com/watch?v=65EDQB4OWcg While I don't know the exact specifics behind what else might be needed or how well it works, you can however see everything from building the map to applying game logic available from right within portal itself. -L On Sat, Sep 12, 2009 at 5:25 PM, Harry Jeffery harry101jeff...@googlemail.com wrote: Or go fullbright and apply a drawdistance of 1024 units to keep the fps friendly. 2009/9/12 Andrew Ritchie gotta...@gmail.com: VMF != BSP You CAN reference brushes and things back to the VMF from a BSP but I'd suggest you go and do a little more reading and file browsing to see why what you are suggesting would require the elimination of seperate file formats and if you want it in real time either an massive overhaul of the RAD calculation or full transition to dynamic lighting. On Sat, Sep 12, 2009 at 11:07 PM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: Well the vmf file contains alot of data and it is easy to draw the brushs but you can still not do lighting without alot of extra work on valves part. from what i know we can have a map load draw brushs and put colsision physics on it, is that not something that can be doen with the sdk, anyway the uses of this are opening map editing to more less knolageable players wanting to make a map. Andrew Ritchie wrote: What would the difference between this and normal hammer be? The only thing you could do was run game logic, you'd still have to run the compilers each time to see the resulting changes. There are rough features in place that make it appear like at some point Source was able to talk back to Hammer, especially with the Source BSP format having precompiled brush data in it. However the advantages of the feature you want and hammer is nothing, except ingame you'd have to reload the map all the time. On Sat, Sep 12, 2009 at 10:45 PM, Matt Hoffman lord.matt.hoff...@gmail.comwrote: Because this totally doesn't go against the BSP/Compile mindset? On Sat, Sep 12, 2009 at 2:43 PM, Joshua Scarsbrook jscarsbr...@gmail.com wrote: Hi I was wondering if it is possable to make a version of hammer that works ingame and renders the vmf as somesort of mesh and then allows you to edit it using ingame tools. 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 ___ 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
[hlcoders] Possable Improvements to the Source SDK
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
Re: [hlcoders] Possable Improvements to the Source SDK
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
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
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
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
Re: [hlcoders] Possable Improvements to the Source SDK
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
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
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] Erour in OB Mod
Thanks for all the help Tony, it is now working fine and i will try to
put in the graple hook once i have made some changes
Vbitz
Tony Sergi wrote:
No it was my fault. In basegrenade_shared.h I was making changes purely for
the SDK because I didn't want the scratch SDK to have grenades as
basecombatcharacter. But HL2MP needs it for the tripmines, and singleplayer
needs it for the barnacles.
If you change the declaration in game\shared\basegrenade_shared.h to this
(it's kind of messy because of the #ifdefs) it'll work.
//Tony; Compromise! in episodic single player, inherit CBaseCombatCharacter
for the barnacle interaction, otherwise this will never get called.
class CBaseGrenade :
#if defined( HL2_EPISODIC ) || defined ( HL2MP )//Tony; HL2MP
needs this too for tripmine grenades.
public CBaseCombatCharacter
#else
public CBaseAnimating
#endif
#if defined( GAME_DLL )
, public CDefaultPlayerPickupVPhysics
#endif
{
DECLARE_CLASS( CBaseGrenade, CBaseAnimating );
public:
-Tony
-Original Message-
From: hlcoders-boun...@list.valvesoftware.com
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Jorge Rodriguez
Sent: August-25-09 12:34 AM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Erour in OB Mod
You have a function definition, looking similar to:
void CBaseGrenade::HandleInteraction()
{
// ... blah blah
}
You must have copied a function from CBaseGrenade and tried to add it to
grenade_frag.cpp because the compiler is complaining. The function is
declared as a member of CBaseGrenade when it needs to be CHL2GrenadeFrag or
whatever.
This is a pretty simply C++ syntax problem. If you're getting in over your
head with the (complicated) C++ syntax, I recommend starting with something
simpler than what you're doing, and reading more about how C++ works.
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Erour in OB Mod
thanks for the help, the problem was i did not compile the server dll silly mistake Minh wrote: your network datatables are not matching on the client and server. Make sure you have a corresponding RecvProp (in the client table) for each SendProp (in the server table) Joshua Scarsbrook wrote: Hi When i try to start the first map in hl2ep2 on my mod i get this in the console Initializing renderer... Missing RecvProp for DT_BaseGrenade - DT_BaseFlex/baseclass Host_EndGame: CL_ParseClassInfo_EndClasses: CreateDecoders failed. Please help with this 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] Erour in OB Mod
1grenade_frag.cpp 1.\hl2\grenade_frag.cpp(409) : error C2039: 'HandleInteraction' : is not a member of 'CBaseGrenade' 1c:\CeraMod\src\game\shared\basegrenade_shared.h(34) : see declaration of 'CBaseGrenade' Fixed the old compile problem but now i have a new one. the base is having a problem somewere, this is bacic obcode. Minh wrote: your network datatables are not matching on the client and server. Make sure you have a corresponding RecvProp (in the client table) for each SendProp (in the server table) Joshua Scarsbrook wrote: Hi When i try to start the first map in hl2ep2 on my mod i get this in the console Initializing renderer... Missing RecvProp for DT_BaseGrenade - DT_BaseFlex/baseclass Host_EndGame: CL_ParseClassInfo_EndClasses: CreateDecoders failed. Please help with this 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] Erour in OB Mod
Thanks for the help, i traced the problem and have still not found where it is Minh wrote: The answer is in the error msg. I couldn't put it any clearer than the error msg. Joshua Scarsbrook wrote: 1grenade_frag.cpp 1.\hl2\grenade_frag.cpp(409) : error C2039: 'HandleInteraction' : is not a member of 'CBaseGrenade' 1c:\CeraMod\src\game\shared\basegrenade_shared.h(34) : see declaration of 'CBaseGrenade' Fixed the old compile problem but now i have a new one. the base is having a problem somewere, this is bacic obcode. Minh wrote: your network datatables are not matching on the client and server. Make sure you have a corresponding RecvProp (in the client table) for each SendProp (in the server table) Joshua Scarsbrook wrote: Hi When i try to start the first map in hl2ep2 on my mod i get this in the console Initializing renderer... Missing RecvProp for DT_BaseGrenade - DT_BaseFlex/baseclass Host_EndGame: CL_ParseClassInfo_EndClasses: CreateDecoders failed. Please help with this 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] Erour in OB Mod
I aggre that it is a simple sort of problem and fixing it should be no
problem but i have not made a single mod to this code other then leting
it compile under vs2008 express. i do have full media for vs2005
professenal and will install it if the problem is not resolved.
Thanks
Vbitz
Jorge Rodriguez wrote:
You have a function definition, looking similar to:
void CBaseGrenade::HandleInteraction()
{
// ... blah blah
}
You must have copied a function from CBaseGrenade and tried to add it to
grenade_frag.cpp because the compiler is complaining. The function is
declared as a member of CBaseGrenade when it needs to be CHL2GrenadeFrag or
whatever.
This is a pretty simply C++ syntax problem. If you're getting in over your
head with the (complicated) C++ syntax, I recommend starting with something
simpler than what you're doing, and reading more about how C++ works.
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Erour in OB Mod
Hi When i try to start the first map in hl2ep2 on my mod i get this in the console Initializing renderer... Missing RecvProp for DT_BaseGrenade - DT_BaseFlex/baseclass Host_EndGame: CL_ParseClassInfo_EndClasses: CreateDecoders failed. Please help with this Vbitz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Trying to Create a Zipline
Hi Thanks for the help Justin. Physics for a droping player would lag like there is no end to the lag. aside from that i have read gamemovement.cpp, also worth noting i have used hl2 graples befor and i have smachball. i can see where the movement types are defined and will try to make a new one. i will try to make a sort of rope thay pigey backs off a crossbow bolt that is effected by like 3 times normal phys Thanks Vbitz Justin Krenz wrote: I coded the grappling hook for Smashball. It's coded as a movement type in gamemovement.cpp and does not use the physics engine at all so that client-side prediction works. You should absolutely avoid the physics engine if you're doing anything that controls the player's movement. On Thu, Aug 20, 2009 at 2:32 PM, Ben Mearsbenmea...@gmail.com wrote: Have you heard about the mod Smashball ? You can download it from the Mods section of Steam. They have a grappling hook type weapon that sounds pretty close to what you're trying to do. Maybe somebody from that team could help you (but maybe they won't want to divulge their secrets either, ha ha) On Thu, Aug 20, 2009 at 11:20 AM, Joshua Scarsbrook jscarsbr...@gmail.comwrote: Hi I am trying to create a mod with weapons that shot ziplines for players to move from one point to another. i was woundering how i would go about creating one. I have been learning c++ for quite a while now and have spent the last year working on 3d programmig. I know i will need 3 entries and a weapon. The weapon will use the crossbow for it's model and the entires will use the little coke can or a harpoon. I was wondering what code i would need to use and where. Thanks in Advance 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] Where to begin?
Hi Good to see another programmer here. you are going to run into a copple problems with this. you have the power to use alot of calls but the renderer is hardcoded in the engine. you can only mod the game logic. number2 you will need the directx sdk. you need c++ 2005 express at the very least. Hope this Helps Vbitz Fred Baba wrote: Hello all, I'm a fairly experienced programmer (Java, C++, Lisp, some OpenGL), but new to the HL/Source Engine development scene. I have a game idea, but I'm currently at a loss as to where to begin. I considered just building the game from the ground up and pulling in elements of the SDK as needed, but this seemed like a suboptimal approach. Furthermore, I've found the Valve documentation to be less than useful, since it doesn't provide a conventional API reference as far as I can tell (though I built my own in Doxygen from the source, but it's not that great). I also considered sucking it up and reading through the source for Forsaken (http://www.moddb.com/mods/forsaken/downloads/forsaken-assets-source-code) in its entirety. I'm less interested in modding HL2 and more interested in a standalone game leveraging the SDK. This may not even be the write place to post this, nonetheless any assistance would be greatly appreciated. Thanks, Fred Baba p.s. I use the gnu tool chain under Mac OS X. I have a strong aversion to Visual Studio... ___ 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] Lines of code in Source SDK?
Based on the Question I would say that you also need to include stuff in the source for the mapping tools. The question needs to be more detailed. But based on Bucky's question i would say that it would be andrews figere that is most acurate as a baseline. you need to remember that if you are using this to show how big the project you are taking on is then you need to know you do not need to mod every file, only the stuff that changes the things you need. Hope that helps Vbitz Andrew Ritchie wrote: 400k+ Depending on what you define as code it could be much more but there's atleast that. Only within the Client and Server projects, and it's always up for debate how much of it is functionally part of each project. On Wed, Aug 19, 2009 at 1:34 AM, Adam Buckland adamjbuckl...@gmail.comwrote: Just a quick question: How many lines of code would you estimate, make up the Source SDK? -- Bucky ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Trying to Create a Zipline
Hi I am trying to create a mod with weapons that shot ziplines for players to move from one point to another. i was woundering how i would go about creating one. I have been learning c++ for quite a while now and have spent the last year working on 3d programmig. I know i will need 3 entries and a weapon. The weapon will use the crossbow for it's model and the entires will use the little coke can or a harpoon. I was wondering what code i would need to use and where. Thanks in Advance Vbitz ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
