Can't Get Autoexec to work

[bibizz944x]

Better then I could do translating to french.

[GunClap]

okay thanks to gunclap i realized i only had it in my etmain not jaymod folder! I didn't know you had to have it in both,thanks all

Let people know if it worked.

[Simtech]

I only have 1 autoexec.cfg, in the etmain folder.
I have multiple etconfig's, but just 1 autoexec.cfg

[mike5a2]

it does gunclap!

[GunClap]

I only have 1 autoexec.cfg, in the etmain folder.
I have multiple etconfig's, but just 1 autoexec.cfg

Cool, so when you call /exec autoexec, it would look first in the jaymod, realise there isn't one there and search your etmain, find that and launch.

[KrispyKritter]

I only have 1 autoexec.cfg, in the etmain folder.
I have multiple etconfig's, but just 1 autoexec.cfg

Cool, so when you call /exec autoexec, it would look first in the jaymod, realise there isn't one there and search your etmain, find that and launch.

I think that's backwards from your original explanation. I think it would look at the general settings, in etmain, then the specific ones in jaymod.

I also only have one autoexec, in the etmain. Etmain and each of my mods have a profiles folder containing folders named after my various handles. Each of those contains an etconfig. The one in my jaymod\profiles\krispykritter folder is time-stamped with the time & date of when I last started Et with jaymod, as is the one in etmain\profiles\krispykritter. The etconfigs in my other mods\profiles folders are dated when I last played them.

It looks like that when you first download a mod, all the profiles from the etmain are copied there.

We could test he order-of-precedence of the autoexecs easilly...just a minute...

OK, if you have an autoexec.cfg in your jaymod and you exec autoexec ingame, the jaymod version will be executed and the etmain one ignored. Jaymod is searched first and etmain second (I assume like other *.cfg files). I could not use the old DOS protocol to override this, such as exec ..\etmain\autoexec, etc. It might be better to do as GunClap does, make a gun.cfg or jay.cfg or mike.cfg for execution while playing jaymod.

I don't know if jaymod\...etconfig is copied over etmain\...etconfig, but my etmain file contains many items that are surprisingly jaymod- and BBA-specific. Closer exam is a future task.

I would have thought, like Gun says, etmain\...etconfig is executed first, but now I dunno.

[GunClap]

