Hello there, new blood here.
Just got started with 4coder a couple of days ago and I'm having a lot of fun hacking around in it.
Currently I'm trying to build a way to hot reload my customization's at runtime so I can try out new changes without having to restart 4coder.
I have a small proof of concept working but I'm having problems with key rebindings. Is there a way to do this at runtime?
The only solution I have come up with is to bind all the keys to custom commands which then calls a function pointer which is linked to the dll. But considering how many keys there are + each combination with ctrl, alt and shift. This would be a pretty insane amount of bootstrapping code to get it working.
Im a bit of a hacky scrub at c so I could easily have missed something obvious.
Just got started with 4coder a couple of days ago and I'm having a lot of fun hacking around in it.
Currently I'm trying to build a way to hot reload my customization's at runtime so I can try out new changes without having to restart 4coder.
I have a small proof of concept working but I'm having problems with key rebindings. Is there a way to do this at runtime?
The only solution I have come up with is to bind all the keys to custom commands which then calls a function pointer which is linked to the dll. But considering how many keys there are + each combination with ctrl, alt and shift. This would be a pretty insane amount of bootstrapping code to get it working.
Im a bit of a hacky scrub at c so I could easily have missed something obvious.
Edited by Rasmus Hoeberg
on
Reason: Initial post
Binding everything might not be as hard as you would think if you're going to bind everything to the same function pointer that handles the real dispatch logic:
Then you can use the API "User_Input get_command_input(Application_Links *app)" inside your single dispatch handler to see what input triggered the command redo the dispatch logic manually with a switch or something. Also, that code is probably not going to compile or handle everything as written, I'm just trying to demonstrate the idea. If you get what I'm trying to say hopefully you can fiddle around with it to make it work?
Unfortunately I don't think there's any better way to make your approach work in the current system because you cannot submit new command maps after initialization in the latest version.
A completely different route would be to save as much of the 4coder state as you can into a file, and then write the necessary code to launch a new 4coder with a different custom dll and reload that 4coder state. Probably a bit of a harder route, but it has the added side benefit of giving you reloadable state between runs at the same time.
1 2 3 4 5 6 7 | u32 binding_combinations[] = {0, MDFR_SHIFT, MDFR_CTRL, MDFR_SHIFT|MDFR_CTRL,
MDFR_ALT, MDFR_SHIFT|MDFR_ALT, MDFR_CTRL|MDFR_ALT, MDFR_SHIFT|MDFR_CTRL|MDFR_ALT};
for (int i = 0; i < ArrayCount(binding_combinations); i += 1){
for (int j = 0; j < 255; j += 1){
bind(context, binding_combinations[i], j, primary_dispatch_handler_command);
}
}
|
Then you can use the API "User_Input get_command_input(Application_Links *app)" inside your single dispatch handler to see what input triggered the command redo the dispatch logic manually with a switch or something. Also, that code is probably not going to compile or handle everything as written, I'm just trying to demonstrate the idea. If you get what I'm trying to say hopefully you can fiddle around with it to make it work?
Unfortunately I don't think there's any better way to make your approach work in the current system because you cannot submit new command maps after initialization in the latest version.
A completely different route would be to save as much of the 4coder state as you can into a file, and then write the necessary code to launch a new 4coder with a different custom dll and reload that 4coder state. Probably a bit of a harder route, but it has the added side benefit of giving you reloadable state between runs at the same time.
Thanks for the reply.
Ah that's smart. Then I guess I wouldn't have to implement any binding logic for the multitude of combinations I don't use.
I like your other idea as well because then I could add new commands to use from the command lister. Could you possibly point me in a direction of how to go about that?
Ah that's smart. Then I guess I wouldn't have to implement any binding logic for the multitude of combinations I don't use.
I like your other idea as well because then I could add new commands to use from the command lister. Could you possibly point me in a direction of how to go about that?