LightMeUp (obsolete, use FocusOnMe!)

Plugins LightMeUp (obsolete, use FocusOnMe!)

CheesyFX

Well-known member
Featured Contributor
Messages
737
Reactions
3,205
Points
93
CheesyFX submitted a new resource:

LightMeUp - Spawns up to 3 colored headlights you can quickly toggle via shortcuts

You want to watch your favourite scene from a different perspective, but that specific angle your interested in isn't lit well? Does your favourite scene creator give a shit about lighting? Don't worry, just install this plugin.

This plugin will spawn up to three headlights (no atoms = no scene clutter) parented to the camera view. One in the center facing forward, and an additional one on each side, tilted to light up the objects in front of you. By default, the center one is white, the...

Read more about this resource...
 
CheesyFX updated LightMeUp with a new update entry:

Improved shortcut behaviour & adjusted defaults

If the global toggle state is off (default after loading), every hotkey toggles it to on, like the Numpad+ key.
I also increased the default angle of the spot lights from 90 to 120 degrees for VR. Depending on the FOV of your headset you could otherwise see the lights fall off, leading to the impression of a torch light, which is not intended by default.

Read the rest of this update entry...
 
I'm really enjoying the plugin, but I don't like the shortcut creep that is happening, especially since we already have collisions, and there will be more. I've already had to uninstall other plugins that had hardcoded shortcuts that were colliding with stuff, and I don't like this to be the next one.

For example, if I want to write `-0.5` into a morph value field, this plugin picks up the `-` key and starts toggling lights.

It'd be way better to unbind all shortcuts by default, and instead integrate with Keybinds by AcidBubbles to allow users to bind these features to their preferred keys.
 
I'm really enjoying the plugin, but I don't like the shortcut creep that is happening, especially since we already have collisions, and there will be more. I've already had to uninstall other plugins that had hardcoded shortcuts that were colliding with stuff, and I don't like this to be the next one.

For example, if I want to write `-0.5` into a morph value field, this plugin picks up the `-` key and starts toggling lights.

It'd be way better to unbind all shortcuts by default, and instead integrate with Keybinds by AcidBubbles to allow users to bind these features to their preferred keys.
I can totally understand your concern. In fact, i haven't thought about the "-" in input fields. Maybe i can disable the shortcuts while a text or float input is expected. The problem with keybindings is: i don't use it and i don't want my plugin to depend on it. Maybe i'll provide an option to disable native shortcuts and refer to keybindings instead. But first, i have to look into how it's done. Also, the intensity adjustment could not work as it does right now, since keybindings does not continuously trigger while the key is down.
Anyways, thanks for the feedback.
 
i don't use it and i don't want my plugin to depend on it

Why not? Keybinds is free and solves so many issues.

It's a sensible solution to a growing issue of managing plugin shortcuts, to which you are contributing right now. It's not feasible or realistic for every plugin to hardcode their own shortcuts and hope they suit every user and don't collide with anything. Integrating with keybinds gives you a guarantee of no inter-plugin collisions, and keybind editing UI for free.

From what I've seen and recall, integrating is really simple, and I think you can bind down/up listeners so hold to increase should also be doable, but even if I'm wrong, I'd actually prefer a static press for +0.1 intensity which lets me guess the final value and control rampup speed by speed of pressing, rather than hold to wait for an ugly float result.

Also, a "Reset to configured intensities" shortcut would be nice. But that just adds one more potential collision if hardcoded, so I'll pass if you decide against integration.

But going the Keybinds route would allow you to add many different shortcuts for resets, hold to change, press to change, etc. and then let users pick and choose which they want. And it's not like the plugin needs the shortcuts. It works without them thanks to the buttons.
 
Why not? Keybinds is free and solves so many issues.

It's a sensible solution to a growing issue of managing plugin shortcuts, to which you are contributing right now. It's not feasible or realistic for every plugin to hardcode their own shortcuts and hope they suit every user and don't collide with anything. Integrating with keybinds gives you a guarantee of no inter-plugin collisions, and keybind editing UI for free.

From what I've seen and recall, integrating is really simple, and I think you can bind down/up listeners so hold to increase should also be doable, but even if I'm wrong, I'd actually prefer a static press for +0.1 intensity which lets me guess the final value and control rampup speed by speed of pressing, rather than hold to wait for an ugly float result.

