feature request - run init again if I change my subjob
I put some stuff in init that depends on my subjob, but if I set change my main job first and then my subjob, it doesn't run correctly and I have to manually reload it.
feature request - run init again if I change my subjob
I put some stuff in init that depends on my subjob, but if I set change my main job first and then my subjob, it doesn't run correctly and I have to manually reload it.
Client will not have job and subjob updated until your job change goes through, so if I were to implement this you'd end up having to reload anyway as your init section would be parsed using the prior subjob. XML is loaded at the time you request the change, client(and thus, the variables) is not updated until server confirms the change has taken place.
Regardless of whether I implement a reload on subjob change, you're going to need to change subjob first to receive the intended effects. I will consider possible solutions, but entertain the possibility that the work required to implement it may be much greater than you typing a single command or shifting the order of your job change.
Client will not have job and subjob updated until your job change goes through, so if I were to implement this you'd end up having to reload anyway as your init section would be parsed using the prior subjob. XML is loaded at the time you request the change, client(and thus, the variables) is not updated until server confirms the change has taken place.
Regardless of whether I implement a reload on subjob change, you're going to need to change subjob first to receive the intended effects. I will consider possible solutions, but entertain the possibility that the work required to implement it may be much greater than you typing a single command or shifting the order of your job change.
As of 1.48, Ashitacast will redo init when changing subjob. However, at present, it will generally execute faster than your client updates sub and variables won't match. This is something that will likely not be remedied, design accordingly.
One option is to have a command with a delay of 1000 in your init section to trigger /initsubjob, then add an inputcommand for /initsubjob that will do your subjob specific stuff.
As of 1.48, Ashitacast will redo init when changing subjob. However, at present, it will generally execute faster than your client updates sub and variables won't match. This is something that will likely not be remedied, design accordingly.
One option is to have a command with a delay of 1000 in your init section to trigger /initsubjob, then add an inputcommand for /initsubjob that will do your subjob specific stuff.
Something that could be done on the user level, create an addon that monitors for job change packets. If that packet is seen, monitor until the next 'x' packet that follows any job change. There is a group of packets that comes in each time you change jobs so you could monitor for those and manually have the addon re-execute the init part.
Something that could be done on the user level, create an addon that monitors for job change packets. If that packet is seen, monitor until the next 'x' packet that follows any job change. There is a group of packets that comes in each time you change jobs so you could monitor for those and manually have the addon re-execute the init part.
Adjusted ashitacast to track your job and sub via outgoing packets and character change packets. This should solve your problem, but created another: Users who inject their job change packets will not have their job kept up to date.
Thus, if you use a plugin or addon to inject job changes, you will need to adjust your plugin or addon to use the matching command when you inject your packet:
/ac setjob # (index of the new mainjob)
/ac setsub # (index of the new subjob)
Adjusted ashitacast to track your job and sub via outgoing packets and character change packets. This should solve your problem, but created another: Users who inject their job change packets will not have their job kept up to date.
Thus, if you use a plugin or addon to inject job changes, you will need to adjust your plugin or addon to use the matching command when you inject your packet:
/ac setjob # (index of the new mainjob)
/ac setsub # (index of the new subjob)
feature request - run init again if I change my subjob
I put some stuff in init that depends on my subjob, but if I set change my main job first and then my subjob, it doesn't run correctly and I have to manually reload it.
Client will not have job and subjob updated until your job change goes through, so if I were to implement this you'd end up having to reload anyway as your init section would be parsed using the prior subjob. XML is loaded at the time you request the change, client(and thus, the variables) is not updated until server confirms the change has taken place.
Regardless of whether I implement a reload on subjob change, you're going to need to change subjob first to receive the intended effects. I will consider possible solutions, but entertain the possibility that the work required to implement it may be much greater than you typing a single command or shifting the order of your job change.
As of 1.48, Ashitacast will redo init when changing subjob. However, at present, it will generally execute faster than your client updates sub and variables won't match. This is something that will likely not be remedied, design accordingly.
One option is to have a command with a delay of 1000 in your init section to trigger /initsubjob, then add an inputcommand for /initsubjob that will do your subjob specific stuff.
Something that could be done on the user level, create an addon that monitors for job change packets. If that packet is seen, monitor until the next 'x' packet that follows any job change. There is a group of packets that comes in each time you change jobs so you could monitor for those and manually have the addon re-execute the init part.
Adjusted ashitacast to track your job and sub via outgoing packets and character change packets. This should solve your problem, but created another: Users who inject their job change packets will not have their job kept up to date.
Thus, if you use a plugin or addon to inject job changes, you will need to adjust your plugin or addon to use the matching command when you inject your packet:
/ac setjob # (index of the new mainjob)
/ac setsub # (index of the new subjob)