vemanager's Introduction

VEManager

A Visual Environment manager for Venice Unleashed.

It's used to create and manage VE presets. Presets can either be created with VEEditor or CinematicTools.

Youtube Tutorial Series

https://youtube.com/playlist?list=PLqlU85EO4crIPxk10YXiKDXE67lU-dM4m

If you have questions contact IllustrisJack#5355 on Discord.

Config Options (Shared/VEM_CONFIG.lua):

A number of features can be switched on/off from the config file located at Shared/VEM_CONFIG.lua

DEV_ENABLE_CHAT_COMMANDS = (true/false)							Enables the use of these chat command
DEV_ENABLE_TEST_KEYS = (true/false)								Enables the use of test keys / shortcuts

For more options, have a look in Shared/VEM_CONFIG.lua.

DEVELOPER CHAT COMMANDS

The following commands can be used: (provided that DEV_ENABLE_CHAT_COMMANDS is set to true)

  !preset PRESET_NAME				Enables a preset of your choice
  !setnight						Sets day-night cycle to night
  !setmorning						Sets day-night cycle to morning
  !setnoon						Sets day-night cycle to noon
  !setafternoon					Sets day-night cycle to afternoon
  !pausetime						Pauses day-night cycle time (pauses presets to current state)
  !disabletime					Disables day-night cycle (reverts to initial preset)

vemanager's People

Stargazers

Watchers

vemanager's Issues

[Bug] Skybox and other CtrRefs are fucked up

Blue Skybox, black skybox, etc.

The serialization of CtrRefs (instances) is as follows right now:

"ColorGradingTexture": "sol.sol::detail::unique_usertype<VeniceEXT::Classes::Shared::DataContainer>: 40E3F4F0"

Saving this as a string is obviously retarded. We have to not overwrite these values or implement a proper serialization. If we do a proper serialization, the type should be the one required by the component referencing it, and not just datacontainer.

Multiple unnecesary calls to SetVisibility( ) for presets that are already destroyed.

How to see the issue:

Enable only VEM in the mod list (I re-added the chat commands for my comfort, I'll be sending another PR for this later), make a simple script or a little hardcode to force the TimeServer:Enable with default values as soon as you get in the server so the time passes.

The issue is in the _Run method inside Time (client module side) where we are calling SetVisibility many times for presets that aren't even necessary at a given time (since they are for example morning or noon but its 2 AM) so they get called with SetVisibility 0, this causes the preset to be Initialized and almost inmediatly after that get Destroyed by the same logic of SetVisibility going to the DestroyVE since its visiblity is 0.

Possible Fix:

Check for m_VEMHandler:CheckIfExists( ) to only call SetVisibility if the preset actually exists inside _Run but this can cause more issues, idk.

The best way would be to debug and check that the currentPreset and the nextPreset are the only ones being correclty existing in the _Run method for the time we see.

[Bug] Disabling a preset doesn't work if its in the process of fading / lerping in

As the title reads, if you disable a preset, it doesnt effect the fading in and probably fading out process.

Test Issue

[Lua - VE - Bug] VEs are not server synced

After #35 VEs are not synced anymore

Client crash on map change

Hi,

I've just deployed a new server in VU with the mod but every time a map is changed via normal round ending.
Not sure if this mod is active anymore but decided to try to reach you.

I'm using the latest release of the mod with VU client and server version 19006. Also tried with "-updateBranch dev" as command option which updates to 19042 but it faced the same problem.

Is this something that is with vu version or am I configuring something wrong here.