Excalibur Targeting ROM

[Cygnus.X1]

http://xelerus.de/index.php?s=mod&id=1230



In the style of the Enhance SRS ROM and Targeting ROM, the Excalibur Targeting ROM installs software (as in, it doesn't take a device slot and uses minimal power) that adds a series of aiming reticles in front of your ship. That part at least is working perfectly. As you can see in the screen shot, it's currently excessive but that's because I'm puzzling out some alignment issues. Screenshot updated...

I tagged it as a dev mod because I'm nowhere near finished. I'm currently working on making one of the aiming reticles lead targeted enemy ships (and failing miserably at the moment ). I also plan on making dock screens (more new stuff to learn) that will allow for different configurations and selectable graphic sets. Obviously there are more updates coming soon, and in testing, saved games will not pick up new overlay settings.

[Edit] Re: saved games, come to find out I outsmarted myself. Although it will eventually be replaced by a dockscreen that includes an install/uninstall option, currently if you se the ROM item it will install or uninstall itself, which in turn uses <OnEnabled> and <OnDisabled> to add or removed the overlays. So, if you load a saved game after making changes to the overlay settings TLisp code, just use the item to uninstall and then install it and the new overlays will have your code changes.

[Watch TV, Do Nothing]

Very cool! Is it possible to make the reticle sprite rotate to orient itself with the direction that you're firing?

Another (scripting-intensive) application would be to mark the outer boundaries of weapon spread or for delayed-fragmentation weapons like the Medusa to indicate (and even manually adjust?) the range at which fragmentation occurs.

[Cygnus.X1]

Very cool! Is it possible to make the reticle sprite rotate to orient itself with the direction that you're firing?

Not sure, but it is on my list to investigate for advanced functionality additions. Creating a 40-faces aiming reticle grid image is one option, but that would be hideously annoying to create, much less code. I don't think the game engine has a built in sprite rotation functionality either, so don't hold your breath on that one.

Another (scripting-intensive) application would be to mark the outer boundaries of weapon spread or for delayed-fragmentation weapons like the Medusa to indicate (and even manually adjust?) the range at which fragmentation occurs.

Ah, heh, well, showing the range of weapons could be possible after I figure out how to lead targeted ships, as doing so may include the need to use your active weapon's projectile speed. If I can finger that out, then it should be easy to extend that to figure out the projectile lifetime and extrapolate the detonation range. I'm not convinced I can tie the reticles into launcher weapons though. I'm not even going to try to adjust the detonation range of a weapon in-game, I'm pretty sure that's not possible outside of editing XMLs before the game is launched.

Meanwhile, I figured out the alignment issue. It seems Trans somehow reduces the bounding box of an overlay to match the active pixels (as in, non 00/black pixels), which in turn messes with the alignment of the overlays which are placed using a 0x0y coordinate to start with. The solution was to put four pixels colored 10,10,10 in the corners of each reticle section so the game engine doesn't alter the bounding boxes.

[RPC]

Sweet, another UI mod!
This sounds like something I would do...

[Cygnus.X1]

Sweet, another UI mod!
This sounds like something I would do...

Orly? Prolly 'cause I started by looking at your AdvLRS code to figure out how to make overlays.

I found a huge and likely insurmountable problem with triggering custom events inside of <ItemType>s, as sysAddTypeRecurringTimerEvent and similar expressions don't trigger the event it's supposed to. Sooooo it's looking more and more like I'm going to have to finger out virtual stations as well to handle recurring events. I'm going to work on making a configuration dockscreen instead

Latest code chunk: http://paste.neurohack.com/view/YfvCn/

[RPC]

Virtual stations are how I got the LRS to work >.>

[Watch TV, Do Nothing]

Not sure, but it is on my list to investigate for advanced functionality additions. Creating a 40-faces aiming reticle grid image is one option, but that would be hideously annoying to create, much less code. I don't think the game engine has a built in sprite rotation functionality either, so don't hold your breath on that one.

yeah, no sprite rotation that I know of either.

how are lasers drawn onscreen? are they line of tiny overlapping sprites or is it some other process? how about the L-shaped lines around targeted ships?

[Cygnus.X1]

how are lasers drawn onscreen? are they line of tiny overlapping sprites or is it some other process? how about the L-shaped lines around targeted ships?

Internal graphics rendering engine. AFAIK the vast majority of the vanilla stock effects are just pre-coded <Shape>s in layers. Newer weapons that George made have their weapon effects defined in their XML code, like the xeno lancer. GUI elements are either sprites with a lot of dynamic masking (like the armor HP display), or pixel drawings from the internal rendering engine.

Updated the screen shot in the OP, showing off short, medium and long range

Fourfire: Most vanilla weapon projectiles in Trans last longer than it takes for the projectile to get off-screen, sorry but in most cases having a dynamic reticle to show weapon range won't do any good.

[Cygnus.X1]

I got really frustrated last night...

http://wiki.neurohack.com/transcendence ... icket/1206

So I feel a little better now.

[Cygnus.X1]

Reuploaded at 18 downloads (wow, 18 already? sweet!!)

Added a dockscreen triggered by se. Don't hit "Activate" more than once (or make sure to use "Deactivate" prior) or you wind up with extra reticles that won't go away. I can fix that...

Since adding the range selection options to the dockscreen, some alignment problems with the reticles have cropped up again, especially on the medium range setting. I think I can fix that.

Still have a lot of work to do on the dockscreen. intAutoInstall was much easier to use, but you couldn't dynamically change the range options. 2 steps forward, 1 step back, or something like that.

[Cygnus.X1]

Release Candidate 1 uploaded at 20 downloads

I learned a lot, but what it boils down to is K.I.S.S. and not using setq for variable storage within a dockscreen, as there is no reliable way to initialize such variable and allow for modifications of that variable without it getting initialized again.

The new batch of docksreen code is a lot more efficient, no more 'Activate' command, just select your range and quit and the work is already done. You can still deactivate, just in case.

[Cygnus.X1]

RC2 (alpha) uploaded

"Alpha" because there is a bug in the code that changes the dockscreen descriptions, however everything else is fully functional as intended.

[Cygnus.X1]

In depth update, because I was in a hurry last night...

Because you can only have up to 8 actions per pane, I had to create 3 panes. The 1st pane lets you select your range, then on the 2nd pane you can select the size of the reticles, and finally on the 3rd pane either quit to keep the settings or deactivate the aiming system and then quit.

I made a quick test run with a normal ship and realized I haven't compensated for it being an item that should be installed before being able to be used. Because this is not a ROM that calls an intrinsic device-like function like the Targeting CPU, I can't completely duplicate that kind of function, so it has to be an installable device via docking services.

[Cygnus.X1]

Official Version 1 Complete!

I fixed all the dockscreen issues, and have made it so that you have to install the item before you can use it, and it automatically deletes the aiming reticles when you uninstall it.

For best results, make sure your ship is facing in a cardinal direction before you active the reticles or you may have some alignment issues. This is due to rounding math in the game engine and there's nothing I can do about that.

My next goal is the hard one. For ease of use and plot stuff, I'm working on ExTargROM II, which will have the target leading reticle I've been talking about.

U/L'd @ 34 D/L's

Yep, that's right, I'm pretty damn happy so I'm calling it Version 1. No more bugs, must be installed as a device (but takes no slots) before use.

Version 1.1 will include a separate item, ExTargROM II, just for a target leading reticle of some kind That's going to take a while tho. Enjoy!

[Cygnus.X1]

http://paste.neurohack.com/view/YAUkW/

The heart of the target-leading reticle is in place, but not quite working as intended. I'll be asking for help on IRC soon enough as soon as I can find the time, but the above pastie link is a sneak peak at what I've got so far. The execution flow is fine, but something's off in the way I'm using the overlay positioning or the syscalcfiresol function or some such.

Code: Select all

(objSetOverlayPos gPlayerShip (objGetData gPlayerShip "lead1") (sysVectorPolarOffset gPlayerShip (sysCalcFireSolution (objGetPos (objGetTarget gPlayerShip)) (objGetVel (objGetTarget gPlayerShip)) (typGetDataField (itmGetType (objGetProperty gPlayerShip 'selectedWeapon)) "speed")) 3))

That's one line... yarg.