First off, I love the ability to fly/hover without thinking out it.
Now the problem. I believe keybinds are causing my map server disconnects. I can go maybe 20 mins before the first one but it eventually happens every 5 mins or less. I could watch the netgraph and see spikes every 1.5 secs or so but then the spikes get closer and closer until, boom, disconnect.
I loaded my old keybinds, played all night, loaded v2.2 again and boom, disconnects. Has no-one else experienced this?
The only correlation I can see is that all /binds are stored on the server, and since each key press combo loads a new bind file, you are sending network traffic to update your binds constantly? It eventually gets bogged down or get stuck in a loop. I have no proof of this except for watching netgraph as I play.
[ QUOTE ]
I loaded my old keybinds, played all night, loaded v2.2 again and boom, disconnects. Has no-one else experienced this?
[/ QUOTE ]
I have not experienced it. I play all night with these binds with no problems. I have DSL, but I do infrequently notice some lag with the movement commands being sent to the server... ie. sometimes I don't hover right away, etc.
But do you know for a fact that binds are saved server side? That makes no sense to me. I thought that the client would sort out what we wanted to do, and just send the movement commands to the server (+forward, +right etc). It just makes no network-programming sense to send what keys are mapped to these fundamental functions.
Gnarly
[ QUOTE ]
I have already converted ahzurdan's binds to the keys that I use and am starting to add some of the functionality from my previous set, such as the blastoff and setdown toggle. I may also play around with the autorun function, I am partial to pressing 'w' + 'r' and haveing the last one released determine my autorun state.
[/ QUOTE ]
Please do post these when you have the chance. I'd appreciate it.
[url="http://tinyurl.com/4ylgy"]The Wanderers[/url] of Virtue
We farm fun!
[ QUOTE ]
Hey Ahzurdan,
I think you read my previous post before I edited it... yes, after a bit more study, I realized that the double sprint didn't cause a problem. A VERY elegant solution to some of the problems we've encountered. You will still toggle sprint on and off if you're running left (A), but not forward, and then press right (F) before releasing the first, but it'll be so quick, and you need to stop to change directions 180 anyway, that it won't be noticeable.
I'm so optimistic, and impressed, that I've already modified your files to use the keys I prefer, and can't wait to get home to test it. Well Done!
Gnarly
[/ QUOTE ]
Thanks alot! I'm glad you liked it. I did see that you had updated your post, but I completely understand that the binds are set up in a manner that seems counter-intuitive at first glance, so I figured I would throw up an explanation anyhow to help others that are looking at it for the first time.
[ QUOTE ]
I agree Gnarly, I have already converted ahzurdan's binds to the keys that I use and am starting to add some of the functionality from my previous set, such as the blastoff and setdown toggle. I may also play around with the autorun function, I am partial to pressing 'w' + 'r' and haveing the last one released determine my autorun state.
[ QUOTE ]
Is there a way to add the "blastoff" functionality that Wasabi created? I really liked holding down the F key to activate fly and take off upwards. If you can tell me roughly how to do this, I would be much obliged. Thanks!
[/ QUOTE ]
Something like this I would imagine :
<font class="small">Code:[/color]<hr /><pre>norun.txt
f "+up$$powexec_name sprint$$powexec_name Super Speed$$powexec_name fly$$powexec_name fly$$mouse_look 1$$bind_load_file c:/coh/binds/run/blastoff.txt"
blastoff.txt
f "+up$$powexec_name hover$$powexec_name hover$$mouse_look 0$$bind_load_file c:/coh/binds/fly/nofly.txt"
</pre><hr />
Because of the simplicity and efficiency of these binds I am giving notice now that I will no longer support my archaic and outdated spaghetti code. 
[/ QUOTE ]
First, I certainly didn't mean to show you up or anything, Joe! Your binds do exactly what they were designed to do, and they do it well. That's what matters!
Second, I originally set out to include the "Blastoff" and "Setdown" functionality into the binds I put together, but I had problems with the coding itself. It is hard for me to get my mind around a single button that sometimes goes up and sometimes goes down. I was having problems with the fact that while a person was holding the SPACE key to jump they could hit F to "Blastoff" as well, which would get the binds completely out of sync. I would basically end up turning off the UP movement entirely when it encountered the second +UP, and then get lost in the binds. It was starting to look like I would need a whole other set of files (like those for Autorun, or Follow) so I set it aside while getting the rest completed.
I am looking into it, though.
Third, for this:
<font class="small">Code:[/color]<hr /><pre> f "+up$$powexec_name sprint$$powexec_name Super Speed$$powexec_name fly$$powexec_name fly$$mouse_look 1$$bind_load_file c:/coh/binds/run/blastoff.txt"</pre><hr />
You might add a POWEXEC_NAME HOVER just before the two FLY ones. This will ensure that if the character doesn't have FLY yet (is between levels 6 and 14, for instance) HOVER is turned on instead. My solo character is taking forever to get to 14, so this keeps biting me. 
Lastly, if you figure out a way to elegantly get the W+R combination to work the way that you are suggesting, please let me know. I was having problems with that because of the basic idea behind the way that I structured the code. All movement along a given axis (the Z for forward and backward, in this case) was treated the same regardless of direction. I was at a loss for how to set up W+R to work correctly without causing wierdness with the way that S works. It is basically a problem that is very similar to what I was having with the "Blastoff" and "Setdown" functionality. You are trying to go FORWARD while already going FORWARD, which kept throwing the binds out of whack.
I will likely look into this one after I finish messing with the "Blastoff" and "Setdown" functionality. No promises.
Sorry for the length of the post. 
Ok so after looking through alot of great responces, what is the best Hover/Fly bind? I need the code so I can write it up tonite. Getting tired of switching around with my mouse! lol
If anyone has that info, please post it
Tempest
[ QUOTE ]
[ QUOTE ]
I loaded my old keybinds, played all night, loaded v2.2 again and boom, disconnects. Has no-one else experienced this?
[/ QUOTE ]
I have not experienced it. I play all night with these binds with no problems. I have DSL, but I do infrequently notice some lag with the movement commands being sent to the server... ie. sometimes I don't hover right away, etc.
But do you know for a fact that binds are saved server side? That makes no sense to me. I thought that the client would sort out what we wanted to do, and just send the movement commands to the server (+forward, +right etc). It just makes no network-programming sense to send what keys are mapped to these fundamental functions.
Gnarly
[/ QUOTE ]
I can vouch that the current keybinds are stored server side. I transferred a character over to the Test Server and he showed up there with my custom binds already installed.
How often they update the keybinds out to the server, that I don't know. I would hope (for the sake of the broadband deficient) that they didn't set it up to push the binds out to the server every time a BIND_LOAD_FILE command is issued.
[ QUOTE ]
First, I certainly didn't mean to show you up or anything, Joe! Your binds do exactly what they were designed to do, and they do it well. That's what matters!
[/ QUOTE ]
I dont feel shown up at all ahz. Like I have said before I consider this an on going discussion and am VERY happy there is now a solution that does not involve an inordinate amount of files.
[ QUOTE ]
I dont feel shown up at all ahz. Like I have said before I consider this an on going discussion and am VERY happy there is now a solution that does not involve an inordinate amount of files.
[/ QUOTE ]
I feel shown up, though! The problem is that I've felt that way for 80% of this thread... Every time I felt like I had a contribution to this topic, somebody else would post not only the idea I had, but a full set of binds with it already implemented. *cough*Wasabi*cough*
Oh, and ahzurdan: apply your heroic powers of streamlining here, please!
[ QUOTE ]
[ QUOTE ]
First, I certainly didn't mean to show you up or anything, Joe! Your binds do exactly what they were designed to do, and they do it well. That's what matters!
[/ QUOTE ]
I dont feel shown up at all ahz. Like I have said before I consider this an on going discussion and am VERY happy there is now a solution that does not involve an inordinate amount of files.
[/ QUOTE ]
I'm glad you feel that way.
I personally know how hard it can be, when you have put alot of time and energy into something, for someone else to come along and provide a new/different idea. The just-out-of-college hires around the office are consistently bringing in new ideas that are wonderful, elegant and efficient, but which can leave alot of the old timers thinking, "Do they even need me here anymore?"
Certainly don't want anyone here feeling like that. The more ideas, the more input, the more feedback and questions, the better!
If you stand on the ground and then press jump, you will jump into air while activating sprint which will be deactivated when you land. If tappin jup shortly, sprint will not deactivate when you land.
[ QUOTE ]
[ QUOTE ]
I have not experienced it. I play all night with these binds with no problems. I have DSL, but I do infrequently notice some lag with the movement commands being sent to the server... ie. sometimes I don't hover right away, etc.
But do you know for a fact that binds are saved server side? That makes no sense to me. I thought that the client would sort out what we wanted to do, and just send the movement commands to the server (+forward, +right etc). It just makes no network-programming sense to send what keys are mapped to these fundamental functions.
Gnarly
[/ QUOTE ]
I can vouch that the current keybinds are stored server side. I transferred a character over to the Test Server and he showed up there with my custom binds already installed.
How often they update the keybinds out to the server, that I don't know. I would hope (for the sake of the broadband deficient) that they didn't set it up to push the binds out to the server every time a BIND_LOAD_FILE command is issued.
[/ QUOTE ]
First off, I want to say thanks so much guys, especially Wasabi Joe, as I'm using his 2.4 binds - awesome stuff. If I get elected mayor, I'll direct more funding to the Paragon City Flight Academy (That would be this thread).
About binds being stored on the server - transferring a character to the test server and keeping your binds wouldn't indicate whether or not the binds are stored on the server or on your computer.
Most likely, it's just stored on your computer, primarily for the reason that it's not necessary for the server to know what your binds are - it just needs the bare bones commands that you execute. Bandwidth usage in an MMORPG is critical - something as smooth as City of Heroes shouldn't be making the mistake of having my binds uploaded to it every time I change them (I.E., every time I hit a movement key...)
That's just the logical reasoning though, and I can't offer definitive proof that this is the case. However, I do have an acid test.
1. Save your binds on your normal computer.
2. Log in from a different computer (or have someone else log in on your account) and see if your binds still exist on that machine. If they do, they're on the server. That should settle the question.
If those binds are being stored on the server, I'll eat my cape.
It doesn't answer why an earlier poster was experiencing disconnects though. My only theory would be that CoH gives a high priority to loading text files, and temporarily ignores the connection, which on a slow connection might be the cause of a disconnect. I don't see why this would be the case, however.
I suppose there's the off chance that any and all text you type is sent to the server, in case it's a command... but again, that's a waste of bandwidth, in many cases.
I have to say ditto to really liking what has happened with the evolution of these binds. I saw some of the capability at one point, but Joe, Gnarly and ahzurdan are much better able to put them into action. I'm just glad I was involved in bringing this thread back to active. The set I settled with is only capable of handling two keys pressed simultaneously, but eliminates much of the overhead. Of course, ahzurdan seems to have done it all in about as many files. But hey, I'm in marketing. I just like coding binds as a hoby (yes, I'm sick and need help!).
Any way, I did have some serious stuff to post about:
[ QUOTE ]
But do you know for a fact that binds are saved server side?
[/ QUOTE ]
Yep, the key-bind configuration with any changes is stored server-side with the character. If you sign on from any other computer, your binds will be there. No need to re-enter. But once bound, there is probably little/no need to comunicate with the server. However, as these binds continally re-bind the key definition, there must be constant communication going on. I can't say I've noticed any real changed in performance, but I'm still using my very much toned down binds until you can all settle on something and move on . Actualy, since I've changed the default keys for movement and this seems to be changing faster than Windows, I've given up trying to keep up with the editing the new files till I can figure out which set I want to use.
Any way, kudos to you all. I MAY have something to contribute in the future, but you're all moving a bit to fast for me!!
[ QUOTE ]
I can vouch that the current keybinds are stored server side. I transferred a character over to the Test Server and he showed up there with my custom binds already installed.
[/ QUOTE ]
Sorry to be so anal, but I'm not convinced by that... Maybe the client stores them by character name? And even if you tested THAT by making 2 characters on different servers with the same name, and creating different binds for them, I'd still say "Maybe the client stores them by servername_charactername, but the Test Server does something different?" I saw something when reading about the test server, that if you deleted a character, it would break your keys when you logged in... can't find the post now, unfortunately.
Oh, one possibility which I just thought of before I hit the "submit" button... maybe the binds are stored server side, but just when logging in/out? Like Roaming Profiles in Windows. You log in, and the server sends you the binds you stored last time. During your play session, you make changes LOCALLY, but they're not propagated to the server. When you log OUT, whatever your current binds are, complete with changes, are sent to the server. This would not explain KarmaTrain's problems, but would explain why Ahzurdan's binds moved with him to the Test Server.
Let me explain a bit more why I say "It makes no sense to store them server side":
- Storage Space - each character has to have a complete set of binds, many of which will be redundant from one character to the next. Not a big consideration, however, with the cheapness of huge disks, and the limited size of even big bind files.
- Server Resources - I'm sure the programmers would prefer for the client to do everything that is possible without bothering the server. Why make an overworked server interpret the "x" key for each of thousands of users each with disk calls to find their binds, disk writes to change them, and memory for remembering them?
- A lot of keys can do things that are server independent, like viewing angle, zoom etc. Why send this key info to the server (client supposedly doesn't know what this key means) just so the server can send back to the client to say "zoom out".
- Network time - this is of course why KarmaTrain things they ARE server side, because of his disconnects. But would YOU do this if you were a programmer for a game with 1000s of clients connecting over limited bandwidth?
I don't mean to start a big argument here, but I'd need pretty compelling proof to make me think they did it this way. And I think if we say "Oh, KarmaTrain is just SOL because he has a slow connection" and stop trying to solve his problem, we're doing him a disservice.
So, in a return to constructive thought... KarmaTrain, have you checked your binds for typos and bugs? Maybe a missing " or $, or a space before or after $$ is causing problems. Maybe you could download binds, if you didn't already, from somebody that tested them and know they work on their system? Is anybody else having crashes when using these binds, but is fine when NOT using the binds?
And Ahzurdan, tried your binds last night and they work sweet Also interested in a Blastoff functionality, and a smooth transition from normal forward movement to autorun, but otherwise much less fragile than the other setup. I'll be looking at the best way to add these features too.
Gnarly
They ARE in fact stored Server side. I play my characters constantly on my Desktop & Laptop. When I created a macro or bind on one pc, when I log in via other pc it's all there.
To top it off, I even occassionly log onto a friends PC and they are there as well.
Of course, though, u need to install wasabi's files if u want that to work but normal binds without load_file commands work fine.
As far as disconnect, I still can do some more testing but I played all night on my 4mb/500kp up cable modem connection and constantly got disconnects. Updated to v2.2 next day and still same thing, they only thing I did was load old bind file and played 5 hrs without problem.
If no one else experiences this, it must be something else that I'm doing different with em?
[ QUOTE ]
If you stand on the ground and then press jump, you will jump into air while activating sprint which will be deactivated when you land. If tappin jup shortly, sprint will not deactivate when you land.
[/ QUOTE ]
I can actually corroborate this. Within my binds it seems to be because you are hitting jump and letting it back off so quickly. The binds don't get swapped over as fast as you hit the keys. Unforetunately jumping is especially prone to this, as jumping can sometimes be a simple tap. I was hoping it wouldn't be an issue so much as the game lends itself more to long jumps (where you hold the key down continuously) than short hops.
I'm sorry, but I can't really give you a better answer than that. Unforetunately I can't see any way to fix this, as it seems to be that the actions that change the binds are not occuring as fast as you are requesting them (with button presses/releases), and that some are getting discarded by the game (or possibly lost due to network problems, if the stuff about the binds being pushed to the server is correct).
I realize that this isn't a good answer 
, but if you continue to have problems with this, then I would suggest trying not to "tap" your keys but to "press" them instead.
Sorry.
Blue Volt the Lurker Returns!
Welcome back! Now all we need is for Sinabyss to come back. He started this revolution in binds, after all. You can even use the difference in key press and release to activate 2 powers with one keypress (1 Key 2 Powers ). You lurking out there, Sin?
Anyway, I've become a steadfast convert to your ESDF setup. Even just having a little bump on my keyboard to confirm I'm in the right place makes it worth it, and there is much less movement of fingers when I want to type some wiseass remark. So, I have modified Ahzurdan's binds to fit. I'm going to see what improvements are made here over the next few days, and mess around with them myself, and then I'll make sure to post a link to them, wherever they end up, when they're bug free and as smooth as possible.
Gnarly
[ QUOTE ]
[ QUOTE ]
I can vouch that the current keybinds are stored server side. I transferred a character over to the Test Server and he showed up there with my custom binds already installed.
[/ QUOTE ]
Sorry to be so anal, but I'm not convinced by that... Maybe the client stores them by character name? And even if you tested THAT by making 2 characters on different servers with the same name, and creating different binds for them, I'd still say "Maybe the client stores them by servername_charactername, but the Test Server does something different?" I saw something when reading about the test server, that if you deleted a character, it would break your keys when you logged in... can't find the post now, unfortunately.
Oh, one possibility which I just thought of before I hit the "submit" button... maybe the binds are stored server side, but just when logging in/out? Like Roaming Profiles in Windows. You log in, and the server sends you the binds you stored last time. During your play session, you make changes LOCALLY, but they're not propagated to the server. When you log OUT, whatever your current binds are, complete with changes, are sent to the server. This would not explain KarmaTrain's problems, but would explain why Ahzurdan's binds moved with him to the Test Server.
Let me explain a bit more why I say "It makes no sense to store them server side":
- Storage Space - each character has to have a complete set of binds, many of which will be redundant from one character to the next. Not a big consideration, however, with the cheapness of huge disks, and the limited size of even big bind files.
- Server Resources - I'm sure the programmers would prefer for the client to do everything that is possible without bothering the server. Why make an overworked server interpret the "x" key for each of thousands of users each with disk calls to find their binds, disk writes to change them, and memory for remembering them?
- A lot of keys can do things that are server independent, like viewing angle, zoom etc. Why send this key info to the server (client supposedly doesn't know what this key means) just so the server can send back to the client to say "zoom out".
- Network time - this is of course why KarmaTrain things they ARE server side, because of his disconnects. But would YOU do this if you were a programmer for a game with 1000s of clients connecting over limited bandwidth?
I don't mean to start a big argument here, but I'd need pretty compelling proof to make me think they did it this way. And I think if we say "Oh, KarmaTrain is just SOL because he has a slow connection" and stop trying to solve his problem, we're doing him a disservice.
So, in a return to constructive thought... KarmaTrain, have you checked your binds for typos and bugs? Maybe a missing " or $, or a space before or after $$ is causing problems. Maybe you could download binds, if you didn't already, from somebody that tested them and know they work on their system? Is anybody else having crashes when using these binds, but is fine when NOT using the binds?
And Ahzurdan, tried your binds last night and they work sweet Also interested in a Blastoff functionality, and a smooth transition from normal forward movement to autorun, but otherwise much less fragile than the other setup. I'll be looking at the best way to add these features too.
Gnarly
[/ QUOTE ]
I am hoping that they didn't do anything like this, but it seems to me as if they did.
I have a friend that let me use his Super Speedster for testing purposes, and he ended up having leftover binds on his character from my testing the next time he logged in. He lives about 3 hours from me, so we definitely don't share a computer.
That made me think that perhaps it was a push that was occuring during zones/logouts. Unforetunately, you can totally see network spikes when using these binds that aren't there when you aren't using them. It seems not so much that the server tells the client what the keys do, but that it stores a current set of your keybinds on the server, and that whenever the BIND_LOAD_FILE command is issued it updates those keybinds to the server.
I would be willing to bet that they just didn't realize how powerful the BIND_LOAD_FILE command could be in making wonderfully useful binds.
I am currently intending to do some testing on the Test Server to see if they changed the way that this works with the "Networking Updates" that they put up there on Tuesday.
ahzurdan, I was looking through your bind files and a couple things confused me.
In followflyyz and followrunyz if you hit R for autorun you are transferred to autorunz instead of autorunyz. But at this point aren't you holding space or lshift? So when you release space or lshift you will be transferred to autorunyz. That seems backwards. Can you explain what I'm missing?
I also noticed that in nofly when you press a movement key fly is turned on but hover does not seem to be turned off. Conversely when releasing the movement key hover is turned on but fly is not turned off. Does turning one on automatically turn the other off? I rerolled so I'm stuck without flight atm and can't check (and don't have access to CoH at work anyway ). The binds I used before turned both on/off and I never thought to check if that was necessary.
Regarding the tap jump, couldn't the binds just be altered to omit y axis in the run set? It doesn't seem like sprint would need to be explicitly turned on for jumping since if moving forward you would already be sprinting etc.. For instance in flyxyz F would transfer you to runxz. Haven't fully thought that through but perhaps it's workable.
Ahz,
Why don't you just change it so there is no real action for the up/down axis while running? In other words, for all the files in the run folder, bind space to +up, and x to nop, but don't start sprint, and don't bind_load_file anything. You'd still need to keep the files with the Y axis though, because you'll need them to gracefully change from flying with some combination using up or down, to running. For Example, if you are flying forward and down to land, then hit F, you want to start just running forward... If you just moved from FlyYZ to RunZ, however, and then release your X key, you'll try to go down (no big deal, I guess). So you use RunYZ to set space/x to just call the other files, but not to +up/+down. Basically, it's a one-way file that is used only so you can release the space bar or x and end in the correct mode.
Well, you can figure it out by looking better than I can explain it with words. They're your binds after all
This same kind of thing will be needed to smoothly transition from running forward to autorun.. you need a file so you can let go of W (and not do anything) in case you're holding it down when you press R.
Sorry for the reply in words... I know if I just made the changes and sent you the files it'd be easier, but I don't use the same keys as you, and I can't test here at work. So, I just give these word explanations instead of sending you confusing ESDF binds that haven't been tested
Gnarly
[ QUOTE ]
ahzurdan, I was looking through your bind files and a couple things confused me.
In followflyyz and followrunyz if you hit R for autorun you are transferred to autorunz instead of autorunyz. But at this point aren't you holding space or lshift? So when you release space or lshift you will be transferred to autorunyz. That seems backwards. Can you explain what I'm missing?
[/ QUOTE ]
Whoops! Mistake there. Good catch! Updated on the site.
[ QUOTE ]
I also noticed that in nofly when you press a movement key fly is turned on but hover does not seem to be turned off. Conversely when releasing the movement key hover is turned on but fly is not turned off. Does turning one on automatically turn the other off? I rerolled so I'm stuck without flight atm and can't check (and don't have access to CoH at work anyway ). The binds I used before turned both on/off and I never thought to check if that was necessary.
[/ QUOTE ]
Hover and Fly are indeed mutually exclusive. If you turn one on the other turns off automagically.
[ QUOTE ]
Regarding the tap jump, couldn't the binds just be altered to omit y axis in the run set? It doesn't seem like sprint would need to be explicitly turned on for jumping since if moving forward you would already be sprinting etc.. For instance in flyxyz F would transfer you to runxz. Haven't fully thought that through but perhaps it's workable.
[/ QUOTE ]
Let me think about this last. My first impression is that it won't work right, but I have blind spots when it comes to my own coding. Let me take another look and get back to you.
[ QUOTE ]
I also noticed that in nofly when you press a movement key fly is turned on but hover does not seem to be turned off. Conversely when releasing the movement key hover is turned on but fly is not turned off. Does turning one on automatically turn the other off? I rerolled so I'm stuck without flight atm and can't check (and don't have access to CoH at work anyway ). The binds I used before turned both on/off and I never thought to check if that was necessary.
[/ QUOTE ]
One turns the other off automatically. If you do it explicitly, then these binds won't work without modifications if you only know how to hover, as you'll fall out of the sky when you try to move This is a pretty nifty way that Ahz did it, and allows me to use the binds with my lower level alts. But, they do put a "Switching on hover instead of fly" message in your chat box, which I don't think you get if you turn it off explicitly. But I'm not sure on that, as I've long ago turned these messages off to avoid spamming.
[ QUOTE ]
Regarding the tap jump, couldn't the binds just be altered to omit y axis in the run set? It doesn't seem like sprint would need to be explicitly turned on for jumping since if moving forward you would already be sprinting etc.. For instance in flyxyz F would transfer you to runxz. Haven't fully thought that through but perhaps it's workable.
[/ QUOTE ]
This is what I tried to say in the post preceding this one... And after making the changes in my binds, I figured out an easy way to describe the changes:
In every file in the run directory, modify all the files with NO y in the filename so that space is "+up" only, and x is nop only.
For all files WITH a Y, erase the entire bind for space and X except for the bind_load_file command. These files with a Y are no longer called when in run mode, and are only used when switching from fly to run and x or space is depressed. Changing the binds as I've said lets you release that key and puts you in the right mode without changing anything else.
Gnarly
[ QUOTE ]
Ahz,
Why don't you just change it so there is no real action for the up/down axis while running? In other words, for all the files in the run folder, bind space to +up, and x to nop, but don't start sprint, and don't bind_load_file anything. You'd still need to keep the files with the Y axis though, because you'll need them to gracefully change from flying with some combination using up or down, to running. For Example, if you are flying forward and down to land, then hit F, you want to start just running forward... If you just moved from FlyYZ to RunZ, however, and then release your X key, you'll try to go down (no big deal, I guess). So you use RunYZ to set space/x to just call the other files, but not to +up/+down. Basically, it's a one-way file that is used only so you can release the space bar or x and end in the correct mode.
Well, you can figure it out by looking better than I can explain it with words. They're your binds after all
This same kind of thing will be needed to smoothly transition from running forward to autorun.. you need a file so you can let go of W (and not do anything) in case you're holding it down when you press R.
Sorry for the reply in words... I know if I just made the changes and sent you the files it'd be easier, but I don't use the same keys as you, and I can't test here at work. So, I just give these word explanations instead of sending you confusing ESDF binds that haven't been tested
Gnarly
[/ QUOTE ]
Ok, here are my thoughts on this.
<ul type="square">[*]I can easily change things so that Sprint isn't toggled by movement along the Y axis. I just don't think that that will fix the problem, as I think the real problem is that the binds are getting out of sync due to how fast the buttons are being used being faster than the binds can be reloaded.[*]I can't remove the BIND_LOAD_FILE command from the Y axis movement in the RUN files, as then I wouldn't know whether to go to FLYZ or FLYYZ if you turned on FLY while running forward. I would no longer have any idea whether or not you were already holding the SPACE key down. It works going from FLY to RUN, but not going the opposite direction.[/list]
Am I missing something?
[ QUOTE ]
In every file in the run directory, modify all the files with NO y in the filename so that space is "+up" only, and x is nop only.
For all files WITH a Y, erase the entire bind for space and X except for the bind_load_file command. These files with a Y are no longer called when in run mode, and are only used when switching from fly to run and x or space is depressed. Changing the binds as I've said lets you release that key and puts you in the right mode without changing anything else.
Gnarly
[/ QUOTE ]
Heh. You keep posting while I am painstakingly hunting/pecking out my own posts.
I think this still runs into the problem that when switching from RUN to FLY you don't know whether or not to go to the FLY file with the Y axis stuff in it, or not. I have alot of times where I will hit and hold jump and then hit F (to approximate what F did in Joe's binds), all while running forward. I would now be coming out of RUNZ and would end up in FLYZ instead of FLYYZ, where I really want to be.
This is basically the stumbling block I am running into with the "Blastoff" and "Setdown" functionality.
Thank you for the clarifications, ahzurdan. There was another thing I forgot to ask earlier. When reading your files it seemed that they assume +forward to have an inherent autorun 0 and not +backward. I thought it was the opposite. +forward does not turn off autorun while +backward does.
For instance autorunz has s toggle autorun while w does not but in both cases you are transferred to normal run files. In my current binds I added autorun 0 to my w bind.
In gaming I've run across the idiosyncrasy that autorun does not turn off follow. This caught me twice last night. I tried adding follow 0 to my autorun bind but it did not work. Obviously I don't want an indiscriminate follow toggle in my autorun.
In your followrun R toggles autorun and loads autorunz, but follow is still on at this point. Of course hitting a or d will break follow but do you know a way of specifically setting follow to off within a bind?
Otherwise the files match my expectations; +right/+left break follow but not autorun etc..
[ QUOTE ]
Hey Ahzurdan,
I think you read my previous post before I edited it... yes, after a bit more study, I realized that the double sprint didn't cause a problem. A VERY elegant solution to some of the problems we've encountered. You will still toggle sprint on and off if you're running left (A), but not forward, and then press right (F) before releasing the first, but it'll be so quick, and you need to stop to change directions 180 anyway, that it won't be noticeable.
I'm so optimistic, and impressed, that I've already modified your files to use the keys I prefer, and can't wait to get home to test it. Well Done!
Gnarly
[/ QUOTE ]
I agree Gnarly, I have already converted ahzurdan's binds to the keys that I use and am starting to add some of the functionality from my previous set, such as the blastoff and setdown toggle. I may also play around with the autorun function, I am partial to pressing 'w' + 'r' and haveing the last one released determine my autorun state.
[ QUOTE ]
Is there a way to add the "blastoff" functionality that Wasabi created? I really liked holding down the F key to activate fly and take off upwards. If you can tell me roughly how to do this, I would be much obliged. Thanks!
[/ QUOTE ]
Something like this I would imagine :
<font class="small">Code:[/color]<hr /><pre>norun.txt
f "+up$$powexec_name sprint$$powexec_name Super Speed$$powexec_name fly$$powexec_name fly$$mouse_look 1$$bind_load_file c:/coh/binds/run/blastoff.txt"
blastoff.txt
f "+up$$powexec_name hover$$powexec_name hover$$mouse_look 0$$bind_load_file c:/coh/binds/fly/nofly.txt"
</pre><hr />
Because of the simplicity and efficiency of these binds I am giving notice now that I will no longer support my archaic and outdated spaghetti code.