balder-devel Mailing List for Balder
Status: Beta
Brought to you by:
holomorph
Menu
▾
▴
balder-devel — balder developers discussion list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(27) |
May
(10) |
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(14) |
Aug
(3) |
Sep
(24) |
Oct
(10) |
Nov
|
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bjorn H. <bh...@uv...> - 2004-01-20 00:16:50
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It turns out the UDP code in CS is broken. TCP is fine (even preferable) f= or=20 arranging games, pregame chats, etc, but unacceptable for in game network=20 performance. So the stuff that's being used for the pregame (netman,=20 netmessage, etc) can be left, which is good. The NetworkController will ne= ed=20 to be redone. I'm going to use GNE (Game Network Engine http://www.rit.edu/ ~jpw9607/gne/) for this; it seems to offer a lot of good features and shoul= d=20 be ideal. =20 The other thing I've done is update balder to use CS cvs from just after=20 Christmas, and changed some of the events. Now, instead of sending=20 individual client events for each key up/down event the client generates, i= t=20 will send 32 bits representing the entire keystate each time it changes. N= ot=20 only does this make missing key up/down events less of a disaster, but also= I=20 is easier (less code) to generate and interpret; as well as being smaller=20 than the client events were. I do need to rethink how firing and pushing o= ff=20 will work though, since I eliminated any concept of "duration" for these=20 events. =20 Bjorn =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADHRIfX9erZFzUHwRAlzPAJ0VBFPSa5OnS1S5yvE55TxTMVgOsgCePOaE dHvQZnW52egW7yMw6UxwAYY=3D =3DMiDL =2D----END PGP SIGNATURE----- |
|
From: Bjorn H. <bh...@uv...> - 2003-10-26 20:51:59
|
I think we're at a good place to make a release, so I'm going to do that=20 today hopefully. The next things I plan to work on are, as mentioned bef= ore,=20 > arbitrary level loading, and > displaying the soldiers that are in a map. =A0Also it's probably about = time > to fix that bug where you can't start a second new game without quittin= g > the program first and re-running :p. The other thing which needs work is in game synchronization. After readi= ng=20 some articles on the subject, I think it might be best to send complete i= nput=20 states, instead of keyup and keydow events. Since most of these are boole= ans,=20 they can be represented by a single bit, This has the advantage that a=20 single event contains all (or at least most) of the inputs for a player, = so=20 this could mean sending less events, in some cases, though these will hav= e to=20 be sent at regular intervals. I'll have to do a bit of testing to see if= =20 this is really a viable idea. =20 Other things that should help with network sync is using UDP instead of T= CP=20 in game (the pregame setup should use TCP still though I think). This is= a=20 simple matter of switching the PROTOCOL constant in network controller, b= ut I=20 think UDP may be broken in CS at the moment, I'm not sure. Sticking in s= ome=20 event prioritization, and modyfiyng sendpkt to send more than one event=20 (larger packets) should help as well. =20 The one major code structure change I would like to get done is moving al= l of=20 the net stuff, except the NetworkController code, out of the game directo= ry=20 and into the menu directory. This should be fairly easy (just change a f= ew=20 include statements). The next step is to decouple that code from anythin= g=20 not in the menu directory. Since our design now uses a different object = for=20 in game networking than for pregame setup, having this code only relate t= o=20 menu stuff makes good design sense. I would like to make network control= ler=20 a CS event Handler instead of a messageListener (same with NetPlayer). S= o=20 preFrame becomes HandleEvent(). Creation of these objects should happen = in=20 the menu as well. This all should simplify things a bit. Also now that = we=20 only have to worry about pregame stuff in Netmanager and NetPlayer, there= is=20 quite a bit more simplification possible, but it's hardly necesarry as th= e=20 code works fine as is. =20 Ok, I'm off to see about that release. . mb I'll make a binary for window= z=20 folks as well :p. Bjorn |
|
From: Bjorn H. <bh...@uv...> - 2003-10-26 20:36:26
|
Most of what I mentioned in the previous email is now done. Point #5 howe= ver=20 is not fully implemented, but that's probably not crucial. The start sig= nal=20 is sent to all clients, however they don't send back a confirmation (I do= n't=20 think). Since we're using TCP for game setup, and it's supposed to be=20 "guarenteed", I think since we aren't sending gobs of data we can reason= ably=20 assume the signal gets there. Only testing on the real internet will tel= l=20 tho, as on my lan, or running two instances on one comp,the signal will=20 always arrive. =20 Bjorn On Thursday 23 October 2003 10:25, Bjorn Hansen wrote: > 5. =A0When the server clicks start, Menu->StartNewMultiplayer() is call= ed. =A0 > This should, in server mode, send a start signal to all clients. =A0Whe= n a > client recieves a start signal, it should call its own > Menu->StartNewMultiplayer(), and send a confirmation back to the server > that the message was recieved; we have to make sure the start message g= ets > through. =A0We need not worry about synchronizing the start of the game= here, > that is done in NetworkController, just have to make sure everyone gets= the > start message. |
|
From: Bjorn H. <bh...@uv...> - 2003-10-24 23:11:41
|
these are done now > call Menu->SetReadyStatus(const char* name, bool ready). =A0I haven't w= ritten > this function yet though, but it is similar to AddPlayer. > > sending. =A0When it is recieved something like Menu->AddChat() should b= e > called. =A0I haven't written this either |
|
From: Bjorn H. <bh...@uv...> - 2003-10-23 23:59:11
|
i've pretty much moved all non-gui stuff out of the MenuWindow class and = into=20 Menu. The last thing that's left is to actually set up the connection, a= nd=20 send ready status, start messages, and chats. The way this works is as=20 follows: 1. When someone hosts a new game or joins a game, Menu->SetServer() is=20 called, being passed the adress of the server and whether to act as clien= t or=20 server. This method is complete except for actually making a call to conn= ect=20 if it's in client mode. I assume this call should be to netplayer? =20 2. When a new connection is made to the server, the server should notify= all=20 cients that a new player joined, and the name of the new player. The ser= ver=20 and all clients then call Menu->AddPlayer(). This will update thier play= er=20 list. =20 3. When a client clicks the ready status toggle, Menu->SendReadySignal()= is=20 called. This should send a status update to the server. The server then= =20 passes it on to all clients. Then the server and all clients should call= =20 Menu->SetReadyStatus(const char* name, bool ready). I haven't written th= is=20 function yet though, but it is similar to AddPlayer. =20 4. When someone clicks send chat, Menu->SendChat() is called, which shou= ld=20 in turn pass the chat message to the network (netplayer I suspect) for=20 sending. When it is recieved something like Menu->AddChat() should be=20 called. I haven't written this either, but I think it's another 2 liner = or=20 whatever, just pass the username and message on to MenuWindow->AddTextToC= hat 5. When the server clicks start, Menu->StartNewMultiplayer() is called. = =20 This should, in server mode, send a start signal to all clients. When a=20 client recieves a start signal, it should call its own=20 Menu->StartNewMultiplayer(), and send a confirmation back to the server t= hat=20 the message was recieved; we have to make sure the start message gets=20 through. We need not worry about synchronizing the start of the game her= e,=20 that is done in NetworkController, just have to make sure everyone gets t= he=20 start message. =20 Anyway, midterms looming in the near future, so I can't do anything for a= t=20 least a couple days. Since you know the netplayer and netmanager code be= tter=20 than I do, if you get a chance to implement this stuff (I think most is=20 already there, just have to make the appropriate calls) that would be=20 excelent. If not, I'm sure I'll get to it sometime :). =20 After that all works I plan to implement arbitrary level loading, and=20 displaying the soldiers that are in a map. Also it's probably about time= to=20 fix that bug where you can't start a second new game without quitting the= =20 program first and re-running :p. =20 Bjorn On Sunday 12 October 2003 18:05, you wrote: > I'm a little concerned with how much program functionality has crept in= to > mwindow. =A0It should only be responsible for the windowing interface, = and > interact with other things through it's controller object (in this case= the > Menu object). =A0From a good design standpoint it should not have knowl= ege > of, or direct access to any other objects. |
|
From: Bjorn H. <bh...@uv...> - 2003-10-13 19:44:25
|
On Sunday 12 October 2003 18:05, you wrote: > this lack of synchronization is quite baffeling. once any soldiers pass > through a portal, it seems to stop appplying updates. =A0Any ideas? it turns out this had nothing to do with portals or gravity or anything e= lse.=20 just that soldier1 was getting updates every second, and usually soldier= 2,=20 but 3 not all the time and 4 hardly ever, since they were all sent at onc= e. =20 Staggering sending these updates to send one at a time, every 200 ms seem= s to=20 have fixed the synchronisation. The biggest issue that remains is failur= e to=20 recieve a keyUp event, thus the client assumes that the key is still pres= sed=20 and tries to spin the soldier.=20 Anyway, things look good when hosting on my laptop,(which is much faster)= ,=20 but segfaults occur when hosting on the slower machine, not sure why yet. Bjorn |
|
From: Bjorn H. <bh...@uv...> - 2003-10-13 01:02:38
|
I've fixed things so that clicking start new practice will start a single player practice session, with controlo of all soldiers as expected. For multiplayer, the server status is no longer hard coded, so it's no longer necesarry to compile a server and a client. Simply create or join a multiplayer game as usual. There are still a few bugs, the client doesn't show up on the server's list of players, and both players must click start to invoke menu->StartNewMultiplayer( ) on each machine. Also it would be nice to set the control bits for the soldiers, but that's a lot more work and not very crutial at this point. I'm a little concerned with how much program functionality has crept into mwindow. It should only be responsible for the windowing interface, and interact with other things through it's controller object (in this case the Menu object). From a good design standpoint it should not have knowlege of, or direct access to any other objects. this lack of synchronization is quite baffeling. once any soldiers pass through a portal, it seems to stop appplying updates. Any ideas? Bjorn |
|
From: Bjorn H. <bh...@uv...> - 2003-10-11 22:58:08
|
is somewhat better now. Update events are being sent from the server every second, and things look pretty good for a while. Stuff gets kinda weird tho after a while. I'm pretty sure this is due to incompleteness of the SoldierUpdateEvent. That still has some issues that need examining obviously. But that will have to wait on school. To test this stuff you have to compile two versions of Balder. One as a client and one as a server (change this in Menu->Draw()). Once we can generate the gamedata_t structure in game this will not be necesarry. Bjorn |
|
From: Bjorn H. <bh...@uv...> - 2003-10-11 20:25:59
|
On Saturday 11 October 2003 11:10, you wrote: > Other thing, in the code in NetworkController::HandleEvent(). Woun't yo= u > created the code to pass from a string to type of GameEvent in GameEven= t > or an utility file? yes, this was why I put the comment: // the following code should probably be put in GamEvent as a static meth= od: I'm planning to write a static method in GameEvent to create the correct = type=20 of event, but I'm not sure exactly how I want to design that yet, so I ju= st=20 put somethnig that works in the HandleEvent function to try it out. Once= the=20 static GameEvent method is written I'll use that. > > Ok. I had knowledge of the unsyncronization. It happens when a Soldier > touch a wall, for example. But this could be easily solved using > SoldierUpdate. Switch to on/off type is only to network load, not to sy= nc. > yes, but I still think it's a good idea, watching the output there was a = huge=20 flood of packets the old way. The new system sends much less data (and=20 actually did do somethnig for the syncronization, though this was probabl= y=20 due to differing stepsizes on the two computers). I have to check my=20 homework volume, but the soldier update event stuff is mostly in place; j= ust=20 have to generate and send them from the server. Hopefully I can do that = today > Noiro > > PD: I =A0changed the code. With the NetworkController code, it doesn't = do > nothing (maybe i need two computers, not a single one). With the old > code changed, it segfault in RecieveEvent. I'll try to find the bug, bu= t > if i find the bug, what code will be used? Well, the networkController code is working, and should not need to be=20 changed again, except for a few minor things; the eventHandler, as noted=20 above, and a small bit for synchronizing the start of the game. Otherwis= e it=20 does all that it needs to ever do, so I see no reason to change. So what we have here is a new set of conections generated for every new g= ame,=20 and in game networking should be pretty much all set (we just have to dec= ide=20 what to send and when). Plus makes cleanup at the end of each game easy.= =20 But we still need a way to set up the games (right now it's hard coded in= to=20 the menu->Draw() method). So that's where the other networking code come= s=20 in. We need that to have the pregame chat, play with options, and then = just=20 before the game starts, make sure everyone's gamedata_t structure is set = up. =20 I think I haven't been quite as clear here with my ideas as i'd like, bu= t=20 perhaps I'll be able to better explain later :p. I hope I've made some s= ense=20 here. Bjorn |
|
From: Pedro D. S. <pd...@so...> - 2003-10-11 18:20:33
|
Bjorn Hansen wrote: >First, there is a new network controller for in game stuff. The ond >packet/event handling code in network manager was causing segfualts and, as I >couldn't really understand how it was supposed to be working I wrote a simple >replacement which is (I think) much simpler, and working nicely. The old >stuff was working fine for pregame chat and stuff, so I left it for that. >The new NetworkController object is created by the EventManager at game setup >time, and makes connections according to the information in gamedata_t, which >should be set up prior to starting a game. > Ok. I just saw a bit the code of NetworkController and I think that is a bad idea to have almost the same code twice. Ok, i think that the netman code could be much simpler, but in this case all that you need is to change the NetMessage code and that is, IMO, easy to understand. I saw the actual code, and seems a little buggy how it is now (basically there is a 2 instead of 1, and the type of event is managed in other way). I'll change the actual code to put what you put in NetworkController and commit it. Just give it a try. Other thing, in the code in NetworkController::HandleEvent(). Woun't you created the code to pass from a string to type of GameEvent in GameEvent or an utility file? >Other small changes, I've added a Game::Setup function, which should set >everything up, and then Game::Start should simply start the timer and allow >the game to proceed. I plan to use this to not start the game simulation >until Start is called (by the EventManager). > >More good news: My laptop arrived, and with the new network stuff, I have >successfully got them connected. The bad news (though not unexpected) is >that there are serious syncronization issues. So, in order to fix this I'm >going to switch events from a duration thing, generated every frame, to an >on/off type, generated by key up and key down events. This should greatly >reduce network load. The other thing I'm plannning to do is actually start >sending, and applying, update events. That should help a lot. > Ok. I had knowledge of the unsyncronization. It happens when a Soldier touch a wall, for example. But this could be easily solved using SoldierUpdate. Switch to on/off type is only to network load, not to sync. Noiro PD: I changed the code. With the NetworkController code, it doesn't do nothing (maybe i need two computers, not a single one). With the old code changed, it segfault in RecieveEvent. I'll try to find the bug, but if i find the bug, what code will be used? |
|
From: Bjorn H. <bh...@uv...> - 2003-10-11 04:37:49
|
First, there is a new network controller for in game stuff. The ond packet/event handling code in network manager was causing segfualts and, as I couldn't really understand how it was supposed to be working I wrote a simple replacement which is (I think) much simpler, and working nicely. The old stuff was working fine for pregame chat and stuff, so I left it for that. The new NetworkController object is created by the EventManager at game setup time, and makes connections according to the information in gamedata_t, which should be set up prior to starting a game. Other small changes, I've added a Game::Setup function, which should set everything up, and then Game::Start should simply start the timer and allow the game to proceed. I plan to use this to not start the game simulation until Start is called (by the EventManager). More good news: My laptop arrived, and with the new network stuff, I have successfully got them connected. The bad news (though not unexpected) is that there are serious syncronization issues. So, in order to fix this I'm going to switch events from a duration thing, generated every frame, to an on/off type, generated by key up and key down events. This should greatly reduce network load. The other thing I'm plannning to do is actually start sending, and applying, update events. That should help a lot. The timetable for all this is of course Schoolwork dependant. Hopefully I can get the events changed tonight though. Bjorn |
|
From: Bjorn H. <bh...@uv...> - 2003-09-26 03:15:41
|
I think this can be done using a csDatastream; the CS network manager does. I'm not convinced, however, that we will get much performance gain from doing this. It should not be hard to implement later if needed though. I should have my new laptop by tomorrow (in theory). Then I will network it with my box here and I can test running 2 clients, see how they sinc. I'd run 2 on one box using User Mode Linux, exept my box barely runs one :). anyway, once i get that testing should be easier. Bjorn |
|
From: Bjorn H. <bh...@uv...> - 2003-09-14 23:39:42
|
On Sunday 14 September 2003 15:10, you wrote:
> ok, I found the bug that give me that error. Don't know how to solve it.
> It is located in the map file default.world, and i don't get the error when
>
> <collider>
> <collidermesh friction="1.0"
> elasticity="1.0">room_walls</collidermesh>
> </collider>
>
> this text is removed. But then, i cross the walls of the ungravity room.
> Uhmm, this text can't be removed, so I don't post to the CVS. Where do
> you find the specifications for this?
>
unfortunately the documentation on the physics loader is somewhat
nonexistant. Everything works ok in the hallway though? try removing the
friction="1.0" elasticity="1.0" from that collidermesh tag.
hmm, from the error though it looks like the room_walls mesh is not getting
created or something.
> Once removed it, I have the bug that you commented. The problem was that
> TIMESTEP is 2 and turnLeft can be odd.
>
> if (turnLeft){
> turnLeft-=TIMESTEP;
> }
>
> I commited the fix to the CVS. Please, check that i do ok in the
> grabTime part. I can't verify it.
>
hah, oops. Yea, this is something I had done at home this summer, but
forgot to commit before I came back to school, so I did it again and forgot
about the possibility of it going negative. Had to change the TIMESTEP to 2
because 1 was to short to run on my box here :P
|
|
From: Bjorn H. <bh...@uv...> - 2003-09-14 23:27:50
|
On Sunday 14 September 2003 12:04, you wrote: > One thing about EventManager. Are the events only for the game or can we > use it for pass a message. Ok, I explain a bit, I say it for the the > Chat. How it is done now, the NetMessage look if the game is running and > if it's not running, then it calls the mwindow function, and if it is > running it called the chatdisplay function. What I have in mind is that > the NetMessage pass it to the EventManager and from it, sends it towards > the register function. That's the reazon because I put an unregister > event function. So really, what we need to decide is do we want pregame stuff sent as events, or do it some other way. I'm not sure. I think drawing some diagrams would help, not sure when I'll have time for that though > But to get this working, we need that the EventManager doesn't belong to > the current game. It must belong to all the system, like the > NetworkManager. What it implies in relation with the EventSaver, for > example, is that we need to pass the EventManager when we start and when we > stop a game (to start and stop saving). not necesarrily. Might be better instead of creating a new eventSaver each game, just have a function in eventSaver to start a new file. Same for the eventManager, have an initialization function called every time a new game is started, and one when it stops |
|
From: Bjorn H. <bh...@uv...> - 2003-09-14 23:17:55
|
On Sunday 14 September 2003 11:35, you wrote: > Bjorn Hansen wrote: > >On Thursday 11 September 2003 09:11, you wrote: > >>One last thing. I thing that maybe will be an interesting thing to start > >>a profile class. In that class, we can save the options of a particular > >>user. It's like the file game.cfg. The game.cfg will be the default > >>option for a new profile, it can be saved in the save directory. It can > >>store, for example, the name of that user, the keys, the default port, > >>the ip to connect to, the color that it prefer, the display options, if > >>save the events, the name of the file to save the events, etc. > > > >I belive CS has a framework for per user settings in place. I'm not sure > > how it works though. It's an interesting idea, but I don't think it's a > > high priority. You're welcome to try it anyway if you like though. > > Ok, I know that is not a high priority, but I think that should be > interesting to start it early, because, it should not be very difficult > to implement, and we could use it now. Of couse, what i'm planning now > is that the profile give us only the name and things like that. For now, > i'm not intention to change all the keys in the option menu. > > >As far as configuration goes though, I'd like to see more control over > > game setup in the menu; like being able to pick the map to load. Once a > > map is chosen, being able to assign soldiers to different players (set up > > the bit array in gamedata) would be nice. > > Yes, this could be better now. I have a question about this. What is it > better? first pick the map and wait to everybody are ready, and before > start, assign every player to some soldier. Or in the same screen of > select map, select the correspondence player - soldier. Seems to be > better the second aproach, but where and how implement it? > Other question about the map's format. What do you use as editor of the > map? And how can we get the information from the map to know how much > soldiers and things like that in an easily way? > > Noiro For now, a practice session should just be a quick start; load the default map and have control of all soldiers. For a network game, the host sthould be able to browse and choose a map. this would be loaded, all start locations (soldierss) in that map should be listed, along with their team color/name. Eventually I'd like to choose team captians and have them assign soldiers etc. but for now, I think just being able to assign them (perhaps the host does this) would be fine. Getting the information from a map is easy, once it's loaded. Look in Game->setupGameObjects() and in the Soldier constructor; we just get all the start locations and iterate over them. Names in the start location are associated with keys of the same name containing team information. So you can build a list of soldiers and their teams and associated start location number (used to know which bitsto set in the soldiers bit array) then display that. Information in the multiplayer setup window. |
|
From: Pedro D. S. <pd...@so...> - 2003-09-14 22:16:41
|
ok, I found the bug that give me that error. Don't know how to solve it.
It is located in the map file default.world, and i don't get the error when
<collider>
<collidermesh friction="1.0"
elasticity="1.0">room_walls</collidermesh>
</collider>
this text is removed. But then, i cross the walls of the ungravity room.
Uhmm, this text can't be removed, so I don't post to the CVS. Where do
you find the specifications for this?
Once removed it, I have the bug that you commented. The problem was that
TIMESTEP is 2 and turnLeft can be odd.
if (turnLeft){
turnLeft-=TIMESTEP;
}
I commited the fix to the CVS. Please, check that i do ok in the
grabTime part. I can't verify it.
Noiro
Bjorn Hansen wrote:
>hmm, well then that's obviously not it :p.
>I immagine it probably says in the docs somewhere which version CS uses, but
>I'm not sure where. I think I saw the upgrade reading the history.txt
>changelog or something like that.
>
>On Sunday 14 September 2003 12:24, you wrote:
>
>
>>My version of ODE in my system is 0.39, but how do I know what is the
>>version that uses CS?, because i upgrade to 0.39 some time ago and it
>>worked after it.
>>
>>
|
|
From: Bjorn H. <bh...@uv...> - 2003-09-14 19:48:41
|
On Sunday 14 September 2003 11:38, you wrote: > >ah, yes, sending in binary might be best. I would hope that the netwo= rk > >plugins for CS would have solved the endian issue, but we should check= for > >sure first. Then we can simply send the events with no need for the > > tostring and fromstring methods. > > Ok, i saw some things related to the endian issue in CS, at least the > conversi=F3n from big endian to local machine (I didn't see the reverse= , > but I suppose that it must exists) > And although we apply the binary mode, we need some method similar to > ToString and FromString (ToBinary and FromBinary?). And as I said befor= e > a reorganitation of the netmessage to don't use csString. I guess I should read a little about the network plugins and how they wor= k. =20 It's not possible to just send a binary copy of the object over the netwo= rk? =20 And if we still need To and From methods then I don't see the advantage o= f=20 binary. =20 > > >>Other idea. When we send UpdateSoldier, we update the position. We al= so > >>can send SoldierState that update if the soldier is moving right or > >>moving up. In this way, we can only desync a fews ms. > > > >The complete state of a soldier (position, orientation, and velocity) = was > >always intended for a soldier update event. Other necesarry informati= on > >probably includes the sector name, state of health, etc. > > Ok, so finally, what will be the way of doing this? > -Get it work > -implement UpdateSoldier and send it when the network load is low at a > rate of 1 times per second aprox. > -change the way that GameEvent works (i mean, sends start moving up and > stop moving up instead of every frame sends that we are moving up). > -Maybe later, an inteligent way of sinc. That looks about right; first, get it working again on a single machine. = =20 Next, get it working with one client and one server (this will almost sur= ely=20 need the soldier updates). Then we evaluate the network load and see wha= t we=20 think will work best for reducing it (probably as you say, start and stop= =20 events) > in UpdateSoldier we update position, orientation, velocity and sector > name, etc. Will it update if we are moving up (and left, right, ....)? to update the state of the physical body in the physics plugin I think we= =20 just need position, orientation, and velocity. To know the system it's = in,=20 we need the sector. for knowing if it's frozen or not, we need the life=20 status. I think that's a good start. When we add new features (like bod= y=20 position), we'll have to add those to the update event as well. Bjorn |
|
From: Bjorn H. <bh...@uv...> - 2003-09-14 19:35:30
|
hmm, well then that's obviously not it :p. I immagine it probably says in the docs somewhere which version CS uses, but I'm not sure where. I think I saw the upgrade reading the history.txt changelog or something like that. On Sunday 14 September 2003 12:24, you wrote: > My version of ODE in my system is 0.39, but how do I know what is the > version that uses CS?, because i upgrade to 0.39 some time ago and it > worked after it. |
|
From: Pedro D. S. <pd...@so...> - 2003-09-14 19:29:17
|
My version of ODE in my system is 0.39, but how do I know what is the version that uses CS?, because i upgrade to 0.39 some time ago and it worked after it. Bjorn Hansen wrote: >what is your version of ODE? The recent CVS upgraded from 0.35 to 0.39 I >believe. That might be the difficulty here. > >On Sunday 14 September 2003 11:32, you wrote: > > >>Ok, I did what you say (snapshot of CS) and although it fails to compile >>a pluging, it now works ok, and let me compile Balder. But now, when I >>start Balder and click the start button, it says me: >> >>Description: No mesh specified for collidermesh >>[node: world,addon,params,system(room),body,collider,collidermesh] >>Error ID: crystalspace.dynamics.loader >>Description: Currently unable to parse a bone, sorry. >>[node: world,addon,params,system(room),body,collider] >> >>and nothing happens. I'll try to hunt this bug. >> >>Noiro >> >> |
|
From: Pedro D. S. <pd...@so...> - 2003-09-14 19:08:47
|
Bjorn Hansen wrote: >I'm going to move the scheduling of when to apply events out of event manager >and let it be dealt with by the event recievers themselves. For one thing, >we might have events that the reciever doesn't care what the timestamp is. >More importantly however is the following: > >Soldiers are currently the primary event recievers. >methods in the solier class get called every step of the physics simulation, >so dealing with event scheduling there allows more precise timing. > Ok, it's better, yes. I put it in EventManager because it was on NetworkManager, but yes, is better to put in Soldier (more sync). > >I also moved creation of the eventSaver to the eventManager; this is where it >belongs. The game need not care about event recording, and playback will have >to be a special mode anyway so this keeps things cleaner until we get there. > ok One thing about EventManager. Are the events only for the game or can we use it for pass a message. Ok, I explain a bit, I say it for the the Chat. How it is done now, the NetMessage look if the game is running and if it's not running, then it calls the mwindow function, and if it is running it called the chatdisplay function. What I have in mind is that the NetMessage pass it to the EventManager and from it, sends it towards the register function. That's the reazon because I put an unregister event function. But to get this working, we need that the EventManager doesn't belong to the current game. It must belong to all the system, like the NetworkManager. What it implies in relation with the EventSaver, for example, is that we need to pass the EventManager when we start and when we stop a game (to start and stop saving). Noiro |
|
From: Bjorn H. <bh...@uv...> - 2003-09-14 18:51:21
|
what is your version of ODE? The recent CVS upgraded from 0.35 to 0.39 I believe. That might be the difficulty here. On Sunday 14 September 2003 11:32, you wrote: > Ok, I did what you say (snapshot of CS) and although it fails to compile > a pluging, it now works ok, and let me compile Balder. But now, when I > start Balder and click the start button, it says me: > > Description: No mesh specified for collidermesh > [node: world,addon,params,system(room),body,collider,collidermesh] > Error ID: crystalspace.dynamics.loader > Description: Currently unable to parse a bone, sorry. > [node: world,addon,params,system(room),body,collider] > > and nothing happens. I'll try to hunt this bug. > > Noiro |
|
From: Pedro D. S. <pd...@so...> - 2003-09-14 18:43:48
|
Bjorn Hansen wrote: >Just out of curiosity, what are you using for developement? > >I've got : >PIII 450 >192MB Ram >Voodoo3 >running Debian >using Kdevelop >gcc 2.95.4 > >over the summer I was using a ~1.2 GHz running windows XP with devC++ and >Mingw. > hehe, i have the same type of curiosity... What i've got: AMD Athlon XP 2000+ 256MB Ram gForce4 running Gentoo under gnome (sometimes kde) using Anjuta, but it consume my resources, so i'm looking for other, kdevelop or scaffold. gcc 3.3.1 (and I have too 2.95.3) Noiro |
|
From: Pedro D. S. <pd...@so...> - 2003-09-14 18:42:17
|
>ah, yes, sending in binary might be best. I would hope that the network >plugins for CS would have solved the endian issue, but we should check for >sure first. Then we can simply send the events with no need for the tostring >and fromstring methods. > Ok, i saw some things related to the endian issue in CS, at least the conversión from big endian to local machine (I didn't see the reverse, but I suppose that it must exists) And although we apply the binary mode, we need some method similar to ToString and FromString (ToBinary and FromBinary?). And as I said before a reorganitation of the netmessage to don't use csString. > > >>Other idea. When we send UpdateSoldier, we update the position. We also >>can send SoldierState that update if the soldier is moving right or >>moving up. In this way, we can only desync a fews ms. >> >> > >The complete state of a soldier (position, orientation, and velocity) was >always intended for a soldier update event. Other necesarry information >probably includes the sector name, state of health, etc. > Ok, so finally, what will be the way of doing this? -Get it work -implement UpdateSoldier and send it when the network load is low at a rate of 1 times per second aprox. -change the way that GameEvent works (i mean, sends start moving up and stop moving up instead of every frame sends that we are moving up). -Maybe later, an inteligent way of sinc. in UpdateSoldier we update position, orientation, velocity and sector name, etc. Will it update if we are moving up (and left, right, ....)? Noiro |
|
From: Pedro D. S. <pd...@so...> - 2003-09-14 18:39:19
|
Bjorn Hansen wrote: >On Thursday 11 September 2003 09:11, you wrote: > > >>One last thing. I thing that maybe will be an interesting thing to start >>a profile class. In that class, we can save the options of a particular >>user. It's like the file game.cfg. The game.cfg will be the default >>option for a new profile, it can be saved in the save directory. It can >>store, for example, the name of that user, the keys, the default port, >>the ip to connect to, the color that it prefer, the display options, if >>save the events, the name of the file to save the events, etc. >> >> > >I belive CS has a framework for per user settings in place. I'm not sure how >it works though. It's an interesting idea, but I don't think it's a high >priority. You're welcome to try it anyway if you like though. > Ok, I know that is not a high priority, but I think that should be interesting to start it early, because, it should not be very difficult to implement, and we could use it now. Of couse, what i'm planning now is that the profile give us only the name and things like that. For now, i'm not intention to change all the keys in the option menu. >As far as configuration goes though, I'd like to see more control over game >setup in the menu; like being able to pick the map to load. Once a map is >chosen, being able to assign soldiers to different players (set up the bit >array in gamedata) would be nice. > Yes, this could be better now. I have a question about this. What is it better? first pick the map and wait to everybody are ready, and before start, assign every player to some soldier. Or in the same screen of select map, select the correspondence player - soldier. Seems to be better the second aproach, but where and how implement it? Other question about the map's format. What do you use as editor of the map? And how can we get the information from the map to know how much soldiers and things like that in an easily way? Noiro |
|
From: Pedro D. S. <pd...@so...> - 2003-09-14 18:35:57
|
Bjorn Hansen wrote: >>functionality that exist already in CS. I think that ToString methods >>can be simplified, but i didn't find a way with all the classes in CS. >>What we need is simple, some method that can dump into a char* and later >>recovering it (like the pickle class in Python). >> >> > >I've simplified (rewrote) the ToString and FromString methods using a >csString, The old ones were causing a segfault for me and weren't very >readable. Also FromString now checks the string it is passed and returns >false if it's not right. This was my origional intention so that we need not >know the type of an event when it's recieved as a string; simply pass it to >different event types FromString method untill one returns true. Actually I >intend to write a static method in for GameEvent that will take a string and >return the right kind of event. That will allow us to call >GameEvent::CreateEvent(const char* TextData) and then pass the returned >pointer to the EventManager. > Sounds good. I see how you do it (ToString and FromString) and I like it. About the static CreateEvent, yeah it's a better aproach and more easy to mantain. >>One thing, I think that now, the code is broken (all works fine until >>you try to move). I know where is the bug, but I can't get by CVS a >>working copy of CS. The broken code is that Extract has been removed >>from StringArray, but Pop() is not the same that Extract(0). Pop() is >>similar to Extract(lengthofStringArray). Instead of that Pop(), we must >>use DeleteIndex(0), but I can't change it because is a new feature of >>StringArray. >> >> > >Yes, I've partially fixed it, but moving doesn't stop once it starts so >something is still screwy. You might try downloading a snapshot of the >current CS CVS? else just try a few times; sourceforge is supposed to have >this fixed very soon. Also you could just tell me where you think the bug is >and I'll have a crack at it. > Ok, I did what you say (snapshot of CS) and although it fails to compile a pluging, it now works ok, and let me compile Balder. But now, when I start Balder and click the start button, it says me: Description: No mesh specified for collidermesh [node: world,addon,params,system(room),body,collider,collidermesh] Error ID: crystalspace.dynamics.loader Description: Currently unable to parse a bone, sorry. [node: world,addon,params,system(room),body,collider] and nothing happens. I'll try to hunt this bug. Noiro |