Menu
▾
▴
craft-devel — For our developers.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(3) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(38) |
May
(33) |
Jun
|
Jul
|
Aug
(31) |
Sep
|
Oct
(13) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
(12) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Martin W. <meh...@we...> - 2004-04-15 15:08:46
|
Hey, Martin Wegner wrote: > [...] > >It is done ;) The libctl is now compiled as a shared library will commit >changes later on. Sateified? >[...] > Just committed the changes. You will have to run: $ make clean $ rm -R /path/to/install/* $ cvs update $ aclocal $ autoconf $ automake $ configure --prefix=/path/to/install $ make $ make install Then libctl should be a shared library again. Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Martin W. <meh...@we...> - 2004-04-15 15:02:42
|
Hey,
Arne Rempke wrote:
> [...]
> With this idea of adding some steps to the path and perhaps correcting
> some steps of a path calculated some time ago I don't think it is good
> to let CPathFinding directly edit the units queue which stores the
> path. I think it will be better to use the Event System: CPathFinding
> can push an path event every time it has a new part of a path (or the
> correction of an old one) and CUnit* only have to poll them and save
> the path in their local variables. That would be also intelligent in
> regard to network compatibility: It's not a good idea to send only the
> moving orders to the clients and let them all calculate a way using
> their CPathFinding because the pathfinding algorithm can return
> different results for the same order. On the other hand it is not very
> economic to send every changing of pixel offsets of the units to all
> clients because that would cause very much traffic. So I think it is
> not bad to only transfer these moving events and let the clients
> calculate the exact pixel positions on their own.
>
Implemented the necessary events. Let's have a look what you will have
to consider when dealing with it:
<code>
// create a new event
CEvent *my_event = new CEvent;
// create a new unit movement event
CEventUnitMovement *my_unit_event = new CEventUnitMovement;
// set appropriate data
my_event->type = CEVENT_UNIT_MOVEMENT;
my_unit_event->unit_id = the_units_id;
// set path
for(...) {
my_unit_event->path.push_back(dir)
}
my_event->unit_movement = my_unit_event;
// "send" the event
classes->event->push(my_event);
</code>
Now the polling:
<code>
// in the constructor or so
int my_handler = 0;
CEvent *my_event;
// at the appropriate position
// ATTENTION: DO NOT RESET my_handler OTHERWISE YOU MAY GET EVENTS TWICE !
while(my_event != 0) {
my_event = classes->event->poll(my_handler);
if(my_event->type == NEEDED_TYPE) {
// do whatever you want
}
}
</code>
Besides the events are now deleted after existing 5 seconds in the event
system. When setting up an event, don't care about the variable
create_ticks since it is set by push() . I also fixed the bug that the
first event could not be polled.
> [...]
Hoping everything is clear now.
Regards,
- Martin
--
Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12
--
Homepage: http://www.mwegner.de.ms/
Powered by Gentoo Linux (http://www.gentoo.org/)
|
|
From: Arne R. <arn...@gm...> - 2004-04-14 17:01:55
|
Hi, I've added a delete game; to main.cpp so it is possible now that destructors are called when quitting the game :D cya arne |
|
From: Arne R. <arn...@gm...> - 2004-04-14 16:53:52
|
Hi, > I've just revised the progress bar. You can add all calls of > setProgress() now again. I was able to speed up the drawing of the > progress bar with some changes in how it is drawed / blitted. The map > loading, for examle, is now almost as fast as without progress bar (a > little bit slowing down is not avoidable). Seems to work. I just decommented the lines giving feedback about the state of loading maptiles and loading the map. We will have to think about a solution for _one_ progress for a greater operation e.g. loading a game (that also means initializing and starting...) because it is not very nice to have several progresses and to count the hundrets of percents the game has already reached... cya arne |
|
From: Arne R. <arn...@gm...> - 2004-04-14 16:45:39
|
Hi, >>- Since this change I only have half as many loops per second as >>before... I think that's because of the semi-transparent panel. It >>would be nice to have the option to enable these alpha-blits and to >>disable them on older machines. (Ok, I'll add the option to craft.conf >>and read it in the kernel, but you'll have to provide a function to >>en-/disable it.) > > Hm, that's weird. I have only about 10% less LPS with control panel > enabled (36 instead of 40) which is acceptable, I think. Try to comment > drawControlPanel() in CVideo::display() out and tell me how your LPS > look like then. Perhaps alpha blitting is not hardware accelerated on > your machine (maybe try 16bit color depth)? > > I think that the alpha blitting of the panel can keep the overview on > smaller resolutions. Test what I said above, then we will see if we need > to make alpha blitting optional ... Oh, I thought it was that slow because of the blit, but I think I had an openoffice compiling at the same time, so that would be reason for little lps... Without the panel I get about 15% more frames, so it is aproximatly the same as you have. cya arne |
|
From: Arne R. <arn...@gm...> - 2004-04-14 16:34:01
|
Hi, I've rewritten CPathFinding. The old class processed different orders one after another. If these calculations took some time you could see the units start moving one after the other. That was not the idea you have when you order a group of units to go somewhere. So I think it is better to calculate only a part of the way in the beginning and let the unit walk very naive without considering any far barriers. Then the unit can walk along this short path and the CPathFinding can search for startpaths for other units. When they are all moving CPathFinding returns to the not already finished orders and calculates a bit more of the way. So after a while we sould get good paths for all the units and the units don't have to wait for the pathfinding algorithm. With this idea of adding some steps to the path and perhaps correcting some steps of a path calculated some time ago I don't think it is good to let CPathFinding directly edit the units queue which stores the path. I think it will be better to use the Event System: CPathFinding can push an path event every time it has a new part of a path (or the correction of an old one) and CUnit* only have to poll them and save the path in their local variables. That would be also intelligent in regard to network compatibility: It's not a good idea to send only the moving orders to the clients and let them all calculate a way using their CPathFinding because the pathfinding algorithm can return different results for the same order. On the other hand it is not very economic to send every changing of pixel offsets of the units to all clients because that would cause very much traffic. So I think it is not bad to only transfer these moving events and let the clients calculate the exact pixel positions on their own. For now the rewrite seems to work, but I till now CPathFinding just prints the found way to stdout and does not send an event because there is no structure for such an event :D Each event has to hold information about: - the unit that is supposed to walk the sent path (unitid? will it be the same on different machines in network?) - the starting point of the path: if the unit has already walked the first steps, don't order a completly new path but skip the first step in the sent way. I would propose a Point with x/cols and y/rows on the map. - the calculated path as a row of integers representing the directions to move. I'm not sure wheather a queue is good any more because we will have to merge paths and replace some parts of a path by others of another... what's about a vector<short>? What do you think about it? Who will implement the event? Does it belong to event.hpp or to pathfinding.hpp? cya arne p.s. I do not have yet commited this version of CPathFinding because you would not be able to move any units :D |
|
From: Martin W. <meh...@we...> - 2004-04-14 15:13:25
|
Hey, Martin Wegner wrote: >Hey, > >Christoph Peltz wrote: > > > >>On Wed, 2004-04-14 at 10:31, Martin Wegner wrote: >> >> >> >> >>>Hey kris, >>> >>>if I recall correctly we agreed not to commit binary files like bmps >>>into the CVS. Please remove elipse_enemy.bmp . Such files are to be >>>released within the multimedia package. Since this has to be created >>> >>> >>>from scratch (I think I'll do it this afternoon), you would have been >> >> >>>allowed to send it via mail =) . >>> >>> >>> >>> >>Aww, sry, I will remove it... >> >>Besides why have you made ctl a static lib? It is supposed to be a >>shared lib. >> >> >> >> >Because I had problems to compile it as a shared lib using the >autotools. So I made it static and it works fine! The problem with a >shared lib is that it has to be installed first, before we link e. g. >craft against it. That would result in making the libctl an extra >package which needs to be installed first. IMHO this is too complicated >since it is a lib which only craft depends on. > > > It is done ;) The libctl is now compiled as a shared library will commit changes later on. Sateified? >>I have also some problems with "make install" it does not copy any of >>the contents in shared/. Any suggestions? >> >> >> >> >Check out the share/Makefile.am again? Then automake, configure, make >clean, make, make install? If this does not work, send me your >share/Makefile.am . > > > >>BTW: there is i little bug in the scrolling code it seems.. normaly I >>will reach a scroll end, but if I drag a selectionrect it dows not stop, >>I can scroll till the next solar system, if ya understand what I mean >>^^. And as Martin I have a really accapable LPS count (65, it was nor >>much higher befor, maybe 1 or 2 LPS) >> >> >> >> >> >Fixed it. Was caused by some uninitialized variables. > > Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Martin W. <meh...@we...> - 2004-04-14 14:00:42
|
Hey, Christoph Peltz wrote: >On Wed, 2004-04-14 at 10:31, Martin Wegner wrote: > > >>Hey kris, >> >>if I recall correctly we agreed not to commit binary files like bmps >>into the CVS. Please remove elipse_enemy.bmp . Such files are to be >>released within the multimedia package. Since this has to be created >>from scratch (I think I'll do it this afternoon), you would have been >>allowed to send it via mail =) . >> >> > >Aww, sry, I will remove it... > >Besides why have you made ctl a static lib? It is supposed to be a >shared lib. > > Because I had problems to compile it as a shared lib using the autotools. So I made it static and it works fine! The problem with a shared lib is that it has to be installed first, before we link e. g. craft against it. That would result in making the libctl an extra package which needs to be installed first. IMHO this is too complicated since it is a lib which only craft depends on. >I have also some problems with "make install" it does not copy any of >the contents in shared/. Any suggestions? > > Check out the share/Makefile.am again? Then automake, configure, make clean, make, make install? If this does not work, send me your share/Makefile.am . >BTW: there is i little bug in the scrolling code it seems.. normaly I >will reach a scroll end, but if I drag a selectionrect it dows not stop, >I can scroll till the next solar system, if ya understand what I mean >^^. And as Martin I have a really accapable LPS count (65, it was nor >much higher befor, maybe 1 or 2 LPS) > > > Fixed it. Was caused by some uninitialized variables. Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Christoph P. <fir...@we...> - 2004-04-14 12:44:47
|
On Wed, 2004-04-14 at 14:36, Christoph Peltz wrote: > BTW: there is i little bug in the scrolling code it seems.. normaly I > will reach a scroll end, but if I drag a selectionrect it dows not stop, > I can scroll till the next solar system, if ya understand what I mean > ^^. And as Martin I have a really accapable LPS count (65, it was nor > much higher befor, maybe 1 or 2 LPS) huh, I have made a little mistake sry, it does not scroll to the next system ^^, but it is clearly over the scrolling end (because the whole screen is black). It also only does this if you drag a selection rect from somewhere upper left to down right (that is by me the case). When you go back up left and see the map and release the mouse button there is an seg fault, I will look closer to it, maybe I find something more detailed information. cya Kris |
|
From: Christoph P. <fir...@we...> - 2004-04-14 12:32:40
|
On Wed, 2004-04-14 at 10:31, Martin Wegner wrote: > Hey kris, > > if I recall correctly we agreed not to commit binary files like bmps > into the CVS. Please remove elipse_enemy.bmp . Such files are to be > released within the multimedia package. Since this has to be created > from scratch (I think I'll do it this afternoon), you would have been > allowed to send it via mail =) . Aww, sry, I will remove it... Besides why have you made ctl a static lib? It is supposed to be a shared lib. I have also some problems with "make install" it does not copy any of the contents in shared/. Any suggestions? BTW: there is i little bug in the scrolling code it seems.. normaly I will reach a scroll end, but if I drag a selectionrect it dows not stop, I can scroll till the next solar system, if ya understand what I mean ^^. And as Martin I have a really accapable LPS count (65, it was nor much higher befor, maybe 1 or 2 LPS) cya Kris |
|
From: Christoph P. <fir...@we...> - 2004-04-14 11:56:42
|
Hi, On Wed, 2004-04-14 at 00:37, Martin Wegner wrote: > Hey, > > Arne Rempke wrote: > > >>> What about "Is player's unit or not?" because I think the behaviour at > >>> clicking at an enemy's unit or at a neutral unit or at an allied > >>> unit is > >>> always the same: only select 1 unit. Maybe we should do it this way ... > >> > >> > >> but a Enemy unit should be attacked a Neutral unit not? Or am I wrong? > > > > > > the internal computing of figthing will be based on the direct player > > ids, won't it? So the computing algorithm has to compare the owners > > and only let them fight if the owners are different. But I think > > Martin's concern is to decide wheather a unit is controllable by the > > guy sitting in front of the local machine or not. And so I think a > > function like isHumansUnit() would be nice. > > > > To sum it up: > - If the player selects more than one of the enemy's units only one > should be selected. > - If the player selects one unit it does not matter whom the unit belongs to > > Therefore, what has to be defined now is what to do if the player > right-clicks an enemy's or a neutral unit. > > I think: If the player right-clicks an enemy's unit, the selected units > should attack this unit. But if he right-clicks on a neutral unit, > nothing happens and he has to say "attack" explicitly. At least, most > games handle it this way ... > > That means, that I only have to distinguish on a right click between > neutral and enemy units, right? ATM, I will implement a function called isPlayerUnit(), because even the neutral unit should be attacked implicit (think about harvesting). cya tomorrow Kris |
|
From: Martin W. <meh...@we...> - 2004-04-14 08:30:21
|
Hey kris, if I recall correctly we agreed not to commit binary files like bmps into the CVS. Please remove elipse_enemy.bmp . Such files are to be released within the multimedia package. Since this has to be created from scratch (I think I'll do it this afternoon), you would have been allowed to send it via mail =) . Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Martin W. <meh...@we...> - 2004-04-14 08:22:03
|
Hey, I've implemented that you can click in the minimap and the big map jumps to that position. In CVS right now. Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Martin W. <meh...@we...> - 2004-04-13 22:36:16
|
Hey, Arne Rempke wrote: >>> What about "Is player's unit or not?" because I think the behaviour at >>> clicking at an enemy's unit or at a neutral unit or at an allied >>> unit is >>> always the same: only select 1 unit. Maybe we should do it this way ... >> >> >> but a Enemy unit should be attacked a Neutral unit not? Or am I wrong? > > > the internal computing of figthing will be based on the direct player > ids, won't it? So the computing algorithm has to compare the owners > and only let them fight if the owners are different. But I think > Martin's concern is to decide wheather a unit is controllable by the > guy sitting in front of the local machine or not. And so I think a > function like isHumansUnit() would be nice. > To sum it up: - If the player selects more than one of the enemy's units only one should be selected. - If the player selects one unit it does not matter whom the unit belongs to Therefore, what has to be defined now is what to do if the player right-clicks an enemy's or a neutral unit. I think: If the player right-clicks an enemy's unit, the selected units should attack this unit. But if he right-clicks on a neutral unit, nothing happens and he has to say "attack" explicitly. At least, most games handle it this way ... That means, that I only have to distinguish on a right click between neutral and enemy units, right? Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Martin W. <meh...@we...> - 2004-04-13 22:36:04
|
Hello, I've just revised the progress bar. You can add all calls of setProgress() now again. I was able to speed up the drawing of the progress bar with some changes in how it is drawed / blitted. The map loading, for examle, is now almost as fast as without progress bar (a little bit slowing down is not avoidable). Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Martin W. <meh...@we...> - 2004-04-13 22:35:57
|
Hey, Arne Rempke wrote: > [...] > >> I've just committed a major update of my sources to CVS. First of all >> I've completely revised the scrolling borders. The player is now not >> able to leave the map too far but as far as it should be to see even the >> units at the border. Second, I worked on using Arne's minimap since he >> was so kind to implement it ;) . The result is a half transparent >> control panel at the bottom of the screen with the minimap at the left >> side. I also implemented that the current screen clip is displayed in >> the minimap. Apart from that the control panel has no further functions. >> Currently I'm working on that the player can click into the minimap and >> the "big" map jumps also to that position. > > > Looks not bad, but... > - Since this change I only have half as many loops per second as > before... I think that's because of the semi-transparent panel. It > would be nice to have the option to enable these alpha-blits and to > disable them on older machines. (Ok, I'll add the option to craft.conf > and read it in the kernel, but you'll have to provide a function to > en-/disable it.) Hm, that's weird. I have only about 10% less LPS with control panel enabled (36 instead of 40) which is acceptable, I think. Try to comment drawControlPanel() in CVideo::display() out and tell me how your LPS look like then. Perhaps alpha blitting is not hardware accelerated on your machine (maybe try 16bit color depth)? I think that the alpha blitting of the panel can keep the overview on smaller resolutions. Test what I said above, then we will see if we need to make alpha blitting optional ... > - The scrolling borders are better than before, but still not optimal :D > If an unit is standing on the top of a map (on 0/0) e.g. I still only > see its feet... and a unit standing at the bottom of a map can not be > selected by a single click (because of the panel). > You are right. I realized that also. I could backtrace this to the border checking which was done in a wrong order. Corrected it and it is woking fine. > [...] Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Arne R. <arn...@gm...> - 2004-04-13 20:54:14
|
Hi, >>What about "Is player's unit or not?" because I think the behaviour at >>clicking at an enemy's unit or at a neutral unit or at an allied unit is >>always the same: only select 1 unit. Maybe we should do it this way ... > > but a Enemy unit should be attacked a Neutral unit not? Or am I wrong? the internal computing of figthing will be based on the direct player ids, won't it? So the computing algorithm has to compare the owners and only let them fight if the owners are different. But I think Martin's concern is to decide wheather a unit is controllable by the guy sitting in front of the local machine or not. And so I think a function like isHumansUnit() would be nice. cya arne |
|
From: Arne R. <arn...@gm...> - 2004-04-13 20:45:49
|
Hi, > I've just committed a major update of my sources to CVS. First of all > I've completely revised the scrolling borders. The player is now not > able to leave the map too far but as far as it should be to see even the > units at the border. Second, I worked on using Arne's minimap since he > was so kind to implement it ;) . The result is a half transparent > control panel at the bottom of the screen with the minimap at the left > side. I also implemented that the current screen clip is displayed in > the minimap. Apart from that the control panel has no further functions. > Currently I'm working on that the player can click into the minimap and > the "big" map jumps also to that position. Looks not bad, but... - Since this change I only have half as many loops per second as before... I think that's because of the semi-transparent panel. It would be nice to have the option to enable these alpha-blits and to disable them on older machines. (Ok, I'll add the option to craft.conf and read it in the kernel, but you'll have to provide a function to en-/disable it.) - The scrolling borders are better than before, but still not optimal :D If an unit is standing on the top of a map (on 0/0) e.g. I still only see its feet... and a unit standing at the bottom of a map can not be selected by a single click (because of the panel). > Sry, Arne, but I had to add a few lines to your map.cpp since they were > a really big danger for hardware damage or even program crashes: the > minimap surface has to be locked / unlocked before / after the use of > drawPx(). This is also written in the source documentation for > CVideo::drawPx(). And because you were not reachable, I had to do this, > just before the first users complain about broken hardware ;) Sorry, I did not know that. Thanks for correcting it. cya arne |
|
From: Christoph P. <fir...@we...> - 2004-04-13 20:18:32
|
On Tue, 2004-04-13 at 18:46, Martin Wegner wrote: > Hey, > > Christoph Peltz wrote: > > >On Tue, 2004-04-13 at 14:48, Martin Wegner wrote: > > > > > >>Hey, > >> > >>Christoph Peltz wrote: > >> > >> > >> > >>>[...] > >>> > >>> > >>> > >>>a bug, but very near). All files which have changed have been attached > >>>to this mail (except the CHANGELOG, I do not think that you guys need > >>>this). > >>> > >>> > >>> > >>> > >>> > >>I may be wrong but isn't that the task of the CVS? What about some cvs > >>commit's? Better than sending the changes via mail. > >> > >> > >I was somewhat confused, because Arne and I did not know who is supposed > >to commit the changes or, that everyone will commit the changes he made > >etc. > > > > > Everyone his own changes, that's the best way and Arne and I already did > so ... > > >>>Now to you Martin: It would be really usefully if you find a way to > >>>stop, that we can command enemy units, maybe with a function from the > >>>unitmanager (isEnemyUnit or something out of this direction). > >>> > >>> > >>> > >>> > >>isEnemyUnit() sounds good. I guess you will expect the coordinates of > >>the click, wont you? Correct me if I'm wrong =) Implement that and I > >>will do my turn ... > >> > >> > >Yeah right, but I think I also implement isNeutralUnit() ^^ and > >isAlliedUnit()...arg maybe I think over it, but at the moment I will > >write isEnemyUnit for ya > > > > > What about "Is player's unit or not?" because I think the behaviour at > clicking at an enemy's unit or at a neutral unit or at an allied unit is > always the same: only select 1 unit. Maybe we should do it this way ... but a Enemy unit should be attacked a Neutral unit not? Or am I wrong? night Kris |
|
From: Arne R. <arn...@gm...> - 2004-04-13 18:25:56
|
Hi Kris,
> I fucking hate this CVS repository one update and you can not use your
> source anymore and after a clear checkout it develops random
> features...:
> kernel.cpp: In member function `void CKernel::run()':
> kernel.cpp:240: error: declaration of `void CKernel::addPlayer(int)'
> outside of
> class is not definition
> kernel.cpp:240: error: parse error before `{' token
> kernel.cpp:246: error: case label `PT_KI' not within a switch statement
> kernel.cpp:250: error: case label `PT_NET' not within a switch statement
> kernel.cpp:254: error: `default' label not within a switch statement
> kernel.cpp:245: error: break statement not within loop or switch
> kernel.cpp:249: error: break statement not within loop or switch
> kernel.cpp:253: error: break statement not within loop or switch
> kernel.cpp: At global scope:
> kernel.cpp:257: error: parse error before `}' token
> make[2]: *** [kernel.o] Error 1
> make[2]: Leaving directory `/home/firewing/Projekte/game/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/firewing/Projekte/game'
> make: *** [all] Error 2
I just thought it was a problem with my local sources, because I had the
same problem about half an our ago, but it seems, the file in cvs is
corrupted. Since web-cvs says the file has not been altered for 5 days I
don't know why the 7 lines are duplicated in cvs. I just commited the
corrected file, so it should work now.
cya arne
|
|
From: Arne R. <arn...@gm...> - 2004-04-13 17:39:07
|
Hi Kris, sorry, but I just realized that I deleted the section which creates units for the different players. So with version 1.20 of kernel.cpp it's right that there are no enimy units. But in version 1.21 half of the units should belong to the second player. Additionally I just commited the map sources because I renamed the tiles option mapcolor into minimapcolor. So you'll probably have to edit some share/tiles/*.tiles cya arne |
|
From: Martin W. <meh...@we...> - 2004-04-13 16:45:21
|
Hey, Christoph Peltz wrote: >On Tue, 2004-04-13 at 14:48, Martin Wegner wrote: > > >>Hey, >> >>Christoph Peltz wrote: >> >> >> >>>[...] >>> >>> >>> >>>a bug, but very near). All files which have changed have been attached >>>to this mail (except the CHANGELOG, I do not think that you guys need >>>this). >>> >>> >>> >>> >>> >>I may be wrong but isn't that the task of the CVS? What about some cvs >>commit's? Better than sending the changes via mail. >> >> >I was somewhat confused, because Arne and I did not know who is supposed >to commit the changes or, that everyone will commit the changes he made >etc. > > Everyone his own changes, that's the best way and Arne and I already did so ... >>>Now to you Martin: It would be really usefully if you find a way to >>>stop, that we can command enemy units, maybe with a function from the >>>unitmanager (isEnemyUnit or something out of this direction). >>> >>> >>> >>> >>isEnemyUnit() sounds good. I guess you will expect the coordinates of >>the click, wont you? Correct me if I'm wrong =) Implement that and I >>will do my turn ... >> >> >Yeah right, but I think I also implement isNeutralUnit() ^^ and >isAlliedUnit()...arg maybe I think over it, but at the moment I will >write isEnemyUnit for ya > > What about "Is player's unit or not?" because I think the behaviour at clicking at an enemy's unit or at a neutral unit or at an allied unit is always the same: only select 1 unit. Maybe we should do it this way ... Regards - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |
|
From: Christoph P. <fir...@we...> - 2004-04-13 15:17:28
|
hy guys,
I fucking hate this CVS repository one update and you can not use your
source anymore and after a clear checkout it develops random
features...:
kernel.cpp: In member function `void CKernel::run()':
kernel.cpp:240: error: declaration of `void CKernel::addPlayer(int)'
outside of
class is not definition
kernel.cpp:240: error: parse error before `{' token
kernel.cpp:246: error: case label `PT_KI' not within a switch statement
kernel.cpp:250: error: case label `PT_NET' not within a switch statement
kernel.cpp:254: error: `default' label not within a switch statement
kernel.cpp:245: error: break statement not within loop or switch
kernel.cpp:249: error: break statement not within loop or switch
kernel.cpp:253: error: break statement not within loop or switch
kernel.cpp: At global scope:
kernel.cpp:257: error: parse error before `}' token
make[2]: *** [kernel.o] Error 1
make[2]: Leaving directory `/home/firewing/Projekte/game/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/firewing/Projekte/game'
make: *** [all] Error 2
I do not find the failure, maybe you have more luck...
really annoyed Christoph Peltz
|
|
From: Christoph P. <fir...@we...> - 2004-04-13 13:51:34
|
On Tue, 2004-04-13 at 14:48, Martin Wegner wrote: > Hey, > > Christoph Peltz wrote: > > >[...] > > > > >a bug, but very near). All files which have changed have been attached > >to this mail (except the CHANGELOG, I do not think that you guys need > >this). > > > > > > > I may be wrong but isn't that the task of the CVS? What about some cvs > commit's? Better than sending the changes via mail. I was somewhat confused, because Arne and I did not know who is supposed to commit the changes or, that everyone will commit the changes he made etc. > > >Now to you Martin: It would be really usefully if you find a way to > >stop, that we can command enemy units, maybe with a function from the > >unitmanager (isEnemyUnit or something out of this direction). > > > > > isEnemyUnit() sounds good. I guess you will expect the coordinates of > the click, wont you? Correct me if I'm wrong =) Implement that and I > will do my turn ... Yeah right, but I think I also implement isNeutralUnit() ^^ and isAlliedUnit()...arg maybe I think over it, but at the moment I will write isEnemyUnit for ya > > >Ill maybe phone you the next days. > > > > > Yeah maybe mhh, but I think thats not really necessary.. > > Regards, > > - Martin bye Kris |
|
From: Martin W. <meh...@we...> - 2004-04-13 12:50:07
|
Hey kris, I just saw that you haven't commit your source code changes from our programming LAN yet. I recommend to do so now. Regards, - Martin -- Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12 -- Homepage: http://www.mwegner.de.ms/ Powered by Gentoo Linux (http://www.gentoo.org/) |