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 itBertram {l Wrote}:More importantly, it was fun to see the kind of window frame you were using
Fill free to change whatever you think is better.Bertram {l Wrote}:I do think we should use a more common background and size for this pop-up
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 lookingDanimal {l Wrote}:Dont be mean and show hmw's pop up screen. Im all intrigued
See how it is nicer than Bertram'sDanimal {l Wrote}:Dont be mean and show hmw's pop up screen. Im all intrigued
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) .
Increasing the code funcitonaliuty IS ALWAYS WAY BETTER THAN POLISHING details
No worries, I was jokingBertram {l Wrote}:I don't want to start a finer pop-up challenge. (I fear losing too much ;])
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 betterBertram {l Wrote}: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 agreeBertram {l Wrote}:Anyway, I do think we need to setup a common modal window skin and use it for all the menu GUI.
I think it is interesting to change the timespeed. Even if 0.01 to 100 seems too muchpaul424 {l Wrote}:Anyway hwa, what do you think of my proposal ?
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 investigatedpaul424 {l Wrote}:Increasing the code funcitonaliuty IS ALWAYS WAY BETTER THAN POLISHING details of exisiting things IMHO.
:)paul424 {l Wrote}:hwoarangmy , also why do you have such difficult nickname ?
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
<Property name="Area" value="{{0.1,0},{0.1,0},{0.9,0},{0.4,0}}" />
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 ?
ThanksBertram {l Wrote}:Hope it will help you with possible further changes there or elsewhere.
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).Bertram {l Wrote}: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?)
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 ?Bertram {l Wrote}: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.
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...Bertram {l Wrote}: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.
Again, is it possible to test multiplayer ? I don't like to upload untested updates...Bertram {l Wrote}: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.)
I added dome bridge to make the ODFrameListener refresh the GameMap through the Mode
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.
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.
Again, is it possible to test multiplayer ? I don't like to upload untested updates...
I mean, in ODFrameListener, instead ofBertram {l Wrote}:Sounds good. You mean something roughly like this?
mGameMap->doTurn();
mModeManager->getCurrentMode()->doTurn()
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 fitBertram {l Wrote}: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.
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.Bertram {l Wrote}: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.
I'm looking forward to thisBertram {l Wrote}:As you may have guessed, there is still a lot to do before having some nice multiplayer games between us.
And letting the mode responsible of doing something (or not). Technically, I added a virtual empty method that was overwritten for GameMode and EditorMode.
I should have guessed. Thanks.paul424 {l Wrote}:Hmm a keystroke reader , when you posses creature and you want to have a control over it ?
Yes. I have played dungeon keeper and I know what it is.Danimal {l Wrote}:I remind hearing about it, its a "doom-like" mode
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)...
I agree, it is not a priority but knowing what we are aiming for helps to choose an implementation that will allow it later.Bertram {l Wrote}: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.
NiceBertram {l Wrote}:Just for you to know that I made a pull request for CEGUI with your changes
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)
Users browsing this forum: No registered users and 1 guest