RendarQueloon Posted July 21, 2006 Share Posted July 21, 2006 Not sure if this should go into a different thread, but since its about the saber system and most of vets are involved thought I would bring this up. SO far I have only played with bots (mostly due to not finding a server with any real people on). The only way I can win is if I play almost %100 defensively and just parry the hell out of the bots untill they mishap and then get some quick swings in on them. Is there a way to fight effectively doing more offense? Does this system have "swing blocking" in it, to say like if they swing right, instead of parrying can I just swing left into there swing and will it cause a parry? One more thing, Not sure if this is a bug or not, but using enhanced I can block %95 perect of all bots attacks just by walking and hold backwards. Side Slashes, vertical slashes, diagnol slashes, all them are blocked by backwards parrying Link to comment Share on other sites More sharing options...
JRHockney* Posted July 21, 2006 Author Share Posted July 21, 2006 I'm assuming you're playing 0.0.9b right? The best way to not play defensively it to combo swing the heck out of the bots and try to hit them on what ever side they are not moving into (this way they wont parry you) you can actually get alot of high swings in on bots because they dont move backwards hardly at all. You can also sort of pary in certain parts of your swing and if you hit there saber, it bounces off and costs no DP usually. Happy 500 post to me!!! LOL. I'll celebrate with a new avatar when I find one. Link to comment Share on other sites More sharing options...
Sushi_CW Posted July 22, 2006 Share Posted July 22, 2006 The reason I don't set up a code server is simply that I don't have a spare machine to do it on at the moment. Do I think my experiment is an improvement? Of course! Then again, I am biased. What I'd like most is to be able to see how it plays human vs human. I think that people who blindly swing-spam will be pretty heavily punished for it: It doesn't take many parries to put the attacker in a world of hurt. Even trying to attack and parry at the same time doesn't put your mishap down as fast, since there is no regen while attacking. That way, pure defenders get the mishap bar advantage. If people try to jump or run away, their mishap bar won't go down any faster than if they stay and parry successfully. There is no regen at all in the air, and regen while running is halved. As far as not resetting to 0 on full mishap: I've actually toyed around with that, haven't found anything I like yet though. I'll keep playing with it. Link to comment Share on other sites More sharing options...
JRHockney* Posted July 22, 2006 Author Share Posted July 22, 2006 The thing is, I kind of like the advantage of swing and parrying at the same time because that helps keep the swinging part this system out of pure swing spam territory. Maybe we should allow regular parrying to still lower the mishap bar, but make it less then half of what it lowers it at the moment. That way it will still be possible to overswing but a person swinging and parrying at the same time will have a bigger advantage over somebody whos not doing that as well. And yeah good luck with that "not making the mishap bar go to 0" thing. I think that is important. More than anything though, I think you should keep learning this code as well as you can. Dont be afraid to run crazier experiments with different parts of the code. The more you know about it, the more you'll be able to do and that will help the OJP community out greatly as Razor starts doing less because of his new job. not that I expect you to take a huge role in the coding, but your help will be greatly appreciated. Link to comment Share on other sites More sharing options...
Sushi_CW Posted July 22, 2006 Share Posted July 22, 2006 That way it will still be possible to overswing but a person swinging and parrying at the same time will have a bigger advantage over somebody whos not doing that as well. I think this is already the case. Pure defense gets the biggest mishap bar advantage, but attacking while parrying will definitely work much better than if you just swing. Link to comment Share on other sites More sharing options...
JRHockney* Posted July 22, 2006 Author Share Posted July 22, 2006 I think this is already the case. Pure defense gets the biggest mishap bar advantage, but attacking while parrying will definitely work much better than if you just swing. Well yeah, it will be easier on your DP to do that, but they will hit their highest mishap threshold at the same time as a nonswinging and parrying person. I'd rather that not be the case so it can better promote playing enhanced the way it should be in my opinion. I think swinging and parrying is what will make this gameplay the most movie realistic while being workable as well. Link to comment Share on other sites More sharing options...
JRHockney* Posted July 24, 2006 Author Share Posted July 24, 2006 I just discovered something very disturbing about 0.0.9f. Tanqexe had mentioned several times that he thinks the hit detection is messed up because he kept losing almost all his life with one hit on several ocassions especailly when fighting Tabbots. Because of this, I decided to test it out by standing still and letting Tabbots hit me many many times while watching the swing and the DP meter at the same time. I notice the same thing that Tanqexe noticed. Basically, several times, one swing ended up hiting 2 or 3 times at once and doing double or triple damage! The saber often literally switches blocking positions two or three times in these hits (which looks very cool, but the result is the loss of your entire DP meter. hehe). I guess we weaken the bounce too much or something. I would recommend either strengthing the bounce again and find another way to fix the lightning strikes or make it so that there is a minimum amount of time that has to pass for a second hit to do damages after a first (or both). FOr that second idea, maybe the intervals could differ for each style. Link to comment Share on other sites More sharing options...
Sushi_CW Posted July 24, 2006 Share Posted July 24, 2006 Yeah, I've noticed that too. Good job confirming/reproducing it! Link to comment Share on other sites More sharing options...
JRHockney* Posted July 25, 2006 Author Share Posted July 25, 2006 Yeah, I've noticed that too. Good job confirming/reproducing it! Thanks. Most of the credit goes to Tanqexe for mentioning it alot. Sushi, do you think you could create set time intervals between when each hit is allowed like I mentioned above? It would solve this problem and also eliminate any chance of lightning strikes if we ever did restrengthen the bounce like it was before. It might also be an interesting challenge. Link to comment Share on other sites More sharing options...
UDM Posted July 25, 2006 Share Posted July 25, 2006 Yeah, the lightning strikes strike back!!! I assume the reason for this is because: tabbots parry like crazy. Notice that when you hit them, they start jittering in all directions. I think this is because they are trying to parry oncoming attacks The funny thing is, I never get this problem when I play with normal bots. Never. That's what led me to assume that the problem lies with tabbots But I could be wrong on this. Whatever it is, any solution that fixes lightning strikes w/o breaking gameplay is okay by me Anyway hockney your sig is AWESOME! Link to comment Share on other sites More sharing options...
razorace Posted July 25, 2006 Share Posted July 25, 2006 Sushi, do you think you could create set time intervals between when each hit is allowed like I mentioned above? It would solve this problem and also eliminate any chance of lightning strikes if we ever did restrengthen the bounce like it was before. It might also be an interesting challenge. mmm, I thought I had fixed that. Crap! The code does already have a built-in delay between impacts, but it's set very fast so prevent passthru situations. As for this problem, it probably not hit detection related. Rather, it's probably some of the bgame causing the saber to rapidly jump into an attack after a bounce, again. Link to comment Share on other sites More sharing options...
JRHockney* Posted July 27, 2006 Author Share Posted July 27, 2006 mmm, I thought I had fixed that. Crap! The code does already have a built-in delay between impacts, but it's set very fast so prevent passthru situations. As for this problem, it probably not hit detection related. Rather, it's probably some of the bgame causing the saber to rapidly jump into an attack after a bounce, again. Hmmm, is it possible to make it so that DP damage could only happen for each impact if a certain amount of time has passed since the last DP damaging impact? That way we could have the same hit detection without any of the lightning stike problems of the past. Is there anything simple coding wise that I can do to fix it for now and if so, what file do I look in? I would like to be able to test a version of this with more actuate hit detection so I can make more actuate suggestions about what the DP hit values should be for each style. Of course if you have the means to send us a dll patch with a fix, that would be good too. Quite idea: I noticed that there is no saber on saber flash glow in a saber lock in enhanced like there is in the movies. Is there any possibility of programming a glow between sabers in a saber lock? Link to comment Share on other sites More sharing options...
Vruki Salet Posted July 27, 2006 Share Posted July 27, 2006 The code does already have a built-in delay between impacts, but it's set very fast so prevent passthru situations. How about setting the delay low before the saber reaches a persons bbox then upping it when it does? That way it'll still be good to prevent passing through an opponent's saber. Link to comment Share on other sites More sharing options...
Sushi_CW Posted July 27, 2006 Share Posted July 27, 2006 I've posted an update to my experimental .pk3 package. Sorry, no fix for the rapid-impact problem, but I've tweaked a few more things and am pretty happy with the result (as happy as I'm going to be until I can play against some humans... anyone willing to volunteer a server? ). Link here. Enjoy! Here are the gruesome details: Stuns and heavy bounces no longer reset the meter all the way to 0. I made push/pulling someone from behind unblockable again. I implemented my changes to the way force jump costs are handled. Regen rules for the mishap bar: - Mishap bar does not regen while attacking or transitioning. - Mishap bar regens at half speed while running. - Mishap bar doesn't regen at all in the air. Penalty rules for the mishap bar: - Hitting an opponent's saber during an attack costs you 1 MP for normal attacks, 2 MP if you are attack faking. Hitting the saber of an attack faker costs you 1 MP and costs him 2 MP. - Hitting an opponent with a normal attack: Costs the attacker 1 MP if blocked and 3 MP if parried. Costs the defender 1 MP to either block or defend. - Hitting an opponent with an attack fake: Costs the attacker 1 MP if blocked and 3 MP if parried. Costs the defender 3 MP to block and 1 MP to parry. The modifications I've made intentionally make it difficult to simultaneously protect your MP, protect your DP, and press an attack. You have to tactically choose which to focus on. Link to comment Share on other sites More sharing options...
JRHockney* Posted July 27, 2006 Author Share Posted July 27, 2006 Um, I think your links broken or something. It just goes to a blank screen and doesnt load anything. Im not sure about making the back vulnerable to Push and pull again at all times. The reasons we made it so that it was only vulnerable to force powers when low on DP or Balance was because it made two on one way too hard and because a few people where jump consantly jumping behind people and pushing or using lightning on their back while in mid air. Link to comment Share on other sites More sharing options...
Sushi_CW Posted July 27, 2006 Share Posted July 27, 2006 The link is the same one as before, it should work. Maybe try it in a new window or different browser? As far as the back pushing... you're right. But, since latest-beta Enhanced servers are rare these days, it makes playing solo more fun. Link to comment Share on other sites More sharing options...
Maxstate Posted July 27, 2006 Share Posted July 27, 2006 I seem to be having some trouble with instant-dp losses in 009F It happens randomly or when I try to parry by using my diagonal-up keys (w+a w+d), it makes my DP crumble all the way to its red zone for no apparent reason, I have screenshots which show my mishap bar being low or empty so I dont think its my own fault. It happens with bots and human players. Link to comment Share on other sites More sharing options...
UDM Posted July 27, 2006 Share Posted July 27, 2006 Me thinks that the only way to fix this is to implement hockney's idea of an invisible barrier. It's just too bad that the engine doesn't allow this Link to comment Share on other sites More sharing options...
razorace Posted July 28, 2006 Share Posted July 28, 2006 Hmmm, is it possible to make it so that DP damage could only happen for each impact if a certain amount of time has passed since the last DP damaging impact? That way we could have the same hit detection without any of the lightning stike problems of the past. There's no need for that. Impacts only cost DP if they were in an attack move. And this shouldn't be possible since the players are supposed to go into bounces after every attack impact. Quite idea: I noticed that there is no saber on saber flash glow in a saber lock in enhanced like there is in the movies. Is there any possibility of programming a glow between sabers in a saber lock? Yeah, I know. But I'm not sure how we can impliment it since the saber detection is turned off during saber locks for technical reasons. How about setting the delay low before the saber reaches a persons bbox then upping it when it does? That way it'll still be good to prevent passing through an opponent's saber. That would eliminate the purpose of the debounce since the bbox is often hit before the saber is hit. Or maybe I just don't understand what you're suggesting. Link to comment Share on other sites More sharing options...
JRHockney* Posted July 29, 2006 Author Share Posted July 29, 2006 There's no need for that. Impacts only cost DP if they were in an attack move. And this shouldn't be possible since the players are supposed to go into bounces after every attack impact. Ok, but what ever it is, it really needs to be taken care of. Its driving us nuts! LOL Yeah, I know. But I'm not sure how we can impliment it since the saber detection is turned off during saber locks for technical reasons. Hmmm, if its possible to turn it back on, maybe we can just make it so it is impossible to have any DP drain while in saberlock. I just had another idea for another saberlock technique.I've heard that MB2 is planning on adding quick saber lock animations in the combat to keep better space in the duals and "just look cool." This give me a mostly unrelated but similar idea visually. I do think that quick saberlock animations would make the combat look even cooler in OJP, but I have an most technique/gameplay idea on how to do it: Basically: we'll add another function to the attack fakes by making it do something a little different if you keep holding both alt attack and attack all the way through the attack fake instead of letting go of alt attack in the swing. What will happen is if the defender does not parry it correctly, you will both go into a saber lock animation with you automatically pushing them in the winning direction and they wont be able to fight it. What happens at the end of the lock will depend on how much DP the Defender has. The DP levels will vary like this: For 3/4+, nothing will happen For 1/2+ a simple slowbounce For 1/4+ a heavy bounce or something else For 0+ a disarm (the next hit will probably be fatal, which will make for some AWSOME Killing hits!) The point of having this variation will be to have the standard attack fake to be about the balance bar and doing a little more DP damage like it is know, and the new attack fake will be about testing your opponents DP levels and adding the saberanims in for visual effect. Of course if there is going to be more attack fake usage in general, we might want to make hitting a person in attack fake cost a little more DP. Maybe 1.25 or 1.5. Also, I was wondering if it would be possible with this new attackfake based saber lock technique if it would be possible to make it so that the person who attacks with this move and successfully hits the defender without getting parried will force the defender to walk backwards while the saberlock takes place. This would add the possiblity of forcing people off cliffs in the saberlock . Of course this could only be done if it is possible to change the lower events for both people in a saber lock to a walking animation. The attacker would walk forward and the defender would backup. Moving in this particular saber lock would also add an awsome movielike visual effect. Lastly, I've been thinking more about the possibility of trying my old "make the turning moves a little stronger" idea again just for variety and control sake. The idea was to make them do maybe 1.25 more damage and cost 1.25 for getting hit while trying it as well as having the damage of the swing negated. This would be fairly reasonable and even make maxstate's anims make more sense. Link to comment Share on other sites More sharing options...
UDM Posted July 29, 2006 Share Posted July 29, 2006 I second the saber lock idea. That sounds really cool, saber locks should be more frequent but not restricted to 10-second long button mashing activities Link to comment Share on other sites More sharing options...
Maxstate Posted July 29, 2006 Share Posted July 29, 2006 Ok, but what ever it is, it really needs to be taken care of. Its driving us nuts! LOL Hmmm, if its possible to turn it back on, maybe we can just make it so it is impossible to have any DP drain while in saberlock. I just had another idea for another saberlock technique.I've heard that MB2 is planning on adding quick saber lock animations in the combat to keep better space in the duals and "just look cool." This give me a mostly unrelated but similar idea visually. I do think that quick saberlock animations would make the combat look even cooler in OJP, but I have an most technique/gameplay idea on how to do it: Basically: we'll add another function to the attack fakes by making it do something a little different if you keep holding both alt attack and attack all the way through the attack fake instead of letting go of alt attack in the swing. What will happen is if the defender does not parry it correctly, you will both go into a saber lock animation with you automatically pushing them in the winning direction and they wont be able to fight it. What happens at the end of the lock will depend on how much DP the Defender has. The DP levels will vary like this: For 3/4+, nothing will happen For 1/2+ a simple slowbounce For 1/4+ a heavy bounce or something else For 0+ a disarm (the next hit will probably be fatal, which will make for some AWSOME Killing hits!) The point of having this variation will be to have the standard attack fake to be about the balance bar and doing a little more DP damage like it is know, and the new attack fake will be about testing your opponents DP levels and adding the saberanims in for visual effect. Of course if there is going to be more attack fake usage in general, we might want to make hitting a person in attack fake cost a little more DP. Maybe 1.25 or 1.5. Also, I was wondering if it would be possible with this new attackfake based saber lock technique if it would be possible to make it so that the person who attacks with this move and successfully hits the defender without getting parried will force the defender to walk backwards while the saberlock takes place. This would add the possiblity of forcing people off cliffs in the saberlock . Of course this could only be done if it is possible to change the lower events for both people in a saber lock to a walking animation. The attacker would walk forward and the defender would backup. Moving in this particular saber lock would also add an awsome movielike visual effect. Lastly, I've been thinking more about the possibility of trying my old "make the turning moves a little stronger" idea again just for variety and control sake. The idea was to make them do maybe 1.25 more damage and cost 1.25 for getting hit while trying it as well as having the damage of the swing negated. This would be fairly reasonable and even make maxstate's anims make more sense. [/agree] Link to comment Share on other sites More sharing options...
razorace Posted July 29, 2006 Share Posted July 29, 2006 The "turning moves" were the cause of the lightning strikes issue that we were having earlier. Making them do non-idle damage causes them to be blocked and causes the weird DP damage levels we were seeing. So, what's the point of the standard attack fakes then? Why not just have the attack fakes always cause saberlocks? Link to comment Share on other sites More sharing options...
Maxstate Posted July 29, 2006 Share Posted July 29, 2006 The "turning moves" were the cause of the lightning strikes issue that we were having earlier. Making them do non-idle damage causes them to be blocked and causes the weird DP damage levels we were seeing. So, what's the point of the standard attack fakes then? Why not just have the attack fakes always cause saberlocks? I think he's just trying to save you the effort of making more buttons or more attacks. Link to comment Share on other sites More sharing options...
Sushi_CW Posted July 29, 2006 Share Posted July 29, 2006 I think I'd rather have these auto-win, fast locks as random events (like the way normal saber locks work) since they're mostly there just to look cool anyway. I also suspect that you'd need a bunch of new animations to make it work...it'll be interesting to see how MB2 handles whatever they're doing. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.