west furnace access why
those dimensions are in meters correct?
Yes, hence the m suffix
Archived M2K2 Forum
Quote from Skull64:
I don't think Samus is 7'3".
Why not? Samus isn't entirely human, and the Chozo are really tall.
That seems shorter than reality actually. The morph ball tunnel in Transport Access North describes the morph ball tunnel as "A metre in diameter" and samus is at least 2 times taller than it.
Pak Tool refuses to run because msvcp110.dll is missing :( I have reinstalled the Visual C++ 2012 multiple times now :/
Quote from Baby Sheegoth:
Pak Tool refuses to run because msvcp110.dll is missing :( I have reinstalled the Visual C++ 2012 multiple times now :/
Try 2010.
Quote from Parax:
Quote from Baby Sheegoth:
Pak Tool refuses to run because msvcp110.dll is missing :( I have reinstalled the Visual C++ 2012 multiple times now :/
Try 2010.
Tried that too but will try again.
Worked this time :s thanks windows.
http://metroid.wikia.com/wiki/Samus_Aran
"She is 6 feet 3 inches tall and weighs 198 pounds, without her armor."
Samus is a big gal :V
"She is 6 feet 3 inches tall and weighs 198 pounds, without her armor."
Samus is a big gal :V
that, and the fact that in some zero mission sketches she was not allowed to have heels taller than like 5cm.
...I should really stop my habit of unintentionally hijacking threads for unrelated discussion too
[edit]: it didn't say any clear measure of maximum height, but... http://www.metroid-database.com/mzm/art/MZMZSSE.png
...I should really stop my habit of unintentionally hijacking threads for unrelated discussion too
[edit]: it didn't say any clear measure of maximum height, but... http://www.metroid-database.com/mzm/art/MZMZSSE.png
I think we need a customized mod installer for this game. It was kinda a PITA figuring out how to release that widescreen mod and what I ended up doing is still not really ideal. What I roughly have in mind is:
Creating mods:
- We have a GUI that allows the user to write in metadata for the mod, including name/game/author, and supported releases of the game.
- Modder provides a bunch of cooked assets and details on how to pack them into .pak files. This can be either a single resource replacement or instructions for building entire paks.
- The modder is also capable of providing a modified .dol file, which will be used to create a patch for the .dol.
- All this info is saved into a .mpm file. The modder distributes the .mpm along with the cooked assets.
- Other possibilities: We allow mods to be distributed as executables that do their own modifications on game files, which would allow things like the randomizer to be used through this system.
- Another option is we have the ability for different options to be toggled on each mod individually. For example, if someone releases a huge mod that introduces new visor HUDs, they can have a "widescreen" toggle that can make it use different HUD files.
- I don't think this tool should handle asset cooking. It does need to be able to do dependency parsing, though.
Using mods:
- User has all mods saved to a common directory, each one in its own folder.
- The user points to a clean ISO of the game. The installer verifies it via checksum and checks which game it is, as well as which version. If the user is using an unsupported version of the right game, they will receive a warning but have the option of trying to install anyway.
- The user checks all mods that they want enabled, has the option of modifying priority, and then clicks a button to generate a new ISO. This allows mods to be stacked on each other (eg Echoes Suits + Widescreen). The problem I see is that mods won't always be stackable - for instance if someone has a huge world mod that introduces new suits that have different asset IDs than the originals, but someone wants to use Echoes suits, it won't work correctly. I'm not sure how we could address that. There should at least be a warning message if a file replace mod doesn't actually replace anything.
- The user can also point to a directory with extracted files instead of an ISO, maybe? This complicates version/checksum checking though.
- Anyway - the end result of this is the user has a new ISO with all their mods installed that they can easily use in either Dolphin or on a homebrewed Wii.
This is probably an incomplete plan and it's more like a rough draft of what I think would be an ideal tool for us. The only thing is I don't really want to make all this by myself, especially since I know nothing about ISO formats, so my question is - if I start this as an open source project, would anyone be willing to collaborate on it? (Antidote, jackoalan?)
Creating mods:
- We have a GUI that allows the user to write in metadata for the mod, including name/game/author, and supported releases of the game.
- Modder provides a bunch of cooked assets and details on how to pack them into .pak files. This can be either a single resource replacement or instructions for building entire paks.
- The modder is also capable of providing a modified .dol file, which will be used to create a patch for the .dol.
- All this info is saved into a .mpm file. The modder distributes the .mpm along with the cooked assets.
- Other possibilities: We allow mods to be distributed as executables that do their own modifications on game files, which would allow things like the randomizer to be used through this system.
- Another option is we have the ability for different options to be toggled on each mod individually. For example, if someone releases a huge mod that introduces new visor HUDs, they can have a "widescreen" toggle that can make it use different HUD files.
- I don't think this tool should handle asset cooking. It does need to be able to do dependency parsing, though.
Using mods:
- User has all mods saved to a common directory, each one in its own folder.
- The user points to a clean ISO of the game. The installer verifies it via checksum and checks which game it is, as well as which version. If the user is using an unsupported version of the right game, they will receive a warning but have the option of trying to install anyway.
- The user checks all mods that they want enabled, has the option of modifying priority, and then clicks a button to generate a new ISO. This allows mods to be stacked on each other (eg Echoes Suits + Widescreen). The problem I see is that mods won't always be stackable - for instance if someone has a huge world mod that introduces new suits that have different asset IDs than the originals, but someone wants to use Echoes suits, it won't work correctly. I'm not sure how we could address that. There should at least be a warning message if a file replace mod doesn't actually replace anything.
- The user can also point to a directory with extracted files instead of an ISO, maybe? This complicates version/checksum checking though.
- Anyway - the end result of this is the user has a new ISO with all their mods installed that they can easily use in either Dolphin or on a homebrewed Wii.
This is probably an incomplete plan and it's more like a rough draft of what I think would be an ideal tool for us. The only thing is I don't really want to make all this by myself, especially since I know nothing about ISO formats, so my question is - if I start this as an open source project, would anyone be willing to collaborate on it? (Antidote, jackoalan?)
my approach to this problem would be to author a contextual binary-patcher to be used on the .gcm/.ico..
the way it would work would be to extract the in-game resource (FRME/CMDL/.../dol itself), keep a copy of the original, make the edit, then supply both the original and patched resource to the patching utility. it would store the original data as a pattern-reference and the data that replaces the pattern; so all the user does is supply the original .gcm/.iso and a find-and-replace is performed on the data (pre-decrypted/re-encrypted for the Wii versions).. this is a tricky proposition cause the patch file would need store a complete copy of the the original object for pattern-searching (legally questionable)..
on the other hand, a meta-data based approach would store a more fine-grained (non-Nintendo IP) binary-patch.. It would store the Retro-assigned hash IDs of the edited resource(s), and a series of patching directives (goto, replace, insert) to apply the patch to individual resource(s).. in order to prevent the patcher from modifying a resource it wasn't designed to patch (such as a Retro-edited PAL resource), the patch-maker would store a fresh hash of the compete original along with the hash ID.. this approach would also address the fact that Retro duplicates many resources for efficient loading..
the tricky thing is that it would essentially need to re-master the whole .pak file and possibly the disc's FST if the length of a given resource increases with the patch.
(P.S. slightly back off-topic but it's worth mentioning that Samus' first-person 'eye' is 1.875m from her feet)
the way it would work would be to extract the in-game resource (FRME/CMDL/.../dol itself), keep a copy of the original, make the edit, then supply both the original and patched resource to the patching utility. it would store the original data as a pattern-reference and the data that replaces the pattern; so all the user does is supply the original .gcm/.iso and a find-and-replace is performed on the data (pre-decrypted/re-encrypted for the Wii versions).. this is a tricky proposition cause the patch file would need store a complete copy of the the original object for pattern-searching (legally questionable)..
on the other hand, a meta-data based approach would store a more fine-grained (non-Nintendo IP) binary-patch.. It would store the Retro-assigned hash IDs of the edited resource(s), and a series of patching directives (goto, replace, insert) to apply the patch to individual resource(s).. in order to prevent the patcher from modifying a resource it wasn't designed to patch (such as a Retro-edited PAL resource), the patch-maker would store a fresh hash of the compete original along with the hash ID.. this approach would also address the fact that Retro duplicates many resources for efficient loading..
the tricky thing is that it would essentially need to re-master the whole .pak file and possibly the disc's FST if the length of a given resource increases with the patch.
(P.S. slightly back off-topic but it's worth mentioning that Samus' first-person 'eye' is 1.875m from her feet)
If I understand right, if we went with a patch-based approach then a patch for a mod would only work on one specific version of the game. In my opinion that's a deal-breaker for two reasons: first of all, it would make it more difficult to support multiple versions of the game. A 0-00 patch presumably won't work on the PAL version of the game, and especially not on Trilogy, even if the files that are modified are the same across every version. You would need to supply a separate patch for every version of the game. The other problem, which is the bigger issue, is the fact that patches for multiple mods can't be easily stacked on each other. You would have to apply them one at a time.. except that applying the patch for one mod suddenly breaks the patches for the other ones. Not good.
My approach would basically be to recreate a new ISO pretty much from scratch, basically using the original game ISO as a source for the original data and injecting in modded files as needed. I feel like this simplifies a lot of things on the user's end by providing them a clean interface to manage different mods and making installation nice and easy. It also avoids the issue you brought up of the patch needing to store the original data. We would also build the paks from scratch, so duplicate files would be handled by the packer. The mod would contain instructions on how to create the paks.
It is sorta more complicated than just making patches, but I think it's ultimately a much more flexible system (and probably easier to code too).
edit: also, keep in mind mods aren't necessarily just going to replace a couple resources and be done. What if we have a mod that replaces entire paks with custom made ones? We can't very well use a find+replace to install that. More flexibility is called for IMO.
My approach would basically be to recreate a new ISO pretty much from scratch, basically using the original game ISO as a source for the original data and injecting in modded files as needed. I feel like this simplifies a lot of things on the user's end by providing them a clean interface to manage different mods and making installation nice and easy. It also avoids the issue you brought up of the patch needing to store the original data. We would also build the paks from scratch, so duplicate files would be handled by the packer. The mod would contain instructions on how to create the paks.
It is sorta more complicated than just making patches, but I think it's ultimately a much more flexible system (and probably easier to code too).
edit: also, keep in mind mods aren't necessarily just going to replace a couple resources and be done. What if we have a mod that replaces entire paks with custom made ones? We can't very well use a find+replace to install that. More flexibility is called for IMO.
One word: depsgraph, yeah it'll be a pain to create and maintain, but the benefits would definitely outweigh that, also we don't necessarily need to rely on existing patch schemes, we have packs, we have asset IDs, abuse the heck out of them ;P.
1) Store the origin pack
2) Store the origin ID
3) Store the difference between the original, and the new
3) patch
4) ...
5) profit!
1) Store the origin pack
2) Store the origin ID
3) Store the difference between the original, and the new
3) patch
4) ...
5) profit!
Essentially, it's a linked data structure representing objects that 'depend' on one another.. They form the basis of Makefiles (software build systems) and really any system with several inter-linked, typified objects:
https://en.wikipedia.org/wiki/Dependency_graph
https://en.wikipedia.org/wiki/Dependency_graph
rebuilding the ISO as paraxade suggested strikes me as the way to go.
within that you'd probably want the option of either replacing any asset file completely or patching part of it. consider that you don't actually need to store copyrighted pattern data in a patch in order to find the part you want to replace. all you need is the length of the original pattern sequence and the hash or checksum of that sequence. then the source file can be searched by repeatedly hashing sections of it. this can be done with varying levels of granularity, so you could start by hashing larger pieces of the source (say 1K) and comparing them against a coarse hash in the patch to find the approximate location, and then do finer grained hashing within that section, comparing against a second hash in the patch to find the exact byte where the replacement should begin. none of this requires any copyrighted material to be stored in the patch -- all you need is a couple of hashes, and doing it at two or more levels of granularity like this would make it decently fast and also ameliorate the situation where the pattern you want to replace is repeated several times in the source file.
also, a reminder that I wrote sample PHP code for handling GC ISOs so I could unpack and repack without needing windows, so reference code for that already exists.
http://chexum.co.uk/uploads/mkiso-0.2.php.txt
within that you'd probably want the option of either replacing any asset file completely or patching part of it. consider that you don't actually need to store copyrighted pattern data in a patch in order to find the part you want to replace. all you need is the length of the original pattern sequence and the hash or checksum of that sequence. then the source file can be searched by repeatedly hashing sections of it. this can be done with varying levels of granularity, so you could start by hashing larger pieces of the source (say 1K) and comparing them against a coarse hash in the patch to find the approximate location, and then do finer grained hashing within that section, comparing against a second hash in the patch to find the exact byte where the replacement should begin. none of this requires any copyrighted material to be stored in the patch -- all you need is a couple of hashes, and doing it at two or more levels of granularity like this would make it decently fast and also ameliorate the situation where the pattern you want to replace is repeated several times in the source file.
also, a reminder that I wrote sample PHP code for handling GC ISOs so I could unpack and repack without needing windows, so reference code for that already exists.
http://chexum.co.uk/uploads/mkiso-0.2.php.txt
Quote from DJGrenola:
rebuilding the ISO as paraxade suggested strikes me as the way to go.
within that you'd probably want the option of either replacing any asset file completely or patching part of it. consider that you don't actually need to store copyrighted pattern data in a patch in order to find the part you want to replace. all you need is the length of the original pattern sequence and the hash or checksum of that sequence. then the source file can be searched by repeatedly hashing sections of it. this can be done with varying levels of granularity, so you could start by hashing larger pieces of the source (say 1K) and comparing them against a coarse hash in the patch to find the approximate location, and then do finer grained hashing within that section, comparing against a second hash in the patch to find the exact byte where the replacement should begin. none of this requires any copyrighted material to be stored in the patch -- all you need is a couple of hashes, and doing it at two or more levels of granularity like this would make it decently fast and also ameliorate the situation where the pattern you want to replace is repeated several times in the source file.
also, a reminder that I wrote sample PHP code for handling GC ISOs so I could unpack and repack without needing windows, so reference code for that already exists.
http://chexum.co.uk/uploads/mkiso-0.2.php.txt
within that you'd probably want the option of either replacing any asset file completely or patching part of it. consider that you don't actually need to store copyrighted pattern data in a patch in order to find the part you want to replace. all you need is the length of the original pattern sequence and the hash or checksum of that sequence. then the source file can be searched by repeatedly hashing sections of it. this can be done with varying levels of granularity, so you could start by hashing larger pieces of the source (say 1K) and comparing them against a coarse hash in the patch to find the approximate location, and then do finer grained hashing within that section, comparing against a second hash in the patch to find the exact byte where the replacement should begin. none of this requires any copyrighted material to be stored in the patch -- all you need is a couple of hashes, and doing it at two or more levels of granularity like this would make it decently fast and also ameliorate the situation where the pattern you want to replace is repeated several times in the source file.
also, a reminder that I wrote sample PHP code for handling GC ISOs so I could unpack and repack without needing windows, so reference code for that already exists.
http://chexum.co.uk/uploads/mkiso-0.2.php.txt
Wow, you're a saint.