Forums WoW Modding Support Archives TrinityCore Discord Archives [DiscordArchive] do transports keep adding up pathProgress even when starting the path again, stay it reaches end poi

[DiscordArchive] do transports keep adding up pathProgress even when starting the path again, stay it reaches end poi

[DiscordArchive] do transports keep adding up pathProgress even when starting the path again, stay it reaches end poi

Pages (2): 1 2 Next
rektbyfaith
Administrator
0
04-14-2025, 02:21 PM
#1
Archived author: Telegrill • Posted: 2025-04-14T14:21:47.590000+00:00
Original source

do transports keep adding up pathProgress even when starting the path again, stay it reaches end point and it starts its pathing again?
rektbyfaith
04-14-2025, 02:21 PM #1

Archived author: Telegrill • Posted: 2025-04-14T14:21:47.590000+00:00
Original source

do transports keep adding up pathProgress even when starting the path again, stay it reaches end point and it starts its pathing again?

rektbyfaith
Administrator
0
04-14-2025, 02:23 PM
#2
Archived author: Telegrill • Posted: 2025-04-14T14:23:39.688000+00:00
Original source

cause it sounds pretty weird that the client wouldn't expect time within 1 cycle only
rektbyfaith
04-14-2025, 02:23 PM #2

Archived author: Telegrill • Posted: 2025-04-14T14:23:39.688000+00:00
Original source

cause it sounds pretty weird that the client wouldn't expect time within 1 cycle only

rektbyfaith
Administrator
0
04-14-2025, 02:25 PM
#3
Archived author: Telegrill • Posted: 2025-04-14T14:25:51.996000+00:00
Original source

and honestly, it raises concern about long-term overflow if the are quite a lot of cycles happening
rektbyfaith
04-14-2025, 02:25 PM #3

Archived author: Telegrill • Posted: 2025-04-14T14:25:51.996000+00:00
Original source

and honestly, it raises concern about long-term overflow if the are quite a lot of cycles happening

rektbyfaith
Administrator
0
04-14-2025, 02:26 PM
#4
Archived author: Tea • Posted: 2025-04-14T14:26:28.579000+00:00
Original source

you are never going to overflow it
rektbyfaith
04-14-2025, 02:26 PM #4

Archived author: Tea • Posted: 2025-04-14T14:26:28.579000+00:00
Original source

you are never going to overflow it

rektbyfaith
Administrator
0
04-14-2025, 02:26 PM
#5
Archived author: Tea • Posted: 2025-04-14T14:26:45.823000+00:00
Original source

i mean you will
rektbyfaith
04-14-2025, 02:26 PM #5

Archived author: Tea • Posted: 2025-04-14T14:26:45.823000+00:00
Original source

i mean you will

rektbyfaith
Administrator
0
04-14-2025, 02:26 PM
#6
Archived author: Telegrill • Posted: 2025-04-14T14:26:53.166000+00:00
Original source

tecnically, it will never happen
rektbyfaith
04-14-2025, 02:26 PM #6

Archived author: Telegrill • Posted: 2025-04-14T14:26:53.166000+00:00
Original source

tecnically, it will never happen

rektbyfaith
Administrator
0
04-14-2025, 02:26 PM
#7
Archived author: Tea • Posted: 2025-04-14T14:26:54.168000+00:00
Original source

but good luck running it for 49 days
rektbyfaith
04-14-2025, 02:26 PM #7

Archived author: Tea • Posted: 2025-04-14T14:26:54.168000+00:00
Original source

but good luck running it for 49 days

rektbyfaith
Administrator
0
04-14-2025, 02:27 PM
#8
Archived author: Telegrill • Posted: 2025-04-14T14:27:38.533000+00:00
Original source

but besides the overflow concern, is it reasonable that the client would expect a progress that's not based on 1 time only?
rektbyfaith
04-14-2025, 02:27 PM #8

Archived author: Telegrill • Posted: 2025-04-14T14:27:38.533000+00:00
Original source

but besides the overflow concern, is it reasonable that the client would expect a progress that's not based on 1 time only?

rektbyfaith
Administrator
0
04-14-2025, 02:29 PM
#9
Archived author: ModoX • Posted: 2025-04-14T14:29:49.128000+00:00
Original source

<@184268014538063882> in CheckProc you do the checks which you cannot do via the spell_proc table (e.g. complex logic). Limiting proc triggers to certain spells or crits only can be done via spell_proc.

GetCaster() is always who casted the spell/who applied the aura
GetOwner() is the owner of the auras (pretty much only relevant for pala auras like devotion aura or aura mastery)
GetTarget() is the person who has the aura

But keep in mind. If i moonfire you, i'm caster and you are target. If i logout caster is null and you are still the target.

eventInfo also provides 2 targets. GetActor or something, which is the unit causing the proc. E.g. if you have a proc aura which procs on damage taken and i moonfire you again, im the actor, may vary per proc. The other one was ActionTarget, which varies per proc.
rektbyfaith
04-14-2025, 02:29 PM #9

Archived author: ModoX • Posted: 2025-04-14T14:29:49.128000+00:00
Original source

<@184268014538063882> in CheckProc you do the checks which you cannot do via the spell_proc table (e.g. complex logic). Limiting proc triggers to certain spells or crits only can be done via spell_proc.

GetCaster() is always who casted the spell/who applied the aura
GetOwner() is the owner of the auras (pretty much only relevant for pala auras like devotion aura or aura mastery)
GetTarget() is the person who has the aura

But keep in mind. If i moonfire you, i'm caster and you are target. If i logout caster is null and you are still the target.

eventInfo also provides 2 targets. GetActor or something, which is the unit causing the proc. E.g. if you have a proc aura which procs on damage taken and i moonfire you again, im the actor, may vary per proc. The other one was ActionTarget, which varies per proc.

rektbyfaith
Administrator
0
04-14-2025, 02:30 PM
#10
Archived author: syntaxhell • Posted: 2025-04-14T14:30:46.862000+00:00
Original source

Thank you for the input
rektbyfaith
04-14-2025, 02:30 PM #10

Archived author: syntaxhell • Posted: 2025-04-14T14:30:46.862000+00:00
Original source

Thank you for the input

Pages (2): 1 2 Next
Recently Browsing
 1 Guest(s)
Recently Browsing
 1 Guest(s)