Opened 14 years ago

Closed 10 years ago

Last modified 10 years ago

#599 closed defect (fixed)

[PATCH] Hide changes to buildings in fog-of-war

Reported by: Philip Taylor Owned by: Itms
Priority: Must Have Milestone: Alpha 17
Component: Core engine Keywords:
Cc: Patch:

Description

When a building (or tree etc) is visible in a fog-of-war region, no new information should be revealed to the player - they shouldn't see when its hitpoints change, or when it's destroyed, etc. Perhaps they shouldn't be able to select the building at all (even just to see its name).

Probably this would have to be implemented by replacing buildings with 'mirage' entities when they fall into FoW, which are clones of the original buildings with all the dynamic/interactive bits removed. (These would have to be serialised in saved games, and therefore network-synchronised, but only rendered for the appropriate player.)

We also have to deal with the case of players ordering units to attack or gather from a mirage entity - when it comes back into vision, the units should automatically switch to attacking/gathering the real entity (or realise that it's been destroyed).

Attachments (8)

proxywip.patch (29.5 KB ) - added by Josh Matthews 12 years ago.
WIP patch
proxy.diff (39.9 KB ) - added by Josh Matthews 12 years ago.
Latest WIP
fogging.patch (33.3 KB ) - added by Itms 10 years ago.
update_visibility.patch (12.4 KB ) - added by Itms 10 years ago.
fogging+optimization.patch (43.4 KB ) - added by Itms 10 years ago.
graphs.png (224.7 KB ) - added by wraitii 10 years ago.
Graph of how much the update_visibility patch affects performance.
fogging_scripted.patch (30.5 KB ) - added by Itms 10 years ago.
fogging.diff (37.5 KB ) - added by Itms 10 years ago.

Download all attachments as: .zip

Change History (66)

comment:1 by (none), 14 years ago

Milestone: Unclassified

Milestone Unclassified deleted

comment:2 by Andrew, 14 years ago

Milestone: OS Alpha 2
Owner: set to Philip Taylor

comment:3 by Kieran P, 14 years ago

Milestone: OS Alpha 2OS Alpha 3

comment:4 by Kieran P, 13 years ago

Type: taskdefect

comment:5 by Kieran P, 13 years ago

Milestone: Alpha 3Alpha 4

comment:6 by Kieran P, 13 years ago

Priority: majorcritical

comment:7 by Kieran P, 13 years ago

Owner: Philip Taylor removed

comment:8 by Kieran P, 13 years ago

Milestone: Alpha 4Alpha 5

comment:9 by Kieran P, 13 years ago

Milestone: Alpha 5Alpha 6

comment:10 by Kieran P, 13 years ago

Milestone: Alpha 6Alpha 7
Priority: Must HaveShould Have

comment:11 by Kieran P, 13 years ago

Milestone: Alpha 7Alpha 8

comment:12 by historic_bruno, 13 years ago

Priority: Should HaveMust Have

Note that this problem is seen with all entities that remain in FOW, including new enemy buildings that are constructed in previously explored areas. Basically, it's a huge cheat because if you explore the map early, you see all building changes for the rest of the game (see also #1008).

comment:13 by Kieran P, 12 years ago

Milestone: Alpha 8Alpha 9

comment:14 by Josh Matthews, 12 years ago

Owner: set to Josh Matthews

I'm attempting to learn the ropes of 0ad development by tackling this bug. More updates as warranted; I have a half-backed patch that was sort of working before I fixed some correctness bugs and started causing crashes instead.

by Josh Matthews, 12 years ago

Attachment: proxywip.patch added

WIP patch

comment:15 by Kieran P, 12 years ago

Milestone: Alpha 9Alpha 10

comment:16 by Josh Matthews, 12 years ago

Just some proof that I haven't given up and abandoned this project yet. The following cases work correctly:

  • fogged entities at the very start of the game still appear
  • a fogged building that is deleted appears unchanged
  • new buildings created in fogged areas do not not appear
  • revealing a fogged proxy when the original entity no longer exists causes the proxy to disappear
  • following orders to gather resources from a proxy transparently switches to gathering resources from the original entity when the original one is revealed
  • a fogged foundation in process of being built does not reveal any further changes in hit points

Untested, but should work:

  • proxied buildings don't have an AI
  • ordering a proxy attacked transparently switches to attacking the original when it is revealed

Tested, doesn't work:

  • a peasant building a house that is fogged for another player will continue building the house event after it appears complete - they appear to be working on the proxied entity for some reason, as the peasant stops as soon as the other player causes the finished house to be revealed

If there are further suggestions for tests I should perform, that would be super helpful.

comment:17 by Kieran P, 12 years ago

Cc: Josh Matthews added
Keywords: review added
Summary: Hide changes to buildings in fog-of-war[PATCH] Hide changes to buildings in fog-of-war

Hey jdm. Thanks for your patch. I'm looking forward to this being completed. In the mean time, hopefully one of our other devs can review what you have so far soon and let you know of any obvious changes needed.

comment:18 by Kieran P, 12 years ago

Keywords: patch added

comment:19 by Kieran P, 12 years ago

Keywords: wip added; review removed

Hey jdm. According to your last report the patch was WIP and still had some things to test. How's progress on that coming along?

comment:20 by Josh Matthews, 12 years ago

I haven't had time to do any further thinking about this between exams and other work.

comment:21 by Kieran P, 12 years ago

Alright, no problem. Are you still keen to finish this up though, when you have free time?

comment:22 by Kieran P, 12 years ago

Milestone: Alpha 10Alpha 11

@jdm I'm pushing this to Alpha 11, which will be due around mid July. Hopefully you'll have some type of summer break if you're in the U.S., and can work on this again if you're still wanting to finish it up. I appreciate your work on this thus far. It's one of the big things missing from multiplayer games.

comment:23 by Kieran P, 12 years ago

Keywords: patch, wip → patch wip
Milestone: Alpha 11Backlog

Pushing back to backlog until a more complete patch is ready for review.

comment:24 by Josh Matthews, 12 years ago

Here's a rebased version that fixes that known problem from several months ago. I would appreciate feedback on this, especially on my solution to the problem of creating fogged buildoings at game start. Since we want those to appear, but not new buildings that are created in fogged areas after the start of the game, I ended up resorting to checks involving the game turn when the building is created. If you have a better idea on how to do this, I'm all ears.

comment:25 by Josh Matthews, 12 years ago

The other thing I'm not thrilled about with this patch is how so many places have to start checking for proxies. One particularly insidious problem I came across is the range manager - for example, units upon finishing constructing a foundation perform a range manager query for other entities nearby. This query ends up returning proxy buildings since they're owned by the player. I didn't spend enough time convincing myself that it would be fine to ignore all proxies in the range manager, so I special cased that one situation. There are likely others, so a more general solution would be nice.

comment:26 by Josh Matthews, 12 years ago

Note to self: test whether territory boundaries change while fogged (they should not, but probably do)

comment:27 by Deiz, 12 years ago

As you're not on IRC at the moment I'll document some issues here.

A lot of these issues stem from proxies being real entities that exist for all players. I don't think this can be worked around due to attack targets and such needing to be valid for all players. However, clearly simply not rendering proxied entities for other players is insufficient.

The first thing I noticed is that proxied entities show territory borders for all players. You can test this by walking past a player 2's civic centre, and then deleting it with player 2 afterwards. Player 2's territory borders will remain the same until player 1's proxy of the civic centre ceases to exist.

A related issue is that proxied entities provide line of sight for their owner. So, again using the above example, if player 2 deletes his civic centre and then moves all his units away, he will still be able to see using the line-of-sight the proxy entity is providing.

Some classes of foundations still seem to get created, even when fogged at creation time. Examples include walls and farm fields, possibly others. This brings me to my next issue: Proxied entities can block construction, in both an abstract and direct sense. The former occurs when you e.g. lose a civic centre and then can't build another near it until the proxied entity is destroyed. The latter occurs any time you try to build walls, farm fields, etc. within an area that is fogged (but not hidden) to your opponent.

Lastly (a small one) you're only copying health for foundations. So, e.g. if you attack an enemy's fortress, get it down to half health, and your force dies, the proxy entity will have full health.

I suppose you're already aware, but... this issue is turning out to be quite complex.

comment:28 by Josh Matthews, 12 years ago

The latest version I've attached should fix the various problems related to territory/influence, construction obstruction, and non-foundation health. I also added the change to the range manager to not follow changes to proxy entities at all, but I'm unsure of the full scope of the effects of this. I have not figured out why some foundations show up in fogged areas yet.

comment:29 by Josh Matthews, 12 years ago

This most recent version should have fixed the issues with farms/walls showing up when they shouldn't. They don't trigger LOS updates like most other buildings, so the proxy creation wasn't occurring.

by Josh Matthews, 12 years ago

Attachment: proxy.diff added

Latest WIP

comment:30 by Deiz, 12 years ago

I did some brief testing and ran into a few issues.

Foundation proxy entities still block construction, so if you observe an enemy's uncommitted (i.e. no builder has reached it yet and it has 1 health) foundation and then leave before it starts being built, your proxy entity obstructs the construction.

Territory borders aren't always updated correctly. If you get into visual range of a proxy entity that's been destroyed, the border is removed, as expected. However, entities that weren't there when you last saw the area will not update their borders until another of that player's (nearby?) visible entities with territory is finished. The delayed update might also happen upon destruction of another visible entity, but I haven't tested that.

It also seems that territory that's there at map start is always revealed. I.e. you will see the territory border of the enemy's civ centre no matter what.

Lastly (this relates somewhat to our IRC discussion), you can't see your own foundation entities if you place them in a fogged region. Nor do you get a proxy entity for them; they're simply hidden until they're within your LOS. For now I'd just create them as proxies immediately.

Restricting information leakage (allowing 'virtual' foundation placement, with the real foundation only being placed when a builder is within LOS) seems outside the scope of this patch, as it's quite complex. Beyond just that, there'd also be issues like the civ centre range restriction or structures that can only be built in friendly or neutral territory - both cases could be impacted by unseen entities.

comment:31 by wraitii, 11 years ago

I'm thinking this could be done in an easier way and with fewer edge cases if the Proxies were components of the actual entity, instead of autonomous entities. Does anybody have input on that?

comment:32 by historic_bruno, 11 years ago

(There was some discussion about this on IRC, see http://irclogs.wildfiregames.com/2013-05-05-QuakeNet-%230ad-dev.log -- from 16:14 to 18:05)

comment:33 by historic_bruno, 10 years ago

Owner: Josh Matthews removed

comment:34 by Itms, 10 years ago

Keywords: review added; wip removed
Milestone: BacklogAlpha 17
Owner: set to Itms

Hello! I've worked on a patch for this feature.

Taking in account previous discussions, I decided to design this using components. I managed to implement most of the things jdm and Deiz mentioned above, without increasing dramatically the complexity of the code.

I was not able to test it on the network yet. I am also wondering what kind of tests I should add for my components.

Finally, this patch does not address #1008, to avoid a patch too huge, but once this is OK I should be able to work on this too.

Please share your thoughts! And thanks in advance for the review work :)

comment:35 by Josh Matthews, 10 years ago

Woo! I have to say that I like how many of the changes just relate to visibility assumptions; this definitely feels more maintainable than my earlier attempts at first glance. Thanks for taking this on :)

