Skip to main content

Overview

Follow these best practices to create mods that are stable, compatible, and easy to maintain.

Project Organization

File Naming

Use descriptive, meaningful names:✅ Good:
  • weapon-rebalance-v2.fbproject
  • 4k-character-textures.fbproject
  • enhanced-lighting-overhaul.fbproject
❌ Avoid:
  • project1.fbproject
  • mod.fbproject
  • asdf.fbproject

Directory Structure

Organize your modding workspace:

Version Control

Track your projects with Git:
.gitignore for mods:
Write clear commit messages:✅ Good:
❌ Avoid:
Use branches for major changes:

Asset Modification

Texture Best Practices

Choose appropriate texture formats:
Don’t use uncompressed formats (RGBA8) for shipped mods. They’re 4-6x larger and hurt performance.

Mesh Best Practices

Maintain good mesh topology:
  • Quad-based: Use quads where possible
  • Triangulate: Triangulate before export
  • No N-gons: Avoid faces with >4 sides
  • Clean geometry: Remove doubles, fix normals
  • Proper UVs: No overlapping (unless intentional)
Match or slightly improve original counts:
High poly counts hurt performance, especially for multiple instances.
Preserve vertex channel requirements:Required Channels:
  • Position (always)
  • Normal (always)
  • UV0 (almost always)
  • Tangent/Bitangent (for normal maps)
  • Vertex Colors (if original had them)
  • Additional UVs (match original count)
Bone Weights:
  • Max bones per vertex: Match original
  • Normalize weights
  • Remove unused influences
Keep materials organized:
  • Use descriptive material names
  • Match original material count
  • Preserve material IDs
  • Don’t create unnecessary materials

EBX Property Editing

Before editing EBX properties:
  • Understand what the property does
  • Note the original value
  • Test changes incrementally
  • Check for dependent properties
Generally safe to modify:
  • Numeric values: Damage, range, speed
  • Boolean flags: Enable/disable features
  • Strings: Names, descriptions
  • Colors: RGB values
  • Asset references: Swap textures/meshes

Compatibility

Mod Conflicts

1

Minimize Conflicts

Reduce chances of conflicts:
  • Modify only what’s needed: Don’t change unnecessary assets
  • Avoid popular assets: Commonly modded assets conflict more
  • Provide alternatives: Offer compatible versions
  • Document changes: List all modified assets
2

Test with Popular Mods

Before release, test with:
  • Top 10 most downloaded mods
  • Mods in same category
  • Known overhaul mods
  • Different load orders
3

Communicate Conflicts

Document known incompatibilities:

Game Version Compatibility

Track which game version your mod targets:
  • Project file: Stores game version (head revision)
  • Description: Document game version in mod description
  • Updates: Test after game patches
  • Changelog: Note when updating for new game version
When game updates:
  1. Wait for Frosty update: Ensure toolsuite supports new version
  2. Test existing mod: Check if still works
  3. Update if needed: Fix broken assets
  4. Increment version: Update mod version number
  5. Notify users: Announce compatibility

Performance Optimization

Resource Size

Optimize mod size without sacrificing quality:
  1. Use compressed formats: BC1/BC3/BC7 for textures
  2. Remove unused mipmaps: Don’t include more than needed
  3. Optimize mesh data: Remove unused vertex channels
  4. Avoid duplicates: Reuse assets where possible
  5. Test compression: Different formats for different use cases

Runtime Performance

Be mindful of texture streaming:
  • Mipmap chains: Ensure proper mipmap generation
  • Chunk ranges: Don’t break texture chunk data
  • FirstMip value: Maintain for streaming textures
  • LogicalOffset/Size: Required for proper loading
Optimize mesh rendering:
  • LOD levels: Provide multiple detail levels
  • Polygon budget: Stay within reasonable limits
  • Vertex cache: Optimize vertex order
  • Material count: Minimize draw calls
Organize assets efficiently:
  • Related assets: Keep in same bundle
  • Streaming: Use appropriate bundle types
  • Size balance: Don’t create massive bundles

Documentation

Mod Description Template

Screenshots

Take quality screenshots:
  1. In-game: Show mod in actual gameplay
  2. Comparisons: Before/after shots
  3. Key features: Highlight main changes
  4. Resolution: 1080p or higher
  5. Clean UI: Hide debugging overlays
  6. Good lighting: Show details clearly

Testing

Pre-Release Testing

1

Functional Testing

Verify core functionality:
  • All modified assets load
  • No crashes during normal gameplay
  • Visual changes appear correctly
  • Gameplay changes work as intended
  • No console errors
2

Compatibility Testing

Test with other mods:
  • Works alone
  • Works with popular mods
  • No conflicts in multiple load orders
  • Performance acceptable
3

Edge Case Testing

Test unusual scenarios:
  • Quick save/load
  • Long play sessions (memory leaks)
  • Different graphics settings
  • Minimum spec hardware (if possible)
4

User Testing

Get feedback before release:
  • Share with trusted testers
  • Gather feedback on usability
  • Fix critical bugs
  • Refine based on suggestions

Bug Reporting Template

Provide users with a bug report template:

Release Process

1

Final Testing

Before release:
  • Full playthrough test
  • Clean game install test
  • Performance profiling
  • Asset validation
2

Prepare Release

Package for distribution:
  • Export final .fbmod
  • Write/update README
  • Create changelog
  • Gather screenshots
  • Record demonstration video (optional)
3

Upload

Publish to platforms:
  • Choose appropriate category
  • Add descriptive tags
  • Include all screenshots
  • Link to documentation
  • Set correct game version
4

Post-Release

After publishing:
  • Monitor comments/feedback
  • Fix critical bugs quickly
  • Update documentation as needed
  • Thank users for feedback

Maintenance

Update Strategy

Use semantic versioning:Format: MAJOR.MINOR.PATCH
  • MAJOR: Breaking changes, incompatible
  • MINOR: New features, backwards compatible
  • PATCH: Bug fixes only
Examples:
  • 1.0.0 → 1.0.1: Bug fix
  • 1.0.1 → 1.1.0: New feature
  • 1.1.0 → 2.0.0: Major overhaul
Maintain detailed changelogs:
When retiring features:
  1. Announce early: Warn users in advance
  2. Provide alternatives: Suggest replacements
  3. Gradual removal: Mark deprecated first
  4. Archive old versions: Keep available for existing users

Community

Being a Good Mod Author

Community Best Practices:
  • Respond to feedback: Engage with users
  • Credit others: Acknowledge help and inspiration
  • Be receptive: Accept constructive criticism
  • Share knowledge: Help other modders learn
  • Respect licenses: Follow other mods’ terms
  • Be patient: Users have varying technical knowledge

Licensing

Consider your mod’s license:
  • Open Source: Allow others to learn/modify
  • Restrictive: Prevent unauthorized use
  • Credits Required: Ensure attribution
  • Commercial Use: Allow/disallow monetization
Common licenses:
  • MIT: Very permissive
  • CC BY 4.0: Requires attribution
  • CC BY-NC-SA 4.0: Non-commercial, share-alike
  • All Rights Reserved: Most restrictive

Resources

Create Mods

Start creating your first mod

Asset Modification

Learn to edit different asset types

Package Mods

Export and distribute your mods

Install Mods

Use Frosty Mod Manager