[Nuke]

ive wrote script based systems for this kind of thing. my table parser and meta systems are in all my scripts. but i noticed that very few people actually use those systems, instead opting to write their own from scratch. this is wasted effort and a hindrance to anyone trying to learn scripting, or modders who want to use imported scripts. these things seem somewhat fundamental to what most people try to do with scripting, and that is make objects in the game do things they dont normally do. needless to say this is yet another rehash of a very old idea of mine (that ive probibly brought up several times).

anyway im thinking of a way to integrate this stuff on the c side (should point out now that i only want to discuss the idea of this system, im not intending this as a feature request or something i may be planning to do). i want to make a general structure for storing script variables which are bound to an object class (anything accessed in lua through a handle) and/or instance (an actual game object like a ship or a weapon). these variables would be defined in the varous freespace table files that modders know and love. lets call it a meta page. its not defined in scripting but in the tables. it would look something like this:

Code: [Select]

$Meta Page:
 +Class Vars:
  +Number: "meaningOfLife" 42
  +String: "aLameHaiku" "shivans everywhere\nwe will die\nbosch is shivan food"
  +Number "maxBrowniePoints" 60
 +Instance Vars:
  +Bool: "enableBigAssGun" false
  +Bool: "moreExplosions" true
  +Bool: "useCustomFeatures" true
  +Number: "browniePoints" 0

fairly simple you have a list of variables with a datatype a name and a default value (this can be changed in scripting). there are two sections here: +Class Vars: are the vars that apply to every instance of that object.
+Instance Vars: apply to every object of that type. say this is defined in a weapon table entry. the class vars will be the same for every weapon, if you change it for one you change it for all. the instance variables can change on an object by object basis. so one instance of a weapon may have 0 browniePoints and another may have 10. browniePoints is just an example. say you wanted a missile that shoots lasers, but only a certain number of shots you might have an ammo field which decriments each time the missile fires a laser. on the script side of things you can gain access to the data through the associated weapon class handle or weapon handle.

Code: [Select]

wep = mn.Weapons[wpnidx]
wepCl = wep.Class
haiku = wepCl.Meta.aLameHaiku
bpnts = wep.Meta.browniePoints

if wep.Meta.moreExplosions then
 blow****Up()
end

and this is just the obvious example. you could apply this other features of the game. ships, object types, hud gauges, input mapping, the pilot (perhaps allow you to save scrip meta to the pilot file). so the system would need to be fairly generic. the data itself would be stored in a c++ object which is exposed to scripting, which could be added as a variable to any structure in the game that gets its data from a table. the class would also include the parsing routines too allow it to be loaded with a single function call. the game itself mostly wont care what gets stored there. and how the data is utilized is entirely up to the scripter.

main benefits here are cleaner scripts, lower memory usage (your not relying on lua's memory sucking tables to store data for every object in the game), more secure than parsing custom files, allows modder friendly scripts, and you dont need megalithic scripts to create systems the game should provide, etc.

[Aginor]

Oh man, I could really use that kind of thing for objects like ships, I'm creating associative arrays for that at the moment (which is what you describe and which is also the way most people do it I guess, I don't have much experience with LUA scripting for FS2).
For my script I needed a variable for each ship that stores whether it is cloaked or not and how long.

I did something that looked like this in the end (sorry for errors if any, I have the script at home, this is from the top of my head. Also excuse my example that I think is somewhat WCS specific, since the Strakha uses a model change with an animated texture to cloak, I have to keep track of that stuff in the script):

Code: [Select]

CloakingTimers = {}
for i=1 #mn.Ships do
   CloakingTimers[tostring(mn.Ships[i].name)] = 0
end
(of course I set the timer to mn.getMissionTime() when a mission event tells me that the ship has started cloaking)

and then reading all the stuff by something like

Code: [Select]

for i=1 #mn.Ships do
 -- do something if a ship is cloaking for 3 seconds so I can change the model again
  if (mn.getMissionTime() - CloakingTimers[tostring(mn.Ships[i].name)]  == 3  and otherStuff)
       mn.Ships[tostring(mn.Ships[i].name)].whateveritis = somevalue
  end
end


Of course there are several disadvantages to that. I would like to have the possibility to just add a custom status variable or function to a ship, in my case that would be the cloakingTimer. Or a variable that tells me based on the the ship.class whether it is cloakable or not.
So I could just look into the variables instead of cycling through all ships that can't cloak anyway.

...or maybe I'm just making a fool of myself now because I don't understand scripting yet. Whatever. I like your idea, it would make things considerably easier I think.

[The E]

You do realize that using this with WCS is impossible until someone either ports WCS to FSO, WCS releases a code patch so that we can port their stuff into FSO, or the WCS team updates their builds to current trunk?

(BTW, the WCS exe is hilariously out of date)

[Aginor]

Yeah, I know. But I am still interested in new things. Maybe there will be a time where modding WCS becomes boring for me so I start working on other projects.
And since I am a software developer I might be able to implement some of that stuff as soon as the Saga source code is released.
So yeah, at the moment this discussion is purely theoretical for me. I am aware and I don't care.

[MatthTheGeek]

You do realize that using this with WCS is impossible until someone either ports WCS to FSO

And this is a 2 hour job top, for the modpack, as long as you're ready to remove some banks on a couple of ships.

I still have it around somewhere, maybe with a couple of yet-unfixed hud bugs. If you're interested Aginor, PM me.

