Modding in 2021 and beyond

ALIEN

I decided to gather a few topics which I do consider important, helpful, and valuable for the modding community. Let's hope that it will bring attention to some of the projects. Anyway, here it is:

Basic:
- Remove ACTION_READLN from your mods and replace it with SUBCOMPOENENT/FORCED_SUBCOMPOENENT feature: ACTION_READLN - it's bad for players and your mods, please replace it
Trust me you don't need it and it causes major pain for players and mod managers.

Metadata:
- Provide details about your mods: Adding metadata for mod
You can provide mod metadata like full display name, description, links, etc-

- Add globally unique LABEL into all your mod components:
What is LABEL, why you should create it and how to do it properly
LABEL is a better DESIGNATED. Please add it to your mods, it will help the community greatly. Also will enable saving components for Project Infinity.

Install order:
- Provide required install order for your mods: Dynamic Install Order
You can provide the install order that your mods require and be sure that players will always install your mods according to it.

- Re-code your mod dependencies using modern way:
How to properly handle mod component dependencies:
Instead of locking other modders with their DESIGNATED numbers, use a modern way that will not interfere.

- If your mods have support for classic games, recode them to use UTF8-based HANDLE_CHARSETS function:
How to properly handle mod translation by using HANDLE_CHARSETS function, with AUTO_TRA
This will make translations much easier to handle, integrate and update for modders and translators.

Advanced things:
- Check immutability and encapsulation in mod design. If you want to avoid strange mod bugs that are very difficult to discover and debug, this topic is for you.

- Check EEEx and what it can do for you. If you had a new, unique idea for a mod but face engine limitation, this has the potential to help you to achieve your goal.

Packaging:
- Create additional IEMOD packages when you distribute your mods
It's a cross-platform, universal way to package Infinity Engine mods. Currently, there is only one tool that creates valid .iemod packages: Infinity Auto Packager and it require mods to be hosted on GitHub. (But if any modder wants to create .iemod packages without hosting the mods at GitHub, feel free to PM me.)

Tools:
- Consider switching your editor to Visual Studio Code with BGforge MSL extension:
When it comes to WeiDU syntax highlighting, Infinity Engine helpers, taken directly from IEDSP, reporting errors, such combination offers features beyond what any other editor can provide.

- Consider using IElib: https://forums.bgforge.net/viewtopic.php?f=35&t=238
IElib is a collection of WeiDU defines, designed to ease mod development by abstracting commonly used magic numbers such as offsets. It's meant to be used with MLS, but it will work standalone as well.

- Consider using Happy IE: https://forums.bgforge.net/viewtopic.php?f=37&t=225
Its purpose is to find and report any (possible) issues found in IE game files. You might be familiar with integrity checks in DLTCEP and NearInfinity. In a nutshell, Happy IE tries to do the same, but in WeiDU form.

- Consider using Golem: https://forums.bgforge.net/viewtopic.php?f=37&t=224
It's a system that automatically tracks your code on GitHub. With each commit, it clones the repo and tries to install it on various IE games. It then parses modname.debbug files, makes note of any found errors and warnings, and presents them on the build page in a nice, human-readable way.

jastey

Unfortunately, I can only give one "Like".
Thank you for your hard work for the community!

AWizardDidIt

fantastic post. Thank you Alien

Jarl

Great ideas, Alien! Any news on the UTF-8 problem with HANDLE_CHARSETS / AUTO_TRA?

ALIEN

Jarl wrote: »

Great ideas, Alien! Any news on the UTF-8 problem with HANDLE_CHARSETS / AUTO_TRA?

No. I'm waiting for the answer here: https://forums.pocketplane.net/index.php?topic=29971.msg340453#msg340453 you can add your vote.

_Luke_

@ALIEN

Could you provide a template (markdown file) for bug reports?

ALIEN

@Luke What do you mean?

_Luke_

ALIEN wrote: »

@Luke What do you mean?

As you surely know, GitHub repos can have one or more templates for bug reports/feature requests.
I was wondering if you have some particular recommendations about how to properly structure it or if it's up to each modder...

ALIEN

@_Luke_ Many modders prefer to have bug reports directly at the mod thread instead of GitHub issues so I didn't focus on those. When we on it, the GitHub issue template at a minimum, should ask about the game version, language, wiedu.log, and mod.debug file since that often missing but important info.

ALIEN

@Jarl The "HANDLE_CHARSETS UTF8" guide was updated, now AUTO_TRA is fully supported.

AndreaColombo

@ALIEN for my benefit, do I understand correctly that:

• In order for my mod to include "immutability", suffice to set a backup folder outside of the mod's main folder
• In order for my mod to include "encapsulation", suffice to split all components into their own separate .tph file rather than having everything into the main tp2

?

Or is there more to it that I should be doing?

ALIEN

@AndreaColombo Nope,

- immutability accounts for modification of all mod files during installation, not only moving backup
- encapsulation accounts for resetting variables after each component and structuring your component so that are self-contained monoliths

the best place for questions regarding those concepts is the topic itself.

AndreaColombo

Additional question. I see most mods still use DESIGNATED together with LABEL.

Isn't that redundant? LABEL should be enough, unless DESIGNATED is left for backward compatibility.

ALIEN

@AndreaColombo That's correct. It's one of the advantages of LABEL but if a mod didn't start with LABEL and comment inside component code aka "// Never ever use the component number, detect components via LABEL's", DESIGNATED kept to have compatibility with the 'old ways of doing things'.