Scriptdev2

[abcwarbot]

Is it needed in mangosthree ?

I compiled the code but sql files are empty.

Regards.

[AdmiralMorketh]

Is it needed in mangosthree ?

I compiled the code but sql files are empty.

Regards.

I belive for the time being this is necessary to have scriptdev installed the database files are manual install i currently have a mangos three server running with scriptdev2 installed and the database populated

before the compile the scriptdev library goes into:

src/bindings/scripts

there is also an SQL file that you you should upload manually. check out the tutorial i wrote on installing and building mangos:

https://github.com/Morketh/MaNGOS-Tuts/blob/master/mangos_tut_rpm.md#databse-installation

unfortunately the one here on the wiki needs a bit of tweaking to show up properly.

hope it helps

Regards

~ Admiral Morketh ~

[abcwarbot]

Thank you.

Seems to me i already got this in DB.

Question is: What are the main function of these scripts.?

Cheers.

[Foereaper]

Instance and quest scripts respectively Some other features are handled by SD2 as well, but mostly content related.

[AdmiralMorketh]

Instance and quest scripts respectively Some other features are handled by SD2 as well, but mostly content related.

the one thing i did have a question about concerning Scriptdev2 was the format in which scripts were added in order to script unscripted instances/quests. i found the quest template table and started to dig around there but im fairly certain that its the scriptdev2 library that needs some adjusting to get a few of the "special" quests to work i'll keep diging and see if i can come up with anything but some input on the matter would be helpful

[antz]

Please feel free to ask away, we will attempt to help as much as we can

[AdmiralMorketh]

How does the scriptdev2 library add scripts to the game engine?

more precisely in what format are they written? not really the language but more like the flow of the script as ive asked a few questions and read posts on the matter ive been trying to assemble a reasonable answer on that one and i cant really figure that out.

ive heard things of scriptdev3 coming out and then about Eluna for scripting seems MaNGOS Three is not compatible with either at this point.

example_creature.cpp

this one for example sets up an example creature. im kind of having a hard time understanding HOW this works with the Mangos Engine. although my concept of script and engine might be entirely wrong im trying to step out of the OpenSim Scripting engine to get more detailed with AI programing and MaNGOS seemed like a realy good project to help understand how these things work

thanks again for your patience Antz

~ Admiral Morketh ~

[antz]

I'll try and answer all your points here.....

Scriptdev2 scripts are written in c++, they are linked to things in mangos using the 'scriptname' fields in about 7 tables - which cover quests, npcs or gameobjects.

- using the example, you would add the name of the script to the scriptname of an NPC

SD3 is an advance on SD2 and is basically a better way of doing it .

Eluna will be in Three very soon

[AdmiralMorketh]

when im writing a script is there any methods or functions or variables that NEED to be used? or are these user defined?

also i browsed over to the scripting how-to in the university section of the forums here wasnt really clear in the way of the structures used. is there any detailed technical documentation with code examples that i could use as a learning tool? i dont want to seem like im just asking the same question over and over trying to get a new answer.

thanks again

~ Admiral Morketh ~

[Olion]

It's not exactly what you asked for, but I hope you'll find a use to this

=====================

What are the "scripts" in MaNGOS /TrinityCore?

The script is thought of a part of the whole emulator machine adding special functionality to an ingame object. This object may be a mob, gameobject, map (instance map in particular), spell, areatrigger so on. There are two important characteristics of scripts differentiating it from core mechanics:

1. a script handles usually an object of some type, thus influencing the world "locally" either in space (where the mob copies are spawned) or in time (like scripted spells);
   
2. scripting is simple (at least compared to developing core mechanics), so less experienced developers can modify the world easily and more safely. Safety arises from the fact that the more controls you have at disposal, the higher is your chance to use one incorrectly, breaking the world to a grade.
   

What are basic principles of script functionality?

Usually a script adds more interactivity to the world. Therefore it implements the scheme "happening => reaction" ("happening" is used here to avoid confusion with "event", which has at least four special meanings in MaNGOS). This happening may be a direct user interaction with the world (spellcasting, opening a dialog to a mob, using a door, looting, mailing so on), an indirect or deferred interaction (stepping into some areas – "areatrigger" stuff, coming close to mobs, start of arena/battleground/LFG raid so on), and a world-intrinsic one (weather change, Darkmoon Fairy coming – "game event" stuff, etc.)

