ahzurdan

[ 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 ]
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.

Hey WeaponX,

As you requested over in the Best Hover/Fly Bind Ever thread, I took a look at your binds. They seem pretty solid for what you are trying to do. I do have a suggestion, however:

/bind c "target_friend_next$$powexec_name BUBBLE"
/bind lshift+c "target_friend_prev$$powexec_name BUBBLE"

Where BUBBLE would be whatever the power name is for the Force Bubbles that Bubble-boys hand out. I use it on my Grav/Force Controller. It seems overly simplistic, but since I do most of my buffing inside Door Missions it works perfectly.

The benefit of this is that you also get any buffable pets. The down side is that you end up cycling through any other PCs that happen to be around.

I really wish that they had implemented the TARGET_TEAM_NEXT and TARGET_TEAM_PREV commands in this game, but it doesn't look like they did. Without them the way that you are currently doing it is the best you can do to stay within your team regardless of who is around.

[ 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.

[ 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.

[ 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!

[ 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 ]
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.

[ QUOTE ]
ahzurdan - I looked at your bind files (curiosity got the beter of me) haven't had a chance to see how they might run in game.
I like the effiency of your code - certainly much friendlier for some one to change from say sprint to quick

One thing I did notice though is that your "defaults.txt" file resets MUCH more than your bind set affects. you might want to pare that down some as it could nuke any additional bind sets someone might be running. at the least warn people that ctrl+r will do a total reset of ALL the standard binds not just those used in your set.

[/ QUOTE ]

I took the easy road on the DEFAULTS.TXT file. At the time I wasn't sure what keys I would be using, so I just reset my keybinds to the default from the Options pane in the game, and then saved out the entire set of binds that resulted.

I ended up leaving it this way so that I was sure that when I hit CTRL+R I was doing the same thing as reseting all keybinds through the Options pane in the game.

You are correct that most people won't need that much reset. I've gone ahead and updated the zip file on my site to reflect that.

I also fixed it so that if you are flying when you use CTRL+R to turn the binds off, you are assumed to be still flying when you turn them back on.

Also fixed a problem with autorun. It was letting you turn on autorun while you were holding down the forward key, which is redundant.

[ QUOTE ]
It's not clear to me how you switch between being on the ground and hovering.

[/ QUOTE ]

The F key toggles flight on and off. When flight is on you will hover when not moving and fly when moving (or hover if you don't have fly yet).

A complete list of the keys I rebound and what they do now is at my web page.

[ QUOTE ]
Fantastic idea ahzurdan. At first I atempted something similar by keeping track of the number of keys depressed and only poping out when the number reached zero, but could not tell in the middle of the code when a key was being pressed or released. By creating a toggle state for each axis of movement you seem to have side stepped the whole issue. I may have to look through you logic and incorperate it into my own bind files.

[/ QUOTE ]

Glad you like it. When I came up with the axis idea earlier this week I decided it was easier to rewrite the binds I was currently using and present them as a complete set than to try to explain the idea without a working example.

The ideas, questions and comments that people keep posting are constantly making me view this stuff in a new light. I love it! Doing this kind of stuff is what I liked about programming back before I got sucked into the corporate machine. Somebody has a goal, then a whole bunch of people go "Yeah! I want that!", and band together to make something great (or make a great thing even better)!

Feedback is always welcome, and I appreciate it; however, I think I have already taken your concerns into account. Read through the rest of this post and then let me know what you think.

Some things for the developers:
<ul type="square">[*]This was designed around the following idea: movement can be reduced to straight movement (bi-directional) along the X, Y and Z axes. X is left and right, Y is up and down, and Z is forward and backward.[*]The only time a power needs to be turned on is when the first key is pressed. That's why all of the movement keys in NORUN.TXT and NOFLY.TXT make sure that SPRINT/SUPER SPEED/HOVER/FLY are explicitly turned on using the double powexecs.[*]The only time a power needs to be turned off is when the last movement key is let go. That's why you will not find too many powexec statements outside of the NORUN.TXT and NOFLY.TXT bind files.[*]The binds are set up as follows: you are standing still, so NORUN.TXT is up. You press and hold W to move forward (along the Z axis) so RUNZ.TXT is brought up. If you press S at this point you will be moving forward and backward at the same time (your character will stop) so the NORUN.TXT bind is brought back up (turning off SPRINT in the process). When you let go of either W or S you will be brought back to RUNZ.TXT (turning SPRINT back on). Make sense?[*]Multiple directions are handled in the same manner. If you move forward you go to RUNZ.TXT, but while moving forward you dodge right which will invoke RUNXZ.TXT, and then when you jump while moving forward and right you will invoke RUNXYZ.TXT; it gets easier once you start to think of it as movement along the XYZ axes. Trying to move in both directions along a single axis (W+S, A+D) is really the same as not moving along that axis at all.[*]One last example: you move forward with W (RUNZ.TXT, turn SPRINT on) then dodge right (RUNXZ.TXT), then change your mind and dodge left, but have that split second where you hold A and D down while still holding W? This kicks you back to (RUNZ.TXT) until you let go of either A or D (sending you back to RUNXZ.TXT), but as the power doesn't get shut off until the last button is released (or it determines you to be standing still through a combination of button presses) you are still sprinting. W+A+D = forward sprint, W+S = no sprint and no movement, W+A+D+S = no sprint + no movement.[/list]

This is a post of a set of binds that are similar to Joe's, but fix all of the problems with key combinations breaking the binds, allow for follow to be toggled (which will kick on fly or sprint/super speed), correct some autorun issues, and reduce the number of overall files.

I currently have the files available in ZIP format on my geocities site here.

Some caveats:
<ul type="square">[*]mouselook is not toggled in the binds[*]the F key turns flight on and off, it does not toggle up and down.[*]the TILDE key (just above the TAB key and below the ESC key) is your follow key.[*]the X key does not toggle down. the LSHIFT key does, which makes it easier to go forward and down, or backward and down simultaneously.[*]CONTROL+R will shift between the default keybinds and these keybinds. When the keybinds are turned on they expect you to be on the ground.[*]If you are playing a character that has Super Speed it will automagically be used instead of Sprint. I don't know the power name for the Prestige Power, so that is not included.[*]If you are playing a character that is working towards FLY but only has hover, these keybinds will still work.[*]For some slower computers I have noticed that if mutliple keys are pressed rapidly causing the /BIND_LOAD_FILE command to be spammed the binds can get lost. If you feel this is the case simply reset the binds with CTRL+R, otherwise attempt to find a way to recreate the problem so that it can accurately be addressed. [/list]
Instructions for installing are on the site. Let me know what you think.