It's the difference between a game load and a user call.
Like I said, the game loads it's base and your etmain config, then the autoexec if it exists, then it loads the mod and that config, then that mod's autoexec if it exists.
But when a user uses the "/exec autoexec.cfg" command after the game has loaded, first it will look in the last activated folder (the mod's folder) and if it finds that, launches that one, disregarding any that may be in the main. But if the mod folder autoexec doesn't exist, then function recurses to the main game folder and checks that for an autoexec.cfg an launches that.
In terms of programming, the "/exec" function is basically using a reversed version of the load order as a checking scheme. This makes the code much easier and shorter to program and it avoids a lot of possible user errors.

What I was commenting to simtech was that because he has an autoexec in his main, but not in his mod. When he calls the "/exec" function, it checks the mod folder first, fails, then finds the one in the main.

If you REALLY HAVE TO use an autoexec.cfg, put it in your etmain folder and make sure there are none in the mod folders. That way, whether you call it or the game calls it, it only calls the one autoexec.

Don't you just love scripting?

Oh and the reason you have jaymod elements in your profile in your main folder is when ET closes, one of it's last functions is to compare mod config to main and merge them. This is a small piece of error capture for users so that if you change a key bind in a mod, it SHOULD pass through to others, but most of the time, because you probably already downloaded different mods, they already took a copy of your etmain config before the changes so when it loads up, it overwrites the newer bind with an older copy. You may find that if you have multiple mods, your etmain config will contain elements from all the mods. But during the loading of the game, after the etmain config is loaded, it's values are immediately overwrote with those from the mod's config.

(God, I love this stuff.)

[KrispyKritter]

one of it's last functions is to compare mod config to main and merge them. This is a small piece of error capture for users so that if you change a key bind in a mod, it SHOULD pass through to others, but most of the time, because you probably already downloaded different mods, they already took a copy of your etmain config before the changes so when it loads up, it overwrites the newer bind with an older copy. You may find that if you have multiple mods, your etmain config will contain elements from all the mods. But during the loading of the game, after the etmain config is loaded, it's values are immediately overwrote with those from the mod's config.

(God, I love this stuff.)

I love this stuff too, but you are obviously much further along in your education!

This may explain why some key-binds that you simply zero out might seem to 'come back' in the future. This merging function might explain a lot of the confusion that I and others have suffered.

The only time I exec my etmain\autoexec is when things seem to have been changed without MY permission. Haarruuumph!


Ah, your words would explain why, when people start ET and don't load a mod and then make changes that are saved in etmain\...etconfig, they might not be evident when they do connect to a server, which loads a mod, which executes it's own etconfig, 'overwriting' the settings just entered.

So, the best use of an etmain\autoexec is to force changes to all of your mods when you do run them online. From your words, I'm thinking that, for most mods, you would have to exec autoexec for each mod, after you load that mod or connect to a server using it.

Which is to say, just do it the way the Elders of BBA have been saying to do it for years, especially if you don't like to tinker with techie stuff.

[GunClap]

I love this stuff too, but you are obviously much further along in your education!

Not really, scripting for me has always given me inspiration as it's like programming for the game itself, so this is like my comfort zone. As for how the game works, it's like talking about the wind; We know it's there because the trees sway.

This may explain why some key-binds that you simply zero out might seem to 'come back' in the future. This merging function might explain a lot of the confusion that I and others have suffered.

Yeah, I was a pure ETPro player for years, but when I went to BBA the first time (because I'd already DLed the mod before coming here and had already taken a config copy) the game called all the old values before my work on ETPro.

The only time I exec my etmain\autoexec is when things seem to have been changed without MY permission. Haarruuumph!

Ah, your words would explain why, when people start ET and don't load a mod and then make changes that are saved in etmain\...etconfig, they might not be evident when they do connect to a server, which loads a mod, which executes it's own etconfig, 'overwriting' the settings just entered.

1: You might only execute it once, but because it's called autoexec.cfg it will launch every time the game does (this is a relic from Q3 that, in ET should have been a failsafe for future mods that may require a special load script but got misinterpreted), which is completely unneeded as the settings get passed through to the etconfig (that is, if you used Seta commands and not Set. The difference being that a SET command only sets that value until the game closes whereas SETA sets a variable in your config with that name and that variable. A fine example is my gamma script. Run it once and never run it again as it will create 30 virtual string variables in your config called gamma00 to gamma30 and rebinds F7 and F8 for gamma up and down. That way, you won't ever need an autoexec file... anywhere...).

2: Spot on, if you only change your etmain autoexec, it's values get overwrote, first by the mods config, then by the mods autoexec.

So, the best use of an etmain\autoexec is to force changes to all of your mods when you do run them online. From your words, I'm thinking that, for most mods, you would have to exec autoexec for each mod, after you load that mod or connect to a server using it.

The use of different mod autoexecs is to allow the mod to load anything that cannot usually be loaded through game calls through a script instead. This idea never took off and people have started using this for personal configuration, disregarding the fact that your profile config is designed for that purpose! However, a good use of it recently is to provide supplementary changes for mod difference. For example, etpub may appear brighter than jaymod, so in your etpub autoexec, you would have a line for r_gamma = 1.0 whereas in your jaymod, this may be r_gamma = 1.5. This is really the only use of it recently.

As I said, my advice is to not use one if you can stand to. Have only your etconfigs and one simple named config. (As a programmer, I like the fact that the "/exec" call doesn't need the script name encased in "" or the .cfg extension if it doesn't have a space in the name. For example, I call my script my simply tying "/exec gun".) Also, by doing it my way, you shave nanoseconds off boot time of the game as it does less variable checks and writes.

[tremor]

Place your .cfg files in /etmain only, pure and simple.

And forget about autoexec.cfg - give them descriptive names.

Keep them short and simple, don't toss in every cvar in the book, each of those have to load into memory... and the more you add in the more chance of duplicates and mistakes. Using the wrong settings can severely impact your game performance.

I for example have a set of .cfg files for different key bindings. BindsNQ.cfg, BindsJay.cfg, BindsPub.cfg and BindsPro.cfg for different mods.. for example one mod may have throwing knives, which you could bind to a key, another mod without them you could bind that same key to something else.

Then a set of .cfg files for different gameplay or video settings. I have configs like clean.cfg (which kills shadows, particles, colored smoke, and turns off vsays and announcer) and another one called pretty.cfg (which allows alot of the visual effects).

Also configs for network and performance settings.. specifically the max FPS, packets, snaps.. In fact I have key bindings to execute these. Often times your settings for one server may be out of parameter for another server with stricter rules.. and you need to change your settings rather quickly before you get the 'ole boot. Or in my case on BBA my FPS is always terrible, so i cap it at 43. Better to have a steady FPS than one that bounces all over with occasional hits up to 76 or 125.

remember for any configs that toy with visual settings, to put a vid_restart at the end.

just my 2 cents.