[i]

Hello.
I've ran into a strange problem.
In a mods with "navpoints" usage (diaspora, aftermath, road to orumpur) their color turned black.
And i cannot edit their color via standart hud editor (F2 - HUD Config) - there isn't any nav points.
Could someone tell me, please, how could i change color for nav point mark?..
Attached a screenshot - highlighted selected nav point, its black on black and totally unusable .
Its being highlighted a little when i come closer to it, but still no use.

[Mobius]

I stumbled into this issue myself, this is due to the alpha value of navpoint colors being set to 0.

In my own WIP missions I set it to 255, thus solving the issue, but I'm wondering what causes it to be set to 0 retroactively in released campaigns.

[i]

I stumbled into this issue myself, this is due to the alpha value of navpoint colors being set to 0.

In my own WIP missions I set it to 255, thus solving the issue, but I'm wondering what causes it to be set to 0 retroactively in released campaigns.

Oh... oooooohhhhh shhhhh... so nav point color/alpha value coded into missions??? Really?..
Can it be adjusted by some hud gauge value, tbl setting, anywhere else?
May be some FSO guru could point to some deep buried string to edit?..

[Mobius]

Alright, so this is... weird. I've just checked related SEXPs in FRED and there are no specific options for navpoint alpha values, but the jump nodes have them so an alpha value of 0 will indeed make them invisible. A while ago however we had to deal with black navpoints in SR development (I've just checked our testing reports on the private Series Resurrecta board and the issue described over there is the same you're reporting in this very thread) and we solved that issue very quickly.

Are you using a recent FSO build? I'm asking that question because I believe something has happened to nav point management in the past few months and you may be using older builds which are somehow affected by this problem.

[i]

Oh, my
the mistery is solved
i'm using 22.2.0
switched to 22.0.0 and there it is - nav point clearly visible ).

[Mobius]

Glad to hear it.

As far as I know, recent Nightly builds aren't affected by this issue, either.

[Iain Baker]

Yup, I had this too.

[DefCynodont119]

I know exactly what's happening here, (I ran into this before)

So basically the code was changed some time ago so that Nav colors can be set in FRED, one of the "Features" of that change is that unset (default colors) are automatically set randomly (this often includes black as a possible color) (I think this is bad design myself but I have no say in the SCP)

You can get around this by creating an event for every nav point to set it's color, note that if the navpoint creating SEXP and Navpoint color change SEXP are in the same event, they will not work.

[EatThePath]

I know exactly what's happening here, (I ran into this before)

So basically the code was changed some time ago so that Nav colors can be set in FRED, one of the "Features" of that change is that unset (default colors) are automatically set randomly (this often includes black as a possible color) (I think this is bad design myself but I have no say in the SCP)

You can get around this by creating an event for every nav point to set it's color, note that if the navpoint creating SEXP and Navpoint color change SEXP are in the same event, they will not work.

Odds are a change like this is an unintended side effect that escaped the implementer and reviewer's notices, or failing that a poorly considered change that could be revised when highlighted. Looking at the code myself now, it looks more like the former.

Even if it were intended it's obviously unsuited for the multitude of old campaigns made with the old default colors and this is the kind of thing that ideally people would speak up about when they notice it so it can get fixed. That's practically the reason to have nightly builds, to try to catch stuff. You may not have "formal" say in the SCP, but your voice and input is still valuable(crucial, even) in letting us know what is needed and when we mis-step.

[Goober5000]

Yeah, pretty much what EatThePath said.

[Mobius]

You can get around this by creating an event for every nav point to set it's color, note that if the navpoint creating SEXP and Navpoint color change SEXP are in the same event, they will not work.

I have been using add-nav-waypoint and set-nav-color in the same event for quite a while now and they do work. If that's bad practice which may result into issues later on, I'll use chained events instead.

[mjn.mixael]

I know exactly what's happening here, (I ran into this before)

So basically the code was changed some time ago so that Nav colors can be set in FRED, one of the "Features" of that change is that unset (default colors) are automatically set randomly (this often includes black as a possible color) (I think this is bad design myself but I have no say in the SCP)

You can get around this by creating an event for every nav point to set it's color, note that if the navpoint creating SEXP and Navpoint color change SEXP are in the same event, they will not work.

Odds are a change like this is an unintended side effect that escaped the implementer and reviewer's notices, or failing that a poorly considered change that could be revised when highlighted. Looking at the code myself now, it looks more like the former.

Even if it were intended it's obviously unsuited for the multitude of old campaigns made with the old default colors and this is the kind of thing that ideally people would speak up about when they notice it so it can get fixed. That's practically the reason to have nightly builds, to try to catch stuff. You may not have "formal" say in the SCP, but your voice and input is still valuable(crucial, even) in letting us know what is needed and when we mis-step.

