- MySQL numeric types can NOT be altered in value range or or storage size at all, so things like INT(32) are entirely pointless. As TC currently doesn't use the display width of numeric types, use the default width to avoid confusion. (see MySQL numeric types docs)
- Timestamps can be stored as INT(10) UNSIGNED. As the max value of this type is 4294967295 which translates into year 2106 using it as timestamp we are NOT affected by the year 2038 bug. If the timestamp needs to be negative in some cases, i.e. for displaying infinity using -1, use BIGINT(20) instead.
- Do NOT set ROW_FORMAT for InnoDB tables unless you specifically want COMPRESSED tables (which we don't for performance reasons). MySQL will chose the appropriate ROW_FORMAT by itself depending on the innodb_file_format setting of the server. (FIXED is only available for MyISAM)
- Even though VARCHAR does require less storage space than CHAR for values with variable length, the length still needs to be chosen wisely as this doesn't apply to memory consumption.
- Set MovementFlagsExtra (2) correctly depending on vehicle 'template' flags. This makes certain vehicles such as demolishers unable to jump/strafe (as intended)
- Fix SMSG_MONSTER_MOVE_TRANSPORT stucture, prevents a client crash when entering certain vehicles, as well as *properly* broadcast position relative to the vehicle.
- Send SMSG_BREAK_TARGET to player when entering vehicle.
- Set MOVEMENTFLAG_ROOT on passenger when entering vehicle
- Cleanup in affected code
* OOP desing and implementation;
* all the queries are moved to prepared statements;
* guild loading is optimized;
* all the possible interaction with guild's data is done inside the guild class;
* added more hooks to GuildScript class;
WARNING: Make sure you backup your characters database before applying this change (just in case).
Known problems with guilds:
* when new member is added to the guild, MOTD is not displayed for him in guild tab of social window;
* if you add item with random property to guild bank visual representation of item below it becomes wrong (it displays wrong stack number);
* packets order differs from official: currently guild bank packet traffic is twice as more than on offy.
--HG--
branch : trunk
- Replace many magic numbers with constants
- Use enum for vehicle flags/seat flags
- Correct structure for ItemRandomSuffixEntry
--HG--
branch : trunk
- Rewrite Field class to be able to store both binary prepared statement data and data from adhoc query resultsets
- Buffer the data of prepared statements using ResultSet and Field classes and let go of mysql c api structures after PreparedResultSet constructor. Fixes a race condition and thus a possible crash/data corruption (issue pointed out to Derex, basic suggestion by raczman)
- Conform PreparedResultSet and ResultSet to the same design standards, and using Field class as data buffer class for both
* NOTE: This means the fetching methods are uniform again, using ¨Field* fields = result->Fetch();¨ and access to elements trough fields[x].
* NOTE: for access to the correct row in prepared statements, ¨Field* fields = result->Fetch();¨ must ALWAYS be called inside the do { }while(result->NextRow()) loop.
* NOTE: This means that Field::GetString() returns std::string object and Field::GetCString() returns const char* pointer.
Still experimental and all that jazz, not recommended for production servers until feedback is given.
--HG--
branch : trunk
* Rename QueryResult class to ResultSet
* Rename QueryResult_AutoPtr to QueryResult
* Declare ACE refcounted auto pointer for PreparedResultSet class
--HG--
branch : trunk
- Implement QueryCallback_2 template for ACE_Future callbacks using 2 parameters for the callback function
- Make MSG_LIST_STABLED_PETS´s handler use async query instead of blocking query
--HG--
branch : trunk
- All "'xxx' will be initialized after 'yyy' when initialized here"
- Some "unused variable"
- Some "enumeration value 'xxx' not handled in switch"
--HG--
branch : trunk
- 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
- Use ACE_Future and ACE_Future_Set for async SQL queries with callback
* Callbacks will now be executed from the thread and object that scheduled the request, instead of the world runnable thread (and thus are no longer dependent on the 50ms forced sleep time).
* This design gets rid of a potential DOS loophole in the resultqueue system - unique requests will be cancelled when re-requested.
- Drop now redundant SQLQueryTask, SQLResultQueue, SQLResultQueueTask operations.
- Drop now redundant CharacterHandler class
- Change static callback functions in WorldSession to normal functions.
Thanks to Derex and Zor for advice along the way.
--HG--
branch : trunk
- Initialize all packet size properly
- Updated all function documentation
- Add placeholders to all LFG opcodes
- Use lowguids wherever is possible
--HG--
branch : trunk
*Add MO transports to ObjectAccessor storage
*Add functions Position::RelocateOffset and Position::GetPositionOffsetTo to help offset manipulations - BIG thanks to azazelkon for creating formulas!
*Add function to output debug info for MovementInfo and SpellCastTargets
*Throw ByteBufferException on incorrect packGUID read
*Add rfinish function to finish bytebuffer read.
--HG--
branch : trunk
* 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
