I finished and commited back to trunk the "multiple fake units" subtask. I
haven't deleted the branch (branches/gabba_ghosted_units/) yet since if you
do a checkout of it at revision 42463, you'll get to see my testing hack. I
put that in the branch to check that multiple fake units work well: every
time a unit moves, it leaves a fake, petrified copy of itself behind.
Alternatively you can just apply the following patch (generated with git
diff) to trunk to get the same testing hack:
---------------------START PATCH------------------------------
diff --git a/src/unit_display.cpp b/src/unit_display.cpp
index 0fa6d24..c18b852 100644
--- a/src/unit_display.cpp
+++ b/src/unit_display.cpp
@@ -118,6 +118,16 @@ void move_unit(const std::vector<map_location>& path,
unit& u,
map_location::DIRECTION dir)
{
game_display* disp = game_display::get_singleton();
+
+
/********************************************************************/
+ /* Silly hack to test multiple fake units
+ * When moving, each unit leaves a petrified statue of itself
behind.
+ */
+ unit* test_unit = new unit(u);
+ test_unit->set_state(unit::STATE_PETRIFIED, true);
+ disp->place_temporary_unit(test_unit);
+
/********************************************************************/
+
assert(!path.empty());
assert(disp);
if(!disp || disp->video().update_locked() || disp->video().faked())
-----------------------------END PATCH------------------------------
Please take a look and tell me what you think. I wasn't sure about exposing
the deque or not, and whether to make it read-only, so your comments on this
are particularly welcome.
2010/4/30 jeremy rosen <jeremy.ro...@enst-bretagne.fr>
> On Fri, Apr 30, 2010 at 9:03 AM, Gabriel Morin <gabrielmo...@gmail.com>
> wrote:
> > Alright Boucman, here's my plan for friday and next week:
> >
> > 1. Create an svn branch and track it with git-svn. I spend a lot of time
> > today learning git and git-svn, and the learning curve is steep, so I'm
> not
> > sure how much of friday is gonna be eaten by this. (Example: I wanted to
> > have separate git working directories for tracking trunk and 1.8, without
> > constantly switching between those and doing a rebuild. And without
> copying
> > the whole 1.7 GB for nothing. Turns out there are several
> badly-documented
> > ways to do this, but finding the little git-provided script that does it
> in
> > an efficient way took way too much searching.)
> >
>
> ok, fair enough,
>
> > 2. Start on the "multiple fake units" small coding task. Once that's
> > started, I'll dcommit to the svn branch regularly so you can see my
> > progress, once a day is a good target I think.
> > Can I use simply the location of the fake unit as the "key" to find it,
> or
> > do I need to support multiple fake units per hex?
> >
> i'm afraid you do, for instance if a unit moves through a hex occupied
> by a shadow unit, we would have two fake units in the same hex during
> the crossing
>
> > 3. As soon as the feature is pretty complete, (carefully) merge back the
> > branch into trunk with the help of git-svn. I'll try to finish this by
> > wednesday.
> >
>
> ok, sounds good
>
> > 4. Implement the arrow drawing engine/framework; at Crab's demand I'll
> make
> > it pretty generic and accessible from anywhere in the program, so that
> > anybody can create arrows with a specific style, get a pointer to them
> (do
> > you suggest some smart Boost pointer for this?),
>
> hmm, I hadn't thought of doing a "generic arrow drawing" code...
> sounds like a good idea,
> vocabulary :
> * owner : the code that knows what the arrow is for and is asking the
> engine to draw it
>
> here are a couple of thoughts on the subject
> 1) smart-pointer or not, that's an implementation detail, so why not.
> Let's see if that's what we need. We will find a sort of "key" for the
> owner of the arrow to be able to find back his arrow in order to
> modify/delete it, and smart pointer is a way to do it...
>
> 2) at what logical level do you want your arrows to be... if it's
> unit+src+dst then the pathfinding is under the responsability of the
> arrow engine. That makes a simpler usage for the owner, but limits
> what the owner can do to describing unit movements only
>
> if you register "an array of hex" then you will have problems with
> arrow continuity and things like that...
>
> 3) it would be tempting to expose the arrow engine to WML at some
> point. Which means we would need to define a bit more what is an arrow
> style, is it limited to recoloring ? can you provide a whole new set
> of arrow image, in which case you need to add and parse the WML to
> find these images somewhere...
>
> 4) what about "special places" like teleports in arrows
>
> > modify them and eventually
> > delete them. The point is that after you've added them, they're added to
> the
> > right layer at the right time and you needn't worry about the details.
>
> > It may make sense to make displaying fake units available in a similar
> way,
> > I'll know more about the specifics when I'll have implemented them.
> >
> not sure what you mean... the fake unit is already available to
> anybody... the problem is that it's very limited, but it's already
> used by multiple owners.
>
> but yes, the fake unit should stay available in a generic way
>
> > 5. Implement PlannedActionSet (with an exposed deque ;) ); the
> PlannedAction
> > class will at first contain just enough info to define arrows. Then use
> the
> > arrow-drawing framework to display those and follow updates to the
> planned
> > moves.
> >
> > You'll probably be back before I finish point #5 since I'll have my
> summer
> > course at the same time.
> >
>
> indeed. I will probably be. Take some time to think a clean API for
> your arrow engine, it is indeed a usefull subproject, and merging
> keeping it cleanly separated from the underlying whiteboard is a good
> thing
>
> > 2010/4/28 jeremy rosen <jeremy.ro...@enst-bretagne.fr>
> >>
> >> This all sounds good, i agree with your conclusion wrt data structures
> >> vs config.
> >>
> >> I'll post a few comments about the data structures themselves
> >>
> >> note that these are general comments on some things you might not have
> >> thought of yet, or not put in your diagram for simplification purpose.
> >> If that the case, that's perfectly fine just tell me so
> >>
> >> PlannedActionSet
> >> * to have a getChanges, you need to somehow know "since when" either
> >> as a param to getChange or an internal data from the
> >> Planned ActionSet => this is probably a "not looking at the details of
> >> network management yet" problem, and I totally agree with that
> >> * std::vectors have much more than just get and set actions, stuff
> >> like iterators are very handy... will the internal vector be exposed ?
> >> or do you plan to reimplemnt the iterator routines (drawing will need
> >> to iterate on the vector) an other way to do it would be to inherit
> >> from vector instead of having an internal one (or simply use a vector
> >> without any wrapping if none is needed)
> >>
> >> ConflictSet
> >> *same question about std::vector
> >>
> >> Planned*
> >> *you probably want an inherited draw() routine rather than all sorts
> >> of drawGhost,drawPath, thus you would just have to iterate on the
> >> PlannedActionSet to do the drawing. This draw will probably take a hex
> >> as parameter (the hex to redraw) (just mentionning that last point
> >> since you havn't put your function params in)
> >> *related : some of your classes should probably contain some cached
> >> pathfinding results
> >> *i'm at work so I can't check, but if units contain their own
> >> position, you don't need to store the start position on a move
> >> *if they don't contain their start position, then you should probably
> >> store the targeted hex in the PlannedAttack rather than the targeted
> >> unit (maybe both)
> >>
> >> Conflict
> >> * I assume that "type" will become an enum at some point, once we have
> >> a good idea of all the types of conflict. Will their be some class
> >> hierarchy of conflict types ?
> >>
> >>
> >> SMALL CODING TASK : MULTIPLE FAKE UNITS
> >> this is a task that you will need, which is independant of your
> >> project, and that you can commit directly to mainline once done. It
> >> will also help you get familiar with the display engine
> >>
> >> The game has a hard limit of one and only one unit per hex.
> >>
> >> However, there are cases where we need to draw more than one unit in a
> >> given hex (typically when a unit moves through an occupied hex) To do
> >> that, the display engine (in the display or game_display class, i'm
> >> not sure) keeps a unit object and a location object, which represent
> >> the "fake unit" it basically says "there is an extra unit in hex XX"
> >>
> >> the problem is that the engine directly keeps a single unit that way,
> >> which means that there can only be a single fake unit
> >>
> >> With your ghosted units, you will need to draw more than one of these
> >> units, so your task is to allow the engine to have multiple such
> >> units, probably using a set of pair<unit,loc> or something like that
> >>
> >> keep in mind that you will need a "key" to somehow allow people to
> >> find their fake unit within the multiple units
> >>
> >> we'll discuss this whenever we meet on IRC, but you can have a look
> right
> >> away
> >>
> >> _______________________________________________
> >> Wesnoth-dev mailing list
> >> Wesnoth-dev@gna.org
> >> https://mail.gna.org/listinfo/wesnoth-dev
> >
> >
> > _______________________________________________
> > Wesnoth-dev mailing list
> > Wesnoth-dev@gna.org
> > https://mail.gna.org/listinfo/wesnoth-dev
> >
> >
>
> _______________________________________________
> Wesnoth-dev mailing list
> Wesnoth-dev@gna.org
> https://mail.gna.org/listinfo/wesnoth-dev
>
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
