DESIGN/DEBUG: Invisible exploits/making invisibility useful

[MrBaggins]

There are a few ways that, as a human player in CTP2 that you can figure out information that you shouldn't ordinarily have... that is...

1) Knowing "where" cities are
2) Knowing if an enemy city is defended
3) Knowing "where" enemy army/units are

The exploits are largely based around the pathing/attack display (will react "truthfully" to unseen/unknown influences,) and the behavior of right click on terrain where it contains an invisible and/or unseen unit.

I'd consider it a bug that you can gain information like this. Its a fairly major exploit.


I'd like to take it just one step forward, though...

I think that invisibility should be "improved" so that not only are the units "invisible" based on visibility classes but that they have a special feature... if movement moves over an "invisible" unit then it will be displaced (unless it doesn't have a valid square to move to.) If the original square becomes available again, then it will move back there.

This special condition should only last until

1) its seen by an enemy unit able to spot it, or,
2) it uses a special ability or action of any type (attacks, enslaves, etc)

We might wish to make disguised trade vessels that have special visibility classes, and limited cargo types... like being able to carry one unconventional unit, say...

Although they'd be good for spying/exploration too...

[child of Thor]

Yes it would be a nice way to resolve the current problem(although to be honest i never usually remember to bother to use it!), i'm guessing that the invisible units movement away from being 'steped on' would be free?
Hmmm how would you do this not on that civs go?
Cant we just make invisible units stackable with other enemy units untill discovered?(and then it would appear next to the discovering unit, rather than under).

[MrBaggins]

Yes, there wouldn't be a cost for the "avoidance" thats happening.

As for how to implement it "out of turn"... that remains to be seen.

As for making the invisible units stackable... that defeats the basic point. Its highly unlikely that a stack will get through, where an invisible unit cannot, versus the human player, which is what this is essentially for.

[Maquiladora]

There is another bug with invisible units, the screen will center on the enemy unit (even if its invisible) when one moves through unfogged terrain.

[child of Thor]

Interesting Maq...........does this happen when you play MP online as well? All this stuff will be important to try to resolve, especially in MP where 'cheats' can destroy a game.

Mr Baggins - with the enemy stackable invisible unit, i was just thinking of a way to make them truely invisible to the player - if you could just walk right over them you wouldn't know they were there, unless you used your own invisible unit to find them first.
I'm worried getting the invisible unit to move outside of its turn might be very difficult.........

[MrBaggins]

I'm not understanding the point you're trying to make here (a way to make them truely invisible)... could you explain it situationally?

[Maquiladora]

How would we kill them if we could just move "through" them? I guess he means we would first need another stealth unit to "see" it then it becomes visible and cant be passed through, and so dies whe moved "onto".

does this happen when you play MP online as well? All this stuff will be important to try to resolve, especially in MP where 'cheats' can destroy a game.

Yes, unfortunately which is why i often play without Slavers in MP, they contain SO many bugs.

[MrBaggins]

Right.. they can't be seen, and automatically avoid and hence can't be killed until they lose this status.

Since I'm suggesting they lose the property when they use any ability or get seen by a capable unit... its not like they gain too much power from this.

This should basically require players to invest a bit more in units that can spot these units.. rather than ignoring those and using military units instead essentially.

[child of Thor]

Originally posted by MrBaggins
This should basically require players to invest a bit more in units that can spot these units.. rather than ignoring those and using military units instead essentially.

Exactly - you can just probe around and bump into a stealth unit with a conventional unit. This may be reasonable in some ways, but to make the whole stealth unit thing really fun it would require a stealth unit to actualy find and reveal another stealth unit.

And Maq summed up what iwas thinking about being able to move your army over an enemy stealth unit, unless you had found it first with your own one. It wouldn't require the Ai civ to do much outside of its own go, like have to move it when an enemy army moved onto it.

It would just be walked over - unless someone used a stealth unit to check the squares first.
So the stealth units would have two states while alive:

1. Steath/hidden - REALLY invisible, other units can walk over it on the map and untill it conducted a failed stealth attack(its own turn) or was discovered by another stealth unit(would have to pop up near the discovering unit - so not under it?) it would be a real stealth unit, not affected by any other.

