Configuration questions for potential new server (huge post!)

[demonstar55]

Disabling consider you can just make Client::Handle_OP_Consider in zone/client_packet.cpp do nothing. And I don't think there is any way around this with MQ2, the client knows nothing of the mobs faction until the server responds to the OP_Consider packet. Disabling groups should be similar, I'm just not sure where in the source group chat is :P Same with the shout change.

KLS recently pushed changes that adds a base data table which also comes with a program to easily generate the SkillCaps.txt and other files after you change them in the database to distribute to players.

EDIT: In zone/client.cpp Client::ChannelMessageReceived is the function that would need to be edited for the chat changes I think :P

[rencro]

Here is how I disable "tell, ooc, and auction", same priciple can be applied for group...

diff --git a/zone/client.cpp b/zone/client.cpp
index 533f8b5..750ff73 100644
--- a/zone/client.cpp
+++ b/zone/client.cpp
@@ -872,6 +872,9 @@ void Client::ChannelMessageReceived(uint8 chan_num, uint8 language, uint8 lang_s
 		break;
 	}
 	case 4: { // Auction
+		Message(13, "Auction is disabled."); //rencro
+			return;
+
 		if(RuleB(Chat, ServerWideAuction))
 		{
 			if(!global_channel_timer.Check())
@@ -911,6 +914,9 @@ void Client::ChannelMessageReceived(uint8 chan_num, uint8 language, uint8 lang_s
 		break;
 	}
 	case 5: { // OOC
+		Message(13, "OOC is disabled."); //rencro
+			return;
+
 		if(RuleB(Chat, ServerWideOOC))
 		{
 			if(!global_channel_timer.Check())
@@ -966,6 +972,9 @@ void Client::ChannelMessageReceived(uint8 chan_num, uint8 language, uint8 lang_s
 		break;
 	}
 	case 7: { // Tell
+		Message(13, "Tell system is disabled."); //rencro
+			return;
+
 			if(!global_channel_timer.Check())
 			{
 				if(strlen(targetname) == 0)

A lazy way of doing it but gets the job done..

[Lucia Moore]

Originally Posted by rencro

Here is how I disable "tell, ooc, and auction", same priciple can be applied for group...

diff --git a/zone/client.cpp b/zone/client.cpp
index 533f8b5..750ff73 100644
--- a/zone/client.cpp
+++ b/zone/client.cpp
@@ -872,6 +872,9 @@ void Client::ChannelMessageReceived(uint8 chan_num, uint8 language, uint8 lang_s
 		break;
 	}
 	case 4: { // Auction
+		Message(13, "Auction is disabled."); //rencro
+			return;
+
 		if(RuleB(Chat, ServerWideAuction))
 		{
 			if(!global_channel_timer.Check())
@@ -911,6 +914,9 @@ void Client::ChannelMessageReceived(uint8 chan_num, uint8 language, uint8 lang_s
 		break;
 	}
 	case 5: { // OOC
+		Message(13, "OOC is disabled."); //rencro
+			return;
+
 		if(RuleB(Chat, ServerWideOOC))
 		{
 			if(!global_channel_timer.Check())
@@ -966,6 +972,9 @@ void Client::ChannelMessageReceived(uint8 chan_num, uint8 language, uint8 lang_s
 		break;
 	}
 	case 7: { // Tell
+		Message(13, "Tell system is disabled."); //rencro
+			return;
+
 			if(!global_channel_timer.Check())
 			{
 				if(strlen(targetname) == 0)

A lazy way of doing it but gets the job done..

Is that an entire .cpp file that I can just copy/paste into my source, or do I have to plug that in somewhere?

As I said, I know some things about programming, but I don't wanna FUBAR my code unless I can figure out where I FUBAR'd it at.

[rencro]

Originally Posted by Lucia Moore

Is that an entire .cpp file that I can just copy/paste into my source, or do I have to plug that in somewhere?

As I said, I know some things about programming, but I don't wanna FUBAR my code unless I can figure out where I FUBAR'd it at.

Thats a diff with my changes that would modify your code, but you want it for groups so you would be better going into zone/client.cpp and making the edits there yourself...

A word of warning..Once you start modifying things, it will be a chore to keep up with the tip release, so you may need to draw a line in the sand and just work from your source exclusively and perhaps cherry pick any new releases to the code manually, if at all....

Any ways:

About line 743 of zone/client.cpp

void Client::ChannelMessageReceived(uint8 chan_num, uint8 language, uint8 lang_skill, const char* orig_message, const char* targetname) {
.
.
.
	case 2: { // GroupChat
		Raid* raid = entity_list.GetRaidByClient(this);
		if(raid) {
			raid->RaidGroupSay((const char*) message, this);
			break;
		}

		Group* group = GetGroup();
		if(group != nullptr) {
			group->GroupMessage(this,language,lang_skill,(const char*) message);
		}
		break;
	}

Not sure about the raid but could try this:

void Client::ChannelMessageReceived(uint8 chan_num, uint8 language, uint8 lang_skill, const char* orig_message, const char* targetname) {
.
.
.
	case 2: { // GroupChat
		Message(13, "Group chat disabled."); //remove group chat
			return;

                Raid* raid = entity_list.GetRaidByClient(this);
		if(raid) {
			raid->RaidGroupSay((const char*) message, this);
			break;
		}

		Group* group = GetGroup();
		if(group != nullptr) {
			group->GroupMessage(this,language,lang_skill,(const char*) message);
		}
		break;
	}

Then recompile and test. If you dont like the "Group chat is disabled message, then remove it -)

[Lucia Moore]

I see. So, if I'm understanding this correctly, could I do something like this?

(Note that I can't actually see the code right now because I'm at work, so my exact syntax may be wrong)

{ // GroupChat
		Raid* raid = entity_list.GetRaidByClient(this);
		if(raid) {
			raid->Say(this,language,lang_skill,(const char*) message);
			break;
		}

		Group* group = GetGroup();
		if(group != nullptr) {
			group->Say(this,language,lang_skill,(const char*) message);
		}
		break;

In other words, just make it so that anything you say in /group comes out as /say instead?

[rencro]

Not as in that example as say is not a member of Raid or Group, but if you like you can repipe it through say, yes, there are actually few limits in what you can do, you just need to "do" it....

I went the lazy route by just disabling the feature and letting the players know it was disabled so they would use other methods, but re-writing it to use the current system as close as possible is also viable...

[Lucia Moore]

Responding to everyone here. (Thanks so much for the replies, by the way!)

I believe all spell data was moved into the database last year.

Does that mean that I don't need to distribute any spell data files? Meaning, if I change a spell in my database, will it appear with the new stats, name, etc. on other peoples' clients when they play there, or do they still have to download something?

As for the things requiring source changes:

Some of those are pretty simple, right? Like, in the source for PvP damage mod, it must say somewhere something like "totalDamage * 0.66" or something similar, I assume, or maybe it's a constant defined somewhere like "PVP_DMG_MODIFIER" or something?

Originally Posted by demonstar55

Disabling consider you can just make Client::Handle_OP_Consider in zone/client_packet.cpp do nothing. And I don't think there is any way around this with MQ2, the client knows nothing of the mobs faction until the server responds to the OP_Consider packet. Disabling groups should be similar, I'm just not sure where in the source group chat is :P Same with the shout change.

KLS recently pushed changes that adds a base data table which also comes with a program to easily generate the SkillCaps.txt and other files after you change them in the database to distribute to players.

EDIT: In zone/client.cpp Client::ChannelMessageReceived is the function that would need to be edited for the chat changes I think :P

My desire to remove /consider wasn't due to faction concerns, it's so that players cannot determine one anothers' levels. However, since level information still gets sent to clients, MQ2 can probably pull it using the ${Target.Level} variable. The Firiona Vie server on live had a modified /consider where people were either green (more than 5 below), white (within 5), or red (more than five over), and you could still pull their exact level using MQ2.

It's a minor concern, anyway. I intend to remove the effects of level on combat and spell resists, and with a cap of 20, level won't be as important as attributes, anyway. I hope to make it so that ATK, AC, and skills are the only factor in determining combat effectiveness.

[rencro]

Realistic NPCs with improved AI
Assuming it can be done, NPCs will fight like real players. Their damage will be based on their current weapon, and they'll hit like a player of that level, too. Hopefully, I can also get help implementing AI that makes casters root melee and back off, snare kite, and other tactics that a PC might use in a fight. How effective this will be is still up in the air, as I myself am not a programmer and am not sure how feasible it is.

I use a combination of Xachary's is evil code, davood's shroud races, and mq2 to make "bot" characters with access level 100 that will pvp the players when they enter a certain zone, which is monitored via WorldWide emotes. This solves your "hit like a player" because they are players. I have one windows box setup with 6 wineq sessions with "stick" graphics and a minimalist eqclient.ini load on them, each of them a different race that is "evil" and can pvp any player that is not "evil", of course they "cheat because they have access to gm commands but all "npcs" cheat.... Still working on the quest files for this to make a chest spawn on the death of the "bot"..Its a big WIP....Only issue is when the server goes down I have to log all the "bots" back in. Eventually I want to make them act like bosses and have assistance from zone npcs against the players.../derail off

[Lucia Moore]

Originally Posted by rencro

I use a combination of Xachary's is evil code, davood's shroud races, and mq2 to make "bot" characters with access level 100 that will pvp the players when they enter a certain zone, which is monitored via WorldWide emotes. This solves your "hit like a player" because they are players. I have one windows box setup with 6 wineq sessions with "stick" graphics and a minimalist eqclient.ini load on them, each of them a different race that is "evil" and can pvp any player that is not "evil", of course they "cheat because they have access to gm commands but all "npcs" cheat.... Still working on the quest files for this to make a chest spawn on the death of the "bot"..Its a big WIP....Only issue is when the server goes down I have to log all the "bots" back in. Eventually I want to make them act like bosses and have assistance from zone npcs against the players.../derail off

That's an interesting idea, but far too excessive for me. Really, all I want is NPCs that behave a little more intelligently than normal. Chanters that mez extra targets, casters rooting attackers and then backing off, that sort of stuff.

The hitting part I can probably work around simply by setting their minimum/maximum damage to be roughly equal to whatever weapon I make them spawn with.