Something not too hard to develop

[Bertram]

I've shown the final result here:
viewtopic.php?p=56912#p56912

[hwoarangmy]

More importantly, it was fun to see the kind of window frame you were using

As it is a static popup, I found it logic to not hard code it (so it is easier to change). If you prefer, you can change it

I do think we should use a more common background and size for this pop-up

Fill free to change whatever you think is better.

Dont be mean and show hmw's pop up screen. Im all intrigued

I just used the main menu picture (which is nice btw) with alpha 0.5 for the popup. It was to not have a black background and was not too bad looking

[paul424]

Well , what I can suggest you to do from the impact , you could implemnt game speedometer / accelerator ....
That one can play the game from very slow ( x 0.01 ) upto ( x100) .

[Bertram]

Hi hwoarangmy,

Well, I must say I changed a few things and I hope you won't mind.
I guess the next goal is to create a nice looking modal window frame and use it all along the inner GUI windows we will have to add.

Feel free to tweak anything I may have changed to make it look better.

Best regards,

[hwoarangmy]

Dont be mean and show hmw's pop up screen. Im all intrigued

See how it is nicer than Bertram's

[Bertram]

Eh eh.
I don't want to start a finer pop-up challenge. (I fear losing too much ;])
Note that whatever is decided about this pop-up, the text should centered as I did in the new one, and the frame line should be hidden (by setting the FrameEnabled parameter to false.)
Anyway, I do think we need to setup a common modal window skin and use it for all the menu GUI.

Would you guys be against reusing the tab window skin for that?

[paul424]

Well , what I can suggest you to do from the impact , you could implemnt game speedometer / accelerator ....
That one can play the game from very slow ( x 0.01 ) upto ( x100) .

Anyway hwa, what do you think of my proposal ? Increasing the code funcitonaliuty IS ALWAYS WAY BETTER THAN POLISHING details of exisiting things IMHO.
Also if you could make some commands for console -- like gameplaypause, gameplayresume. The CONSOLE tries to be the main gate for modifing game program during program run imho. Ahh also -- the game runs forwad ( ignores the pause ) when you open console ( the '~' button ). Could you fix that as well ?
What do you think of finishing that ? ( Bertarm Pshhh !!)
hwoarangmy , also why do you have such difficult nickname ?

[Bertram]

Increasing the code funcitonaliuty IS ALWAYS WAY BETTER THAN POLISHING details

Eh eh. Depends on how the details are hurting the overall gameplay.

[hwoarangmy]

I don't want to start a finer pop-up challenge. (I fear losing too much ;])

No worries, I was joking

Note that whatever is decided about this pop-up, the text should centered as I did in the new one, and the frame line should be hidden (by setting the FrameEnabled parameter to false.)

I tried to center text but it didn't work on static text. And I didn't want to spend too much time on this. But I agree it is better

Anyway, I do think we need to setup a common modal window skin and use it for all the menu GUI.

I agree

Anyway hwa, what do you think of my proposal ?

I think it is interesting to change the timespeed. Even if 0.01 to 100 seems too much

Increasing the code funcitonaliuty IS ALWAYS WAY BETTER THAN POLISHING details of exisiting things IMHO.

It depends on what you call a detail. IMHO, a game that crashes when you quit or that crashes when you start a second game is a detail that deserves to be investigated

hwoarangmy , also why do you have such difficult nickname ?

:)

Concerning the crash when quiting, I have found what was going on. When the GameMap is cleared , the creatures are deleted but when the server notification queue is not empty, it keeps some references to the deleted creatures. I am currently trying to start 2 consecutive games.

Concernning setting the GameMap into the GameMode, I have tried but there are some problems. Why is the console a game mode ? What is the expected behaviour when it is displayed ?

[paul424]

No, that was the foolish way of naming some mechanism ,
Actaually what is Game, Editor, Console, etc modes is large and by just an INPUT MODE for INTERPRETING keyboard and mouse strokes , it was never planned to be nothing less or more .... the idea was mine to name it after vim MODS . And before split it was called InputManager .
So ... if you have the venue, you could propose some less fooling names <:@) .

[Bertram]

Hi guys,

I tried to center text but it didn't work on static text. And I didn't want to spend too much time on this. But I agree it is better

For the record, and just in case, I simply changed the text absolute position, to box scaling: See the 0.1 - 0.9 = % of the parent window, for instance.

{l Code}: {l Select All Code}

<Property name="Area" value="{{0.1,0},{0.1,0},{0.9,0},{0.4,0}}" />

Hope it will help you with possible further changes there or elsewhere.

