[HELP / REQUEST / PROJECT] improved target activation with SirNuke's hotkeys

[kuertee]

2. is there another way than find_object_component to find subcomponents? I tried it with find_object and added e.g. class.turret to the search, but that doesn't work. This is about adding subcomponents directly under the cursor, i.e. extending the "line-of-sight" search with subcomponents, which does not work yet...

Hmmm ... i don't know. If I have my assumptions correct, can't you get the ship or station under the cursor, find all their surface elements, then assume that the nearest one (i.e. $surfaceElement.distanceto.{player.entity}) to the player would be under the cursor.

3. do only wards, L and XL ships really have sub-components? You can also build turrets on an M... But I can't find them with the Egosoft search either...

nah, turrets on M ships should be findable. if <find_object_component /> is empty try: $ship.turrets

4. in your mod, Kuertee, there is the line: "<find_object_component groupname="$surfaceElements" object="$lastDefensibleTarget" operational="true" surfaceelement="true" multiple="true">". However, an auto-check with common.xsd and scriptproperties says this is wrong, operational="true" is supposedly not supported there. You might also be able to check it with a do-loop, but I don't know which is better. The way you do it is more elegant, but does it work properly?

it likely doesn't. the compiler didn't complain. but I do find that mod not targeting the next surface element. and on investigation, I found that its because the next surface element wasn't yet operational. so, I tried adding the "operational" parameter - which didn't work, because I'm still finding that mod not going to the next surface element.

5th (slightly different topic): If I add a commodity, e.g. to make advanced target functions (missile unlocking e.g.) dependent on expensive software, then this is no longer save-compatible, or is such a commodity simply ignored when the MOD is deleted again? Is there any way to do this anyway and remain safegame compatible?

sorry, I don't know. I've not attempted to add a new object type apart from new factions.

6. is there somewhere a good tutorial (written, video translate is very exhausting for me), where the cues etc. is well explained? How do I nest them? Where does the programme jump to when I call cancel_cue? What does "this" or "parent" mean? How do I share variables elegantly in a common namespace, at the moment I do everything via global.xxx, which is perhaps not so clean... Way too many questions to answer directly, therefore tutorial, I need a crash course

unfortunately, no tutorial apart from X4's Wiki on the Mission Director.

All cues are actioned once only (except if it instantiates) - until they are reset. And all sub-cues are inactive (doesn't receive signals) until their parent cue is active or completed (i.e. actions in the parent cue have executed, but all its sub-cues are waiting for their signals). When a cue is reset it returns to its waiting state. All its subcues become disabled (and all variables and properties declared in the cue and its subcues are garbage collected).

[Trajan von Olb]

Thanks as always, Kuertee!

2. is there another way than find_object_component to find subcomponents? I tried it with find_object and added e.g. class.turret to the search, but that doesn't work. This is about adding subcomponents directly under the cursor, i.e. extending the "line-of-sight" search with subcomponents, which does not work yet...

Hmmm ... i don't know. If I have my assumptions correct, can't you get the ship or station under the cursor, find all their surface elements, then assume that the nearest one (i.e. $surfaceElement.distanceto.{player.entity}) to the player would be under the cursor.

Unfortunately, this doesn't work so well for several reasons, because the next object is not automatically the line of sight, not even the next ship - for example, if I hide behind a thick ship, but then want to target the engines of another ship from there. It should also feel like a direct selection under the cursor, like a mouse click in the middle.
After some trial and error, it now works quite well with the line-of-sight component search. However, the larger cannons are somehow sometimes obscured by some clipping and thus difficult to find, which is exactly what happens when you have an oblique viewing angle.
I will therefore experiment with "find_object_surface" at some point in the future. If I'm right, then you can target any point on the surface in the line of sight, which results in a position. I would then define this as the search centre point and start a component search from there. This way, the object closest to the point of view should always be found, even if it is not directly in line of sight. But that's so much trial and error, and I don't yet know how to define the player's angle of view as the starting point, that I'll move it for now, otherwise the MOD will never be finished

3. do only wards, L and XL ships really have sub-components? You can also build turrets on an M... But I can't find them with the Egosoft search either...

nah, turrets on M ships should be findable. if <find_object_component /> is empty try: $ship.turrets

I'll try that. But I was sceptical because even the Egosoft targeting doesn't find any subcomponents at an M... But that would be an added value if I could do it... Great tip in any case!

4. in your mod, Kuertee, there is the line: "<find_object_component groupname="$surfaceElements" object="$lastDefensibleTarget" operational="true" surfaceelement="true" multiple="true">". However, an auto-check with common.xsd and scriptproperties says this is wrong, operational="true" is supposedly not supported there. You might also be able to check it with a do-loop, but I don't know which is better. The way you do it is more elegant, but does it work properly?

it likely doesn't. the compiler didn't complain. but I do find that mod not targeting the next surface element. and on investigation, I found that its because the next surface element wasn't yet operational. so, I tried adding the "operational" parameter - which didn't work, because I'm still finding that mod not going to the next surface element.

Maybe I can be of help here for a change. I have found the following way to check whether a surface element is operating, which seems to work very well:

Code: Select all

			<do_if value="$ptargetparent">
				<find_object_component groupname="$things" object="$ptargetparent" surfaceelement="true" multiple="true" sortbydistanceto="player.entity">
				</find_object_component>
				<do_all counter="$i" exact="$things.count">
					<do_if value="$things.{$i}.issurfaceelement and $things.{$i}.isoperational">
						<add_to_group groupname="$knownThings" object="$things.{$i}" />
					</do_if>
				</do_all>
			</do_if>

6. is there somewhere a good tutorial (written, video translate is very exhausting for me), where the cues etc. is well explained? How do I nest them? Where does the programme jump to when I call cancel_cue? What does "this" or "parent" mean? How do I share variables elegantly in a common namespace, at the moment I do everything via global.xxx, which is perhaps not so clean... Way too many questions to answer directly, therefore tutorial, I need a crash course

unfortunately, no tutorial apart from X4's Wiki on the Mission Director.

All cues are actioned once only (except if it instantiates) - until they are reset. And all sub-cues are inactive (doesn't receive signals) until their parent cue is active or completed (i.e. actions in the parent cue have executed, but all its sub-cues are waiting for their signals). When a cue is reset it returns to its waiting state. All its subcues become disabled (and all variables and properties declared in the cue and its subcues are garbage collected).

Just so I understand this correctly: I can, for example, put the entire MOD in a cue, whereby the initialisation, e.g. the definition of hotkeys and variables, happens in the main cue. The individual functions (after pressing a key, for example) are then sub-cues. And instead of the "global.$var" variables, I can then use "parent.$var"? Or instead of "parent" the name of the main cue? Do I then always have to check the wait state before a cue is executed so that the initialisation is completed? A new initialisation is then carried out with "Reset", for example, right?
And what about the instances? Isn't there a danger when I instantiate that a new cue is opened each time while the old one is still in the wait state? Doesn't that clutter up the memory?
Last question: What happens (when I instantiate) when the last command of a cue is processed, does the cue then go into the wait state? And if it is then called again (directly or by a condition), does that happen in the waiting cue or is a new one opened? (This actually belongs to the previous thought)...

Thanks as always for answers! Super RESPECT for that and for your MODs, you are really busy

Schmollo aka Trajan von Olb


Translated with www.DeepL.com/Translator (free version)