Ranger Archive
Thread: Harvest Bug with 60% cap
Page 4 of 4
Suenr
Sat Sep 06, 2003 12:10 am
#40
Just to answer the question on what is solo. Holocron (Raph Koster, Creative Director) said this about soloing.
"Yes, there is a missing fact here... nobody is supposed to be able to kill a red solo. And your pet doesn't count--if it's you and a pet, that's "solo.""
Ikochan
Sat Sep 06, 2003 12:47 am
#41
Please note that when Raph used the word "solo", it was in regards to whether or not someone can defeat a red con. The issue we are currently having is the definition of the word "grouped" (they sound like they would relate to each other and be mutually exclusive, but that might not be the case if two different variables are used to define these terms). It's important to note how the word is actually being used within the SWG application.
I have observed that the application does not see me "grouped" when I attack a enemy with my pet and my pet is not technically "grouped" with me (group type 1 as per my definitions above). I believe other players have made this same observation. My yield is equivalent to me attacking the enemy on my own.
This observation leads me to two conclusions:
1) There is a work-around for those "solo-ing with pets", so please use it in the meantime as the devs clear the air about this issue for us. Perhaps this is group type 1.5: a player with a pet that is not in a group with the player. Although the player does not get the benefit of knowing their pets current status (HAM and distance), the player can still use the pet to attack enemies and harvest/loot them even if we took no part in their demise.
2) Programmatically, the killing of an enemy causes some sort of flag to be set based on the status of the enemy's killers. If the killers are "grouped" (definition of "grouped": the target cannot be invited to a group because the target's "isGrouped?" flag is set to positive), then drop only 60%. To me, this means the formula is really simplistic. We would need to use another flag: "isPlayerGrouped?" which would indicate if someone is grouped with another PC or not, and check for that value. We still need the "isGrouped?" flag to check for allowing or disallowing invites. Now, I don't know if this is how it works exactly, but this is how my brain perceives it working.
It bothers me a little that the work-around exists and would prefer to see that eliminated. I prefer for it to one way (if in group type 2, or in group type 1.5, drop 60%) over the other (if in group type 2, drop 100%), since the player is being assisted. But that's just personal preference and can understand the arguments for the latter.
I have observed that the application does not see me "grouped" when I attack a enemy with my pet and my pet is not technically "grouped" with me (group type 1 as per my definitions above). I believe other players have made this same observation. My yield is equivalent to me attacking the enemy on my own.
This observation leads me to two conclusions:
1) There is a work-around for those "solo-ing with pets", so please use it in the meantime as the devs clear the air about this issue for us. Perhaps this is group type 1.5: a player with a pet that is not in a group with the player. Although the player does not get the benefit of knowing their pets current status (HAM and distance), the player can still use the pet to attack enemies and harvest/loot them even if we took no part in their demise.
2) Programmatically, the killing of an enemy causes some sort of flag to be set based on the status of the enemy's killers. If the killers are "grouped" (definition of "grouped": the target cannot be invited to a group because the target's "isGrouped?" flag is set to positive), then drop only 60%. To me, this means the formula is really simplistic. We would need to use another flag: "isPlayerGrouped?" which would indicate if someone is grouped with another PC or not, and check for that value. We still need the "isGrouped?" flag to check for allowing or disallowing invites. Now, I don't know if this is how it works exactly, but this is how my brain perceives it working.
It bothers me a little that the work-around exists and would prefer to see that eliminated. I prefer for it to one way (if in group type 2, or in group type 1.5, drop 60%) over the other (if in group type 2, drop 100%), since the player is being assisted. But that's just personal preference and can understand the arguments for the latter.
Page 4 of 4