Razmataz

Yeah, sorry, you'd need to make a completely new smart_script action then. Potentially where the x, y and z parameters in that smart_script do ± the xyz coordinates it is at, so that you have 0, 0, -0.48. I can't think of any other way. Honestly the idea that you have is just not feasible without a large scale core edit. TrinityCore hasn't got any documentation on http://www.wowhead.com/item=85500/anglers-fishing-raft which is the closest thing I can find - preventing something from accessing land. It's a vehicle sort of thing because you're able to fish while on it (afaik). Don't know.

I don't know how much use it is but Blizzard did do a Level Design Panel that showcases the logic behind some things, including that textures are very important in dictating what is and what isn't walkable on. Give it a watch if you have time - it's just under an hour. If you're short on time, 7:25 is roughly where you want to watch from. Right screen.

Based on https://github.com/TrinityCore/TrinityCore/issues/18254 it looks like the functionality is not in yet. SMART_ACTION_SET_HOME_POS is probably to do with creature AI, as the below snippet suggests. if (Unit* unit = GetCharmerOrOwner()) return victim->IsWithinDist(unit, dist); else return victim->IsInDist(&m_homePosition, dist); You might actually have to endeavour in making a smart_script action that executes creature->Relocate(x, y, z, o); PreparedStatement* stmt = WorldDatabase.GetPreparedStatement(WORLD_UPD_CREATURE_POSITION); stmt->setFloat(0, x); stmt->setFloat(1, y); stmt->setFloat(2, z); stmt->setFloat(3, o); stmt->setUInt64(4, lowguid); WorldDatabase.Execute(stmt); creature->SendTeleportPacket(creature->GetPosition()); You might or might not get the correct x, y and z coordinates from repurposing the SET_HOME_POS code. That's something you'd have to figure out I'm afraid! If you set its teleport to the exact coordinates it has when you exit, it might be fine. The only other way is to make the smart_script explicit for your boat to always set it to z = -0.48 and the x and y are other arguments entirely. ...CONDITION_IN_WATER? Maybe? Force eject them? Another answer is creating a new inhabittype that restricts the boat from exiting water. I haven't a clue how to do this.

I don't mean to speak on behalf of the rest of the community but when these big projects are posted by someone with a vision, it is only fair for you to show us that you've already put work into it. By saying that you're looking for someone to remove objects in Gilneas, create quests and creatures, code in a VIP account system, create a web site with shops, forums and an account page, you're saying you have no real skills to help with the project, just that vision. Making quests and NPCs isn't hard. It just requires a lot of reading. You have various server options but because I work with TrinityCore, you simply need to look at this to make quests and this to make creatures. Having all of this to begin with would show you've put in at least 50 man hours. You should always come with more than just words and pictures to show that you're serious about this. Otherwise you're wasting both your time and the people who you recruit. Many projects don't see through to completion.

You can use the Conditions table. You use the condition CONDITION_QUEST_NONE in conjunction with a CONDITION_SOURCE_TYPE_SMART_EVENT that details the smart_script you're dealing with. As long as the person meets the condition that they have not gotten/done the quest, they cannot execute the smart_script you define. Another thing - I just realised and it is probably what was causing the initial stuff to not work - you didn't set the Gameobject to use SmartAI. You need to set 'AIName' to 'SmartGameObjectAI'.

Oh, so you did. My bad. The issue might lie in the target type, then. Maybe 7 (invoker) doesn't work. I can't say at this point.

You need to create a new NPC, let's call it "Interact with Gobname" and let's give it an entry $ID. In the Quest_template, requirednpcorgo needs to be $ID and RequiredNpcOrGoCount needs to be 1. In Smart_script, Param1 needs to be $ID. Right now your smart_script is probably triggering but you've not ordered it to credit the player with any monster kills, nor does your quest track those monster kills.

You can use a smart_script. Use script SMART_ACTION_CALL_KILLEDMONSTER to award credit for a quest_objective that requires a certain NPC to be killed Either works. Yes. Probably in CharacterHandler.cpp WorldSession::HandleCharCreateOpcode, an insert into Character_QuestStatus (I think you'll need to add it to CharacterDatabase.cpp and .h as well) Yeah, it's a region of space made by some shape of some size around some centre coordinates that, upon entering, can execute a script through areatrigger_script or even Smart_Scripts (SMART_SCRIPT_TYPE_AREATRIGGER is source_type 2). With one of the latest TrinityCore revisions you seem to be able to make AreaTriggers with Areatrigger_template. I've not dabbled, so I dunno how it might end up. You might also be lucky enough to find one of Blizzard's areatriggers serves your purposes. Quest_Template PortraitGiverText and Name is all I can find. They do not appear to be documented.

A brief ponder and I've concluded adding quests on character creation can be done by the following: - Execute a query in the process that creates a new character, inserting into character_queststatus the relevant details - Character enters the world in an AreaTrigger that has a script to add the quest via a smart_script I know the functionality involved in the quest completing upon the item being acquired. It was done very often in Cataclysm with the portraits showing up, but I'm too lazy to go find out how that's done. However, for actually meeting the quest criteria, you could attach a smart_script to a chest object despawning - something it only does when its loot table has been emptied out. That smart_script could complete the criteria for the player who looted it and therefore the item itself would not be at all related to the quest but nonetheless be required to loot.

That's normal. That became normal behaviour a long time ago. The server loads items from the dbcs (or db2s, I think? Can't remember which is used in Cata) called Item and Item-Sparse. It then loads additional ones that are done entirely through the database. If you want to edit them you might be able to get away with extracting the data from item-sparse and item and combining them to fill out the item_template table. You can find details on those two DB files in WoWDev, as well as the format of the Item_Template on TrinityCore's Wiki. [Edit] I did a quick look at https://gitlab.com/trinitycore/TrinityCore_434/blob/4.3.4/src/server/worldserver/worldserver.conf.dist and you will want to make sure your worldserver.conf has DBC.EnforceItemAttributes disabled (set to 0). Then you would be able to proceed with replacing the data from DBCs/DB2s with data in Item_Template.

