k-Knight wrote:I have an idea for a mod, C++ coding experience and some programming knowledge. What I don't have is knowledge of where to start, so I am asking for help.
Currently in the game there's only 1 thing that affects how production of an industry will be changed, it's amount of cargo transported last month. So if it's above 60% then it's 67% chance for production to increase and 33% chance for it to decrease. And vice versa if transported amount is below 60%.
What i want to do is to change it so it wouldn't be just this simple condition but a curve (function) that will give probabilities based on amount of cargo transported last month.
So the question is: where should I start?
Cadde wrote:You should start with NewGRF, where all those parameters you mentioned can be controlled.
But the question is, what do you want to replace the production change with? Especially for raw industries that doesn't accept cargo?
There's limitations in NewGRF that would shape what you can possibly achieve.
Look here for what's possible:
https://newgrf-specs.tt-wiki.net/wiki/NML:Industries
You should also know why we don't call them "mods"...
Cities Skylines can use files for buildings and interface features, thanks to official support. Those are mods.
Sim City 4 has official support for mods, which is why it was popular right up until Cities Skylines came out. Once again, those were mods.
Grand Theft Auto V does not have official mod support, but with OpenIV you can apply mods to it. Thus, those are mods.
ROM hackers, such as the creator of Kaizo Mario World, usually distribute the hacks as patches (to avoid copyright issues) which are applied to a ROM by a program. These are essentially the same as the mods applied to GTAV.
TTDPatch was a program which, at one time, was used with OpenTTD. From what I've dug up on it, it had to re-patch the original TTD game every time to avoid copyright issues, likely because even the method used by ROM hackers was somehow still illegal, or it was more convenient. Technically, it could be considered a launcher that enabled a mod.
OpenTTD is sort of weird that way. From what I managed to track down, this forum had pursued a clone of TTD for years, in a project called "Transport Unlimited" which has its own archive on these forums. The progress was so gruelingly slow (according to the post date tags) that I'm surprised it continued for so long.
Then this happened...
viewtopic.php?f=29&t=6559
Out of nowhere, the forum admin (still in the position to this day) posts a file that was given to him by an emulation developer that made an open-source clone of TTD. In a surprisingly short period of time, Transport Unlimited was obsolete. However...
TTDPatch stuck around for years, and a couple features it had like diagonal rail crossings have disappeared with TTDPatch when it finally bit the dust. At current, there are four categories of changes, none of which can be called mods despite serving the same function...
NewGRFs: These use either a coding language created for TTDPatch called NML (NewGRF Meta language, based on XML) or NFO (hex editing, tedeous and unweildy but required for stations and a couple other types of NewGRF; the original coding method of TTD's "base set"). PNG files packaged with NML or NFO enable easy addition of buildings, terrain and vehicles. These can't be changed mid-game unless you disable a hidden feature that prevents it AND if you do change them your game save will likely get corrupted.
An interesting issue is "bootstrapping", where a feature that should have been done as a patch was done as a NewGRF to avoid dying out.
Basesets: NewGRFs are added on top of the baseset. "ttd_original" is if you take the files from the original game, giving the original graphics. OpenGFX is the default included with OpenTTD now (if you don't have "ttd_original" on first startup, it automatically downloads and uses OpenGFX). They tried adding some 32-bit graphics but the support from NewGRFs is far worse than for normal sprites (apparently needs 3D modelling?). Unlike NewGRFs, basesets always contain the same number and purposes of graphics, so you can switch between them at will.
Basesets also include music and sound effects, which can also be switched at will.
NoAI: The opposite of what it sounds like. Originally OpenTTD probably had a copy of the default AI. At some point they must have stripped it out and added "NoAI", a feature which enables the creation and use of one or more custom AIs.
Patches: Unlike TTDPatch and ROM hacks, a "patch" in OpenTTD is an actual feature. Think of it like the official DLC which adds a major feature and costs $5-$10, except because it's under GPL you can get it free. The downside of this is that patches usually die, the ones that don't disappear upon being added to the main version, or become part of a patch pack. Patch packs seem relatively new, so many patches died out because the main version devs didn't want to maintain extra patches whose original programmers disappeared years ago.
For example, canals are considered lucky to be a main feature because a lot of people don't use ships and the feature is so complex. The truth is that backwards compatibility means the 2017 April Fools (removing canals) was just a joke, not because they wouldn't remove canals, but because backwards compatibility is the one thing they will not violate (even patch pack devs don't like doing this), and removing canals is impossible to do without ruining backwards compatibility. It also means that they won't include a feature until it is practically bug-free and several other important requirements, because they can't afford to add a feature that has even a remote chance of becoming impossible to maintain.
To do what you want without restrictions, you would need to develop a patch for it, but getting it into trunk, let alone stable, is going to be hard. Getting it into a patch pack is a good idea, and should be pursued once the patch is out, because it can make it important enough for someone to maintain it if you can't. After that, getting it into trunk is the next goal, IIRC. I've never programmed a patch, but I can see the general reasons they do things fairly well. The issue is apparently that if it gets into a patch pack, getting it into trunk actually becomes harder because of what it might do to the patch pack(s) it's in, which is why NotRoadTypes (hint: it's not
not Road Types) isn't in a patch pack and is aiming for trunk.
The worst case, however, is when the patch doesn't get into anything. In these cases, the patch's death is one break from OpenTTD on the part of the dev away.
None of the above fit the idea of the "game mod" well enough to be the same thing. So, to do what you're trying to, you don't program a mod. You program a potential new feature.
Also, sorry for the wall of text. It was the best I could do.
