Post: #1

Hello everyone. I have been stuck for a couple of weeks with a trouble that i could not solve.
I have tweaked the sphere source to build the combat system as i want, everything is working but i need to change this behaviour in sphere to make it perfect, it´s one of the few things left to do in my weapon/damage system.

using in sphere.ini
speedscalefactor=15000
combatspeedera=0
no combat flags
mondains legacy with 2.0.5 client.
the source modified is from january 2016.

Imagine the situacion, player A in front of player B with a distance of 1 tile. Player A click war button and dbclick player B. This is what happends with the setting before posted in that right moment when you dbclick in war mode:

attack anim -----> hit -----> recoil anim -----> swing time -----> attack anim -----> over again same pattern.

You all would see this if you have the same settings posted above.

And i would like to start the fight combat in this way:

swing time -----> attack anim -----> hit -----> recoil anim -----> swing time -----> over again same pattern.

In other words how can i start the record of the fight with war_swing_swinging instead of war_swing_ready? then the system would work the same way as the sphere custom default.

I have tried to do it with an event in a softcoded way, but to work it properly i had to redo all the combat system and i would prefer a rat pack than this, since been doing everything in source for weeks.
i thought it was easier, until i found this... i have no clue on how to handle this, tried to play a bit with fight memories in source but i messed up the whole system always.

if anyone who "plays" with source or one of the devs can help me out or just give me some advice i would be really appreciate. If someone know how to do it in scripts without redo the system you are very welcome too. Regards and thanks in advance.

Post: #2

it's not clear if you want change the "waiting delay" from the start to the end of the action, or if you just want simulate the old behavior which there's no "waiting delay" (because the animation time is always the same of the action time, so an 2.7s swing will slow down the animation to 2.7s too, etc)

in this case you just need change the attack animation delay to use the same timer of the action

Post: #3

Hello Coruja, thanks very much for response. Sorry if i did not stated it more clearly before.

This is the way i see things in combat by checking source code:

war_swing_swinging: i take iswingdelay from weapon selected and wait until time is over.(the more weight more iswingtime, if twohand more iswingtime even, saying it fast and bad ---> using sphere custom formula). (bardiche can take 8,7 seconds and halberd 10 just an example).

war_swing_ready: ok now iswingdelay time is over, i´m ready to hit, if i have my opponent near my attack anim will show up and will hit or miss to player, if not i´ll be holding the hit waiting to be near and hit/miss in that precision time i´m close to my opponent.

war_swing_equipping: recoil anim and we say swing is finished.
When war_swing_equipping ends I call again war_swing_swinging if i keep the intend to hit again.
That´s how I would like it to run it. Actually when I try to hit for first time a player my character starts the fight in war_swing_ready instead of war_swing_swinging because @HitTry is called when war_swing_ready takes place in action.

I commit a mistake by don´t telling that im using sphere custom combat formulas but I tweaked some things like this that would answer your question about how iswingdelay and animdelay works in my system, take a look at //MOD. comments:


My animdelay is always the same for every weapon but not it´s argn1 for each on @Hittry, just like 51a. I made an event that involved all weapons from second age assigning a custom argn1 value like if (<argo.baseid>==i_bardiche)  argn1=87 endif… I don´t care about the formula because i know in seconds how they should work.
It takes 0,014/0.01 = 1,4 seconds to display the whole anim (forward swing plus recoil anim) because that:

So it´s not working really like sphere custom, I made this “cheap trick” to accomplish my targets, it´s all about like reverse engeenering looking through older versions.

So just realize that animdelay is the same for every weapon in my system, but iswingspeed is different for each other.

My problem comes when I want to start a fight and with the first hit. There is no iswingdelay called before hitting the opponent for first time, anim comes as fast as I double click player in war mode and once hit or miss iswingdelay is now coming but not in first hit.

Here are some vids with the differences between versions more easy so you can check out by yourself better. in 0.56c when player says current time it is the time that the swing took to complete (argn1 in hittry trigger). Also be aware that attacks starts for me when player turn blue just before double clicking him in war mode.

0.56c:




0.51a (the way i want)




Thanks for your time again, i hope you see better this time. Greetings mate.

Post: #4

I still don't see the issue, except the delay for your first one was longer and your target didn't strike back in defense (Which I am assuming that might be your issue is the latter). Otherwise, I am with Coruja, what is wrong? The delays seem be different which you can change. Minus the Mobile not striking back (again, bug?), I don't see what is wrong. Just change your formulas. I will dig out my old UO:R Combat system and release it again if needed. It replicated old EA/UO:R perfectly.

Post: #5

Yes you are right, the target doesn´t strike back until damage is done but that wouldn´t be hard to change, i have not checked at all yet.

