Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7587] branches/2.2/data/mods
On Fri, May 29, 2009 at 9:25 PM, bugina...@users.sourceforge.net wrote: Revision: 7587 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7587view=rev Author: buginator Date: 2009-05-29 19:25:03 + (Fri, 29 May 2009) Log Message: --- Move aivolution from globals to multiplay, as this mod is only for multiplay use. Fix the makefile.am and makefile.win32 (untested) as well. The NSIS script also needs to be updated. It now creates a desktop link that uses the wrong parameter. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7600] branches/2.2
On Sunday, 31 May 2009 at 2:47, bugina...@users.sourceforge.net wrote: Revision: 7600 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7600view=rev Author: buginator Date: 2009-05-31 02:47:27 + (Sun, 31 May 2009) Log Message: --- Update Changelog NSIS script again Modified Paths: -- branches/2.2/ChangeLog branches/2.2/pkg/nsis/warzone2100.nsi Your modified question is not quite correct, DejaVu Sans supports far more than English, French and German (I think all our languages except Chinese). Performance impact is also not quite right, it's rather long startup time on the first run after a reboot. I'm not sure what exactly the issue is (and I have no Vista+ machines handy to find out), but if I understood it correctly, the font cache gets deleted when restarting because its in a temp dir. Then removing the cachedirWINDOWSTEMPDIR_FONTCONFIG_CACHE/cachedir line from fonts.conf should help there (so the delay is _only_ on the first run). Anyway, how about shipping one config file with good substitutions, and having a Install Chinese font option (and others if we need more later), which downloads e.g. WenQuanYi and puts it into our font dir? And having all the installer actions documented so people can download/install stuff themselves would be nice as well. As would be a wiki page where the _exact_ file locations (for data, mods, savegames, screenshots, config file etc.) for the different systems are mentioned. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] [INFO] Website temporary down.
As you can notice, the whole server is down right now. Reason was a fresh installed virtual windows machine on the same host, which did a whole network scan in our hosters network. As result it triggered security measures which took down our whole subnet. Unlocking is a manual process and tomorrow is a holiday here in germany. So, the ETA is probably tuesday. I'm sorry for the trouble... best regards, Kamaze ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7587] branches/2.2/data/mods
On 5/31/09, Per Inge Mathisen per.mathi...@gmail.com wrote: On Fri, May 29, 2009 at 9:25 PM, bugina...@users.sourceforge.net wrote: Revision: 7587 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7587view=rev Author: buginator Date: 2009-05-29 19:25:03 + (Fri, 29 May 2009) Log Message: --- Move aivolution from globals to multiplay, as this mod is only for multiplay use. Fix the makefile.am and makefile.win32 (untested) as well. The NSIS script also needs to be updated. It now creates a desktop link that uses the wrong parameter. Nice catch. Fixed. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7600] branches/2.2
On 5/31/09, Christian Ohm chr@gmx.net wrote: On Sunday, 31 May 2009 at 2:47, bugina...@users.sourceforge.net wrote: Revision: 7600 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=7600view=rev Author: buginator Date: 2009-05-31 02:47:27 + (Sun, 31 May 2009) Log Message: --- Update Changelog NSIS script again Modified Paths: -- branches/2.2/ChangeLog branches/2.2/pkg/nsis/warzone2100.nsi Your modified question is not quite correct, DejaVu Sans supports far more than English, French and German (I think all our languages except Chinese). Performance impact is also not quite right, it's rather long startup time on the first run after a reboot. OK, so change it to: If you want to use a custom font, or need a Chinese font, then you should answer yes, all others should answer no. NOTE: on vista, reading the windows font directory can take a very long time, so the initial run of the program will be delayed, until that process is done. I'm not sure what exactly the issue is (and I have no Vista+ machines handy to find out), but if I understood it correctly, the font cache gets deleted when restarting because its in a temp dir. Then removing the cachedirWINDOWSTEMPDIR_FONTCONFIG_CACHE/cachedir line from fonts.conf should help there (so the delay is _only_ on the first run). If that line is removed, then it goes to cachedir~/.fontconfig/cachedir I have no idea where that will put the cache file then. The fontcache file isn't deleted from the temp directory after reboot/shutdown, at least, not on my system, but I have no way of knowing what it does on vista. The issue is, that if we allow fontconfig to read the windows font directory, and this is on vista, then it takes a very long time to create said cache. The only time we need to read the windows font directory is when we run into a language that DejaVu font don't support, or, people want to override the font that we are currently defaulting to. Anyway, how about shipping one config file with good substitutions, and having a Install Chinese font option (and others if we need more later), which downloads e.g. WenQuanYi and puts it into our font dir? And having all the installer actions documented so people can download/install stuff themselves would be nice as well. As would be a wiki page where the _exact_ file locations (for data, mods, savegames, screenshots, config file etc.) for the different systems are mentioned. I have no problem with packaging more fonts, I just can't test it. I tend to agree for the addition to the wiki about this info. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7600] branches/2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bugs buggy wrote: OK, so change it to: If you want to use a custom font, or need a Chinese font, then you should answer yes, all others should answer no. NOTE: on vista, reading the windows font directory can take a very long time, so the initial run of the program will be delayed, until that process is done. Do you want to use a custom font or a font supporting Chinese characters? Important: On Windows Vista the initial run of Warzone 2100 will take a very long time as the Windows font directory is read. The idea behind this text is: Ask the user what to do and then tell him/her about the possible consequences and give an explanation for that consequences at the end. Users aren't primarily interested in the reason, which is why I put it at the end. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKIrSo4y86f1GXLDwRAvDAAJwPbnuP7dvk7GO2bQsMDjoozlpb1QCffhqa Ci9lHaNDvYp4tcmaDA7mX4s= =62a6 -END PGP SIGNATURE- ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7600] branches/2.2
On Sunday, 31 May 2009 at 12:35, bugs buggy wrote: I'm not sure what exactly the issue is (and I have no Vista+ machines handy to find out), but if I understood it correctly, the font cache gets deleted when restarting because its in a temp dir. Then removing the cachedirWINDOWSTEMPDIR_FONTCONFIG_CACHE/cachedir line from fonts.conf should help there (so the delay is _only_ on the first run). If that line is removed, then it goes to cachedir~/.fontconfig/cachedir I have no idea where that will put the cache file then. The fontcache file isn't deleted from the temp directory after reboot/shutdown, at least, not on my system, but I have no way of knowing what it does on vista. The issue is, that if we allow fontconfig to read the windows font directory, and this is on vista, then it takes a very long time to create said cache. Yes, and that cache will be lost because it's not in a permanent dir, I think. So if we use a private directory instead (~/.fontconfig is probably not the best choice though), the cache should survive reboots. The only time we need to read the windows font directory is when we run into a language that DejaVu font don't support, or, people want to override the font that we are currently defaulting to. That's why I prefer using only our fonts. But that might need more time than we want to spend before releasing 2.2. Anyway, how about shipping one config file with good substitutions, and having a Install Chinese font option (and others if we need more later), which downloads e.g. WenQuanYi and puts it into our font dir? And having all the installer actions documented so people can download/install stuff themselves would be nice as well. As would be a wiki page where the _exact_ file locations (for data, mods, savegames, screenshots, config file etc.) for the different systems are mentioned. I have no problem with packaging more fonts, I just can't test it. That's the basic problem, we need someone with Vista who can test this stuff, and then we don't have to do all this guesswork. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[7600] branches/2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kreuvf wrote: Do you want to use a custom font or a font supporting Chinese characters? Important: On Windows Vista the initial run of Warzone 2100 will take a very long time as the Windows font directory is read. Möchten Sie eine andere Schriftart wählen oder eine Schriftart, die chinesische Zeichen unterstützt? Wichtig: Unter Windows Vista wird der erste Start von Warzone 2100 sehr viel Zeit benötigen, da das Windows-Schriftart-Verzeichnis gelesen wird. As mentioned on IRC, the de translation :D - - Kreuvf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKIrdK4y86f1GXLDwRAmlmAJ0TGToNxR+42RlxTLCafmgFjhsZSgCfU9aa dpFb7K3taGTHM4Ui8CrNos8= =js3i -END PGP SIGNATURE- ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Drag rearm pad building
This small patch makes it possible to drag a line of rearm pad
production similar to how walls and defenses can be built by dragging
the production with the mouse. It also removes the obligatory empty
tile between rearm pads.
The reason should be obvious - it is currently very tedious to build
massive VTOL rearm fields.
Posted here since wz2100.net is down.
- Per
Index: src/display.c
===
--- src/display.c (revision 7604)
+++ src/display.c (working copy)
@@ -565,7 +565,8 @@
sBuildDetails.psStats-ref (REF_STRUCTURE_START + REF_RANGE))
{
if STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_WALL
- || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_DEFENSE)
+ || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_DEFENSE
+ || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_REARM_PAD)
!isLasSat((STRUCTURE_STATS *)sBuildDetails.psStats))
{
wallDrag.x2 = mouseTileX;
@@ -608,7 +609,8 @@
sBuildDetails.psStats-ref (REF_STRUCTURE_START + REF_RANGE))
{
if STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_WALL
- || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_DEFENSE)
+ || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_DEFENSE
+ || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_REARM_PAD)
!isLasSat((STRUCTURE_STATS *)sBuildDetails.psStats))
{
wallDrag.x1 = wallDrag.x2 = mouseTileX;
@@ -686,7 +688,8 @@
if(buildState == BUILD3D_VALID)
{
if STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_WALL
- || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_DEFENSE)
+ || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_DEFENSE
+ || ((STRUCTURE_STATS *)sBuildDetails.psStats)-type == REF_REARM_PAD)
!isLasSat((STRUCTURE_STATS *)sBuildDetails.psStats))
{
int dx, dy;
Index: src/action.c
===
--- src/action.c (revision 7604)
+++ src/action.c (working copy)
@@ -1860,7 +1860,7 @@
psDroid-player,
false))
{
- debug( LOG_NEVER, DACTION_MOVETOBUILD: !validLocation);
+ objTrace(psDroid-id, DACTION_MOVETOBUILD: !validLocation);
psDroid-action = DACTION_NONE;
}
else
@@ -1870,9 +1870,9 @@
psDroid-actionPoints = 0;
}
}
- else if( (psDroid-order == DORDER_LINEBUILD||psDroid-order==DORDER_BUILD)
- (psStructStats-type == REF_WALL || psStructStats-type == REF_WALLCORNER ||
- psStructStats-type == REF_DEFENSE))
+ else if ((psDroid-order == DORDER_LINEBUILD || psDroid-order==DORDER_BUILD)
+ (psStructStats-type == REF_WALL || psStructStats-type == REF_WALLCORNER ||
+ psStructStats-type == REF_DEFENSE || psStructStats-type == REF_REARM_PAD))
{
// building a wall.
MAPTILE* const psTile = mapTile(map_coord(psDroid-orderX), map_coord(psDroid-orderY));
Index: src/structure.c
===
--- src/structure.c (revision 7604)
+++ src/structure.c (working copy)
@@ -4063,7 +4063,7 @@
}
//if we're dragging the wall/defense we need to check along the current dragged size
if (wallDrag.status != DRAG_INACTIVE
- (psBuilding-type == REF_WALL || psBuilding-type == REF_DEFENSE)
+ (psBuilding-type == REF_WALL || psBuilding-type == REF_DEFENSE || psBuilding-type == REF_REARM_PAD)
!isLasSat(psBuilding))
{
UWORDdx,dy;
@@ -4318,6 +4318,7 @@
if (!(psBuilding-type == REF_DEFENSE ||
psBuilding-type == REF_WALL ||
psBuilding-type == REF_WALLCORNER ||
+ psBuilding-type == REF_REARM_PAD ||
psBuilding-type == REF_MISSILE_SILO))
{
/*need to check there is one tile between buildings*/
@@ -4470,8 +4471,7 @@
BOOLvalidCombi;
//defense and missile silo's can be built next to anything so don't need to check
- if (!(psBuilding-type == REF_DEFENSE || psBuilding-type ==
-REF_MISSILE_SILO))
+ if (!(psBuilding-type == REF_DEFENSE || psBuilding-type == REF_MISSILE_SILO || psBuilding-type == REF_REARM_PAD))
{
for (psDroid = apsDroidLists[player]; psDroid; psDroid = psDroid-psNext)
{
@@ -4488,6 +4488,8 @@
{
if (psDroid-asOrderList[order].order == DORDER_BUILD)
{
+STRUCTURE_STATS *orderTarget = (STRUCTURE_STATS *)psDroid-asOrderList[order].psOrderTarget;
+
validCombi = false;
if (((STRUCTURE_STATS *)psDroid-asOrderList[order].
psOrderTarget)-type == REF_DEFENSE ||
@@ -4498,8 +4500,7 @@
}
//walls can be built next to walls and defence
if ((psBuilding-type == REF_WALL || psBuilding-type == REF_WALLCORNER)
- (((STRUCTURE_STATS *)psDroid-asOrderList[order].psOrderTarget)-type == REF_WALL
- || ((STRUCTURE_STATS
Re: [Warzone-dev] Drag rearm pad building
2009/5/31 Per Inge Mathisen per.mathi...@gmail.com: This small patch makes it possible to drag a line of rearm pad production similar to how walls and defenses can be built by dragging the production with the mouse. It also removes the obligatory empty tile between rearm pads. Um... but the obligatory empty line between rearm pads is like a staple of Warzone! We can make the drag only place every other rearm pad. We can just rewrite the drag routine to only place structures in the places they can go, instead of invalidating the whole line when only a few of them are in bad places. I've also been considering leaving the build menu up if a building is placed while Shift or Ctrl is held down. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Drag rearm pad building
On Sun, May 31, 2009 at 8:58 PM, Zarel zare...@gmail.com wrote: Um... but the obligatory empty line between rearm pads is like a staple of Warzone! Uhm... No? On maps that are more cramped, being able to build rearm pads without spaces between will be a god-send. It makes VTOLs a lot nicer to use. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] 2.2 has been released!
We have released 2.2. We have the source tarball, the Fedora rpm, and the windows installer all available on our SourceForge project page. Just need the Mac builds. http://sourceforge.net/projects/warzone2100/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Drag rearm pad building
On 5/31/09, Per Inge Mathisen per.mathixxx...@gmail.com wrote: This small patch makes it possible to drag a line of rearm pad production similar to how walls and defenses can be built by dragging the production with the mouse. It also removes the obligatory empty tile between rearm pads. The reason should be obvious - it is currently very tedious to build massive VTOL rearm fields. Posted here since wz2100.net is down. I like the idea of being able to build *anything* via the 'drag a line' approach. I thought that anything but the walls had spaces, so that the AI can find a path around it? I don't think units can drive over the rearm pads? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[Warzone-dev] Broken PhysFS zip support for Macs?
When the forums were up, there was talk that a few users couldn't load .wz files. After looking a bit, I found this thread on the ML, https://mail.gna.org/public/warzone-dev/2007-12/msg00129.html It seems it was never really fixed? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] 2.2 has been released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bugs buggy wrote: We have released 2.2. We have the source tarball, the Fedora rpm, and the windows installer all available on our SourceForge project page. Just need the Mac builds. http://sourceforge.net/projects/warzone2100/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev Thanks for the release announcement! 8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKI2rA4y86f1GXLDwRAtj7AKCKbzvnirMnydeIz2GKT6f+veZuEgCeJ/JO ukf6hXLaUxYVCTeCli4tGLA= =WwMR -END PGP SIGNATURE- ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
