Re: How to continue

[David Philippi]

On Tuesday 11 June 2002 16:07, Ingo Ruhnke wrote:
> 'make CXXFLAGS="-s"' was always enough for me, since that speeds up
> the final link dramatically. Changing something in WorldObj.hh,

The final link is very fast for me - at least as long as I omit using -g.

> One doesn't really needs to understand the whole thing. When you want
> to fix an action, you basically just have to go to
> src/actions/your_broken_action.cc, to fix a background, goto
> src/backgrounds/, etc. There a few issues which needs global tweaking,
> but there are also a lot of issues which just involes editing one or
> two files.

Well, at least I've got to understand the global concept. I don't know how 
the different components interact with the world. Without this knowledge I 
won't know what to do at all.

> I don't know much about ClanGUI in generall, but what we need for
> Pingus is basically a preferences dialog for each object types where
> one can edit the objects properties, like release rate for the
> entrance or owner_id for the exit. The dialog might basically just a
> varible-value list. Not sure how exactly that should be integrated in
> the editor, but something like adding a get_property_dialog() to the
> EditorObj class and then adding that property dialog to some dialog
> manager class might be working. Rewriting some parts of the Editor to
> become a real ClanGUI component would also be possible, but would
> involve quite a bit more work.

I'll try to get some sense out of the source. My problem is, that I've never 
ever programmed any GUI - I don't know how they work. All I know is some 
documentation I've read about the Java GUI.

> The complicated part is basically to get the design right and
> implemented correctly, since this would involve the ripout and
> rewrite/rearange of quite a few classes in Pingus. One could also just
> hook the recording up into Server.cc, which would be quite a lot more
> easy, but as the whole Client/Server thing isn't really that clean at
> the moment one might need to fix a few issues there.

Doing it via mail is a bit difficult, but it shouldn't be impossible:
Try to give me as much details of what's to do and I'll try to create a basic 
design of the classes and post it. Then you can tell me what's wrong with it 
and we may keep changing it until it sounds good.
I've got a few books about software patterns and design standing just behind 
me, so you may guess that I've spent some time with learning how to do 
software design. Let's try wheter I can find a solution to this problem. 
Implementing it afterwards should be the easy part if the design is done 
well.

> Yep, you can do all things in pause mode that you can also do in
> non-pause mode. Turning that off isn't a problem, but thats not what I
> want. I want something like a limited pause mode, which allows one to
> do precise applying of an action to a pingu, but not without going to
> a complete freeze of the gameplay at that time.

Hmmm... not much clearer then before. If you want to allow precise applying 
of an action, you've got to stop every pingu, right? So what is there not to 
be stopped? Animations of other parts? 

> We have the ColMap, which is used for pingu<->ground collison
> (basically PinguAction::rel_get_pixel()). We have the GfxMap, which is
> what one sees on the screen. They are seperate so that one can use gfx
> effects without influencing the pingus behaviour.

This means that objects inserted into the GfxMap aren't physical in respect 
to a pingu so one may e.g. have rain in the background or suchlike?

> The problem that pingus get stuck results basically from an incorrect
> collision checking and from the more complex interaction of actions.
> Unifying the collision checking might help, but in the end I guess
> this will be pure try and error to get the actions fine tuned against
> each other.

If you don't want to go the mathematical way this may very well be the case. 
But I think doing it by try and error will be less work in the end.

> An example would be a bridger which walks towards a wall, collides
> with the wall and turns back into a walker, but as the bridger as
> walked already 'into' the wall, the walker action now gets stuck.

You mean that the bridger actually walks "into" the wall while the walker 
would have changed it's direction if a step forward would result in a 
collision? If so, the solution would probably be that if the bridger changes 
back into a walker because of a collision, the walker should be initialized 
with the opposite direction, right?

Bye David