Has there been any update on fixing the "XXX is too far away." and causing us to loose TP? This was addressed and responded too a while back and not implemented. Can we get some kind of status update?
Printable View
Has there been any update on fixing the "XXX is too far away." and causing us to loose TP? This was addressed and responded too a while back and not implemented. Can we get some kind of status update?
They announced the TP loss fix much longer ago, though. I believe they mentioned they were gonna look into it with the next update, although for the life of me I can't remember where I've read that now. Maybe I was just hallucinating, I'm not sure. Both of these things seem like really easy fixes, though.
Everything seems like an easy fix when you don't actually have access to the code or the duty to modify it.
Everything seems magical and arcane when you have no idea how computers work.
Changing code is hard, bro.
I thought we were being quiet about this because in all likelihood SE would fuck this up and have the adjustment affect monsters too then refuse to fix the new problem?
Kind of like how curelocking was "fixed" to be worse.
That's not a fallacy. Coding is easy and quick. For programmers. And one can reasonably assume that the development team are just that, programmers. This is an easy fix. Whenever someone tries to use a WS, the following happens:
1. Check if engaged
2. Check if mob can be seen
3. Check if enough TP
4. TP is consumed
5. Check if distance is under a certain limit
Aside from the fact that fixing this would be as easy as including the last check into the group of previous checks, it never made any shred of sense to have it like this in the first place. I have no idea who first came up with it. Anyone know if this was always that way or only after ranged attacks (or ranged WS) were introduced? That could explain it, but aside from that I have no idea why.
They obviously already do a check that determines whether or not you are close enough to WS the monster. They could change the code to refuse to WS instead of giving an "out of range" message, or not remove TP upon "out of range" WSing.
Anyone remember how Blood Pacts used to work?
SE said that'd look into it. Is losing your TP so bad that it should trump over other adjustments already planned out? Honestly, I'd rather see storage access from everywhere before they get around to this.
I haven't been on SMN in a while but unless they adjusted it, that also happens if the mob dies before your avatar gets to complete their BP, making you wait for recast. My apologies if this has been fixed. And I think I'd rather see this fixed before "XXX is to far away"; but still pulling for storage access before both of those. At any rate, I believe SE will get around to it once they finish with the other stuff that was planned before moving onto user submitted adjustments...but that's just my line of reasoning.
If it gets amnesia'd (Pil) before the BP goes off, your timer is also not reset.
Also if you use Assault while your avatar is taking its time drunkenly staggering to your position (a.k.a. pathing poorly), you lose that timer as well.
I think basic quality of life or job performance issues like TP or job timer loss have to take precedence over pretty much anything. To put it simply, they need to fix what's broken before they start making new additions.
It's easy, really easy for someone who's job it is to do this stuff every day. It's not a matter of difficulty as to why it's not been changed it's a matter of the bossman giving the green light to actually let someone do it.Quote:
He's not sticking up for SE... it's a common fallacy that coding is easy and quick, and anyone can do it better then the guys actually doing it.
There's a Dutch saying: "The best helmsmen are on shore." (De beste stuurlui staan aan wal.)
Those of us with training and experience in the field can tell the difference between "Okay, code isn't magic. They can't just change this at will" type code and "Why can't they just go in and change a 1 to a 0? This is stupid" type code. Both exist. They're not something we need to see SE's code to figure out.
Thought they said they weren't going to change this simply because if they change it for players, they'd have to change it for mobs too
That was a player concern, a pretty irrelevant one if I may say so myself. SE replied they're currently looking into ways to fix it. Although seeing how "currently" was almost nine months ago, one can only wonder whether or not they've determined it wasn't possible and have given up on it. Unless that's the case, they're still working on it.
I heard they were updating Rajas/Tamas/Sattva rings too...
...ten months ago. Even though I suspect this would not be a very difficult fix for competent programmers, I think that the Rajas/Tamas/Sattva thing would practically be just changing constants in their code. If they can't even do that . . . well, at least your menus look different than they did before.
I don't know what your 'training and experience' might be, but you just described the difference between messing with the inner workings of a complex interlocking piece of 10 year old code and adjusting the contents of a resource.
The slightest mistake, and you got a low level NM dealing 20k Magic Mortars or WAR30/WHM1 dealing 99999 dmg Cure I to undead.
It's not going to be the most difficult of exercises, but neither is it very easy, even for experienced developers. It's not like every developer knows every last line of code.. if they were even employed at the time the code was written.
That's... exactly what I meant. And no, I'm sure the majority of the original programmers were fired or reassigned soon after release and the Developers now work almost exclusively with toolkits rather than with the actual codebase.
There are, however, some very simple problems we've asked them to fix that literally amount to adding an extra 0 on a few indexes or changing an 8-bit designation to 16-bit.
Trying to generalize about the hazards of these changes as a whole is simply poor form. In the case of "XXX is too far away"? This is probably a fairly easy fix. Not a 1-liner, but it shouldn't take more than 1 man-hour to change, test, and confirm it's working.
The problem essentially boils down to how many actual programmers FFXI has on staff, as the indications thus far have been fairly poor.
I would guess it's also an issue of sending them spelunking into a deep dark cave of unfamiliar and poorly commented code. Code that was written more with performance in mind rather than for clarity and modular expansion for years to come. That's just a hunch though.
This is the main reason why it's taking longer than expected. The dev. team is currently investigating rule adjustments and looking for a way to allow players to keep their TP when they use a weapon skill on a far away monster.
Don't worry, the dev. team hasn't given up! :)
Not sure what the mess of code looks like in FFXI, but it seems like a simple "if" statement before readying the WS would handle it. We can live with a nerfed blau dolche and maneater if we have to. I'm sure I'm wrong but I wish I wasn't. Appreciate the update though!
P.S. fix cruor buffs on DC as well thanks!
Or track down Azaril, buy the windower source code, make FFXI reject it, then make your own version of the spellcast plugin that only SE can modify.
That wasn't what she said. They're considering enemy TP as well, which I believe they shouldn't. Outrunning mobs is so rarely done (aside from kiting, which is itself very rarely done), that it's hardly an issue. And even if they keep TP, who cares, they won't spam Throat Stab throughout the entire fight.
Not sure how that relates to this thread, as Windower never addressed this issue, and SpellCast wasn't made for it either (and cannot perfectly prevent it anyway, it's impossible to do client-side). Also, Azaril doesn't do Windower anymore. Also, they cannot make FFXI "reject" it. Also, they could do it if they wanted to, which means they don't.
And cruor buffs also don't really belong in here... you're kinda all over the place in this thread.
Even worse than losing BP timer on an attack BP on a mob that dies before it completes is when it happens with a BP that doesn't even target the mob (healing and buffing BPs) that don't go off and reset the damn timer.
Ok SE,
A bulk of the player-base are programmers. Enlist us to fix/update the code and create new content with free service as incentive. I'm tired of depending on the development team to get things done. Put together a confidentiality and non-compete agreement and let's get things done.
Yeah, which makes sense too, but like I said, I wouldn't care much if mobs kept their TP too. How often do you even outrun mobs' TP moves these days?
Pff, I'd do it completely for free. I'd rather pay play a good game than pay to play a buggy game, which is what I currently do. Besides, programming is fun.
^
It's not what you think it means. She's just saying that it appears that the same parent function governs player and monster TP moves (not surprising, it's more efficient that way), so they need to tweak it in such a way that it works for players and not monsters without causing a cascade of issues elsewhere down the inheritance line.
Changes to large legacy systems are not easy. Even a single line of code requires a significant amount of testing, especially on a system that can't have automated tests to cover most test cases (which is what FFXI sounds like).
If you've worked as a QA tester or as a developer on a large scale gaming project then your comments are valid.
If not, go away.
Out of curiosity, which one are you? Making such generic comments sounds like you're trying to justify the existence of testers for random garbage that a monkey with half a brain could figure out. Instead of throwing around blanket statements like that tell me what could possibly go wrong here.
Large legacy systems can still be extremely easy to edit, if they're well designed from ground up. Despite what people may think of SE's poor judgment, I do believe the underlying coding is extremely adaptable and versatile. You can see this clearly from the myriad of effects that you can equip through gear. Being able to buff for the casting time based on spell, type, skill and element depending on several variables (time of day, moonphase, weather) shows you how well designed the game is. Unless they handle literally thousands of seperate cases, hardcoded, (which would be an insult to any programmer to even assume) it means that their game design allows buffs to plug into the chain of evaluation for certain variables at any given point, making adjustments in myriad ways. Additive boni, multiplicative boni, introducing new steps in the evaluation process (like there's at least two seperate DT calculations), none of that would be possible if SE designed a game as crappy as you imagine it to be. And this is nothing compared to how WS damage calculation works and how you can modify it. You can literally influence every step of it, base damage, WSC, pDIF, critical pDIF, direct damage multiplier (also at least two tiers), and that's all before the plenty ways of damage reduction are applied: xDT1, xDT2, SS-like effects, Phalanx-like effects, or just downright weird effects (like Mana Wall).
So I have good reason to believe that SE's code doesn't suck as much as people like to believe. And yes, I've worked on gaming projects myself, networked 3D games as well. Admittedly, not nearly as big as FFXI, but who has? Are you saying only commercial MMOG developers get to discuss this because everyone else has absolutely no idea? It's not about the size of the project as much as it is about the complexity, and on that note I consider myself qualified.
I also disagree with you on the automated testing. They could easily write scripts that feed random variables into a function and test the results, compare it with the old function and single out the "TP lost cases". If those test cases return the same TP that was put in as one of the variables and all other test cases have the same result as the matching test using the old function, they've just simulated an arbitrarily large test and gotten a positive result. If there's deviations, they can single out those cases and analyze where it went wrong, and what exactly went wrong. Testing done, why would you need human testing on for this? The way the variables are put in is the same, only the chain of evaluation changes, so there's nothing a tester could do that a random variable sampling couldn't simulate.
Quote:
Making such generic comments sounds like you're trying to justify the existence of testers for random garbage that a monkey with half a brain could figure out.
Your QA Team must love you.Quote:
There's nothing a tester could do that a random variable sampling couldn't simulate. If there's deviations, they can single out those cases and analyze where it went wrong, and what exactly went wrong. Testing done, why would you need human testing on for this?
I'm not going to argue about this. You actually have some valid points, but the tone of your posts speaks volumes.
Good day sir.
I was part of my own QA team, so yeah, I did. I think you misunderstood me though. I'm not saying testers aren't needed or their jobs are useless, I'm just saying you don't need testers for every change in code, especially not things that can be tested with automated scripts (almost what you said yourself, I just pointed out that this could indeed be tested automatically).
I'm not sure what you expected writing that. Basically telling me to stfu then expecting a nice reply? Not gonna happen. Unless I'm in an exceptionally good mood, which I wasn't (I blame the maintenance interfering with my Voidwatch plans).