The spell scripts may be classified into an other type. Many spells, namely ones having spelleffects 3 (DUMMY) and 77 (SCRIPT_EFFECT), are not implemented generally because not having a pre-defined effect; few others are "server-side", i.e. completely unknown to the game client and therefore to us. The scripting restores their functionality. Combat AI of the mobs belongs to this category too.

What are the script levels available in MaNGOS?

1. The simplest scripts are "database scripts" defined in the DB tables dbscript_on*. These can handle mobs (_creature_death, _creature_movement, _gossip, _quest_end, _quest_start), gameobjects (_go_template_use, _go_use), and spells (_spell, _event). The functionality is limited enough:
   https://github.com/mangosthree/server/blob/master/src/game/ScriptMgr.h
   but still allow to create beautiful game encounters. As any DB scripts, these are safe in the sense that cannot cause a core crash.
   
2. A higher functionality level is provided by the EventAI engine:
   https://github.com/mangosthree/server/blob/master/src/game/CreatureEventAI.h
   This is applicable only to the mobs. The related data are gathered in the DB tables creature_ai_scripts, creature_ai_texts, creature_ai_summons. EventAI is handy even for a rough scripting of dungeon bosses, and is actually used by over 4000 creatures in Zero. These DB scripts are safe also.
   
3. Even better functionality is provided by the Eluna engine not integrated into Three yet, so here are script examples from Zero:
   https://github.com/mangoszero/LuaScripts
   The concept is new to me, at least in relation to MaNGOS. I guess this is a hand to the addon developers giving them scripting capability with the same formal language. Sorry, here I cannot say anything helpful.
   
4. The highest possible script functionality is available in SD2 (written in C++). This comes for a price: these scripts are unsafe, and non-experienced devs create the core crashes readily. The scripts are named and referred by the names (ScriptName field) in the following DB tables: creature_template (mobs), gameobject_template (GOs), instance_template (map scripts related to instances), item_template (items), scripted_areatrigger (areatriggers), scripted_event (spell event, analogous to dbscript_on_event table; actually should be a part of map scripts), world_template (map scripts for non-instantiable maps).
   

What level of the scripting I have to use for my task?

A simple answer: either, which allows you to score your goals.

The exact answer is more complicated and, therefore, subjective. In analogy with known proverb about militaries, one could say: there are three ways to do something: right, wrong, and hacker's one. Put aside the "wrong" one, which will never lead you to a solution. It happens when you try to solve a task with missing important instruments, which cannot be substituted. The difference between the terms "right" and "hacker's" lies in the semantic area. To me, a "right" way is the optimal (at the given level of full emulator capabilities) and therefore good-looking one ("a beautiful theory cannot be wrong", you remember?). All others belong to the "hacker's" one. Sad to say that in such terms, most of the MaNGOS code seems "not right" as equivalent to "hacker's" (but also "not wrong"). This is caused by many factors, inlcuding objective ones. For instance, SD2 is distorted due to it more or less separate development route; incorporating it into the core (which AFAIK was the first unsolvable conflict raising the whole TrinityCore line) improved the class structure of SD2 greatly, in between allowing to create such powerful instrument as SpellScript in a subtle integration with the core. But the same effect can be achieved by a complete redesign of the Spell and dependent core classes.

So how I should start scripting, finally?

Use the simplest possible level of scripting.

Before starting, get rid of the following illusions:

• it is possible to work with SD2 without an extensive database understanding,
  
• it is possible to restrict yourself only to the DB tables directly related to DB scripts, mentioned above,
  
• you will be lucky to find a coherent and actual documentation on a particular thing or question, so you'll follow recipes and do not need experiments; after this – your experiments will succeed quickly,
  
• your scripts will be compatible between MaNGOS levels (Zero, One, up to...) or at least will remain valid for the target level during a long time,
  
• any of your five acceptable approximations to the solution of a particular problem will be "right" in the sense defined above.
  

The simplest development level is restricted to changing database only, and for a lot of tasks it will be enough.

=====================

Sometime I had started with a brief study of all DB tables, for a few months it sufficed, supplemented by experiments. Then I bumped into a problem requiring information directly from the core sources. This code is the only guaranteed your information source.

If this was of any help, I could try futher and closer to the particular SD2 though I have no specific knowledge about Three (the most came from Two and below).

