[Release] Guild Master Occupied FW Auto Title System [EASY CONTROL]

[EdwardTeach+-]

Originally Posted by Locklyon

This is badly coded.... Lemme address your problems:

 Spoiler

DECLARE @SiegeFType int
SET @SiegeFType = (SELECT FortressID FROM SRO_VT_SHARD.dbo._SiegeFortress)

The part above will return more than 1 value, it won't work.

 SET @CharID =
 (
 SELECT CharID FROM SRO_VT_SHARD.dbo._Char WHERE CharID IN 
 (
 SELECT CharID FROM SRO_VT_SHARD.dbo._GuildMember WHERE GuildID IN
 (
 SELECT GuildID FROM SRO_VT_SHARD.dbo._SiegeFortress 
 )
 AND MemberClass = '0' AND Permission = '-1' AND SiegeAuthority = '1'
 ))

Have you ever thought about using JOINs?

  DECLARE @HwanLevel INT = 
 (
  SELECT CharID FROM SRO_VT_SHARD.dbo._Char WHERE HwanLevel = @HwanNumJG OR HwanLevel = @HwanNumHT OR HwanLevel = @HwanNumBT OR HwanLevel = @HwanNumCON AND CharID NOT IN
  ( CharID
  )

This will return more than 1 value too, does this procedure even work?

Uhm I won't continue, this is pure cancer.

Here is a version I just created (for the lulz):

Procedure:

USE [SRO_VT_SHARD]
GO
/****** Object:  StoredProcedure [dbo].[_FortressWarTitle]    Script Date: 1/4/2017 9:45:17 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author:		Ace
-- =============================================
CREATE PROCEDURE [dbo].[_FortressWarTitle]
@FortressID TINYINT
AS

SET NOCOUNT ON;

DECLARE @FortressOwner INT = 0,
		@FortressTitle TINYINT = 0;

/* Setting stones */

SET @FortressOwner = (  SELECT	TOP 1 C.CharID
						FROM	SRO_VT_SHARD.._Char C
						JOIN	SRO_VT_SHARD.._GuildMember GM
						ON		C.CharID = GM.CharID
						JOIN	SRO_VT_SHARD.._SiegeFortress SF
						ON		GM.GuildID = SF.GuildID
						WHERE	SF.FortressID = @FortressID
						AND		GM.MemberClass = 0 AND GM.Permission = '-1'
						AND		GM.SiegeAuthority = 1 )

SET @FortressTitle = (	SELECT	HwanLevel
						FROM	SRO_VT_SHARD._FortressWarTitleContainer
						WHERE	FortressID = @FortressID )


IF @FortressOwner > 0 AND @FortressOwner IS NOT NULL AND @FortressTitle > 0 AND @FortressTitle IS NOT NULL
BEGIN
	UPDATE	SRO_VT_SHARD.._Char
	SET		HwanLevel = 0
	WHERE	HwanLevel = @FortressTitle

	UPDATE	SRO_VT_SHARD.._Char
	SET		HwanLevel = @FortressTitle
	WHERE	CharID = @FortressOwner
END

Table & Data:

USE [SRO_VT_SHARD]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[_FortressWarTitleContainer](
	[FortressID] [tinyint] NULL,
	[HwanLevel] [tinyint] NULL
) ON [PRIMARY]

GO


INSERT INTO _FortressWarTitleContainer
VALUES (1, 1), (6, 2), (4, 3), (3, 4)

How to use?

EXEC _FortressWarTitle 3

Fortress IDs:

• Jangan (Fortress ID: 1)
• Hotan (Fortress ID: 3)
• Bandit (Fortress ID: 6)
• Constantinople (Fortress ID: 4)

For automatic usage, I would suggest using SQL Server Agent (just create a new job to execute the procedure and done)

You can change the hwanlevels in _FortressWarTitleContainer (HwanLevel)

it's badly coded alright, i know it's not the best performance.
but yours is pure shit just tbh

DECLARE @CharID INT = NULL;

IF @CharID > 0 AND @CharID IS NOT NULL
	SELECT 1;
ELSE
	SELECT 2;

PURE SHIT LIKE 100% PURE MAN ITS YOUR MIND

Originally Posted by B1QB0SS :3

imagine having 300 players trying to enter fw (teleporting)

the procedure will be executed 3 hundred times AMAZING

 Spoiler

nice release i like (Y)

actually this is how the auto equipment works

IF (@EventID = 22) -- Character level up
BEGIN
    -- Character reached certain level
    IF (@Data2 = 13 OR @Data2 = 21 OR @Data2 = 29 OR @Data2 = 37 OR @Data2 = 47 OR @Data2 = 57 OR @Data2 = 69 OR @Data2 = 81)
    BEGIN

it's just the same executing shit every level up.
and this is how the Silk per hour system works

IF (@EventID = 4 OR @EventID = 6)
    BEGIN

every log in and log out it also executing shit every times
its nothing basically new but all we can do is adding more check points so we could make it execute as less as we can

[AceSpace]

Originally Posted by EdwardTeach+-

it's badly coded alright, i know it's not the best performance.
but yours is pure shit just tbh

DECLARE @CharID INT = NULL;

IF @CharID > 0 AND @CharID IS NOT NULL
	SELECT 1;
ELSE
	SELECT 2;

PURE SHIT LIKE 100% PURE MAN ITS YOUR MIND



actually this is how the auto equipment works

IF (@EventID = 22) -- Character level up
BEGIN
    -- Character reached certain level
    IF (@Data2 = 13 OR @Data2 = 21 OR @Data2 = 29 OR @Data2 = 37 OR @Data2 = 47 OR @Data2 = 57 OR @Data2 = 69 OR @Data2 = 81)
    BEGIN

it's just the same executing shit every level up.
and this is how the Silk per hour system works

IF (@EventID = 4 OR @EventID = 6)
    BEGIN

every log in and log out it also executing shit every times
its nothing basically new but all we can do is adding more check points so we could make it execute as less as we can

What? Let's not compare such a thing to silk per hour, Fortress war titles has to be updated only at certain time to avoid performance issues, having them executed at every teleport is purely called suicide and only a retarded developer would do such a thing and it's not like your procedure is even WORKING.

I doubt you understood any of what I wrote cause your reply doesn't make any sense.

Please stop, you make my eyes burn.

[EdwardTeach+-]

Originally Posted by Locklyon

What? Let's not compare such a thing to silk per hour, Fortress war titles has to be updated only at certain time to avoid performance issues, having them executed at every teleport is purely called suicide and only a retarded developer would do such a thing and it's not like your procedure is even WORKING.

I doubt you understood any of what I wrote cause your reply doesn't make any sense.

Please stop, you make my eyes burn.

what you mean by "such a thing?" isn't that still procedure running in the same place and the only difference between it is the EVENT ID VALUE And what you did is the same **** that made it running on a only event id without any other check point, and actually it took me 15 minute to code that so it may not be the best as i said but it works good dude why i see you mad if you don't like my kral system you simple leave my topic you a prostitute? I doubt you just here to flame and gain some posts like most of arab usual doing i thought its a lifestyle lol

[​Exo]

You guys both know that joins vs sub-querying at this amount of data isn't much of a difference right? However, since the amount is roughly going to be > 3000 in most cases, it doesn't make any difference. You're both querying against a very limited data source.
As of the 'IS NOT NULL' being evaluated first that just saves you the second evaluation in case it returned false, which also doesn't make any significant performance gain (if it makes any at all).

Originally Posted by EdwardTeach+-

what you mean by "such a thing?" isn't that still procedure running in the same place and the only difference between it is the EVENT ID VALUE And what you did is the same **** that made it running on a only event id without any other check point, and actually it took me 15 minute to code that so it may not be the best as i said but it works good dude why i see you mad if you don't like my kral system you simple leave my topic you a prostitute? I doubt you just here to flame and gain some posts like most of arab usual doing i thought its a lifestyle lol

EventID value resembles the event but you should also take into account the frequency of occurrence of that event you're using to trigger your procedure. For something as Fortress it's wiser to limit the execution times to that time of fortress. There's no need to keep updating the same tables over and over again. It's costly.

[EdwardTeach+-]

Originally Posted by ​Exo

You guys both know that joins vs sub-querying at this amount of data isn't much of a difference right? However, since the amount is roughly going to be > 3000 in most cases, it doesn't make any difference. You're both querying against a very limited data source.
As of the 'IS NOT NULL' being evaluated first that just saves you the second evaluation in case it returned false, which also doesn't make any significant performance gain (if it makes any at all).



EventID value resembles the event but you should also take into account the frequency of occurrence of that event you're using to trigger your procedure. For something as Fortress it's wiser to limit the execution times to that time of fortress. There's no need to keep updating the same tables over and over again. It's costly.

you may just simple add more check points so if it's not exists it won't just execute it as you said it's costly aitee

[AceSpace]

Originally Posted by EdwardTeach+-

you may just simple add more check points so if it's not exists it won't just execute it as you said it's costly aitee

yes right yes yes

CANCER THIS IS CANCER! I QUIT.

[​Exo]

Originally Posted by EdwardTeach+-

you may just simple add more check points so if it's not exists it won't just execute it as you said it's costly aitee

Well you could use Date(Part/Name) functions to limit the execution BUT that will also keep checking with every teleport (I didn't read your procedure, I am just assuming you're using teleport eventid as a trigger) which will keep checking for date. Basically there will be some sort of evaluation with every event id. So it's still not the optimal solution.

[B1Q]

Originally Posted by ​Exo

Well you could use Date(Part/Name) functions to limit the execution BUT that will also keep checking with every teleport (I didn't read your procedure, I am just assuming you're using teleport eventid as a trigger) which will keep checking for date. Basically there will be some sort of evaluation with every event id. So it's still not the optimal solution.

he's using the tp eventid but i think adding the exec line at the top of the _SiegeFortressFinished (not sure if it's functional) procedure will be much better as the name suggests (Siege Fortress Finished) that means it will be executed when the fortress war ends (not 100% sure)

