Re: [Warzone-dev] Approaching Version 2.0.6

[Kamaze]

About the documentation,
why not create a subfolder like www.wz2100.net/docs/,
it is absolutly no problem to give kim (for example) access to this.

Maybe we can integrate or port it some day into the wiki.
(Integrating them as pure HTML code -we tried that- will break the HTML
code and make xss attacks easily possible, so don't ask for that :))

Oh, because we talking about the wiki: i'll play around with MediWiki
this weekend. To replace dokuwiki. It looks like the most people are
more familar with the MediaWiki software/syntax. But it is a bit
difficult to integrate the forums-accounts as wiki-accounts.

And i'll will register at ModDB these days, and try to add WZR again :)

- Kamaze

Dennis Schridde schrieb:
 Am Donnerstag, 15. Februar 2007 schrieb Christian Ohm:
 On Monday, 12 February 2007 at 23:50, Dennis Schridde wrote:
 In the roadmap (http://wz2100.net/wiki/roadmap:2.0.6) only one bug is
 left, which I want to fix for 2.0.6 (empty config file on Windows).
 Any hints on that? Delaying the release for a bug you don't have any
 idea on how to tackle seems a bit pointless... (same as some of the
 others you listed).

 Anyway, I'd like to improve the current documentation a bit (inspired by
 the long comment at http://happypenguin.org/show?Warzone%202100), that
 might take some time, so if the release is delayed for a bit that could
 be added as well.

 Oh, and how about a release candidate for 2.0.6? Not as see if anyone
 finds some bugs in it, that can be done by the release as well. But add
 the return TRUE to disable videos, and ask people to especially report
 any problems related to that (so perhaps its more a test release than a
 release candidate - just a name, anyway). That'll have the effect of
 delaying the release a bit as well, and gives people something to play
 with in the meantime.

 (some time later) Ah, well, I don't want to rewrite all that, I'll look
 some more into the video issue, so take the previous paragraph with a
 grain of salt.

 And finally, the release checklist is missing run ./autogen.sh to
 create the build system for the source tarball, and happypenguin.org to
 announce the release on (any other interesting sites?).
 Excellent game, shame about the documentation and not having one central 
 Warzone 2100 online resource.
 
 I just found out that I did not include the README in the Linux package. It 
 is 
 not even installed by default...
 
 And he is absolutely right... If someone not knowing anything about Warzone 
 comes along the way, he will be totally lost...
 
 And as he mentioned what I experienced earlier: Kim, could you send me the 
 raw 
 HTML files (NOT compiled into a .chm)?
 
 --Dennis
 
 PS: (About 3 hours after I wrote the part above)
 The README, COPYING, etc. files are now installed by default on Linux. The 
 AutoPackage and NSIS installer will also contain them.
 
 
 
 
 ___
 Warzone-dev mailing list
 Warzone-dev@gna.org
 https://mail.gna.org/listinfo/warzone-dev

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Please apply this patch

[Gerard Krol]

Giel van Schijndel wrote:

Giel van Schijndel schreef:
  

Gerard Krol schreef:
  


I know I only posted it only 4 days ago, but I really sleep better
when I know my patches have been applied. Could someone apply this
patch? I even polished it a little bit more.

This patch prevents a segfault when designing a droid on amd64.
Reproduce: on amd64, go to the droid design screen and design a
construction droid. Then hover your mouse over another system, like
sensor or command.

Regards,

Gerard

  

Applied in r750.

Hope you did sleep well enough those 4 days? Anyway I'm hoping you'll
sleep better now again  ;-) .


Sorry, I haven't looked at your latest patch until after committing the
previous one.

Anyway your latest version looks a bit ugly to me. There's an awfully
large amount of casts in there, not to mention that your insertion of
that switch statement uses the variable `type` which at that point isn't
yet initialized = undefined behaviour.
  

Oops, I guess that must be a copy-paste error.

Plus I'm not quite sure what the difference is between the first and
second patch. Not meaning to offend you though.
  
I just noticed that my patch created a lot of warnings (16) about 
'warning: initialization from incompatible pointer type'. The second 
patch was a quick attempt to solve that problem. A little too quick as 
it seems.


I tought about it a little and the attached patch avoids the casting 
problem and also doesn't give the warnings.


- Gerard
Index: src/design.c
===
--- src/design.c	(revision 762)
+++ src/design.c	(working copy)
@@ -3615,14 +3615,14 @@
 	UDWORDpower, i;
 
 	if (psStats != NULL) {
-COMP_BASE_STATS* bodyStats = asBodyStats + sCurrDesign.asParts[COMP_BODY];
-COMP_BASE_STATS* brainStats = asBrainStats + sCurrDesign.asParts[COMP_BRAIN];
-COMP_BASE_STATS* sensorStats = asSensorStats + sCurrDesign.asParts[COMP_SENSOR];
-COMP_BASE_STATS* ECMStats = asECMStats + sCurrDesign.asParts[COMP_ECM];
-COMP_BASE_STATS* repairStats = asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT];
-COMP_BASE_STATS* constructStats = asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT];
-COMP_BASE_STATS* propulsionStats = asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION];
-COMP_BASE_STATS* weaponStats = asWeaponStats + sCurrDesign.asWeaps[0];
+UDWORD bodyPower= (asBodyStats + sCurrDesign.asParts[COMP_BODY])-buildPower;
+UDWORD brainPower   = (asBrainStats + sCurrDesign.asParts[COMP_BRAIN])-buildPower;
+UDWORD sensorPower  = (asSensorStats + sCurrDesign.asParts[COMP_SENSOR])-buildPower;
+UDWORD ECMPower = (asECMStats + sCurrDesign.asParts[COMP_ECM])-buildPower;
+UDWORD repairPower  = (asRepairStats + sCurrDesign.asParts[COMP_REPAIRUNIT])-buildPower;
+UDWORD constructPower   = (asConstructStats + sCurrDesign.asParts[COMP_CONSTRUCT])-buildPower;
+UDWORD propulsionPower  = (asPropulsionStats + sCurrDesign.asParts[COMP_PROPULSION])-buildPower;
+UDWORD weaponPower  = (asWeaponStats + sCurrDesign.asWeaps[0])-buildPower;
 
 
 		type = statType(psStats-ref);
