Age | Commit message (Collapse) | Author | Files | Lines |
|
Not entirely sure if this is what was happening, but if a
PAMSG_LOGIN_RNDTRGR was handled, a new pending account was always
created and appended to mPendingAccounts. However, when handling the
follow-up PAMSG_LOGIN, only the first pending account with matching
username was checked, which could result in a failed login due to
mismatching token.
Resolved this issue by unifying the client-specific random token with
the Stellar token stored on the AccountClient. This means the username
value in PAMSG_LOGIN_RNDTRGR could be removed.
Eventually it would also be nice to simplify this further such that the
token is automatically sent to the client after connecting rather than
being something that needs to be requested.
|
|
When using login with Stellar, the email address remains empty. This was
causing issues since the email is also required to be unique, in effect
only a single Stellar account could exist.
Resolved this by allowing the email column to be null, since the unique
requirement does not cover null values. An empty email will now be
stored as null value.
For non-Stellar logins, an email address is still required.
|
|
Something doesn't seem to be working right...
|
|
Fixes many memory leaks, but also made it clear that we're very often
loading all the character data only to immediately throw it away again,
even when most of the time all we really need is the database ID or the
name.
|
|
* Overall includes cleanup
* Use std::make_pair
* Make some functions const
|
|
The client needs to know the URL to open in the browser. The bare token
is still sent as well, which might allow the client to directly interact
with a Stellar wallet in the future.
|
|
|
|
Using atomic operations to avoid a compiler potentially optimizing away
the thread responsible for clean shutdown.
|
|
* Added PAMSG_STELLAR_LOGIN / PAMSG_STELLAR_LOGIN_RESPONSE, which is
used by the client to request a login token that can be signed using a
Stellar wallet.
* Added uWebSockets dependency, used to listen for a separate server
that verifies signed tokens (the Stellar Bridge). When a token is
verified, it is sent to manaserv-account, which then sends a
APMSG_LOGIN_RESPONSE to the client matching the token.
* Added RapidJSON dependency to parse the JSON WebSocket messages.
* To keep everything in a single thread, uWebSockets is now driving the
event loop. Processing of ENet hosts, writing stats and expired bans
have been moved to uSocket timers.
* C++ standard updated to C++17, as required by uWebSockets.
When Stellar is used to login, the public key is used as the username.
It might be better to introduce an explicit field for this, especially
when we want to enable an account to feature both Stellar login as well
as login with username / password.
|
|
modernize-loop-convert
modernize-deprecated-headers
|
|
modernize-use-auto
modernize-use-nullptr
modernize-use-override
modernize-use-using
|
|
Finishing 213af0fbde3f198ad1ab2143d32fc6798b7f8f50.
|
|
This is because the network interface on which the account server
listens to the game server does not need to match the one on which the
account server listens to the client.
|
|
Fixed by changing account instances to be managed by std::unique_ptr, so
we don't forget to delete them somewhere, like in that function as well
as during shutdown in AccountHandler.
|
|
For whatever reason, GCC 5.1 no longer finds an operator<< overload
for streaming a std::ostringstream into a std::ostringstream.
|
|
|
|
|
|
This makes it easier on the client to decide whether to immediately open
the Create Character page or to go to the Choose Character page.
Still supports client version 9 as well.
|
|
|
|
|
|
|
|
|
|
I was wrong to assume that we do not need it. The accountserver needs to
send the info the the client in order to display the equipment on the
character selection page.
|
|
wrapped the code parts with {} to prevent trashing the scope too much
|
|
|
|
It was a inventory slot not equipmentslot.
|
|
|
|
|
|
Things done:
- Removed the equips table and added another column which keeps track about
whether the item is equipped or not
- Added a message to notify the client about failing equips instead of
hardcoding to chat notification
- Removed the move possibillity. It was a quite long function and our future
idea of the inventory does not need any moves
- Removed the inInventory and inEquipment parameters from chr_inv_count,
but added a equipped key to the table that chr_get_inventory returns
This change makes equipped items still being in the inventory. This means
in-inventory triggers are still active! However it makes no sense to disable
this triggers during equipping since it will appear as still in the inventory
to the client.
|
|
|
|
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.
|
|
- Removed hardcoded using of attributes
- Simply introduced lua functions to set global and ability cooldowns
- Requires database update
- Bumps the protocol
|
|
Things done:
Wrote a entity:give_experience function (lua side only).
Renamed characterpoints to attributepoints (no db update. Did not want
to do one for a simple rename).
Temponary introduced a ATTR_LEVEL constant. TODO: dehardcode this.
Script binds for settings the correction and attribute points.
|
|
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.
|
|
This allows a lot more flexibility and makes stuff like magical items a
lot easier to implement. We will also use this for the attack system in
the future. So a attack (abilitiy) would simply depend on some value
like Agility (or a derived attribute from it). Which sets the recharge
speed.
The recharge speed is the modified value of the attribute per game tick.
|
|
|
|
Makes cleanup automatic and ownership somewhat better recognizable.
|
|
I am really bad at spelling verbosity :->
|
|
|
|
|
|
|
|
A CharacterData was created as a proxy class in order to allow using the
old serialization method.
|
|
|
|
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.
|
|
Reviewed-by: bjorn.
|
|
|
|
|
|
Same thing, but shorter.
|
|
Kept the accountserver_startup time for now, since it could be useful.
Reviewed-by: Stefan Beller
|