Re: [hlcoders] Successful mod team tips and warstories?
-- [ Picked text/plain from multipart/alternative ] Sorry, going backwards a little here, but about realism. I tend to stay away from that sort of gameplay, it bores me alot. Recently on the BG2 forums I have been fighting to keep anal realism out of what is generally a rather arcadish game. The topic is iron sights, which is strange considering the guns didn't have sights and the soldiers were trained to just point and shoot at a clump of enemies and hope it hits(excluding skirmishers of course). I guess what I'm getting at here, is has your community ever zerged a crappy suggestion into your mod? has there ever been such overwhelming support for something you don't like but have felt obliged to add? I can see both sides, your players want you to make their game, while we want to make ours. Do tell. -- Draco -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Animation Events
-- [ Picked text/plain from multipart/alternative ] I'm attempting to add a new animation event to test view punches with reloading (COD2-esque). However, I honestly have no idea where to start for this. I'm actually feeling rather stupid with my current problems, as I've figured out much more difficult ones. As a test I tried adding a viewpunch in the AE_CL_PLAYSOUND event (case statements in c_baseviewmodel and c_baseanimating) however I couldn't get the view punch to work (casting C_BasePlayer::GetLocalPlayer() to pPlayer and using pPlayer->ViewPunch) but the view punch doesn't even work here. Can anyone point me in the right direction as to what I'm doing wrong with my viewpunch code, and how to add an entirely new event I can specify in the model events (CL_VIEWPUNCH and params of X and Y values to punch by) Thanks all, Matt -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Successful mod team tips and warstories?
In Forsaken, we get this a lot. The community is die-hard on having vehicles and iron-sights in game but we believe it doesn't fit into the world. The point is to take their suggestions, discuss it, and maybe have a little test version with one weapon in the game. If you feel it doesn't mesh well with the entire feel after going this far you have to be willing to put your foot down. You don't know how many times I've gotten some pretty nasty messages from community members because I have had to shoot down their ideas... it really is a fine line between making the game that you guys dream of and the game that they want. We've also had some issues on keeping our internal alphas from being leaked out. Forsaken has taken the standpoint of gameplay first, polish later. Whilst our popularity isn't outstanding by any means, we do have a few core members that annoy us everyday about the progress of the mod. We had to tell the person, in good faith, to just delete the installer and not run it. It's at a point where it'd just ruin it unless you can play against a decent amount of others. Not to mention that a lot of features are still in early testing/balancing. Forsaken has also run into some issues with team reliability. This is just a factor of any mod as you have to work it around your work, school, personal life, etc. There have been a couple of months where no work on Forsaken was done at all, and then suddenly a large spurt of work was done. I think this is something that a lot of mods suffer from, and it's nothing to be surprised about. If you can be patient and still work on other portions of the mod whilst other people are away attending to work or personal matters then you need to. The problem is when you get people taking a leave of absence and that leaves your mod truly hanging, a showstopper if you will. That's when you start needing to evaluate what to do about the mod at large if this continuously happens and if you should remove that person from the team. There have been times in Forsaken where the team has started to get large, but we've cut a lot of people who weren't contributing enough. Since the SDK has been released there have only been ~4-6 dedicated team members contributing... and I believe this is how we are going to stay. We don't have to worry about team bloat (which I believe Insurgency is having to deal with to a LARGE extent) and we don't have to worry about any communication issues. By leaving our team small we can work even more closely together to develop something that we truly have a shared vision for. I hope that helped someone :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Houston Sent: Monday, January 02, 2006 2:48 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Successful mod team tips and warstories? -- [ Picked text/plain from multipart/alternative ] Sorry, going backwards a little here, but about realism. I tend to stay away from that sort of gameplay, it bores me alot. Recently on the BG2 forums I have been fighting to keep anal realism out of what is generally a rather arcadish game. The topic is iron sights, which is strange considering the guns didn't have sights and the soldiers were trained to just point and shoot at a clump of enemies and hope it hits(excluding skirmishers of course). I guess what I'm getting at here, is has your community ever zerged a crappy suggestion into your mod? has there ever been such overwhelming support for something you don't like but have felt obliged to add? I can see both sides, your players want you to make their game, while we want to make ours. Do tell. -- Draco -- ___ 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] Successful mod team tips and warstories?
-- [ Picked text/plain from multipart/alternative ] Aye, couldn't of said it better myself. I have been doing that during my time asone of the BG2 coders and have been scolded on the forums plenty for my apparent closed-mindedness. It does help to get some input though. I am always running little competitions on the forums(BG2 needs your voice!) or I share upcoming features with everyone and get their opinion. -- Draco -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Successful mod team tips and warstories?
-- [ Picked text/plain from multipart/alternative ] Granted that my experience comes from RL work in graphic animation but and of course I also get paid for it, but the structure and procedures apply the same. Yes Input should always be welcomed, but only as input "suggestions" The core of the idea or should I say The main components of the project are not and should never be arguable. The main components unless they are just simply ridiculous or have absolutely no point in being part of the story are not up for discussion to its inclusions or exclusions. When creating you MOD you set out projects or wish list of things that need to be completed. Of course your coder is not going to be concerned with weather or not you have blue pants or green ones but obviously he or she does has direct interest to many variables withing the structure or placement of items in your MOD. Having said that the suggestions that you take should be coming from your designated producer or Lead Level designer let him or her get all these suggestions from the team and you decide accordingly listen to what the LD has to say and what comments have been made by other TM regarding the proposed suggestions and then decide. But these suggestions should be about NON GAME BREAKING ENTITIES or NON BREAKING FUNCTIONS!!!. When you layout the game plan by that I mean when you have decided the path the game will take from start to finish 'THE STORY" and you assign the necessary components that have to in the story, then every thing else is up for grabs in the suggestion box. Let me explain further to make sure I am understood exactly at least what I mean. You make a MOD that a Gun fighter in the old west in a small town, and he has to fight opponents to reach the other end of this small town in order to complete the game. OK obviously by that short description you need a gunfighter so you need to skin /animate/code and create that gun fighter, you need to map create building that represent the old west, create/skin/model/code the opponents, and you need to create the textures needed for the building and surroundings. OK well those are the core elements they are not up for debate even if the game was bone bare with just the items i described, everything else that goes into creating that MOD is up for grabs, your decision on how much more to add will deal with directly with the suggestions, that are presented and to what level. Separate your mappers into different group, those that are responsible for scenery, for structures and those that are responsible for special effects. Look I know these people are working from there hearts and not from what they put in there pockets But I assure you that If you split up the team members into individual projects and maintain core components in the don't bother asking me box, life will flow much smoother Jason Houston <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] Aye, couldn't of said it better myself. I have been doing that during my time asone of the BG2 coders and have been scolded on the forums plenty for my apparent closed-mindedness. It does help to get some input though. I am always running little competitions on the forums(BG2 needs your voice!) or I share upcoming features with everyone and get their opinion. -- Draco -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders - Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Successful mod team tips and warstories?
-- [ Picked text/plain from multipart/alternative ] Please let me add this, I am not currently part of any MOD team, my hardcore experience come from working with large teams for an animation Co. I have experience in MOD's from having worked on Xen Rebels and Karl is an excelent individual, probably one of the most Knowledgeable HL'er I have ever met. My suggestions are from my RL experiences working with teams on graphic projects that incombus coding/design/graphics and so many more elements, projects that can take years so in a lot of ways its a direct coralation to the DO's and DON'Ts here. I will tell you this though one of the more important aspects of a MOD's team member's is it's maturity, you can have a very mature novice mapper and end up with a great map or MOD, but you can also have a completely imature Picaso mapper/coder/graphics designer and end up with an un finnished disaster. Eugenio Gonzalez <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] Granted that my experience comes from RL work in graphic animation but and of course I also get paid for it, but the structure and procedures apply the same. Yes Input should always be welcomed, but only as input "suggestions" The core of the idea or should I say The main components of the project are not and should never be arguable. The main components unless they are just simply ridiculous or have absolutely no point in being part of the story are not up for discussion to its inclusions or exclusions. When creating you MOD you set out projects or wish list of things that need to be completed. Of course your coder is not going to be concerned with weather or not you have blue pants or green ones but obviously he or she does has direct interest to many variables withing the structure or placement of items in your MOD. Having said that the suggestions that you take should be coming from your designated producer or Lead Level designer let him or her get all these suggestions from the team and you decide accordingly listen to what the LD has to say and what comments have been made by other TM regarding the proposed suggestions and then decide. But these suggestions should be about NON GAME BREAKING ENTITIES or NON BREAKING FUNCTIONS!!!. When you layout the game plan by that I mean when you have decided the path the game will take from start to finish 'THE STORY" and you assign the necessary components that have to in the story, then every thing else is up for grabs in the suggestion box. Let me explain further to make sure I am understood exactly at least what I mean. You make a MOD that a Gun fighter in the old west in a small town, and he has to fight opponents to reach the other end of this small town in order to complete the game. OK obviously by that short description you need a gunfighter so you need to skin /animate/code and create that gun fighter, you need to map create building that represent the old west, create/skin/model/code the opponents, and you need to create the textures needed for the building and surroundings. OK well those are the core elements they are not up for debate even if the game was bone bare with just the items i described, everything else that goes into creating that MOD is up for grabs, your decision on how much more to add will deal with directly with the suggestions, that are presented and to what level. Separate your mappers into different group, those that are responsible for scenery, for structures and those that are responsible for special effects. Look I know these people are working from there hearts and not from what they put in there pockets But I assure you that If you split up the team members into individual projects and maintain core components in the don't bother asking me box, life will flow much smoother Jason Houston wrote: -- [ Picked text/plain from multipart/alternative ] Aye, couldn't of said it better myself. I have been doing that during my time asone of the BG2 coders and have been scolded on the forums plenty for my apparent closed-mindedness. It does help to get some input though. I am always running little competitions on the forums(BG2 needs your voice!) or I share upcoming features with everyone and get their opinion. -- Draco -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders - Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders - Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping -- _
Re: [hlcoders] (no subject)
-- [ Picked text/plain from multipart/alternative ] I remember something happening to me where it had an error at npc_talker.h but i don't remember how i fixed it, EXCEPT I KNOW that gcc 3.4.1 compiles it perfectly, but other versions don't, so maybe that's what it was. I know 3.4.4 no worky and 3.4.3 no worky either. I vaguely remember tinkering around to make that error go away, but then another error popped up, so I switched to gcc version EXACTLY 3.4.1 and started over and I had not a single error. On 1/2/06, HJ <[EMAIL PROTECTED]> wrote: > > WFM, YMMV, very clean build and successful Linux srcds execution. > > Files in question are: > modname/src/dlls/npc_talker.h > modname/src/linux_sdk/Makefile > > Index: npc_talker.h > === > --- npc_talker.h(revision 1) > +++ npc_talker.h(revision 8) > @@ -15,9 +15,11 @@ > #include > #endif > > +#ifndef _LINUX > #pragma warning(push) > #include > #pragma warning(pop) > +#endif > > #ifdef _WIN32 > #pragma once > > > Index: Makefile > === > --- Makefile(revision 4) > +++ Makefile(revision 9) > @@ -9,6 +9,7 @@ > > # the name of the mod binary (_i486.so is appended to the end) > NAME=server > +MODDIR=hl2mp > # the location of the vcproj that builds the mod > MOD_PROJ=../dlls/hl_sdk.vcproj > # the name of the mod configuration (typically _ type>) > @@ -25,14 +26,14 @@ > # compiler options (gcc 3.4.1 or above is required) > CC=/usr/bin/gcc > CPLUS=/usr/bin/g++ > -CLINK=/usr/bin/gcc > +CLINK=/usr/bin/g++ > #CPP_LIB="/usr/lib/libstdc++.a /usr/lib/libgcc_eh.a" > > # put any compiler flags you want passed here > USER_CFLAGS= > > # link flags for your mod, make sure to include any special libraries > here > -LDFLAGS="-lm -ldl $(GAME_DIR)/bin/tier0_i486.so $(GAME_DIR)/bin/ > vstdlib_i486.so" > +LDFLAGS="-lm -ldl tier0_i486.so vstdlib_i486.so" > > # XERCES 2.6.0 or above ( http://xml.apache.org/xerces-c/ ) is used > by the vcproj to makefile converter > # it must be installed before being able to run this makefile > @@ -106,3 +107,5 @@ > $(MAKE) -f $(MAKE_PLUGIN) $(BASE_DEFINES) clean > $(MAKE) -f $(MAKE_MOD) $(BASE_DEFINES) clean > > +install: > + cp -f $(NAME)_$(ARCH).so $(GAME_DIR)/$(MODDIR)/bin > > > ___ > 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] m_nOldButtons losing data?
I've been experimenting with ways to get m_nOldButtons to stay the same (gamemovement.cpp/prediction.cpp set it to something on the client side) for more than three days now. I've taken it out of prediction, and put it back into prediction. Somewhere (in code that I apparently cannot see) it is being modified, and I don't know where. Has anyone had a similar problem, and do they have any suggestions as to how to fix it? Thanks in advance, -- Will "xENO" Ewing ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
