Marking Variable Name Issues (Attempt #2)

[Maelwys]

Continued from here...

Target /Marking issues

Firstly, marking variable names are inconsistent.

Example: Using /mk ignore1 <t> will mark a target to ignore. But to retarget that marked target, you need to use /target <stop1> (Note the different variable names!) However to do the same to mark a target to attack, it's /mk attack1 <t> and /target <attack1> (Note the identical variable names!)

--------------------------------------------------

Also when using macros to mark targets to attack, I've noticed a very strange behaviour:

You can mark targets sequentially from Attack1 through to Attack5 by using the command /mk attack <t>. (The first target you use this command on will get marked as Attack1, the next target gets marked as Attack2, etc etc.) So far this is fine, but it then gets a bit odd depending on whether you use the command out in a world zone or inside a mission instance...

If you mark five foes in this way out in a world zone and one of those five marked targets dies, the mark used on that target gets freed up for you to use again - e.g. if you mark five foes and then the foe marked Attack2 dies, then using the command a sixth time will mark the next foe as Attack2. However if you mark five foes inside an instanced mission and one of them dies, the mark used on that target will NOT get freed up - so using the command a sixth time will no longer mark anything.

(This behaviour caught me out the first time I tried tanking inside a mission instance... it meant I could only mark the first five targets we encountered before the macro stopped working entirely. It's REALLY odd...)

We appreciate you taking the time to report this error to us. However, there are still some details that we need to collect from you before we are able to investigate this properly. Please use the bug reporting template found Here, and make another post. Thank you!

Regards,
Melemyth

Fine then. As Requested:

Time: Today. That is, the 25th day of Halimath, in year 10 of the Fourth Age of Middle-Earth. (Seriously though, this has been happening since the release of ARR, because it is an inconsistency in the naming convention of marking variables within the ARR software. You could therefore pick any time since release and encounter the same behaviour)

Frequency: As quickly as you can issue a marking or targeting command to the server. So every 0.1 seconds, plus network latency. Or longer... depending on whether the server is feeling particularly laggy today.

World name: This matters not (because it is an issue with internal FFXIV variable names which will be identical across all worlds). Though for the record, as my profile to the left clearly states, my main character resides on Ragnarok.

Character name: Womble O'flaherty. (Once again, stated to the left...)

NPC name: He wouldn't tell me, but he looks a bit like a "Susan". (This really doesn't matter. See above)

Monster name: I'm going to go with "Cyril, the Legendary Chicken of Antioch". (This STILL really doesn't matter. See above)

Class/Level: Geography, First floor. (This DOES NOT MATTER. And is getting very silly, so I shall reciprocate.)

Party or solo: Yes. (I like parties. Do they have cake?)

In-game time: Linear. Usually. Sometimes appears to halt completely or even flow backwards, especially whenever a quest requires you to kill a highly camped mob. (If SE ever bring out a "Time Mage" job class, their first ability should be to allow the user to occasionally actually get a claim on one of the five enemies in the entire game that drops 'Fleece')

Area and coordinates: Hang on, I know this one: 20 meters squared, X and Y? (Sorry, I got a D in Maths...)

Steps:
1. Manually target a mob
2. type /mk ignore1 <t>
3. Watch the mob get marked.
4. Untarget the mob
5. Type /target <ignore1>
6. Watch the mob NOT get targeted.
7. Type /target <stop1>
8. Watch the mob get targeted.
9. Realise that I already gave all this information in the last post, which was subsequently marked "Not enough Information".

<*Add more steps if necessary>
<Claire Richards, Faye Tozer, Lisa Scott-Lee, Ian "H" Watkins, Lee Latchford-Evans> (Believe me, it's necessary: They've been plaguing the planet for years, PLEASE take them away!!)

Connection Specs
- Type of internet connection/provider: RJ45 (AKA the IEC 60603-7 8P8C modular connector) / CableWorld. (This DOES NOT MATTER)
- Modem maker/model number: BT / I quite like Cindy Crawford, but unfortunately she wouldn't give me her number.

PC Specs
-=-=-=-=- System Information -=-=-=-=-
If you really want me to, I could give you a version stamp of all the 636 GB worth of data files currently on my computer's hard drives. However since THIS IS COMPLETELY IRRELEVANT to the naming convention of variables within FFXIV's software, I doubt it'd make for particularly fascinating reading. All you need to know is that I'm running the current 32-bit PC ARR English-Language client.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Laptop Model Name: I do have a laptop somewhere. I think it's an IBM 486. I don't use it for gaming, but thanks for asking.
Laptop Model Number: Five.

Gamepad Manufacturer: Gravis.
Gamepad Model Name: Gamepad Pro. I think. I don't use this for gaming either since it broke about 8 years ago. I tried gluing it back together but that just made it worse... (I'm actually using a PS3-style gamepad with FFXIV, but since the default crossbar setup was useless I decided to just disable gamepad support and make the device emulate a variety of keyboard and mouse commands instead. As far as the game is concerned, there's no joypad)
Gamepad Part Number: Five. No wait, that was the laptop. Erm... Four.

Browser Information
- Name and version of the browser currently in-use: Chrome (various). IE 6,7,8, and 9. Mozilla Firefox (various). Netscape Navigator 4 (yes really). All "currently in-use" in various Virtual Machine instances. I should probably mention that I'm currently in work at the moment not at home, and part of the work we do in here is related to compliance testing for various platforms. (When I'm at home I use 32-bit Chrome mainly, but once again this DOES NOT MATTER!)
- Internet Explorer Version: I'm going to go with "Five" again here, just because.


--------------------------------------------------

Look, the underlying issue here is perfectly simple:

The variable names used within the FFXIV ARR client software to denote MARKING and then subsequently TARGETING those marked targets are inconsistent.

The names used to mark a mob are "attack1" "attack2" "attack3" "attack4" "attack5" "ignore1" "ignore2" "bind1" and "bind2". (plus those cross/triangle/circle/square icons that nobody ever uses).
The names used to target those marked targets are "attack1" "attack2" "attack3" "attack4" "attack5" "stop1" "stop2" "bind1" and "bind2" (plus Cross/Triangle/Circle/Square, note that they remain largely the same except for a bit of odd behaviour with capital letters).

As the Sesame Street song goes: "One of these things is not like the other ones, one of these things just doesn't belong..."

All of this I mentioned in my previous post.

(The second Issue I previously reported about the weird behaviour in Marking targets with /mk attack <t> does not really concern me, because it appears that the "/mk attack" command is not technically supported by the ARR client, however /mk ignore1 and /mk ignore2 ARE and therefore the variables used for them SHOULD BE CONSISTENT. I was not able to find any mention of how to retarget enemies marked with ignore1 and ignore2 and managed to stumble across <stop1> and <stop2> myself eventually whilst trying every conceivable command I could think of)

PLEASE FIX THIS, or at least draw attention to the difference in variable naming conventions for marking and then retargeting enemies. I am not the only one having this issue, and it has been happening for months.

Apologies if the mildly grating humour in this post offends, I tried valiantly not to go too overboard (believe me, this is the edited version!!) but I work in IT support and have grown to detest being asked for obviously unnecessary information. I realise that completed bug submission templates are probably required for all bug submissions because of an edict handed down from above, but in this case all it does is ask me to provide completely redundant information which engages my sarcasm mode.

However, the fact that the original message thread was locked and I was made unable to add any of the requested additional information to it, instead being instructed to open a brand new thread for the same bug?!? That strikes me as completely ridiculous. This experience has made me loathe to report any other bugs in the future.