Freelancer Community Network
Reminder: Internet Explorer 6 or below are NOT supported.
HomeHome
ForumForum
WikiWiki
DownloadsDownloads
ForgeForge
Multiplayer Connection Tutorial
Collapse/Expand Random Image
Collapse/Expand Login
Username:

Password:

Remember me



Lost Password?

Register now!
Collapse/Expand Chat
Collapse/Expand Who's Online
38 user(s) are online (22 user(s) are browsing Forum)

Members: 0
Guests: 38

more...
Collapse/Expand Donations
Monthly costs: -30€
Income (ads): +5€
Donations (last month): +5€

Current balance: -85€
(last updated 11/2019)

Please make a donation if you want to help keeping The-Starport online:

Bitcoin address:
Thanks!
Collapse/Expand Links
Collapse/Expand Advertisement
There are currently 18 users playing Freelancer on 40 servers.
December. 6, 2019

Browsing this Thread:   1 Anonymous Users



 Bottom   Previous Topic   Next Topic  Register To Post



The big .thn/.lua research thread
Quite a regular
Joined:
2008/2/14 21:37
From İstanbul, Turkey
Group:
Registered Users
Posts: 107
Offline
I’ve been meaning to get around to document the Freelancer .thn files and what you can actually do with them for a while. I wrote some (fairly bad) tutorials about it back in the day with a lot of information that I’ve now figured out isn’t quite right and I’d like to clear things up a bit, and also share what I’ve worked out since then.

I’ll post to this thread as I work stuff out, along with an index in the OP if it gets cluttered to make referencing stuff easier. If anyone has any corrections or additions, please please post them here.

First off, some key things:


  • .thn is lua. More specifically, it’s lua 3.2. I originally figured this out by pulling a strings list out of thorn.dll (Attached to this post for anyone who’s interested), but how the scripts behave and what works has only really confirmed this.


  • lua written normally in scripts functions normally. For example, you can call things like system time, set global variables, and even read and write to your own files from outside the game (a working example of all three of these things can be found here)


  • You can call any entity, effect or object defined in the following files:

    petaldb.ini
    CHARACTERS\bodyparts.ini
    EQUIPMENT\misc_equip.ini
    EQUIPMENT\prop_equip.ini
    EQUIPMENT\st_equip.ini
    EQUIPMENT\weapon_equip.ini
    FX\effects.ini
    FX\ENGINES\engines_ale.ini
    FX\EQUIPMENT\equipment_ale.ini
    FX\EXPLOSIONS\explosions_ale.ini
    FX\MISC\misc_ale.ini
    FX\SPACE\space_ale.ini
    FX\WEAPONS\weapons_ale.ini
    SHIPS\shiparch.ini
    SHIPS\rtc_shiparch.ini
    (You can actually attach loadouts from loadouts.ini, loadouts_special.ini and loadouts_utility.ini to ships with a line under userprops, but more on that later)
    SOLAR\solararch.ini

    If you want to call an effect, you will need to initiate it with a START_PSYS events entry (more on that later)


  • I've been using this version of FLED-Thorn and the included .bat file to decompile and clean up the scripts when I need to get to the ingame ones. (Many thanks to Adoxa for this)



I’d like to start the thread off by dissecting a few basic entries from a really basic custom script from the alternate menu screen pack I made as a template for folks. The full pack can be found here, but I’ve attached the script in question to this post:

Code:
{
entity_name = "scene_seto", --How the entity is referred to in the script
type = SCENE, --The entity type.*
template_name = "", --The item model or reference defined from one of the .inis mentioned above
lt_grp = 0, --Objects will only be lit by lighting in the same lt_grp
srt_grp = 0, --This relates to how backdrops merge and overlap, but not 100% on it yet. Jeider from Nomad legacy has a better understanding of this than me
usr_flg = 0, --No idea what user_flg does yet
spatialprops =
{
pos = { 0, 0, 0 }, --Position of the object
orient = --Orientation of the object in a 3d matrix.
{
{ 1, 0, 0 },
{ 0, 1, 0 },
{ 0, 0, 1 }
}
},
up = Y_AXIS, --Defines what ‘up’ for the object is.
front = Z_AXIS, --Defines the default direction the object will face.
Ambient = { 128, 128, 128 } --Ambient lighting. Numbers are RBG values. As far as I know this is only applicable for SCENE entities
},


Things I don't yet understand the fuction of here are srt_grp and usr_flg.

*Valid options are UNDEFINED_EVENT, PSYS, DELETED, MOTION_PATH, SUB_SCENE, SCENE, HARDPOINT, MARKER, SOUND, LIGHT, MONITOR, CAMERA, DEFORMABLE, COMPOUND and UNKNOWN_ENTITY. Some of these are self-explanatory, but I’m not 100 percent on all of them just yet, notably MONITOR and SUB_SCENE.

Next I’d like to take a quick look at the cameraprops entity for Camera_0

Code:
cameraprops =
{
fovh = 30, --Field of view
hvaspect = 1.333333, --Horizontal-vertical aspect ratio(?)
nearplane = 1, --Closest the camera will render things
farplane = 1000000 –Furthest away the camera will render things
}


I mostly understand these, but I wouldn't mind some confirmation on fovh and hvaspect regarding what exactly they alter as it's not entirely clear.

