Some mission lose the message pause after save

[luca2125]

Hi Mike,

In the attached mission 1b14m1hf1tf.zip .

After save and don't change nothing the message times are showed without pause.

The original file that I have attached play 4/5 messages and after stop and wait the events.

After save, all messages are play without paused and without wait any event.

Can you check please ?

Thanks !

[MikeG621]

The problem is that all of the messages have been changed to "OR always", which will cause the message to always fire. If you set them to "AND" per the original XvT mission, it should work just fine.

On Sun, Feb 28, 2021 at 5:22 AM luca2125 notifications@github.com wrote:

Hi Mike,

In the attached mission 1b14m1hf1tf.zip https://github.com/MikeG621/YOGEME/files/6056691/1b14m1hf1tf.zip .

After save and don't change nothing the message times are showed without pause.

The original file play 4/5 the messages and after stop and wait an event.

After save all messages are play without paused and without wait any event.

Can you check please ?

Thanks !

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5EQPSPXCDKYNRFP7KILTBIRNZANCNFSM4YK6VERQ .

[luca2125]

Hi Mike,

I confirm that if I change from "OR" to "AND" the mission work.

The original file came from "Tie Fighter" and not from "Xwing Vs Tie Fighter"

If I keep untouched with "OR" without save the mission work.

To avoid to test manually each mission what is control that I need to do to avoid this situation ?

Can I use you c# api to it ?

Thanks !

[MikeG621]

While testing the conversion from TIE works fine on my end, looked a little closer and noticed that the Converter.exe with the 1.9.1 release somehow reverted to an older revision. I've uploaded a "r2" zip file on the latest YOGEME release in case it was a problem with the original conversion from TIE. Converter should be v1.6. That said, I can't replicate this even with the older v1.5 Converter, although it's got other issues.

"If I keep untouched with "OR" without save the mission work." This implies that the mission file itself is fine (converted with "AND"), and something is causing YOGEME to flip the buttons, which then stores it on save. I can't get this to happen.

"To avoid to test manually each mission what is control that I need to do to avoid this situation ?" I don't know what you're asking.

On Sun, Feb 28, 2021 at 8:25 AM luca2125 notifications@github.com wrote:

Hi Mike,

I confirm that if change to "OR" to "AND" the mission work.

The original file came from "Tie Fighter" and not to "Xwing Vs Tie Fighter"

If I keep untouched with "OR" without save the mission work.

To avoid to test manually each mission what is control that I need to do to avoid this situation ?

Can I use you c# api to it ?

Thanks !

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-787460810, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5ESTTXCTGECZ3DNWXOLTBJG5RANCNFSM4YK6VERQ .

[luca2125]

"To avoid to test manually each mission what is control that I need to do to avoid this situation ?" I don't know what you're asking.

I try to explain better:

In this period I working about the old conversion of Tie Fighter / Xwing / XVT (about 270 missions).

These missions are not made by me, but seem work fine.

If I keep untouched these missions work, but I like to add multilanguage support of these missions (that need to save all of these).

Actually there is the risk that if I save some mission, this problem may occur.

My question is:

To get sure to avoid this risk and set automatically "AND" Is there a risk of running into other problems ?

What happen if I set to "AND" to a mission that need to "OR" ?

I don' t known when is correct "OR " and when is correct "AND".

In other words, what type of control I need to do for each mission to prevent it ?

Thanks !

[MikeG621]

It is impossible to automatically know what the "correct" value is without comparing it to the original mission if you don't know the original intent for the logic flow, as some will require "AND" and some will require "OR". Trying to set all of them one way or another is guaranteed to break something. In general though "AND always (TRUE)" and "OR none (FALSE)" is going to be the answer when one of those are used, but it gets more complicated when there's more than one trigger involved.

Converting missions between platforms isn't always a straightforward process; a mission designed for X-Wing or TIE may play very differently in XWA even if the conversion is "perfect". If you're working with an "old conversion" of missions, I don't know if they were converted or rebuilt by hand, so I don't know how they would compare to the originals. Ultimately I would need an example mission that works before you touch it, that same mission when it doesn't work, and I'd need to know exactly what you did to it when it broke.

