[DiscordArchive] Can I vote:don't because players should know what their server is?
[DiscordArchive] Can I vote:don't because players should know what their server is?
Original source
```cpp
/* 5 */
PlayerInfo const* ObjectMgr::GetPlayerInfo(uint32 race, uint32 class_) const
{
/* 6 */
if (race >= MAX_RACES)
return nullptr;
if (class_ >= MAX_CLASSES)
return nullptr;
/* 7 */
auto const& info = _playerInfo[race][class_];
if (!info)
return nullptr;
return info.get();
}
/* 8 */
std::unique_ptr<PlayerInfo> _playerInfo[MAX_RACES][MAX_CLASSES];
/* 9 */
#define MAX_RACES 12
/* 10 */
#define MAX_CLASSES 12
/* 11 */
void ObjectMgr::LoadPlayerInfo()
{
// Load playercreate
{
uint32 oldMSTime = getMSTime();
// 0 1 2 3 4 5 6
QueryResult result = WorldDatabase.Query("SELECT race, class, map, zone, position_x, position_y, position_z, orientation FROM playercreateinfo");
/* ... */
}
```
rektbyfaith
06-27-2021, 03:22 AM #11Archived author: p620 • Posted: 2021-06-27T03:22:41.110000+00:00
Original source
```cpp
/* 5 */
PlayerInfo const* ObjectMgr::GetPlayerInfo(uint32 race, uint32 class_) const
{
/* 6 */
if (race >= MAX_RACES)
return nullptr;
if (class_ >= MAX_CLASSES)
return nullptr;
/* 7 */
auto const& info = _playerInfo[race][class_];
if (!info)
return nullptr;
return info.get();
}
/* 8 */
std::unique_ptr<PlayerInfo> _playerInfo[MAX_RACES][MAX_CLASSES];
/* 9 */
#define MAX_RACES 12
/* 10 */
#define MAX_CLASSES 12
/* 11 */
void ObjectMgr::LoadPlayerInfo()
{
// Load playercreate
{
uint32 oldMSTime = getMSTime();
// 0 1 2 3 4 5 6
QueryResult result = WorldDatabase.Query("SELECT race, class, map, zone, position_x, position_y, position_z, orientation FROM playercreateinfo");
/* ... */
}
```
Original source
**Disclaimer:** The code above was extracted from the latest (at the time of the extraction) revision of the `3.3.5` branch of `TrinityCore`.
`---`
At `1` a homebind load is attempted during a player load. At `2` a `PlayerInfo` instance gets fetched with `5` and the fetch result undergoes immediate validation. If any of the checks at `6` fail - the validation will fail as well, which will result in an error message being issued and the entire homebind loading process failing. Given that the race and the class indices requested satisfy the condition of being less than *12* (as it is shown at `9` and `10`), the actual `_playerInfo` (with the relevant declaration referenced under `8`) will be returned. This info is formed through the means described at `11` and evidently originates from the corresponding record within the `world.playercreateinfo` table.
Now, at `3` it becomes obvious that only a query that has actually yielded a match and provided a **coherent** homebind location will be accepted as a loading source. Otherwise, the code at `4` will be executed which will utilize the aforementioned `PlayerInfo` instance as an alternate loading source. Its `mapId`, `areaId`, `positionX`, `positionY` and `positionZ` will seed the initial homebind and consequently become the "anchoring" location a hearthstone will reference.
Thus, setting up the desired configuration within `world.playercreateinfo` will automatically create an initial hearthstone "anchor". Changing this behavior would require modifying the core.
`---`
*Having now to glance over all this code I assert the complete absence of regret from quitting wow modding. An array of* **immutable** *almost trivial objects (if not for the same exact nonsense being nested within) wrapped with* `std::unique_ptr<>` *- who would even dare to deem such an abomination as a tolerable idea?*
rektbyfaith
06-27-2021, 03:23 AM #12Archived author: p620 • Posted: 2021-06-27T03:23:45.104000+00:00
Original source
**Disclaimer:** The code above was extracted from the latest (at the time of the extraction) revision of the `3.3.5` branch of `TrinityCore`.
`---`
At `1` a homebind load is attempted during a player load. At `2` a `PlayerInfo` instance gets fetched with `5` and the fetch result undergoes immediate validation. If any of the checks at `6` fail - the validation will fail as well, which will result in an error message being issued and the entire homebind loading process failing. Given that the race and the class indices requested satisfy the condition of being less than *12* (as it is shown at `9` and `10`), the actual `_playerInfo` (with the relevant declaration referenced under `8`) will be returned. This info is formed through the means described at `11` and evidently originates from the corresponding record within the `world.playercreateinfo` table.
Now, at `3` it becomes obvious that only a query that has actually yielded a match and provided a **coherent** homebind location will be accepted as a loading source. Otherwise, the code at `4` will be executed which will utilize the aforementioned `PlayerInfo` instance as an alternate loading source. Its `mapId`, `areaId`, `positionX`, `positionY` and `positionZ` will seed the initial homebind and consequently become the "anchoring" location a hearthstone will reference.
Thus, setting up the desired configuration within `world.playercreateinfo` will automatically create an initial hearthstone "anchor". Changing this behavior would require modifying the core.
`---`
*Having now to glance over all this code I assert the complete absence of regret from quitting wow modding. An array of* **immutable** *almost trivial objects (if not for the same exact nonsense being nested within) wrapped with* `std::unique_ptr<>` *- who would even dare to deem such an abomination as a tolerable idea?*
Original source
Again, in TrinityCore this comes from here:
```cpp
void WorldSession::HandlePlayerLogin(LoginQueryHolder const& holder)
{
/* ... */
// send server info
if (sWorld->getIntConfig(CONFIG_ENABLE_SINFO_LOGIN) == 1)
chH.PSendSysMessage(GitRevision::GetFullVersion());
```
And it indeed may be disabled by editing the corresponding configuration file.
And no, this motd contains a rather sensitive information and potentially endangers the serving host at a much greater severity than any of its clients. So yes, it would be wise to disable it for players (and all non-developers, actually). TrinityCore most likely keeps it enabled by default due to *envisioning* itself as an educational project, so a non-hostile environment is assumed.
rektbyfaith
06-27-2021, 03:36 AM #13Archived author: p620 • Posted: 2021-06-27T03:36:05.565000+00:00
Original source
Again, in TrinityCore this comes from here:
```cpp
void WorldSession::HandlePlayerLogin(LoginQueryHolder const& holder)
{
/* ... */
// send server info
if (sWorld->getIntConfig(CONFIG_ENABLE_SINFO_LOGIN) == 1)
chH.PSendSysMessage(GitRevision::GetFullVersion());
```
And it indeed may be disabled by editing the corresponding configuration file.
And no, this motd contains a rather sensitive information and potentially endangers the serving host at a much greater severity than any of its clients. So yes, it would be wise to disable it for players (and all non-developers, actually). TrinityCore most likely keeps it enabled by default due to *envisioning* itself as an educational project, so a non-hostile environment is assumed.
Original source
there's nothing particularily "sensitive" about a core revision, unless you are sitting at an older rev with security issues, which a playerbase should know of
rektbyfaith
06-27-2021, 03:53 AM #14Archived author: tester • Posted: 2021-06-27T03:53:04.257000+00:00
Original source
there's nothing particularily "sensitive" about a core revision, unless you are sitting at an older rev with security issues, which a playerbase should know of
Original source
any pen tester type of person would just test any and all attacks, old to new and see if anything sticks
rektbyfaith
06-27-2021, 03:54 AM #15Archived author: tester • Posted: 2021-06-27T03:54:25.628000+00:00
Original source
any pen tester type of person would just test any and all attacks, old to new and see if anything sticks
Original source
them knowing it specifically in that regard would do them less good
rektbyfaith
06-27-2021, 03:54 AM #16Archived author: tester • Posted: 2021-06-27T03:54:36.544000+00:00
Original source
them knowing it specifically in that regard would do them less good
Original source
just a couple checks into recent commits into whatever bug you found, you would know it works in any rev between there and the next commit where it changed
rektbyfaith
06-27-2021, 03:55 AM #17Archived author: tester • Posted: 2021-06-27T03:55:31.085000+00:00
Original source
just a couple checks into recent commits into whatever bug you found, you would know it works in any rev between there and the next commit where it changed
Original source
First of all, one would have to identify the core itself. Than the revision. Than the underlying OS. And "pen testing" won't necessarily look like running a script that unleashes a zoo of exploit probers at the target host. The process can easily be quite delicate, especially with the projects aware of the possibility of becoming such targets. Not to mention that the playerbase actually risks **nothing** except for their virtual riches. For the serving host to become a source of infection the clients themselves must exhibit a vulnerability.
rektbyfaith
06-27-2021, 04:03 AM #18Archived author: p620 • Posted: 2021-06-27T04:03:45.498000+00:00
Original source
First of all, one would have to identify the core itself. Than the revision. Than the underlying OS. And "pen testing" won't necessarily look like running a script that unleashes a zoo of exploit probers at the target host. The process can easily be quite delicate, especially with the projects aware of the possibility of becoming such targets. Not to mention that the playerbase actually risks **nothing** except for their virtual riches. For the serving host to become a source of infection the clients themselves must exhibit a vulnerability.
Original source
there are only 2 real active cores at the current time. that isn't any surprise. the revision, above. fair i suppose on the OS, but any server with > a couple hundred tend to run on linux due to a reduced cost for the same resource. and it only gives a unix/windows, not a specfic build of windows for somethign OS based such as that. and while i do wish that were true, too many players use real usernames/passwords/emails they use for their banks/other things.
rektbyfaith
06-27-2021, 04:05 AM #19Archived author: tester • Posted: 2021-06-27T04:05:23.482000+00:00
Original source
there are only 2 real active cores at the current time. that isn't any surprise. the revision, above. fair i suppose on the OS, but any server with > a couple hundred tend to run on linux due to a reduced cost for the same resource. and it only gives a unix/windows, not a specfic build of windows for somethign OS based such as that. and while i do wish that were true, too many players use real usernames/passwords/emails they use for their banks/other things.
Original source
and a pen tester could guestimate a general revision just by going to the oldest message about a server, there's really only 2 groups, those who either never update or those who stay close to whatever a latest commit is, so it gives you a pretty close guess
rektbyfaith
06-27-2021, 04:06 AM #20Archived author: tester • Posted: 2021-06-27T04:06:38.257000+00:00
Original source
and a pen tester could guestimate a general revision just by going to the oldest message about a server, there's really only 2 groups, those who either never update or those who stay close to whatever a latest commit is, so it gives you a pretty close guess
1 Guest(s)
1 Guest(s)