[​Exo]

Originally Posted by B1QB0SS :3

he's using the tp eventid but i think adding the exec line at the top of the _SiegeFortressFinished (not sure if it's functional) procedure will be much better as the name suggests (Siege Fortress Finished) that means it will be executed when the fortress war ends (not 100% sure)

Yeh something like that would be way better than this blind approach.

[EdwardTeach+-]

Originally Posted by ​Exo

Well you could use Date(Part/Name) functions to limit the execution BUT that will also keep checking with every teleport (I didn't read your procedure, I am just assuming you're using teleport eventid as a trigger) which will keep checking for date. Basically there will be some sort of evaluation with every event id. So it's still not the optimal solution.

well i think it's really really really simple no need for anything really major to do i was thinking about we just make a simple check point like we could check the "SiegeFortress" Table like for ex:
we declare the @SiegeFortressGuildID to select GuildID from SiegeFortressWar
and we we'll make a table EX "TitleSentCheckPoint"
that store and record every GuildID that got the title already and add a column SENT AND VALUE WILL BE ((0)) FOR EVERYONE SO IF YOU GOT THE TITLE AND YOUR GUILD WON THE FORTRESS WAR YOU VALUE WILL BE CHANGED TO ((1)) IN THE END OF THE PROCEDURE. SO THE CHECK POINT WILL BE ON THE DECLARE

IF
(@EVENTID= '9')
OR
(@EventID='11') AND @SiegeFortressGuildID >0 AND @TitleSentCheckPoint = 0
BEGIN
EXEC SRO_VT_SHARDLOG..GuildMasterAutoTitle @CharID
end
AND WE'LL MAKE INSIDE THE PROCEDURE
UPDATE the check point column SENT TO 1 ONCE THE PROCEDURE EXECUTED
SO THE PROCEDURE WILL NOT EVER RUN IF THERE IS NO NEW GUILDID INSERTED WITH SENT COLUMN = 0

ahh, or just like @b1qb0ss said adding it on a procedure like that game server only execute it when the fw finished