[AdmiralMorketh]

well that is defiantly a ton of good information and i hope that does help. guess i should learn how to not bite off more then i can chew on. I think what i will do is try and learn how this works and write some documentation on subject seems like most of this is all trial and error some one out there knows enough about it after all if they didnt it wouldnt have been developed in the first place i think the problem lies int he lack of documentation. i think with a little work what y'all have mentioned above can be broken down into a good piece of documentation with some awesome code examples on how to build new scripts or new content.

Antz ive seen various places around the forums you have developed some kind of tool to aid in the creation of scripting content/NPCs would you by any chance have a link for that? id like to see if i could get my hands dirty a bit now that i have a better understanding of what i might be doing

[Foereaper]

In short, Eluna is a Lua interpreter integrated into the core as an optional script framework to SD2. One of Elunas pros is that it doesn't require you to recompile the core when you add/edit existing scripts. Lua scripts can be reloaded on the fly, though this should only be used for development purposes. These scripts are saved in the "lua_scripts" folder in your server directory.

As mentioned above, Eluna is not yet implemented into Three, but it's being worked on and will be available shortly, specifically with Rel20.

Like SD2, it is based around action/reaction, referred to as events. Each event is registered to a function (As an example RegisterCreatureEvent(), see Eluna API for a list of all the different registers and what events they support), and passes variables to the function that can then be manipulated by the use of methods. As an example, an event could return a Player object. You can then invoke a method, say :GetName() on the player method, and it would return a string containing the Player objects name. The below example script will print the players name in the console whenever the player logs in:

