Camera Light - Illuminate your development experience

First I want to say I’m glad we’re having this conversation, and that you’re willing to entertain some of the points I’m making.

Nob back to the regularly scheduled program, haha.

Yup! I think we’re more in agreement than either of us think.
My analogy with the free-market economy was mostly just that, an analogy.

To quote Wikipedia,

“…a free market is an economic system in which the prices of goods and services are determined by supply and demand expressed by sellers and buyers. Such markets, as modeled, operate without the intervention of government or any other external authority.”

Which is what I believe we’re seeing here. Again, just an analogy. Roblox doesn’t really step in much to influence prices (except for their 30% cut, but that can be alikened to tax). And the selling of plugins is kind-of reminiscent of the supply-demand equilibrium. Higher cost = less buyers. And you’re absolutely right that developers ought to find a price that strikes the balance between a good cost and a good value. And of course if they don’t do that, they’re going to feel the reprecussions for their own actions.

I see your point, what I’m saying sort of plays into my previous statement about sales.
In the real world, companies have to advertise their products. Here, most of the really popular plugins either have a really good description or a good DevForum post, it’s what makes them attractive, as I think you somewhat implied.

Granted, I’m somewhat biased. If none of the popular plugins I look at have a specific feature I want (or if they’re too expensive), then I just make my own plugin – that’s actually how most of the plugins I’ve created came to be. If you know scripting, it’s actually a surprisingly straightforward process.

In any case, while I realize that doing research is impossible sometimes, I don’t see why you would purchase plugins that have no context or rep to them, even if they advertise having that feature.

I’m not terribly sure about this one. I may be wrong, but I don’t think any country mandates refunds for customers, unless there’s something like a mass-recall. In most cases that I’ve seen, returns are handled exclusively by the producer, unless you’re thinking about doing a middle-man thing like Amazon does, which I’d say is reasonable. And this is often done because it’s easier to just issue a refund, rather than having to deal with a customer that is stirring up a stink. In other words, it’s often part of the business model.

As far as allowing you to test plugins, not sure how that would be accomplished in a secure-for-the-developer fashion. The general rule of thumb I go by (mostly for exploit-proofing) is that if the client has access to source code on a machine-level, then the exploiter has the full capacity to steal it. I would apply that same concept to this situation.

1 Like

Which is what I believe we’re seeing here. Again, just an analogy. Roblox doesn’t really step in much to influence prices (except for their 30% cut, but that can be alikened to tax). And the selling of plugins is kind-of reminiscent of the supply-demand equilibrium. Higher cost = less buyers. And you’re absolutely right that developers ought to find a price that strikes the balance between a good cost and a good value. And of course if they don’t do that, they’re going to feel the reprecussions for their own actions.

But from what I’ve seen, Roblox does step in to influence prices. Plugins have been deleted for what’s essentially an overly high price to functionality ratio, which is a regulation on the pricing. There’s also a price floor on 100 Robux for plugins. Plugins are also regulated for a lot of other reasons.

Granted, I’m somewhat biased. If none of the popular plugins I look at have a specific feature I want (or if they’re too expensive), then I just make my own plugin – that’s actually how most of the plugins I’ve created came to be. If you know scripting, it’s actually a surprisingly straightforward process.

Plugins for me are a time saving resource, if I can save a single hour or two just once, it is well worth it paying $30-$40 let alone 500 Robux. I have been scripting professionally and privately for over a decade, so making plugins is not a problem, but I’d be unlikely to save any time at that point. One of the systems I needed at one point, was a quick way to load different accessories onto rigs for something I wanted to do once. Building a system for that would be far slower than manually adding the accessories twice, which is what I needed.

In any case, while I realize that doing research is impossible sometimes, I don’t see why you would purchase plugins that have no context or rep to them, even if they advertise having that feature.

Because they’re cheap enough it’s worth the risk. And again, they can have a context or rep, but just be rather tiny, so you don’t reaaally know. Ideally though, I should still not eat the loss for a bad product, no matter how small the loss is or calculated the risk was.

I’m not terribly sure about this one. I may be wrong, but I don’t think any country mandates refunds for customers, unless there’s something like a mass-recall.

The EU Consumer Rights Directive by default has a 14 day refund right even when nothing’s wrong with the product. When the product has defects or isn’t as advertised, the protections are even better.

Here’s a direct quote

