Ideas for V3.0

Since we’re already at V2.7.x, it’s probably a good idea to start planning for V3.0. This will be a major version, so we should throw backwards compatibility straight out of the window and take the opportunity to remove all obsolete methods/properties and rename ones that might have a strange name or not accurately reflect their purpose.

More ideas will be added periodically, so feel free to leave your own idea/feedback below.

Native hashes

One of the biggest changes will definitely be the native hashes. There’s a lot of duplicates or ones with bad names from months and months ago. Since there’s literally thousands of hashes, I suggest splitting NativeHashes.hpp into separate files like so:

[core]\hashes\[category].hpp – partial Native::Hash enum definitions [core]\NativeHashes.hpp – includes all partial definitions from NativeHashes folder

There will be multiple files containing native hashes, but they will still be all in one enum.

Attributes

ScriptHookVersionAttribute

Also new for 3.0 should be the ability for developers to implement a ScriptHookVersion attribute that allows user to define a Minimum and a Maximum supported version of ScriptHookV.NET. There’s actually a built-in class called System.Version that can be used to process these values. The attribute constructor should support all of the System.Version constructors. The Revision part of the Version should be ignored.

This attribute should only be applicable to the assembly of the script, and accessed when the script is first loaded. Any scripts that are not safely compatible should be unloaded and a message printed to the log file.

Classes

• Implement a Checkpoint class [#486]
• Implement a ParticleFX (PTFX) class [#535]

Source code

XML Documentation

We should start getting into the habit of adding XML documentation to methods/properties/enums so developers don’t have to try and guess what something does.

[crosire]

I don’t think we should split the native hashes into separate files by the way. Yes, it’s a big file, but some clean up should be enough (like removing all the “_0x…” enum values).

[crosire]

New SHVDN will be distributed as ScriptHookVDotNet3.dll or something similar.