On Sun, Feb 28, 2021 at 9:38 AM luca2125 notifications@github.com wrote:

"To avoid to test manually each mission what is control that I need to do to avoid this situation ?" I don't know what you're asking.

I try to explain better:

In this period I working about the old conversion of Tie Fighter / Xwing / XVT (about 270 missions).

If I keep untouched these missions work, but I like to add multilanguage support of these missions (that need to save all of these).

Actually there is the risk that if I save some mission, this problem may occur.

My question is:

To get sure to avoid this risk and set automatically "AND" Is there a risk of running into other problems ?

What happen if I set to "AND" but another mission need to "OR" ?

In other words what type of control I need to do for each mission to prevent it ?

Thanks !

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-787471353, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5EWHXI2N64CK4J65BOLTBJPOFANCNFSM4YK6VERQ .

[luca2125]

Many Thanks Mike !!

Attached you find the untouched mission (2015) and the some mission saved (without change nothing, only press "save").

test_xwa.zip

Hope can be solved.

Thanks !

[MikeG621]

Okay, I see what it is. The real problem is the 2015 mission is bad. There's some information that was in the original TIE mission that was used as editor-only notes, and it was partially written into the XWA conversion, but out of order, and in a bad spot. So if the note in TIE was "ABCDE", it was written into XWA as "CDA". There is a place for editor-only notes in XWA, but it's not even close to being positioned correctly. No idea how these files were created to get that kind of messy output.

Unfortunately, the example "A" that was written in XWA is at the location for the "AND/OR" value. Typically, any non-zero value is treated as "TRUE", which is then read by YOGEME as "OR", and only a 00 means "FALSE", which YOGEME reads as "AND". XWA on the other hand, if the originals are working as intended, must be explicitly looking for a 01 to be "TRUE" and treating everything else as "FALSE". This isn't normal.

So information that should not be there that XWA is ignoring is being read into YOGEME, which then on the first save writes it back out to the "correct" value of 01, which XWA then accepts. I suspect that you're going to have this problem with most missions from the set that you're working with, at least for the TIE conversions.

Now that I know it's a bad mission file that's causing it, I could create a fix so YOGEME uses the XWA method of true/false in this specific case, but like I said this is not normal, and I'm not going to apply this everywhere due to the potential consequences. I don't even know if this "01 only" method is used everywhere, or just here.

On Sun, Feb 28, 2021 at 10:31 AM luca2125 notifications@github.com wrote:

Many Thanks Mike !!

Attached you find the untouched mission (2015) and the some mission saved (without change nothing, only press "save").

test_xwa.zip https://github.com/MikeG621/YOGEME/files/6057212/test_xwa.zip

Hope can be solved.

Thanks !

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-787479309, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5EU456G2LBS6PPJYNQLTBJVV7ANCNFSM4YK6VERQ .

[luca2125]

Many Thanks Mike,

In the meantime I have found another hipotetic issue:

delay_difference_not_match.zip

In short if I change the delay of messages the time don't match the difference.

In this example I have incresed the message delay of 20% (a short difference).

But the last massage was showed after 21 seconds vs original 6 seconds that is not the 20% that I have added.

I have compared with YOGEME the original numbers with modified numbers and YOGEME show the exact values, but the game pause don't match these values.

I suppose the cause is the some.

At the point do you suggest me to to copy all Tie Fighter original files and compare all to these missions and syncronize these settings and after do the some with xwing / xwing conversion ?

I suppose the value of original file is correct. So if is different automatically I can set the original value to these bad files.

Do you suggest me to do this ?

if yes what paramaters is better compare to original files and what is not necessary ?

[MikeG621]

That's working as intended, nothing wrong there. There's a 1-second delay from the mission start, so ignore that.

The "Delay" value is only seconds until 20, after that it's increasing by 5 seconds, not 1. So that's why message 5 now has a 40s delay instead of the 24 you're expecting. If you play with the value you'll see that a value of "21" will give you 25 seconds, which is pretty close.

On Sun, Feb 28, 2021 at 11:25 AM luca2125 notifications@github.com wrote:

Many Thanks Mike,