Eh except that when we ran into this issue in BtA2 in April we were told it's working as intended and to just implement the new sexps to fix it. It was a goober PR that caused it and as I recall he was not interested in reverting or fixing the mistake. So we implemented the new sexps instead and had to update BtA1 as well.

[Goober5000]

Eh except that when we ran into this issue in BtA2 in April we were told it's working as intended and to just implement the new sexps to fix it. It was a goober PR that caused it and as I recall he was not interested in reverting or fixing the mistake.

Where did this take place?  I searched the forums, Discord, and GitHub and found no such conversation.

[EatThePath]

I took a look back myself and only found this, with no evident followup conversation.


But I suspect it's unproductive to go much further down that rabbit hole. Where I'm at with this is, if someone does dig their heels in about this kind of thing they're wrong to do so, and I personally would beg you to file an issue or post a thread about it. Not to snipe or even to start a long protracted fight about it, just to make a clear, public and visible record of what's going on. If there is a pattern of that kind of bad decisions and stonewalling, unspoken 'oh that's just how it is and everyone knows it' only helps the rut get deeper.

Er, anyway. There's a patch in review now that ought to fix this particular issue, at least. Yay.

[mjn.mixael]

I, and others such as battuta, used to make quite the fuss about this sort of code-caused mod rot for older mods. The solution that SCP rallied around at the time was "don't use new builds for old mods" or what I'd call a collective shrug and an "oh well".

That's why I remember this so clearly because it was one of the first times I just let it go. If SCP is now saying things like this can and should be fixed, that's the kind of about-face I can get behind. I'm glad there's a PR in.

[EatThePath]

Well, all opinions above are my own and not official scp positions, my own capacity to argue against bad changes is obviously finite, and not everything is going to be as happily resolved as this one, but I certainly can't push for fixes to problems I don't know exist. Every time I see someone mention they've been just working around a bug or fundamental flaw for months or years(something that I've seen steadily the whole time I've been in the community) it kills me inside a little.

I, and others such as battuta, used to make quite the fuss about this sort of code-caused mod rot for older mods. The solution that SCP rallied around at the time was "don't use new builds for old mods" or what I'd call a collective shrug and an "oh well".

I recall the rallying you're talking about pretty well. I had a lot of thoughts at the time about SCP-modder dynamics that I almost posted, this being back before they stuck a badge to me, but I held them because tempers were very hot and I still felt a lot like a newcomer and outsider. Maybe I'll make that thread soon after all, though the badge makes it a bit more awkward.

[Asteroth]

The solution that SCP rallied around at the time was "don't use new builds for old mods"

If SCP is now saying things like this can and should be fixed...

For what it's worth, these are both true. Mods no longer under active development being forced to use builds they weren't tested on practically guarantees bugs, especially the larger and more complex the mod is. Nevertheless, these situations are a great way to expose bugs so we can fix them! Backwards compatibility as a principle is not something I'm aware we have budged on, except in perhaps extreme circumstances.

[mjn.mixael]

I really don't want to get into this further but it seems like you're just saying whatever's convenient at the time. In that thread a while back about BP's (a mod that has spurts of active development) compatibility issues you literally told battuta to use an old build and not a new one.

If SCP wants to have a policy then have one and stick with it. Or don't have one and stick with that. Whatever this is, it's worse. This kind of everyman response means us modders don't know what answer to expect.

[Asteroth]

Again, to be clear, regardless of whatever build you do or do not use backwards compatibility is something we, in general, try to guarantee, and such breakages are bugs which we try to fix. As far as 'SCP Policy' goes that hasn't changed.

In that thread, I didn't entirely understand the situation he was in, and I recognize now simply sticking to an old build is probably not a workable solution. Mods under active development almost always needs to be on recent builds, as they typically request and then rely on new features. Unfortunately, especially in the case of large mods with multiple campaigns developed over many years like BtA or BP, this can 'drag' older campaigns or missions which used to work under the purview of new builds and break them. While this is a great way to discover bugs to fix, it's understandably frustrating for the modder. Mods like these simply have a large 'attack surface', they are complex, rely on many different features, and there's a lot of content, all of which adds up to a high likelihood that something gets broken along the way. There's no real fundamental solution to this I know of, as long as new features are added the risk of new bugs is ever-present.

In any case, the SCP's 'answer' to any bug or breakage of backwards compatibility is the same: a bugfix. (Exempting some extreme circumstances, I'm sure there have been or will be extraordinary scenarios I haven't thought of where the bug was simply too hard to fix, or the breakage was worth it or something)