comment:36 by Itms, 10 years ago

This is a new version of the patch, using EntityRenamed to improve command redirecting between mirages and real entities.

I also reverted a wrong change about the visibility states defined in the range manager. Now the "fogged" state only describes a mirage entity in the FoW, which is useful to determine, when the real entity is destroyed, when the mirage can be destroyed too.

comment:37 by Josh, 10 years ago

Not an actual functional review, but you have trailing spaces on line 340 of TemplateLoader.cpp and line 337 of BuildingAI.js. The comment on line 338 of BuildingAI.js, and a few similar ones, don't really make sense to me (remember that comments should be understandable by anyone who reads your code). The parentheses in the if statement on line 95 unit_actions.js isn't needed (AND is always evaluated before OR). you should combine the two for loops starting on lines 71 and 74 of CCmpFogging.cpp similar to what you do in Deserialize(). You have extraneous brackets and indentation on lines 100-102 and 105-112 of CCmpFogging.cpp. There is some similar irregular indenting/bracketing in the switch on line 69 of CCmpMirage.cpp. Comment on 1370 of CCmpRangeManager.cpp doesn't make sense to me. Otherwise, it looks pretty good.

comment:38 by Itms, 10 years ago

Thanks for your input!

This version addresses your comment and fixes some problems I came across while testing.

