Page MenuHomeFeedback Tracker

Allow overriding of SQF functions via two new commands.
Closed, ResolvedPublic


There are some situations where intercepting/overriding SQF commands could be useful for mod teams.

I suggest allowing SQF functions to be overridden via two new commands, "override" and "callOriginal".

Overriding a function would take two arguments, a code block on the left side and a string of the original SQF function name on the right side. The code block would be passed the original left/right arguments when called normally in the future via _this as an array where index 0 is left and index 1 is right, or for functions that only take right arguments, right as index 0.

To call the original SQF function a user would pass the arguments in _this sto callOriginal on the left, and a string name of the original SQF function on the right.

Return values would be handled as with any SQF code block function.

Having looked at the way SQF stores functions internally and how the calling structure is set up this doesn't seem like it would be that overly complicated to implement.


Legacy ID
Won't Fix
Feature Request
Additional Information

This would be of benefit for mods that attempt to override default functionality in the engine and replace it with their own extended or improved functionality.

Additional commands to query overridden function names might also be useful.

I have not fully explored the security aspects of a system like this.

Event Timeline

Nou edited Steps To Reproduce. (Show Details)Nov 12 2013, 6:30 PM
Nou edited Additional Information. (Show Details)
Nou set Category to Feature Request.
Nou set Reproducibility to N/A.
Nou set Severity to None.
Nou set Resolution to Won't Fix.
Nou set Legacy ID to 2491439658.May 7 2016, 5:24 PM

What kind of override are we talking about, could you give an example?

Nou added a subscriber: Nou.May 7 2016, 5:24 PM
Nou added a comment.Nov 12 2013, 8:00 PM

As in replace functionality or add code that is called before/after the internal function is called.

For example, I am working over in my head how to get rid of the action menu. A lot of that information is stored in configs, but since there is the addAction command to dynamically add items to the action menu it is a point where I'd have no control over the what is intended to be in an action menu (or its replacement). If I can override the addAction function I can seamlessly integrate a new action menu system into any previously existing content.

Other examples would be for debugging code, error checking risky calls, and any number of other things where intercepting the internal BIS call would be ideal.

addAction has nothing to do with default actions. They are part of inGameUI and are not added via addAction. If you are a "modder" you can override all that by messing with config. This is not possible for straight mission scripting.

Nou added a comment.Nov 13 2013, 2:49 AM

I have no idea what you are trying to say Killzone and I don't think you entirely parsed my last post. Please re-read it. I want to create an alternative to the BIS action menu.

KK he disables all actions in cfgActions. He is talking about 3rd parties adding new actions via addAction.
If the action menu (UI) is hidden, those will not be usable. Instead he wants to integrate new actions, in his custom interaction system.

Nou added a comment.Nov 13 2013, 7:34 AM

Yes, that is just one example of what I was suggesting this could be used for.

There are numerous other things which it could be used for such as debugging, like overriding createVehicle to log to the RPT on every vehicle creation to see what/when an addon is creating things.

Thanks kju, I think I understand now. Don't think this is something we will ever see due to complexity involved but good luck.

Nou added a comment.Nov 13 2013, 6:20 PM

Jaynus did it in Jaylib via patching, it sucked, was very complex, but I can't imagine it'd be harder to do it at the source level.

From how I understand they store the SQF functions there is essentially a list of function pointers for each command. If you just have two lists, one that can be manipulated via override, changing the pointers to the override function and is used by default, and another that can be referenced by callOriginal you'd be pretty close.

It is a pretty niche request but it'd provide a lot of power to advanced SQF users.

OK let's for a moment imagine you have the ability to override a command and make it execute custom SQF code instead of it's native c++ code. Do you realise that by overriding 1 single command you will override every single occurrence of this command everywhere, including BIS own scripts? You will be able to break the game with 1 single override. This is where it gets complicated not adding the actual redirect. I honestly think BIS will never allow this.

Nou added a comment.Nov 13 2013, 7:59 PM

Uh, I believe that was the point of my making this ticket Killzone... I feel like we are going in circles now.

I'm afraid that marginal benefit of the feature would be overshadowed by decreased performance and huge security hole it would introduce.

Mass-close of resolved tickets not updated in last two weeks.