Impish Kat
-
Posts
1986 -
Joined
-
I'z a happy Kat
-
Quote:At the risk of sounding like my mom;Originally Posted by Perfect_Pain
I know I do not belong in the top 10. But, I honestly think Rep should be for more than just a forum game.
"Should be, could be, would be... IF only..."
Some "if's " are really just that big (or bigger). -
Quote:Oh, you mean like this?Originally Posted by Obsidius
...Instead, game shops should be made to more strictly enforce the ratings on games (and not sell Mature games to minors) while increasing parental awareness of ratings;...
Take your time, read them all.
Then tell me again how a store (read, buisness) should be held responsible for the behaviors of their customers (read, private decisions). -
Quote:So what you're saying is that your name is really "Phlip"otic Knight?Originally Posted by PhiloticKnight
Come ON, look at who you're talking to. I'm the man that's probably changed his avatar and even FORUM NAME more often than anyone else on the boards!
You really expect me to remain consistent at this point? -
I corrected myself and apologized.
Skinning the cat is redundant. -
Quote:You know you can adjust facial features with the sliders while in the character creator, right? (not sure, but I think you can even do it at the tailor with one of the booster pack options). So you can pick a face that is the closest to what you want, then tweak on a small scale with the sliders.Originally Posted by Taco
Had a bit of team grinding just yesterday, actually. It was actually pretty fun since we just kinda charged in and attacked anything that moved.
I think I'm pretty satisfied with one character as she is now, although the other one... Her face still bothers me. REROLL
And thanks for the warm welcomes, everyone! I'll probably be picking of the Good vs. Evil set this Monday since Gamestop has it for $10. Do I still need to buy a seperate game card/game-time card or attach a credit card to the account to use that, though? I got a little confused there after looking through some stuff in the support section of CoH.
As for using the cards, I agree the NC support pages get a bit confusing. The way I understand it, is that you can use the game cards but you will still need to pick a "billing option" somewhere along the line. So, you may need a credit card or paypal option to attach to the account.
NOTE: Remember to use the "apply serial code" and UPGRADE when you move up to full account status. Not sure how that works when using the boxed version, maybe someone else has more details on how that works. I do know that if you use the "create new account" option, you will lose everything you've worked on in your trial account.
Last, but certainly not least, WELCOME to our addiction!
-
Quote:tskOriginally Posted by Feugan
we did base raids up until i13 on LIVE servers, I am 100% certain we did about 10 during i12.
don't get yer panties in a bunch... didn't you see my next post?
As far as destructible items go.... I believe that it was attempted, unsuccessfully. Don't ask me to explain the whys and wherefores, Cende might have a better explanation on that front. -
ahhh... yes, my memory is a bit faulty on the timeline... Hubby started playing during i8, and I came in during i9. He does not remember raids being active on the live servers, either...
However, in looking through P-wiki, I see it may have just been a mistaken impression that they weren't active. Cathedral of Pain was disabled, therefore many SG's simply didn't bother with raiding... except on the training servers.
I see, I see... mia culpa.
The real experts on the subject would of course be Azrhiaz and MCG Warface
-
Quote:The problem I have with this is that "targetcustomnext teammate" actually works more like target NEAREST teammate... It does not cycle through the team LIST. Also, as you mention, you can't target a specific teammate that may need a little extra help.Originally Posted by Blue_Crow
You should be able to use "targetcustomnext teammate" on say NUMPAD1.
This should cycle through the team mates.
I've tried incorporating the teamselect into my binds, but have not been able to get it to work the way I want (cycle through team list). I even tried it in a rotating bind (one key cycles through the team list), but it always got hung up at whatever point in the list I was at.... since I couldn't target myself, the command couldn't complete and move on to the next.
*facepalm*Quote:PS: you can bind ALL your toggles to the one key:
So say for a scrapper with regen, fighting, leadership & Epic:
/bind T "powexectoggleon focused accuracy$$powexectoggleon tactics$$powexectoggleon assault$$powexectoggleon maneuvers$$powexectoggleon weave$$powexectoggleon tough$$powexectoggleon intergration"
Doh! why didn't I think of that?! friggin brilliant
I do have some powers set to fire on a downpress/release. One power fires on the downpress, the other on the release. The trick is to use the "+" in combination with the "toggleon" command. It can force a click power to behave like a toggle power within the command string. Here are some examples:
"+ $$powexec_toggleon Aim$$powexec_toggleon Build Up"
"+ $$powexec_toggleon Nova$$powexec_toggleon Conserve Power"
"+ $$powexec_toggleon Increase Density$$powexec_toggleon Speed Boost"
The last power in the string will fire first on the downpress. Then, since they are being labled as "toggles" the next power will fire on the release.
For doing this with powers that ARE toggles (not clicks), you may need to work the toggleoff command into the string.
"+ $$powexec_toggleoff sprint$$powexec_toggleoff combat jumping$$powexec_toggleon sprint$$powexec_toggleon combat jumping"
IOW, to make the first down/up turn stuff on, and the second down/up turn stuff off. I understand several folks with Keld builds do this for switching between forms, though I don't know if I have the right of it.
NOTE: It is necessary to use a "paused press" technique with these binds. Else, if the release is too quick, it will just que up the last power again.
Here is some info I came across while looking into this sometime back:
Quote:
*** A note about the "+" and "++" prefixes in some of these commands ***
The short explanation of the + and ++ prefixes is that they represent how persistently the command will be carried out. Most of these keybindings represent "press and fire" commands -- that is, you press down on the button and the action will be performed once, until the button is pressed again.
With a "+" prefix the command will be carried out for as long as the button is pressed down, and ceases as soon as the button is no longer being pressed. For example, the default binding for the w key is +forward. For as long as the w key is pressed down your character will continue moving forward... but as soon as the button is no longer being pressed, the character stops moving.
With a "++" prefix the command will be toggled "on" and will continue to be activated until the button is pressed again, toggling it "off." If the w key were bound to ++forward, pressing the w key once would cause the character to move forward, and that character would continue to move forward until the w key were pressed again.
Any command that has a + prefix can work with a ++ prefix, and vice versa. This can lead to some redundant commands. For example, ++forward works exactly the same as ++autorun -- you run until you turn the command off.
Through trial and error, I've formed the following theory on how the "+" modifier works in binding.
The "+" modifier has two behaviors.
Behavior one: at all times when "+" is prepended to a command, it is the same as doing "command 1". Obviously this only works correctly on commands that take 1 or 0 as input. When other commands are prepended with it, it adds the 1 to the end of the arguments, and gives an error. This behavior is mirrored by the "-" modifier, which yields argument 0.
Behavior two: ( Only when directly in the bind.. in other words this does not work when made a macro which you then bind to a key! )when prepended to the first command in a bind (assuming that command is one that works with it, ie takes 1/0 argument), it gives the entire bind statement a "press/unpress" behavior. This means two things:
* a) the command prepended with the "+" turns on (aka is given argument 1) when you press the key as you would expect per behavior 1. Additionally it turns off (argument 0) when you unpress the key
* b) the rest of the commands in the bind are performed once when you press the key, and again when you unpress it
Note that this behavior is not mirrored by the "-" modifier.. it might be nice if it did at least the first part, ie turn a command off when you press the key and back on when you unpress, but it doesn't.
Side note: I am actually a bit surprised that they decided to overload the use of the "+" in this way. It seems to me it would have been more intuitive and useful to have another character modifier (> for instance) to prepend to a bind statement (without a necessary command after it) to extend the second behavior, with the addition that any commands following in the statement with a "+" would work in the on/off manner when press/unpressed instead of just the first one.
The secondary behavior of the "+" in binds makes several useful things possible. Especially when you realize that the first command doesn't always have to do something, since you can always override it with a "-" form of it elsewhere in the bind. For instance a simple yet very useful bind for fly which makes you fly only while you hold down "f":
* /bind f "+up$$-up$$powexec_name Fly"
Another behavior can be achieved by exploiting the "overwrite" effect of powers (aka if several powers are entered one after the other in a bind, only the last one will go off in most cases). A very useful binding for getting out of melee range quickly with hover is:
* /bind v "+up$$powexec_name Hover$$powexec_name Hover"
This makes you jump and then hover up in the air just out of melee range. Note the doubling up of the hover power.. this is because if you only have it once in the bind, it will turn hover on when you press it and off when you let go (usually.. sometimes the hover from press and hover from unpress go through together and one gets overwritten, but this is rare). Why doesn't it turn on/off quickly when you press it and on/off quickly when you let go if you enter it twice? Because of the power overwrite effect.. while it is busy doing the jump when you press the button down, both hovers go through and the second overwrites the first, resulting in hover being turned on. When you let go, it stops the jump and both hovers go through, turning hover off and back on very quickly (before you drop) resulting in you being left in hover mode. This causes a bit of spam to your combat messages window, but it's worth it. Note: the differing behavior here (ie overwrite happening on press but not on unpress) I believe is due to the interaction between commands and powers on timing in a bind, but this is just a guess. -
Nope.
The raids were disabled on the LIVE servers, but were active on the TRAINING servers.
What remained on the live servers was RAID PATHING, which was part of the base editor and did not effect the mechanics of the actual raiding.
There was an ATTEMPT to re-vamp the raid system so they could bring them back to the live servers for i13, but it FAILED miserably. The result being that RAID PATHING was finally disabled on the live servers, since there was no real need for it. And raids were completely disabled on the training servers as well, since it was apparently borked beyond repair.
So, to summarize, we did not lose RAIDS on the live servers with i13 (they had been long disabled), we lost RAID PATHING (which, honestly, didn't really break too many hearts in these forums). You might consider that we "lost" raids because they were disabled on the training servers, but technically nothing is guaranteed to stay the same over there anyway (their doom was inevitable).
-
Not quite.
The way I understand it...
Base raiding on the live forums was very short lived due to exploitation. I've been playing since about i7, and there have not been base raids on the live servers in all that time. While they disabled the raiding mechanics on the live servers, they did leave raid pathing as part of the base editor's functionality. This was a bit of a thorn in many base architects' sides.
Base raiding did continue on the Training Server, however, and there was a healthy community of PvPers that staged raids over there.... until i13.
When they instigated various changes to the PvP game, they tried to make base raiding viable again, while also addressing some of the architect/editor's desires for more pathing flexibility. The results were.... less than optimal (read "disastrous"). Therefore, they decided to simply disable raid pathing and base raids altogether on all servers, live and training.
I suspect Base Raids will remain on the back burner until they can devise a way to make them viable for PvP as well as for the Architectural Artists. -
Quote:Originally Posted by MrVacant
... there are many more ways to skin this particular cat ...
wut?!
-
It's been pretty slow for me this morning as well. Hanging up on loading... even logged me out twice.... once not even 30 seconds after I re-logged in.
I've been doing the "just in case" ctrl+a, ctrl+c maneuver for my posts. -
I've tried incorporating the teamselect into my binds, but have not been able to get it to work the way I want (cycle through team list). I even tried it in a rotating bind (one key cycles through the team list), but it always got hung up at whatever point in the list I was at.... since I couldn't target myself, the command couldn't complete and move on to the next.
Sooooo.... currently I am using the default team select (shift + number) plus these nifty binds...
I do have some powers set to fire on a downpress/release. One power fires on the downpress, the other on the release. The trick is to use the "+" in combination with the "toggleon" command. It can force a click power to behave like a toggle power within the command string. Here are some examples:
"+ $$powexec_toggleon Aim$$powexec_toggleon Build Up"
"+ $$powexec_toggleon Nova$$powexec_toggleon Conserve Power"
"+ $$powexec_toggleon Increase Density$$powexec_toggleon Speed Boost"
The last power in the string will fire first on the downpress. Then, since they are being labled as "toggles" the next power will fire on the release.
For doing this with powers that ARE toggles (not clicks), you may need to work the toggleoff command into the string.
"+ $$powexec_toggleoff spring$$powexec_toggleoff combat jumping$$powexec_toggleon spring$$powexec_toggleon combat jumping"
IOW, to make the first down/up turn stuff on, and the second down/up turn stuff off. I understand several folks with Keld builds do this for switching between forms, though I don't know if I have the right of it.
NOTE: It is necessary to use a "paused press" technique with these binds. Else, if the release is too quick, it will just que up the last power again.
Here is some info I came across while looking into this sometime back:
Quote:
Quote:*** A note about the "+" and "++" prefixes in some of these commands ***
The short explanation of the + and ++ prefixes is that they represent how persistently the command will be carried out. Most of these keybindings represent "press and fire" commands -- that is, you press down on the button and the action will be performed once, until the button is pressed again.
With a "+" prefix the command will be carried out for as long as the button is pressed down, and ceases as soon as the button is no longer being pressed. For example, the default binding for the w key is +forward. For as long as the w key is pressed down your character will continue moving forward... but as soon as the button is no longer being pressed, the character stops moving.
With a "++" prefix the command will be toggled "on" and will continue to be activated until the button is pressed again, toggling it "off." If the w key were bound to ++forward, pressing the w key once would cause the character to move forward, and that character would continue to move forward until the w key were pressed again.
Any command that has a + prefix can work with a ++ prefix, and vice versa. This can lead to some redundant commands. For example, ++forward works exactly the same as ++autorun -- you run until you turn the command off.
Through trial and error, I've formed the following theory on how the "+" modifier works in binding.
The "+" modifier has two behaviors.
Behavior one: at all times when "+" is prepended to a command, it is the same as doing "command 1". Obviously this only works correctly on commands that take 1 or 0 as input. When other commands are prepended with it, it adds the 1 to the end of the arguments, and gives an error. This behavior is mirrored by the "-" modifier, which yields argument 0.
Behavior two: ( Only when directly in the bind.. in other words this does not work when made a macro which you then bind to a key! )when prepended to the first command in a bind (assuming that command is one that works with it, ie takes 1/0 argument), it gives the entire bind statement a "press/unpress" behavior. This means two things:
* a) the command prepended with the "+" turns on (aka is given argument 1) when you press the key as you would expect per behavior 1. Additionally it turns off (argument 0) when you unpress the key
* b) the rest of the commands in the bind are performed once when you press the key, and again when you unpress it
Note that this behavior is not mirrored by the "-" modifier.. it might be nice if it did at least the first part, ie turn a command off when you press the key and back on when you unpress, but it doesn't.
Side note: I am actually a bit surprised that they decided to overload the use of the "+" in this way. It seems to me it would have been more intuitive and useful to have another character modifier (> for instance) to prepend to a bind statement (without a necessary command after it) to extend the second behavior, with the addition that any commands following in the statement with a "+" would work in the on/off manner when press/unpressed instead of just the first one.
The secondary behavior of the "+" in binds makes several useful things possible. Especially when you realize that the first command doesn't always have to do something, since you can always override it with a "-" form of it elsewhere in the bind. For instance a simple yet very useful bind for fly which makes you fly only while you hold down "f":
* /bind f "+up$$-up$$powexec_name Fly"
Another behavior can be achieved by exploiting the "overwrite" effect of powers (aka if several powers are entered one after the other in a bind, only the last one will go off in most cases). A very useful binding for getting out of melee range quickly with hover is:
* /bind v "+up$$powexec_name Hover$$powexec_name Hover"
This makes you jump and then hover up in the air just out of melee range. Note the doubling up of the hover power.. this is because if you only have it once in the bind, it will turn hover on when you press it and off when you let go (usually.. sometimes the hover from press and hover from unpress go through together and one gets overwritten, but this is rare). Why doesn't it turn on/off quickly when you press it and on/off quickly when you let go if you enter it twice? Because of the power overwrite effect.. while it is busy doing the jump when you press the button down, both hovers go through and the second overwrites the first, resulting in hover being turned on. When you let go, it stops the jump and both hovers go through, turning hover off and back on very quickly (before you drop) resulting in you being left in hover mode. This causes a bit of spam to your combat messages window, but it's worth it. Note: the differing behavior here (ie overwrite happening on press but not on unpress) I believe is due to the interaction between commands and powers on timing in a bind, but this is just a guess. -
Quote:errrr... I think it's the fishnet stockings ... I mean really, fishnet is for catching fishiesOriginally Posted by Prof_Backfire
Whaddua mean my cocktail dress ain't goot enough for ya?!
-
Quote:Well, I hate to break it to ya Mr. Vick, but killing dogs carries prison penalties as well.Originally Posted by Myrmydon
Well, unfortunately, making the owner take a dirtnap is a felony.
The dog was just being a dog; an animal following its natural prey instincts. Taking revenge on the dog would be pointless.
There are laws... The owner can and should be held responsible.
I will comment on this matter no further, as it detracts from the consolation sentiments and support that Zube & his family need at the moment.
Again, Zube, my heart goes to you and your family for the loss of your feathered family member. In time the heartache will ease, in time.
(hugs)
-
Quote:Since we don't know the exact circumstances here, I'm not willing to lay blame on the dog.... more like the owner.Originally Posted by Myrmydon
Sounds like the dog needs to take a dirtnap.
Anyone who has a dog needs to realize that they are carnivores, and as such still retain their natural prey drive (some breeds more so than others). Hence, leash laws and fencing laws.
Dog owners have the responsibility of maintaining control of their animals at all times, whether that is through leash or through training.
Though I am not a bird person myself, I understand that macaws are very personable and usually long lived (50-80 yrs).
So very sorry for your loss, Zube. -
Quote:No, but I have sushi!Originally Posted by Bionic_Flea
Yo! Kitty! Do you have drinks and snacks?
*nom nom nom*
-
Quote:Minor Detail:Originally Posted by Sam_Hufinson
<Partial Posi announcement quote above>
My eye immediately jumped to the section of the announcement concerning in-game spam and the email system.
The rest is a blur at the moment.
I'm looking forward to i16.
Quote:Originally Posted by Starcloud
Positron:
WHen you say "only recieve mail from people on your friends list" does this refer to the *global* friends list, or to the *character* friends list?
There is a massive difference between the two.
With the character friends list, I cannot make a villain character a friend on a hero, or vice versa. This means that if it's limited by the character friends list, I will never be able to get e-mail from a villain on a hero or vice versa.
If it's limited by the global friends list, there is no issue.
Please clarify what you mean by "friends list" since there are two different lists in game.
Quote:Originally Posted by Positron
Current implementation on Training Room is "character" friends list. -
Quote:*nom noms nons*Originally Posted by EU_Damz
My head hurts from that to many nons
Quote:Originally Posted by Ullikummis
Too many *noms*?
mmmmmmm, fishies! -
I thought YOU were the bar nut, Flea...
*watches fishies intently* -
-
Quote:Question here, just to clarify...Originally Posted by Positron
As for low level characters missing out on accelerated leveling speeds, we are increasing the rewards they earn from level 1 to 20 (about 20% across the board) so that every player can get through the lower levels faster, not just those that know the tricks.
Which "rewards" are going to be increased? inf? exp? drops? all of the above?
I know you say "across the board", but the focus seems to lean heavily toward the "leveling faster" business, so a clarification would be nice.
I've already made my comment regarding the e-mail feature (global list please).
As for the SSK, although there seems to be a few implementation tweaks to work out, I'm liking the general idea... a lot.
-
67% explorer
60% socializer
47% achiever
27% killer
-
Huh.
Well, I have the sig images option turned off, so all I see is the link. When I click on the link, I get the cropped version of the pic. Guess that's just the way it's gonna work for me. *shrug*