I'll be able to improve this by cleverly select for which entities the mirages should be updated. This will be way better performance-wise and will make possible the fogging of Gaia entities.

In the meantime, this version should be fully functional and testable. Thanks again in advance for the review work!

comment:39 by Josh, 10 years ago

Just some quick comments as I read through it again:

  • I think I was too vague about the switch statements. You have:
switch (msg.GetType()) 
{ 
case MT_Update: 
{ 
    UpdateMirages(); 
} 
break; 
case MT_Destroy: 
{ 
    for (std::vector<entity_id_t>::iterator it = m_Mirages.begin(); it < m_Mirages.end(); ++it) 
    { 
        CmpPtr<ICmpMirage> cmpMirage(GetSimContext(), *it); 
        if (cmpMirage) 
            cmpMirage->SetParent(INVALID_ENTITY); 
    } 
} 
break; 
} 

While according to the coding conventions it should be:

switch (msg.GetType()) 
{ 
case MT_Update: 
    UpdateMirages(); 
    break; 
case MT_Destroy: 
    for (std::vector<entity_id_t>::iterator it = m_Mirages.begin(); it < m_Mirages.end(); ++it) 
    { 
        CmpPtr<ICmpMirage> cmpMirage(GetSimContext(), *it); 
        if (cmpMirage) 
            cmpMirage->SetParent(INVALID_ENTITY); 
    } 
    break; 
} 
  • Nothing seems to have actually changed besides breaking commented out code in CCmpUnitRenderer.cpp?
    • source/simulation2/components/CCmpUnitRenderer.cpp

       
      2222
      2323#include "simulation2/MessageTypes.h"
      2424
       25#include "ICmpFogging.h"
      2526#include "ICmpPosition.h"
      2627#include "ICmpRangeManager.h"
      2728#include "ICmpSelectable.h"
       
      374375        CmpPtr<ICmpVision> cmpVision(unit.entity);
      375376        if (cmpVision && cmpVision->GetAlwaysVisible())
      376377            unit.visibility = ICmpRangeManager::VIS_VISIBLE;
       378
       379        // Uncomment the following two lines to prevent the models from popping into existence
       380        // near the LOS boundary. Is rather resource intensive.
       381        //else if (cmpVision && cmpVision->GetRetainInFog())
       382        //  unit.visibility = ICmpRangeManager::VIS_VISIBLE;
       383
      377384        else
      378385        {
      379386            CmpPtr<ICmpRangeManager> cmpRangeManager(GetSystemEntity());
      380             // Uncomment the following lines to prevent the models from popping into existence
      381             // near the LOS boundary. Is rather resource intensive.
      382             //if (cmpVision->GetRetainInFog())
      383             //  unit.visibility = ICmpRangeManager::VIS_VISIBLE;
      384             //else
      385                 unit.visibility = cmpRangeManager->GetLosVisibility(unit.entity,
      386                     GetSimContext().GetCurrentDisplayedPlayer());
       387            unit.visibility = cmpRangeManager->GetLosVisibility(unit.entity,
       388                GetSimContext().GetCurrentDisplayedPlayer());
      387389        }
      388390    }
      389391    else
  • You might want to check you updated the copyright year in all the files you modified, but otherwise it looks good stylistically.

