Exploratory Radar

[spiritplumber]

Do we want an exploratory radar in the game RIGHT NOW?


How it would work (kinda hackish):


An exploratory radar would have a color qualifier of 3 -- 0 is b/w, 1 is basic color and 2 is full color.

An exploratory radar would act exactly as a B&S radar but, if the approprate flag is set in vegastrike.config, it would display jump points that belong to the "unknown" faction. No other radar would then display them.

Is this workable/acceptable?


(I did say I was going to semi-quit, but patch 15 has too many bugs and I want an alpha 0.2 that is nicely playable)

[klauss]

I would think it twice.
It's a good idea to tie the color value, but I'm not sure about the "unknown faction" thing. That could be messy, since the unknown faction, I think, is used somewhere for scripted missions. I'd better have a new "unexplored" faction.

[spiritplumber]

well it would only affect jump points having them belong to the "unnown" faction is acceptable... since the radar color variable is a shortint, we can use the six most significant bits as a bitmask for special features i guess, like "show a blip for cloaked ships" and "show a blip/allow jump thru uncharted jump points".

With the preamble that all this stuff can be overridden by vsconfig in case it's not being used, what i wanted to do was:

bits 0-1 color level (00 b/w, 01 basic color, 10 full color, 11 spare)
bit 2 show blip, and allow jumping thru, nonvisited jump points (otherwise you need to prebuy a map -- this should make the GG crew happy)
bit 3 show blip, and allow jumping thru, belonging-to-unknown (aka unexplored) jump points
bit 4 show blip for cloaked ship
bit 5 allow targeting a cloaked ship
bit 6 jam other people's radars maybe? would be good for wc4 jammr corvette and zartoth
bit 7 leave alone to not compromise signs

this might make the upgrades a bit messy but we could have radar upgrades that just set a bit in the bitmask.

[klauss]

I see.
Why not promote the short to a long, and make:

bits 0-4: color level (00 b/w, 01 basic color, rest spare) - have some room for expanding
bit 5: autovisit - show blips, and allow jumping through, nonvisited jumppoints.
bit 6: autoexplore - show blips, and allow jumping through, unexplored jumppoints (those belonging to 'unknown' or 'unexplored', as you wish)
bit 7: cloak detection - show blips for cloaked ships
bit 8: cloak targetting - can target cloaked ships
bit 9-30: free
bit 31: 0 - keep sign, make life easier for CSV editing

But... a few things I would keep out of these detection flags, and create new fields:
cloak detection range
cloak targetting range
autoexplore range

Most important is the autoexplore range. Jumppoints should not be detected across the entire system. You should have to get close to them.

[spiritplumber]

hmm.... this is WCU specific of course, but autoexplore should be a quest item -- you stealing it off the Exploratory Service or something. The idea is having something that allows you to travel in the grey zone we keep talking about freely.

as for detection range, what's wrong with using radar range? maybe have a multiplier for it.

and if we're adding fields at this point i vote for adding a dedicated bitmask shortint and leaving radarcolor alone easier to check against stuff.

just a thought ^^;

[chuck_starchaser]

You're sooo fast, Spirit. Exploration radar already! I had something a bit more gimmicky in mind, like, say in the Rygannon missions first you have to fly to the jump-points, which are marked like waypoints, and when you're done, the computer analyzes the data. You could see completion bars that go through several stages...

Code: Select all

Dead reckoning...
+****************+
Triangulating...
+****************+
Paralax...
+****************+
Antigrav drift...
+****************+
Testing...
+***********.....+

... and then the jumps appear on the HUD

I have no problem with bitwise arithmetic per-se, but if this "color variable" is going to be used as a "scanner target attributes" perhaps it should be in a class named...

Code: Select all

class scanner_target_attributes //never mind "color"
{
    char bitmask; //or an actual bitvector
};

then

Code: Select all

class radar_color : public RGB
{
};

then

Code: Select all

class scanner
{
  virtual radar_color get_color( int unit_type_id ) const = 0;
};

then

Code: Select all

class BnSOmniExplorer : public scanner
{
  radar_color get_color( int unit_type_id ) const;
};

then in cpp file

Code: Select all

radar_color BnSOmniExplorer::get_color( int unit_type_id x )
{
   RGB result;
   load_file( "units.csv"); // ;-)
   scanner_target_attributes sta = lookup_units_csv_for_attr( x );
   load_file( "OmniExplorer_color_table.csv" ) or whatever...
   if( sta & 0b01000000 ) do_x();
   else if( sta | ~0b01000000 ) do_y();
   else look_up_in_table(x) or whatever...
   close_files();
   return result;
}

Just being liberal and poetic with the code
What I mean to convey is the general organization, and properly naming things, which often doesn't get enough attention...

[klauss]

Yes, spirit... you're right. Leaving color alone and creating a bitmask with flags would be the best option.

Try to do it similarly to the way tractor flags are done: with symbolic names instead of a bitmasked int. It's much more readable that way.

About the range: I can think of many reasons to have a decoupled range for exploration. We could want exploration to occur only when you're almost on top of the jumppoint, or even need to trigger it. Or we could want blips to appear all around, and still have the need to trigger antigraviton tracing to confirm the jumphole's viability (we could have fake jumpholes that don't jump anywhere )

So...

color is left alone.

There is a bitmask like this:

Code: Select all

struct scanner_attributes {
    unsigned int autovisit:1;
    unsigned int autoexplore:1;
    unsigned int antigravtracing:1;
    unsigned int detectcloak:1;
    unsigned int targetcloak:1;
}

Note antigravtracing: that, along with a keybinding, allows you to trigger the antigraviton tracing procedure.

And in CSV you specify them with a string where V=autovisit, E=autoexplore, Dc=detect cloak, Tc=target cloak, so all features on would be a string like "VETcDc", all off would be "-", default would be "" (which, incidentally, and as opposed to tractor flags, would be all off).

And, another field for scanner_autoexplore_range, which could be anywhere from 1(1 meter) to 0(infinity), with al the inbetweens (that is, 0=infinity, >0 is range in meters, disabled with the scanner attributes).

And another fields for cloak detection. Cloak detection ranges could be specified as multipliers of the scanner's detection range.