In the meantime I have found another hipotetic issue:

delay_difference_not_match.zip https://github.com/MikeG621/YOGEME/files/6057358/delay_difference_not_match.zip

In short if I change the delay of messages the time don't match the difference.

In this example I have incresed the message delay of 20% (a short difference).

But the last massage was showed after 21 seconds vs original 6 seconds that is not the 20% that I have added.

I have compared with YOGEME the original numbers with modified numbers and YOGEME show the exact values, but the game pause don't match these values.

I suppose the cause is the some.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-787487441, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5ETEIYCKBIMLIHK6OM3TBJ4BRANCNFSM4YK6VERQ .

[luca2125]

Ok, what you think about previous way to solve in my last response ? Do you suggest me to do what I have writed ?

[MikeG621]

I can't make sense of what you're asking again.

On Sun, Feb 28, 2021 at 11:42 AM luca2125 notifications@github.com wrote:

Ok, what you think about previous way to solve in my last response ? Do you suggest me to do what I have writed ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-787489898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5EUIJ2HXNQSU6Y3BERTTBJ57BANCNFSM4YK6VERQ .

[MikeG621]

So I tested the original mission you sent, the one you said works, but actually it doesn't. Without doing anything, there should only be 5 messages, but instead there's 10. When you did the save, yes all 16 would play, but what I'm seeing matches the behavior I would expect given what I know XWA itself is doing.

So even if I do exactly what XWA is doing, those converted missions are still bad and the messages aren't working properly.

On Sun, Feb 28, 2021 at 12:11 PM Michael Gaisser mjgaisser@gmail.com wrote:

I can't make sense of what you're asking again.

On Sun, Feb 28, 2021 at 11:42 AM luca2125 notifications@github.com wrote:

Ok, what you think about previous way to solve in my last response ? Do you suggest me to do what I have writed ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-787489898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5EUIJ2HXNQSU6Y3BERTTBJ57BANCNFSM4YK6VERQ .

[luca2125]

Thank Mike, this information is very useful.

For your opinion if possible update your MissionVerify to detect some anomalies like this ?

Is very common that some mission seem work but is wrong.

I already known that is impossible detect all type of anomalies, but a few more is always better.

I have other 150+ missions to save: xwc and xvt:

X-Wing Conversion 4.0 + XvT rebel part for X-Wing Alliance http://www.maxgames.it/xwc/

Can be very useful if I can use a batch verifier to check if there is the some situation to the other missions.

Thanks !

[MikeG621]

That's a good idea, I can certainly this type of broken Trigger detection to MissionVerify

On Tue, Mar 2, 2021 at 1:28 AM luca2125 notifications@github.com wrote:

Thank Mike, this information is very useful.

For your opinion if possible update your MissionVerify to detect some anomalies like this ?

Is very common that some mission seem work but is wrong.

I already known that is impossible detect all type of anomalies, but a few more is always better.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-788684507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5EUTB4H7PPPN6SASSOTTBSHTFANCNFSM4YK6VERQ .

[luca2125]

Thank you Mike !

I ask another favour if you can.

1b8m1xwc.zip

In this xwc mission after play correctly the briefing , after in the briefing summary show only one row.

This problem is present an all xwc 106 missions.

Actually is not clear why.

If you can add this control in your MissionVerify can be very usuful.

Thanks !

[RandomStarfighter]

Now that I know it's a bad mission file that's causing it, I could create a fix so YOGEME uses the XWA method of true/false in this specific case, but like I said this is not normal, and I'm not going to apply this everywhere due to the potential consequences. I don't even know if this "01 only" method is used everywhere, or just here.

Checking the game code, it does appear to be comparing a specific value of 1 for the "and/or" option. Checking in game (in this case XvT) confirms it. I haven't checked TIE, but it wouldn't surprise me if it was a persistent code quirk between the games.

In my XvT travels I've noticed many instances of things being compared to 1, instead of "true" always being nonzero. This would probably require a full audit of everything marked as BOOL in the file format specs. It looks like the FG Goal EnabledForTeam array might have similar problems. Some pieces of code check for zero, some for nonzero, and some for 1. This could be a mess. Perhaps the safest assumption is to stick with 0 and 1? It looks like C# already does this under the hood, so it's fine from YOGEME's perspective.

