Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
It definitely seems like there's something wrong with your system. I recommend doing some careful uninstalling and reinstalling to try to fix things. To clarify about the issue, the first legacy projected light (the one simply named "projected_light") uses the built-in Source Engine "env_projectedtexture" entity, which is also what the gmod lamp tool uses. The second legacy projected light and the updated new one both use "ProjectedTexture" objects, which are client-side objects and essentially just simple handles for controlling the projected light effect itself. It seems like there's a discrepancy between them on your system that's not there for others.
I just played around with "r_flashlightdepthres" for both the old versions and the new one, and everything worked exactly the same. I even tried spawning an old projected light and converting it to a new one using the "advlights_update" concommand with a delay while looking at the shadows, and I did not see any difference. I think the issue you're having is on your side, and is a difference between the built-in "env_projectedtexture" entity and the gmod "ProjectedTexture" object. Is there anything unusual about your gmod installation or the system you're running it on?
also is there a way to make the menu appear in the middle of the screen by default like it used to?
Well, I guess It is not deleting lamps from previous savefiles.
But It happened the opposite way, I started using updated Lamps, but when I realized I can't use SMH with updated version, I used "advlights_legacy 1" in console. After I reloaded Gmod, all New lamps disappeared, so I had to place Legacy lamps from scratch. It took just a few minutes to place them back as Legacy version, but It scared me, like it could possibly happen with my old savefiles. Thanks anyway.
No problem. I need to finish thinking through the new system that I've implemented for organizing code, then I'll contact the SMH devs and try to help them interface with the new content.
This update should NOT delete anything from previous saves or otherwise break any existing content for the old version, as everything from the old version still exists in this version, including all six original entities! The "advlights_legacy" convar only removes the spawn menu options when it's set to 0. Are you SURE that old content is being broken? If it is, I need details, as you are the first person to suggest that content for the old version (saves, etc.) is breaking after the new update.
I really really wish ability to turn addon to Legacy version will stay forever, because I used it SO MUCH in my unfinished project, and it will be the loss of everything if I won't be able to restore the light.
Right now I turned it to Legacy because I couldn't animate new version with SMH.
It's will be much better if you'll somehow upload maybe on Google Drive or on Workshop the real Legacy version, so I'll be able to restore everything.
Or maybe restore the update here, and add newer version as the "NEW Updated Advanced Light" one. Just notify people, that you can use one or another, but not both versions.
This is a way too big change that deletes all the light from previous Savefiles and etc.
The "advlights_legacy" convar should let you permanently change to the old one, as the convar is archived and replicated and restores everything from the old version (except for spawn icons). But please tell me what problems you're having with the new version!
As for how it works, I'm fairly certain what SMH does is that it simply makes the brightness slider (for example) go up and down depending on the distance of the keyframes from each other. Because if I drag the timeline slider from one keyframe to another, I can see the entities brightness slider gradually go up and down. (From 10.00 to 5.0 to 0.0)
That's very strange. The new entities work the same as the old ones, with networked variables that control the light properties. I'm not familiar with Stop Motion Helper, but I would assume that it just sets the networked variables. The only thing that's different about the new ones is how they interface with the new editor system. This is probably an issue with SMH, and I'll try to investigate.
Are you talking about new light entities that you have added to a project after the update, or are you talking about legacy entities in an existing project? Or, are you talking about legacy entities in an existing project that you have converted to new entities with the "advlights_update" concommand? I assume it's the first of the three, but I want to be certain.
Basically, before this new update, I could tag the light entities and add them to my timeline in SMH. If I changed the brightness slider, etc... the different keyframes would make the light go brighter or dimmer for example.
Now, it is completely unaffected by SMH. If I put the light at 10.00 brightness and make it a keyframe then add another keyframe where the light is at 00.00 brightness, it doesn't change. That's the simplest way I can put it. (Just in case your command doesn't change it)
The new entities work the same way as the old entities, so I don't understand why that would break. What exactly is going wrong when you try to use the new entities? Also, remember that you can restore the old entities to the spawn menu by setting "advlights_legacy" to 1 and restarting.
Remember that you can restore the old entities to the spawn menu by setting "advlights_legacy" to 1 and restarting. Is there a reason you want to use the old ones? The new ones should have all the features and capabilities of the old ones.
no more problems, thanks for the prompt fix. I have always used, am using, and will continue to use such wonderful lighting
-- The issue where files not opening on the client caused the mod to not load
-- The performance issues with the expensive lights
-- The issue with the UI not working with the Dark UI mod
If any of these issues persist, please tell me!
Using the ui, I have a problem in the form of white light on the scales. YaBoiTomScout showed a suitable example
Thank you! I think I know what's going on here. Expect a fix soon.
Before: https://steamproxy.com/sharedfiles/filedetails/?id=3551824734
After: https://steamproxy.com/sharedfiles/filedetails/?id=3551824684
To clarify, both of the original/legacy expensive lights are giving you performance problems that were NOT there in the old version of the addon? And this persists even when "advlights_legacy" is set to 1? If so, I do not see how that is possible, as I quite literally copied and pasted the entire content of the old version into the new version (which works because the new version uses completely different file structures and naming conventions), and the only changes I made to the old code were a few checks for the legacy convar, as well as changing the texture file from a vtf to a png and loading it accordingly. The only thing I can think of that could do anything like this is the new texture. I can try to use the old texture again, but I would prefer not to if possible. You're not the only one having this issue, correct?
I have seen a few people talking about issues with the UI. Does the text show up too light for you? If so, I think I can fix that, but the fact that this happens suggests that the dark UI mod is doing things it shouldn't.
Are you talking about reverting to the old version? What issues are you having?
Based on that error message, it's simply failing to open the Lua file on the client. My loader system is attempting to open the client-side init file (x0110000105206010/advlights/1/cl_init.lua) using the "file.Open()" function, but the function gives nil instead of a valid file handle. It reports that the file exists, but gives 0 for the size and refuses to open it. This could be a load-order issue as you described, where the file is somehow not sent to the client by the time that the loader system needs to open it.