Should I post this to TC?

I have made some TC code changes for an armor item I’m creating that starts a quest by simply owning it.

There seemed to be no easy way to do this, so I added a new field to quest_template table called ‘RequiredStartItemID1’. If you set this field to a non-zero value, then you must have an item with that ID in order to be able to see or start the quest.

It’s a very straightforward change in player.cpp, questdef.cpp and objectmgr.cpp. It also changes no existing behavior and may be generally useful to other people, but there’s currently not a Blizz-like need for it.

I can post the diffs to the tracker if Trinity thinks it would be useful to have.

Ultimately custom code and possibly even client modifications are the future. I’d say post it in the custom code section of the forums.

How do you do it? a loop? a new container map based on item id?

Try posting it in the custom code section.

No loops. I just added a new “RequiredStartItemID” field on the quest_template table which is loaded into a new Quest instvar. Then I added a new SatisfyQuestStartItemID method in player.cpp which is called by both the CanSeeStartQuest and CanTakeQuest methods.

It was really quite trivial but is going to be very useful for what I am doing. Beyond the table alteration, it’s a fairly innocuous change for the current TC core.

I’ll grab the diffs and post them in the custom code section.

You should have added a condition to the conditions system, that would be vastly more usable.

– Brian

The wiki documentation on how to use the conditions system with quests was incredibly sparse and I didn’t feel like spending 10x the effort investigating it to see if they even worked together when a 30-minute solution was staring me straight in the face.

Understandable since you only needed the solution for yourself. I only pointed it out because a lot of people wonder why things like this don’t get pushed to master, and that is why – a more generic solution is possible using an existing system.

– Brian

I decided about three months ago to make this a hobby and get a cool private server running for my friends. The TC core is riddled with bugs, the gameworld has LOTS of QA problems that are individually easy to fix but overwhelming in number, and a chunk of the developer community is more intent on refactoring code (EAI, etc) than fixing actual quality problems.

I work full-time and have a personal to-do list for this project that is at least 6 months long. I offer to post this non-Blizzlike change specifically because TC developers complain (rightly) that not enough people are willing to push their changes to the main repo. If you want to contribute a solution to this particular problem that uses the conditions table, then go for it.

– Ray

The TC core is riddled with bugs, the gameworld has LOTS of QA problems that are individually easy to fix but overwhelming in number, and a chunk of the developer community is more intent on refactoring code (EAI, etc) than fixing actual quality problems.

Why not help us fixing those bugs instead of creating new features?

I have been? I have split my time about 50/50 doing a QA sweep through the zones and doing fun, non-Blizzlike stuff that motivates me. From that alone, I have found dozens of mobs missing pathing, stealth auras or pets, and I’ve submitted sql changes for those. But, in a complex program like this, there are a lot of server components to get familiarized with and the fun stuff is what spurs me into understanding more of them better. For example, I just added about 400 non-combat pets to my server using the Wolvar Pup mechanic. Because of that non-Blizzlike feature, I now have a greater understanding of how things like the npc_click_spells table works as well as the SAI/EAI. That will pay off with Blizz-llke improvements when I finally get around to improving the mob AI.

This latest feature is going to allow players to learn crafting spells from items they find in the world (using a quest turn-in mechanic to their profession trainer), which forces me to have a better understanding of how quests are implemented along with all of the obvious loot drop tables.

I have some changes to the RandomMovementGenerator that allow for large-scale wander radius (which my testers love), but I’m not considering releasing it until the MMaps branch is merged so that I can make sure it still works with that effort.