[Nuke]

for know you can just do things the way i do, i guess. using mn.getObjectFromSignature() and object:getSignature(). just use a table full of tables. where each sub table is a meta page for a particular object, and this page is stored in the main table with an index which is in essence that objects signature. if you have an object with a signature of 123 you just look up meta[123].someKeyInTheMetaPage. and if you have a signature and want an object handle then you have a function for that. it can be slow-ish though. and it makes your code messy, all your data is not in one spot, its in a few. and especially in concert with my parser that puts everything in its own mess of tables, things get confusing fast. you also have to idiot proof everything yourself. hell forbid you try to access something that aint there. most of the code is checking to see if the expected field isnt nil.

it works but it begs the question why is it not a built in feature? the two systems i use easily take up 40kb of script, which the game has to slowboat through, all so you can have your own pet ucav to rocket across the mission space and take out those 2 bombers you cant get to with your ship. how else would you associate all the information that makes that little drone possible with the missile you just shot? ive rewrote par parser twice and my meta system 4 times to make them faster/smaller. this one theoretical system replaces both.

[Admiral MS]

I would really like to see something like this integrated into the game - would somewhat improve the script I'm currently working on. At the moment its pretty much down to either trying to integrate your meta-data system together with the cfg-file/table parser (which itself is quite long and not that easy to understand and extend from my point of view) or create something myself (will take its time and definitely won't be better in the end).

Table based variables and their additional information storage would remove the need for a whole load of scripting code. The scripter doesn't won't have to handle thousands of variables himself and the normal user has an easy way to create or change settings for ship/weapontypes a script can use without having to touch any lua code or whatever file

[Nuke]

my parser works but its a bloody mess. it doesnt qualify or error check. if something did go wrong you would get a cryptic lua error message. and since it only parses that which is there fields left blank will be nil. which is the same exact thing that would happen if you typed something wrong. freespace parsing code forces you into a strict convention that will always contain a value of the appropriate type. it makes sure you get the right tags in the right order. it also doesnt bind anything to anything, it lumps everything into a centralized table and you have to manually look stuff up in lua. the idea was to build a universal parser that everyone can use, and the fact that nobody is using it but me seems to indicate that it is anything but perfect.

[mjn.mixael]

needless to say this is yet another rehash of a very old idea of mine (that ive probibly brought up several times).

Well.. to be fair, you bring up your "old ideas" often... As in, almost any time someone posts about an idea of their's and you respond... 9 times out of 10 "you did something like this in nukemod many years ago, why is it so tough for you? just do it with scripting"

Hard to keep track of all your "old ideas" that we should be using, and which ones are worth figuring out. 

[Nuke]

ive modded this game for over a decade, surely my experience is valid. i remember requesting this when scripting was new and wmc was a regular around here. i contributed considerable time to testing the system not to mention countless bugfixes and features. but there are still obvious week points in the system that were never seriously addressed. i figure these weak points are at least partially responsible for the slow uptake of scripting and a serious time sink for anyone serious about developing scripts. i mostly just worked around them (and showed people how), script defined meta is possible because of features i added. i then proceeded to show people how to use it. for parsing i developed my own systems and gave them away with documentation. i could have sat on them and claimed they were explicitly for nukemod, but i believed at the time that scripting would be the future of the engine, and that its better to give others examples.

this was of course at a time where you needed a forum wide petition to get a coder to add a feature. and figured scripting would ease the burden. i was kind of inspired by quake c (i had played with it somewhere between my attempts at descent modding and moving on to fs1 modding with some mapping thrown in for good measure) in that reguard. quake c had countless tutorials on how to do everything, guided rockets, radars, custom entities, add models, etc. you had to be a hacker back then to mod, a hex editor was your very best friend. anyway i figured the same would happen to freespace once we had a scripting system. unfortunately it did now turn out that way. it was easier to get coders to pile on features than it was to find capable scripters who knew what to do with it.

you probibly didnt want a history lesson though. only reason i bring up the old ideas so often is because if they were implemented back in 2006, we wouldnt be having this discussion at all and all those posts asking: how to make a variable stick to a ship? would be answered in 2 posts instead of 2 pages.

[mjn.mixael]

We're getting off track here, and that's my fault.. sorry.

I'm just saying that many of your posts start off with "I did this way back when in nukemod with scripting. It's easy peesy if you just WALL OF TEXT" Honestly, I've kind of started just skimming your posts (if I read them at all anymore) because I'm bored of reading how the community should have implemented your stuff back in '06 or whatever.

So meh, take it as constructive criticism, complaint, insult, or whatever you wish. My soapbox has ended.

This meta data thing looks useful though. I certainly have ideas for it's uses.

[Nuke]

yea im not a skilled writer so my posts tend to come out as a wall of rambling gibberish. sometimes i think its because i feel that my heyday has come and gone and im just reliving old successes. ....back in my day we had to write code flipping those dip switches with a toothpick, our machines barely could render 7 polygon models and so we had to use sprites.... and so on like an old geezer talking about the war. kind of a well geared post with good intent twisted into a deranged nostalgia trip. so yea, my bad.

[jr2]

Age is a frame of mind, Nuke.  It's just a matter of if you want to sink all the time and effort into getting back up and current again, I guess?  But you know you can't escape.  The HLP Borg nanites are in your bloodstream,

 you must comply.