• The period for consumers to pull out of any distance purchase (e.g. something bought online) or off-premises purchase (such as when a seller visits
the consumer’s home) is extended from the previous minimum 7 days, to a
uniform 14 days across the EU. These 14 days start counting from the day
the consumer receives the goods, and the consumer has the right to cancel the purchase for any reason. When a seller hasn’t clearly informed the
consumer about the right to cancel the purchases, the return period will be
extended to a year.

Some EU countries have even stronger consumer rights, so in reality there are plenty of countries. The law is a little complicated so I won’t go into too much detail, but there are some points around whether something is digital content or a digital service, and sealed software vs unsealed software. None of this matters though once you throw a faulty product into it.

In other words, it’s often part of the business model.

Things become part of the business model because consumers expect it. Consumers come to expect it because of culture and regulation. So it’s really not that simple.

Look at GDPR for example, EU citizens have become very entitled to having their online information deleted(a good thing). Regulations are a strong driver of consumer expectation.

As far as allowing you to test plugins, not sure how that would be accomplished in a secure-for-the-developer fashion. The general rule of thumb I go by (mostly for exploit-proofing) is that if the client has access to source code on a machine-level, then the exploiter has the full capacity to steal it. I would apply that same concept to this situation.

It’s really not too complex. You host the plugin in a secure environment. Roblox can boot up a test server where the plugin is hosted, and then the developer only interacts with the plugin through UI. The logic is containerized.

If the logic can only possibly be executed on the client, then it’s naturally not an option, but I doubt the plugin would be that tempting to steal in the first place then. Most plugins could offset their logic to a server with the only issue being a communications delay.

But even that could be secured, though I wouldn’t recommend it. You’d just have to render the visuals elsewhere and stream them to the client.

Stuff can also be secured well enough on the client. Clients can have access to source code without it being feasible to steal because the effort just wouldn’t be worth it for a roblox plugin. Denuvo has clearly done remarkably well for itself. Star Wars Jedi Survivor has been out for a year and not been cracked. Nowhere near the same level of protection would be necessary for a roblox plugin, for which there are a far fewer interested consumers.

1 Like

Ollie, I like your plugin. Thank you for contributing to the dev forums. My best advice: don’t engage with people on the internet. Not worth it at all. If you make something, enjoyed the product you delivered, you charge for your service. Anyone with a brain can see that. Keep up the good work.

3 Likes

Chat did he get banned?

No one likes toxic ppl

1 Like

Just from the first post’s screenshot, I could tell this plugin could be a nice spiritual successor to WorkLight, a plugin that hasn’t been updated in a while, so I bought it!

From the few minutes I’ve used it, it’s pretty good but I have a couple suggestions:

  • I like that the light can be offset from the camera, something WorkLight couldn’t do, but once it’s off-center, there isn’t an easy way to “center” the light again. I think each slider should have a textbox off to the side so I can enter “0” to re-center the light, or a button that sets the offset back to 0, 0, 0.
  • The invisible part can be selected using the Select tool, so it could get in the way if I used it while working on something. I don’t understand it, but Roblox added a new StudioSelectable collision group.; Maybe the invisible part could be put in its own group, not marked in the StudioSelectable group?
  • When I used WorkLight, I used File > Advanced > Customize Shortcuts to assign SHIFT+CAPS LOCK to toggle it, which was a pretty quick and useful way to turn it on when I entered a dark area or needed to preview PBR textures on a 3D model. Camera Light only has one action, to show/hide the plugin’s panel. I think an extra “toggle” action would basically make this the replacement for WorkLight.
  • I don’t think I’m ever going to change my light’s color from pure white, so I don’t really need to keep the color picker visible, but it’s grouped with the brightness/range sliders. I would like to be able to hide that section and just show the brightness, range, and offset sliders.
  • Lastly, I don’t know if it really matters, but the invisible part should probably have its “Archivable” property set to false so it can’t be saved to places. (I’ve heard Team Create destroys cameras so this won’t affect places with it enabled, but local places could get saved with an invisible part in the camera instance.)
2 Likes

These are really great, I’ll do all of this and send it out as an update later, thanks for your feedback :slight_smile:

1 Like

UPDATE 1.0.0

  1. Placed the “Color” feature into a Customization collapsible section so it isn’t constantly visible in the viewport.
  2. Changed the offset range to -50, 50 and set the increment to 5, this means it’s easier to reset and drag the sliders at precision.
  3. Added a plugin action that enables and disables the camera light. To set a keybind for this action, instructions can be found on this page.

Let me know of any more improvements I can make!

2 Likes