Hard Light Productions Forums
Modding, Mission Design, and Coding => The Scripting Workshop => Topic started by: WMCoolmon on January 20, 2007, 02:05:08 am
-
Another obvious thread title. ;) So it's easier to pick function requests out of the discussion, please use the form:
object:function(arguments)
This would be a description of what the function actually does
vector:getOrientation()
Takes the current vector and returns an orientation object from its normalized direction. (I've implemented & tested this in my local codebase, it should be around when I release another build.)
//Implemented. --WMC
-
vector:getOrientation()
Takes the current vector and returns an orientation object from its normalized direction. (I've implemented & tested this in my local codebase, it should be around when I release another build.)
oh goodie, just what i needed. :D
im sure il come up with other stuff as needed.
-
any chance we can get some aa on the gr.draw functions? some of the draws tent to be rather jagged.
-
Use the form!!!
-
well not everythings gonna be a function, sometimes youl have a new object handle. but if you insist
gr.setBlendingMode(string)
sets blending of draw functions to "add" "subtract" "multiply" "average" ect.
gr.setFilterMode(string)
filtering for draw functions, can be "normal" "bilinear" "bicubic" or whatever to smooth out draw calls.
object.ShildsMax
handle for maxshilds, couldnt fine one for max, need it for custom shild gauges. can use indexes/enums like object.Shields
//Implemented. (object.Shields.CombinedMax) --WMC
-
I was just being an ass :p
-
of course :D
-
It helps a lot when I'm scrolling down the page to look for feature requests, and filter between discussion and those. Anyway if I was being anal I would point out that you didn't bold them. :p
I don't know if I can implement those, I thought I'd pretty well gotten the 2D functions. But I can certainly check again.
AA functions will require additional, well, functions. There is an _aaline function, but I don't remember it actually doing anything different, and I don't remember there ever being an _aacircle. That may require some icky calculations. Hopefully not. But it will require some extra GL knowledge, which means reading or asking taylor, and either will take time.
ShieldsMax sounds much easier. I'll get started the next time I read this thread and have some time to implement stuff.
-
what about some kind of post process function? as i understand it by default the gr. are painted onto a hud texture. would it be possible to run like a bilinear filter on the whole hud image rather than the individual elements as their drawn. that way i could do a gr.applyFilter() at the end of the hud section or anything else thats being drawn to.
-
Everything is drawn to the screen by default, but what you're saying shouldn't be too hard to do already (draw via scripting). There's no way to bilinear filter a texture though.
-
yea thats right thats a rendering thing. but there should be some fairly simple pixel math to clear up any jaggedness,
-
Well, here's the effect of the builtin OpenGL line antialiasing function.
[attachment deleted by admin]
-
its not a big improvement but it helps some.
-
Shipclass.Textures or Shipclass.Model.Textures
same as Ships.Textures but lets me globally acess or change a model's textures. need it so that i can change an object's textures before a :renderTechModel() call. usefull for 3d hud gauges :D
//Implemented. (shipclass.Textures) --WMC
-
Ship.Subtarget
handel for the subsystem index of the ships target. nil, false or invalid if no subsystem is selected. need this for things like targeting gauges so that subsystems can be tracked.
//Implemented. (Ship.TargetSubsystem) --WMC
-
This is sort of more complicated request...
Multiplayer scripting
Preferably so that certain functions can be limited to run only on the host cpu after which results are sent to clients.
-
what about broadcast vars. variables which are shared across all all clients and the server. you also need network environment vars and funcs as well. a client index is a good example. i can imagine lots of stuff being stored in arrays where each client has their own index. now all clients and servers would need to run the same script so we need flags to id wether the script is running on a host, server, or client so that it knows what part of the script it needs to run. with just those features alot of stuff can be done as far as multi goes.
-
The 'host only' or 'server only' option is rather important as due different cpu speeds and generic multiplayer game lag the distance checks and other similar evaluations yield different results between players. That is this has already been tested with 'scripted multiplayer' and it causes - well occasionally - problems.
-
server side timing might also be a good option as well. anything which the client script cant be trusted to do by its self on its own clock can be done on the server.
oh and i need a
weaponbanktype.Selected
weaponbank index of the currently armed weapon. need this for my weapon select and lead gauge.
if you cant tell by my requests, im slowly working on a new hud :D
//Implemented. (weaponbank.Armed) --WMC
-
As you may have guessed from my edits, I've got an upcoming build. Planned changes list:
- Improved Linux error-reporting support
- Fixed one silly bug that's been around since practically day 1.
- Added "On Splash Screen" and "On Game Init" conditional hook actions
- Added "Version" conditional hook condition
- Added "Shields.CombinedLeft" and "Shields.CombinedMax"
- Replaced subsystem:getName() with .Name; added the ability for subsystems to have a name independent of the original model name to support the variable. (Did not think to check how easy this would be to do for turrets, as well)
- Added "Self" and "Object" variable pair to collision sequences to allow for easier generic collision actions.
- Tweaked drawString so that when it's called without any position arguments (eg gr.drawString("Hello")) it will write another line below the previous one.
- Added "Self" hook variable for the HUD hooks. (Still need to test this one)
- Added support for model textures (Untested/Unfinalized)
- Probably some other stuff that I've forgotten, but will hopefully catch before I commit the build to CVS.
I've successfully tested Wanderer's sample script with it, so I assume the hv.Weapon crash is fixed. If there's anything you want by the next build and it's not in this thread or on this list, especially if it's something small, then you ought to re-ask for it here.
-
load.image:(filename)
imports images, for things like HUD pong. example: imports an image of a sandwich located in the same folder as the scripting.tbl.
-
gr.loadTexture() or gr.drawImage()?
-
maybe.
-
I think you kinda missed what i meant.. Those two functions are already in the scripting so there isn't really any use for additional function.
-
so how do you use them? just stick a filename in the parenthesis?
-
read the scripting.html
-
Hmm.. Some weapon related functions would benefit if we had some sort of scripting functions to get weapon shooter object as well as weapon target (meaning the target against which the weapon was aimed at - if any) object directly from the weapon handle.
-
I bumped in a Parent variable for all objects, and Target, Homing Object, Homing Subsystem, and Homing Position types for weapons. Changes will be in the next build. I'm not entirely sure what the relationship b/t the last three is. :D
-
Can we have some way to give the AI orders through scripting?
-
If that's too big of a request, how about getting access to the Gun/Shield/Engine System in the meantime? ;)
-
can we get a multiply operator (which performs matrix multiplication) for orientation objects?
also can i get access to ship moi?
//Both implemented in CVS (Model.MomentOfInertia) --WMC
-
Hmmm.. I think asteroid and debris equivalents to mn.Ships[] and mn.createShip() arrays/functions might also be rather useful additions
-
couple more matrix requests, ones really easy, another might be difficult (or from what i know it uses alot of math).
createOrientation(r1c1, r1c2, r1c3, r2c1, r2c2, r2c3, r3c1,r3c2,r3c3) --create an orientation object, with arbitrary fields.
//Implemented in CVS (ba.createOrientation) --WMC
the second one is
intrepolateOrientation(oria, orib, t) --interpolates between oria and orib by t and returns the resulting orientation. t ranges from 0 to 1 where 0 will return oria and 1 will return orib. if t = 0.5 then it will return a matrix that represents a rotation that is halfway between oria and orib.
//Implemented (matrix:interpolate()) --WMC
math ref
http://www.gamedev.net/reference/articles/article1691.asp#Q44
i could probibly write some functions in lua for this if i get the first function. though it would be much faster if handeled by c. i need theese for a keyframe animation system im thinking about doing (which would be usefull fo something like a giant robot mod).
im thinking about making a file format, using conventional freespace table style formatting. it would contain a referance for each subobject in a model that is to be animated and a list of keyframe markers to describe a point along a defineable timeframe. and each key would also be associated with a matrix.
this data would be loaded on game start. then when an animation is ready to be used, you call a function to get orientations for subobjects. you pass it a time key and and the name of the submodel, and the function will look up the preceding and following keys, intepolates between them to create a new matrix, and then applies that matrix to the sub model. this way momentary and looping animations could be handeled. also sence you control what time key gets used you can arbitraril;y control the rate of animation. for example, if you want the mech to move its legs faster at full throttle than at half throttle. it can also be used for momentary actions like recioling a gun or activating swing wings.
-
You can always take a orientation from any of the objects from the game and move on from there.
-
seems a rather cumbersome way to do it if you ask me. if i want to write a function that returns an orientation, i would have to pass it an object in the game so that i can steal its orientation. if you ask me thats no way to program. id have to write 20 or so lines of code just so that i could create an orientation object, not good.
-
Dunno if others agree but i could see some use for certain set of AI related scripting options. Possibly for directly forking the AI with scripts but mainly just for debugging and figuring out what is wrong in certain AI behaviors. Especially if there are no changes being planned to be made to the AI code. Stuff like the ones listed below might of use for others too...
aip->mode
aip->submode
aip->submode_start_time
aip->mode_time
-
I've added
- createOrientation
- orientation multiplication
- orientation tostring()
- Moment of Inertia
to CVS; these are fully tested and seem to work. The only thing I'm concerned about is that I can't really tell if matrices are treated the same way by the code as I treat them with Lua. My assumption is that they go r1c1 r2c1 r3c1 etc.
I've uploaded a debug build (http://fs2source.warpcore.org/exes/latest/C11242007d.zip) to warpcore, this also includes the bugfixes I did tonight on mantis.
I agree that interpolateOrientation sounds like it could be added; but I'm not familiar enough with matrices to do what's described in the document with the existing internal FS2 functions, at least not without further reading.
-
link is 404
is that the same build from the recent builds forum?
*edit*
nevermind, you just left out a d :D
-
ok heres the first of many wish lists for the freespace rts mod, some we need, some we might need and some we could do without (probably because were doing it wrong):
getVectorFromScreenCoords(x,y,depth)
calculates a world vector based on screen coords and a depth value (we scripted a function to do this but its still off by quite abit).
//Implemented (gr.getVectorFromCoords()) --WMC
ship:warpTo(Position, Orientation, Delay)
warps out a ship, waits till delay, then warps it in at position with orientation.
alternatives are: a way to make ships enter a sort of limbo state, where they are not in the level but can be warped back in as needed. or just make them invisible to the ai, so they can be moved behind the camera and ignored until i warp em in where they need to go. or we need a way to create an almost copy of a ship, so we can move the real one somewhere and warp it out. then we can move the original back and call warpIn() to show the animation.
ship:setOrders("ordertype", object, ect...)
sets a ships orders. mainly we need to be able to set waypoint orders for script generated ships, but if we can set any order that would be good. we mainly need this because the rts will use mainly dynamic orders that have to be set up at run time. should have the same params as the initial orders box. were mainly dependent on the ai to do everything the rts needs to do.
//Implemented (ship:giveOrder()) --WMC
Model.BoundingBoxMin
Model.BoundingBoxMax
self explanatory, needed for drawing targeting brackets
//Implemented (model.BoundingBox*) --WMC
thats it for now.
-
Another thing for the rts mod, that might be able to replace the need for a give-orders script: a way to tell the event system to execute a fredded event that uses a list of ships as event arguments.
Basically: a script-triggered event that takes script-supplied arguments, but is defined in FRED.
I can't guarantee that this will solve the problem, but it might help.
Another thing: OnMissionStart and OnMissionEnd events would be very useful.
//Implemented ($On Mission Start, $On Mission End) --WMC
Also, in the long run, it would be nice if we could dynamically create events using the scripting language, that'd be awesome.
Yet another thing: we need to be able to make a warping-out ship not be deallocated, but instead place it in a sort of limbo state, from which we can return it at will using the scripting system.
-
i think we also need a ship:arriveFighterbay(subsystem) and ship:departFighterbay(subsystem)
-
No, not ship functions, Nuke! What we need is generic $On Ship Removal hooks, that can be overridden to prevent the removal of the ship. They should have variables with info like:
- What was the cause of removal (destruction, warpout, entering a fighterbay)
- If it entered a fighterbay, which
- Maybe some others?
Edit: And obviously, a Ship variable.
-
Nuke... i thought the ship:warpOut(false) would do the 'fake' warp thing...
-
will if thats the way its supposed to work, then its broke.
-
Actually, though Nuke's departFighterbay function is unnecessary, an arriveFighterbay function that could be called on a ship, similar to :warpIn(), would actually be useful.
-
see the thing is i want to make runtime created ships to come out of a fighterbay, and when told to depart will be removed after flying into the bay.
-
i have a debug request. were using a series of lua files, so far one for each hook. we would like to break up the code into yet more managable chunks. the problem is when an error is thrown it only gives the line number in the hook. but it doesnt specify in which lua file or on which line of that file, rather only on which line of the hook. is there a way to make it pin down the error more accurately?
-
any way i can get a matrix and position for various view functions . what i want to do is use custom cameras, but i still want any player applied view angles from the track ir or other view controls to apply to that camera. i was thinking about doing things like view slaved turrets and missile targeting, also view functions to apply to things like the tail gunner seat or anywhere else i can stick a camera.
-
Some hooks we'd like: On Mouse Moved
Some hooks we'd like more: On Mouse Pressed / Released
Keypresses, or if that's too hard, weapon key presses, would be nice, because our current system makes my skin crawl just thinking about it. Also key/weapon release hooks, if possible.
A note about the giveOrder function: we need to be able to clear the orders, and possibly append orders if it isn't doing that now. Otherwise, they won't work right. It'd be best to have some way to see what orders a ship has, as well.
Also, for the purpose of emulating the in-system jump, or out-and-back jump: A way to copy ALL of the data of a ship but the name, and then to assign that data to a ship created with something like createClonedShip. The copy, for our purposes, will need to run on warpout, and the paste will need to work after the ship has warped out.
Also, we need a way to make the hud blend func consistent! It's no good having it change when a comm message comes up! I think there is a function like this, but iirc it doesn't do anything.
Lastly, although it was Nuke's great accomplishment and I hate to diminish it, I think his metadata system should get hard-coded. What it does, in short, is allows scripters (us) to add additional data to ships. In our system, I believe it is just a bunch of parallel arrays, but I think it would be best to allow for the user to create at will any fields and flags they need. Could this be done? Ideally, in a manner such that when copy+pasting the ship data the metadata doesn't get lost?
We = The FS RTS Mod Team (So far just Me + Nuke)
-
Also, for the purpose of emulating the in-system jump, or out-and-back jump: A way to copy ALL of the data of a ship but the name, and then to assign that data to a ship created with something like createClonedShip. The copy, for our purposes, will need to run on warpout, and the paste will need to work after the ship has warped out.
Already possible using ship-copy.
-
Ah, but does that work for ships that have been removed from the game?
-
No, and that's not possible due to the way ships are removed. You wouldn't be able to do it with scripting either.
It does, however, work for ships that have not yet arrived. So you can achieve the same result via a slightly different method (doing the copy immediately before the source ship is removed, as opposed to immediately after the destination ship arrives).
-
i think it would be cool to create a ship thats in a not yet warped in state. then we can copy a ship and create a ship thats not yet in system, and would remain out of system (or in a fighter bay) until warpIn() is called.
as for the meta system. its pretty inefficient, i have to run a cleanup cycle every time the # of ships in the mission changes (now that i think about it it might be running every frame due to a bug, its not causing any ill effects except for a few lost cpu cycles). if a ship is found dead or mission, its index is added to a dead ship array. i could probibly optimize that by changing the name in the lookup table to something like "corpsed" :D
-
Is it possible to read whether a ship is targetable by the player or not? I've been playing with a script to add lead indicators for untargeted ships but in the fog, they still appear because I don't have a way to determine fuzzy lock.
-
Allow a getDistance function or check that returns like displayed_target_distance does, but not based on a subsystem or turret targeting. (Base model distance check from plr.Position, or obj-obj Distance)
-
hu.setCustomGaugeText
hu.setCustomGaugeCoords
hu.setCustomGaugeFrame
hu.setCustomGaugeColor
Might be useful since those functions exist as SEXPs already anyway, but doing more complicated stuff in FRED is kind of a nuisance and you also don't have the wide range control you have in LUA.
Patch file to include these functions attached. I did some testing with them for an experimental HUD mod I did for Saga so they should work fine. They're mostly adaptations of the SEXP functionality plus some additional checks and tests to make sure they work.
At the moment when you move a parent gauge with hu.setCustomGaugeCoords, the child gauges won't be moved with it, that would require additional calculations. I left that out in this implementation since the corresponding SEXP doesn't do that either. So if one would upgrade this to move child gauges, (maybe optional with an additional optional boolean parameter) one should implement that for the function and the SEXP simultaneously to keep them in synch.
[attachment deleted by admin]
-
hu.setCustomGaugeText
hu.setCustomGaugeCoords
hu.setCustomGaugeFrame
hu.setCustomGaugeColor
Might be useful since those functions exist as SEXPs already anyway, but doing more complicated stuff in FRED is kind of a nuisance and you also don't have the wide range control you have in LUA.
You are aware that you can run SEXPs from scripts with mn.runSEXP(), right?
-
Yes and I'm also aware that the more interfaces you use the more performance you lose. HUD is already hard on performance and I'd like to avoid unnecessary function calls.
A SEXP needs to resolve node information and that is costly. The direct functions can do this better.
-
If you're really concerned about performance, you'd be looking at the collision code, not the SEXP code. SEXPs are significantly lower down on the performance bottleneck scale and shouldn't be a concern. Remember what Knuth said about premature optimization.
-
That and Kara (I think it was him) managed a massive optimization on SEXP processing and over head which effectively boosted the operations of the SEXP system, so I can guarantee that it is less of a slow down performance wise than Scripting currently is, especially if said scripting is rendering or manipulating on-screen elements (where it can crop 20-40 FPS on higher end machines depending on the script, even one as simple as the Escort HUD Display script)
-
Indeed.
That said, submitting patches is A-1 SUPAR and I don't think I have any objections to adding the one Keldor posted. But it's important to try to find a pre-existing solution before coding up something new. Especially if it's redundant.
-
*AHEM*
There's only a few things that can be done with FRED that can't be done with scripting (especially now that we have the runSEXP function).
Among them: waypoints. Although there are a few types and functions relating to waypoints, it's impossible to create waypoint paths, and there's no SEXP to do it either; waypoint paths have to be placed in FRED before they can be used.
-
as dead and as old as this thread is i think il post a couple things here that scrpiting really needs.
ai library - for access to ai related data, so you can have some degree of control over what the ai does (like setting the kamekazi flag when an enemy ship runs out of ammo).
ui library - for access to data which would normally be edited by the hard coded user interface, the purpose of this would be mainly for scripted ui replacement.
-
Having those libs alone wont help any one.. they need some content to fill them as well
-
i could probibly add the content myself as i made progress on the ui. it would certainly help resolve this (http://www.hard-light.net/forums/index.php?topic=71076.msg1407573#msg1407573) situation. ai is less important right now, but its something i may need in the near future. im just not sure how to add new libraries to the scripting system. if someone started them and added a couple of examples, i could quickly populate them.
-
Something akin to...
//**********LIBRARY: Controls library
ade_lib l_HUD("HUD", NULL, "hu", "HUD library");
Perhaps?
-
:bump:
Bumping this because I have some ideas about scripting functions:
mn.objectFromScreenPos(x, y[, depthOffset=0])
Returns a handle to the object or invalid handle when there is no object. Optionally takes an argument for a minimum distance the object should have
subsystem:rotateTurret(vector woldPos)
Rotates the turret to face worldPos.
But I also wrote some additions myself, see attached patches.
Things I added:
- A $On Weapon Creation: hook that gets called when a weapon is created
- Types for thruster information on a model
- Variables for Model and FreeFlightTime in weaponclass
- Function to determine the type of a weapon in weaponclass (laser, missile or beam)
- A function in subsystem to determine the normalized forward vector of a turret
- Functions for getting information on slash direction in the beam type
Could someone please review those patches and tell me what I did wrong? :D
Regards,
m!m
EDIT: NOTE TO SELF: Check if patch actually compiles :banghead:
And the new version contains a variable for weaponclass that checks if the class is flagged as a bomb.
[attachment deleted by ninja]
-
lots of stuff there i like.
not quite sure i understand what objectFromScreenPos is supposed to do. if its supposed to find ships on the screen, that is something i would have done with a frustum cull and so that kinda saves some time (and maths).
up till now i mostly aimed turrets by setting the orientation of the base and barrel models, then called fireWeapon(). trouble there was you had to somehow tell the script which turrets were single part, which where 2 part, and also i dont believe the base orientation is accessible from anywhere (u/fvec would have needed to be accessible, then used to compute a matrix), so you would essentially have to guess as to whether the turret was upper or lower, and turrets at angles were all but impossible. being able to do it with one function call really speeds things up.
$On Weapon Creation: sounds like a pretty nice hook to have. though i kinda wish it was object level (so that it could apply to any object derivative). would definitely be a good way to initialize meta for weapons though.
lots of nice time savers here. good work.
definitely want to cross post to the scp forum for some proper code review.
-
not quite sure i understand what objectFromScreenPos is supposed to do. if its supposed to find ships on the screen, that is something i would have done with a frustum cull and so that kinda saves some time (and maths).
That function should look for a object that is at screen position x, y, just like the "target under reticle" hotkey does but for a specified screen position.
up till now i mostly aimed turrets by setting the orientation of the base and barrel models, then called fireWeapon(). trouble there was you had to somehow tell the script which turrets were single part, which where 2 part, and also i dont believe the base orientation is accessible from anywhere (u/fvec would have needed to be accessible, then used to compute a matrix), so you would essentially have to guess as to whether the turret was upper or lower, and turrets at angles were all but impossible. being able to do it with one function call really speeds things up.
Currently I'm doing exactly like that but with that I can rotate the turret to impossible angles and the fireWeapon() thing doesn't fire from the firing point but from the center of the subsystem.
Maybe we need another type for firingpoints that provides information about the firing point. I also noticed that weapons that have the "cycle" flag set don't cycle firingpoints on the turret.
-
id say in a perfect world, you would be able to take a turret, throw any world vector at it, and it would attempt to track that vector to the best of its ability, with regardless to its rotation speed and available fire arcs. such a function would work without needing to be told what kind of turret it was.
fire turret has many issues. im not even sure if it can fire beam weapons, it can fire flak, but needs to be told the detonation distance. i dont know why it doesnt take firing points into consideration, though i kinda think it should. it should also try to calculate the flak range automatically if it hasn't been called with a custom flak range.
if youve ever used my cockpit mod, you can see i have a very elaborate way to deal with turrets. though for the most part i had to manually provide settings in the form of a custom table. the turret system is still in somewhat of an incomplete form, i had planned to make it capable of everything shown in my older demos, but kinda lost interest.
-
I added some other functions to the lua subsystem interface:
- Varaibles: Turret resets, TurretResetDelay, TurnRate quite obvious
- Function: subsystem:rotateTurret(vector worldPos[, boolean reset]) Rotates the turret to face worldPos
Updated patch is attached.
[attachment deleted by ninja]
-
Committed to trunk in rev 7010
-
i also got a patch of some minor bugfixes and a few more functions that have been sitting in my lua.cpp for the last few months. for example:
-io.updateTrackIR() now returns false on failure (such as if there is no trackir available on the system).
-added descriptions for model.MomentOfInertia and model.radius
-added Physics.isGliding(), tells script if gliding is being used or not
-added Physics.LastPosition and Physics.LastOrientation, which should be useful on physics related scripts
[attachment deleted by ninja]
-
I tweak subsystem:fireWeapon() so now it actually fires the weapon from the correct firing-point.
I mostly copied the behavior from the existing function in aiturret.cpp so could a coder please check the attached patch?
Regards,
m!m
[attachment deleted by ninja]
-
Committed to trunk in rev 7077, with slight adjustment to use model instances in order to get around the slowness known as ship_model_start()
-
Thank you The E :)
I have another patch (attached) that gives access to particle information but I needed to change some lines in particle.cpp/.h and I need some feedback if that is the right way to do it.
Regards,
m!m
[attachment deleted by ninja]
-
and get mine too while youre at it.
-
Both are in as of rev 7079
-
thanks.
-
I need help with my particle code. The current code just isn't usable so I changed it to use the heap memory to obtain pointers on the objects (see attached patch). It mostly works but I can't get the isValid() method to work correctly as the pointer in the class is never set to NULL unlike the pointer in the vector. I can even see that the object was deleted as accessing the object later via lua simply results in garbage. I'm quite sure that I miss something obvious as I'm not very experienced in C++.
Thanks for you help,
m!m
<solved>
-
I added a OriginClass variable to the Debris handle to have access to the origin shipclass and a isValid() function as it didn't exist before.
Can a coder please review my changes? :)
[attachment deleted by ninja]
-
Comitted to trunk in rev 7270
-
Thank you very much :)
-
I have another patch which adds access to the radius of a debris object.
Nothing big but can someone review it?
[attachment deleted by ninja]
-
Committed as 7354.
-
And I have another patch for some scripting functions:
I added access to the collision information of a weapon by saving the mc_info struct inside the weapon. The critical thing I did was that I needed to allocate the collision information which would be added to the scripting system using new as I can't use a pointer to the struct inside the weapon as the weapon will not be in memory forever. The memory should be freed correctly as I delete the pointer inside the lua __gc function.
I'd like to ask for feedback from a coder whether I broke something or not ;)
[attachment deleted by ninja]
-
Anybody looked into it?
If that patch gets adopted, some interesting things will become scriptable.
-
Patch is in as of revision 7418.
-
I noticed that I missed to add the collision info to the object:checkRayCollision() function where is is very helpful to get additional informations.
Can a coder review it please, it shouldn't break anything and I have tested it :nod:
[attachment deleted by ninja]
-
In as of rev 7512
-
I needed to add another two functions which allow me to manipulate the afterburner data of a ships physics (adding a AfterburnerActive filed to the Physics handle) and an unhackish way to know if a subsystem is a turret or not (added isTurret() to subsystem handle).
The second patch deals with possibly unwanted behavior in the "On Mission Start" hook. There the Player Hookvariable wasn't set although it would be very helpful to have it available. The second thing is that at the time that hook is called the mission is technically not in Mission (the GM_IN_MISSION flag is missing) which causes that most mn.* functions don't work. Currently I need to know the mission filename in that hook but without that flag being set mn.getMissionFilename() always returns an empty string. I "solved" it by temporarily adding the flag when executing the hook and removing it again afterwards but I'm not sure what side effects it has :nervous:
[attachment deleted by ninja]
-
I would like to request a feature to be able to fire a primary or secondary gunbank on a ship. not the currently selected one as the <ship handle>.firePrimary(<ship handles>) works, but an absolute gb.
basically something like: <ship handle>.firePrimary[<ship handle>,<gunbank index>, ...] and the ability to fire more than one gunbank at once.
or, if thats possible already, can someone just quickly walk me through how to do it?
-
:bump: :nervous:
So did someone take a look at the patches yet?
-
I have them, will take a look later and commit as needed.
-
I have a new patch which adds access to the Viewer_mode as I need to know if the view is currently in the cockpit or not.
I'd be grateful if a coder could take a look at it.
[attachment deleted by ninja]
-
I have a new patch which adds access to the Viewer_mode as I need to know if the view is currently in the cockpit or not.
I'd be grateful if a coder could take a look at it.
Reviewed, and committed to trunk (http://svn.icculus.org/fs2open?view=rev&revision=7888).
-
Here is a new patch ;)
While working on a script for Diaspora I noticed that the scripting API does contain some sound functions but these function were lacking information which I needed. I also noticed that there were some handle definitions for a soundentry handle and a sound handle which weren't implemented completely. So I just completed those parts and added some new function to the Audio library to use the new handles.
I completed the soundentry handle which represents an entry in sounds.tbl or more precisely an index into the Snds Vector.
This handle can be used to play a sound either normally, looping or in 3D where the 3D function also returns a specialized handle which also gives access to the special 3D functions (currently only one).
Can a coder take a look at it?
Thankyou
[attachment deleted by ninja]
-
:bump:
;)
Is there anything wrong with it? I really need it for a script for Diaspora...
-
This thread looks like a good place to post this little patch, which adds a kill() function to asteroids. With this, scripts can actually kill asteroids, whereas previously you'd have needed to spawn a fake weapon to hit and destroy them.
Index: lua.cpp
===================================================================
--- lua.cpp (revision 7927)
+++ lua.cpp (working copy)
@@ -4627,6 +4627,30 @@
}
+ADE_FUNC(kill, l_Asteroid, "[ship killer=nil, wvector hitpos=nil]", "Kills the asteroid. Set \"killer\" to designate a specific ship as having been the killer, and \"hitpos\" to specify the world position of the hit location; if nil, the asteroid center is used.", "boolean", "True if successful, false or nil otherwise")
+{
+ object_h *victim,*killer=NULL;
+ vec3d *hitpos=NULL;
+ if(!ade_get_args(L, "o|oo", l_Asteroid.GetPtr(&victim), l_Ship.GetPtr(&killer), l_Vector.GetPtr(&hitpos)))
+ return ADE_RETURN_NIL;
+
+ if(!victim->IsValid())
+ return ADE_RETURN_NIL;
+
+ if(killer != NULL && !killer->IsValid())
+ return ADE_RETURN_NIL;
+
+ if (!hitpos)
+ hitpos = &victim->objp->pos;
+
+ if (killer)
+ asteroid_hit(victim->objp, killer->objp, hitpos, victim->objp->hull_strength + 1);
+ else
+ asteroid_hit(victim->objp, NULL, hitpos, victim->objp->hull_strength + 1);
+
+ return ADE_RETURN_TRUE;
+}
+
//**********HANDLE: Shipclass
ade_obj<int> l_Shipclass("shipclass", "Ship class handle");
extern int ships_inited;
-
Ooo, nice one. And you got the optional arguments too!
-
Here is a new patch ;)
In as of 7930.
This thread looks like a good place to post this little patch, which adds a kill() function to asteroids. With this, scripts can actually kill asteroids, whereas previously you'd have needed to spawn a fake weapon to hit and destroy them.
In as of 7931.
-
I have another patch which adds the following things:
- Eyepoint access to the model handle
- getCollisionDistance() to the collision info handle to get the precomputed distance to the hit point
- A Disabled variable for the ship handle
- getTimeUntilExplosion() for the ship handle to get the time until the ship finally explodes
- A change to the documentation of ad.play3DSound() to reflect that the function also takes position parameters
Thank you for your time
[attachment deleted by a basterd]
-
finally eyepoints. now i can use the eyepoint list from the model instead of having to copy all the data to a fake table.
-
A auto-targeting function as seen in WCS that not only fires your guns at your target but also at the selected subsystem and can be toggled on and off with a key.
-
need a function to have scripting spew out the current game version and build number and debug mode flag so that i can conditionally evaluate or exclude lines of script based on engine version. if it exists i cant find it.
probibly just return it as a string "version,subversion,subsubversion,buildnum,debug|release" or an table of numbers {version,subversion,subsubversion,build,1|0}, or even a userdata type. not sure which would be more intuitive. idea is you should be able to be able to check this quickly in one line of code as you would with a #ifdef in c.
also need a way to disable transparency of a render target. when drawing bitmaps with transparency to a texture that needs to remain opaque, the transparency information from the bitmaps are drawn to the texture making those areas of the texture transparent. this is undesirable, like when the bitmap will be applied to an object in the game. seems the alpha is overwriting the underlying pixel data when it should be added. being able to change the blending operatione (such as multiplicative, additive, subtractive, etc) would also be completely awesome.
-
I'll post the patch I posted a while ago here again as the old one seems to have gotten deleted. Can a SCP coder take a look at it?
Original message below:
I have another patch which adds the following things:
- Eyepoint access to the model handle
- getCollisionDistance() to the collision info handle to get the precomputed distance to the hit point
- A Disabled variable for the ship handle
- getTimeUntilExplosion() for the ship handle to get the time until the ship finally explodes
- A change to the documentation of ad.play3DSound() to reflect that the function also takes position parameters
Thank you for your time
[attachment deleted by a ninja]
-
Committed r8199
-
Here's a patch which adds an $On Turret Fired hook, providing hook variables Ship, Weapon and Target. I'll later try to add a handle to the associated subsystem to weapon objects, since I can't pass that as a hook variable (due to subsystems not inheriting from object).
Index: ai/aiturret.cpp
===================================================================
--- ai/aiturret.cpp (revision 8215)
+++ ai/aiturret.cpp (working copy)
@@ -21,6 +21,7 @@
#include "ai/aiinternal.h" //Included last, so less includes are needed
#include "iff_defs/iff_defs.h"
#include "weapon/muzzleflash.h"
+#include "parse/scripting.h"
#include <limits.h>
@@ -1717,6 +1718,12 @@
objp=&Objects[weapon_objnum];
wp=&Weapons[objp->instance];
+ parent_ship->last_fired_turret = turret;
+ turret->last_fired_weapon_info_index = wp->weapon_info_index;
+
+ Script_system.SetHookObjects(3, "Ship", &Objects[parent_objnum], "Weapon", objp, "Target", &Objects[turret->turret_enemy_objnum]);
+ Script_system.RunCondition(CHA_ONTURRETFIRED, 0, NULL, &Objects[parent_objnum]);
+
//nprintf(("AI", "Turret_time_enemy_in_range = %7.3f\n", ss->turret_time_enemy_in_range));
if (weapon_objnum != -1) {
wp->target_num = turret->turret_enemy_objnum;
Index: parse/scripting.cpp
===================================================================
--- parse/scripting.cpp (revision 8215)
+++ parse/scripting.cpp (working copy)
@@ -71,7 +71,8 @@
{"On Weapon Fired", CHA_ONWPFIRED, 0},
{"On Weapon Selected", CHA_ONWPSELECTED, 0},
{"On Weapon Deselected", CHA_ONWPDESELECTED, 0},
- {"On Gameplay Start", CHA_GAMEPLAYSTART, 0}
+ {"On Gameplay Start", CHA_GAMEPLAYSTART, 0},
+ {"On Turret Fired", CHA_ONTURRETFIRED, 0}
};
int Num_script_actions = sizeof(Script_actions)/sizeof(flag_def_list);
@@ -279,7 +280,7 @@
}
case CHC_WEAPONCLASS:
{
- if (!(action == CHA_ONWPSELECTED || action == CHA_ONWPDESELECTED || action == CHA_ONWPEQUIPPED || action == CHA_ONWPFIRED)) {
+ if (!(action == CHA_ONWPSELECTED || action == CHA_ONWPDESELECTED || action == CHA_ONWPEQUIPPED || action == CHA_ONWPFIRED || action == CHA_ONTURRETFIRED )) {
if(objp == NULL || objp->type != OBJ_WEAPON)
return false;
else if(stricmp(Weapon_info[Weapons[objp->instance].weapon_info_index].name, scp->data.name) != 0)
@@ -333,7 +334,13 @@
case CHA_ONWPFIRED: {
if (! (stricmp(Weapon_info[shipp->weapons.primary_bank_weapons[shipp->weapons.current_primary_bank]].name, scp->data.name) == 0 || (stricmp(Weapon_info[shipp->weapons.secondary_bank_weapons[shipp->weapons.current_secondary_bank]].name, scp->data.name) == 0)))
return false;
+ break;
}
+ case CHA_ONTURRETFIRED: {
+ if (! (stricmp(Weapon_info[shipp->last_fired_turret->last_fired_weapon_info_index].name, scp->data.name) == 0))
+ return false;
+ break;
+ }
}
} // case CHC_WEAPONCLASS
Index: parse/scripting.h
===================================================================
--- parse/scripting.h (revision 8215)
+++ parse/scripting.h (working copy)
@@ -66,6 +66,7 @@
#define CHA_ONWPSELECTED 24
#define CHA_ONWPDESELECTED 25
#define CHA_GAMEPLAYSTART 26
+#define CHA_ONTURRETFIRED 27
// management stuff
void scripting_state_init();
Index: ship/ship.h
===================================================================
--- ship/ship.h (revision 8215)
+++ ship/ship.h (working copy)
@@ -310,6 +310,7 @@
float favor_current_facing;
ship_subsys *targeted_subsys; // subsystem this turret is attacking
bool scripting_target_override;
+ int last_fired_weapon_info_index; // which weapon class was last fired
int turret_pick_big_attack_point_timestamp; // Next time to pick an attack point for this turret
vec3d turret_big_attack_point; // local coordinate of point for this turret to attack on enemy
@@ -708,6 +709,7 @@
bool shader_effect_active;
int last_fired_point[MAX_SHIP_PRIMARY_BANKS]; //for fire point cylceing
+ ship_subsys *last_fired_turret; // which turret has fired last
// fighter bay door stuff, parent side
int bay_doors_anim_done_time; // ammount of time to transition from one animation state to another
The ship.h additions were necessary (the other similar workarounds would have been even messier, IMO).
I'm not entirely comfortable committing stuff like this without a chance for someone to review it first, so I'll let this sit here for a day or two first, just in case someone finds something wrong with it.
-
^ this kinda thing would probably help improve how my gatling turret system works and will generally better organize my code. will check it out. probably not qualified for the code review though.
-
Updated the patch to not cause crashes... :rolleyes:
-
if it hasnt been done already, are there any plans to upgrade lua to 5.2? there are some new goodies, like bit32 library for dealing with bitfields.
-
There's a couple of things I've added recently which I haven't yet mentioned anywhere on the forums:
- r8457 Added subsystem:getModelName() scripting function, returning the original subsystem name as it appears in the model file, which is useful for example as a unique subsystem identifier.
- Added weapon:ParentTurret scripting variable, providing a handle to the turret (if any) which fired the weapon. This allows $On Turret Fired hooks to easily get a handle to the fired turret.
- Added subsystem:TurretLocked scripting variable, providing a way of directly getting/setting the locked status of a turret (also without the random delay incurred by the turret-free SEXP).
- Added subsystem:NextFireTimestamp scripting variable, exposing the ship_subsys->turret_next_fire_stamp variable to Lua.
I also committed the above $On Turret Fired hook patch.
-
if it hasnt been done already, are there any plans to upgrade lua to 5.2? there are some new goodies, like bit32 library for dealing with bitfields.
...goto statement...
The horror!
Anyway, updating is a good idea.
-
There are some inconsistencies with previous versions which may break the way FreeSpace uses the lua API or a script which relies on a specific behavior although that is unlikely. See this link for a list: http://www.lua.org/manual/5.2/manual.html#8 (http://www.lua.org/manual/5.2/manual.html#8)
-
most of the changes relate to modules and oop related stuff. heres the changelog from the new manual (http://www.lua.org/manual/5.2/manual.html#8)
things that caught my eye:
like unpack() is now table.unpack()
loadstring has been depricated, and load should be used instead (this affects the way we use cfile to get at external scripts, but only requires switching to load)
math.log10 is depricated
in patterns you must use \0 instead of %z
theres a section on api changes, since ive never implemented lua on the c side im not qualified to point out the anything which may be an issue.
-
I want a feature to expose the score attribute of a ship class to scripting. It seems silly that this hasn't been done already, yet the score of an event is already accessible. Then again, I'm literally the only person who would even care about such a thing.
-
Score of a ship... isn't that only used for when you kill them? Thinking... why not have a function to award a number of points? (dependent on if you accept the outcome of the mission, ofc.)
-
Would definitely be useful for games/mods that have "bounties" on certain craft. Hopefully later down the road the points system could be augmented to facilitate a money system. :nod:
-
Ship:JumpToPoint(Vector3 point)
Makes the ship engages its jump drives and then come back on defined point (Could be used on Alpha 1)
-
That's much more difficult than it sounds. There are ways to do this using sexps that work quite well and aren't too complicated while allowing a great deal of control over the whole process, so my immediate instinct would be to veto that particular request.
-
This is already possible through SEXP's, check out Axem's excellent tutorials!
http://www.hard-light.net/wiki/index.php/Tutorial_-_In-Mission_Jumps (http://www.hard-light.net/wiki/index.php/Tutorial_-_In-Mission_Jumps)
Doing this is too easy.
-
Relevant to in-system jumps:
"Limbo" (as discussed on page 2) was never in trunk, was it? I remember somebody had a branch which did it, but it's been so long...
-
Limbo was in trunk briefly, but removed as it violated a number of assumptions prevalent throughout the codebase.
-
I would like to have a limbo feature but I don't really see how to implement it without breaking things. It may be possible by using a combination of disabling the rendering of the ship (no idea what issues this can cause) and disabling collision detection, locking weapons, stopping ai (of the ship and any orders targeting said ship) and making it untargetable + invulnerable.
-
*cough* limbo can be supported by sectors *cough*
-
@z: Sectors? That's not a thing that exists yet, is it?
@Goober: How was it implemented? Was it treated as a special case of a departed ship, or a ship that has yet to arrive, or what?
@Admiral MS: That sounds needlessly complicated to me. Idunno.
-
No, sectors have not yet been implemented, but is a desired feature for FringeSpace, Fate of the Galaxy, and others.
-
@Goober: How was it implemented? Was it treated as a special case of a departed ship, or a ship that has yet to arrive, or what?
As I recall, it was handled using a ship flag: SF_DEPARTED_TO_LIMBO. The problem is that a ship flag isn't sufficient unless you override dozens and perhaps hundreds of cases. And before anyone volunteers to do exactly that, a) you're not going to find every case, especially the hidden edge cases; and b) even if you did, the code base would become too polluted to maintain.
The best way to handle ships in limbo is the same way it's been done since X-Wing: give two ships the same display name, while keeping their unique identifiers distinct.
-
The best way to handle ships in limbo is the same way it's been done since X-Wing: give two ships the same display name, while keeping their unique identifiers distinct.
Which is no solution for the RTS script as they are effectively random player issued tactical jumps. Fred never liked created ships anyway and anticipating the name of the ship is also impossible. Also the player ship is able to jump which can never be replaced.
The current implementation in the script does most of the stuff I already mentioned but I don't know of any way to disable colission detection and to switch off rendering. Ships get moved far away for the duration of the jump but that's not a really a good solution. Maybe I can code some scripting functions to cover colissions and rendering.
-
A new way to turn off collisions I think is in code review right now, from FUBAR. I updated the patch recently but it needs more scrutinization on how I managed one of the merge conflicts. I think this had to do with an initial collision state but if there's no sexp yet it should be easy to add with alter ship flag, I believe.