Now that the format specs are better understood, it might be better to convert missions again instead of relying on old conversions from outdated or obsolete software. At least for YOGEME we have the benefit of fixing bugs as we find them.

[MikeG621]

Under the hood, when writing .NET defaults to 0/1, yes. So really it's a special case of ensuring that the read process is making whatever corrections are necessary since the games handle 0/1 perfectly fine (special cases that use -1 aside, of course). I did ask Jeremy about this and he said XWA is really looking for "(value & 1) = true", so that makes it a little more confusing and seemingly random if there's bad data mixed in. Once I made that correction to YOGEME then the messages behavior matched up perfectly to what it was doing in-game. The mission itself still has to be fixed due to the bad data, but now YOGEME is at least interpreting it correctly and reflecting what XWA will do.

And I'll definitely have to take the time to go through everything and see how far this goes. So far I've only added this updated bool check to XWA and only for Trigger And/Or values, not across the board.

On Tue, Mar 2, 2021 at 7:30 PM RandomStarfighter notifications@github.com wrote:

Now that I know it's a bad mission file that's causing it, I could create a fix so YOGEME uses the XWA method of true/false in this specific case, but like I said this is not normal, and I'm not going to apply this everywhere due to the potential consequences. I don't even know if this "01 only" method is used everywhere, or just here.

Checking the game code, it does appear to be comparing a specific value of 1 for the "and/or" option. Checking in game (in this case XvT) confirms it. I haven't checked TIE, but it wouldn't surprise me if it was a persistent code quirk between the games.

In my XvT travels I've noticed many instances of things being compared to 1, instead of "true" always being nonzero. This would probably require a full audit of everything marked as BOOL in the file format specs. It looks like the FG Goal EnabledForTeam array might have similar problems. Some pieces of code check for zero, some for nonzero, and some for 1. This could be a mess. Perhaps the safest assumption is to stick with 0 and 1? It looks like C# already does this under the hood, so it's fine from YOGEME's perspective.

Now that the format specs are better understood, it might be better to convert missions again instead of relying on old conversions from outdated or obsolete software. At least for YOGEME we have the benefit of fixing bugs as we find them.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-789355455, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5EUSHVZ3CZVXXVWHTHTTBWGK3ANCNFSM4YK6VERQ .

[luca2125]

Many thanks RandomStarfighter / RandomStarfighter !!

I wating for the next update, in the meantime if only you can tell me why this mission:

1b8m1xwc.zip

Play correctly the mission briefing but the summary brifing show only one row.

After undersand this, I will apply the correction to all xwc missions if is easy to do.

Thanks !

[MikeG621]

Didn't have time to look at it last night after work but will get to it.

On Wed, Mar 3, 2021 at 1:56 AM luca2125 notifications@github.com wrote:

Many thanks RandomStarfighter / RandomStarfighter !!

I wating for the next update, in the meantime if only you can tell me why this mission:

1b8m1xwc.zip https://github.com/MikeG621/YOGEME/files/6074376/1b8m1xwc.zip

Play correctly the mission briefing but the summary brifing show only one row.

After undersand this, I will apply the correction to all xwc missions.

Thanks !

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-789517311, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5EQIMIUJAF5FU767J3LTBXTTJANCNFSM4YK6VERQ .

[luca2125]

thank you !

[MikeG621]

The problem with the briefing is that at each time that the Caption changes, there's a "Clear Text Tags" event before it that's supposed to be a "Page Break". Once those are fixed then it'll appear just fine.

On Wed, Mar 3, 2021 at 9:42 AM luca2125 notifications@github.com wrote:

thank you !

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MikeG621/YOGEME/issues/48#issuecomment-789808598, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHO5ERWGXZGMLMCEEOF7UDTBZKHHANCNFSM4YK6VERQ .

[MikeG621]

While waiting for YOGEME to be updated, you can download the latest Platform.dll (now v5.2) and place that in YOGEME's /bin/ directory to solve the AND/OR read behavior.

As that's the only actual problem to be reported in this issue, it's being closed.