Hooray!

Cryptic. Thought that was a greeting...

Like I said, most of the reported things aren't issues at all, just a difference that I noticed.

Oh yes, this is good to see fixed too. What I meant, that sometimes error message still report at line 0, is it intended to work like that?

Not an issue.

Okay, there are "At least" and "At most" that doesn't have the second word capitalized. Also "ore", "gas", "ore and gas" aren't capitilized to the same basket. There is a little bit of capitalization inconsistency with classic trigedit. But meh I'm such a paranoic . All this is minor.

Actually I just figured out this is an issue. If there is a character "·" in string it is compiled properly, but then decompiled as "\xfff" which recompiles into something different "ÿ".

Cool! I tried to put this type of comment in various places, worked for me yet.

Yes, it's in trigedit for years literarly. I had hard times to figure out the logic behind that and implement it into my color scheme for vim SCMD triggers highlighting. I don't even remember all peculiarities anymore. But hey, it's ridiculous to keep such things. I bet no one had a meaningful use of this bug, except probably for malicious intents? to overflow buffers and cause the crash or something worse? Gone for the better.

That's how I tried to break it at first place! The gotcha is a semicolon also disables the action/conditon, so double semicolon at end of the line might be a surprise. Maybe treat a semicolon as a disabling marker only if it is the first non-blank (space, tab, etc.) character on the line? But then one can't put series of disabled triggers in one line . Someone shoot me , this is so minor again.

Post has been edited 4 time(s), last time on Jul 14 2019, 9:16 am by Wormer.

Error Messages: There used to just be 1 line counter "current line" while parsing. The new engine no longer updates that, so a few low level error messages appear to be line 0. Since it now displays an error for the broken trigger, then action, then param, it shouldn't be a big deal until I fix it.

Special chars: I think I know what is going on - it is treating the chars as signed when testing if it is a color code or not. Is a simple fix, and will be included in tonight's version.

Logic for that bug was anything that didn't utterly fail parsing to number but was invalid turned into 0, which means the resulting string had an embedded end of string marker and was truncated early. No buffer overflow though.


Using semicolon for two things was a bad design decision, but we are stuck with that for backwards compatibility

Post has been edited 1 time(s), last time on Jul 14 2019, 9:10 pm by Suicidal Insanity.

And a new build is up, once again !

Found a bug, or... don't know how to qualify that.

Make a name for a force "Player 1" then make a trigger for that force in classic trigedit, then recompile in text trigedit and! see how trigger changes owner to player 1.

That way, there is a number of forbidden names for forces: "Player 1" through "Player 12", "Foes", "Allies", "Non Allied Victory Players", "Current Player", "Neutral Players", "All Players", "unknown/unused", and "unknown/unused (22)" through "unknown/unused (25)".

The ultimate fix for this kind of situation is to also accept integer values for owners. ADDED: and if conflict with those names is detected, decompile conflicting trigger forces as numbers when populating text triggers.

Post has been edited 3 time(s), last time on Jul 16 2019, 9:43 pm by Wormer.

Ya, text trigedit doesn't protect the user from himself if he tries to break things. I've slowly been adding some checks - but I mostly assume if the user uses text trigedit he knows what he is doing.

The most surprising of these all are probably "Neutral Players" and "Foes"/"Allies". I can imagine forces with those names.

Also, if you make a location with name "Anywhere" it will gobble all *real* Anywhere locations on recompile.

Gladly units use their original names.

Stuff I noticed now after upgrading to the latest build (which fixed the bug with the TRANSMISSION briefing action I was about to report):

Now the SWITCH condition lists the states from SET SWITCH action instead, and they don't seem to work in-game.

UPD: Screenshots attached.

Attachments:

Will fix once I am home.

Thanks. I found a quick workaround, so it's not like my mapping binge that I'm suffering(?) today will be harmed.

Build is up with fix for switch conditions, and with text trigger editing in classic trigedit. Give it a try, give me feedback.

Poke?

Sorry, was asleep.
Everything works so far, thank you (except is the CR not supposed to work in Text View mode? Copying and pasting works though). I'm not sure I would use text trigger editor much, although (say) copying and pasting actions between triggers is an application I could find use for. Actually I was about to wonder if copy/paste was going to be in the pipeline, though now I guess it's less of an issue.

One more thing: I know the "Always Display" debate rages on but I think it's still worthwhile to have this switch set by default. The reasoning is as follows: unsetting "Always Display" is only useful (if you can call it that) for transmissions in campaigns with full voice acting but somehow I think they're few and far between, especially now.

P.S. A cosmetic bug to report - it was there before and is there now. Sometimes weird characters (including Chinese hieroplyphs) are seen in the trigger list when looking at a trigger with a lengthy comment. Click on it and they go away and may be replaced with something else (but equally nonsensical).

Attachments:

Post has been edited 3 time(s), last time on Jul 18 2019, 11:02 am by IlyaSnopchenko.

If you can send me a map with just a handful of triggers that causes that corruption, I'll take a look.

Always Display: Any other opinions on changing the default value?

No, no, the corruption is purely visual. Nothing is/was done to the trigger itself. It appears rather randomly, and only if there's a trigger with the comment so long that it exceeds the 7 line mark and wraps into (MORE). I know it's a rare occurence and here's another example.

Attachments:

I understand it is purely visible, I just didn't want to have to create a test map to repro it, especially if it may be dependent on the exact text of the comment.

Yes, Always Display should be set by default. Unless you can tie this to a profile setting, in which case that's better.

Not a big deal, but I'm standing for Always Display default as well.

There might be cases when someone switched that in-game setting off and forgot about it, and now cracks his head against the wall why the display text action isn't working.

Most of the time you want the text display always. Aside of classic design to support sound transmissions, the limited cases when you want to hide text are turning around some kind of map hints for new players, or a supplementary info that isn't important and can be hidden by players on their will, notification messages that player might or might not want to see, etc.

Actually it doesn't seem to depend on anything. Just adding multi-line comment does the trick. Here's the map I started from scratch for, like, 5 seconds. 13 lines of text - and I got this stuff too.

It does not need to be a high priority fix as it doesn't affect the actual editing/map in any way.

Attachments:

Ya but now that the text integration is there, I don't want to make any major changes, just improve error logging of that panel and other bugfixes for the next three days then a release. So that is a good candidate for something to be fixed.

Ya but now that the text integration is there, I don't want to make any major changes, just improve error logging of that panel and other bugfixes for the next three days then a release. So that is a good candidate for something to be fixed.