* all teleport commands support new areatrigger and areatriger-target shiftlinks
* .go trigger now let select areatrigger or areatrigger target as teleport point
* New commands:
.trigger - show detail info about areatrigger including all requirements
for teleport with shift-links to items/keys/quest
.trigger active - show all currently activated by character areatriggers
.trigger near - show near areatriggers
* .lookup item now show [usable] postfix if item can be used/equipped by selected character.
Signed-off-by: VladimirMangos <vladimir@getmangos.com>
Note: prev. commit of same author (Toinan67 is alt. nick name ;) )
Also added some more checks in ref. function.
* Database table needs data for each faction that should give spillover to other faction(s). One faction may give spillover to max 4 other spillover factions.
* The spillover rate is multiplied with the points after bonuses and reward rate is set, Rate is given as: 0.5 for 50% gain, -1.0 for 100% loss, etc
* It is possible to restrict spillover faction by rank. If player has a higher rank with the spillover faction given in database, no spillover will be given towards this faction
Signed-off-by: NoFantasy <nofantasy@nf.no>
* In addition, implement "flat" reputation for quests, where a value in RewRepValueN is given. Human diplomacy will not affect the total. The rate however will be applied, where a faction is defined with a rate for quests. Value in database are expected to be *100 of the actual value given (before rate are applied).
* New database storage can contain rates for quest/creature/spell reputation and will affect the base value given as reward. When for example the quest reward for a faction should receive 30% more reputation points, the rate can be set to 1.3.
* This will fix issues with certain quests that are using the expected RewRepValueId but where the outcome has been lower than expected.
* Note that if the rate is set to 0.0 it will disable reputation gain for the faction and type.
* Reputation rate for spells (spell effect) is not yet implemented
Signed-off-by: NoFantasy <nofantasy@nf.no>
Maybe command not so useful for stable case because spell can be learned,
but it example how can be packet allowed depndent from player possibility
when some functionality base at many packets recieved from client.
Same way possible can be used for auction anywhere, maybe some other cases.
Also it will very usefull for 2.x/1.x branches where no another way... ;)
* Use single command search function with recursion and reuse it in now more simple
and consistent for execute/help/loading
* Add intergiry checks for hardcoded part of commands list. Fix some cases base at it.
* Fixed diff small problems in past code:
- in console single symbol commands rejected (without dot start)
- .help not output propertly subcommands list for not found subcommand
- some other...
* Now '.go' command can be used with creature_entry/gameobject_entry shift links (output of .lookup creature/object commands)
* Now '.go object' command sipport id-mode and name part mode similar .go creature case: .go object id #gameobject_id or .go object $namepart.
* HandleGoHelper use in more commands also.
* Now if for .go command provided no X Y Z args command will not teleport player to nowhere.
* Instead command allow used with player name and work as simplifed .goname
(teleport to player _point_ in user instance binding, not to player instance)
* Also command can be used with diferent point coordinates provided shift-links:
- player (result for example .lookup player account)
- creature (result .list creature command)
- gameobject (result .list object command)
- tele (result .lookup tele)
- taxinode (result .lookup taxinode)
* .server log filter comamnd let temporary (until config reload or restart)
set log filters state. Or look at filters state.
* .server log level renamed from .server set loglevel but now let look at log level also.
* .lookup account email, .lookup account ip, .lookup account name
* For new commands and for .lookup player versions use first arg as part of email/ip/name search
* Use similar output format for player/account lists.
* At login reset '.reset all talents' will reset all spec talents.
* New command '.reset specs' will reset its online/offline.
* Command '.reset talents' now not support offline player case.
Command show really know by selected player talent ranks,
including bugged cases like 2 rank same talent known and etc.
Also command claculated count of talents and total used talent
points cost of known talent ranks.
Can be helpful in bug debuging and cheating cases.
Only one example (mostly) case converted to use it.
Need lot work for finally switch to class obly use, so old low-level defines still exist also (while used).
But some unused low-level defines dropped.
* Now at login by RA-connection RA-connection use account id/access level
for commands execute. So at login with moderator access by RA-connection you
can execute only moderator level commands. For administrator level accounts
allowed execute only console level commands if new config option RA.Stricted = 0.
For security reasons by default RA.Stricted = 1.
* RA-connection executed commands now logged for associalted account id
* Some own account related commands allowed execute in RA-connection
NOTE: config version updated because RA.Stricted = 1 not compatible with old
way work and this can break tools thta use RA-access if it not disabled.
Yuo will need update mangosd.conf.
- removed deprecated code from RASocket
- allow more than one login at a time on the RA console
- added gsoap library for handling SOAP requests
- removed deprecated mangos_string entry
Thanks to:
- Derex for reporting a bug which occured if more than 1024
players were connected [poll() vs select()]
- caeruleaus for adding windowsbuild support
- vladimir for suggesting a different thread starting order
- fdb_ for suggesting SOAP in the first place
* For reload `gossip_menu`, `gossip_menu_option`, `gossip_scripts`,
`npc_gossip`, `points_of_interest` by single command.
* Also fixed reloading `points_of_interest`.
* It was wasting CPU power as cell-level locking is not needed.
* Future multithreading will be on map-level.
* CellLock was just a 'proxy' between Cell and CellPair and in some cases carried redundant data.
* Some minor cleanup in Cell::Visit/Map::Visit.
