Shadow Wolf TJC wrote:As modders, we often take and accept risks when developing our mods, knowing full well that what we do may end up breaking the game some way or another. While the issues that we find may be given lower priority than issues that plague the base game (since these issues don't affect the base game anyways), by pointing them out and fixing them, we can still help evolve the Warzone 2100 experience as a whole.
I understand that modders want to push the limit, and that is all good, except when it comes time when the modders release something. Then, it can have unforeseen consequences, that could cause random issues.
The end result is we get tickets from people and they have really odd errors that we can't replicate easily.
By changing the game's limits, and just exporting everything out without fixing the underlying issues causes many, many issues, and it makes it incredibly difficult to trace back to what is going on, when it turns out the issue is a mod or map-mod that the user was using, and not the base game.
I once posted a screen grab of the way WZ works in a flow chart.
Yes, WZ is that complex, and changes that can't possibly cause issues have come back to haunt us again and again.
For example, I'd personally like to see factory, LasSat Command Post, and Satellite Uplink limits handled exclusively by rules.js, multilim.slo, and multilim.vlo instead of this piece of code from structures.cpp:
Code: Select all
//paranoid check!!
if (psBuilding->type == REF_FACTORY ||
psBuilding->type == REF_CYBORG_FACTORY ||
psBuilding->type == REF_VTOL_FACTORY)
{
//NEVER EVER EVER WANT MORE THAN 5 FACTORIES
if (asStructLimits[selectedPlayer][inc].currentQuantity >= MAX_FACTORY)
{
continue;
}
}
//HARD_CODE don't ever want more than one Las Sat structure
if (isLasSat(psBuilding) && getLasSatExists(selectedPlayer))
{
continue;
}
//HARD_CODE don't ever want more than one Sat Uplink structure
if (psBuilding->type == REF_SAT_UPLINK)
{
if (asStructLimits[selectedPlayer][inc].currentQuantity >= 1)
{
continue;
}
}
Ideally, unhardcoding such things would not have any effect on the base game experience, but have a profound effect on the modding community (for example, it could very well fix
ticket #3775 in the process), even though it would not deal with issues like what's described in
ticket #3521, which the hard code previously attempted to keep hidden. Then again, if the code was rewritten carefully enough, then these newer issues would probably never surface within the base game either.
The above don't actually fix anything though. That just removes one safety net.
Pumpkin did things in their unique way, trying to save as much memory as possible to run on the PSX.
Pretty much everything is NOT dynamically allocated, and instead, there is a fixed size in many arrays. They even have "unique" ways of using guards used for certain things that causes issues. At the time, with that compiler, and on only one platform, it wasn't that big of a deal, and AFAIK, pretty much all the mods done back then never had as much access as there is now, which makes things much more complex. When those are not fixed, and the limits are exported out, it spells random issues and very difficult to find out what went wrong.
There are tons of things that are only known at compile time, so the game has no way of knowing something outside of its scope has changed, and no way to fix it.
Yeah, I know other projects could care less about this, and like the quick hack instead.
Been there, done that, and it has pretty much always come back to haunt us.
Although we understand that fixing bugs and issues that affect the base game should take priority for the development team, some of us may be willing to help deal with some of these less important issues. For example, I'm personally looking into finding a way to fix tickets
#3775,
#3521,
#3465, and
#3438, though later, I may want to help add some new functionality to the code (such as, say, adding support for building some, but not all, structures on water).
Help is good.
