* Update OfflineConfiguration.cs
Removed the duplicate "the" from the comment on line 63
* Update Config.js.docker
Removed the duplicate "the" from line 216
* Update Config.js.example
Removed the duplicate "the" from line 217
* Update Player_Networking.cs
Removed the duplicate "the" from line 27
* Add mod support
* Change .NET Core 3.1 to .NET 6 for DatLoader.Tests to remove dependency.
* Add default mod path
* Attempt to create missing mod folder
* Update Source/ACE.Server/Mods/ModManager.cs
Co-authored-by: gmriggs <gmriggs@gmail.com>
* Use pre-release Harmony
---------
Co-authored-by: gmriggs <gmriggs@gmail.com>
* Added optional check for newer server binary. Changed DB Update to check only 'latest'
* Update OfflineConfiguration.cs
* Update Program.cs
* Update Config.js.example
Co-authored-by: Ty Conner <tyconner@itcproductions.com>
* Adding extra options for AutoApplyWorldCustomizations
* Added examples for world customization content paths config option.
* Added double-backslash for path examples in world customization paths config.
* Improve Multi-threaded landblock group ticking (non-physics)
This splits up the previous Landblock Tick() work into two functions:
TickMultiThreadedWork()
TickSingleThreadedWork()
Mainly, this allows multi-threading of the following work:
Landblock.actionQueue.RunActions();
Landblock creatures Monster_Tick()
Landblock Heartbeat
Landblock Database Save
The first two of which are the biggest CPU consumers from the previous Tick(), and, fortunately enough are pretty safe to multi-thread.
* Make player teleports from portal collisions via physics a thread safe action
* Fix an exception raised in debug mode when creating new characters
* Thread safety for player teleports from death
* ThreadSafeTeleport framework
* More ThreadSafeTeleport cleanup
* AdjustDungeonCells fix
* update AdjustPos comments
* WIP: Multi-thread landblock ticking
This is the start of "landblock group" ticking.
The idea behind the landblock groups are that each group may contain multiple landblocks that must be ticked on the same thread, but, each group itself can be ticked on independant threads.
The current groups are as follows:
Every outdoor landblock is in a group
Every dungeon landblock is in it's own group (one per dungeon)
This is not ready for public servers yet.
* More changes
* First pass at actual groups
* ObjMaint.KnownPlayers needs to be concurrent
* Removing original PoC code from LandblockManager
* Landblock Tick Cleanup
* VisibleObjects also needs to be concurrent
* DestructionQueue also needs to be concurrent
* KnownObjects needs to be concurrent
* Use a bool to toggle multi-threading
* Add thread safety to SequenceManager
* Move landblock phsyics ticking to LandblockManager
Also
* Cleanup log.Info level messages
Log.info is the default console output and is intended for:
server startup
connection/disconnections
admin initiated command output
server shutdown
Log.Debug is the appropriate level for debug-type messages that are to be logged and audited at a later date, but not output to the console.
* Missed a couple
* Move HandleSalvaging from Warn to Debug
* Add thread safety to Landblock
* More landblock group calc stuff
* couple comments
* Add some thread capping
* Limit database from taking all the threads
This adds limits to the database thread consumption.
It also should allow the world to now consume threads easier.
The way it is done is as follows.
- We determine the number of available threads using Environment.ProcessCount
- We allocate (int)Math.Max(Environment.ProcessorCount * .34, 1) to the World, and the remainder tothe database.
It breaks down as follows
1 vCPU = 1 thread world, 1 thread database
2 vCPU = 1 thread world, 1 thread database
3 vCPU = 1 thread world, 2 thread database
4 vCPU = 1 thread world, 3 thread database
5 vCPU = 1 thread world, 4 thread database
6 vCPU = 2 thread world, 4 thread database
7 vCPU = 2 thread world, 5 thread database
8 vCPU = 2 thread world, 6 thread database
9 vCPU = 3 thread world, 6 thread database
10 vCPU = 3 thread world, 7 thread database
I'd like to get some feedback from this PR on various sized servers.
What you may notice is that loading a player may take slightly longer (very slightly).
What you will probably notice is no discenerable difference in-game.
What I want to make sure happens is that the world doesn't end up feeling more choppy due to the parallel processing of outbound network traffic. Hopefully the more fair thread distriubiton will help prevent thread starvation.
* quit if not enough vCPU
* separate landblock group recal between add/remove
* revert landblockMutex in Landblock.cs
* World Manager AboveNormal thread priority.
* Add some tags
* Couple more
* Create LandBlockGroup entity
* remove space between tags
* Update the log4net examples
* Efficiency improvements
* fix message
* more WIP
* Improve log4net
Add color to console output
Make the default logger use Log4Net.Async
* WIP
* More WIP
* more WIP
* More WIP
* more WIP
* More WIP
* more WIP
* wip
* more WIP
* remove old processor count check
* Create ServerObjectManager
This removes the ServerObjects collection out of ObjectMaint into it's own class.
This paves the way for thread safety that will need to be added to ObjectMaint for the multi-threaded landblock groups.
* Only split if multi-threading is enabled
* remove comment
* ObjMaint refactor
* all obj maint collections are now private
* few more optimizations
* alternate objectmaint thread safety model
* fix
* Remove a couple of comments
* improved ObjectMaint locking
* lock (ThreadConfiguration.WorldLockObject) OnDeath
* progress
* set MultiThreadedLandblockGroupPhysicsTicking to false
* Move a bool
* add lock
* physics ticking thread safety improvement
* use Config.js for thread configuration
* Add config comments
* measure physics ticking performance
* /serverstatus info added
* comments
* /serverperformancemonitor command
Optional parameters are:
start
stop
reset
If no parameters are present, the current performance metrics are spit out.
When disabled, overhead is the cost of some simple function calls and a bool check. When enabled, the additional cost is stopwatch events. In comparisson to the work that ACE does for normal processing, the work done when serverperformance is enabled is nearly 0.
Default is disabled.
Enable it to start up automatically in the config.js. This is recommend for most servers. Enable it at runtime using /serverperformance start
* Fix Reset
* Change WorkFactor to 8
* Add configuration option for password workfactor, and migration option to support [up/down]grade at runtime
* Fix a default
* Do not pass in values less 4 and greater than 31 to prevent server crash
* Update defaults
* Changing configuration file format to JavaScript instead of JSON for the ability to embed comments, Backwards compatible, ACE.Server project pre-build renames Config.json to Config.js when needed, but if that never happens it's still OK and falls back to the old filename.
Changed startup batch files to determine what the current directory should be and change to it before starting ACE
* fixed
* move config old to new filename upon program start
2019-02-16 16:27:46 -05:00
Renamed from Source/ACE.Server/Config.json.example (Browse further)