Concerning the crash when quiting, I have found what was going on. When the GameMap is cleared , the creatures are deleted but when the server notification queue is not empty, it keeps some references to the deleted creatures. I am currently trying to start 2 consecutive games.

Interesting. Do you think it's possible to clear the server queue in that case? (And maybe send a server close packet to the clients?)

Concernning setting the GameMap into the GameMode, I have tried but there are some problems.

Well, that change alone isn't easy IMHO. If we can avoid crashes for now, it's already a victory though. Let's have a go with that later, when the design change will be a pre-requisite to some feature, like displaying a map mode, or selecting a level before starting it, for instance.

Why is the console a game mode ? What is the expected behaviour when it is displayed ?

It's a good question. Application modes were at first used only to grab input and handle it, as Paul said above. That's why the console was only ported as an application mode since the code was there.
Afterwards, I turned the application modes into, well, fuller application modes, handling graphics and updates as well, because it permits to let each application mode to handle its own music, video features, input of course, and every custom things each mode needs, without adding workaround in each manager, which was rather ugly and hard to maintain.
I guess you've seen that.

The console "mode" is already an hybrid in term of design since it's a hollow mode containing the console itself and handling input activation/deactivation for it.
I don't think it would hurt if one turned this into a true common component of the Mode Manager, as the work is 3/4 done already. It's up to you to decide about what suits you the best for your own needs.

Now, as Paul rightly said, making the game pause when you open the console is a good idea, but only IF the game app is the server. In a multiplayer game where you are a client, you shouldn't be able to stop the game by opening the console, and maybe the server should send a pause packet to clients? (It's already so cool to be able to pause the game by pressing esc, btw.)

Regards,

[hwoarangmy]

Hope it will help you with possible further changes there or elsewhere.

Thanks

Interesting. Do you think it's possible to clear the server queue in that case? (And maybe send a server close packet to the clients?)

For a dirty workaround, that's what I have done and it doesn't crash anymore. But before I upload it, I will try something better to make sure no new message is accepted when quiting. And I have already seen that the same thing is going on when you start 2 consecutive games (but it might not be the only reason why the application crashes).

Well, that change alone isn't easy IMHO. If we can avoid crashes for now, it's already a victory though. Let's have a go with that later, when the design change will be a pre-requisite to some feature, like displaying a map mode, or selecting a level before starting it, for instance.

Ok. But IMHO, it could be good to decide the architecture we are aiming for because if we don't, we will keep adding dirty hacks because we have no choice due to the implementation. BTW, I have seen code about server/client. But from what I have seen, I don't get how it can work. Is it really possible to play multiplayer yet ? If yes, is there a way to test ?

It's a good question. Application modes were at first used only to grab input and handle it, as Paul said above. That's why the console was only ported as an application mode since the code was there.
Afterwards, I turned the application modes into, well, fuller application modes, handling graphics and updates as well, because it permits to let each application mode to handle its own music, video features, input of course, and every custom things each mode needs, without adding workaround in each manager, which was rather ugly and hard to maintain.
I guess you've seen that.

Yes and that's not a bad idea but if I am not mistaken, Modes are expected to be used exclusively (not at the same time). But when I moved the GameMap to the GameMode, I added dome bridge to make the ODFrameListener refresh the GameMap through the Mode (editor or Game) in an object way. But when the console is opened, the GameMode is not active anymore and the GameMap is not refreshed (so it is paused as requested ). But that's not the current behaviour...

Now, as Paul rightly said, making the game pause when you open the console is a good idea, but only IF the game app is the server. In a multiplayer game where you are a client, you shouldn't be able to stop the game by opening the console, and maybe the server should send a pause packet to clients? (It's already so cool to be able to pause the game by pressing esc, btw.)

Again, is it possible to test multiplayer ? I don't like to upload untested updates...

Talking about implementation, I think it would be a good point to have the same behaviour when playing multiplayer or single player. When playing single player, it would be like having a server with only one client (but that uses sockets just like the other players). The good point with this implementation is that when single player works, multiplayer is very likely to work too.
And it would be even better if there was some kind of validation from the server. For example, as it is now, when you clic on a creature, you pick it up and notify the server that you picked it up (and then, the clients will be informed). It could be nice to start by asking the server if you can pick up a creature and wait for his message saying that you picked it up. Because as the game is now, it will be really a mess during multiplayer games when the server will receive from 3 different clients that the same creature got killed or that the same ressources have been harvested.
And about the console, it would be much simpler since most of its command would just be sending the correct message to the server.

[Bertram]

Hi hwoarangmy,

I added dome bridge to make the ODFrameListener refresh the GameMap through the Mode

