- Make SQL Transactions actual objects used in code. (Thanks to Derex for the idea)
* Uncommitted transactions will be automatically rolled back and cleaned up using ACE_Refcounted_Auto_Ptr, so no need to call Rollback() in the code.
* Prevents recursive transactions and makes developers aware of transactions going on.
* Gets rid of unneccesary overhead iterating over a concurrent map.
- Some cleanups in affected code, including better usage of transaction control in AH / mail related code to prevent data loss.
*** Experimental, use at own risk, recommended to backup your DBs. ***
--HG--
branch : trunk
Database Layer:
- Implement connection pooling: Instead of 1 delay thread per database, you can configure between 1 and 32 worker threads that have a seperate thread in the core and have a seperate connection to the MySQL server (based on raczman/Albator´s database layer for Trinitycore3)
- Implement a configurable thread bundle for synchroneous requests from seperate core threads (see worldserver.conf.dist for more info)
- Every mapupdate thread now has its seperate MySQL connection to the world and characters database
- Drop inconsistent PExecuteLog function - query logging will be implemented CONSISTENTLY later
- Drop current prepared statement interface - this will be done *properly* later
- You´ll need to update your worldserver.conf and authserver.conf
- You´re recommended to make a backup of your databases before using this.
* HIGHLY EXPERIMENTAL - USE AT OWN RISK *
* HIGHLY EXPERIMENTAL - USE AT OWN RISK *
etc.
--HG--
branch : trunk
* Rename *mgr to their new names in scripts project
* Mass convert all the scripts (NEEDS THOROUGH TESTING, because it was done automatically) Please, report bugs on issue tracker.
--HG--
branch : trunk
rename : src/server/game/Instances/InstanceData.cpp => src/server/game/Instances/InstanceScript.cpp
rename : src/server/game/Instances/InstanceData.h => src/server/game/Instances/InstanceScript.h
* Removed the misdesigned on_events script/hooks.
* Lots of related cleanups and assertions.
* The interface is now fully object-oriented.
** Scripts no longer use function pointers.
** Scripts no longer use the general-purpose Script struct for everything.
** Script types are split into separate classes which must be inherited depending on what functionality is desired.
* Several script types have been added to allow extending functionality in a code-only manner (some script types require
assignment in the recently added ScriptName columns in the database, though).
** SpellHandlerScript: Wrapper around spell scripts (returns new SpellScript objects (`spell_script_names`.`ScriptName`)).
** ServerScript: Allows scripting events that occur in the network layer.
** WorldScript: Allows scripting certain world-global events.
** FormulaScript: Allows hooking and interfering with core formulas.
** *MapScript: Allows hooking different map types (including world, instance, and battleground maps (`instance_template`.`ScriptName`)).
** ItemScript: Allows scripting of items (like the old interface (`item_template`.`ScriptName`)).
** CreatureScript: Allows scripting of creatures/AI (like the old interface (`creature_template`.`ScriptName`)).
** GameObjectScript: Allows scripting of gameobjects (like the old interface (`gameobject_template`.`ScriptName`)).
** AreaTriggerScript: Allows scripting triggered area triggers (like the old interface (`areatrigger_scripts`.`ScriptName`)).
** OutdoorPvPScript: Script which should return OutdoorPvP objects for use by OutdoorPvPMgr (`outdoorpvp_template`.`ScriptName`).
** CommandScript: Allows extending the in-core command table.
** WeatherScript: Allows scripting of weather changes (`game_weather`.`ScriptName`).
** AuctionHouseScript: Allows scripting of auction events.
** ConditionScript: Allows scripting of conditions (`conditions`.`ScriptName`).
** DynamicObjectScript: Allows scripting of dynamicobjects.
** TransportScript: Allows scripting of transport events (`transports`.`ScriptName`).
* OutdoorPvP objects are now created through scripts. This effectively means that they'll need to be moved to scripts
before the they're functional again.
* The whole idea with this new interface is to allow expanding core functionality without touching core code. If further
hooks are needed to expand functionality of the core, let us know; we'll add them, if we agree that it is appropriate
to do so.
*** NOTE: The scripts project will _not_ build before it has been adapted to the new interface.
*** Thanks to everyone who helped out with related preparations and suggestions!
--HG--
branch : trunk