i just would like to add for now the 7.4 seconds of the bardiche ot whatever weapon is it when i double click in war mode the target, then everything goes well for me and i don´t need to change anything, and i will need another 7,4 for a next hit release and so on.

i know that in the second video the bardiche hit quick for being a polearm but i think the evidence is tangible. In 51a it takes like 3 second moreless at the beggining, in 0.56c it is instant. in that 51a the speed of the weapons are quick as hell and imo screwed. About the osi uo:r system... i just know sphere51a was somehow based on it but the differences are not small for what i heard, never played osi hehe. Thanks for your time, greetings.

Post: #6

Okay, I am understanding you now.

Coruja, what he is saying is there is no delay at the beginning swing itself. Honestly, it might just need a flag for it in the INI. Because he is right, there was a delay in initial fight swing pre-AoS in UO:R if I remember right. Then in AoS+ it was considered a pre-swing I believe. I'd have to log into an EA account in a few days to test to be sure. An INI option for either way would be best, because as it is, it is a pre-swing, then delay. He wants a delay, then a fight swing. It should be optional either way which gets done, because video games differ in how they handle fight swings in any game.

---

Gunther for a quick workaround, you could do this:


or

---

Hope this helps for now. Let me know if that solves the issue any. It could be just what you need to stop that pre-swing. Honestly, you could do your whole combat speed system in @HitTry and override Sphere. I did it in my code before they did the hard code changes. I ran the entire AoS Speed system through @HitTry.

Post: #7

honestly I think that "pre-swing-delay" is a bug instead feature. Probably it happens on 51a because old codes are somewhat weird, where the client send the attack request to server, the server receive this request, but will only start the action on next server tick after ~1s (which is not correct, because the server must start the action immediately instead wait for the next tick)

the current internal code (even using legacy formulas) is much more accurate, reliable, optimized and customizable compared to the code from 15 years ago, so copy the old behavior is like take a step backward. Instead, you can use the new code and just tweak the animation/swing delay, like this

or
etc

PS: ARGN1 will override the internal swing speed formula (CombatSpeedEra) allowing you to use a custom formula. Also if you don't set LOCAL.AnimDelay it will be 7 by default

Post: #8

(02-17-2016 03:12 PM)Khaos Wrote:  Okay, I am understanding you now.

Coruja, what he is saying is there is no delay at the beginning swing itself. Honestly, it might just need a flag for it in the INI. Because he is right, there was a delay in initial fight swing pre-AoS in UO:R if I remember right. Then in AoS+ it was considered a pre-swing I believe. I'd have to log into an EA account in a few days to test to be sure. An INI option for either way would be best, because as it is, it is a pre-swing, then delay. He wants a delay, then a fight swing. It should be optional either way which gets done, because video games differ in how they handle fight swings in any game.

---

Gunther for a quick workaround, you could do this:

Code:

on=@HitTry
argn1=7.5
return 0

or

Code:

on=@HitTry
argn1=<src.findlayer.layer_hand1.uid.speed>
return 0

---

Hope this helps for now. Let me know if that solves the issue any. It could be just what you need to stop that pre-swing. Honestly, you could do your whole combat speed system in @HitTry and override Sphere. I did it in my code before they did the hard code changes. I ran the entire AoS Speed system through @HitTry.

Thanks for response khaos, now you know what i mean hehe.I tried what you said but it didn´t worked. i have tried things like that without success. I think it is what i´m going to do, rescript everything under calling fulltriggers, but memories are gonna be funny to script linking them with combat flags lol, well i´ll see if following that way i reach the prize.

The reason i tried to do in source is because i think it could lightweight fight of more memories and make them goes very smooth like the old days(wich is not a scientific fact). Same for trying to run a 51a replica with clients that doesn´t belong to reinassance or t2a era, im really sceptic about that but everyone has their opinion and taste, so i. Greetings!

(02-18-2016 02:06 AM)Coruja Wrote:  honestly I think that "pre-swing-delay" is a bug instead feature. Probably it happens on 51a because old codes are somewhat weird, where the client send the attack request to server, the server receive this request, but will only start the action on next server tick after ~1s (which is not correct, because the server must start the action immediately instead wait for the next tick)

the current internal code (even using legacy formulas) is much more accurate, reliable, optimized and customizable compared to the code from 15 years ago, so copy the old behavior is like take a step backward. Instead, you can use the new code and just tweak the animation/swing delay, like this

Code:

//total swing delay is 7.4s, where the animation/damage occour in 5.0s and waiting the rest of the 2.4s
ON=@HitTry
LOCAL.AnimDelay=50
ARGN1=74

or

Code:

//animation/damage will always be the same of the total swing delay, with no waiting delay
ON=@HitTry
LOCAL.AnimDelay=<ARGN1>

