Miscellaneous fixes for HEMTT warnings and related#144
Open
Tuupertunut wants to merge 30 commits into
Open
Conversation
It has been broken since it was added because its name was missing the letter s.
Nothing was actually broken because the player command happens to return the same object that is in the _player variable, but it was clearly intended to use the _player variable here.
They did basically nothing useful but were stacking new event loops on top of the existing ones so that the player could have multiple wanted loops, HUD update loops, notification loops etc.
The perk system loop that adjusts stamina based on player fitness was being created again every time the player respawned but never deleted. After a few respawns you could effectively have infinite stamina. There is no reason to bind perk and notification loops to a unit (who might die) as they are player features and not unit features, so they are separated from the player unit setup code. One loop per system is now created when the player joins the server and it keeps running over respawns.
- In some instances the command `addCuratorEditableObjects` was being called with the required parameter `addCrew` missing. - In some instances a vehicle was added for zeus before creating its crew, causing the crew to not be added. - In some instances only the crew of a vehicle was added for zeus but not the vehicle. - In some instances spawned units were only added for zeus after a delay. - In some instances spawned units were not added for zeus at all. All temporary units for NATO, gangs, resistance and civilians are now added to zeus, including their vehicles. Player controlled characters, job characters such as faction traitors and special permanent characters such as shop employees and mayors were left out of zeus view. They can be added later if needed.
There was a semicolon missing. This bug has existed since the player list was first created.
`+` has higher precedence than `call`, so this was trying to add an array to a number. This code isn't actually used anywhere so this bug is not visible in the game.
In warehouse code it was added. In arsenal code it did nothing so it was removed.
That variable is never used for drugs so this bug was not visible in the game.
- The correct ace event handler to use is ace_explosives_setup. ace_explosives_place is only called when the explosive is armed. - Units were not revealed to NATO/CRIM the same way as with other crimes. - The notification was sent to _x which does not exist here. The locality of the setCaptive and reveal commands is probably wrong like with many other crimes. This needs to be fixed separately.
Only refactoring, no functional changes.
This one was not in use. There is another in functions/player/fn_doConversation.sqf.
These pieces of code are not used so the errors are not visible in the game. Fixed just to silence HEMTT.
In commit b7f7ee9 fn_factionNATO was split into smaller functions, leaving behind a lot of NATO bugs related to undefined or read-only variables. - NATO resources would always reset to 2000. - Abandoning towers and sending aircraft did not spend NATO resources. - Air patrols and FOB raids never happened. - Cleared NATO FOBs would always respawn. - Controlled population did not affect NATO objective defence or town counter-attack cost. - NATO could not send drones to FOBs. - In some cases NATO couldn't counter-attack objectives. - NATO deploying FOBs did not affect their spending calculations. - Nato could still take a turn after countering by abandoning towers or sending aircraft.
Only refactoring, no functional changes.
This code is not currently used so this change is not visible in game.
This was first incorrectly implemented in 7fdada6 (if statement left out of the loop) and later incorrectly fixed which made it worse in b665804 (the variable _done was also moved out of the loop). I'm pretty sure the intention has always been to have them inside the loop. Translated to English the loop basically means "Update class loadouts with values loaded from the save, or if the class doesn't have a loadout yet, create a new one". As far as I know, this change should not break anyone's save.
These changes should not affect gameplay.
While placing an object, it was possible to go to the menu and start placing another at the same time. This caused floating zero cost objects. The same could happen when already placing and starting building at the same time.
These minefields are modules and can't be created with BIS_fnc_objectMapper like the rest of the checkpoint. The module could be created with createUnit, but that still doesn't spawn a minefield. I tried manually placing minefields to the sides of a checkpoint but the checkpoint guards will just walk into their own mines all the time and die, so I just turned them off for now. If minefields are really wanted on checkpoints, they could be implemented in the future.
- If a player was within spawn distance, a gang could not spawn its first members (besides the leader) because the group was missing. It's a bad idea to create an empty group beforehand and flag it as "deleteWhenEmpty" and then wait for a long time before the first member is created. Of course the group has been garbage collected by then. Now it's created only when trying to spawn the first member. - If a player was within spawn distance when a gang was formed, the gang leader would never despawn, because the gang leader group was not added to the spawner system.
Town, objective and business positions are already there. This currently only has an effect on the buggy behavior of checkpoint guards after a search, where they start following gendarme behavior.
Previously all waypoints were removed and the searcher group started acting like a gendarme patrol, no matter which role they were in. Now the previous parameters and waypoints are restored after the search is over.
- Set stability module was throwing script errors for wrong parameter type. - Set stability and set money dialogs did not have default values. - Set stability and change support modules were deleting units if placed on top of them. - Set stability module only set the stability variable locally, so the module worked only when the server was zeus.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As promised in #133, while refactoring I (and HEMTT) found many old bugs in the code. This PR fixes them and any related bugs that I found while investigating those. Many of these bugs were found by running
hemtt check --pedanticand seeing it complaining about an "undefined variable" or "invalid parameter type", and when looking at the code I realized there was a bug. All relevant HEMTT warnings have now been fixed. The remaining ones seemed to me like intentional design choices or HEMTT was wrong about them.Notable fixed bugs:
Other changes:
More info in commit messages.
I will continue fixing more bugs that I can find. I suggest merging this when you can but if this is still unmerged when I'm complete with the next batch of bugfixes, I will add them here.