NosCore Emulator

repository·master·Indexed 41 days ago

https://github.com/noscoreio/noscore

An open-source emulator project and ecosystem including Packets, Dao, Algorithm, and parser tooling designed for educational and proof-of-concept purposes. Built with .NET 10 and PostgreSQL 17.2, the system consists of several services including master, world, and login, with specialized data structures like BCard.dat for managing game effects, buffs, and debuffs.

Tokens
48.1K
Snippets
73
Records
92
Agent score
51%

What's inside NosCore

  1. Identify BCard.dat effect groups

    master

    Effects in BCard.dat are grouped by their first ID column. Based on the provided segment, the following groups exist:

    • 50: HugeSnowman effects (environmental/area damage and buffs).
    • 51: Drain effects (HP transfer, Sun Wolf interactions).
    • 52: BossMonsters skills (Sun Wolf related, HP scaling, resurrection).
    • 53: LordHatus effects (location damage, Sun Wolf commands, HP/MP restoration, damage caps).
    • 54: LordCalvinas effects (location damage, dragon summons: Fire, Ice, Moonlight).
    • 55: SeSpecialist effects (buff/damage thresholds, movement auras, HP scaling, light dragon summons).
    • 56: FourthGlacernonFamilyRaid effects (field damage, Rage bar HP, PvP resistances, invisibility).
    • 57: SummonedMonsterAttack effects (damage scaling, debuff removal, HP/MP consumption, movement speed).
    • 58: BearSpirit effects (MP/HP scaling, Soulripper damage storage, monster-specific damage).
    • 59: SummonSkill effects (summoning probabilities and timed summons).
  2. Understand the Item.dat file structure

    master

    The Item.dat file defines item properties through several data sections: FLAG, INDEX, NAME, and VNUM. These sections are used to populate item DTOs (Data Transfer Objects) with attributes like item type, name, price, and various boolean flags.

    Data Sections

    • FLAG: A 25-bit boolean field containing item properties (e.g., tradability, warehouse status).
    • INDEX: Contains structural information like ItemSubType and EquipmentSlot.
    • NAME: Contains the NameI18NKey for localization.
    • VNUM: Contains the VNum (item ID) and Price (NPC shop sell price).
    • Computed Fields: Many properties (like DamageMaximum, Hp, Element) are derived from various offsets within the DATA array depending on the ItemType.
    	FLAG	0	0	0	{IsSoldable}	{IsDroppable}	{IsTradable}	{IsMinilandActionable}	{IsWarehouse}	{Flag9}	{Flag1}	{Flag2}	{Flag3}	{Flag4}	{RequireBinding}	{IsColored}	{FemaleOnly}	{MaleOnly}	0	{Flag6}	0	{IsHeroic}	{Flag7}	{Flag8}	{RaidItem}	{UnknownLastBit}
    	INDEX	0	0	{ItemSubType}
    	NAME	{NameI18NKey}
    	VNUM	{VNum}	{Price}
  3. Understand the monster.dat data structure

    master

    The monster.dat file defines the attributes, stats, and behaviors of monsters in the game. The data is organized into several logical groups: AINFO, ARMOR, ATTRIB, BASIC, CARD, EFF, ETC, EXP, HP/MP, ITEM, LEVEL, MODE, NAME, PARTNER, PETINFO, PREATT, RACE, SETTING, SKILL, VNUM, WEAPON, WINFO, and ZSKILL.

    Note that some values stored in the .dat file (like meleeDef, rangedDef, magicDef, and dodge) are recomputed at runtime from the armorLvl rather than being used directly.

  4. Understand the Card.dat file format

    master

    The Card.dat file defines card properties using a fixed-column text format. Each entry follows a specific sequence of keywords (EFFECT, GROUP, LAST, NAME, STYLE, TIME, VNUM) followed by their respective data values.

    Data Structure Template

    	EFFECT	{EffectId}
    	GROUP	0	{Level}
    	LAST	{TimeoutBuff}	{TimeoutBuffChance}
    	NAME	{NameI18NKey}
    	STYLE	0	{BuffType}
    	TIME	{Duration}	{Delay}
    	VNUM	{CardId}
  5. Verify BCard combat behaviors

    master

    BCards (Battle Cards) define specific combat mechanics. Use these criteria to verify their implementation:

    • Movement (BCard type 40):
      • Push (subtype 11): Target is pushed back a specific number of cells.
      • Pull (subtype 21): Target is drawn towards the user (e.g., Drawing Shot, Rotating Hammer). A value of 0 should result in the target being "up against you."
      • Charge (subtype 31): The user moves to the target.
      • Note: In all movement types, walls must stop movement to prevent clipping into geometry.
    • Damage as % of HP (BCard type 37 subtype 31): Damage must be calculated against the target's maximum HP, not current HP. It should stack with ordinary blows and trigger standard death mechanics (corpse, rewards, respawn).
    • Guaranteed Hit/Dodge (BCard type 16):
      • subtype 11: Lands even against high-dodge targets.
      • subtype 21: Causes misses against the user.
      • Conflict Resolution: If both are active, the attacker's guarantee is resolved first.
    • Elemental Resistance (BCard types 13 and 14): Buffs/debuffs should affect fire, water, light, and dark elements. An "all elements" effect must apply to each individually.
    • Multiplied Stats (BCard types 34 and 35): These use factors rather than percentages (e.g., a value of 5 is a fivefold increase). Subtypes for melee, ranged, and magic should only affect their respective categories.
  6. Understand the BCards computed field

    master

    The BCards property is a computed field derived from the raw data. It is an ICollection<T> that aggregates data from multiple sections.

    • Source: Combines 1ST and 2ST sections (specifically 5 groups of 6).
    • Composition: Contains up to 5 BCards. The first 3 are sourced from 1ST, and the remaining 2 are sourced from 2ST.
  7. Identify BCard.dat effect groups

    master

    The effects in BCard.dat are organized into functional groups. Common groups include:

    • Element Resistance (Group 13): Modifies resistance to Water, Light, or Dark.
    • Enemy Resistance (Group 14): Modifies an enemy's elemental or general resistances.
    • Damage (Group 15): Modifies damage taken or received from various sources (Melee, Ranged, Magical) or scales HP/MP based on attacks received.
    • Guaranteed Dodge (Group 16): Handles ranged attack hit chances, dodge probabilities, and distance-based damage.
    • Morale (Group 17): Affects the Morale stat, skill cooldowns, or enemy morale interaction.
    • Casting (Group 18): Affects effect durations, mana costs, attack speed, and casting success/interruption.
    • Movement (Group 19): Modifies movement speed, hidden speed, or movement possibility.
    • Reflection (Group 20): Handles HP/MP gain/loss based on damage dealt or received, and MP loss chances.
    • Drain and Steal (Group 21): Manages HP/MP conversion between player and enemy (leeching, stealing, or converting).
    • Healing, Burning, and Casting (Group 22): Manages HP/MP restoration or reduction during casting or via consumption.
    • HP/MP Restore/Decrease (Group 23): Handles percentage-based restoration or reduction of remaining HP/MP.
    • Specialization Buff (Group 24): Provides targeted resistance, damage increases, or critical hit modifiers against specific entities.
    • Buff/Debuff Logic (Group 25): General logic for causing/removing effects, preventing bad effects, or applying buffs to nearby objects based on level.
  8. Verify monster respawn timing

    master

    To test monster respawn logic, use the $Kill command and compare the actual respawn time against the value defined in the monster's .dat file.

    Key Timing Rules:

    • The .dat field is measured in tenths of a second (e.g., a value of 400 equals 40 seconds).
    • Monsters must not flicker back within one second of dying.
    • If the file value is 0, the monster should still respawn after a minimum one-second delay.
  9. Verify character and equipment mechanics

    master

    When testing character progression and state, check the following:

    • Mounts: Mounting should change the sprite and increase speed. Speed must persist across map changes and return to the base class value upon dismounting.
    • Class Changes: Using $ChangeClass should update the skill bar to the new class's skills. After a relog, ensure no old skill icons remain in the client memory.
    • Equipment Gates:
      • If an item requires a higher job level, the error message must specify that the job level is too low (not the class).
      • If an item is for a different class, the error must specify the wrong class.
      • Use $SetJobLevel to verify that meeting requirements allows equipping the item.
  10. Regenerate BCard.dat effects

    master

    To regenerate the BCard.dat file and its associated BCardEffect members, run the dotnet test command with a specific filter. You must provide the NOSCORE_DAT_FOLDER environment variable to specify the target folder for the data file.

    Note: BCard.dat tracks every effect declared by a client file. If a member is not declared by any client file on record, its Declared status will be no.

    NOSCORE_DAT_FOLDER=<folder> dotnet test --filter BCardVocabularyTests.Regenerate
  11. Build the NosCore code

    master

    To build and run the NosCore project, follow these steps:

    1. Install .NET 10: Download from the official .NET website. In Visual Studio, enable preview features via Tools > Options > Preview Features > Use previews of the .NET CORE SDK and restart.
    2. Configure PostgreSQL: Install PostgreSQL from the official website.
    3. Update the Database:
      • Open the Package Manager Console via Tools -> NuGet Package Manager.
      • Select the NosCore.Database project.
      • Run the command update-database.
    4. Start Services: Use the scripts located in the .\scripts directory to start the necessary services.
    # In Package Manager Console (selecting NosCore.Database project)
    update-database
  12. Configure local NuGet packages for development

    master

    If you are developing and testing un-released versions of NosCore.Packets, NosCore.Dao, or NosCore.Shared without publishing them to a registry, you can use a local NuGet source.

    Every NosCore repository includes a Directory.Build.props file that automatically adds a NuGet source if the NOSCORE_LOCAL_PACKAGES environment variable is set.

    Setup Instructions:

    1. Set the environment variable and create the directory (run once per machine):
      setx NOSCORE_LOCAL_PACKAGES C:\LocalPackages
      mkdir C:\LocalPackages
    2. Restart Visual Studio or your shell to apply the changes.
    3. Place your .nupkg files into C:\LocalPackages and perform a standard NuGet restore.

    If NOSCORE_LOCAL_PACKAGES is not set, the project defaults to using only nuget.org.

    setx NOSCORE_LOCAL_PACKAGES C:\LocalPackages
    mkdir C:\LocalPackages