etc

PS: ARGN1 will override the internal swing speed formula (CombatSpeedEra) allowing you to use a custom formula. Also if you don't set LOCAL.AnimDelay it will be 7 by default

Thanks for help Coruja. im just interesting in having local.animdelay=14 for every weapon. Then bardiche can have a total time of 7,4 wich result in 7,4-1,4= 6 seconds of waiting like you said before, battle axe can have 6 seconds of total but it results in 6-1,4=4.6 seconds of waiting. So 6 (bardiche) or 4.6 (battle axe) or whatever weapon is it, what i want is add that number plus 1 second replicating the old system while just giving the first hit that delay!. So first hit for a bardiche take 6 seconds + 1 second and the swing comes, the next ones to be released will just take 6 seconds of waiting and swing comes again.


You were right and wrong and how 51a worked. But it´s not just 1 second and 51a send to trash the 6 resting seconds from the bardiche at first hit. It takes 1 second cause the old tick behaviour + the waiting seconds of the weapon. i have just checked it out in a old full 51a server changing speeds of weapons.

This system was full of bugs and you are right 100% about this. But it was what people liked and made it famous. I think menasoft devs had something like a serendipity. they found something good without looking at it, and thanks to that serendipity some of us had some damn good times and we lived the golden era of ultima online with sphere at the top. I don´t see it like a back step, i see it like a tribute to these old times and give back what was given to me. What´s better the new or old? well everyone has his favourite color ^^. Thanks for your time and help, greetings!

PD: i was confusing swing_swinging with argn1 and that´s totally wrong now i see it clear.

Post: #9

(02-18-2016 02:06 AM)Coruja Wrote:  honestly I think that "pre-swing-delay" is a bug instead feature. Probably it happens on 51a because old codes are somewhat weird, where the client send the attack request to server, the server receive this request, but will only start the action on next server tick after ~1s (which is not correct, because the server must start the action immediately instead wait for the next tick)

the current internal code (even using legacy formulas) is much more accurate, reliable, optimized and customizable compared to the code from 15 years ago, so copy the old behavior is like take a step backward. Instead, you can use the new code and just tweak the animation/swing delay, like this

Code:

//total swing delay is 7.4s, where the animation/damage occour in 5.0s and waiting the rest of the 2.4s
ON=@HitTry
LOCAL.AnimDelay=50
ARGN1=74

or

Code:

//animation/damage will always be the same of the total swing delay, with no waiting delay
ON=@HitTry
LOCAL.AnimDelay=<ARGN1>

etc

PS: ARGN1 will override the internal swing speed formula (CombatSpeedEra) allowing you to use a custom formula. Also if you don't set LOCAL.AnimDelay it will be 7 by default

Which was a precise point I was making, that the @HitTry and <Argn1> can completely rewrite his own system.

The only thing I am wondering is, was it a bug back in the day?! I mean OSI ran it the same way if I remember right. I think it was just their feature and then EA/Mythic changed it. Either way, it can be redone in @HitTry.

Gunther, I do not suggest adding a lot to the source. You could do this with soft code, which the source actually reads very fast and is made for the soft code overrides. Hence why Sphere you can do just about anything with. Our goals were to put most of the source we could into scripts to make less work on the server processing. Script code is as lightweight as the user makes it.

Just add that local.animdelay=14 to @HitTry if you want it on every fight swing and add it to skillclass 0 or a player event. That would give you that delay on every weapon.

I mean really, you could just do:

This will give you the 1.4 second hit and whatever time is left for the wait.

Post: #10

Hi khaos, that just set animdelay and argn1 but no pre swing delay like i pretend. Like i said before i´m happy with animdelay and argn1 values i have, it´s working like i wanted. The only trouble is i want to start the combat with that argn1 value as a delay, once this delay expires the combat just work as the same way sphere does without anything extrange added on in mentioned feature. I´m using an old client but i think doesn´t mess with the event... that just would happend when you start a fight against a player.

|-------------------| |-------| |-------------------| |-------| |-------------------|


delay=<argn1>=6 seconds for a bardiche.
swing=local.animdelay=1,4 seconds

right now it works like this in 0.56c with the event wich is at i was first:
|--------| |-------------------| |--------| |-------------------| |--------|

nothing changed...


Im just figuring out the best way to do it is creating a memory and a few checks when fights starts and memories comes in action, i´m going to work in that way under hitcheck since i need to change parrying skill on @gethit so it´s better to start from the scratch and see how it works and fuck the 1 second plus, no one cares about 1 second really.

About the osi old system i have been reading the official origin´s guide from second age and there is not nothing related to some kind of predelay. Greeting and thanks so much for the support man!!.