Saints Row: The Third Advice needed on a lua file (Sandbox+)

[[V] IdolNinja]

I fixed the missing end and it crashed at the same point.

I'll look into it later after I finish updating GotR.

 

[[V] tulip.sniper]

I fixed the missing end and it crashed at the same point.

Does it crash if you spawn a thread with a very simple function that doesn't try calling any SR specific functions? This is most likely a problem with sytem_lib.lua being loaded early on during system initialization, and trying to call functions that either haven't been registered or are acting on uninitialized data.

 

[[V] IdolNinja]

What about trying to use either vint_lib.lua or ug_lib.lua?

 

[[V] tulip.sniper]

I did not work on SR2, and wasn't even aware ug_lib.lua even existed.

Doing a quick look at that file, it would appear that ug_lib.lua was the predecessor to game_lib.lua and likely functions the exact same way for this hack. No idea what UG stands for (maybe Utility Gameplay?), but likely was renamed to game_lib early on during the development of SR3. Some interesting history there.

As far as vint_lib.lua, it would possibly work, but your new thread would reside in the Interface Lua state, which I don't think you guys are wanting.

 

[InnocentSam]

I tried ug_lib.lua which got to the loading screen after loading/starting a new save before crashing. No silly mistakes like a missing end this time, I swear

EDIT: Keycombo function is at the very bottom, button is on line 5, and the airport.lua include is at line 179.

 

[[V] tulip.sniper]

UPDATE:

I had a chance to look into this a little bit more.

After looking into how the SR2/SR3 engine handles the Lua threads in more detail, simply adding a call to thread_new() outside of an existing thread like I proposed will not work. A lot of the backend code that handles our implementation of Lua threads in SR2/SR3 goes to lengths to ensure all threads are safely encapsulated so that we don't end up with rouge threads that got created and never cleaned up. So, any call to thread_new() outside of an existing thread will NOT work.

I'm still investigating a possible work around, but the current approach is a dead end unfortunately.

 

[[V] IdolNinja]

UPDATE:

I had a chance to look into this a little bit more.

After looking into how the SR2/SR3 engine handles the Lua threads in more detail, simply adding a call to thread_new() outside of an existing thread like I proposed will not work. A lot of the backend code that handles our implementation of Lua threads in SR2/SR3 goes to lengths to ensure all threads are safely encapsulated so that we don't end up with rouge threads that got created and never cleaned up. So, any call to thread_new() outside of an existing thread will NOT work.

I'm still investigating a possible work around, but the current approach is a dead end unfortunately.

Good to know, especially since I didn't waste any time troubleshooting it yet.

 

[[V] tulip.sniper]

Without modifying the executable, there is not a good way to spawn a new Lua thread for the client in the Gameplay Lua state.

I'm putting support for loading arbitrary Lua files and creating threads on the client at the top of my list of potential features to hopefully support in the near future. Enabling the developer console will go a long way towards this goal.