User avatar
Lapin
Posts: 262
Joined: Mon Dec 24, 2012 12:35 pm
Location: There's no place like 127.0.0.1
Contact: Website

Hooking engine-close function/LuaJIT+LuaFFI/Native binary modules support/Threaded Lua instances/[Gfx/Scaleform lib]

Mon Dec 14, 2015 12:06 am

Having access to engine function, thinking about camera angles/pos hooking for making VR mods in C++/Lua would be nice, it would also allow cinematic mods (anything related to custom camera for specs/movies cameras) would be useful.


LuaJIT is going to be required if we want to make mods with LuaFFI (so with external binary modules), LuaJIT also give really nice performances compared to Lua 5.1/5.2/5.3.*



About mods, if we really want to mod it we're going to need an external x64 malloc-ator (i know it's not a word) using VirtualAllocEx->WriteProcessMemory (As far as i remember, BF3 is not a x64 build, right ?)


That's why a native binary module support is maybe going to be required (Or just a D3D9 proxy if we just want an external malloc-ator), because even LuaFFI has limits.

Something with custom dll entry and exit





A way to start a Lua thread (so using a new lua state) would also be useful, or at least make the Lua engine using it's own thread, maybe BF3's Lua integration already has it's own thread, idk.


A way to acces to some basic draw function (images, shapes (maybe poly draw)) would be nice, with some gfx function like stencils. Or just Scaleform .gfx support
Last edited by Lapin on Mon Dec 14, 2015 10:51 am, edited 1 time in total.
Ding dong bannu

User avatar
mizudg
Posts: 1620
Joined: Mon Apr 01, 2013 5:09 pm
Location: Bulgaria
Contact: Facebook Skype YouTube

Re: Hooking engine-close function/LuaJIT+LuaFFI/Native binary modules support/Threaded Lua instances/Gfx/Scaleform lib

Mon Dec 14, 2015 12:40 am

On a side-note : Oh, you're alive! Welcome back!
Image

User avatar
NoFaTe
Blazin' your Brains!
Posts: 520
Joined: Sun Dec 16, 2012 7:22 pm
Contact: Website

Re: Hooking engine-close function/LuaJIT+LuaFFI/Native binary modules support/Threaded Lua instances/[Gfx/Scaleform lib

Mon Dec 14, 2015 8:17 pm

Venice Unleashed already uses Lua internally (with LuaJIT) for the VeniceEXT extension system. Through that system we expose a lot of engine functionality, along with various hooks and events for important engine functions.

However, we will not allow native code loading and execution (either via FFI or some other method) because of the serious security implications that come with it. In other words, if you want to functionality that's not yet available through the VeniceEXT extension system, you'll have to let us know.

As for the UI, we opted not to use Scaleform, since not only does Frostbite utilize it in a very non-standard manner, but also because we would be limiting the ability of people without the GFx SDK to create custom UI solutions for VU. Instead, VU offers a completely separate UI system, with which you can create fully custom UIs and interactions using technologies such as HTML, CSS, JavaScript, and WebGL (in conjunction with the VeniceEXT system).
[03:55:41] <~Bag> Yes, I can put things inside me when I need to

User avatar
Lapin
Posts: 262
Joined: Mon Dec 24, 2012 12:35 pm
Location: There's no place like 127.0.0.1
Contact: Website

Re: Hooking engine-close function/LuaJIT+LuaFFI/Native binary modules support/Threaded Lua instances/[Gfx/Scaleform lib

Tue Dec 15, 2015 12:32 am

Securities problem linked to LuaFFI, i get it, but what about some kind of "Safe folder", where "dangerous" functions can be used, but not by files sent by the server (I guess Shared/Clientside mods stored on the server are sent to the client while he's connecting).


Here what i'm talking about, to be honest i have like 0 idea of how's the system is working right now.

Let's say this is the "normal" Lua mods system.

Serverside : Stored on the server
Shared code (for common functions) : Stored on the server
Clientside code (for the server mods) : Stored on the server and on the client if he want some custom hud elements


Player join the server -> Download the compiled (with luajit.exe -b )(or compressed) Lua code -> Compiles it and stored in a folder called

./Mods/Lua/ServerIP_Port/*


Player can put his own mods in :

/Mods/Lua/Local/



And mods with dangerous function in

Mods/DevLua/Local/
Only him can put lua files there, the server cannot store it there, so only him can do shit with his computer.


To be honest i don't think you don't want modders to ask you to put addnew code/libs/funcs ever weeks.

Or maybe by "security problems" you mean cheatings, i don't know.


Let me explain the problem, i got a Private API and a dev license for TrackIR, and a NDA saying i can't release the source code, so yeah, there is a Lua part but the other part is in C++ (Can also be done in C#, if you want peoples to dis-assemble it easily).

Or we can forget all this shit and i should maybe make a .lib file so you can bind the functions and then make some calls from Lua.
Ding dong bannu

User avatar
NoFaTe
Blazin' your Brains!
Posts: 520
Joined: Sun Dec 16, 2012 7:22 pm
Contact: Website

Re: Hooking engine-close function/LuaJIT+LuaFFI/Native binary modules support/Threaded Lua instances/[Gfx/Scaleform lib

Tue Dec 15, 2015 8:04 pm

If you want to communicate data from an application (ie. coordinates from your closed-source TrackIR system), VeniceEXT will provide support for network sockets, which you can utilize for such occasions.
[03:55:41] <~Bag> Yes, I can put things inside me when I need to

User avatar
Lapin
Posts: 262
Joined: Mon Dec 24, 2012 12:35 pm
Location: There's no place like 127.0.0.1
Contact: Website

Re: Hooking engine-close function/LuaJIT+LuaFFI/Native binary modules support/Threaded Lua instances/[Gfx/Scaleform lib

Tue Dec 15, 2015 8:34 pm

Oh, nice.
Ding dong bannu

Return to “Rejected”

Who is online

Users browsing this forum: No registered users and 1 guest