Files
ClassicAssist.Avalonia/.qoder/repowiki/en/content/Game Automation Features/Autoloot System/Advanced Features and Customization.md
T
Beyhan Oğur d5f52cc3d3 first commit
2026-09-03 04:45:36 +03:00

19 KiB
Raw Blame History

Advanced Features and Customization

**Referenced Files in This Document** - [AutolootViewModel.cs](file://ClassicAssist.Shared/UI/ViewModels/Agents/AutolootViewModel.cs) - [AutolootManager.cs](file://ClassicAssist.Shared/Data/Autoloot/AutolootManager.cs) - [AutolootEntry.cs](file://ClassicAssist.Shared/Data/Autoloot/AutolootEntry.cs) - [AutolootConstraintEntry.cs](file://ClassicAssist.Shared/Data/Autoloot/AutolootConstraintEntry.cs) - [PropertyEntry.cs](file://ClassicAssist.Shared/Data/Autoloot/PropertyEntry.cs) - [PropertyType.cs](file://ClassicAssist.Shared/Data/Autoloot/PropertyType.cs) - [AutolootOperator.cs](file://ClassicAssist.Shared/Data/Autoloot/AutolootOperator.cs) - [AutolootTabControl.xaml.cs](file://ClassicAssist.Avalonia/Views/Agents/AutolootTabControl.axaml.cs) - [CustomPropertiesWindow.xaml.cs](file://ClassicAssist/UI/Views/Autoloot/CustomPropertiesWindow.xaml.cs) - [PropertySelectionWindow.xaml.cs](file://ClassicAssist/UI/Views/Autoloot/PropertySelectionWindow.xaml.cs) - [ClilocSelectionWindow.xaml.cs](file://ClassicAssist/UI/Views/Autoloot/ClilocSelectionWindow.xaml.cs) - [AutolootTests.cs](file://ClassicAssist.Tests/Agents/AutolootTests.cs)

Table of Contents

  1. Introduction
  2. Project Structure
  3. Core Components
  4. Architecture Overview
  5. Detailed Component Analysis
  6. Dependency Analysis
  7. Performance Considerations
  8. Troubleshooting Guide
  9. Conclusion
  10. Appendices

Introduction

This document explains advanced autoloot features and customization options with a focus on the AutolootViewModel’s role in managing rule collections and providing MVVM binding for the UI. It covers advanced filtering capabilities (including regular expressions, custom property evaluators, and conditional logic based on player state or location), performance tuning for high-throughput scenarios, memory management for large rule sets, extension points for creating custom property types and operators, debugging techniques for complex rule conflicts, monitoring autoloot performance metrics, and strategies for organizing and maintaining large collections across different gameplay scenarios.

Project Structure

The autoloot feature spans shared data models, managers, view models, UI views, and tests:

  • Shared data layer defines rule entries, constraints, properties, operators, and the manager orchestrating evaluation.
  • View model binds rules to UI and exposes commands and observable collections.
  • Avalonia/XAML views provide configuration windows and tabs for editing rules.
  • Tests validate behavior and edge cases.
graph TB
subgraph "Shared Data"
AM["AutolootManager"]
AE["AutolootEntry"]
ACE["AutolootConstraintEntry"]
PE["PropertyEntry"]
PT["PropertyType"]
AO["AutolootOperator"]
end
subgraph "UI Layer"
VM["AutolootViewModel"]
TAB["AutolootTabControl"]
CPW["CustomPropertiesWindow"]
PSW["PropertySelectionWindow"]
CLW["ClilocSelectionWindow"]
end
subgraph "Tests"
T["AutolootTests"]
end
VM --> AM
AM --> AE
AE --> ACE
AE --> PE
PE --> PT
AE --> AO
TAB --> VM
CPW --> VM
PSW --> VM
CLW --> VM
T --> AM

Diagram sources

Section sources

Core Components

  • AutolootViewModel: Manages rule collections, provides MVVM bindings for the UI, and coordinates rule evaluation requests from the UI.
  • AutolootManager: Central engine that evaluates rules against game objects using configured properties, operators, and constraints.
  • AutolootEntry: Represents an individual autoloot rule with associated conditions and actions.
  • AutolootConstraintEntry: Encapsulates constraint definitions used by rules.
  • PropertyEntry and PropertyType: Define available properties and their types for rule conditions.
  • AutolootOperator: Defines supported operators for evaluating conditions.
  • UI Views: Provide dialogs and controls for selecting properties, clilocs, and configuring custom properties.

Key responsibilities:

  • Rule collection lifecycle (add, remove, reorder, import/export).
  • Binding observable collections to UI elements.
  • Invoking evaluation pipelines when items drop or are picked up.
  • Exposing validation and error feedback to users.

Section sources

Architecture Overview

The autoloot system follows an MVVM pattern:

  • The ViewModel owns rule collections and exposes them to XAML views.
  • The Manager performs rule evaluation using data models and operators.
  • UI components trigger evaluations and display results or errors.
sequenceDiagram
participant UI as "AutolootTabControl"
participant VM as "AutolootViewModel"
participant M as "AutolootManager"
participant E as "AutolootEntry"
participant C as "AutolootConstraintEntry"
participant P as "PropertyEntry"
participant O as "AutolootOperator"
UI->>VM : "User edits rule or triggers evaluation"
VM->>M : "Evaluate(item, rules)"
M->>E : "Iterate rules"
E->>C : "Check constraints"
C->>P : "Resolve property value"
P->>O : "Apply operator"
O-->>C : "Boolean result"
C-->>E : "Aggregate condition(s)"
E-->>M : "Match decision"
M-->>VM : "Result + diagnostics"
VM-->>UI : "Update UI / notify user"

Diagram sources

Detailed Component Analysis

AutolootViewModel: Rule Collection Management and MVVM Binding

Responsibilities:

  • Maintain observable collections of rules and related metadata.
  • Provide commands for adding, removing, duplicating, and reordering rules.
  • Bind rule properties to UI controls via data templates and converters.
  • Coordinate with AutolootManager to evaluate rules and present outcomes.
  • Expose validation messages and error states to the UI.

MVVM patterns:

  • Observable collections for two-way binding.
  • Commands encapsulating user actions.
  • Properties raising change notifications for reactive UI updates.

Common usage:

  • Initialize rule set from configuration or defaults.
  • Handle item pickup/drop events by invoking evaluation through the manager.
  • Persist changes back to storage.

Section sources

AutolootManager: Evaluation Engine

Responsibilities:

  • Iterate over rule entries and apply constraints.
  • Resolve property values and apply operators to compute boolean conditions.
  • Aggregate multiple constraints per rule and determine matches.
  • Return match results and optional diagnostic information for debugging.

Evaluation flow:

  • For each incoming object, iterate rules in priority order.
  • For each rule, evaluate all constraints; short-circuit on first failure if applicable.
  • Use property resolution and operator application to decide matches.

Section sources

Rule Models: AutolootEntry, AutolootConstraintEntry, PropertyEntry, PropertyType, AutolootOperator

  • AutolootEntry: Holds rule-level settings, constraints, and actions.
  • AutolootConstraintEntry: Defines a single condition with left/right operands and operator.
  • PropertyEntry: Describes a resolvable property path and its type.
  • PropertyType: Enumerates supported property types for conversion and comparison.
  • AutolootOperator: Enumerates supported operators (e.g., equals, contains, regex).

These models enable declarative rule definition and flexible evaluation.

Section sources

UI Integration: Tabs and Windows

  • AutolootTabControl: Hosts the autoloot UI within the agents tabbed interface.
  • CustomPropertiesWindow: Allows defining or editing custom properties for advanced scenarios.
  • PropertySelectionWindow: Provides a guided selection of available properties for rule conditions.
  • ClilocSelectionWindow: Enables selecting localized strings for rule matching.

These views bind to AutolootViewModel and delegate evaluation to the manager.

Section sources

Testing and Validation

  • AutolootTests: Contains unit/integration tests validating rule evaluation, constraints, and edge cases.

Use these tests as references for expected behaviors and to guide customizations.

Section sources

Dependency Analysis

The following diagram shows key dependencies among core autoloot components:

classDiagram
class AutolootViewModel {
+Rules
+AddRule()
+RemoveRule()
+Evaluate(item)
}
class AutolootManager {
+Evaluate(item, rules)
-ResolveProperty(entry)
-ApplyOperator(op, left, right)
}
class AutolootEntry {
+Constraints
+Actions
}
class AutolootConstraintEntry {
+LeftOperand
+RightOperand
+Operator
}
class PropertyEntry {
+Path
+Type
}
class PropertyType {
}
class AutolootOperator {
}
AutolootViewModel --> AutolootManager : "uses"
AutolootManager --> AutolootEntry : "iterates"
AutolootEntry --> AutolootConstraintEntry : "contains"
AutolootConstraintEntry --> PropertyEntry : "references"
PropertyEntry --> PropertyType : "typed"
AutolootConstraintEntry --> AutolootOperator : "applies"

Diagram sources

Section sources

Performance Considerations

High-throughput scenarios benefit from careful rule design and evaluation optimization:

  • Rule ordering: Place most selective rules earlier to short-circuit evaluation quickly.
  • Constraint composition: Prefer exact matches before broad patterns; use negation sparingly.
  • Operator selection: Choose operators that minimize string processing overhead where possible.
  • Property resolution caching: Avoid repeated expensive lookups by leveraging cached property values when available.
  • Batch evaluation: When many items arrive simultaneously, consider batching to reduce per-item overhead.
  • Memory management: Limit rule set size by splitting into scenario-specific profiles; unload unused rules at runtime if supported.
  • Diagnostics: Enable lightweight logging only during troubleshooting to avoid overhead in production.

[No sources needed since this section provides general guidance]

Troubleshooting Guide

Debugging complex rule conflicts:

  • Inspect rule priority and order; conflicting rules may be overridden by higher-priority entries.
  • Validate constraint operands and operators; ensure property paths resolve correctly for the target object.
  • Use test cases to reproduce issues deterministically; compare expected vs actual outcomes.
  • Narrow down by disabling subsets of rules to isolate problematic conditions.
  • Review UI feedback and error messages exposed by the ViewModel for invalid configurations.

Monitoring autoloot performance metrics:

  • Track evaluation time per rule and overall throughput during peak activity.
  • Log counts of matched vs skipped rules to identify bottlenecks.
  • Monitor memory usage growth when loading large rule sets; consider profile-based loading.

Section sources

Conclusion

The autoloot subsystem combines a robust MVVM architecture with flexible rule modeling and evaluation. By leveraging advanced filtering, custom properties, and operators, users can create precise and performant autoloot behaviors. Organizing rules into focused profiles, applying performance best practices, and using testing and diagnostics ensures maintainability and reliability across diverse gameplay scenarios.

[No sources needed since this section summarizes without analyzing specific files]

Appendices

Advanced Filtering Capabilities

  • Regular expression support: Use regex-capable operators for pattern matching on names, descriptions, or other text properties.
  • Custom property evaluators: Extend PropertyEntry and PropertyType to introduce new resolvable attributes.
  • Conditional logic: Combine multiple constraints with logical operators to implement complex conditions based on player state or location.

Implementation pointers:

  • Add new operators to AutolootOperator and integrate evaluation logic in the manager.
  • Register custom properties via PropertyEntry and ensure proper type handling with PropertyType.
  • Compose constraints in AutolootConstraintEntry to express multi-condition logic.

Section sources

Creating Custom Property Types and Operators

Steps:

  • Define a new PropertyType and corresponding PropertyEntry to expose the property path.
  • Implement operator logic in AutolootOperator and update evaluation routines accordingly.
  • Wire UI components (PropertySelectionWindow, CustomPropertiesWindow) to allow users to select and configure the new property/operator.

Validation:

  • Add tests covering edge cases and performance characteristics.
  • Ensure backward compatibility with existing rules.

Section sources

Organizing and Maintaining Large Rule Collections

Strategies:

  • Group rules by gameplay scenario (e.g., farming, questing, PvP) and load relevant profiles dynamically.
  • Use consistent naming conventions and comments in rule metadata for clarity.
  • Periodically review and prune unused or redundant rules.
  • Employ version control to track changes and collaborate effectively.

[No sources needed since this section provides general guidance]