Sounds good. You mean something roughly like this?
in ODFrameListener:

{l Code}: {l Select All Code}

if (mode != NULL && mode->getGameMap() != NULL)
    mode->getGameMap()->doSomething()

Ok. But IMHO, it could be good to decide the architecture we are aiming for because if we don't, we will keep adding dirty hacks because we have no choice due to the implementation.

Well, if you need some decision about this, I'm strongly sure about the fact that game modes should be full application modes as it is mostly the case already, and that, at some point, the console should be become a independent common component of all game modes.

Also, I'm also sure the game map should become a component of certain application modes, but not all, not in the main menu mode, or a future world map mode/campaign mode, for instance.
By design, this will force us to have a clear memory management about that area.

Talking about implementation, I think it would be a good point to have the same behaviour when playing multiplayer or single player. When playing single player, it would be like having a server with only one client (but that uses sockets just like the other players). The good point with this implementation is that when single player works, multiplayer is very likely to work too.
And it would be even better if there was some kind of validation from the server. For example, as it is now, when you clic on a creature, you pick it up and notify the server that you picked it up (and then, the clients will be informed). It could be nice to start by asking the server if you can pick up a creature and wait for his message saying that you picked it up. Because as the game is now, it will be really a mess during multiplayer games when the server will receive from 3 different clients that the same creature got killed or that the same ressources have been harvested.
And about the console, it would be much simpler since most of its command would just be sending the correct message to the server.

A client/server paradigm, indeed. I'm sure I wrote something very similar on the forums and in the wiki TODO list. So I guess we agree completely on the way to go.
You have my full support about this design which was more or less what was being aimed at, even before we both fell on this project.

Again, is it possible to test multiplayer ? I don't like to upload untested updates...

Well, it would "almost" work but there are several big things in the way:
1. According to the wiki TODO list, the server new client socket listening function is using basic sockets making it a blocking/never-returning one until a new client comes.
It's the only regression we have from before removing all the broken threading code. To fix this, we should switch from sockets to SFML net for client/server packets sending/receiving.
https://github.com/Bertram25/OpenDungeo ... er.cpp#L57
^ Here you can see I added a return since the socket->accept() function is returning only when one client is connecting.

2. The level file has got only one player seat:
https://github.com/Bertram25/OpenDungeo ... e.cpp#L103
^ Here you can see that the local player has got the first "Player" Seat. To add an available client slot, you would have to change a "KeeperAI" seat slot to "Player" in the TestLevel.level file.
Then, you should be able to try multiplayer by running another app instance (with the exact same level file.), click on new game, and in the console, type: connect <server-ip>
Plus, I'm sure it won't be far from perfect.

As you may have guessed, there is still a lot to do before having some nice multiplayer games between us.

Regards,

[hwoarangmy]

Sounds good. You mean something roughly like this?

I mean, in ODFrameListener, instead of

{l Code}: {l Select All Code}

mGameMap->doTurn();

, doing

{l Code}: {l Select All Code}

mModeManager->getCurrentMode()->doTurn()

And letting the mode responsible of doing something (or not). Technically, I added a virtual empty method that was overwritten for GameMode and EditorMode.

Well, if you need some decision about this, I'm strongly sure about the fact that game modes should be full application modes as it is mostly the case already, and that, at some point, the console should be become a independent common component of all game modes.

Yes, since the console is supposed to impact GameMode, I don't see how it can be a mode itself (otherwise, it would break the modeManager model having to act on another mode than the last in the vector). And btw, all the specific code for console in the modeManager is enough for me to tell that it is not the best place to fit
That's why I cannot upload my changes. The console would not work when the GameMap is inside the other modes (except by using the dirty hacks I was talking before).

Well, it would "almost" work but there are several big things in the way:
1. According to the wiki TODO list, the server new client socket listening function is using basic sockets making it a blocking/never-returning one until a new client comes.
It's the only regression we have from before removing all the broken threading code. To fix this, we should switch from sockets to SFML net for client/server packets sending/receiving.
https://github.com/Bertram25/OpenDungeo ... er.cpp#L57
^ Here you can see I added a return since the socket->accept() function is returning only when one client is connecting.

2. The level file has got only one player seat:
https://github.com/Bertram25/OpenDungeo ... e.cpp#L103
^ Here you can see that the local player has got the first "Player" Seat. To add an available client slot, you would have to change a "KeeperAI" seat slot to "Player" in the TestLevel.level file.
Then, you should be able to try multiplayer by running another app instance (with the exact same level file.), click on new game, and in the console, type: connect <server-ip>
Plus, I'm sure it won't be far from perfect.

