Talendrys

[quote=madmax]Oh really? We should really make these things give an error that tells you what to use instead of 0x40 which i have no idea lol.[/quote]

By the way, 0x40 is 64 (recommended, green).

While 40 is the combination of 32 + 8 (New players + Unknown flag) but I think that new players flag is a blue recommended.

And I would not say that the core needs to tell you to put something it doesn't know... however, you could read the documentation : [url]https://getmangos.eu/wiki/Reference%20Information/DB/realm/realmlist.md#realmflags[/url]

;-)

I would suggest to implement JaNGOS Database structure for the realmlist table. In JaNGOS, you set 0 or 1 to flags instead of an integer which is then interpreted as an hexadecimal value for the game.

Several other fields have exactly the same issue in the MaNGOS database: playerBytes, item_data, ...

According to myself (and maybe others), it is actually a stupid idea to store an integer which has several flag meaning into the database (Especially whenever you can combine them).

Database:

`id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'ID of the realm.',
`name` varchar(32) NOT NULL DEFAULT '' COMMENT 'Name of the realm.',
`address` varchar(32) NOT NULL DEFAULT '127.0.0.1' COMMENT 'Address of the realm, may be a name of an ip.',
`port` int(11) NOT NULL DEFAULT '8085' COMMENT 'Listen port of the realm.',
`fk_realmtype` int(11) NOT NULL COMMENT 'Foreign key to the Realm Type.',
`fk_timezone` int(11) NOT NULL COMMENT 'Foreign key to the timezone.',
`population` float NOT NULL DEFAULT '0' COMMENT 'Population calculated from (playerCount / maxPlayerCount * 2)',
`maxPlayers` int(11) NOT NULL DEFAULT '1000' COMMENT 'The maximum number of players allowed on this realm.',
`countPlayers` int(11) NOT NULL DEFAULT '0' COMMENT 'The number of players actually created on this realm.',
[COLOR="#FF0000"][B] `invalid` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Means that this realm is invalid and must not be shown to the client.',
`offline` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Means that this realm is offline.',
`showversion` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Means that the version of this realm must be shown to the client.',
`newplayers` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Means that only the new players may join this realm.',
`recommended` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Display the recommended option in the client.',[/B][/COLOR]
PRIMARY KEY (`id`),
KEY `fk_realm_type_idx` (`fk_realmtype`),
KEY `fk_realm_timezone_idx` (`fk_timezone`),
CONSTRAINT `fk_realm_timezone` FOREIGN KEY (`fk_timezone`) REFERENCES `realmtimezone` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT `fk_realm_type` FOREIGN KEY (`fk_realmtype`) REFERENCES `realmtype` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION

Software code:
/**
* This method is converting the realm flags into a single integer.
* @param r The realm for which the flags needs to be converted.
* @return The integer value corresponding to the flags.
*/
private int convertFlagsToInt(Realm r) {
int flags = 0;
flags+=(r.isInvalid() ? 1 : 0);
flags+=(r.isOffline() ? 2 : 0);
flags+=(r.isShowversion() ? 4 : 0);
// flags+=(0*8); // Unknown flag
// flags+=(0*16); // Unknown flag
flags+=(r.isNewplayers() ? 32 : 0);
flags+=(r.isRecommended() ? 64 : 0);
// flags+=(0*128); // unknown flag

return flags;
}

Well, for me, the discussion is rather: do we allow it ?

This is not like it is blizzlike... So is it Worth to do that effort ?

Which part of SM did you try ?

At least, you have the file where it happened.

I am not saying something else than you though...

"DB-Connection strategy" actually means a real DB layer with connection management... Never said you don't have to check if you connection is open.

Although it will certainly fix the issue, I don't think this is a good idea. You will only hack-fix the code by doing this everywhere.

If you want to fix it properly, you need to figure out the complete DB-connection strategy of Mangos and, if there's none, put one in place.

I'm convinced that with a simple singleton-pattern, you can achieve it efficiently.

Deleting data from DBC is forbidden. :-)

Ok, you are true. Connection pooling is something businesses don't do.

All the world process uses a DB connection. I can also tell you that SQL queries are sometimes queued and flushed when the server has time.

It's a common practice to keep a pool of connections open, this is because establishing a connection is CPU-consuming. Doing what you suggest is a bad idea as-is. On the other side, identifying the component that doesn't re-use the connection it has open to see whether it doesn't lack a proper pooling mechanism makes more sense.

By the way, if you run the world, connections will be made but if nobody is playing on it, the problem does not occur nether because you never reach the time-out.

Another idea is to handle properly a DB-side timeout.

Does istappedby including the check that the mob was ont grey ?

So, let's theorycraft a bit.

235 / 5 = 47.

You must have glance hitting mobs level 50 as well. Up your weapon skills to, at least, 255 and retry.

For me, so far it's working as intended.

It's inside the core already. I've worked on it to rewrite how the Imp is working (first one) because for Mangos, all pets are generic pets (which is incorrect) and have the same behavior.

Regarding the mana/health generation, in the past, it was going well but the amount was too low (and I never found the original data). I don't know what has been changed.. that it doesn't work now.

The SD2 script is bugged. Eluna tasks :-)

Hi Xen',

It's not about your level but your weapon level. Can you give more data for theorycrafting this ? :-)

The PetAI script need an overhaul .. that's clear.

Glance appears once the monster has 3 or plus level above your weapon skill.

E.g:

200 in weapon skill means that attacks against monster level 43+ will have a high chance to get a "glance" result.

wave isn't hi. :-)

What about glance ?

UPDATE creature_template, creature_template_classlevelstats SET PowerMultiplier = MinLevelMana/BaseMana
WHERE creature_template_classlevelstats.Level = MinLevel and BaseMana != 0;

UPDATE creature_template, creature_template_classlevelstats SET HealthMultiplier = MinLevelHealth/BaseHealthExp0
WHERE creature_template_classlevelstats.Level = MinLevel;

It was something like this for health/mana.

Don't rewrite the wheel... This has been already analyzed and the issue was because everything to make calculation about monster hp/mana is ready within the DB but not populated (so basically they all have the same multiplier).

Just update your DB with the correct SQL query and that will be solved. (Unfortunately, I don't remind it by heart... maybe someone can find it back since I posted it on Skype channel).

Shockwave in Vanilla ? Surprising.

I don't think it has been added. I think the default parameter may have been corrected somehow.

Do you have Rate.Corpse.Decay.Looted = 0 in mangosd.conf ?

If yes, change it for another value. :-)

New commit: [url]https://github.com/Warkdev/server/commit/5bd920fc573f94f56c39a8e99b4ee284cdd52e62[/url]