katstasaph/otii

Oregon Trail II reverse engineering/decompilation project, in progress

otii

Decompiled and commented code from Oregon Trail II. This is decompiled C++ from the executable; I would be very surprised if it compiled, this is purely for data diving/reverse engineering purposes.

Decompilation from Snowman: https://github.com/yegord/snowman/

To view data in a more legible format: https://docs.google.com/spreadsheets/d/1lJlZA0BBIAZVAxEuniHffpb3K18b27j4LeYaTmV1dX8/edit?usp=sharing

otii's Issues

Some questions.

So, I noticed you mentioned that this was just for extracting info about the game. I have been looking through the spreadhsheet and also one other persons reverse engineering.

I think it's a real disappointment that some of the features that most excited me about Otii weren't functional, from what I can find there currently aren't any fixes for the issue with weekly and monthly trigged things. Maybe I am wrong?

From digging arround in the spreadsheet It doesn't seem to mention weights, but maybe I am reading it wrong. I may dig a little into your annotated code to try to understand things and figure out that sort of thing.

I am also sort of curious how the food consumption equations work in more detail. Is it just based on unit of material. Or does each unit have partial usage that isn't obvious. Like being based on weight for items with a listed weight.
How is item weight handled for things that don't list a weight?

Anyways, it seems like a fix for the triggering issue is unlikely, otii seems like the most complex and fleshed out oregon trail game, although a decent chunk of the complexity seems to be non-functional or hard to interact with. Trying to explore it is really fun for a data-dive or adult, I could see a lot of it being confusing for a kid. And even then a lot of my intuitions about how things worked as implied by the game text and items offered seem to be wrong after diving into it a little more.

I would love to try OT2 modding, but I am not quite good enough at C, assembly, and disassembly to be able to troubleshoot getting something to recompile. I have done a little rom-hacking but mostly small stuff.

Assuming such a fix isn't feasible, it made me sort of think about what if there was a game that was kind of a hybrid between OT1 and 2. Or the potential if there was an "Open Oregon Trail" or something.

Although, technically there are a bunch of meh student projects that don't even hit oregon trail 1 standards. I mean something more significant.

Not sure if starting from scratch/something like that in a newer language, or perhaps trying to upgrade and modify the basic version. (Or maybe the first MISC version if it is available.) And adding extra routes and stuff to try to back-port a lot of the ot2 content would be better?

I actually like the MISC 1 hunting system better than in 2. But it doesn't have anywhere near as many options for roleplaying.

If I were to start from scratch, trying to add some more narrative elements might also be interesting potentially? Not sure.
I would probably put it either in python, or in like a javascript/html based engine. Since that might let us have a web-hosted version, or potentially a mobile release easier without having to use a clunky heavyweight game engine that would make modding a little harder.

If it was download only, we might be able to do a RCT2 style thing, and either have the option, or require that someone have a copy of the OTII so that graphics and such could be extracted or something. Or alternatively, just going for some sort of pixel art style sort of like 1. but more intense could be cool.

I am curious about your opinions, as well as if you know anyone else who might be interested in a project like that?

nerf drowning

.

Music files + Website

Just found this project and wow!! Excellent work! I'm wondering if you could upload the music files, I've been looking to remaster the soundtrack but I can't figure out how to extract them.

ChatGPT can fix/help with this immensely

fun_401000:
    Initializes an object and allocates memory.
    Calls initializeEightBytesToZero to zero out eight bytes of memory.
    Calls operator new to allocate memory and fun_4a619a to further initialize the object.
    Sets several properties on the object.

fun_42c492:
    Placeholder function likely initializing or resetting some data. Needs more context to provide a precise description.

__crtMessageBoxA:
    Wrapper function for MessageBoxA which shows a message box.
    Uses GetProcAddress to get function pointers dynamically.

initializeEightBytesToZero:
    Initializes eight bytes of memory to zero.

operator new and operator delete:
    Custom memory allocation and deallocation functions.

storeStringToNewlyAllocatedMemory:
    Allocates memory for a string and stores the string in that memory.

loadDataSection:
    Loads a section of data, possibly from a file or memory.

createRectRegionWrapper:
    Wrapper for creating a rectangular region using CreateRectRgn.

loadWeatherDataWrapper:
    Loads weather data and resets some precipitation-related values.

fun_48419c:
    Destructor-like function that cleans up various data structures and memory.

Potential Issues and Fixes

Memory Leaks:
    Ensure all allocated memory is properly freed.
    In fun_401000, verify that memory allocated by operator new is freed if the function encounters an error.

Uninitialized Variables:
    Ensure all variables are properly initialized before use.
    In functions like fun_401000, check that all required properties are set before the function returns.

Error Handling:
    Add proper error handling to functions that perform memory allocation or other operations that can fail.
    For example, in operator new, handle the case where _nh_malloc returns nullptr.

Function Documentation:
    Adding comments and documentation to each function can help understand their purpose and how they interact with each other.