The Star Citizen Thread v5

[ianw]

If they get this upset about the radar being under par, how will they react the theoretically possible MVP in all it's woefully shoddy glory.

What I find most remarkable is that some of the people that shout down concerns for other things like pants in space - fake airlock mechanism - have chosen the golf thing to take a stand on.


For some reason they choose to see pants and airlock as "placeholders" but can't do the same with the golf swing thing.


Maybe they worry the golf thing is deliberately dumbed down quick and easy design - rather than something in progress - and it's a sign of things to come.

 

[Stigbob]

I don't think the press <<9 iron>> to scan thing is in itself the problem.

Normal backers can't raise concerns without being down voted off reddit or banned from RSI's forum. Suddenly lots of people agree that this radar thing is bad, and are saying so. All the backers who think (perfectly reasonably) that a few too many dates have been missed, lots has gone wrong and are starting to question the wisdom of their expensive in game ship suddenly have a topic where they pretty much all agree it's not good enough.

The outcry over something very minor is exaggerated because it's possibly the first time there's been an outcry that wasn't immediately silenced by RSI's mods the cult and paid online reputation management companies.

Normal backers have doubts they are not allowed to express this one's safe for them to speak about and it's attracting attention.

 

[Cmdr Eagleboy]

I don't think the press <<9 iron>> to scan thing is in itself the problem.

Normal backers can't raise concerns without being down voted off reddit or banned from RSI's forum. Suddenly lots of people agree that this radar thing is bad, and are saying so. All the backers who think (perfectly reasonably) that a few too many dates have been missed, lots has gone wrong and are starting to question the wisdom of their expensive in game ship suddenly have a topic where they pretty much all agree it's not good enough.

The outcry over something very minor is exaggerated because it's possibly the first time there's been an outcry that wasn't immediately silenced by RSI's mods the cult and paid online reputation management companies.

Normal backers have doubts they are not allowed to express this one's safe for them to speak about and it's attracting attention.

They sacrificed their rights to speak for "ultimate mega game". Now they understand that it is just a game and developers give zero damn about their imagination.

 

[dsmart]

LOL, good luck with that and the way ships move in SC!

I'm just going to interrupt our regularly scheduled SC bashing and just say it:

It's much ado about nothing.

Excerpt from what I posted earlier today on my forum.

As a systems designer and someone who has developed some of the most complex (go play any of my Battlecruiser/Universal Combat games if you think this is hyperbole) systems in a space combat sim, I quite like how they implemented it. It looks cool, straightforward and functionally sound. Plus (and this is a biggie), they unified it across the infantry and ships. I did the same thing in my BC/UC games, whereby even the NPC infantry characters, have some sort of radar system which not only detects sounds, but also prioritized based on range and elevation.

What's lost in the translation I think, is how the dev described it. But the fact of the matter is that he described it correctly for the layman to understand how it works. On the face of it, the system is no different from any other implementation of a "power up" mechanic in hundreds of games. So this outrage is completely misplaced I think. Plus, he also stated that it's a first iteration, and that LA is going to be running with it. Which means that they are going to be tweaking and fine tuning it along the way.

The issue that I have with this system is that unless you're going to be doing this "scanning" while stationery or moving at low speed, it's going to be quite cumbersome to use - if you're the pilot. Using a mechanic such as this, whereby the player needs to provide constant input, is counter-intuitive and misplaced in a game like this. Heck, even the most hardcore air combat sims don't do it like this. I think it should be implemented as a fire-and-forget type system, but with simple key presses to activate whatever modes (e.g. ACTIVE vs PASSIVE) they want. Then all the benefits and restrictions are embedded within those modes.

