[Topgun]

can we name shield generators whatever we want? I mean use that shield gen subsystem but name it... let's say... astrotech droid?

[Snail]

You can name it anything as long as it has the word "shield" in it.

(being serious despite the smiley)

[akenbosch]

so "SOOPA DOOPA DEKER KICKING shield" would work?

[chief1983]

Was that code committed, and if so, to what branch, and when?

[Goober5000]

Unstable (HEAD) branch, in February or thereabouts.  It's not in stable yet because it breaks pilot files.

[WMCoolmon]

I feel like I'm going to get *****ed at for being negative, but having functionality be controlled by player-visible metadata (which could very well be a plot aspect) seems like a really poor design method. Is there some way of easily changing the visible subsystem names where they're visible to the player? I remember implementing something like that for turrets, probably via a SEXP or something, but I don't remember if it got in CVS or the stable branch, or if I even committed it at all.

[Nuke]

with a physical subsystem you have the option of using the $name field for player visible discription. you could set it to monkeyproofing and thats what the player would see, even though its subsystem name is $shield. ive used this field to hide script readable mod data by placing 1 or 2 character codes adter the masking character # (same as used in things like cyclops#short). for example using $name: Laser Turret#pt, where the pt indicates to script to tell lua to enable player operation for that turret.

anyway is it possible to use the masking character on a non-physical subsystem name so you could use "$astrotech droid#shield" in the name field of the special point, so th player can only see astrotech droid. that might actually work.

[jr2]

Ummm... *whack*  astromech.  Am I right?

[Goober5000]

I feel like I'm going to get *****ed at for being negative, but having functionality be controlled by player-visible metadata (which could very well be a plot aspect) seems like a really poor design method.

It seems to me like an appropriate decision.  What else are communication, navigation, sensors, engines, and weapons going to be than communication, navigation, sensors, engines, and weapons subsystems?  Otherwise you'd have the redundant arrangement where an engine subsystem is required to carry the "engine" subsystem flag, etc. etc.  I think the simpler method is far better.

The alternate name feature is an appropriate way to handle the extremely rare cases where you'd need a different name.  I don't know if your feature ever got into CVS -- probably not, because karajorma did something similar recently.

[akenbosch]

$Subsytem alt name:

change-subsytem-name SEXP

and it went into the stable branch too ^_^

[karajorma]

No it didn't. I added the feature to my codebase but then noticed that it suffered from the same stumbling block that a SEXP to change ship names mid-game would, i.e that the log would be buggered. The result was that I backburnered the idea for a bit while I had a think about what to do about it.

To be honest I've never been a huge fan of using the log as a method of determining which ships are destroyed or departed in the first place. This info should really be coming from Ships_exited[] as then you could use the log for what it's really for (writing information for the player) rather than having it double up as a method of keeping track of game data too. And you could add SEXPs to allow you to write fake log entries without worrying about it buggering up the game.
 
Of course the changes required to do all this are fairly substantial which means I'm going to have to come up with another way to deal with the log, drop the feature completely, have it write the wrong name to the log or bite the bullet and change over to Ships_exited.

[akenbosch]

actualy, some campaings rely on the log, and so do mutli players. its used so you can tell if,say, in drums of war 2, if a jester bot arrives. and in multi, its used to see who got the kill on a particularly large ship. perhaps th game could use a second invisible log to keep track of names, goals, departures, arrivals, and destructions, while the player sees a log that only shows arrivals, goals, departures, destructions, and not name-changes.

[karajorma]

I'm well aware that people use the log thankyousoverymuch.

[WMCoolmon]

I feel like I'm going to get *****ed at for being negative, but having functionality be controlled by player-visible metadata (which could very well be a plot aspect) seems like a really poor design method.

It seems to me like an appropriate decision.  What else are communication, navigation, sensors, engines, and weapons going to be than communication, navigation, sensors, engines, and weapons subsystems?  Otherwise you'd have the redundant arrangement where an engine subsystem is required to carry the "engine" subsystem flag, etc. etc.  I think the simpler method is far better.