comment:40 by Itms, 10 years ago

Thanks again Josh! Actually, when uncommented, the UnitRenderer code failed when cmpVision didn't exist. But after some changes in my patch, this is indeed a bugfix independent of the fogging system.

This version of the patch includes fogging of Gaia entities and I cleaned up some parts of the code. Please make comments about the functionality!

by Itms, 10 years ago

Attachment: fogging.patch added

comment:41 by Itms, 10 years ago

Hey! I am struggling with the range manager for the optimization system. Above is a wip partial patch I upload, just to be able to discuss this on IRC right now.

EDIT: I'll eventually revert all my awful changes and work on a general-use system of visibility updates. Such messages might also be useful for other systems like UnitAI.

Last edited 10 years ago by Itms (previous) (diff)

comment:42 by Itms, 10 years ago

This is a patch adding the VisibilityChanged message. I haven't really tested it yet, but it seems to work in a game without AI enemy.

comment:43 by Itms, 10 years ago

This is a new version of my patch, addressing a big oversight and serialization issues.

However, it does not work as expected, so I've still work to do on it. In the meantime, my fogging patch can still be reviewed!

comment:44 by Itms, 10 years ago

This is, finally, the working version of my patch! Thanks a lot to Philip` for his help on IRC, along with Josh, leper and sanderd17.

I updated my fogging system accordingly and I upload a complete patch merging the two systems. Please share your thoughts :)

Possible ameliorations: write tests (not sure what is worth testing) and avoid the temporary vanishing of miraged entities. I have a system in mind to implement this, but I don't know if it is really necessary?..

by Itms, 10 years ago

Attachment: update_visibility.patch added

by Itms, 10 years ago

Attachment: fogging+optimization.patch added

by wraitii, 10 years ago

Attachment: graphs.png added

Graph of how much the update_visibility patch affects performance.

comment:45 by Itms, 10 years ago

In 15508:

Add a VisibilityChanged message sent by the range manager whenever an entity changes visibility for any player.

This will be necessary for hiding buildings/trees/etc in fog-of-war, and may be useful for AIs and for UnitAI.

Refs #599.

comment:46 by Itms, 10 years ago

Keywords: review removed

I decided to script the Fogging component to allow access to Health components and so on. This patch does not change the functionality, it is just the same rewritten system.

Also, the patch is regenerated to be applicable to r15508.

comment:47 by Itms, 10 years ago

With this version, the disappearing problem doesn't occur anymore!

I still have some work to do about mirage information, such as health, resource supplying, and so on. I decided not to add these components, because that breaks parts of the simulation logic (UnitAI tries to gather from mirages, etc.)

I'll add interesting, GUI-oriented data to the Mirage component itself in the next version of the patch, and then this should be ready for a new review.

comment:48 by Itms, 10 years ago

This is the fully functional version of the patch!

I should have tested most of the possibilities, however I'm not sure how this will behave when toggling "reveal map".

Thanks for testing, please share your thoughts!

comment:49 by Itms, 10 years ago

Keywords: review added

comment:50 by wraitii, 10 years ago

Compiled nicely, works in most cases, some instances where it doesn't:

-if you place a foundation in fogged territory and it gets destroyed, you immediately know about it being destroyed. You shouldn't.

-If you order units to work on a fogged resource, and select that resource, you will lose selection focus when the resource becomes fogged. The GUI doesn't switch you to the miraged entity. Interestingly this only happens in Real->Mirage, because Mirage->Real switches properly.

-Trying to build over a fogged (invisible) entity does not work. This is probably because the obstruction map isn't updated per player or something, I'm not sure. However this should be fixed, since it can allow you to know where the enemy has expanded (though so far we also have territory borders, but that's unrelated). OTOH, you can build over mirages, since they have no obstruction.

-Territory expansion doesn't reveal entities. If you phase up, you won't see any entity in your newly fogged territory, when you probably should. It's probably because you only create mirages if entities fo from "hidden" to "visible", but "hidden" to "fogged" needs to be considered as well. This is also true of entities in fogged territory at the beginning of a game.

It seems however that proxy entities do not affect distance restrictions or things like that (ie if you build a CC, an enemy sees it, and you destroy it, and the enemy doesn't know about that, the proxy doesn't affect the "distance between CC"). So that's good.

Reveal Map changes nothing to the state of fogging, ie you return to what you should know, which in the end I'm fairly OK with.

The first issue should be an easy fix and needs to be. The second is annoying and should be fixed, sounds easy enough. The third issue isn't too bad, it's a complicated problem that we could imo live with for the time being (and it seems not too distant from the territory border issue so maybe you could fix both). It's already better than what we have now, and it doesn't stem imo from a fundamental design flaw in the patch. The fourth is possibly more annoying code wise but it's needed imo, even if we need special code to handle that.

I'll comment on the code itself later.

comment:51 by Itms, 10 years ago

First issue solved :)

Also some commented out, forgotten code removed.

Last edited 10 years ago by Itms (previous) (diff)

by Itms, 10 years ago

Attachment: fogging_scripted.patch added

comment:52 by Itms, 10 years ago

In 15538:

Recompute the number of LoS tiles whenever these tiles are reset (especially when loading serialized data).
Also add a verification about LoS tiles in the tests.

Fixes #2678
Refs #599

comment:53 by Itms, 10 years ago

In 15563:

Some changes on the VisibilityUpdate message system, aimed at correcting recent OOS problems.
I still experience troubles with serialization tests but I played a few games without OOS. At least these changes will help us to debug more efficiently the remaining problems.

Fixes initialization of visibility data and update order for LoS-related systems (territory borders, etc).
Also removes a C-like array and fixes a player ID shifting.

Refs #599

comment:54 by Itms, 10 years ago

Corrected some little problems. I created a branch here: https://github.com/na-Itms/0ad/tree/fogging to make it easier to develop, and I post the global patch here.

Please share your opinion. :)

comment:55 by Itms, 10 years ago

I generate a svn patch from the branch I linked above. I think this version is a release candidate, so don't hesitate to test it!

comment:56 by Itms, 10 years ago

Latest version of the patch, ready to be committed.

by Itms, 10 years ago

Attachment: fogging.diff added

comment:57 by Itms, 10 years ago

Resolution: fixed
Status: newclosed

In 15612:

Hide changes to buildings in the fog-of-war.

To achieve this, mirage entities are created per player, to replace the real entities when these ones fall into the fog-of-war. These mirage entities are created on-the-fly, and destroyed when they get back in sight.
This depends heavily on the VisibilityChanged message added in r15508.

As a temporary adjustment, territories do not explore the map anymore when their borders change. See #2709.

Fixes #599

comment:58 by Itms, 10 years ago

Cc: Josh Matthews removed
Keywords: review patch removed
Note: See TracTickets for help on using tickets.