About 3 years ago tobi wrote functionality to allow ingame alliances to one-directionally share LoS by using /ally [0|1|2] (not allied, allied no los, allied w/ los, respectively). I'd really like to make use of alliances that had asymmetric LoS sharing, and the set of changes looked fairly small and manageable, so I tried rebasing losshare on develop.
So far: I have worked through all of the merge conflicts without any major silliness, and redistributed the logic that used to be in Game.cpp into the appropriate places. However, I have two questions.
1) Been trying to build, and realized that the MergedLosMap class (which is meant to be polymorphic with LosMap) has methods AddMapSquares and AddMapArea which don't take allyTeam (and indeed, it doesn't make sense for it to take allyTeam - this is a los map shared by two allyTeams).
However, the normal LosMap class methods for AddMapSquares and AddMapArea expect allyTeam as a param. It is only used when a USE_UNSYNCED_HEIGHTMAP flag is triggered. What's the best way to resolve the breakdown in polymorphism here?
2) LosMap's SetSize method takes a boolean for SendReadmapEvents. I honestly don't know what that does. LosHandler.cpp 92-93 sets it to true for normal LoS and false for AirLos. Is it safe to assume that it'll always be true for normal and false for AirLos when SetSize is called from elsewhere? For example, in losshare branch: LosHandler.cpp 285/291).
Thanks!
Merging tobi's losshare branch into develop
Moderator: Moderators
Re: Merging tobi's losshare branch into develop
1) just let MergedLosMap::AddMap* take an allyteam argument too, but eg. cast it to void to explicitly mark the parameter as unused
2) yes
2) yes
Last edited by Kloot on 17 Oct 2012, 00:41, edited 1 time in total.
Re: Merging tobi's losshare branch into develop
Update - it works...sort of. I managed to merge latest develop with losshare and get it more or less functioning, but there's an issue where shared LoS segments don't update spatially when the allied units move. They retain LoS of a fixed position, even if the units from the LoS-sharing team have gone elsewhere. Normal LoS is unaffected.
Awesome, thanks kloot. I did that (minus casting it as void), and realized it isn't actually unused because CMergedLosMap AddMapSquares then calls CLosMap AddMapSquares, which needs it.
Here it is: https://github.com/kanatohodets/spring/tree/losshare
Awesome, thanks kloot. I did that (minus casting it as void), and realized it isn't actually unused because CMergedLosMap AddMapSquares then calls CLosMap AddMapSquares, which needs it.
Here it is: https://github.com/kanatohodets/spring/tree/losshare
Re: Merging tobi's losshare branch into develop
Update again: either I somehow totally broke tobi's code while resolving merge conflicts, or he wasn't quite finished with it. There are a few weird things that happen at the moment.
Situation: Player A (allyTeam 0) and Player B (allyTeam 1). Player A types /ally 1 2.
What happens: Player B gets LoS on player A's current position. However:
1) The previously mentioned non-updating of LoS. When team A shares LoS to team B, team B's los stops updating on movement of any units (their own or the newly allied ones).
2) In that situation, team A (the team that just shared LoS) now gets full LoS from both teams! which updates on unit movement! but they weren't supposed to get it. Also, when Team A stops sharing LoS to team B, they retain fixed spots on the map where they have sight, unattached to any unit.
I'm not really sure how a team's allyteam is affected when ingame-alliances are created, so maybe there's something funky there. Perhaps (hypotheticals on hypotheticals) something to do with AddMapSquares/Area taking an allyTeam that doesn't make sense in the context of a LoS map shared amongst allyteams.
Situation: Player A (allyTeam 0) and Player B (allyTeam 1). Player A types /ally 1 2.
What happens: Player B gets LoS on player A's current position. However:
1) The previously mentioned non-updating of LoS. When team A shares LoS to team B, team B's los stops updating on movement of any units (their own or the newly allied ones).
2) In that situation, team A (the team that just shared LoS) now gets full LoS from both teams! which updates on unit movement! but they weren't supposed to get it. Also, when Team A stops sharing LoS to team B, they retain fixed spots on the map where they have sight, unattached to any unit.
I'm not really sure how a team's allyteam is affected when ingame-alliances are created, so maybe there's something funky there. Perhaps (hypotheticals on hypotheticals) something to do with AddMapSquares/Area taking an allyTeam that doesn't make sense in the context of a LoS map shared amongst allyteams.
Re: Merging tobi's losshare branch into develop
did you ask tobi about that?Nemo wrote:or he wasn't quite finished with it
i guess there is a reason why it isn't / wasn't merged...
Re: Merging tobi's losshare branch into develop
I don't think I've seen those issues. Actually I think they weren't present in the branch back when I made it. No guarantees though
I think I didn't merge it because I wanted to optimize the case of sharing symmetrically (in both directions) a bit more and because it could use some more testing.
Sorry for abandoning that branch btw...
I think I didn't merge it because I wanted to optimize the case of sharing symmetrically (in both directions) a bit more and because it could use some more testing.
Sorry for abandoning that branch btw...