Questions about the source

[backlog]

Does the JobData really needs stats and start map attributes? Custom settings?

I was thinking in moving the StartMap, StartX, StartY, StartZ to a conf or a db file, instead of the job db file, so I could set a start map for Klaipeda and Orsha on Character Creation.

However I would like your opinion if I should do it and, If I should, which one should be used.

[exec]

That was added before iCBT2 when there were no different starting towns yet. Since the client had those values for every job I assumed you were eventually meant to start in different cities based on your job. You're right, that code is obsolete now. Adding it to a conf file, like login, would be one option, another would be to create a db, in case more starting cities are added at some point. If there were like 8 starting places, having them in a db would make for much cleaner code.

Exaggerated example:

var startingCity = (StartingCity)packet.GetInt();
switch(startingCity)
{
  case StartingCity.City1:
    map = LoginServer.Instance.Conf.Login.StartMapCity1;
    x = LoginServer.Instance.Conf.Login.StartXCity1;
    y = LoginServer.Instance.Conf.Login.StartYCity1;
    z = LoginServer.Instance.Conf.Login.StartZCity1;
    break;
  case StartingCity.City2:
    map = LoginServer.Instance.Conf.Login.StartMapCity2;
    x = LoginServer.Instance.Conf.Login.StartXCity2;
    y = LoginServer.Instance.Conf.Login.StartYCity2;
    z = LoginServer.Instance.Conf.Login.StartZCity2;
    break;
  case StartingCity.City3:
    map = LoginServer.Instance.Conf.Login.StartMapCity3;
    x = LoginServer.Instance.Conf.Login.StartXCity3;
    y = LoginServer.Instance.Conf.Login.StartYCity3;
    z = LoginServer.Instance.Conf.Login.StartZCity3;
    break;
  // ...
}

vs

var startingCity = (StartingCity)packet.GetInt();
var data = LoginServer.Instance.Data.StartingCitys.Find(startingCity);
map = data.Map;
x = data.X;
y = data.Y;
z = data.Z;

 

[backlog]

About the stats, should them be moved to a StatsDb?

 

[Serializable]
	public class StatData
	{
		public int Id { get; set; }
		public int Str { get; set; }
		public int Con { get; set; }
		public int Int { get; set; }
		public int Spr { get; set; }
		public int Dex { get; set; }
	}

	/// <summary>
	/// Stat database, indexed by job id.
	/// </summary>
	public class StatDb : DatabaseJsonIndexed<int, StatData>
	{
		public StatData Find(Job job)
		{
			return this.Find((int)job);
		}

		protected override void ReadEntry(JObject entry)
		{
			entry.AssertNotMissing("jobId", "str", "con", "int", "spr", "dex");

			var info = new StatData();

			info.Id = entry.ReadInt("jobId");
			info.Str = entry.ReadInt("str");
			info.Con = entry.ReadInt("con");
			info.Int = entry.ReadInt("int");
			info.Spr = entry.ReadInt("spr");
			info.Dex = entry.ReadInt("dex");

			this.Entries[info.Id] = info;
		}
	}

 

[exec]

What do we have to gain by moving the stats in your opinion? I don't see an advantage right now.

[backlog]

Different classes have different initial stats like HP, SP, Phy Atk, Magic Atk, etc, on level 1.

So I would create a stats database to save those different stats of each class.

Swordsman example:

{ jobId: 1001, str: 8, con: 9, int: 3, spr: 3, dex: 6, hp: 980, maxHp: 980, sp: 57, maxSp: 57, maxStamina: 25000, hpRecovery: 15, spRecovery: 6, minPhysicalAttack: 9, maxPhysicalAttack: 9, minSecondaryPhysicalAttack: 9, maxSecondaryPhysicalAttack: 9, minMagicAttack: 6, maxMagicAttack: 6, aoeAttackRatio: 4, accuracy: 8, blockPenetration: 3, criticalAttack: 8, criticalRate: 9, physicalDefense: 3, magicDefense: 3, aoeDefenseRatio: 1, evasion: 7, criticalResistance: 10, movimentSpeed: 30, maxCarryWeight: 5185 },

PS: In the screenshot, these are not the true stats, because I completed some collections. I would have to use an account that has no collections completed and is not using a token to get the real numbers.

 

Edited May 8, 2016 by huenato

[exec]

On 5/8/2016 at 7:46 PM, huenato said:

Different classes have different initial stats like HP, SP, Phy Atk, Magic Atk, etc, on level 1.

Yes, but why separate that from the actual job data?

Btw, I think we shouldn't create base stats for everything, but only for stats that actually have a base value. For example, weight is completely calculated to my knowledge. You may check the client data for formulas.

[backlog]

On 5/8/2016 at 10:33 PM, exec said:

Yes, but why separate that from the actual job data?

Btw, I think we shouldn't create base stats for everything, but only for stats that actually have a base value. For example, weight is completely calculated to my knowledge. You may check the client data for formulas.

Oh yea, I completely forgot that detail. Then I will check those later.

I asked that because the stats are repeating for each job on job data.

[exec]

11 hours ago, huenato said:

I asked that because the stats are repeating for each job on job data.

Ah, you're absolutely right, that is a little redundant. Could there be any situation where we might need that? I haven't played the game enough to know.

[backlog]

Nothing is coming to mind right now. I'll tell once I have some new things to discuss. :­)