function [color=#00ff00]PrintOnLogin[/color]([color=#dda0dd]event[/color][color=#000000],[/color][color=#dda0dd] player[/color])    
   print([color=#dda0dd]player[/color]:[color=#00ffff]GetName()[/color])
end

[color=#ff0000]RegisterPlayerEvent[/color]([color=#0000ff]3[/color], [color=#00ff00]PrintOnLogin[/color])

# = This is how we register a Player event to a function. It requires an event ID and a Function name. The said event will then be registered to the function specified.

# = This is the event ID. Each register type (in this case Player event 3 = OnLogin) has several different events, and can be found on each register types documentation page.

# = This is the function name. This is arbitrary, and can be named whatever you like.

# = These are the variables passed to the function by the specific event registered to it. This varies from event to event, and is specified in the event list of each register type.

# = This is a method, invoked on the Player object passed from the register. Some methods require other variables, like :SetHealth(health).

Though this is as simple as it gets for a script, it is pretty much how the entire system is built up. Several hundred methods that can be invoked on a large array of objects can be found on our documentation/wiki. If you have any questions, feel free to ask!

For Eluna, several examples can be found here:

Emudevs: EmuDevs | Home of the Eluna Lua Engine - WoW Repacks, Scripts, Applications & Support + Console Emulation |

Eluna repo: https://github.com/ElunaLuaEngine/Scripts

Mangos' script repo: https://github.com/mangos/LuaScripts

Our documentation page can be found here: Eluna API

[AdmiralMorketh]

Forereaper,

this will be a great addition to Mangos-three once its done (is there an ETA for that? A few posts back Antz said "very soon") im actualy going to pull a copy of mangos-Zero (is that the one with the eluna engine?) and play around with it and see what i can come up with. im going to take Olions post up there and see what i can learn. start off with something small to get the hang of it thank you for the help y'all have been very helpful i actualy think i can "safely" (is that the way Olion put it? ) script a few things now with out breaking the engine too much

[antz]

Sadly soon is soon, We are still putting the final polish of Rel20 of Zero and One.

- Once these are out of the door, I'll have a lot more time to get Three shipshape

In the meantime, many of the existing outstanding updates are being applied to three in preparation for this mammoth undertaking

[Foereaper]

Eluna has been implemented into the latest branches of Zero, One and Two. Three is on the chopping block though, so like Antz said, "soon" If you have any questions or need any help, make a support thread and I'll help as much as I can

[Olion]

Our documentation page can be found here: Eluna API

Thank you for the ref remembered. As of the instrument set, it is close to native C++ (SD2) scripts.

For interested ones, there is a loooong discussion at TrinityCore about Eluna. Would I participate there, I noted that even with JIT, Eluna will never approach an optimizing compiler due to calls LUA->C tearing fragments apart; number of these calls should be greater if doing things correctly, i.e. denying DB access as well as direct packet sending to every scripting engine. TC is lucky: since SmartAI, any other scripting engine can be dropped safely. Too complicated? But doesn't require any programming language. Also, there are too few products you're really interested in, created without complicated technologies: from your computer and phone to your breakfast with GMO or at least decades of selection. (Honestly, it's the main my reason to dislike LUA )

But from end user point of view, I see two obvious Eluna disadvantages: efficiency and text localizability. Don't know about thread safety also (about deadlocks mostly), this may be really tested at online >1k, I suppose.

Back to the topic. Another bit of my view. I think it is necessary before speaking about DB tables and source code.

===================================================

General World construction

The scene, at which the play takes place, consists of many components of the two kinds.

• Static content is represented by parts hardcoded into the client. Here are maps, building/creature/item visual models, sounds, spell animations so on. All the data are kept in *.MPQ archives and can be modified too, which will mean modifying the client, - a bad practice in all senses. The server uses some data from MPQ archives "as is" (DBC files), other after a treatment (map files in maps/), and adds new data fully derived from the previous one with either a minor labour (vmap files needed for effective line-of-sight implementation) or a major one (mmap files required for creature pathfinding). So, these derived data resulted from usual size-for-speed trade.
  
• Dynamic content, provided to the client by the emulator (server). The most evident example is the World population: a placement of creatures and objects into the scene (i.e. maps). Any synchronization data between clients, leading to exactly the same World displayed for each participant (player), represent dynamic content too. Moreover, there are more or less invisible to player parts like Warden, or dynamic code blocks for the World behaviour appeared since 4.x client version.

From the exact ("blizzlike") emulation point of view, some of dynamic content should be viewed as a predefined one. An example of this is provided by item parameters. Few of these parameters, like type and visual model, are hardcoded in ItemDisplayInfo.dbc or elsewhere, but many, like stats, are provided by the server. The parameters are kept in the "mangos" database in the item_template table. However, for each World version they are (in principle) known and should not be changed. In this way the "WDB verified" concept rises: there are fields in description of objects, defined by data directly got from official server. List of such fields for WotLK is presented here.

Main entities, available for control in the World

A list of the most important controllable in-game entities reflects actual core C++ classes to a huge part, as it was expected.

Unit. A hub of the universe, but not easily describable. A "living" entity? An entity, able to move? An active entity? A selectable entity? Neither of this statement is always true for a unit. Consider, for example, chairs around a Pilgrim's Bounty table: these units are special cases of mounts, more exactly, of vehicles. Alike the Wintergrasp cannons. Consider then an invisible bunny, having the only purpose to mark a target spell position. Well, hope you got the idea anyway From this base class, core derives Creature and Player classes.

Gameobject. A "non-living", "static" element at the scene? Barely static: doors, chests, "destructible GOs" since 3.x like Wintergrasp castle walls, and so on, are the examples from the GameObject class. A mailbox is interactible, in contrast to campfire or anvil. Sometimes it is impossible for player to visually distinct a gameobject from a map object, the later belonging to the static content as a part of map.

Spell. Probably the most complicated World construct. Mostly it can be viewed as a recipe for interaction between two or more other entities. The vast majority of actions in the World are done through spells. Any example, as well as any number of examples below, say, 1% of the total (client-known) 22359 spells for Zero or 49839 spells for Two, will be insufficient here. One of the simplest spells represent direct damage (mage's Fireball) or healing (priest's Heal). Another greatly important spell type is known as auras, which modify parameters of the affected Unit, including its spells, for either a predefined time interval or permanently. HoTs, DoTs, talents are all represented by Aura class, as well as polymorph and invisibility, mounted and fly effects and many others.

Item. Anything you may put into your bag (which, in turn, is an item too). Some tokens not placed usually into the bags belong to items also, these are mainly currencies (PvP tokens etc.)

Quest. It is "material" in the sense in which a fairy tale/adventure is. This limits possible ways of controlling it: the story can be changed, unfinished and so on.

===================================================

[sanctum32]

Well to script creature is not too hard for sd2 (sd3 is comming soonish), so till it will ported, you could try to pick some examples and start inspect c++... I do not see any issue on it because sd2 script structure is really easy to learn.