@@ -3662,25 +3662,25 @@
 		switch (type)
 		{
 		case COMP_BODY:
-			bodyStats = psStats;
+			bodyPower = psStats-buildPower;
 			break;
 		case COMP_PROPULSION:
-			propulsionStats = psStats;
+			propulsionPower = psStats-buildPower;
 			break;
 		case COMP_ECM:
-			ECMStats = psStats;
+			ECMPower = psStats-buildPower;
 			break;
 		case COMP_SENSOR:
-			sensorStats = psStats;
+			sensorPower = psStats-buildPower;
 			break;
 		case COMP_CONSTRUCT:
-			constructStats = psStats;
+			constructPower = psStats-buildPower;
 			break;
 		case COMP_REPAIRUNIT:
-			repairStats = psStats;
+			repairPower = psStats-buildPower;
 			break;
 		case COMP_WEAPON:
-			weaponStats = psStats;
+			weaponPower = psStats-buildPower;
 			break;
 		//default:
 			//don't want to draw for unknown comp
@@ -3689,15 +3689,15 @@
 		// this code is from calcTemplatePower
 
 	//get the component power
-	power = bodyStats-buildPower + brainStats-buildPower + sensorStats-buildPower + ECMStats-buildPower + repairStats-buildPower + constructStats-buildPower;
+	power = bodyPower + brainPower + sensorPower + ECMPower + repairPower + constructPower;
 
 	/* propulsion power points are a percentage of the bodys' power points */
-	power += (propulsionStats-buildPower *
-		bodyStats-buildPower) / 100;
+	power += (propulsionPower *
+		bodyPower) / 100;
 		
  	//add weapon power
 // FIXME: Only takes first weapon into account
-power += weaponStats-buildPower;
+power += weaponPower;
 	for(i=1; isCurrDesign.numWeaps; i++)
 	{
 		power += (asWeaponStats + sCurrDesign.asWeaps[i])-buildPower;
@@ -3727,14 +3727,14 @@
 	UDWORDbody, i;
 
 	if (psStats != NULL) {
-