Actually, I can see a room for improvement in the plugins. For example, if you have multiple types of the same file, like in Diablo/Diablo2 they have the same roughly the same format, and you can use a lot of the same code, it would be nice to be able to use one plugin for multiple formats or multiple games. Like
bnGetExtensions() to get a list of extensions or
bnGetExtensionCount() to get a count of supported ectensions
then
bnGetExtensionInfo(Index) to get the info for each Extension (Game name/support flags)
then when you extract or list, you pass in that index into the other functions like iList
Also, you might wanna put in versioning. For example a function
bnSupported(Version), where mexcom passes in the version and the plugin lets it know if it'll work with that version. That way mexcom can "skip" plugins not supported on upgrade. This doesn't have to be the version of the mexcom, it could a version of the dll interface methods, this could also help mexcom support older plugins as the future goes on.
Important information: this site is currently scheduled to go offline indefinitely by end of the year.
Code Submissions
I could work on it, if you want, even though I havent worked with VB in years. My strong suits, at least in windows, C/C++ and Delphi. Also, I have the problem of not owning VB6. The closest I have VB.NET. But what I could do, is convert it to VB.NET (cuz you have to ) and then submit a code changes to you directly. Man, I should sign up on your forum.
-
- Site Admin
- Posts: 4073
- Joined: Wed Jan 15, 2003 6:45 pm
- Location: Dungeons of Doom
- Has thanked: 450 times
- Been thanked: 682 times
- Contact:
LOL. Yeah, would be advisable.Guest wrote:Man, I should sign up on your forum.
There are ways to overcome the problem of not owning VB though. But yeah, you could always send the implementations directly. Especially if we'd create a separate plugin-handling class + module. Changes in there would never interfere with the rest of the code, as its...well..separate.
Right, in fact, i'm writing the plugin right now, in Delphi. Once I get that done I could port it over C/C++, so other developers can have a sample in the language they prefer.Mr.Mouse wrote:There are ways to overcome the problem of not owning VB though. But yeah, you could always send the implementations directly. Especially if we'd create a separate plugin-handling class + module. Changes in there would never interfere with the rest of the code, as its...well..separate.
Also, i would like to build, at least along side Mexcom, a command line tool, that can utilize the same files as the gui, for 2 reasons
1) It would be nice to write a batch(script) file to do batches for certain games, and it would be nice for MODer to have build scripts for their MODs.
2) It would make it easily portable to a unix/linux environment, where some games are actually are.
Let me know your take on that.
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
-
- Site Admin
- Posts: 4073
- Joined: Wed Jan 15, 2003 6:45 pm
- Location: Dungeons of Doom
- Has thanked: 450 times
- Been thanked: 682 times
- Contact:
Well, a command-line tool might be possible, you do know that the actual processing of the scripts (listing contents) is done by multiex.dll. MultiEx Commander just uses multiex.dll to list archive content. It is fed MexScripts. MultiEx.dll coudl be called by such a command-line tool, but that would be problematic cross-platform wise.
I own Delphi as well, so I can test your code in there. If you have the plugin, with the added functions you mention, then I will update the code in MultiEx Commander to use it.
Please also note that my life is pretty busy, and I will not always have the time to work on it. If it is speed you are after, I won't be able to help. But I don't think you will need speed in this case. And besides, as it might be turned into a mutual project you could always adapt pieces of code yourself after I send you the latest source.
I own Delphi as well, so I can test your code in there. If you have the plugin, with the added functions you mention, then I will update the code in MultiEx Commander to use it.
Please also note that my life is pretty busy, and I will not always have the time to work on it. If it is speed you are after, I won't be able to help. But I don't think you will need speed in this case. And besides, as it might be turned into a mutual project you could always adapt pieces of code yourself after I send you the latest source.
It would if the dll was turned into a shared library. Most platforms have a shared library format now.Mr.Mouse wrote:Well, a command-line tool might be possible, you do know that the actual processing of the scripts (listing contents) is done by multiex.dll. MultiEx Commander just uses multiex.dll to list archive content. It is fed MexScripts. MultiEx.dll coudl be called by such a command-line tool, but that would be problematic cross-platform wise.
First I have to get mexcom to SEE it as a pluginMr.Mouse wrote:I own Delphi as well, so I can test your code in there. If you have the plugin, with the added functions you mention, then I will update the code in MultiEx Commander to use it.
Understandable, as I'm busy myself with my own projects as well as work, this includes my own coding web site. But I was thinking of it as a port of sorts, and everyone knows ports of a software never come out the same time as the original . The shared library could also be a port. The worse thing here is the ActiveX Plugins, only cuz those aren't portable. Everything else could be easily portable.Mr.Mouse wrote:Please also note that my life is pretty busy, and I will not always have the time to work on it. If it is speed you are after, I won't be able to help. But I don't think you will need speed in this case. And besides, as it might be turned into a mutual project you could always adapt pieces of code yourself after I send you the latest source.
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
Ok i think i found the problem, in Module1.bas.
1) There has to be at least one entry in the MRF file for that file extension (will not create new file extensions, ie Making a XXG directory without adding a an entry into the MRF will be ignored.)
2) Problems if the file extension is less than 3 characters. If I add the Extension "XX" into the MRF file, and then make a directory called "XX" the system will never see it as a plugin because you pad out the extension in the MRF file, but not the subdirectory. Hence "XX" <> "XX ".
Also good to note, a lot of newer games, are using more than 3 character extensions. This system might want to be upgraded.
I found this out, by putting my module in the PAK directory, and it loaded just fine.
1) There has to be at least one entry in the MRF file for that file extension (will not create new file extensions, ie Making a XXG directory without adding a an entry into the MRF will be ignored.)
2) Problems if the file extension is less than 3 characters. If I add the Extension "XX" into the MRF file, and then make a directory called "XX" the system will never see it as a plugin because you pad out the extension in the MRF file, but not the subdirectory. Hence "XX" <> "XX ".
Also good to note, a lot of newer games, are using more than 3 character extensions. This system might want to be upgraded.
I found this out, by putting my module in the PAK directory, and it loaded just fine.
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
Further Analysis
I saw "If t <= ExtFormats + 1 Then" which means that it attempts to load it.
This attempts to load it past the end of the format list, but the ExtFormats variable is never updated. The plugin definition is there (I think, i can't remember if VB auto redims an array when you try assign past its boundary).
This ExtFormats is used later, and when loop from 0 to ExtFormats -1, you never get to the NEW entries.
I saw "If t <= ExtFormats + 1 Then" which means that it attempts to load it.
This attempts to load it past the end of the format list, but the ExtFormats variable is never updated. The plugin definition is there (I think, i can't remember if VB auto redims an array when you try assign past its boundary).
This ExtFormats is used later, and when loop from 0 to ExtFormats -1, you never get to the NEW entries.
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)