The alternate name feature is an appropriate way to handle the extremely rare cases where you'd need a different name.  I don't know if your feature ever got into CVS -- probably not, because karajorma did something similar recently.

"Communication Disruptor", "Navigation deflector", "Radiation sensors", "Backup engines", "Weapons cache" and "Heat shield" all feature one of those keywords but mean something quite different from what FS2_Open would assume. Plus, what if you wanted to have "Comms", "Telemetry", "Scanners", "Stardrive", "Defenses", and "Force field"? Or maybe "astromech droid"? Or some completely alien names? ("Gal'frush" for shield generators)

Suddenly the naming convention doesn't work at all. The only thing that using keywords does is force campaign makers to standardize their names, making things look that much less interesting and creative (and for TCs using another universe, such as a Star Wars mod, possibly breaking canon).

So, no, to me it doesn't seem more appropriate at all. Just easier to do (as long as you know the right name for the thing you're trying to name, and whether it's plural or singular, and how to spell it properly, and you don't make a typo in the process.)

[Nuke]

you could just enable the use of the # character and allow shortened versions of the subsystem names, like nav or com. so you could do $Radio#com, you can see radio, but internally the engine knows thats its really a com subsystem. you can do this with physical subs, but not special points. i think the functionality of # should go both ways. seems like basic stringmanip to me.

people do realize that you can do custom subsystem behavior with scripting, right?

[Wanderer]

Main point in the naming issue is AFAIK with the turrets which get the name directly according to their weapon loadout. So lets take WCS for example.. Almost all turrets are tagged as 'laser turrets' regardless of their actual firepower so for example mission 'take out Fraltha's main guns' is a tad more difficult than what it sounds as you have no way of knowing which of all the turrets are the main turrets. In SW mod you cant target 'turbolaser batteries' or 'ion cannons' etc. etc. ad infinitum

In standard FS2 setup this is not an issue, as laser turrets are harmless bomb killers, beam turrets are always the only dangerous ones, missile launchers aren't even worth a mention and flak guns are just an annoyance... But in mods a system for naming the subsystems would be extremely useful.

And - finally - if turrets (ie. certain subsystems) would gain option for tagging them so why couldn't all the subsystems have the same option?


EDIT: Of course their names can be set via scripts run in every single mission but that is somewhat laborous. Just tested it and named all the turrets as 'boomsticks' . But form what i quickly tested for example FREDed changes do no change appearance ingame... That is I switched all when accessed via script it appeared as 'laser turret' (ie. exactly as defined in pof) regardless of weapons and i could overwrite the existing turret (one given by game engine) name with the original one (from pof)..

EDIT2: correction into the above...

[Nuke]

i didnt know that, i thought it always used the $name: field from subsystem properties. ive looked at it again and it seems youre right. its probibly a throwback to fs1. rather than changing the name fields, they just hacked in the engine to determine what weapon was used and name the gun accordingly. perhaps an optional display name field in the table?

[Wanderer]

Well... downside is that my system has exactly same issue as with Kara's system.. the log. And besides any hardcoded system ought to be preferred over scripted versions.

[karajorma]

i didnt know that, i thought it always used the $name: field from subsystem properties. ive looked at it again and it seems youre right. its probibly a throwback to fs1. rather than changing the name fields, they just hacked in the engine to determine what weapon was used and name the gun accordingly. perhaps an optional display name field in the table?

It is indeed hardcoded in.

The change I made was to add a $Subsytem alt name setting to all subsystems. That allows you to name the subsystem whatever you want. For instance



The problem is the the log. The log will still call the subsystem by its original name, not the alt name. If I change this behaviour various SEXPs will fail as they check the log to see if a subsystem was destroyed.

That said after a chat with Wanderer I think I'm going to commit what I have now anyway. It's still useful in-game even if the log is writing the wrong info.

[Mobius]

The change I made was to add a $Subsytem alt name setting to all subsystems. That allows you to name the subsystem whatever you want.

That's what we want because names like "BFGreen" aren't actually supposed to appear ingame.