From: Jan E. <ch...@in...> - 2001-01-29 07:36:01
|
For a few days to come, Civil will be horribly broken in CVS. I'm working on the reorganizations to a server-based system. Please hang on or help out. :-) --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Jan E. <ch...@in...> - 2001-01-29 19:37:34
|
Well, nobody protested too much about splitting up Civil into a server and a client, so now it is partially done. The current situation (as checked in) does run, with "some" limitations. Changes include: * new screen shown first. Lets player select server host, port and the name he/she wants to use. * scenarios are now totally retrieved from the server. The index files too, as well as the raw XML. Works ok. Uses the list from properties.py, but only the first url! I think the server should manage *all* scenarios, thus they are all in one index file at the server. * starting a new game is slightly changed. There is no "Setup Players" anymore, it is gone. The functionality from that one is partially in the "Connect to server" (first dialog) and partially in "New game". Reduces the needed clicks to start a game. * the side (rebel/union) is chosen in the dialog "New game". * the connection to the server is done immediately when the first dialog is Ok:ed. At this point the game waits for the other client to join. This needs some work, as the player must know what goes on. * when "Start game" is clicked it all dies. This is how far I've got. * much other stuff here and there.... Quite a lot of the stuff is still entangled in stuff that the server/client needs. The server needs an own "scenario.py" (or equivalent) and "properties.py", as these will need to differ *a lot*. Unless objections are heard I'll do that one of these days. Comments? What did I do Wrong(tm)? --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Gareth N. <gar...@uk...> - 2001-01-29 20:29:35
|
>* new screen shown first. Lets player select server host, port and the >name he/she wants to use. Cool... >* scenarios are now totally retrieved from the server. The index files >too, as well as the raw XML. Works ok. Uses the list from properties.py, >but only the first url! I think the server should manage *all* scenarios, >thus they are all in one index file at the server. This is a good thing IMHO... >* much other stuff here and there.... Excellent! Nice work Jan! :) However, I'm curious as to how you always manage to do a load of updates the day before you have a project to hand in! ;-) |
From: <mik...@rc...> - 2001-01-29 22:36:00
|
Jan Ekholm writes: > * scenarios are now totally retrieved from the server. The index files > too, as well as the raw XML. Works ok. Uses the list from properties.py, > but only the first url! I think the server should manage *all* scenarios, > thus they are all in one index file at the server. That solves (even better, eliminates) a lot of problems. All graphics are still retrieved locally from the client? Hmm. That's probably correct, I think. > Comments? What did I do Wrong(tm)? Sounds good so far. My wife's new laptop arrived this weekend and she's starting to move stuff over to it; my email access will be especially sporadic for the next week or so, but at the end of that I ought to actually manage to do some productive coding... - mikee |
From: Gareth N. <gar...@uk...> - 2001-01-29 22:39:34
|
>All graphics are still retrieved locally from the client? Hmm. >That's probably correct, I think. You definitely don't want to download them. They aren't optimised for net access... :-\ However, it could be done if you ever wanted to move that direction. Would probably only take a weekend or so... G -- "Computer games don't affect kids. I mean if Pacman had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music." -- Unknown -- |
From: Mike S. <mik...@de...> - 2001-02-03 02:57:16
|
This is sort of old... (by the way, linuxworld kicked ass!) Gareth Noyce wrote: > >> All graphics are still retrieved locally from the client? Hmm. >> That's probably correct, I think. > > > You definitely don't want to download them. They aren't optimised for > net access... :-\ > However, it could be done if you ever wanted to move that direction. > Would probably only take a weekend or so... I think this would be a horrible, horrible idea to download the graphics, unless they were new ones or something specific to the scenario but i don't think that will be an issue at all. Mike -- ------------------------- Mike Szczerban | m...@sz... ------------------------- -- |
From: Jan E. <ch...@in...> - 2001-02-02 14:28:51
|
Hi all, A little hacking made Civil a little more userfriendly again. The last version had the clients wait until both players had connected before it would allow them to continue with setting up the game. That was clearly not good, the only place the server should have the clients wait is just before the game should start. So, the thing behaves that way now. Players can connect independetly, select scenarios and so on. Players can even disconnect and reconnect, and the server manages those issues just fine. When clicking "Start game" a crash happens. I haven't got that far yet. What is still missing before the game could run as before is to make a main loop for the server, strip out all server-specific things from the main loop of the clients. Also a few parameters need to be exchanged with the server once the clients click "Start game", as the players must obviously have chosen the same scenario and different sides (union, rebel). Some dialogs now use the new MessageBox class to display errors. Still need to replace all those print():s with messageboxes so that the player really knows what went wrong. What else should I whack into pieces and remodel while I'm rewhacking? All suggestions welcome, as I now have the dialog stuff in fresh memory. Maybe some data about a scenario author should be put into the scenario files? Something like: <authorinfo> <author>Foo Bar</author> <email>fo...@ex...</email> <version>1.3</version> <date>2001-02-28</date> <comments>My first scenario</comments> </authorinfo> could be put into the <scenarioinfo> tag. Everyone wants fame and fortune. We can provide fame to those who create scenarios. :-) --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Mike S. <mik...@de...> - 2001-02-03 03:19:53
|
Everything sounds cool. I'd add a <url> entry in the <authorinfo> stuff. mike Jan Ekholm wrote: > > Hi all, > > A little hacking made Civil a little more userfriendly again. The last > version had the clients wait until both players had connected before it > would allow them to continue with setting up the game. That was clearly > not good, the only place the server should have the clients wait is just > before the game should start. > > So, the thing behaves that way now. Players can connect independetly, > select scenarios and so on. Players can even disconnect and reconnect, and > the server manages those issues just fine. > > When clicking "Start game" a crash happens. I haven't got that far yet. > What is still missing before the game could run as before is to make a > main loop for the server, strip out all server-specific things from the > main loop of the clients. Also a few parameters need to be exchanged with > the server once the clients click "Start game", as the players must > obviously have chosen the same scenario and different sides (union, > rebel). > > Some dialogs now use the new MessageBox class to display errors. Still > need to replace all those print():s with messageboxes so that the player > really knows what went wrong. > > What else should I whack into pieces and remodel while I'm rewhacking? All > suggestions welcome, as I now have the dialog stuff in fresh memory. > > Maybe some data about a scenario author should be put into the scenario > files? Something like: > > <authorinfo> > <author>Foo Bar</author> > <email>fo...@ex...</email> > <version>1.3</version> > <date>2001-02-28</date> > <comments>My first scenario</comments> > </authorinfo> > > could be put into the <scenarioinfo> tag. Everyone wants fame and fortune. > We can provide fame to those who create scenarios. :-) > > --------------------+-------------------------------------------------------- > Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ > Linux Inside | I'm the blue screen of death, nobody hears your screams > > > _______________________________________________ > Civil-devel mailing list > Civ...@li... > http://lists.sourceforge.net/lists/listinfo/civil-devel -- ------------------------- Mike Szczerban | m...@sz... ------------------------- -- |
From: Jan E. <ch...@in...> - 2001-03-12 15:03:02
|
CVS ChangeLog: * scenario10.xml now is 600 turns long. * Leader now has a modifyBaseDelay() method for modifying a delay to reflect command control and leader skill etc. * Unit.getBaseDelay() now does something valid, and commands Move and Rotate uses it. * command Move now handles rotation internally. * MoveUnit no longer sends separate commands 'rotate' and 'move', only one 'move' is sent. This marks the beginning of using real delays when doing something with units. Earlier we've used very faked data, now the delays are calculated from the unit and its leader. Still a little fake, but better. Previously when moving a unit the state issued a 'rotate' first if needed, which was not really good. Now the 'move' command can internally perform the rotation if needed. Better handling of simultaneous commands. Previously when two commands were given to a unit almost at the same time the commands were applied in parallell, which was not the wanted thing. Now the commands are applied sequentially, i.e. the second starts when the first is finished. There are still some small bugs with that, but I'm working on them. Tomorrow it should work (famous last words). :-) --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Gareth N. <gar...@uk...> - 2001-03-12 15:07:46
|
Quoting Jan Ekholm <ch...@in...>: > CVS ChangeLog: > > * scenario10.xml now is 600 turns long. > * Leader now has a modifyBaseDelay() method for > modifying a delay to > reflect command control and leader skill etc. > * Unit.getBaseDelay() now does something valid, > and commands Move and > Rotate uses it. > * command Move now handles rotation internally. > * MoveUnit no longer sends separate > commands 'rotate' and 'move', only > one 'move' is sent. Wow! You've been really busy! Excellent work... I look forward to having a play when I get home tonight! :) G ------------------------------------------------- This mail sent through UK Online webmail |
From: Jan E. <ch...@in...> - 2001-05-03 10:05:18
|
Hi all, I did some work on the AI client, and this is what got whacked up: * AI client can now connect and select a scenario, side, host etc. I use it like this: % ./civil-ai.py --rebel --port=20000 --host=localhost --scenario=3 Errorhandling is still not quite ok, as the server will exit if the AI-client passes invalid data (such as an invalid scenario id). Normal players do not disconnect when they send invalid data and get an error back fro the server. The AI client however disconnects and this confuses the server a little bit. * ids are used to handle all scenario identification internally now. No visible changes, except when starting the AI client. * added directory src/ai/ for AI-related stuff. * AI client now has an own main loop in src/ai/event_loop.py. It has a hook where all AI code could be plugged in. I think the AI client will crash once events start to arrive from the other player, as the commands/plans will try to do graphical things too (the AI client is totally text based). * a few cursors modified. Phew. 'nuff for now.... --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Jan E. <ch...@in...> - 2001-05-07 11:18:47
|
Hi all, A quiet weekend is over, so I had to add some stuff to Civil to start the week and get going again. It is now possible to view the superior commanders/units for any selected unit. Just click on a unit and a light green line will trace all superior commanders for the unit (i.e. battallion, regimental, brigade, division (not yet in scenarios)). The display can be toggled by first deselecting any unit (click in the map) and pressing "6". The setting will be togglable from other states too, after I get the time to clean them up a little bit. The code is in src/playfield/commanders_layer.py There is now a handy method Unit.getSuperiors() that finds all superior commanders for the unit. If the unit itself contains the commander for some organization, say a regiment, then the method will return only those superior the the commander, not the full sequence. Ack phfth, that description sucks, please have a look at the source. I saw today that we've passed 20k lines of code. Amazing amounts of weird stuff. :-) --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Jan E. <ch...@in...> - 2001-05-17 10:42:19
|
The recent changes include (the CVS log message): * removed the ModeMachine classes from being used. They are not needed after all. Mode handling is taken care of by the Plan classes. * updated all Mode subclasses to set a number fo flag that describe what the mode can do. Methods in Mode are used to access the flags. * state class OwnUnit is patched to build up the keymap of available orders based on what the unit can do. The help dialog (show by pressing F1) is also built up dynamically by querying Mode. * implemented the 'change mode' functionality that lets a player change the mode of a unit from movement mode to battle mode, such as 'column' to 'formation'. Still needs some tweaks. * much other small things here and there to facilitate the modes. This basically means that things may be a little bit unstable for a while, as long as I fix up a basic working handling of the modes. It will be good, and I know what must be done, it is just quite a lot of stuff. All plans need to be patched to set the proper modes (e.g. the plan MoveFast must set the unit in a 'move fast' mode when the movement starts and restore the old mode when it ends. There is a new command SetModeCmd that is used for that (src/protocol/command/set_mode_cmd.py) --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Jan E. <ch...@in...> - 2001-05-22 06:51:05
|
Hi all, I added a small feature that enables the player to view information about the weapon(s) of the currently selected own unit. Pressing "i" (for info) brings up a dialog (similar to the help dialog) and shows info about the weapon. Click anywhere and the dialog disappears. What should I focus on doing now? Too much to do, too little time... --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Gareth N. <gar...@uk...> - 2001-05-22 08:04:39
|
> What should I focus on doing now? Too much to > do, too little time... I know what I'd like to see; a new map! But that's got nothing to do with the code, and I'm just being lazy... I should really do it myself... :) G ------------------------------------------------- This mail sent through UK Online webmail |
From: Jan E. <ch...@in...> - 2001-05-22 08:53:45
|
On Tue, 22 May 2001, Gareth Noyce wrote: >> What should I focus on doing now? Too much to >> do, too little time... > >I know what I'd like to see; a new map! But >that's got nothing to do with the code, and I'm >just being lazy... I should really do it myself... I'll do it. I've just had a few days of nightmarish stress with inivitation cards, getting the website up, bla bla... :-) --------------------+-------------------------------------------------------- Jan 'Chakie' Ekholm | Balrog New Media http://www.balrog.fi/ Linux Inside | I'm the blue screen of death, nobody hears your screams |
From: Jan E. <ch...@in...> - 2001-07-16 08:56:52
|
Hi all, After a few days quiet I added some stuff today. There was some code for asking questions from the user, and I now "made it work". So, there is now an easy and convenient way for all states in the game to ask questions from the user using the method askQuestion() and by binding the answer event to a callback. It is in use for quitting (Alt+q), surrendering (Alt+s) and cease fire (Alt+c). The ChangeLog: * layer QuestionLayer now works ok. * state Question now works ok. * state Idle now asks questions before quitting, surrendering and before offering a cease fire. * convenience method askQuestion() in State. * added event class QuestionDone that is posted by state Question when a question has been answered by the player. It does need a small tweak... If you try it out you'll see that both buttons on the dialog are "Close Help". :) They should either be Yes/No or Ok/Cancel. I use the icon gfx/dialogs/butt-help-close.png for now. May I add two items to your already too long ToDo-list, Gareth? Have you already regained conciousness from the weekend's partying? :D ----------------------------------------------------------------------------- Real children don't go hoppity-skip unless they are on drugs. -- Susan Sto Helit, in Hogfather (Terry Pratchett) |
From: Gareth N. <gar...@uk...> - 2001-07-16 14:42:04
|
Quoting Jan Ekholm <ch...@in...>: [SNIP] Excellent Jan. Useful stuff as ever! :) > May I add two items to your already too long > ToDo-list, Gareth? No problem! Small yes/no and ok/cancel buttons will be done this week for you... Might not be until tomorrow night though. Got accounts stuff to do tonight... > Have > you > already regained conciousness from the > weekend's partying? :D Just about. Had an excellent weekend. The party was ace, although the cleaning up was not! ;-) Felt Ok today, which was a bonus. However fighting FOP has killed my will to live... Can I get Java Extensions to work in it? Can I hell... Anyway, no more plans for mad nights/weekends for a while. Should be able to get some proper work done! :) G ------------------------------------------------- This mail sent through UK Online webmail |
From: Jan E. <ch...@in...> - 2001-08-31 17:37:44
|
I did some minor hacking today and added use of a new button in the setup dialogs. If you select a scenario and press "More info" you now get full info about the scenario. A new button is also used in that dialog. I also removed the file scenario/scenarioindex.xml, as it always should be generated by the player/developer to suit his/her system. it contains paths, and there has been more than one question as to why the server tries to load scenarios from /home/chakie. :) So now it must be regenerated manually when doing a checkout, as described in INSTALL. This should reduce the amount of problems new players/developers face. ----------------------------------------------------------------------------- Real children don't go hoppity-skip unless they are on drugs. -- Susan Sto Helit, in Hogfather (Terry Pratchett) |
From: Gareth N. <gar...@uk...> - 2001-09-08 12:52:50
|
At 16:05 31/08/01, you wrote: >I did some minor hacking today and added use of a new button in the setup >dialogs. If you select a scenario and press "More info" you now get full >info about the scenario. A new button is also used in that dialog. :) Kewl! >This should reduce the amount of problems new players/developers face. I think you're right with that. It does seem to be the biggest hurdle and the most confusing aspect... Cheers G -- "Computer games don't affect kids. I mean if Pacman had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music." -- Unknown -- |
From: Jan E. <ch...@in...> - 2001-09-07 12:35:04
|
I've done a few additions to the combat code today, among other a lot of new mode classes (src/mode/). These should sooner or later just "plug in" into the main state machine. What is still missing is the actual combat resolving code (who died and what happened), some states (src/state/) for assaults and attacks as well as some more modes for artillery. ----------------------------------------------------------------------------- Right, you bastards, you're... you're geography! -- Terry Pratchett, in Guards! Guards! |
From: Jan E. <ch...@in...> - 2001-09-24 08:28:56
|
Hi all, I added some terrain colors to hex.py so that all icons now have a color that is used in the minimap. This was just a few additions to the large static array in the file. Gareth made a new icon for selections, so there are now two icons. The first one is used for the "primary" selected unit, i.e. the one that was selected first. When selecting several units and moving them the clicked movement destination is that of the primary selected units, all other selected units move relatively to the primary unit. Another icon is used for the secondary units. I also changed the way BaseState.getSelectedUnit() works so that it returns the first unit from the list of selected units. I also have a few ideas for combat that need some input, but I'll send that later, or l8r as the 3l337 say. :) -- Sometimes it's better to light a flamethrower than curse the darkness. -- Terry Pratchett, Men at Arms |
From: Jan E. <ch...@in...> - 2002-01-11 13:29:40
|
Hi all, I started developing Civil seriously again after a month of very little action from my part. A few of the changes are fairly large, and a few are interesting. 1. the messages that were shown in the panel no longer are shown there. They are instead moved to the main playfield. A new message (e.g. chat) will be shown in th eupper right corner of the playfield, and further messages under it. To avoid filling the whole right side a max number of messages (changeable in properties) will be shown, and when too many messages arrive older ones will be removed. Old ones will also be removed after a certain time (currently 20s), so that they slowly jump-scroll up and finally vanish. Gareth has said he's not happy with the current panel design, and it will be redone at some point. Then the space where the messages were shown will be used for something else, possibly a list of orders for the current unit, or something else. 2. simple animation is now possible. Interested classed register a callback in a class AnimationManager with an interval for updates, and the manager then calls the callback when it's time to animate. Currently the minimum interval is 250ms (4fps), so nothing too fancy can be done. The interval could probably be dropped to, say, 50ms without too big a performance hit. I think. 3. I'm working on optimizing the playfield a little bit so that it can use a "dirty rect" for repainting. Currently a repaint has always blitted the whole damn thing, and it can get sluggish at times, for instance when the menu is shown and new items should be highlighted. It doesn't work yet, but I hope to get it done sooner rather than later. Other than that, there are a multitude of minor fixes all over the place. Nothing visible though. -- "Yes, bugger all that." said Nanny. "Let's curse somebody." -- Terry Pratchett, Wyrd Sisters |
From: Jan E. <ch...@in...> - 2002-01-29 10:44:39
|
Hi, For those who have ever looked at the code under state/ it has been a little messy. Especially asking questions from the player has been complex and hard to understand. It has used the state Question and messages send using the pygame event mechanism. I rewrote that a bit so that all event handling etc is in the Question class, and questions can be asked from the user like this in all State subclasses: # ask the player for confirmation if self.askQuestion ( ['Do you really want to quit?' ] ): # the answer to our quit question was accepted, do it ... else: # player does not want to quit ... Look at a diff for src/state/idle.py to see how things were changed and simplified. -- Five exclamation marks, the sure sign of an insane mind. -- Terry Pratchett, Reaper Man |
From: Jan E. <ch...@in...> - 2002-02-13 15:26:17
|
Phew... First batch of code for implementing executors and action is in, and works fairly ok. Lots of bugs, major bugs and buglest probably remain, but the grunt work is done. Please have a look at the new "plan executing" code in engine/executor/. I think it's a lot simpler than it was before. I moved a lot of common stuff out into some *_util files in order to get code reuse without inheritance. In case you feel like testing, only the orders "move" and "rotate" work yet. Comments etc are welcome. -- "Students?" barked the Archchancellor. "Yes, Master. You know? They're the thinner ones with the pale faces? Because we're a university? They come with the whole thing, like rats --" -- Terry Pratchett, Moving Pictures |