Also, a "Reset to configured intensities" shortcut would be nice. But that just adds one more potential collision if hardcoded, so I'll pass if you decide against integration.

But going the Keybinds route would allow you to add many different shortcuts for resets, hold to change, press to change, etc. and then let users pick and choose which they want. And it's not like the plugin needs the shortcuts. It works without them thanks to the buttons.
There already is a shortcut to reset the intensities: CTRL+<x>. See the main post. I have a new version almost ready which lets the user configure the shortcuts. It will release soon.
Why not Keybinds: I tried it for a short while, but despite me saving it as a session default, i had to manually set up the few shortcuts i liked (i.e. copying atoms) on every startup. So, it was really not that useful to me. Also, i want full control of the shortcuts. Maybe you're right and Keybinds can do everything i want, but its easier for me to just code it myself instead of reading how it (eventually) could be done in someone elses api.
 
Last edited:
i had to manually set up the few shortcuts i liked on every startup

Keybinds has a save button above the search bar, so that you don't have to go to "Save as session default" every time.

I'm absolutely certain that integrating with this: https://github.com/acidbubbles/vam-keybindings#integrating-your-plugins
is orders of magnitude less work than writing your own UI for binding and managing shortcuts. I've skimmed through the very brief example/docs, and it does supports down/up events if you pass it `JSONStorableBool`.

It's nice when people have all of the shortcuts management in one place so that they can search throught and see what is bound to what and re/un-bind stuff to their liking. It's a nightmare when something happens after I pressed something, and now I have to go look through all of the plugin's UI's and readmes to find which one is occupying the shortcut I've just pressed if they don't use Keybinds.

But if you really want to make your own UI, at least don't forget to add an option to unbind each shortcut.
 
Last edited:
My current UI is rather simple. You can set the 4 main keys my plugin uses. It's your responsibility that no other plugin occupies that key. I don't exactly know what you mean by "unbind". Set to "None", aka not use it? I'll definitely not scan every other plugin for their shortcuts and unbind them if you happen to set a shortcut to a key already used elsewhere. If that is what you meant...
I'll see. Maybe i can provide an option for Keybinds if it's doable and integrates well with the system i already set up. I don't want the keys to behave differently if you switch from native to Keybinds.
 
Last edited:
I don't exactly know what you mean by "unbind"

An ability to disable/remove the keybind for an action completely, so that if I don't want to use it, it won't have to occupy a shortcut. I've already encountered plenty UI's that don't provide this option.

It's your responsibility that no other plugin occupies that key.

If plugins just used Keybinds this wouldn't be necessary.
 
Every time I try to load it :

!> Compile of CheesyFX.LightMeUp.4:/Custom/Scripts/CheesyFX/LightMeUp/MacGruber_Utils.cs failed. Errors:
!> [CS246]: The type or namespace name `CheesyFX' could not be found. Are you missing an assembly reference? in <Unknown> at [21, 7]


And the plugin doesn't run. I can't get to the customisation page or anything. :-(
 
Try updating to v.5 and load 'CheesyFX/LightMeUp/ LightMeUp.cslist'.
 
Great, thank you. One suggestion.:
Could you maybe add more options to move the lights on all axis?
I want a constant back Light (Light facing me from far away) but positioning that light thtat way isn't possbile currently
 
I want a constant back Light (Light facing me from far away) but positioning that light thtat way isn't possbile currently
Nice idea, but I tried it and it doesn't look good/right. Plus: What if you step back? Then the backlight would become a front light. And what if you look down? Then the light would come from below, or, in most cases, will be blocked by the floor.

Edit: I think I can put this to a whole new level. It also goes hand in hand with a future plugin i'm about to release. Stay tuned.
 
Last edited:
Nice idea, but I tried it and it doesn't look good/right. Plus: What if you step back? Then the backlight would become a front light. And what if you look down? Then the light would come from below, or, in most cases, will be blocked by the floor.

Edit: I think I can put this to a whole new level. It also goes hand in hand with a future plugin i'm about to release. Stay tuned.

Yes true, you would need to be in the right position for the backlight to also be positioned correctly.
Cool, good to hear =)
 
Back
Top Bottom