Re: [warzone2100-dev] Remove armour hit sides
Am 19.02.2010 00:02, schrieb Safety Off: I don't think there is any point using it currently, simply because the user doesn't have enough control over the orientation/movement of the droids and their formations. I think that when droids turn they will expose their weaker side by no fault of the player, this will likely be more frustrating than anything else. Cheers, -Safety0ff I'm with i-NoD to keep this code and make it useable (at least in future). Right now, most fighting is just who has the best upgrades instead of unit tactics. Making flanking more attractive would add a lot of competition to warzone. And about the unit movement code, I guess we really need an update there, to implement such features as retreat (Moving backwards, which might be slower then driving forards, but it faces the good armor side to the enemy) and real formations. - Kamaze ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
On Fri, Feb 19, 2010 at 5:20 AM, NoName fearthec...@gmail.com wrote: I'm with i-NoD to keep this code and make it useable (at least in future). Right now, most fighting is just who has the best upgrades instead of unit tactics. Making flanking more attractive would add a lot of competition to warzone. And about the unit movement code, I guess we really need an update there, to implement such features as retreat (Moving backwards, which might be slower then driving forards, but it faces the good armor side to the enemy) and real formations. I don't know, seems like too much tactics. Our movement code is horrible; making fine-grained control of units necessary would suck for everyone... OTOH, I'd prefer not to change the mod format that much, so I'd vote to keep everything the way it is (lots of fixes to movement code notwithstanding). -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
Am 19.02.2010 12:27, schrieb Zarel: I don't know, seems like too much tactics. Our movement code is horrible; making fine-grained control of units necessary would suck for everyone... OTOH, I'd prefer not to change the mod format that much, so I'd vote to keep everything the way it is (lots of fixes to movement code notwithstanding). -Zarel I'm not talking necessarily about a fine graded single unit micromanagement, but more about a better group behaviour. World in Conflict is a very good example from my point of view. It just has 2 possible formations, a straight line and a simple quad. If you move units, you can also set easily where to face, by simply holding the mose button and then drag into the direction where to look. If you drag farther, the formation will be more loosely. It's somewhat simple and intuitive. Also a better group select would help a lot. Last but not least we still have _much_ potential using commanders. Using this, you could at lleast take down some havy tanks when attacking intelligent with weaker units. - Kamaze ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #1612: Unify commander levels
#1612: Unify commander levels ---+ Reporter: Zarel | Owner: Type: patch | Status: new Priority: major | Milestone: 2.3 Component: other |Version: svn/2.3 Keywords: | Operating_system: All/Non-Specific Blockedby: | Blocking: ---+ Hey, this is a quick proposal: Currently, units assigned to a commander have effective experience levels of: MAX(level, commanderLevel+1) in skirmish, and MAX(level, commanderLevel) in campaign I'd like to change these both to: MAX(level+1, commanderLevel) This ensures that there's always a reason to attach a unit to a commander, without otherwise changing balance. I'm also planning on making commanders gain levels twice as fast in campaign (so they match current MP). That makes them take 1024 experience to reach hero status (compare 512 for a normal unit, 1024 for an MP commander, and 2048 for a current campaign commander). Previously, hero commanders were practically never seen, so this should alleviate that somewhat. Barring objections, I'll be committing this in a few days (to 2.3, too - it's a balance change, and if you read it, there's nothing in there that can break anything, and it fixes a few bugs relating to commanders). -- Ticket URL: http://developer.wz2100.net/ticket/1612 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[9641] branches/2.3/win32/__BUILD_SCRIPT
On Fri, Feb 05, 2010 at 11:59:56PM +, bugina...@users.sourceforge.net wrote:
Revision: 9641
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=9641view=rev
Author: buginator
Date: 2010-02-05 23:59:55 + (Fri, 05 Feb 2010)
Log Message:
---
Change HOST_TRIPLET to be i586-mingw32msvc instead of mingw32 as the default
HOST_TRIPLET
Modified Paths:
--
branches/2.3/win32/__BUILD_SCRIPT
On Sun, Feb 07, 2010 at 05:27:55PM +, bugina...@users.sourceforge.net wrote:
Revision: 9722
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=9722view=rev
Author: buginator
Date: 2010-02-07 17:27:54 + (Sun, 07 Feb 2010)
Log Message:
---
Update cross-compiler build script to make use of --with-distributor
Modified Paths:
--
branches/2.3/win32/__BUILD_SCRIPT
On Sun, Feb 07, 2010 at 05:35:54PM +, bugina...@users.sourceforge.net wrote:
Revision: 9723
http://warzone2100.svn.sourceforge.net/warzone2100/?rev=9723view=rev
Author: buginator
Date: 2010-02-07 17:35:44 + (Sun, 07 Feb 2010)
Log Message:
---
fix a typo from previous commit
Modified Paths:
--
branches/2.3/win32/__BUILD_SCRIPT
None of these ^^ commits are necessary.
Using another HOST_TRIPLET than mingw32 can be achieved by specifiying
HOST_TRIPLET=${whatever_you_want} as command line argument to
__BUILD_SCRIPT.
Using a non-default distributor (remember that configure.ac already
uses UNKNOWN as its default) can be accomplished by specifying
--with-distributor=$distributor as command line argument to
__BUILD_SCRIPT.
The build script will pass *all* its arguments to the ./configure
script, so no special hacks are required to pass paramters to
./configure. Furthermore all arguments of the form \w+=.* (e.g.
VAR=val) will cause environment variables of that name to be
overridden.
Thus rather than complicating the cross build script any further I
suggest to revert the above commits.
--
Giel
signature.asc
Description: Digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Another release is planned on Feb 21st
buginator wrote: On 2/17/10, Guangcong Luo za...@x.net wrote: How's about RC 1a? RC 1b / 2 / whatever. I don't really care what we call it. :) AD 1 for Almost Done 1 or NYG 1 for Not Yet Gamma 1 :X - Kreuvf signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
Per Inge Mathisen wrote: Hello, In my effort to clean up the basic engine definitions, I would like remove the armour hit sides. This was added a while ago by Watermelon, and to my best knowledge it has never been used for anything useful or interesting, nor do players keep this in mind while playing or make use of it while micromanaging their units. It does, however, waste some memory for each game object, and we could get rid of some code complexity by removing this feature. So unless anyone complains, I will rip it out. I am all for removing it: 1. Too complex. 2. GUI not up to show people this. 3. Control over units not good enough to use the knowledge. 4. Even more stuff to consider when balancing (similar to too complex). 5. There already is enough variation/tactics in Warzone 2100. Less is more. - Kreuvf signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
I am all for removing it: 1. Too complex. 2. GUI not up to show people this. 3. Control over units not good enough to use the knowledge. 4. Even more stuff to consider when balancing (similar to too complex). 5. There already is enough variation/tactics in Warzone 2100. Less is more. - Kreuvf I still wonder what is s complex in this code? Could someone give me a hint, please? Yes, there is a usability problem due to 2 and 3, but I think those could be changed/fixed. I'm more then willing to make some improvements to current GUI (as I'm not much in betawidget stuff) and could start right from this task. I don't ask to change current stats/tactics model, I just want to allow some productive persons to use this feature in their mods and maps and invite some new tactics to gameplay - as more alternatives is not always bad (this will solve 4 and 5 for core game if you wish). I don't know for sure, but maybe a majority of modders/people aren't aware of the feature? We could re-announce it and just to see if it will interest someone. We could always remove it if not... just give another chance. i-NoD ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
i-NoD wrote: I am all for removing it: 1. Too complex. 2. GUI not up to show people this. 3. Control over units not good enough to use the knowledge. 4. Even more stuff to consider when balancing (similar to too complex). 5. There already is enough variation/tactics in Warzone 2100. Less is more. - Kreuvf I still wonder what is s complex in this code? Could someone give me a hint, please? I do not mean code-complexity. It's the gameplay itself that's getting too complex IMHO. There is enough stuff in the game that you have to worry about. Yes, there is a usability problem due to 2 and 3, but I think those could be changed/fixed. I'm more then willing to make some improvements to current GUI (as I'm not much in betawidget stuff) and could start right from this task. I don't ask to change current stats/tactics model, I just want to allow some productive persons to use this feature in their mods and maps and invite some new tactics to gameplay - as more alternatives is not always bad (this will solve 4 and 5 for core game if you wish). I don't know for sure, but maybe a majority of modders/people aren't aware of the feature? We could re-announce it and just to see if it will interest someone. We could always remove it if not... just give another chance. Some time ago Per posted his experiences from that Freeciv and IIRC one of the interesting things was: Don't make things for modders only/add only stuff that _you_ want to have in the game and that _you_ use. Per will be able to correct me if I'm wrong :) - Kreuvf signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
I do not mean code-complexity. It's the gameplay itself that's getting too complex IMHO. There is enough stuff in the game that you have to worry about. Some time ago Per posted his experiences from that Freeciv and IIRC one of the interesting things was: Don't make things for modders only/add only stuff that _you_ want to have in the game and that _you_ use. Per will be able to correct me if I'm wrong :) - Kreuvf Well, the idea was to give that feature second(or first?) chance, without disrupting current too complex gameplay. It could be promoted into core game or purged after that, as it's clear for me that mod-only feature (effectively unused) will not live long... That's is the only option I see in contrast to removal... i-NoD ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
There is no question that different armor values for front/side/rear hits more closely models the real world. And it would certainly add to the tactical nuances of the game. Good things, IMHO. HOWEVER: Right now the movement code makes a droid circle and expose what would be its most vulnerable sides instead of retreating backwards. Until this is changed, side values are a defect. People are arguing we can fix this and that and add some more code and all is well. No, we can't. Manpower is limited. The two biggest problem areas are the netcode and movement/orders. Better to focus our attention on refactoring those areas than make promises for future features. If you want to work on this, make a branch. This is a prime example of what branches are for. We look forward to your work. Bottom line: simple is better. Take it out. -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
Fine, I got you point and will not object more. And I already have one branch to keep up and there is no point to spread up even more. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #1614: Possible to start building of sixth cyborg factory in campaign
#1614: Possible to start building of sixth cyborg factory in campaign -+-- Reporter: Emdek |Type: bug Status: new |Priority: major Milestone: 2.3 | Component: Data: Scripts Version: 2.3 beta 10 |Keywords: Operating_system: All/Non-Specific | Blockedby: Blocking:| -+-- I've managed to start building sixth cyborg factory in campaign (gamma, mission 6). When it was done then game frozen (not crash) with 100% CPU usage on one (virtual) core. I've started to build 3 cyborg factories (3 were already done before). -- Ticket URL: http://developer.wz2100.net/ticket/1614 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #1615: Overwriting Autosave with full save game slots leads to lost of last save game
#1615: Overwriting Autosave with full save game slots leads to lost of last save game -+-- Reporter: Emdek |Type: bug Status: new |Priority: major Milestone: 2.3 | Component: other Version: 2.3 beta 10 |Keywords: Operating_system: All/Non-Specific | Blockedby: Blocking:| -+-- When we have all slots in save game menu already used and we create new save in place of Autosave entry then last save game will be lost after next launch of game (or probably when game is auto saved). Maybe it could be possible to allow more save games (in my case current limit is not enough, im saving game up to 9 times per mission sometimes) and display them in pages (like other things that do not fit on single screen)? And yes, we can manually copy saves to another directory, but it is not comfortable and not everyone knows that. And is there somewhere option to disable autosave? -- Ticket URL: http://developer.wz2100.net/ticket/1615 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #1616: View Frustum Culling
#1616: View Frustum Culling ---+ Reporter: i-NoD | Owner: Type: bug| Status: new Priority: major | Milestone: 3.0 Component: Engine: Graphics |Version: svn/trunk Keywords: clipping, culling | Operating_system: All/Non-Specific Blockedby: | Blocking: ---+ Here is a small patch to enable the aforementioned feature for trunk. Could be easily adapted for 2.3 too. What's for: currently WZ uses very simple algorithm (in clipXY() ) based on the distance between the tested point and player on the grid, it doesn't care if user actually sees the point (OpenGL will remove redundant data anyway, but it's still better to not process it beforehand). While it's not a problem for current low-poly graphics or/and when you've turned shadows off, it helps much in case with high-poly graphics and shadows on - we will process tiles that are actually visible on screen. The feature was stripped of some extensive functionality due to optimizations (like sphere bounding). To do less calculation every frame clipVFC() is based and guarded by whole clipXY() framework, effectively skipping processing of distant tiles. Also, you don't want to use clipVFC() when you do need clipXY(), consider 'shake screen' functionality with building that exploded behind you (so it's not visible on screen) is still triggering shakes. Based on code from: http://robertmarkmorley.com/opengl/frustumculling.html (hint: use Time Machine) -- Ticket URL: http://developer.wz2100.net/ticket/1616 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Remove armour hit sides
On 2/18/10, Per Inge Mathisen per.xx...@gmail.com wrote: Hello, In my effort to clean up the basic engine definitions, I would like remove the armour hit sides. This was added a while ago by Watermelon, and to my best knowledge it has never been used for anything useful or interesting, nor do players keep this in mind while playing or make use of it while micromanaging their units. It does, however, waste some memory for each game object, and we could get rid of some code complexity by removing this feature. So unless anyone complains, I will rip it out. While it is a good idea, it really wasn't finished, and implementation was pretty much at a standstill, and lots would have to change to make good use of this code. The same can be said about multi-turrets which still isn't really finished, and still is possible to make crappy looking units. Perhaps it is best to remove it, and those that want to improve this, just make a patch. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[9641] branches/2.3/win32/__BUILD_SCRIPT
On 2/19/10, Giel van Schijndel m...@x.eu wrote:
None of these ^^ commits are necessary.
Using another HOST_TRIPLET than mingw32 can be achieved by specifiying
HOST_TRIPLET=${whatever_you_want} as command line argument to
__BUILD_SCRIPT.
Well, while not 100% necessary, it didn't really make sense to keep
setting the HOST_TRIPLET, when it was always the same thing for both
of the people that built the windows builds.
Using a non-default distributor (remember that configure.ac already
uses UNKNOWN as its default) can be accomplished by specifying
--with-distributor=$distributor as command line argument to
__BUILD_SCRIPT.
The build script will pass *all* its arguments to the ./configure
script, so no special hacks are required to pass paramters to
./configure. Furthermore all arguments of the form \w+=.* (e.g.
VAR=val) will cause environment variables of that name to be
overridden.
This didn't work, in win32/ I did: ./__BUILD_SCRIPT
--with-distributor=blah and it would error out with unknown option.
That is why I did it like that.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] [Warzone 2100 Trac] #1617: Game will not start (skirmish mode) [proj_UpdateKills] Experience increase out of range
#1617: Game will not start (skirmish mode) [proj_UpdateKills] Experience increase out of range -+-- Reporter: lritc...@…|Type: bug Status: new |Priority: major Milestone: unspecified | Component: other Version: unspecified |Keywords: Operating_system: All/Non-Specific | Blockedby: Blocking:| -+-- game crashes afte selecting map and entering board to begin game play -- Ticket URL: http://developer.wz2100.net/ticket/1617 Warzone 2100 Trac http://developer.wz2100.net/ The Warzone 2100 Project ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
