[Nuke]

i think we also need a ship:arriveFighterbay(subsystem) and ship:departFighterbay(subsystem)

[Aardwolf]

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.

[Wanderer]

Nuke... i thought the ship:warpOut(false) would do the 'fake' warp thing...

[Nuke]

will if thats the way its supposed to work, then its broke.

[Aardwolf]

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.

[Nuke]

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.

[Nuke]

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?

[Nuke]

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.

[Aardwolf]

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)

[Goober5000]

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.

[Aardwolf]

Ah, but does that work for ships that have been removed from the game?

[Goober5000]

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).

[Nuke]

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"

[ChronoReverse]

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.

[Zacam]

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)

[KeldorKatarn]

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]

[zookeeper]

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?

[KeldorKatarn]

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.

[Goober5000]

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.

[Zacam]

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)