Excalibur Targeting ROM

[TVR]

Try replacing (sysCalcFireSolution ...) with the following:

Code: Select all

(sysCalcFireSolution (sysVectorSubtract (objGetPos (objGetTarget gSource)) (objGetPos gSource)) (sysVectorSubtract (objGetVel (objGetTarget gSource)) (objGetVel gSource)) (typGetDataField (itmGetType (objGetProperty gPlayerShip 'selectedWeapon)) "speed"))

These take the position vectors and velocity vectors relative to the playership, instead of the center of the system.

[Cygnus.X1]

Try replacing (sysCalcFireSolution ...) with the following:

Code: Select all

(sysCalcFireSolution (sysVectorSubtract (objGetPos (objGetTarget gSource)) (objGetPos gSource)) (sysVectorSubtract (objGetVel (objGetTarget gSource)) (objGetVel gSource)) (typGetDataField (itmGetType (objGetProperty gPlayerShip 'selectedWeapon)) "speed"))

These take the position vectors and velocity vectors relative to the playership, instead of the center of the system.

Thanks!!

I think that did it, actually testing testing testing

[Cygnus.X1]

Ver1.1a uploaded at 38 downloads ^_^

Core functionality on the Advanced ROM is complete, you can now have a reticle indicator of what angle your ship needs to be at to hit whatever you have targeted.

ToDo:

. 40 facing "laser line" graphic

. multiple leader reticles

. config dockscreen for Adv ROM

. incorporate all code into a single XML file

That pretty much sums it up You'll notice flickering on the leading reticle from the Adv ROM when you turn your ship. There's nothing I can really do about that.

I haven't yet tested the survivability of the virtual station through gating to other systems. At the very least I'm pretty sure uninstalling and re-installing the Adv ROM will restore all functionality.

[Cygnus.X1]

. multiple leader reticles -> this will be easy but I need to get other stuff figured out first
. config dockscreen for Adv ROM -> not much to config as yet
. incorporate all code into a single XML file -> when all is said and done...

. 40 facing "laser line" graphic -> this is ugly so far

So, I figured out that what you attach an overlay to affects it significantly. When attached to gPlayership, the overlay will rotate around the player's ship as your ship rotates, which was causing near epileptic flickering. I've fixed that by attaching the overlay to virtual station used to control the recurring timer events instead, which makes it look a lot better. I'm still working on getting the overlay angle to line up with the firing solution, which wil lmake a "laser line" possible.

Happy Turkey Day y'all!

[Cirevam]

Have I mentioned how much I like this mod? It's great and extremely useful. I think it should be a must-have whenever I play.

[Cygnus.X1]

Aww, thanks! Always glad to know when somebody else likes to play with my creations

Ver 1.2 uploaded (@ 52 downloads)

The leading target overlays from the Advance ROM are now working quite well. I've also figured out how to make the whole thing survive gating to a new system without odd behavior. Apparently not

This update is not compatible with previous save games, sorry.

ToDo:

. Figure out if configuration via dockscreen will add any value

. Incorporate all code into a single XML file (which will likely break previous save games as well, fair warning)

So I now have 3 laser-like target leading overlays working, and so far have squashed all bugs related to gating that I could find. I'm debating if configuration via dockscreen would be worth it for the advanced ROM.

Some odd tidbits I've learned along the way:

. Overlays are not automatically destroyed when the object they are attached to is destroyed (or left behind)

. Virtual Stations do not follow the playership through gating, and may even be left behind in the previous system. (Either way I'm pretty sure I've compensated for it.)

. A stupidly overpowered ship drive with an excessively high thrust makes for very difficult testing of attacking while drifting

. A laser beam effect is 2 light seconds long

[Cygnus.X1]

ARGH! I've uploaded a bug-fix for gating problems. I've got the virtual station to successfully be created when you gate to different systems, however make sure to turn off any active targeting before you gate out or the target leading overlays will persist when you return to the system and will be stuck at whatever heading they were at when you gated out.

tl;dr version: quick bugfix uploaded, but hit [R] before you hit [G] to gate out...

[Cygnus.X1]

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

That is the latest code chunk, but I haven't bothered uploading it to Xels because it's functionally the same as the previous version. It's driving me crazy...

There's only one problem, and I'm afraid it might be a game engine bug. If you have the AdvTarg engaged, and have an active target with the leading overlays showing, then gate out of the system, I have code (redundantly even) to remove the overlays before you leave. However, no matter what I try, if you return to the previous system, you will be stuck with 'frozen' overlays pointing in the same direction they were at when you left in the first place.

The workaround is to make sure you remove active targeting (key [R] ) before you gate out (key [G] ), but that's sub-optimal to me. I'm hoping somebody will have a bright idea before I give up and write up a bugtrac ticket. Any suggestions out there?

[TVR]

Use this for recurring event timing control, rather than the virtual station method:

Code: Select all

<ItemType UNID="&Timer;"
		name=				"Timer1"
		level=				"5"
		value=				"2500"
		mass=				"3000"
		frequency=			"uncommon"
		modifiers=			"MajorItem; NAMI"

		description=		"This device will execute the <OnFireWeapon> event in itTimerEvent once every tick."
		>

	<Image imageID="&rsItems1;" imageX="0" imageY="192" imageWidth="96" imageHeight="96"/>

	<AutoDefenseDevice
			targetCriteria=	"G N:10000"
			weapon=			"&itTimerEvent;"
			fireRate=		"1"
			/> <!-- fireRate controls how often the recurring event should fire, 1 or 2 = 30 times per second, 3 = 15/s, 5 = 10/s, 15 = 6/s, etc. Default target criteria is when a gate is within 10k ls, which means it will almost always trigger, and weaponDevice is a special dummy weaponDevice that only includes the code to be executed and some additional parameters -->
			
	<Events>
		<OnInstall>
			Nil
		</OnInstall>
	</Events>
</ItemType>

<ItemType UNID="&itTimerEvent;"
		name=				"Timer Event"
		level=				"5"
		value=				"2500"
		mass=				"3000"
		frequency=			"notrandom"
		modifiers=			"MajorItem; NAMI"

		description=		"When fired and only when fired from an AutoDefenceDevice or the weapon fire button, this weapon device executes the code placed under its <OnFireWeapon> event."
		>

	<Image imageID="&rsItems1;" imageX="96" imageY="0" imageWidth="96" imageHeight="96"/>
	
	<Weapon

			type=			"missile"
	
			damage=				"generic:0"
			fireRate=			"15"
			powerUse=			"100"
			
			sound=			"&snRecoillessCannon;"
			> <!-- powerUse controls the amount of power consumed by the timer device, fireRate is only used if this device is installed separately from the timer, and sound will play every cycle, other keys have no function -->
	</Weapon>
	
	<Events>
		<OnFireWeapon>
			<!-- repeating code here -->
		</OnFireWeapon>
	</Events>
</ItemType>

This does not require a new station per system, instead, the timing control device stays on the spaceObject once installed. <checkTarg> can be transferred to <OnFireWeapon> with no or minimum modification.

[digdug]

@TVR
that's a very clever way to fire a recurring event once per tick. You can use virtual itemTypes so that your event bearing items won't show anywhere.

That is the latest code chunk, but I haven't bothered uploading it to Xels because it's functionally the same as the previous version. It's driving me crazy...

There's only one problem, and I'm afraid it might be a game engine bug. If you have the AdvTarg engaged, and have an active target with the leading overlays showing, then gate out of the system, I have code (redundantly even) to remove the overlays before you leave. However, no matter what I try, if you return to the previous system, you will be stuck with 'frozen' overlays pointing in the same direction they were at when you left in the first place.

The workaround is to make sure you remove active targeting (key [R] ) before you gate out (key [G] ), but that's sub-optimal to me. I'm hoping somebody will have a bright idea before I give up and write up a bugtrac ticket. Any suggestions out there?

What I do is simply to check if the station that has my recurring event is already in the system when the playership enters a system, if not, create it, if it is, then everything is ok, since the event is already running.
You can also mark the system with sysSetData to quickly check if you have your event station in the system.

[Cygnus.X1]

What I do is simply to check if the station that has my recurring event is already in the system when the playership enters a system, if not, create it, if it is, then everything is ok, since the event is already running.
You can also mark the system with sysSetData to quickly check if you have your event station in the system.

TVR> That's... impressive! Can't wait to try it out.

RPC and I had a very similar discussion via IRC, and with two experienced modders having the same idea, sounds like a plan to me. Which, well, will be my backup plan if TVR's idea doesn't pan out

RPC did help me find a significant bug in my coding. I'm creating the virtual station every time the playership enters a system, and my method of making sure the virtual station is destroyed is fatally flawed. This means duplicating virtual stations and overridden ship-stored variables mucking about with my methods of controlling those stations. I'm no longer confident in my statement that overlays are automatically removed when the object they are attached to is destroyed as well. RPC and Digdug's solution is the only way to continue with the coding structure as it is now.

Stay Tuned

[Cygnus.X1]

I've munged up my own code so much I've had to restore backups three times now

TVR, your solution is brilliant, but I can't attach an overlay to non-space-objects, and I can't attach them to the player ship or the overlays flicker terribly. I have other timed event ideas that I may use that moment of genius of yours for.

RPC and Digdug's idea for tracking each virtual station by system name seems to be the best route for now, but coding that is giving me a literal headache I will persevere

[TVR]

It's much easier to attach the overlay to the origin station, ie the primary star, than a virtual station.

Replace gSource with (sysFindObject Nil "t N"), this will return the spaceObject that is guaranteed to be present in any system, will always be the same spaceObject, and can be called from anywhere.

Otherwise, another solution involves adding a new, automatically disappearing overlay to gPlayership every tick. (objAddOverlay obj overlayType [pos rotation] [lifetime]) takes an optional lifetime argument, which can be set to 1 as to disappear on the next tick.