XWA Upgrade

You two seem to be the guys who are the "Mission Update Team", so you seem to know what all the new changes and status stuff are, I would have thought that you might change the Allied Files yourselves, instead of waiting foe someone else to change them for you, so if you would please be so kind as to stop jabbering on about what does what and upload your versions of the Allied Files please or are Bmans version more up to date than yours?

Thank you

I will check my Allied txt files.

Bman Class.txt and Conds.txt are up to date.

There is an error in Status.txt: should be replaced whith: Except that, Status.txt is up to date.

In Status.txt these lines:

Already Identified
Inspected?
Identified?
Limited Targetability?

should be replaced by

Already Inspected
Already Identified
Limited Targetability?
28

JeremyaFr wrote: ↑

Tue Mar 05, 2019 2:49 pm

The status number 27 is only evaluated for status1, not for status2.

Was there only one status field in any of the past games? Could be simple neglect to update the handling code. Or it could have a different, as yet undiscovered meaning in status2 (although I think that unlikely).

I thought you knew what Status 28 was? Due the Cargo Hangar in the Prologue missions having this status??

And thanks for the update

Thanks Mark, noted. Yeah, if you guys could experiment to see what values 28 through 50 represent in Status.txt, that would be awesome. Any of the AlliED files. A brief description is better than just a number i.e. 27, 28, .... I think a lot of info is derived from the Strings.txt file in main directory which has a ton of conditions the game may read from. Some lines/slots are unfinished. Perhaps some things are hard coded, not clear on that.

Darksaber wrote: ↑

Tue Mar 05, 2019 8:12 pm

I thought you knew what Status 28 was? Due the Cargo Hangar in the Prologue missions having this status??

If you are referring to the Container Hangar which gets replaced by 14 objects (maybe 15?) inside the hangar of Azzameen Station, Status 1 has always been set to 27 (Limited Targetability?)

@Mark_Farlander, ok I apologies, my mistake, it's the Container Hangar and status 27, opps!

keiranhalcyon7 wrote: ↑

Tue Mar 05, 2019 6:37 pm

Was there only one status field in any of the past games? Could be simple neglect to update the handling code. Or it could have a different, as yet undiscovered meaning in status2 (although I think that unlikely).

X-W and TIE had a single status, XvT added the 2nd one which carried over into XWA.

I remember about a very old DS2 Superlaser tutorial, aviable at the old XWLegacy site. Thanks to this tutorial it was possible to use the backdrop of the Second Death Star as a Superweapon for the SSDII Legacy. Unfortunatly I don't find the tutorial in my Hard Drive

As I remember, the name of the DS2 Backdrop is the time of the Superlaser fire sequence: in B7m2 the DS2 backdrop is called "3.00 599.00". The first shot of the DS2 is 3 seconds after the start of the mission. The other shots happen after 599 seconds next to the prevoius one. The target of the Superlaser are set in the "Orders" section. The order type is not important: the primery target is the first victim of the Superlaser. The secondary target are the next targets.

As I remember it's possible to set the size of backdrop as 0, to make the origin of the superlaser invisible. Also, it's possible to set the coordinates of the DS2 backdrop >1.00, to give a precise position at the Superlaser start. As I sais, this worked for the SSDII Legacy OPT, that has a big Gun on the noise...
Superlaser should be tested...