2. Non-stealth - act as a seen unit on th map, unable to be passed by an enemy without being attacked etc.

Any clearer? I'm not sure if i can put it better

I'm just thinking making the AI look out for if its stealth units are being walked into while NOT on its actual turn will be hard to do or the small pause it may generate be a bit of a give away?(although i have no idea if these are legitimate concerns )

[MrBaggins]

Regarding the actual bug, I'm just getting started on sorting it.

FWIW, from an initial glance, its got to do with just aborting the m_contextMenu instead of defaulting to showing a Map Info, when the unit is invalid because of invisibility. Its in (as all of the main interface functions are,) \CTP2_CODE\ui\interface\controlpanelwindow.cpp

EDIT:

It doesn't occur at the front end abstracted ui interface level, it seems... its further back in the basic AUI stuff.

[MrBaggins]

Found, solved and (very quickly) tested.

The resolution is in SelItemClick.cpp, listed in UI/AUI_CTP2/Original in Visual Studio FileView.

Although its "Original" its apparently still in use...

The current behavior is to not show anything (including Map Info) for a context (right) click on tiles with enemy armies on. I've simply changed that to showing Map Info on a Enemy Army context click.

void SelectedItem::EnemyArmyContextClick(const MapPoint &pos, const aui_MouseEvent *data, BOOL doubleClick)
{
	// Context click on Enemy Army shows Map Info dialog instead of nothing, to avoid being able to detect
	// 'invisible units' by the absence of Map Info when clicking on a square.  Default was to do nothing
	// on a context click on Enemy Army/Unit.  We could also, if it was desired, only show Map Info if the
	// unit was 'invisible'
	//
	// Bug Fix by MrBaggins - 20031230
		if(g_player[GetVisiblePlayer()] && g_player[GetVisiblePlayer()]->IsExplored(pos)) {
		helptile_displayData(pos);  //Map Info Dialog
	}

}

[Martin Gühmann]

And what is now the difference between this code:

//----------------------------------------------------------------------------
//
// Name       : SelectedItem::EnemyArmyContextClick
//
// Description: Handle mouse click on an enemy army.
//
// Parameters : pos			: position on the map
//				data		: click properties (right, left, etc.)
//              doubleClick	: is it a double click?
//
// Returns    : -
//
// Remark(s)  : -
//
//----------------------------------------------------------------------------

void SelectedItem::EnemyArmyContextClick(const MapPoint &pos, const aui_MouseEvent *data, BOOL doubleClick)
{
#if !defined(ACTIVISION_ORIGINAL)
	// Report the underlying terrain information. For visible units, this is 
	// just being useful. For invisible units, it will fix the bug that 
	// detection is too easy.
	TerrainContextClick(pos, data, doubleClick);
#endif
}

The altered source file zip I uploaded recently contains the SellItemClick.cpp that contains that code. File: 2003-12-23All.zip and it is also in the previous versions.

-Martin

[MrBaggins]

/me smiles

Guess I should load the new package, huh?

I could have sworn I did... Oh well... *smiles*

You could have mentioned you'd fixed it in this thread, btw, which would have saved some duplication.

/me chuckles some more

[Martin Gühmann]

Originally posted by Mr Baggins
You could have mentioned you'd fixed it in this thread, btw, which would have saved some duplication.

Of course I could have, but to be able to do it I need to read it first, and in the last days I had something else to do. And if it is not really important I don't like to log in here as I lose all the posts as marked unread.

And by the way please use this format to mark added code:

#if !defined(ACTIVISION_ORIGINAL)
      //new code#endif
#endif

#if defined(ACTIVISION_ORIGINAL)
      //Old code
#else
      //New code
#endif

Using the compiler derectives to "outcomment" code is in my opinion a very clean way to mark new and old code. Unfortunatly I started to do it like this afterwards Fromafar posted such code, so in my first fixes you see also the format of really outcommented code. Of course for testing purposes you can first outcomment the code and once you have the final code together do it in the clean way.

-Martin