[Nuke]

i was thinking it might be very usefull to have metadata fields in various game files that can be accessed by the scripting system. variables can be read, written, created, or deleted from theese metafields. good places to have metafields would be the player files (theyre being redone anyway, right), missions and campaign files, tables, perhps models as well (META chunk, or stored in submodel properties). most of the metafields would be in read only mode, so as not to screw with multiplayer. player files would be the only exception, as this is the best place to store dynamic variables, for things like cashflow and legal status. the read only fields are to allow modders to add data that will be handled by script and ignored by the engine. this also allows modders with no scripting ability to use scripts other people have written. for example if i were to write a script for atmospheric flight physics, modders can add metatags to tables for lift characteristics and drag, and missions get the option wether or not to use activate that part of the script. it seems like it could be very a very versitile feature that could be implemented with very little hassle. all the text based formats can be edited to include meta very easily, player meta fields would be added dynamically through scripting. the scripting system would need to be modified to recieve and edit metafields, and the engine would need exceptions to allow the fields to be presant and not cause an error. it would really add versatility to the whole thing.

[Ferret]

Paragraphs?

[WMCoolmon]

Lua does have builtin file I/O functions. They're not a very good choice for Linux compatibility (Unless you go to the trouble of checking for and saving in the user's home directory), but it wouldn't be impossible to add the default Freespace 2 write functions.

[Wanderer]

Could we use the forthcoming ship or rather shipclass specific scripts (with scripting tbms) for dealing atleast part of this stuff?

[Nuke]

Could we use the forthcoming ship or rather shipclass specific scripts (with scripting tbms) for dealing atleast part of this stuff?

along those lines mission and campaign specific scripts (possibly imbedded).

Paragraphs?

dude, it was barely long enough to require any line breaks 

[Goober5000]

Dude, paragraphs are A-1 SUPAR.

[taylor]

Dude, paragraphs are A-1 SUPAR.

But it's much easier to ignore them when you actually have to work to make sense of their posts.  When I see something like that, I just ignore it, since it's one less feature to have to spend time on. 

[Goober5000]

But it's much easier to ignore them when you actually have to work to make sense of their posts.  When I see something like that, I just ignore it, since it's one less feature to have to spend time on. 

You know, I end up doing the same thing, but this is the first time I've seen it spelled out in words.  Brilliant. That can be one of our stock rejection criteria: didn't bother to format his post; doesn't respect the coders; request denied; thread closed.

[Mongoose]

Oh, come on; that is a paragraph.  It doesn't even come out to half a screen at 1024x768.

[Flipside]

Well, to be fair to both sides, Nuke has some great ideas and is one of the few people really using the engine's features to their utmost, but then I can understand why the last thing a coder wants to see is a request that doesn't even include Captitalisation and comes in one big lump of text. So I'd say 6 of one, half dozen of the other

[Bobboau]

well I hope this thread can be salvaged.

[Nuke]

wow, a complement, thanks flip

well the idea is to make scripts more portable. lets say im a modeler (well i am:D) but i havent a clue how to write script. lua is gibbrish to me, but this other guy he does know how to write script. so the moddeler wants to make a sidefire bomber. we can point the gunpoints to the side, but we cant lock onto the target because its not in the hud its on the side. no problem wel use dumbfire bombs, but how to aim them? a sidefire gunsight. but i dont know how to write lua! oh no, so much for my cool idea. but this other guy wrote a script for a non line-of-sight targeting. unfortunately it requires i enter the gunpoint position and normal, but i cant read lua!

this is where metafields become handy. instead of editing the script, the modeler can just punch in a custom table tag which is only read by script, and ignored by the engine. this lets modders pass variables to script without editing script. it lets scripters write scripts with parts that can be turned on or off depending on the extra variables in the various entries in the tables, mission files, or campaign files. for example to only enable a fog radar script only when a custom boolean variable is set to true. the main point is to make it so scripts dont have to be re-written or edited every time new content is added.

the playerfile meta fields are to allow for more customizable gameplay. theyre the only fields that should be able to change from script. its mainly for things like a trade engine or an open universe. you can store money or cargo manifests, system location. for my mod i want to have an arms dealer and a loot system where pirated goods can be traded for weapons and ammo. its important however to note the player file metadata serves a different purpose. it has nothing to do with script portability and everything to do wint changing gameplay.