Minor update: the first "No Effect?" box (the one at the bottom left corner) for the "Deliver/drop off" order is the number of Flight Group where the craft with such order is going to deliver the object.
Just remember that the first Flight Group of the list in AlliED (Flight Group #1 of X) is considered the number 0, so you have to input "1 less".
If the station where the craft is going to deliver the container is Flight Group #N, then you have to input N-1 in the box.

Has anyone found any additional features with the "(orbit)" command?

You know, much of this would be a lot easier if the fg list just started counting at 0 instead of 1.

Yeah, same thing for the Team number, as the "Defect" order takes Team 1 as Team 0.

ual002 wrote: ↑

Fri Jul 19, 2019 9:54 pm

Has anyone found any additional features with the "(orbit)" command?

Do you mean Orbit/Permanently disabled or Follow Targets/Orbit?
Orbit/Permanently disabled is used to make a craft travel in a circular orbit with center in (0, 0, 0).
Follow Targets/Orbit is used to follow an object when you are in the gun turret position (1b0m2fw).

Both bits are useful, however I meant the first one. Are there any modifiers?

I just did a few tests and came to the following conclusions.
If (Orbit)/Permanently disabled is the first order a craft or Flight Group performs (with Jump to order condition set to Always true), it's simple to set the center and the radius of the orbit:
the center is Waypoint 1, but with your surprise YOU MUST NOT ACTIVATE IT (I know this sounds absurd), just set WP1 coordinates, but keep it deactivated;
the square of the radius is given by the sum of the square difference between the coordinates of the Start 1 point and those of the Waypoint 1 (simply Theorem of Pythagoras).

Just make sure to have the WP1 available for this thing, so avoid using it as a hyperspace emersion vector in case the craft does not start in that region.

This works with Z coordinate set to 0, both for the Start 1 point and the Waypoint 1.



As for the first N (N<8) waypoints activated and/or at least 1 Z coordinate different from 0, further testing is required.

I know this is not much, but it's something to begin with.

Edit: It also works if you activate WP1.

I'll test that.

One other question: Has anyone figured out if the editor has any conditions to determine if a ship's engines have been knocked out without actually being disabled?

If the Start 1 point and the WP1 have the same Z coordinate, it works as I wrote in my previous post, with the orbit parallel to the X0Y plane at height H=Z.

If the Start 1 point and the WP1 have different Z coordinate, I have obtained some contrasting results, but it seems that the Z coordinate of the WP1 is "not always" the Z of the center, because the craft cannot travel below a certain Z level (while orbiting), which I was not able to determine.

As for the first "No Effect?" box of the (Orbit)/Permanently disabled order (the one at the bottom left corner), it is the number of loops.
The maximum is 255, but you can input 0 to have infinite loops, just like the Circle waypoints order.

Mark_Farlander wrote: ↑

Sat Jul 20, 2019 4:44 pm

As for the first "No Effect?" box of the (Orbit)/Permanently disabled order (the one at the bottom left corner), it is the number of loops.
The maximum is 255, but you can input 0 to have infinite loops, just like the Circle waypoints order.

This doesn't seem to work. Its having no effect.

Is the 0 setting having odd behavior or is the first box having no effect at all, regardless of the number you input?

Which settings did you use for the other 2 "No Effect?" boxes?
Mine were set to 1 (the second box) and 0 (the third box).

No effect, and the other boxes were set the same as you.

I also dove into the alert siren feature in the beginning of battle 2 Mission 5. Hoping its function was related to another one I'm trying to figure out. I also was not able to find any clues to how it works in either Allied or Yogme. I can also confirm that the suspicion its tied directly to a flight group setting can be confirmed.

In editing the TIE Fighter missions through XWA I discovered an issue with the Rendezvous order. No matter what the move waypoints were set to, it ignored them all and always attempted to move to 0.00 0.00 coordinates. After much tinkering and noticing the order description is 'Fly to Rendezvous WP' implying a specific waypoint type, I finally discovered this could be changed by altering the co-ordinates of the Start 3 ? option (regardless of it being enabled or not).

Great job, AngeI. This is one less unknown point.

OK. Reporting this interesting thing here (after testing a few missions): the Departure event via hyperspace does not count to make the "must leave region" condition become true.
If a Flight Group is located in region N, its Departure condition is triggered and it enters hyperspace, this does not make the "[Said FG] must leave region N" condition become true.

From this I can deduct that the only way to make such condition become true is using the "Hyper to Region #Y" order for said Flight Group.
In other poor words "Hypering out of area" because of the Departure event does not count as "leaving region", whereas "Hypering out of area" because of the specific order counts.

I think a section "Conditions" in the AlliEd part of the Mod-Wiki will be needed.

Edit: How the "Fly home" order triggers with the "must leave region" condition also needs to be investigated.