refactor: Save/load to json part 2#642
refactor: Save/load to json part 2#642EttyKitty merged 22 commits intoAdeptus-Dominus:feat/json-savingfrom
Conversation
load now goes to defeat screen, better than infinite crashes
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughSummary by CodeRabbit
WalkthroughBy the blessed logic of the Machine Spirit, this update implements a comprehensive transition from legacy INI file operations to a modern JSON-based system for persistent data management. The changes introduce new serialisation and deserialisation functions across multiple objects—including controllers, fleets, initial configurations, and stars—for converting in-game states into structured, JSON-compatible data. Iterative type checking is employed to ensure only simple data types and arrays thereof are included, whilst complex types trigger warning logs for the sake of data integrity. A new Possibly related PRs
Suggested labels
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (11)
objects/obj_controller/Create_0.gml(1 hunks)objects/obj_en_fleet/Create_0.gml(1 hunks)objects/obj_ini/Create_0.gml(3 hunks)objects/obj_p_fleet/Create_0.gml(1 hunks)objects/obj_saveload/Alarm_0.gml(2 hunks)objects/obj_saveload/Create_0.gml(2 hunks)objects/obj_star/Create_0.gml(1 hunks)scripts/scr_load/scr_load.gml(1 hunks)scripts/scr_save/scr_save.gml(2 hunks)scripts/scr_save_controller/scr_save_controller.gml(2 hunks)scripts/scr_specialist_point_handler/scr_specialist_point_handler.gml(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
`**/*.gml`: Macro constants require a space between the constant name and value. Without it, the compiler will throw an error. I.e. `#macro ARR_body_parts["arm"]` will crash the ga...
**/*.gml: Macro constants require a space between the constant name and value. Without it, the compiler will throw an error. I.e.#macro ARR_body_parts["arm"]will crash the game, because there is no space between the array and the name of the macro.
scripts/scr_specialist_point_handler/scr_specialist_point_handler.gmlobjects/obj_en_fleet/Create_0.gmlobjects/obj_star/Create_0.gmlobjects/obj_p_fleet/Create_0.gmlobjects/obj_ini/Create_0.gmlobjects/obj_saveload/Create_0.gmlscripts/scr_save_controller/scr_save_controller.gmlobjects/obj_saveload/Alarm_0.gmlscripts/scr_load/scr_load.gmlobjects/obj_controller/Create_0.gmlscripts/scr_save/scr_save.gml
`**/*.gml`: Color codes in the code shouldn't have any spaces in their id. I.e., color code `# 80 bf40` will crash the game.
**/*.gml: Color codes in the code shouldn't have any spaces in their id. I.e., color code# 80 bf40will crash the game.
scripts/scr_specialist_point_handler/scr_specialist_point_handler.gmlobjects/obj_en_fleet/Create_0.gmlobjects/obj_star/Create_0.gmlobjects/obj_p_fleet/Create_0.gmlobjects/obj_ini/Create_0.gmlobjects/obj_saveload/Create_0.gmlscripts/scr_save_controller/scr_save_controller.gmlobjects/obj_saveload/Alarm_0.gmlscripts/scr_load/scr_load.gmlobjects/obj_controller/Create_0.gmlscripts/scr_save/scr_save.gml
🔇 Additional comments (26)
scripts/scr_specialist_point_handler/scr_specialist_point_handler.gml (1)
87-87: Admonition: Altered formatting for output.
O most dutiful acolyte, thou hast changed the newline to a hash symbol for “Combat Repairs”. This should function adequately, provided thou desirest a single-line summarised readout.scripts/scr_save_controller/scr_save_controller.gml (2)
6-7: Observation: Blank lines introduced.
These lines appear to be simple spacing adjustments and should not affect functionality.
16-16: Confirmation: Additional blank line.
Likewise, this extra spacing is harmless.objects/obj_en_fleet/Create_0.gml (2)
74-139: Commendation: Newserializefunction.
Blessings upon thee for implementing a thorough serialisation routine. The array-type checks and the exclusion of complex data uphold the Machine Spirit’s desire for structured data. Ensure, however, that any future expansions requiring struct-based data are integrated with explicit logic rather than omitted.
143-150: Approval: Newdeserializefunction.
Thy function correctly recreates the fleet instance and handles sprite selection. Verily, the usage ofinstance_create_layerand populating relevant fields fromsave_dataaligns well with the new system. Watch for hidden dependencies in the future if additional attributes require re-initialisation.objects/obj_star/Create_0.gml (2)
116-202: Laudation: Prudent design forserialize.
Thy code diligently captures planet data, checking arrays for compliance with the simple-type requirement. This fosters clarity within the Omnissiah’s grand design for data integrity. Mind that large or nested arrays may eventually tax performance; vigilant testing is recommended.
204-237: Endorsement: Logicaldeserializestructure.
The logic for reconstructing planetary data and reassigning arrays is well-devised. The explicit handling of excluded fields—particularlypresent_fleet—is beneficial to prevent undesired re-initiation. Maintain caution when altering the planet indexing scheme in future expansions.objects/obj_p_fleet/Create_0.gml (2)
61-72: Commendable approach for dynamic serialisation.
Thy function's initial design, including a short documentation comment, neatly sets the purpose of converting variables into JSON. Retaining an array of excluded fields ensures that ephemeral or internal variables, such as "temp" or "serialize", are not mistakenly preserved.
130-133: Deserialisation logic properly spawns the fleet instance.
Instantiatingobj_p_fleetwith stored coordinates is clear. Yet, if the system must merge data into an existing instance, additional logic shall be necessary.objects/obj_saveload/Create_0.gml (1)
3-9: Centralised save structure is well-structured for expansions.
Thou hast declared aGameSaveas a container for crucial arrays and structs. This fosters clarity and easier maintainability as new domains (stars, event logs, etc.) are introduced.objects/obj_saveload/Alarm_0.gml (2)
51-52: Shift to JSON file deletion is consistent with new format.
The code snippet aligns with the transition from.inito.json. Deletion logic is straightforward, ensuring stale saves are purged.
125-125: Load checks updated for JSON presence.
Verifying JSON file existence preserves the new unified approach to storing game data. This is consistent with the rest of the refactor.objects/obj_controller/Create_0.gml (2)
1801-1877: Comprehensive serialisation approach with clear exclusions.
Your usage ofstruct_get_namesto dynamically process each variable is methodical. Excluding ephemeral properties liketempor referencingrestart_variables prevents unwanted bloat in saved data. However, keep watch for complex structures that might require deeper recursing.
1878-1904: load_con_data function ensures state restoration.
Reconstructing theobj_controllerfrom the saved data is thorough, and re-initialising dependent constructs (specialist_point_handler,location_viewer) is praiseworthy. Verify that newly introduced variables or expansions receive similar re-initialisation to avoid partial states.Wouldst thou want a script to scan all calls to
variable_struct_setor references to these newly initialised objects, confirming completeness?scripts/scr_load/scr_load.gml (5)
10-14: Confirm new parameter usage for JSON data.
By introducing thestructparameter and invokingload_json_data(struct), thou invitest a more direct approach to loading. Ensure all invocations ofload_marine_structpass valid data and handle missing or partial fields gracefully.
25-26: Verify integrity ofjson_game_save.
If theSaveproperty is non-existent, this code simply overwritesobj_saveload.GameSave. Double-check thatjson_game_saveholds valid sub-structs, so that no corruption transpires.
47-58: Scrutiny of star deserialization.
The supreme logic is invoked to recreateobj_starfrom stored data. Beseech the Omnissiah to confirm that all relevant star fields are properly handled indeserialize(star_save_data).
60-64: INI deserialization check.
Observe here howobj_iniis resurrected from saved data. Confirm that any changes toobj_ini.deserializeremain consistent with the new JSON-based scheme.
104-118: Enemy fleet re-creation.
A parallel sequence forobj_en_fleetarises. Confirm that the instantiation lines and logic remain symmetrical with the player fleet, ensuring no key data is lost.objects/obj_ini/Create_0.gml (3)
106-108: Confirm usage of newly introduced arrays.
advanddisare declared as empty arrays. Verify thou art harnessing them somewhere else, lest they remain barren.
122-124: Segregation of save/load region.
Thou hast demarked a region for JSON serialisation. The structure is neat: maintain it well for future expansions.
226-291: Careful restoration indeserialize.
The function resurrects data, loads marines, squads, and associated arrays. Confirm that out-of-bounds indices or missing fields are gracefully handled, as corruption may slip in from incomplete saves.scripts/scr_save/scr_save.gml (4)
31-50:GameSave.Savepopulation.
This newly forged struct is comprehensive, holding data likechapter_nameandfoundation. Confirm all relevant global variables are appended, and that no hallmark is omitted.
62-69: Player fleet array logic.
Gathering all activeobj_p_fleetinstances intoGameSave.PlayerFleetis correct. Consider if any fleets in a spawning state or partial construction require special handling.
82-85: Serialising the controller.
obj_controller.serialize()is placed inGameSave.Controller. Affirm that all controlling logic is included, so reloading yields the same high-level game state.
94-105: INI-based metadata.
While thou shift the main data to JSON, these lines still track essential metadata insaves.ini. Confirm consistency between the JSON’s content and these summary records.
|
@coderabbitai, maybe you'll be able to spot the issue. there is a problem on this branch: |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 8150 🏁 Script executed: Length of output: 18726 🏁 Script executed: Length of output: 14003 The sacred code reveals a potential heresy in the Draw events. Both fleet types contain these visibility filters: if (x <0) or (x>room_width) or (y<0) or (y>room_height) then exit;
if (image_alpha=0) then exit;The likely issue is that deserialized fleet positions are invalid or defaulting to (0,0). During loading, fleets are created at position (0,0): var p_fleet_instance = instance_create(0,0, obj_p_fleet);Two potential remediations to appease the Machine Spirit:
deserialize = function(save_data) {
// Existing code...
// Explicitly set position even if it was handled in the automatic var setting
x = save_data.x;
y = save_data.y;
image_alpha = 1; // Force visibility
// Rest of the function...
}May your binary be purified and your runtimes efficient. (\/) [,,_,,] Code Analysis ToolsTool Analysis ResultsCodeRabbit ran static analysis tools on your files and found the following: No specific issues were found in your files. You can proceed with your changes. |
|
@coderabbitai okay it wasn't that, but i did put a bunch of debug messages in the draw function and nothing showed up, suggesting the object isn't getting drawn at all. |
|
Tip For best results, initiate chat on the files or code changes. @VanWeapon By the Omnissiah, I have discovered the critical flaw in the data matrices! The fleet deserialization functions contain a fundamental logical error which prevents their manifestation in the material plane. Observe this heretical code in your fleet deserialization functions: deserialize = function(save_data) {
// Create a new instance of the object at the given position
var p_fleet_instance = instance_create(0,0, obj_p_fleet);
for (var i = 0; i < variable_instance_get_names(p_fleet_instance); i++) {
variable_instance_set(p_fleet_instance, variable_instance_get_names(p_fleet_instance)[i], variable_instance_get(self, variable_instance_get_names(p_fleet_instance)[i]));
}
}The sacred silicon spirits are displeased! This function creates new fleet instances but copies variables from Recommended correction to appease the Machine God: deserialize = function(save_data) {
// Create a new instance of the object at the saved position
var p_fleet_instance = instance_create(save_data.x, save_data.y, obj_p_fleet);
// Copy all properties from save_data to the new instance
var prop_names = variable_struct_get_names(save_data);
for (var i = 0; i < array_length(prop_names); i++) {
var prop_name = prop_names[i];
// Skip object name and position which are already handled
if (prop_name != "obj" && prop_name != "x" && prop_name != "y") {
variable_instance_set(p_fleet_instance, prop_name,
variable_struct_get(save_data, prop_name));
}
}
// Ensure sprite is set correctly
with (p_fleet_instance) {
set_player_fleet_image();
}
return p_fleet_instance;
}Apply this correction to both obj_p_fleet and obj_en_fleet. The Machine Spirit demands it! Code Analysis ToolsTool Analysis ResultsCodeRabbit ran static analysis tools on your files and found the following: No specific issues were found in your files. You can proceed with your changes. |
VanWeapon
added
Type: Refactor
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@EttyKitty this is ready for review/test build i think, got it fairly stable now and eyeballing things looks like loading restores values properly everywhere that matters |
Co-authored-by: EttyKitty <20323032+EttyKitty@users.noreply.github.com>
Co-authored-by: EttyKitty <20323032+EttyKitty@users.noreply.github.com>
VanWeapon
force-pushed
the
refactor/save-load2
branch
from
e8875f7 to
074612b
Compare
|
okay @EttyKitty this is good to go again |
refactor: Better array and var helpers
2 participants
Purpose
Describe your changes/additions
What can/needs to be improved/changed
Testing done
Related things and/or additional context