| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This getting annoying while trying to do multiple changes.
Types/structures had to be shared all the time making it nessecary to
find ugly workarounds.
|
|
This removes support for skills. The plan is to allow to implement the skills
as they were implemented before via attributes. This adds a lot more
flexibility to the server creators while also removing the confusion about
skills and attributes.
So this change does:
- Remove the skillmanager with all its calls, the skill xml file, etc
- Move exp giving to the script engine:
--> Allows to implement the old behaviour (and more) in the scripts
- Remove the exp tag from the monster definition:
+ Since the server itself does not require it anymore it feels wrong to
require it for EVERY monster. TODO: Add a system to add properties to the
monsters/items.xml which allow defining things like the exp and allows to
read the value from the script engine.
+ Small drawback, but it should not be hard to implement this property
system.
- Drop the level networking and calculation.
+ level calculation will happen via the attribute system later but i would
prefer to do this in a seperate patch since this patch already got longer
than expected especially since this requires to make setting correction
points and available status points scriptable.
+ The level would be simply set as a attribute, the int number of it will be
the level, the remaining digits will be the % number till the next levelup.
- NOT remove any existing skill tables in the database update scripts.
+ There is no way to move them into the attribute table in a unified way
(there are too many different way they could have been used). So server
admins have to care about moving theirs skills to attributes themselves.
+ Keeping the old tables does not hurt for existing databases. So removing
does not give any advantage/is required anyway. The now obsolote info
about the EXP transaction is not removed for updated databases either.
(The update script basically only bumps the version number without doing
anything else.
- bump the network protocol version --> old clients won't be able to connect.
- bump the database version --> serveradmins need to update their db.
|
|
|
|
|
|
|
|
Since the name was used to log things and the default now is "" also added
logging of the address and port too.
|
|
If you set net_gameServerName you can now reserve maps in the maps.xml.
There you have to add the servername - property to the <map> tag.
Then the map will only be activated by that server.
Also changed the activate sequence that the account server now tells the game
server what maps to activate (previously the server requested all maps and the
account server said yes or no).
TODO: Fix general inter server map switching.
|
|
|
|
Same thing, but shorter.
|
|
Allows inspection of message data. It is off by default since it consumes
additional bandwidth, but it can be turned on using the net_debugMode option
in manaserv.xml.
Currently the option only affects outgoing data for each host individually.
In particular, enabling this debug mode for the server does not automatically
make the client annotate its messages.
Reviewed-by: Erik Schilling
|
|
Compiler error was due to variable redeclaration (variable inside of for
loop had the same name as the loop iterator variabele) - fixed through
renaming of the inner variable.
Reviewed-by: bjorn
|
|
In preparation for using an entity/component system for the entities
in the game world, this name will be more recognizable and easier to
talk about.
Reviewed-by: Yohann Ferreira
|
|
Due to a wrong primary key, which covered only the state name, it was
impossible to use the same state name on different maps. This has now
been fixed.
Another problem was that the map variables were being included in the
global variables, because the related database query did not filter on
the map_id column properly. While fixing that, the map_id column now
allows explicitly marking a state variable as global (with the value 0)
or system variables (with the value -1).
System variables are currently not accessible from scripts, but that
could be changed later.
Reviewed-by: Yohann Ferreira
Reviewed-by: Erik Schilling
|
|
The AGMSG_REGISTER_RESPONSE message should be sent _after_ adding the
global world state variables to it rather than before.
Reviewed-by: Yohann Ferreira
|
|
- Added announcements having senders now.
- Removed /announcement support.
Reviewed-by: Bjorn.
|
|
Also made some random changes where useful, including:
- Code formatting fixes,
- Design fix about the fact that only the game config option
should be checked.
- Fixed the size of the values sent and receive to follow
the rest of the development.
- Fixed variables names to make them show what they are,
and not why they are used.
Resolves: Mana-Mantis #142.
|
|
The player sends party invites to the game server.
If the invitee is within the visual range of the inviter,
the game server forwards the invite to the chat server.
Reviewed-by: Bjorn, Jaxad0127
|
|
* Remove SYNC_END_OF_BUFFER since the end of a message can already be
identified by no more data being available.
* Consistently prefix ++ rather than postfix ++ when incrementing
mSyncMessages.
* Made SYNC_BUFFER_SIZE into constants rather than defines, and moved
them into the .cpp file since they're not used anywhere else.
* Just use 1 and 0 to indicate online status. No point in writing it
like 0x01 and 0x00.
* Merged some duplicated documentation for
AccountConnection::syncChanges.
Reviewed-by: Jared Adams
|
|
Just seems a bit more organized to me.
|
|
A bunch of variables that were continuously requested from the
configuration are now members of the AccountHandler.
Reviewed-by: Freeyorp
|
|
When banning a character, the game master now sets a time unit (m, h, d, w
or y for minutes, hours, days, weeks or years) after the duration.
Ban durations longer than 2^16 minutes are now possible.
The banned character is now kicked automatically and the banning character
receives a feedback chat message.
Reviewed-by: Thorbjorn
|
|
The gameserver now receive a copy of all world state variables when
they are accepted by the accountserver and receive a copy of all
map state variables of a map when they register it successfully.
Implemented LUA script bindings for getting and setting these variables.
When such a variable is set, the accountserver is notified about this
change. Changes to world state variables are then propagated to all
gameservers by the accountserver.
Be aware that when a gameserver is updating a map, there is no check if
it is actually responsible for said map. But I consider this not a
security flaw, because authenticated game servers are considered to be
trustworthy in a lot of other situations, too.
Also renamed "quest" to "character variable" in the sourcecode.
Reviewed-by: Bertram
|
|
Trivial.
|
|
Resolves: Mana-Mantis #278.
|
|
Also added an header to the autoattack.{h,cpp} files.
Big but trivial fix.
|
|
Mainly for consistency with the client, and the general consensus was
that these numbered versions were clearer.
|
|
Avoids having to remember to call rollbackTransaction and makes
transactions exception-safe (since the destructor of PerformTransaction
will be called when an exception is thrown).
|
|
This message can contain a lot of small database updates, which at least
on my system are way more efficient when performed in a transaction (now
it takes no more than 1 second vs. about 14 seconds before). Not saying
this is normal, my guess is that it's due to using full partition
encryption.
I've also prevented the thing from entering an infinite loop in the case
of a wrong message, and corrected some variable names.
|
|
Reviewed-by: Bertram
|
|
TODO: The game-server also needs to keep track of this for when new attributes
or attributes not in the default scope need to be created.
Also hopefully fix attribute calculation order for derived attributes. Still
hardcoded for now.
Reviewed-by: Bertram.
|
|
Attribute system:
Structure is no longer completely hardcoded. Attributes and structure is
defined by new xml file (defaulting to stats.xml)
Structure defines non-base modifications to an attribute, to be used by
modifiers from items, effects, etc.
Calculating the base value for core attributes is still done in C++ (and for
such fundamental elements the only reason I can think of to do it any other
way is perhaps being able to quickly change scripts without a compile could be
useful for testing, but such things are a low priority anyway)
Item structure:
Modifiers are now through triggers rather than single events. This also
removes hardcoded types - an item could be both able to be equipped and be
able to be activated.
Item activation no longer consumes by default, this must be specified by the
property <consumes /> inside the trigger.
Currently only attribute modifications, autoattacks, and consumes are defined
as effects, but stubs for others do exist. Autoattacks are currently
non-functional, and this should be rectified with some urgency.
Auto Attacks:
AutoAttacks are now separate entities, though not fully complete, nor fully
integrated with all beings yet. Integration with the Character class is
urgent, integration with other Being children less so.
When fully integrated this will allow for multiple autoattacks, through
equipping multiple items with this as an equip effect or even through other
means if needed.
Equipment structure:
As ItemClass types are no longer hardcoded, so too are equip types. An item
have multiple ways to be equipped across multiple equipment slots with any
number in each slot. Character maximums are global but configurable.
Miscellaneous:
Speed, money, and weight are now attributes.
Some managers have been changed into classes such that their associated
classes can have them as friends, to avoid (ab)use of public accessors.
The serialise procedure should also be set as a friend of Character (both in
the account- and game- server) as well; having public accessors returning
iterators is simply ridiculous.
Some start for such cleanups have been made, but this is not the primary focus
here. Significant work will need to be done before this is resolved
completely, but the start is there.
BuySell::registerPlayerItems() has been completely disabled temporarily. The
previous function iterated through equipment, yet in the context I think it is
intended to fill items? I have been unable to update this function to fit the
modifications made to the Inventory/Equipment/Possessions, as I am unsure what
exactly what it should be doing.
ItemClass::mSpriteId was previously unused, so had been removed, but I
notice that it was used when transmitting equipment to nearby clients.
Experimentation showed that this value was never set to anything other than
0, and so has been left out of the ItemManager rewrite.
I am not entirely sure what is happening here, but it should be worth looking
into at a later time, as I am not sure how equipment appearences would be sent
otherwise.
|
|
Reviewed-by: Jared Adams
|
|
|
|
The only reason it was a DALStorage was because it used to implement the
Storage interface, but that interface got removed a long time ago.
|
|
Also updated the headers to refer to the GPL by URL instead of
suggesting to contact the FSF by snail mail, as per the latest
GPL usage instructions.
|
|
defines.h, and removing some overheading along the way.
|
|
|
|
Needed when the server has multiple network interfaces and the one you
want to use isn't the default one for localhost.
The host to listen on can be set in config file with 'net_listenHost'.
|
|
Also renamed Guild::totalMembers to Guild::memberCount
|
|
Same as for the client.
|
|
|
|
This upgrade will be the first, we provide database installation scripts
and update scripts to upgrade from the previous version. For more details
about database upgrades see
http://wiki.themanaworld.org/index.php/Upgrade_Database and feel free to
comment.
|
|
The game server buffers all changes made to a character in a sync buffer.
The buffer is sent to the account server if the buffer contains more then
20 message, reaches size of 1kb or at least every 10 seconds.
ATM Character attributes, corr points and attribute points and skills are
synchronized. TODO: items, location, money...
|
|
|
|
version to account server during registration and gets notified if the version is up-to-date or outdated to prevent inconsistencies.
|
|
|
|
come at a later date)
|
|
|
|
|
|
|
