Modify

Ticket #688 (closed bug: duplicate)

Opened 3 years ago

Last modified 2 years ago

Mod loading patch!

Reported by: Zarel Owned by: Zarel
Priority: major Milestone: 2.3.0
Component: Engine: other Version: git/master
Keywords: mods Cc: warzone-dev@…, devurandom
Blocked By: Blocking:
Operating System: All/Non-Specific

Description

Yep, it's finally here. Though the code is arguably a bit ugly, it's still mostly readable. The patch file is for trunk - I will backport it to 2.2 before I commit it.

"Blocker" priority because the command line simply shouldn't be the only way to load a mod.

Fixes:

  • Fixed a possible buffer overflow when exactly MAX_MODS are loaded.
  • Fixed some magic numbers (someone used 100 when they meant MAX_MODS).

Changes:

  • Specifying mods via the command line is simpler. Instead of: --mod_mp ntw.wz one can simply type --mod ntw. The command line is also more forgiving: --mod ntw.mmod.wz will load NTW Mod if it's in mods/ntw/, or in mods/multiplay/ntw.wz...
  • Mods can be named modname.mmod.wz and placed directly in mods/, and will be treated as a multiplayer mod. The same goes for .cmod (campaign) and .gmod (global). Mods in the mods/ directory without one of these extensions will be treated as global mods.
  • The autoload/ folder is back, and works as it did previously. Note that mods/autoload/modname.mmod.wz will not be loaded in campaigns, and vice versa.
  • The name of every mod loaded is stored in multiplay_loaded_mods (a null-terminated array of strings that maxes out at MAX_MODS). They should probably be sorted alphabetically, concatenated with a separator, and sent with the version string.
  • MAX_MODS lowered from 100 to 64. MAX_MODS controls the max number of each type of mod that can be specified with the command line, as well as the number of mods that will be counted in multiplay_loaded_mods (additional mods will still be loaded, but not counted).

Attachments

modloading.patch (19.3 KB) - added by Zarel 3 years ago.
New version, with suggestions from cybersphinx

Change History

Changed 3 years ago by Zarel

New version, with suggestions from cybersphinx

comment:1 Changed 3 years ago by DevUrandom

I object against the milestone:2.2.2 and propose milestone:2.3. Reason being that there shall be no rewrites and functionality/semantic changes in bugfix releases.

comment:2 follow-up: ↓ 6 Changed 3 years ago by Per

IIRC the reason we removed autoload was that it generated lots of bogus bug reports when people forgot to mention (to other players, and in bug reports) that they played with them in online games. Before we re-enable this functionality, we need to prevent players from being able to join a game with the wrong mods, and add the list of mods used to the crash dump report. IMHO.

comment:3 Changed 3 years ago by DevUrandom

The code once was able to list which folders were mounted. You could just add that output to crashdumps, and also use it for version comparisons (use the basename of the file/folder).

comment:4 Changed 3 years ago by Zarel

  • Status changed from new to accepted
  • Owner set to Zarel

The code still lists which folders are mounted (and my code doesn't change this) in LOG_NEVER.

The code can easily be revised to output this in crashdumps, and is designed to easily interface with the version checking code. The agreement was originally for Buginator to do that part, but it appears I may have to do it myself.

comment:5 Changed 3 years ago by DevUrandom

  • Cc devurandom added

comment:6 in reply to: ↑ 2 Changed 3 years ago by Buginator

Replying to Per:

IIRC the reason we removed autoload was that it generated lots of bogus bug reports when people forgot to mention (to other players, and in bug reports) that they played with them in online games. Before we re-enable this functionality, we need to prevent players from being able to join a game with the wrong mods, and add the list of mods used to the crash dump report. IMHO.

We also need a way to check it is the same mod, so perhaps some CRC check or something along those lines, and we should transfer the mod like we do maps, in case the person don't got it.

comment:7 Changed 2 years ago by Buginator

Just a note, when we check the mod, we should calculate a CRC checksum (we need GPL code for this) of some kind, and I guess do that for each mod, then transmit it for each mod, or should we XOR all the CRCs of all the mods, and just send it then?

Whatever we decide, we need a well defined way to handle this, and so far, we don't have it, and I am strongly against doing it the haphazard approach that won't solve the issues with having mods in the first place.

comment:8 Changed 2 years ago by Zarel

/shrug

You can go implement or reimplement as you wish. The main problem is that our current haphazard way of doing things is interfering with much progress.

comment:9 Changed 2 years ago by Zarel

  • Priority changed from blocker to critical
  • Milestone changed from 2.2.5 to 2.3

comment:10 Changed 2 years ago by Per

I think we need a better way to inform the user of why he cannot join games (because there is an autoload mod in his folders) before this is committed.

comment:11 Changed 2 years ago by BlueMaxima

Simple, just say, "Cannot join game due to loaded mod" or something.

comment:12 Changed 2 years ago by Zarel

  • Status changed from accepted to closed
  • Resolution set to duplicate

Obsoleted by #1415.

View

Add a comment

Provide an email address (will not be publicly visible) in the Author field or register an account (uses your forum account).

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.