smells like multiplayer is not a very well tested feature I will have a look into SFML because I'm curious. If I find something, I will tell.

As you may have guessed, there is still a lot to do before having some nice multiplayer games between us.

I'm looking forward to this

[Bertram]

And letting the mode responsible of doing something (or not). Technically, I added a virtual empty method that was overwritten for GameMode and EditorMode.

Looks fine to me.

[hwoarangmy]

Hi,

Concerning the modes, what is the FppMode ? It looks like an empty shell right now but what is it supposed to be ?

Thanks

[paul424]

Hmm a keystroke reader , when you posses creature and you want to have a control over it ?

[Danimal]

I remind hearing about it, its a "doom-like" mode, you posses a creature by spell and control it like a first person shooter, you can attack, move around and use all of it spells and skills ( like digging, healing or fireball). Its cool for making puzzle levels, clearing traped dungeons or simply to get into the action with your strongest creature.

As you can guess, as good as it sounds its not a priority.

[hwoarangmy]

Hmm a keystroke reader , when you posses creature and you want to have a control over it ?

I should have guessed. Thanks.

I remind hearing about it, its a "doom-like" mode

Yes. I have played dungeon keeper and I know what it is.

But again, we will have problems when we will implement it. It cannot be a Mode if the GameMap is in the GameMode (in this case, the map has obviously to be refreshed when you possess a creature)...

[Bertram]

Hi hwoarangmy,

But again, we will have problems when we will implement it. It cannot be a Mode if the GameMap is in the GameMode (in this case, the map has obviously to be refreshed when you possess a creature)...

Funny as i had a hard time guessing what FPP was, also.
It stands for something like "First Person Point of view" IIRC.

It's indeed a stub but at the time I left it there since it was harmless and I didn't want to spend too much time on this one while working on the rest.
But now you tell it, it can't be an application mode, of course, but more something like a sub mode of the game mode itself.
Note also that the camera manager can only manage one type of camera atm, with foundation for other types but nothing truely done.

And I wonder: Is the FPP mode a priority? I think not. We can keep it in mind while developing but IMHO, that proven useless stub can fall.

Regards,

[hwoarangmy]

And I wonder: Is the FPP mode a priority? I think not. We can keep it in mind while developing but IMHO, that proven useless stub can fall.

I agree, it is not a priority but knowing what we are aiming for helps to choose an implementation that will allow it later.

For example, if we choose the client/server paradigm, the game map will be updated on the server side so the application modes may work even for FPP, console or Game . So we can forget this problem, it will be resolved later

[Bertram]

Hi hwoarangmy,

Just for you to know that I made a pull request for CEGUI with your changes:
https://bitbucket.org/cegui/cegui/pull- ... mingw/diff

Regards,

[hwoarangmy]

Just for you to know that I made a pull request for CEGUI with your changes

Nice

Concerning the Cavehornet skeleton problem, it seems like the problem is that the skeleton within the mesh (Insect_low.003.skeleton) is not the same as the one in the repository (Cavehornet.skeleton). As a dirty fix, I have renamed the file. But it would be better to re-generate the mesh with the good skeleton filename. Feel free to integrate or not this change

Concerning the bugs, I have fixed the game crash when exiting the game or launching a new game. I have also changed a little bit the mode manager to prepare things to make easier to launch different levels.

Now, I think I'm gonna have a look into CEGUI to make the GUI for choosing the level to launch (if nobody is doing it yet)

[Bertram]

Hi hwoarangmy,

Just for you to know, the CEGUI team merged the pull request, so it should be even easier to compile using MingW with the next CEGUI version.
They told me they will also update the cegui deps zip file for the new release with the fixes in the .def file.

Concerning the Cavehornet skeleton problem, it seems like the problem is that the skeleton within the mesh (Insect_low.003.skeleton) is not the same as the one in the repository (Cavehornet.skeleton). As a dirty fix, I have renamed the file. But it would be better to re-generate the mesh with the good skeleton filename. Feel free to integrate or not this change
Concerning the bugs, I have fixed the game crash when exiting the game or launching a new game. I have also changed a little bit the mode manager to prepare things to make easier to launch different levels.

I've merged it! Thanks!

Now, I think I'm gonna have a look into CEGUI to make the GUI for choosing the level to launch (if nobody is doing it yet)

Cool, I think nobody is.

Regards,

[hwoarangmy]

Hello,

I have made a pull request concerning the load level menu.
I have also made some changes in the pause mechanism due to what we have said about the modes. Since we can switch modes during a game (like FPP or console), I think that the pause should not be in the GameMode but in the GameMap so I moved it.

I'm gonna have a look on how multiplayer works now

Regards