In games of this type, the operation of a radar system is usually automated (it's not like this is a realistic air combat game which requires accuracy and fidelity). You plot the targets, give the radar a range, give the player a way to select targets etc. You can also differentiate the radar op based on range, elevation, altitude (if on planet surface), target cross-section size, op mode etc. You can literally go crazy with it.

If they wanted to implement this as a "skill" (which is precisely what I think they're going for) based op for multi-crew ships in which one player is going to be using this; then this is probably the way to do it. It's not like the pilot is going to be doing any of this; in much the same way that a turret gunner isn't expected to fly a multi-crew ship.

But here's the problem which all multiplayer games which require player cooperation, run into: who the frack wants to be sat there, in a chair, ing around with a game mechanic which, for all intent and purposes, doesn't provide the same instant gratification and satisfaction as any other game mechanic. I don't care what some of these guys keep dreaming up, even as they theory craft their way through a litany of pure and utter (which not even Chris Roberts has promised they could do in the game); when it comes down to it, most of them won't want to be that guy. In games which require player co-operation, there is always "fun" stuff for all players to use. e.g. a medic, a tank etc. In a game like this, there is nothing fun about a skill based radar system, no matter how it's implemented. Again, this is all assuming they are targeting this as a skill based system. If they aren't, then this point is moot.

At the end of the day, it's all down to user experience. If they keep it this way, in which it's a timed "progress bar" type system which requires constant input (among other things), instead of just a fire-and-forget key input (which can also have the progress bar as it powers up and activates), it will be a complete disaster. And then they will have to do what they always do: go back in, rip it all out, or nerf it. Time wasted.

My suggestion would be to keep everything as-is, but instead of the constant "golf swing" input, simply make it a fire-and-forget mode change input. e.g. passive is the default, then you press a key, and it switches to active, which then initiates the same progress bar. Then, it could be that once the player (pilot or other) switches modes, the pilot would have to keep the ship pointed at the target in order for the progress bar scan to complete quickly. Doing it this way also allows the player to operate the radar system, even without a co-op player. And in the event of a co-op player, perhaps the ability to select multiple targets based on priority (which the pilot may not be aware of; especially in a combat situation), is the add-on benefit. The other benefit to this is that it would work in all ship types, since it gives the pilot autonomy, but at a cost.

FYI, I don't believe this is a QTE (QuickTime Event) they are showing as the progress bar. It just looks like a Flash based UI (probably using Scaleform or similar; we use Iggy in LoD) animation.

Additional reading:

The radar system in my BC/UC games is quite complex under the hood, and I did my best to not expose too much of that to the user. Read how it works on p27 of the UCCE 3.0 game docs or read the excerpt below.

Spoiler

3.6 Tactical Radar Scanner (TRS)


This system is the center of your weapons and radar systems and its primary function is to track targets in all environments. Select one of its tabs to put it command mode or use the T key.

The TRS has several operating modes depending on the craft and the environment


SPC : Tracks space borne targets when in space
GND : Tracks ground targets when on planets
AIR : Tracks airborne targets when on planets
SUL : The Support Unit Locator mode filters out all targets except those of your
support crafts and personnel. These are color coded as follows:


Blue : Command Craft
Yellow : Shuttle
Cyan : Fighter
Green : Ground Unit
Red : Personnel
White : Probe
Grey : Mining Drone


When activated, two circles are displayed with one smaller than the other. These circles are used to track all targets in relation to your ship. Any target within the inner circle is in front of your ship's bearing. If the target is in the outer circle, it is behind your ship. The very center of the inner circle represents what is directly in front of your ship. Therefore, if a target is in the inner area you are directly facing it.


It is important to note there may be times when all targets in your region are not picked up by the TRS due to its limited range.


Targets in the display are color coded as follows, depending on the environment:


Blue : Neutral
Yellow : FATAL assigned
Cyan : Towed
Green : Friendly
Red : Enemy
White : Missile or Mine
Grey : Disabled


To select and cycle targets, use the . and , keys or move the mouse into the display and then click on the desired target. If the mouse is over more than one target, the target info is stacked and the current target is displayed with a flashing > marker.

Each click of the mouse will then cycle to the next target and the marker will move to that target (if any) in the cluster. You can also select a target from a menu list by clicking on one of the mode tabs (e.g. SPC) and using the Select Target menu.


Once a target is selected, the TTD (see section 3.3) will appear in the TDD if it is within the craft's field of view and will continue to move with the target. The target's range (km), closure (m/s) and acceleration rates (m/s) are displayed in the top left/right and lower right corners of the TRS.


Use the I command to view a target in the VID mode of the VDD. To cancel the current target, press the X key.


To switch to Single Target Tracking (STT) mode which filters out all targets except for the current one, use the \ key.


RADAR MODES


There are three radar modes and which also affect some of the NID and TACOPS operating modes. These modes can be toggled using the R key.


In ALERT mode (default) the radar tracks up to limits of the current space region and up to 250km when on a planet. The target info for all targets are displayed in the ITD but only the current target (if any) has all the information about the target. The other TTDs show only the target name and range.


In this mode, the TTDs are referred to as VTT (Visual Target Tracking) designators because they are always on (the object does not need to be targeted first) when you are within a certain range of a target. In first person mode, the VTT is always on, regardless of the DIE (see section 8) radar mode.


The VTT range varies depending on whether you are in space or on a planet and whether you are in first person mode or in a craft. The min/max ranges:


PLANET: SPACE:


Crafts 25m / 50km 1m / 150km
Personnel 1m / 100m 1m / 1km


In ACTIVE mode, the radar operates the same as ALERT mode, but only the TTD (with full information about the target) for the currently selected target is displayed in the ITD.


In PASSIVE mode, the radar ranging circles in the TRS go off and the ship detects objects based on a rotating antenna model. If you are on a planet, a Green line (you must zoom the map to see this) in the NID rotates about your craft's position, detecting any objects that the line passes over. This is like a conventional radar system. No energy is emitted from your craft as it is assumed that the objects are detected due to their thermal, EM or other property. This allows your craft to detect objects without exposing its position.


A limitation of passive mode is that, on a planet, the effective range is reduced to 5km, except when an object is using radar, in which case it can be detected up to 250km away. NPC units frequently use active radar.
Try sneaking up on one, and there is a very good chance that you're going to get pinged.


A missile cannot lock if the radar is in passive mode.


A radar enabled unit cannot achieve active ping if the target is outside of its min/max acquisition parameters. Just because an active ping is achieved, does not mean that the target has a lock solution. It could have a long radar range and still not have a missile that can launch within those parameters.


For example, a SAM unit with a max radar distance range of 100km and a radar min/max altitude range of 500ft/5000ft, cannot see a target that is more than 100km away. Once the target falls within its radar distance range, the target altitude is then taken into account. For example, if the target is at 80km distance at an altitude between 500ft and 5000ft, the SAM can see it. If the target then drops below 500ft or pops above 5000ft, the SAM will lose its tracking after a few seconds.


Note that all air, space and ground units have different radar detection characteristics. When in doubt, check the appendix data files.

You can use the Track Warning Indicator, TWI, to determine whether or not a selected ground threat can see you on radar or not.


Note that NID targets are not subject to the TRS radar target filters and if the TRS is in ground mode, then radar type objects are also visible in the NID.


LAUNCH WARNING INDICATORS (LWI)


These indicators are located to the lower left corner of the TRS display and provide critical threat assessment info.


TRK : Your craft is being tracked and scanned on radar
LCK : A hostile target has a valid weapons lock and launch solution on your craft.
LNH : A weapon has been launched at your ship and it has an active lock

 

[Stigbob]

Spoiler

I'm just going to interrupt our regularly scheduled SC bashing and just say it:

It's much ado about nothing.

As a systems designer and someone who has developed some of the most complex (go play any of my Battlecruiser/Universal Combat games if you think this is hyperbole) systems in a space combat sim, I quite like how they implemented it. It looks cool, straightforward and functionally sound. Plus (and this is a biggie), they unified it across the infantry and ships. I did the same thing in my BC/UC games, whereby even the NPC infantry characters, have some sort of radar system which not only detects sounds, but also prioritized based on range and elevation.

What's lost in the translation I think, is how the dev described it. But the fact of the matter is that he described it correctly for the layman to understand how it works. On the face of it, the system is no different from any other implementation of a "power up" mechanic in hundreds of games. So this outrage is completely misplaced I think. Plus, he also stated that it's a first iteration, and that LA is going to be running with it. Which means that they are going to be tweaking and fine tuning it along the way.

The issue that I have with this system is that unless you're going to be doing this "scanning" while stationery or moving at low speed, it's going to be quite cumbersome to use - if you're the pilot. Using a mechanic such as this, whereby the player needs to provide constant input, is counter-intuitive and misplaced in a game like this. Heck, even the most hardcore air combat sims don't do it like this. I think it should be implemented as a fire-and-forget type system, but with simple key presses to activate whatever modes (e.g. ACTIVE vs PASSIVE) they want. Then all the benefits and restrictions are embedded within those modes.

In games of this type, the operation of a radar system is usually automated (it's not like this is a realistic air combat game which requires accuracy and fidelity). You plot the targets, give the radar a range, give the player a way to select targets etc. You can also differentiate the radar op based on range, elevation, altitude (if on planet surface), target cross-section size, op mode etc. You can literally go crazy with it.

If they wanted to implement this as a "skill" (which is precisely what I think they're going for) based op for multi-crew ships in which one player is going to be using this; then this is probably the way to do it. It's not like the pilot is going to be doing any of this; in much the same way that a turret gunner isn't expected to fly a multi-crew ship.

But here's the problem which all multiplayer games which require player cooperation, run into: who the frack wants to be sat there, in a chair, ing around with a game mechanic which, for all intent and purposes, doesn't provide the same instant gratification and satisfaction as any other game mechanic. I don't care what some of these guys keep dreaming up, even as they theory craft their way through a litany of pure and utter (which not even Chris Roberts has promised they could do in the game); when it comes down to it, most of them won't want to be that guy. In games which require player co-operation, there is always "fun" stuff for all players to use. e.g. a medic, a tank etc. In a game like this, there is nothing fun about a skill based radar system, no matter how it's implemented. Again, this is all assuming they are targeting this as a skill based system. If they aren't, then this point is moot.

At the end of the day, it's all down to user experience. If they keep it this way, in which it's a timed "progress bar" type system which requires constant input (among other things), instead of just a fire-and-forget key input (which can also have the progress bar as it powers up and activates), it will be a complete disaster. And then they will have to do what they always do: go back in, rip it all out, or nerf it. Time wasted.

My suggestion would be to keep everything as-is, but instead of the constant "golf swing" input, simply make it a fire-and-forget mode change input. e.g. passive is the default, then you press a key, and it switches to active, which then initiates the same progress bar. Then, it could be that once the player (pilot or other) switches modes, the pilot would have to keep the ship pointed at the target in order for the progress bar scan to complete quickly. Doing it this way also allows the player to operate the radar system, even without a co-op player. And in the event of a co-op player, perhaps the ability to select multiple targets based on priority (which the pilot may not be aware of; especially in a combat situation), is the add-on benefit. The other benefit to this is that it would work in all ship types, since it gives the pilot autonomy, but at a cost.

FYI, I don't believe this is a QTE (QuickTime Event) they are showing as the progress bar. It just looks like a Flash based UI (probably using Scaleform or similar; we use Iggy in LoD) animation.

Additional reading:

The radar system in my BC/UC games is quite complex under the hood, and I did my best to not expose too much of that to the user. Read how it works on p27 of the UCCE 3.0 game docs or read the excerpt below.

Spoiler

3.6 Tactical Radar Scanner (TRS)


This system is the center of your weapons and radar systems and its primary function is to track targets in all environments. Select one of its tabs to put it command mode or use the T key.

The TRS has several operating modes depending on the craft and the environment


SPC : Tracks space borne targets when in space
GND : Tracks ground targets when on planets
AIR : Tracks airborne targets when on planets
SUL : The Support Unit Locator mode filters out all targets except those of your
support crafts and personnel. These are color coded as follows:


Blue : Command Craft
Yellow : Shuttle
Cyan : Fighter
Green : Ground Unit
Red : Personnel
White : Probe
Grey : Mining Drone


When activated, two circles are displayed with one smaller than the other. These circles are used to track all targets in relation to your ship. Any target within the inner circle is in front of your ship's bearing. If the target is in the outer circle, it is behind your ship. The very center of the inner circle represents what is directly in front of your ship. Therefore, if a target is in the inner area you are directly facing it.


It is important to note there may be times when all targets in your region are not picked up by the TRS due to its limited range.


Targets in the display are color coded as follows, depending on the environment:


Blue : Neutral
Yellow : FATAL assigned
Cyan : Towed
Green : Friendly
Red : Enemy
White : Missile or Mine
Grey : Disabled


To select and cycle targets, use the . and , keys or move the mouse into the display and then click on the desired target. If the mouse is over more than one target, the target info is stacked and the current target is displayed with a flashing > marker.

Each click of the mouse will then cycle to the next target and the marker will move to that target (if any) in the cluster. You can also select a target from a menu list by clicking on one of the mode tabs (e.g. SPC) and using the Select Target menu.


Once a target is selected, the TTD (see section 3.3) will appear in the TDD if it is within the craft's field of view and will continue to move with the target. The target's range (km), closure (m/s) and acceleration rates (m/s) are displayed in the top left/right and lower right corners of the TRS.


Use the I command to view a target in the VID mode of the VDD. To cancel the current target, press the X key.


To switch to Single Target Tracking (STT) mode which filters out all targets except for the current one, use the \ key.


RADAR MODES


There are three radar modes and which also affect some of the NID and TACOPS operating modes. These modes can be toggled using the R key.


In ALERT mode (default) the radar tracks up to limits of the current space region and up to 250km when on a planet. The target info for all targets are displayed in the ITD but only the current target (if any) has all the information about the target. The other TTDs show only the target name and range.


In this mode, the TTDs are referred to as VTT (Visual Target Tracking) designators because they are always on (the object does not need to be targeted first) when you are within a certain range of a target. In first person mode, the VTT is always on, regardless of the DIE (see section 8) radar mode.


The VTT range varies depending on whether you are in space or on a planet and whether you are in first person mode or in a craft. The min/max ranges:


PLANET: SPACE:


Crafts 25m / 50km 1m / 150km
Personnel 1m / 100m 1m / 1km


In ACTIVE mode, the radar operates the same as ALERT mode, but only the TTD (with full information about the target) for the currently selected target is displayed in the ITD.


In PASSIVE mode, the radar ranging circles in the TRS go off and the ship detects objects based on a rotating antenna model. If you are on a planet, a Green line (you must zoom the map to see this) in the NID rotates about your craft's position, detecting any objects that the line passes over. This is like a conventional radar system. No energy is emitted from your craft as it is assumed that the objects are detected due to their thermal, EM or other property. This allows your craft to detect objects without exposing its position.


A limitation of passive mode is that, on a planet, the effective range is reduced to 5km, except when an object is using radar, in which case it can be detected up to 250km away. NPC units frequently use active radar.
Try sneaking up on one, and there is a very good chance that you're going to get pinged.


A missile cannot lock if the radar is in passive mode.


A radar enabled unit cannot achieve active ping if the target is outside of its min/max acquisition parameters. Just because an active ping is achieved, does not mean that the target has a lock solution. It could have a long radar range and still not have a missile that can launch within those parameters.


For example, a SAM unit with a max radar distance range of 100km and a radar min/max altitude range of 500ft/5000ft, cannot see a target that is more than 100km away. Once the target falls within its radar distance range, the target altitude is then taken into account. For example, if the target is at 80km distance at an altitude between 500ft and 5000ft, the SAM can see it. If the target then drops below 500ft or pops above 5000ft, the SAM will lose its tracking after a few seconds.


Note that all air, space and ground units have different radar detection characteristics. When in doubt, check the appendix data files.

You can use the Track Warning Indicator, TWI, to determine whether or not a selected ground threat can see you on radar or not.


Note that NID targets are not subject to the TRS radar target filters and if the TRS is in ground mode, then radar type objects are also visible in the NID.


LAUNCH WARNING INDICATORS (LWI)


These indicators are located to the lower left corner of the TRS display and provide critical threat assessment info.


TRK : Your craft is being tracked and scanned on radar
LCK : A hostile target has a valid weapons lock and launch solution on your craft.
LNH : A weapon has been launched at your ship and it has an active lock

That's very sensible, reasonable and informative.

Who are you, and what have you done with Derek ?

 

[dsmart]

That's very sensible, reasonable and informative.

Who are you, and what have you done with Derek ?

hehe yeah, heads are going to be exploding today once the herd gets wind of that one

 

[Osmanthus]

I'm just going to interrupt our regularly scheduled SC bashing and just say it:

It's much ado about nothing.

Excerpt from what I posted earlier today on my forum.

As a systems designer and someone who has developed some of the most complex (go play any of my Battlecruiser/Universal Combat games if you think this is hyperbole) systems in a space combat sim, I quite like how they implemented it. It looks cool, straightforward and functionally sound. Plus (and this is a biggie), they unified it across the infantry and ships. I did the same thing in my BC/UC games, whereby even the NPC infantry characters, have some sort of radar system which not only detects sounds, but also prioritized based on range and elevation.

What's lost in the translation I think, is how the dev described it. But the fact of the matter is that he described it correctly for the layman to understand how it works. On the face of it, the system is no different from any other implementation of a "power up" mechanic in hundreds of games. So this outrage is completely misplaced I think. Plus, he also stated that it's a first iteration, and that LA is going to be running with it. Which means that they are going to be tweaking and fine tuning it along the way.

The issue that I have with this system is that unless you're going to be doing this "scanning" while stationery or moving at low speed, it's going to be quite cumbersome to use - if you're the pilot. Using a mechanic such as this, whereby the player needs to provide constant input, is counter-intuitive and misplaced in a game like this. Heck, even the most hardcore air combat sims don't do it like this. I think it should be implemented as a fire-and-forget type system, but with simple key presses to activate whatever modes (e.g. ACTIVE vs PASSIVE) they want. Then all the benefits and restrictions are embedded within those modes.

In games of this type, the operation of a radar system is usually automated (it's not like this is a realistic air combat game which requires accuracy and fidelity). You plot the targets, give the radar a range, give the player a way to select targets etc. You can also differentiate the radar op based on range, elevation, altitude (if on planet surface), target cross-section size, op mode etc. You can literally go crazy with it.

If they wanted to implement this as a "skill" (which is precisely what I think they're going for) based op for multi-crew ships in which one player is going to be using this; then this is probably the way to do it. It's not like the pilot is going to be doing any of this; in much the same way that a turret gunner isn't expected to fly a multi-crew ship.

But here's the problem which all multiplayer games which require player cooperation, run into: who the frack wants to be sat there, in a chair, ing around with a game mechanic which, for all intent and purposes, doesn't provide the same instant gratification and satisfaction as any other game mechanic. I don't care what some of these guys keep dreaming up, even as they theory craft their way through a litany of pure and utter (which not even Chris Roberts has promised they could do in the game); when it comes down to it, most of them won't want to be that guy. In games which require player co-operation, there is always "fun" stuff for all players to use. e.g. a medic, a tank etc. In a game like this, there is nothing fun about a skill based radar system, no matter how it's implemented. Again, this is all assuming they are targeting this as a skill based system. If they aren't, then this point is moot.

At the end of the day, it's all down to user experience. If they keep it this way, in which it's a timed "progress bar" type system which requires constant input (among other things), instead of just a fire-and-forget key input (which can also have the progress bar as it powers up and activates), it will be a complete disaster. And then they will have to do what they always do: go back in, rip it all out, or nerf it. Time wasted.

My suggestion would be to keep everything as-is, but instead of the constant "golf swing" input, simply make it a fire-and-forget mode change input. e.g. passive is the default, then you press a key, and it switches to active, which then initiates the same progress bar. Then, it could be that once the player (pilot or other) switches modes, the pilot would have to keep the ship pointed at the target in order for the progress bar scan to complete quickly. Doing it this way also allows the player to operate the radar system, even without a co-op player. And in the event of a co-op player, perhaps the ability to select multiple targets based on priority (which the pilot may not be aware of; especially in a combat situation), is the add-on benefit. The other benefit to this is that it would work in all ship types, since it gives the pilot autonomy, but at a cost.

FYI, I don't believe this is a QTE (QuickTime Event) they are showing as the progress bar. It just looks like a Flash based UI (probably using Scaleform or similar; we use Iggy in LoD) animation.

Additional reading:

The radar system in my BC/UC games is quite complex under the hood, and I did my best to not expose too much of that to the user. Read how it works on p27 of the UCCE 3.0 game docs or read the excerpt below.

Spoiler

3.6 Tactical Radar Scanner (TRS)


This system is the center of your weapons and radar systems and its primary function is to track targets in all environments. Select one of its tabs to put it command mode or use the T key.

The TRS has several operating modes depending on the craft and the environment


SPC : Tracks space borne targets when in space
GND : Tracks ground targets when on planets
AIR : Tracks airborne targets when on planets
SUL : The Support Unit Locator mode filters out all targets except those of your
support crafts and personnel. These are color coded as follows:


Blue : Command Craft
Yellow : Shuttle
Cyan : Fighter
Green : Ground Unit
Red : Personnel
White : Probe
Grey : Mining Drone


When activated, two circles are displayed with one smaller than the other. These circles are used to track all targets in relation to your ship. Any target within the inner circle is in front of your ship's bearing. If the target is in the outer circle, it is behind your ship. The very center of the inner circle represents what is directly in front of your ship. Therefore, if a target is in the inner area you are directly facing it.


It is important to note there may be times when all targets in your region are not picked up by the TRS due to its limited range.


Targets in the display are color coded as follows, depending on the environment:


Blue : Neutral
Yellow : FATAL assigned
Cyan : Towed
Green : Friendly
Red : Enemy
White : Missile or Mine
Grey : Disabled


To select and cycle targets, use the . and , keys or move the mouse into the display and then click on the desired target. If the mouse is over more than one target, the target info is stacked and the current target is displayed with a flashing > marker.

Each click of the mouse will then cycle to the next target and the marker will move to that target (if any) in the cluster. You can also select a target from a menu list by clicking on one of the mode tabs (e.g. SPC) and using the Select Target menu.


Once a target is selected, the TTD (see section 3.3) will appear in the TDD if it is within the craft's field of view and will continue to move with the target. The target's range (km), closure (m/s) and acceleration rates (m/s) are displayed in the top left/right and lower right corners of the TRS.


Use the I command to view a target in the VID mode of the VDD. To cancel the current target, press the X key.


To switch to Single Target Tracking (STT) mode which filters out all targets except for the current one, use the \ key.


RADAR MODES


There are three radar modes and which also affect some of the NID and TACOPS operating modes. These modes can be toggled using the R key.


In ALERT mode (default) the radar tracks up to limits of the current space region and up to 250km when on a planet. The target info for all targets are displayed in the ITD but only the current target (if any) has all the information about the target. The other TTDs show only the target name and range.


In this mode, the TTDs are referred to as VTT (Visual Target Tracking) designators because they are always on (the object does not need to be targeted first) when you are within a certain range of a target. In first person mode, the VTT is always on, regardless of the DIE (see section 8) radar mode.


The VTT range varies depending on whether you are in space or on a planet and whether you are in first person mode or in a craft. The min/max ranges:


PLANET: SPACE:


Crafts 25m / 50km 1m / 150km
Personnel 1m / 100m 1m / 1km


In ACTIVE mode, the radar operates the same as ALERT mode, but only the TTD (with full information about the target) for the currently selected target is displayed in the ITD.


In PASSIVE mode, the radar ranging circles in the TRS go off and the ship detects objects based on a rotating antenna model. If you are on a planet, a Green line (you must zoom the map to see this) in the NID rotates about your craft's position, detecting any objects that the line passes over. This is like a conventional radar system. No energy is emitted from your craft as it is assumed that the objects are detected due to their thermal, EM or other property. This allows your craft to detect objects without exposing its position.


A limitation of passive mode is that, on a planet, the effective range is reduced to 5km, except when an object is using radar, in which case it can be detected up to 250km away. NPC units frequently use active radar.
Try sneaking up on one, and there is a very good chance that you're going to get pinged.


A missile cannot lock if the radar is in passive mode.


A radar enabled unit cannot achieve active ping if the target is outside of its min/max acquisition parameters. Just because an active ping is achieved, does not mean that the target has a lock solution. It could have a long radar range and still not have a missile that can launch within those parameters.


For example, a SAM unit with a max radar distance range of 100km and a radar min/max altitude range of 500ft/5000ft, cannot see a target that is more than 100km away. Once the target falls within its radar distance range, the target altitude is then taken into account. For example, if the target is at 80km distance at an altitude between 500ft and 5000ft, the SAM can see it. If the target then drops below 500ft or pops above 5000ft, the SAM will lose its tracking after a few seconds.


Note that all air, space and ground units have different radar detection characteristics. When in doubt, check the appendix data files.

You can use the Track Warning Indicator, TWI, to determine whether or not a selected ground threat can see you on radar or not.


Note that NID targets are not subject to the TRS radar target filters and if the TRS is in ground mode, then radar type objects are also visible in the NID.


LAUNCH WARNING INDICATORS (LWI)


These indicators are located to the lower left corner of the TRS display and provide critical threat assessment info.


TRK : Your craft is being tracked and scanned on radar
LCK : A hostile target has a valid weapons lock and launch solution on your craft.
LNH : A weapon has been launched at your ship and it has an active lock

Haha that's great
Thanks Derek
I legitimately enjoyed reading that, it was thoughtful and constructive

 

[Ben Parry]

That is not so. Reduce the scene scale by half and you run into all sorts of problems. Collision detection will get more and more wonky because of the reduced precision.

The reason is that if you reduce the scale of objects in your scene, you do lose precision.

If you want to halve the precision errors you have to double the scale of the scene.
(By that i mean making everything in the scene twice as big, which means the total room the scene portraits is halved)

I think you're pretty much saying the same thing but as viewed from a programmer's side rather than the user/player's side, and I think you meant halve the size of scene and double the errors.

Going to use rubbish numbers/powers of ten for ease but e.g. if at a certain internal scale in 32bit you can achieve 1cm accuracy and when you go to 64 bit and get 1mm accuracy for the same size play area then changing the scales so 1mm=1cm in 64bit the user experiences the same level of precision as 32bit but gets a vasty larger play area working out just as you describe - acceptable accuracy over a much larger distance from origin.

Internally you're exactly right about what's going on, but to the layman it could be described as shrinking all the objects and not be entirely wrong - but still not a bad thing and a stupid thing to kick up a fuss about in many ways. I guess the big detractors are saying so because it's not really solving the problem just changing it's scale, but while space is THAT big and even 64bit won't cover a real solar system it almost certainly will cover any actual space battles/events that really require it to all be in one segment(? what's the right term) so it's probably plenty to work with.

No, you guys still aren't getting it. The point I'm trying to make is that all this magical doubling and halving, there's no point in a programmer trying to do it manually, because that's what the "floating" in floating-point is. The first 8 bits of a float32 are literally that trick, built right into the number format.
I'll try to do a made-up decimal version, let's say we make up a fictional format that has seven decimal places (instead of bits) of mantissa, and two of exponent. Here's how some numbers might get represented:

1.36cm	1.360000 * 10-2	(works fine)
20km	2.000000 * 104	(so far so good)
20km + 1.36cm	2.000001 * 104	(oh dear)

So the format's lost us 36mm. This isn't great, so we decide to shrink eerything 100 times to "regain" the precision.

1.36cm / 100	1.360000 * 10-4
20km / 100	2.000000 * 102
20km / 100 + 1.36cm / 100	2.000001 * 102

That literally doesn't touch the main number representation at all, it just subtracts two from the exponent. Precision hasn't got better, it hasn't got worse. If there's some code somewhere that wants to, I dunno, sort objects into buckets, and it was assuming that 1m intervals was a good granularity, you've confused the hell out of that, but it'd have been confused by adding a moon several million km away too so it needed fixing anyway.
If you do a "fourteen decimal place conversion" instead, 20km + 1.36cm gets represented as 2.0000013600000 * 10⁴ and everything's dandy, besides people a strange recurring bug where people insist you didn't do it.

 

[dsmart]

No, you guys still aren't getting it. The point I'm trying to make is that all this magical doubling and halving, there's no point in a programmer trying to do it manually, because that's what the "floating" in floating-point is. The first 8 bits of a float32 are literally that trick, built right into the number format.
I'll try to do a made-up decimal version, let's say we make up a fictional format that has seven decimal places (instead of bits) of mantissa, and two of exponent. Here's how some numbers might get represented:

1.36cm: 1.360000 * 10^-2 (works fine)
20km: 2.000000 * 10⁴ (so far so good)
20km + 1.36cm: 2.000001 * 10⁴ (oh dear)

So the format's lost us 36mm. This isn't great, so we decide to shrink eerything 100 times to "regain" the precision.

1.36cm: 1.360000 * 10^-4
20km: 2.000000 * 10²
20km + 1.36cm: 2.000001 * 10²

That literally doesn't touch the main number representation at all, it just subtracts two from the exponent. Precision hasn't got better, it hasn't got worse. If there's some code somewhere that wants to, I dunno, sort objects into buckets, and it was assuming that 1m intervals was a good granularity, you've confused the hell out of that, but it'd have been confused by adding a moon several million km away too so it needed fixing anyway.
If you do a "fourteen decimal place conversion" instead, 20km + 1.36cm gets represented as 2.0000013600000 * 10⁴ and everything's dandy, besides people a strange recurring bug where people insist you didn't do it.

Agreed.

FYI, I didn't chime in because you seemingly had it under control. Then again, you're not as verbose as I am; so it's going to take you 3-4 posts (you have 1 more to go I think) to get your point across.

 

[Asp Explorer]

to get your point across.

It'll float across on it's own

You could always get a 68882 outboard motor

 

[dsmart]

Haha that's great
Thanks Derek
I legitimately enjoyed reading that, it was thoughtful and constructive

Honestly, I think all this time, people have forgotten that I backed this game - right from the start. So of course I had my own dreams in my head; and in which someone with the financial and team resources, built an accessible triple-A space combat sim in the vein of Wing Commander meets Freelancer.


Sadly, since CIG were mostly focused on raising money, than building a game, it didn't leave much room for me to engage in these types of discussions. PLUS, the last (July 2015) time I did that, I wrote a similarly themed blog. It all went sideways shortly after.


The fact is that I like the "idea" of the game, what its trying to do etc. That's why I backed it. So things like functionality, features etc, are things that I would much rather be writing about, than all this other stuff. However, while I don't believe - for one minute - that they are ever going to deliver the game promised, if they get the basic functionality of what was promised in 2012, into the much touted MVP, I'd be OK with that. It would be a grave injustice to those who backed thousands of dollars for a more advanced game than an MVP, but that's their problem, not mine. It's not like they didn't have enough warning that the game - as pitched - could never be built.

 

[Ben Parry]

Agreed.

FYI, I didn't chime in because you seemingly had it under control. Then again, you're not as verbose as I am; so it's going to take you 3-4 posts (you have 1 more to go I think) to get your point across.

I prefer something more like a dialogue. I find your posts, while verbose, tend to get to the point via some very odd tangents (recent examples: "game units", and a tangent explaining that when we say animations, there's more than one kind of animation in a game). Now, you've been having online arguments longer than I've had a computer, so maybe your techniques really are more optimal, but to me they read kind of... padded.

 

[dsmart]

I prefer something more like a dialogue. I find your posts, while verbose, tend to get to the point via some very odd tangents (recent examples: "game units", and a tangent explaining that when we say animations, there's more than one kind of animation in a game). Now, you've been having online arguments longer than I've had a computer, so maybe your techniques really are more optimal, but to me they read kind of... padded.

Indeed. But that's what makes us all different; and why someone giving a TED talk, isn't likely to be using the same format as a QA session on Quora, let alone a Powerpoint presentation.

Also, to me it's not really about what's "optimal"; but rather about how someone chooses to frame a response in their own unique style (which may not appeal to all in the target audience). To wit: In the 2 posts you made to get an important and very relevant point across, I'd have done it in one shot, dropped the mic, and walked off the stage.

 

[Ben Parry]

Indeed. But that's what makes us all different; and why someone giving a TED talk, isn't likely to be using the same format as a QA session on Quora, let alone a Powerpoint presentation.

Also, to me it's not really about what's "optimal"; but rather about how someone chooses to frame a response in their own unique style (which may not appeal to all in the target audience). To wit: In the 2 posts you made to get an important and very relevant point across, I'd have done it in one shot, dropped the mic, and walked off the stage.

Indeed. You're a very confident man.

 

[Cmdr Eagleboy]

Nice argument Derek. This discussion covers not only SC btw, as we have similar debates over this in ED community as well.

 

[dsmart]

Nice argument Derek. This discussion covers not only SC btw, as we have similar debates over this in ED community as well.

Which argument specifically? The radar one, or the banter with Ben?

 

[Soliluna]

Spoiler

No, you guys still aren't getting it. The point I'm trying to make is that all this magical doubling and halving, there's no point in a programmer trying to do it manually, because that's what the "floating" in floating-point is. The first 8 bits of a float32 are literally that trick, built right into the number format.
I'll try to do a made-up decimal version, let's say we make up a fictional format that has seven decimal places (instead of bits) of mantissa, and two of exponent. Here's how some numbers might get represented:

1.36cm	1.360000 * 10-2	(works fine)
20km	2.000000 * 104	(so far so good)
20km + 1.36cm	2.000001 * 104	(oh dear)

So the format's lost us 36mm. This isn't great, so we decide to shrink eerything 100 times to "regain" the precision.

1.36cm / 100	1.360000 * 10-4
20km / 100	2.000000 * 102
20km / 100 + 1.36cm / 100	2.000001 * 102

That literally doesn't touch the main number representation at all, it just subtracts two from the exponent. Precision hasn't got better, it hasn't got worse. If there's some code somewhere that wants to, I dunno, sort objects into buckets, and it was assuming that 1m intervals was a good granularity, you've confused the hell out of that, but it'd have been confused by adding a moon several million km away too so it needed fixing anyway.
If you do a "fourteen decimal place conversion" instead, 20km + 1.36cm gets represented as 2.0000013600000 * 10⁴ and everything's dandy, besides people a strange recurring bug where people insist you didn't do it.

Very informative, sadly I can't rep you again so instead I'm having to respond to you (which isn't a burden, it's just extra noise in the thread!)

 

[dsmart]

radar theory crafting. I don't even know what to say really.

Spoiler

 

[SkUnimatrix]

I'm just going to interrupt our regularly scheduled SC bashing and just say it:

It's much ado about nothing.

Excerpt from what I posted earlier today on my forum.

As a systems designer and someone who has developed some of the most complex (go play any of my Battlecruiser/Universal Combat games if you think this is hyperbole) systems in a space combat sim, I quite like how they implemented it. It looks cool, straightforward and functionally sound. Plus (and this is a biggie), they unified it across the infantry and ships. I did the same thing in my BC/UC games, whereby even the NPC infantry characters, have some sort of radar system which not only detects sounds, but also prioritized based on range and elevation.

What's lost in the translation I think, is how the dev described it. But the fact of the matter is that he described it correctly for the layman to understand how it works. On the face of it, the system is no different from any other implementation of a "power up" mechanic in hundreds of games. So this outrage is completely misplaced I think. Plus, he also stated that it's a first iteration, and that LA is going to be running with it. Which means that they are going to be tweaking and fine tuning it along the way.

The issue that I have with this system is that unless you're going to be doing this "scanning" while stationery or moving at low speed, it's going to be quite cumbersome to use - if you're the pilot. Using a mechanic such as this, whereby the player needs to provide constant input, is counter-intuitive and misplaced in a game like this. Heck, even the most hardcore air combat sims don't do it like this. I think it should be implemented as a fire-and-forget type system, but with simple key presses to activate whatever modes (e.g. ACTIVE vs PASSIVE) they want. Then all the benefits and restrictions are embedded within those modes.

In games of this type, the operation of a radar system is usually automated (it's not like this is a realistic air combat game which requires accuracy and fidelity). You plot the targets, give the radar a range, give the player a way to select targets etc. You can also differentiate the radar op based on range, elevation, altitude (if on planet surface), target cross-section size, op mode etc. You can literally go crazy with it.

If they wanted to implement this as a "skill" (which is precisely what I think they're going for) based op for multi-crew ships in which one player is going to be using this; then this is probably the way to do it. It's not like the pilot is going to be doing any of this; in much the same way that a turret gunner isn't expected to fly a multi-crew ship.

But here's the problem which all multiplayer games which require player cooperation, run into: who the frack wants to be sat there, in a chair, ing around with a game mechanic which, for all intent and purposes, doesn't provide the same instant gratification and satisfaction as any other game mechanic. I don't care what some of these guys keep dreaming up, even as they theory craft their way through a litany of pure and utter (which not even Chris Roberts has promised they could do in the game); when it comes down to it, most of them won't want to be that guy. In games which require player co-operation, there is always "fun" stuff for all players to use. e.g. a medic, a tank etc. In a game like this, there is nothing fun about a skill based radar system, no matter how it's implemented. Again, this is all assuming they are targeting this as a skill based system. If they aren't, then this point is moot.

At the end of the day, it's all down to user experience. If they keep it this way, in which it's a timed "progress bar" type system which requires constant input (among other things), instead of just a fire-and-forget key input (which can also have the progress bar as it powers up and activates), it will be a complete disaster. And then they will have to do what they always do: go back in, rip it all out, or nerf it. Time wasted.

My suggestion would be to keep everything as-is, but instead of the constant "golf swing" input, simply make it a fire-and-forget mode change input. e.g. passive is the default, then you press a key, and it switches to active, which then initiates the same progress bar. Then, it could be that once the player (pilot or other) switches modes, the pilot would have to keep the ship pointed at the target in order for the progress bar scan to complete quickly. Doing it this way also allows the player to operate the radar system, even without a co-op player. And in the event of a co-op player, perhaps the ability to select multiple targets based on priority (which the pilot may not be aware of; especially in a combat situation), is the add-on benefit. The other benefit to this is that it would work in all ship types, since it gives the pilot autonomy, but at a cost.

FYI, I don't believe this is a QTE (QuickTime Event) they are showing as the progress bar. It just looks like a Flash based UI (probably using Scaleform or similar; we use Iggy in LoD) animation.

Additional reading:

The radar system in my BC/UC games is quite complex under the hood, and I did my best to not expose too much of that to the user. Read how it works on p27 of the UCCE 3.0 game docs or read the excerpt below.

Spoiler

3.6 Tactical Radar Scanner (TRS)


This system is the center of your weapons and radar systems and its primary function is to track targets in all environments. Select one of its tabs to put it command mode or use the T key.

The TRS has several operating modes depending on the craft and the environment


SPC : Tracks space borne targets when in space
GND : Tracks ground targets when on planets
AIR : Tracks airborne targets when on planets
SUL : The Support Unit Locator mode filters out all targets except those of your
support crafts and personnel. These are color coded as follows:


Blue : Command Craft
Yellow : Shuttle
Cyan : Fighter
Green : Ground Unit
Red : Personnel
White : Probe
Grey : Mining Drone


When activated, two circles are displayed with one smaller than the other. These circles are used to track all targets in relation to your ship. Any target within the inner circle is in front of your ship's bearing. If the target is in the outer circle, it is behind your ship. The very center of the inner circle represents what is directly in front of your ship. Therefore, if a target is in the inner area you are directly facing it.


It is important to note there may be times when all targets in your region are not picked up by the TRS due to its limited range.


Targets in the display are color coded as follows, depending on the environment:


Blue : Neutral
Yellow : FATAL assigned
Cyan : Towed
Green : Friendly
Red : Enemy
White : Missile or Mine
Grey : Disabled


To select and cycle targets, use the . and , keys or move the mouse into the display and then click on the desired target. If the mouse is over more than one target, the target info is stacked and the current target is displayed with a flashing > marker.

Each click of the mouse will then cycle to the next target and the marker will move to that target (if any) in the cluster. You can also select a target from a menu list by clicking on one of the mode tabs (e.g. SPC) and using the Select Target menu.


Once a target is selected, the TTD (see section 3.3) will appear in the TDD if it is within the craft's field of view and will continue to move with the target. The target's range (km), closure (m/s) and acceleration rates (m/s) are displayed in the top left/right and lower right corners of the TRS.


Use the I command to view a target in the VID mode of the VDD. To cancel the current target, press the X key.


To switch to Single Target Tracking (STT) mode which filters out all targets except for the current one, use the \ key.


RADAR MODES


There are three radar modes and which also affect some of the NID and TACOPS operating modes. These modes can be toggled using the R key.


In ALERT mode (default) the radar tracks up to limits of the current space region and up to 250km when on a planet. The target info for all targets are displayed in the ITD but only the current target (if any) has all the information about the target. The other TTDs show only the target name and range.


In this mode, the TTDs are referred to as VTT (Visual Target Tracking) designators because they are always on (the object does not need to be targeted first) when you are within a certain range of a target. In first person mode, the VTT is always on, regardless of the DIE (see section 8) radar mode.


The VTT range varies depending on whether you are in space or on a planet and whether you are in first person mode or in a craft. The min/max ranges:


PLANET: SPACE:


Crafts 25m / 50km 1m / 150km
Personnel 1m / 100m 1m / 1km


In ACTIVE mode, the radar operates the same as ALERT mode, but only the TTD (with full information about the target) for the currently selected target is displayed in the ITD.


In PASSIVE mode, the radar ranging circles in the TRS go off and the ship detects objects based on a rotating antenna model. If you are on a planet, a Green line (you must zoom the map to see this) in the NID rotates about your craft's position, detecting any objects that the line passes over. This is like a conventional radar system. No energy is emitted from your craft as it is assumed that the objects are detected due to their thermal, EM or other property. This allows your craft to detect objects without exposing its position.


A limitation of passive mode is that, on a planet, the effective range is reduced to 5km, except when an object is using radar, in which case it can be detected up to 250km away. NPC units frequently use active radar.
Try sneaking up on one, and there is a very good chance that you're going to get pinged.


A missile cannot lock if the radar is in passive mode.


A radar enabled unit cannot achieve active ping if the target is outside of its min/max acquisition parameters. Just because an active ping is achieved, does not mean that the target has a lock solution. It could have a long radar range and still not have a missile that can launch within those parameters.


For example, a SAM unit with a max radar distance range of 100km and a radar min/max altitude range of 500ft/5000ft, cannot see a target that is more than 100km away. Once the target falls within its radar distance range, the target altitude is then taken into account. For example, if the target is at 80km distance at an altitude between 500ft and 5000ft, the SAM can see it. If the target then drops below 500ft or pops above 5000ft, the SAM will lose its tracking after a few seconds.


Note that all air, space and ground units have different radar detection characteristics. When in doubt, check the appendix data files.

You can use the Track Warning Indicator, TWI, to determine whether or not a selected ground threat can see you on radar or not.


Note that NID targets are not subject to the TRS radar target filters and if the TRS is in ground mode, then radar type objects are also visible in the NID.


LAUNCH WARNING INDICATORS (LWI)


These indicators are located to the lower left corner of the TRS display and provide critical threat assessment info.


TRK : Your craft is being tracked and scanned on radar
LCK : A hostile target has a valid weapons lock and launch solution on your craft.
LNH : A weapon has been launched at your ship and it has an active lock

I would make a horrible game designer. I've always wanted to introduce a level in FPS COD/Battlefield games that would be a Penn & Teller's Desert Bus like level called "Guard Duty". Where you patrol a perimeter for several hours and nothing happens. Or there is a 1/1000 chance of something happening. There would also be a mechanic where if your character stops moving for more than a couple minutes they "fall asleep" and the mission fails. Also would be a number of other fail mechanics like if they discharged a weapon they would fail for causing a negligent discharge, etc..

As far as radars/sensors go there's been a lot of designs. Maybe your main dish can scan out to say 10KM in front, but has a passive detection range of only 2KM with a 360 degree bubble. But they've mentioned features like a RWR (Radar Warning Receiver) in the Brochure of the Gladiator way back in the day. So basically it would work closer to say a DCS: Flaming cliffs where you have to learn to use the sensors in front of you and how to target missiles when the opponent is using a jammer. All this is usually modeled rather simply in aviation sims because the exact nature of how ELINT/SIGINT and Jamming systems work is classified. Even if the game designers know how it work they don't show it in the civilian market products. They basically just turn it into basic game mechanics at that point.

Signed, someone who seriously looked into making an F-4 cockpit for DCS only to meet with the folks at Boeing and discover all the flight data, etc. for the F-4 is still classified because Iran.

 

[Stigbob]

I would make a horrible game designer. I've always wanted to introduce a level in FPS COD/Battlefield games that would be a Penn & Teller's Desert Bus like level called "Guard Duty". Where you patrol a perimeter for several hours and nothing happens. Or there is a 1/1000 chance of something happening. There would also be a mechanic where if your character stops moving for more than a couple minutes they "fall asleep" and the mission fails. Also would be a number of other fail mechanics like if they discharged a weapon they would fail for causing a negligent discharge, etc..

How about a ceremonial royal guard level where you can't move for 2 hours, with a fascinating tourist attraction behind you and sarcastic tourists ahead. You have to keep your eyes moving about with the mouse to look for naughty people. With a 1/10,000 chance of a suicide bomber.

If you move you fail and get 2 extra punishment duties doing the same thing, which you need to complete before finishing a total of 6 hours on guard. If you don't see the suicide bomber you get blown up and die, if you do see the suicide bomber you raise the alarm and he detonates early permanently crippling your legs.

I can't see realistic military games ever catching on.