Jump to content
TrinityCore

nubqt

Plebs
  • Posts

    14
  • Joined

  • Last visited

  • Days Won

    1

nubqt last won the day on November 25 2017

nubqt had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

nubqt's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. Tickets reporting incidents in a granular manner are being closed in favor of keeping tickets that describe large, vague, and obscure issues. For instance, I reported that Skittering Spiderlings in The Hinterlands are attackable rather than lootable only to get that ticket closed in favor of keeping a ticket titled Cataclysm Zones - Quests + Phasing. So now, rather than tackling the spiderling issue, which is an easy fix, we can't apply the solution until the Cataclysm ticket is solved entirely. That is bad policy. The process of Incident Management has been developed, polished, and heavily tested for more than thirty years and separates incidents from problems. The way that @DoctorKraft managed this ticket is the right way to do so: a User-Acceptance Tester (UAT) reported an issue and @DoctorKraft then created a separate ticket that explains the technical problems causing that incident for developers to solve. It allows specialization by having testers reporting issues while developers focus on building code that testers can then test. Furthermore, putting everything into a single huge ticket describing large, vague, and obscure issues goes against the paradigm of divide-and-conquer in software development. That paradigm establishes that the best way to solve a big issue (such as 'Westfall is not scripted') is by breaking the problem into many small problems (such as Quests 'Hot On the Trail: The Riverpaw Clan' and 'Hot On the Trail: Murlocs' are available before completing quest 'Murder Was They Case That They Gave Me' and Two-Shoed Lou is not phased in after getting quest Meet Two-Shoed Lou). That paradigm allows developers and scripters to fix tiny problems that incrementally solve the big issue, rather than having to wait for the entire big issue to be solved in order to apply the fix. Moreover, this policy discourages UAT testers from testing the core. For example, if I wouldn't have tested the Hero's Call Board in Ironforge (which is considered a Cataclysm zone) we wouldn't have discovered that there is a feature missing in the core. Same thing when I tested Rune of Fire in Dun Morough (which is also considered a Cataclysm zone) which allowed us to find that the spell Burn Constriction Totem does not support the `conditions`.`SourceTypeOrReferenceId` for CONDITION_SOURCE_TYPE_SPELL which is also a core issue. But what incentives do I have now to continue to do UAT if the time and effort I spend in such testing is worthless since my reports will get closed on behalf of tickets that describe large, vague, and obscure issues? I suspect this is one of the factors why Ohloh reports a -31% decline in contributors to this project in the last twelve months. If you discourage contributors like UAT testers to participate, what do you expect? I don't think that's what we want as a community. Fortunately, the incident management process in software development has been well documented and developed in the past thirty years. There's no need to reinvent the wheel. But if we want to make this project flourish and more successful that what it already is, we should start adopting best practices and encouraging people--particularly UAT testers--to contribute rather than disincentivize them.
  2. Doesn't 33 (SMART_ACTION_CALL_KILLEDMONSTER) assume that the player has already killed the NPC? In this quest I'm working on, the Player doesn't actually need to kill an NPC; it's just that the quest objective is coded as an NPC. Just in case, the quest is Proving Pit and the `quest_objectives`.`ObjectID` is a Darkspear Jailor. But you don't have to kill it. When you click the gossip menu that objective should be marked as completed. Thanks for the help and sorry for the questions; I'm just trying to clear all the confusion I have.
  3. Could you please explain how to do something like that? I'm working on a different quest now where I have to give a kill credit after selecting a particular gossip. The objective is a coded as an NPC/creature rather than a spell.
  4. Could not find documentation for world -> creature_default_trainer nor for world -> trainer on the wiki. Anybody knows where this is documented?
  5. Thanks for the reply but where is this defined?
  6. Based on this issue https://github.com/TrinityCore/TrinityCore/issues/16224 and my suggestion to mark it as Critical, a username at github by the name of trokli suggested that I move this question to this forum. I would like to know how this project defines what a 'Critical,' 'High,' 'Medium,' 'Low', and 'Very Low' issue is. I have not been able to find that definition on this forum, on github, nor on the wiki. Such definition is what is typically known as Checklist Incident Priority matrix, helps developers focus their efforts effectively, and makes categorization systematic rather than subjective. Does anyone know where this was defined by the project owners or by the community? Or any suggestions on how to define these categories?
  7. I'm using smart_scripts to fix https://github.com/TrinityCore/TrinityCore/issues/20836 But at some point in that quest, two things might happen after the Player gossips with an NPC: 1. A 50% chance that the NPC becomes hostile 2. if-and-only-if that does not happen, a quest objective must be completed I looked at the documentation and it says that smart_scripts can handle 'chances' but I can't figure out how to make something else happen if that chance does NOT occur. Any ideas?
  8. I'm using smart_scripts to fix https://github.com/TrinityCore/TrinityCore/issues/20836 But at some point in that quest, the Player completes a quest objective after gossiping with an NPC. I got the whole thing working except for the objective completion. The documentation says that SMART_EVENT_QUEST_OBJ_COMPLETION is not yet implemented but that documentation might be outdated. Any suggestions or ideas?
  9. @CDawg: first fix: https://github.com/TrinityCore/TrinityCore/issues/18519
  10. @CDawg: installing the databases!!! Didn't need a MySQL client. The CLI was enough. I got confused because the instructions say to 'import' the content from github but in reality you just need to run the SQL commands to create the user and the databases. Thanks for the help!!!
  11. Thanks, I'm following the Linux instructions and they are easy to translate to Mac. I'm already extracting the DBC, vmaps, and so on. Hopefully I can get this running and update the wiki after.
  12. I'm confused. Does that mean I have to install a MySQL client to work on Trinity? The instructions don't mention that.
  13. I'm on a Mac and followed the instructions on the wiki. What client would I have?
  14. The wiki says: Import the content of https://github.com/TrinityCore/TrinityCore/blob/master/sql/create/create_mysql.sql (master branch) or https://github.com/TrinityCore/TrinityCore/blob/3.3.5/sql/create/create_mysql.sql (3.3.5a branch) with your favorite mysql client with root account before starting core. But it doesn't say how to do that. Can someone please provide the instructions on how to do that for the master branch?
×
×
  • Create New...