MiranDMC
commented
1 year ago I would like to request support for proposed {$INCLUDE_ONCE file} feature too.
During development even simple projects it is good practise to split code into smaller, topic oriented files. Then lack of include once starts making the process problematic. If there is file like Utils.txt with commonly used functions and it is included by two project sub-files, then redefinition compile errors occurs.
Currently walk around is to disable include of Utils.txt in all but one of sub-files, but then editor constants highlighting and auto complete stops working in that files.
If I'm not mistaken feature seems be easy to implement. Preprocessor just need to keep list of absolute paths of already included files, and check it before each INCLUDE_ONCE is performed.
$INCLUDE_ONCE
Not really a request, but an excuse to talk about a project I'm trying to document. The computer I've been using for most of my SA modding died recently. I'm a bit discouraged and looking to retire but I wanted to finish up a couple of projects as best I can. One of which would benefit from
$INCLUDE_ONCE
... proved to be a limitation of the 010 Editor. The original idea was to adapt my SA save template to active memory in a way that could be adapted to PS2 memory dumps and offer documentation that's somewhat appropriate to mobile memory. Instead I built a template for the topic at hand, which was vehicles in memory. This post shows an early example of what I had in mind for PlayerInfo, but is in the format used for Game Memory documentation on GTAMods. What I'd prefer is a format that could be used to copy and paste constant addresses, pointers and relative offsets directly into a cleo script. Or for a more complex project, the whole page could be saved and implemented with
$INCLUDE_ONCE
The goal was to bring DK22pac's SDK-plugin style documentation to cleo users. Lack of class structure in 010 proved to be a difficult problem. My lack of understanding of class structure was an even greater problem, but I managed to work something out that mapped, iirc, everything in CVehicle using the plugin's naming convention, modified to a version that 010 and Sanny can both support, but I had to build the structures twice.
CVehicle: A struct based format that organizes the classes into structs in a familiar and useable format ClassVehicle: A class-like structure that starts with, for example, Quadbike, and works it's way backwards
The ClassVehicle structure should describe the expected class-like offsets when Start Address is set to local.
I'm almost to the point of trying to produce SB compatible files for vehicle constants, but I'd like to consult about naming conventions, whether I've fairly represented the class structure in a manner that makes sense for cleo coding, and strategies for documenting the template and constants. If you'd care to take a look;
$INCLUDE_ONCE SAmem_b1.zip