its really 2 ideas. but they would greatly increase the possibilities of the scripting system.

[WMCoolmon]

Could we use the forthcoming ship or rather shipclass specific scripts (with scripting tbms) for dealing atleast part of this stuff?

along those lines mission and campaign specific scripts (possibly imbedded).

I'm not quite sure what he ship/shipclass-specific scripts would have to do with Nuke's original idea?

And mission and campaign-specific scripts should easily be possible either through the new conditional hooks, or by simple use of conditionals

[WMCoolmon]

I should also take this opportunity to point out a shift I've been thinking about...

With variables now working, I think I may understand why my ill-fated attempts at an library-defined arrays didn't pay off. So I was thinking of replacing the currently-cumbersome functions of:

Code: [Select]

--Get the last created ship in the mission
numships = mn.getNumShips()
loser = mn.getShipByIndex(numships)
--Get Alfalfa 1
ourhero = mn.getShipByName("Alpha 1")
with

Code: [Select]

numships = #mn.Ships
loser = mn.Ships[numships]
ourhero = mn.Ships["Alpha 1"]
It's much cleaner, but it would break existing scripts if I removed the old functions. Of course I can leave the old functions in, but I'm still trying to avoid locking out syntax improvements for the sake of backwards compatibility, since scripting hasn't yet been included in a major release. (The "#" is a new operator that gets the size of something)

It would apply for pretty much all sets of items referenced with "getNum*" functions.

[Nuke]

i think scripting is too new to worry about breaking reverse compatability. i really havent written anything major, and it wouldnt be too hard to fix my code. i can see later on, when people start heavily scripting mods, that it could be a problem. were still wrestling with the beast to see what we can make it do.

[Wanderer]

I'm not quite sure what he ship/shipclass-specific scripts would have to do with Nuke's original idea?

And mission and campaign-specific scripts should easily be possible either through the new conditional hooks, or by simple use of conditionals

Some referred to the physics thing in which shipclass specific scripts could perhaps act as poor man's table file extensions...

I should also take this opportunity to point out a shift I've been thinking about...

With variables now working, I think I may understand why my ill-fated attempts at an library-defined arrays didn't pay off. So I was thinking of replacing the currently-cumbersome functions of:

Code: [Select]

--Get the last created ship in the mission
numships = mn.getNumShips()
loser = mn.getShipByIndex(numships)
--Get Alfalfa 1
ourhero = mn.getShipByName("Alpha 1")
with

Code: [Select]

numships = #mn.Ships
loser = mn.Ships[numships]
ourhero = mn.Ships["Alpha 1"]
It's much cleaner, but it would break existing scripts if I removed the old functions. Of course I can leave the old functions in, but I'm still trying to avoid locking out syntax improvements for the sake of backwards compatibility, since scripting hasn't yet been included in a major release. (The "#" is a new operator that gets the size of something)

It would apply for pretty much all sets of items referenced with "getNum*" functions.

Whichever way is fine for me... i kinda like the current, perhaps tad cumbersome way of doing things though.

i think scripting is too new to worry about breaking reverse compatability. i really havent written anything major, and it wouldnt be too hard to fix my code. i can see later on, when people start heavily scripting mods, that it could be a problem. were still wrestling with the beast to see what we can make it do.

QTF, i'm pretty sure that no one of the current 'scripters' has so much material that this change would be in any way catastrophic to them.

[Nuke]

i have 4 scripts so far. ones hudpong, anothers a pirate hud, but all i got working so far is the gunsight. i still have the problem of how to aquire aspect lock with targeting overridden. perhaps i can just use heat seekers and find a way to lock the bank uness certain conditions for a lock are met. the other 2 scripts are experimental things, a mouse operated turret, and various particle effects.

[WMCoolmon]

Are there any other scripting concerns at all that should be addressed?

[Nuke]

lets see

any chance we can get per-gauge overrides for the hud? i have a new lead indicator i want to use without shutting down the whole hud system.

new object types:
pixel/color object (rgba).
2d vector object

thats all i can think of right now

[Turey]

hudpong

is this what i think it is?

imagine... we can start up an extremely processor-intensive, full screen PONG GAME!