It's all good. Best of luck with your project

@lululalaland You use the WDBXEditor to open the DB2 and then you open the corresponding ADB named file but from your Blizzard/Cache/ADB/EnUS/ folder. Doing this allows you to import directly from a SQL table into the ADB - I use this because otherwise I have to send 450,000 hotfix entries and it takes too long. Alternatively you use the hotfix_data table from your up to date server. You fill in data in the hotfixes table for the DB2 you want to add content to, then add a hotfix_data entry with the corresponding hash (https://raw.githubusercontent.com/TrinityCore/WowPacketParser/master/WowPacketParser/Enums/DB2Hash.cs) and ID from the table. I.e, Spell_Effect 0 0 1 0 0 0 0 0 0 0 0 999000 0 6 260 0 0 0 0 0 0 21 0 0 0 0 1 0 999000 0 0 0 Hotfix_Data 4030871717 999000 0 0

This is why I've been using ADBS instead of DB2s. I can overwrite Blizzard values with pseudo hotfixes or create new ones without a hitch (with some limitations). You could alternatively find the duplicates and dispose of them in the DB2 before saving it. Then editing it should be easy.

@lululalaland As informed by a friend: Go to the WDB5 Parser, select SpellXSpellVisual, parse it and save it under any build number. It will give an error (unable to save definitions) but don't worry about that. Then open the .db2 with the WDBX Editor like normal and select the duplicated entry. The parser will work and not work simultaneously. You should then export it to SQL for easy editing in an actual database program. @MR.Farrarie Do you mind PMing me an example of a spell you've made - all the DB2s it runs through?

SpellVisualMissile.db2 seems to hook into SpellVisual directly, at least on 7.1.0 22996. Here's what I figured: Using spell 206356 (Greed) and Effectname spells7FX_Rogue_Greed_Missile.mdx, I traced the following route through the files. You can see the connectors from one file to the next by the number that I have bolded and underlined. spellxspellvisual 206356 1 54114 0 0 0 0 0 0 96393 spellvisual 0 0 65637 0 0 0 0 576 65615 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7399 255 34 54114 0 0 0 spellvisualmissile 0 300 82436 0 0 0 0 0 0 7399 26314 0 0 750 3720 50 34 8520 0 0 effectname 26314 spells7FX_Rogue_Greed_Missile.mdx 0 0 0.5 0.25 0.75 1 0 0 0 0 0 0 Hope that helps.

Hello there! It is possible to pass data from itemdisplayinfo to item_template to automatically generate items, but one big issue you'll come across is that it is often hard to distinguish what displayid is used for what inventorytype. Your starting point is to work with leftmodel, leftmodeltexture, rightmodel and rightmodeltexture. Create a program or a query that scans these columns for common terms to describe an item. An axe is always known as axe_1h or axe_2h. A cloak is always known as cape_ and doesn't have leftmodel or rightmodel entries. Helmets are almost always prefixed with helm_, but you'd want to check both model and texture. Shoulderpads are more random. Then, you want to scan uppertorso and lowertorso. If both of them have a string then you know it's going to work in the chest slot. But chests also have textures on upperarm, lowerarm, upperleg and lowerleg. Not only that, you'd need to inspect the geoset properties to determine if it's a robe instead of a chest item. In some cases, you'll be lucky - belts for example usually have the word 'belt' in them. Other cases, not so. Repeat for all the other inventorytypes too. You want to keep this in mind: LeftModel/RightModel: InventoryTypes 1, 3, 13, 14, 15, 16, 17, 21, 22, 23, 25 UpperArm: InventoryTypes 4 5 20 LowerArm: InventoryTypes 4 5 9 10 20 Hands: InventoryTypes 9 10 UpperTorso: InventoryTypes 4 5 19 20 LowerTorso: InventoryTypes 4 5 6 19 20 UpperLeg: InventoryTypes 4 5 6 7 20 LowerLeg: InventoryTypes 4 5 7 8 20 Foot: InventoryTypes 7 8 I gave up trying to determine what displayid was meant for what slot and opted to make every item possible using the displayids. Also, if you're using WoD or beyond, you'll be dealing with FileData entries instead of the strings for files. You'll need to cross-reference ItemDisplayInfo with TextureFileData and FileData in order to resolve the values into strings. Everything else continues on from there.