Thanks for your suggestion again Jeff. I was just typing an email trying to explain what I didn't like about your solution and why I thought it was just another work-around, but it became really long. Experience has taught me that when it takes you really long to explain to someone why you're doing something a certain way, that's most often because you're not doing it right in the first place. So after thinking about it I came to the conclusion that your suggestion is exactly what I need. :-)
Still, your solution means that I now use one +exec parameter (for a general cfg file which sets the gamemode, e.g. payload.cfg) and one +servercfgfile parameter (for identity and some other stuff) on the command line to start a server. So just because I'm curious, I would still like to know, preferably from someone at Valve, why you can't have multiple +exec parameters on the command line, because I still consider it a bug, even though it might be intentional. On Mon, Sep 3, 2012 at 6:04 PM, Jeff Sugar <[email protected]> wrote: > Ah - why not use +servercfgfile to set each server to use a cfg other than > the default of server.cfg, and then make a server1.cfg , server2.cfg, etc? > You could completely do away with the +exec portion in that case, instead > using '+servercfgfile server1.cfg' > > If you want to, you can even still consolidate the settings that all the > servers will have in common into one cfg (say, allservers.cfg) and then > exec it at the start of the server-specific configs. > > If you already thought of this and decided against it for some reason I > haven't thought of, then I apologize, but this seems like exactly what you > want to do. > > ---------- Forwarded message ---------- > From: "Rudy Bleeker" <[email protected]> > Date: Sep 3, 2012 8:37 AM > Subject: Re: [hlds_linux] srcds_linux command line argument handling > To: "Half-Life dedicated Linux server mailing list" < > [email protected]> > > Hi Jeff, > > thanks for your suggestion. I was indeed already aware you could chain > config files this way, but this isn't what I'm looking for. The reason > I'm reporting this bug and want to have this functionality is for > example when you're stacking multiple TF2 servers on one piece of > hardware. I use one config file (with some others exec'ed from it as > you suggest) to set the gamemode (cp, cfg, mvm), config replays, > logging, etc. Then I want to exec another one from the command line > which has the server identity in it, since this has to be different > for every instance you start. > > If anyone has a suggestion for another way of doing this in a nice, > modular fashion, please let me know. > > Regards, Rudy > > On Mon, Sep 3, 2012 at 4:53 PM, Jeff Sugar <[email protected]> wrote: >> For what it's worth, if you want a workaround, you can make a main cfg > file >> that exec's the other configs you wish to execute. >> >> So, "myconfigfile.cfg" could contain... >> exec config1.cfg >> exec otherconfig.cfg >> exec onemore.cfg >> >> I don't know if you were looking for a workaround in addition to reporting >> the bug, or just reporting it, but I figured I'd mention it just in case. >> For all I know, you've already set it up like the above, but still wanted >> to make the list/Valve aware of it. >> >> >> On Mon, Sep 3, 2012 at 6:47 AM, Rudy Bleeker <[email protected]> wrote: >> >>> Hi, >>> >>> I'm sorry if what I'm about to write is a known bug, but I couldn't >>> find anything about it on the internet. >>> >>> I was messing around with different server configs this weekend and >>> noticed some strange behaviour when feeding the srcds_run script >>> multiple +exec arguments. So I put some "say" lines into the config >>> files for debugging and I found that when you try to execute multiple >>> config files this way, only the first one you specify gets executed. >>> The cvars in any consecutive config files you specify with a +exec are >>> never set, instead the first config file you specified gets executed >>> another time, once for every +exec command present in your startup >>> line. I've tested this with up to 3 arguments. >>> >>> I know that all the + arguments given to the srcds_run script are >>> passed on directly to the srcds_linux binary, so to the best of my >>> knowledge the bug should not be in the script (unless there is some >>> limitation to /bin/sh and the shift buildin that I don't know about) >>> but in the way the binary handles it's input arguments. I was hoping >>> someone at Valve could shed some light on this. >>> >>> Regards, Rudy >>> >>> -- >>> Idleness is not doing nothing. Idleness is being free to do anything. >>> - Floyd Dell >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >>> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, > please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > > -- > Idleness is not doing nothing. Idleness is being free to do anything. > - Floyd Dell > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux -- Idleness is not doing nothing. Idleness is being free to do anything. - Floyd Dell _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