After this is a monitor entity. I’m still not 100% certain what these are for. There are events present in many scripts that set monitors as cameras, but changing or removing these entries doesn’t seem to have an effect. If anyone has worked these out, please let me know!

I’m going to break this initial breakdown into a couple of posts. Lighting needs an entire section to itself I think and I’d like to try and keep this relatively neat and avoid rambling if I can.

Attach file:


zip intro_seto.zip Size: 1.26 KB; Hits: 10
zip thorn.dll.str.zip Size: 6.34 KB; Hits: 10

Posted on: 11/15 10:56
Top
Re: The big .thn/.lua research thread
Not too shy to talk
Joined:
2010/8/27 14:02
Group:
Registered Users
Posts: 69
Offline
Here is unfinished doc I was writing on THN stuff. If you want to continue from where I left off feel free to request writing rights.


Posted on: 11/15 11:40
Top
Re: The big .thn/.lua research thread
Quite a regular
Joined:
2008/2/14 21:37
From İstanbul, Turkey
Group:
Registered Users
Posts: 107
Offline
This is an absolutely brilliant document that has demystified a whole bunch of stuff for me! Thank you so much for sharing it. Going to change the format of what I had planned a bit as you've covered pretty much everything I wanted to + the bits I didn't really understand.

A few questions I still have though:

What do the values in diffuse represent? is it just an RGB value, or is it a bit more complicated than that? (Sorry if this is more of a general 3d lighting question)

I'm still not entirely clear what MONITOR does. Is it actually required to switch cameras, or is it okay to use a marker entity for this?

I've run into an issue, particularly in menu screens, where using running_lights = true under userprops results in some odd visuals (boxes around the lights). Have you had any luck getting this particular line to work properly? (Screenshot attached.)

Attach file:



jpg  running_lights_cruiser_menu.jpg (32.34 KB)
14_5dce9d40b68a3.jpg 412X377 px

Posted on: 11/15 12:42
Top
Re: The big .thn/.lua research thread
Not too shy to talk
Joined:
2010/8/27 14:02
Group:
Registered Users
Posts: 69
Offline
Glad to be of help. Just keep in mind while most information here is correct a few things aren't, I simply never got around to correct them or to continue writing it.

Monitor is meta-object representing your viewport, your screen to put it simple. Switching between cameras is event of SET_CAMERA. You should have only one monitor object in scene.

Pretty much every color there is going to be RGB, however THN is inconsistent when it comes type of values: integers ranging from 0 to 255 or normalized floats from 0.0 to 1.0. Some properties expect integer, others expect float.

Regarding lights it's just a case of textures not loaded for some reason, so it defaults to plain white color which is then tinted to whatever sprite had for diffuse color.

Posted on: 11/15 13:43
Top
Re: The big .thn/.lua research thread
Quite a regular
Joined:
2008/2/14 21:37
From İstanbul, Turkey
Group:
Registered Users
Posts: 107
Offline
Ah, that makes sense. I'll play around a bit with diffuse and see what I can get out of it.

Regarding the lights, I assume there isn't a fix for this. They were never intended to be loaded into the menu screens. I'm going to guess that getting the textures to load in correctly would probably involve an exe hack?

Also I noted in your document you suggested to use 3d modelling software to draw the paths and then import them. Which software were you using for this? Any recommendations?

Posted on: 11/15 14:38
Top
Re: The big .thn/.lua research thread
Not too shy to talk
Joined:
2010/8/27 14:02
Group:
Registered Users
Posts: 69
Offline
There is a simpler fix for lights textures, you just need a model to embed texture used by those light sprites (matching name too) and push it into scene so it'll load the resources and display those sprites.

Regarding paths I'd normally just make them in 3Ds MAX. But there isn't a readily available solution I'm afraid, so it's not like you can install it, make paths and grab em from there. For my own uses I've made a script to export spline knots and capture rotation of a dummy object to THN path key points.

Posted on: 11/15 16:34
Top
Re: The big .thn/.lua research thread
Not too shy to talk
Joined:
2013/3/16 7:49
Group:
Registered Users
Posts: 67
Offline
FYI I'm attempting (with mild success) to provide an implementation of thn with a player of sorts in Librelancer (https://github.com/Librelancer/Librelancer) but no arbitrary code execution there lol. When it's done I'll be able to publish some more thorough docs since I'll have code to base it off.

RE your lights problem, you could try and make a tiiiny model that references the textures in the txm which would get the game to load it. (e.g. a solar that references efx.txm , and DcDt mats that use "bulb" and "shine". I haven't tried this though so YMMV

Posted on: 11/28 7:55
Top
Re: The big .thn/.lua research thread
Quite a regular
Joined:
2008/2/14 21:37
From İstanbul, Turkey
Group:
Registered Users
Posts: 107
Offline
That's a pretty good idea! I'll have a go and report back

Honestly it might be worth leaving the arbitrary code in just because it does actually allow you to do some interesting things with variables and makes scripts much easier to customize on the fly.

Something else I've run into:

It seems that when loading base/planet scenes, the events section for any 'hardpoint' scripts will not execute at all. Unfortunately this prevents the use of ATTACH events in bases. I've not yet found a way around this other than putting the models I want to attach things to in the 'ambient' scripts.

Posted on: 2019/12/4 6:25
Top