Code Submissions

Guest · Post by **Guest** » Thu Aug 05, 2004 9:54 am

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.

Guest · Post by **Guest** » Thu Aug 05, 2004 9:57 am

Mr.Mouse wrote:Forget about the current state of the CVS, the latest version is not up there yet. I have had very limited time lately to actually update that.

BAH!... well thats not good

Post by **Mr.Mouse** » Thu Aug 05, 2004 10:00 am

Your ideas are very valid.

Would you care to work on such an implementation? I will update the CVS to the latest then.

Guest · Post by **Guest** » Thu Aug 05, 2004 10:14 am

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.

Rahly · Post by **Rahly** » Thu Aug 05, 2004 10:18 am

Ahhh this is better. I feel less..... naked.

Post by **Mr.Mouse** » Thu Aug 05, 2004 10:18 am

Guest wrote:Man, I should sign up on your forum.

LOL. Yeah, would be advisable.

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.

Rahly · Post by **Rahly** » Thu Aug 05, 2004 10:42 am

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.

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.

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.

Post by **Mr.Mouse** » Thu Aug 05, 2004 11:23 am

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.

Rahly · Post by **Rahly** » Thu Aug 05, 2004 11:39 am

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.

It would if the dll was turned into a shared library. Most platforms have a shared library format now.

Mr.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.

First I have to get mexcom to SEE it as a plugin

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.

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.

Rahly · Post by **Rahly** » Fri Aug 06, 2004 7:04 pm

Yeah, I'd really like to see the code you use to check for a plugin.

Post by **Mr.Mouse** » Fri Aug 06, 2004 9:12 pm

If everything is well, I'm updating the CVS as we speak.

For now, here is the clean source code:

Guest · Post by **Guest** » Sat Aug 07, 2004 12:19 am

You rule

Rahly · Post by **Rahly** » Sat Aug 07, 2004 1:22 am

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.

Rahly · Post by **Rahly** » Sat Aug 07, 2004 1:33 am

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.

Post by **Mr.Mouse** » Sat Aug 07, 2004 9:51 am

Please feel free to adapt and, improve on, the code. It would help a lot if we could work together on this matter, see also my reply in the Painkiller thread.

XeNTaX

XeNTaX

Code Submissions