[warzone2100-dev] This list will terminate On Feb-29-2012.
Greetings all, In order to get a more reliable mailing list that don't eat legitimate mail, we have now moved our traffic to our other host, Source Forge. https://lists.sourceforge.net/lists/listinfo/warzone2100-project is the new list. If you wish to subscribe, do so. Again, this list will terminate On Feb-29-2012, and be made a archive only list. Thanks for your cooperation. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Sun, Feb 19, 2012 at 11:08 AM, Per Inge Mathisen wrote: On Fri, Feb 17, 2012 at 3:10 AM, buginator wrote: Because we have lots of events being called (and more being added all the time) that not every script should be forced to implement just to make the warnings disappear. Eh ? You are inviting bugs then, as can be seen by 001ef35faf1. I've fixed up the lint tool, and will be adding code to detect such errors in it. Are you talking about be00eb4577603c56416005380d017177075130a4 ? While testing like that is good, it don't really work unless you use it... The codebase is still firing off events and if it isn't in the script then it should be yelling that it can't find it, otherwise you open up a can of worms, making pretty much all bug reports much, much harder to see if the problem is in the codebase, or if it just happens to be a script that didn't implement said missing function. What? Surely the bug reports will be harder to read when they are full of meaningless warnings. LOG_WARNING only displays when compiled in debug builds, not release. That means we can have instant feedback, not waiting for a separate tool to be run. When we make builds for release, then those are not shown. If the script writer wants to ignore said missing function, then they can NOP the function in question. This slows down processing of events *significantly*. And then I add a new event, and all old scripts start to produce warnings. How would it be significantly slower, all the function does is NOP, and there shouldn't be any major overhead in that. Adding it to the 'list of functions that are not used in game' is hardly more trouble than remembering to update the external tool to check for the new event/trigger. Some scripts will then contain a few functions of real code, and dozens of no-op functions. Ugly. You can put the ones that aren't used in one (or more files, perhaps splitting them on what they are used for, like attack, defense, structures, and so on...) file and just include that in any script that don't need to override that. We definitely should be warning/throwing out errors on all missing triggers or events. Triggers, yes. Events, no. Events are equally as important as triggers. In both cases, the game fires / calls it, and if not found, it means that it was either a bug (which the LOG_WARNING would have found in real-time, not wait for reports from the field or using the external utility which may or may not find the issue), or expected behavior, since it is unused. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Thu, Feb 16, 2012 at 9:23 AM, Per Inge Mathisen wrote: A script should not get a warning for every event it does not implement. If you want to warn about misnamed timers, this function needs an additional bool parameter that is not set for events. If you want to warn about misnamed events, then we could check for functions named event*() but not in the set of defined events on load (could be a job for lint, but not sure if that is the right tool for the job anymore). On Thu, Feb 16, 2012 at 2:49 PM, Christian Ohm wrote: It looks to me that change adds a warning if we call any undefined function. I noticed this behaviour already when I used a wrong function name, and it took a bit to find the problem, since the game just silently ignored that line. If the script calls a function that doesn't exist, why would we ever not want to know about that? Because we have lots of events being called (and more being added all the time) that not every script should be forced to implement just to make the warnings disappear. Eh ? You are inviting bugs then, as can be seen by 001ef35faf1. The codebase is still firing off events and if it isn't in the script then it should be yelling that it can't find it, otherwise you open up a can of worms, making pretty much all bug reports much, much harder to see if the problem is in the codebase, or if it just happens to be a script that didn't implement said missing function. If the script writer wants to ignore said missing function, then they can NOP the function in question. We definitely should be warning/throwing out errors on all missing triggers or events. So far, the debuggability of javascript seems not much better than that of wzscript, maybe integrating a QScriptEngineDebugger would help there. When wzscript triggered a crash or assertion, you would not know from which line or even file the error came from. Now you get a nice backtrace. That is the difference between being able to debug and not. Wzscript itself has the same debugging capabilities as the current JS scripts, spam printf's/asserts in your code. The issue with WZscript was in the back end, and how the interpreter was created with rudimentary recovery/error reporting. In my fastplay conversion to JS--which did fully work, doing a 1:1 conversion from WZscript, I noticed how poor the debugging capabilities we had with qtscript were, which is when I tried to get QScriptEngineDebugger working, but I quickly found out it had the same limitations with the way we are using qt handling the update draw calls. If we really want a good debugger, then, at this time the only option I see is go with a external script engine (V8 along with the debugger that is available for that--if we still want to stick with JS) Oh, I know that Qt will be using V8 soonish, but that still won't fix the issue mentioned above. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 3.1 release strategy ?
Need some clarification on the release strategy. Namely: 3.1 goes into the beta cycle this weekend with the first build. 3.1.x will be for bug fixes only. 3.2 will be the next feature(s) from master 3.2.x will be bug fixes only. 4.0 will be for major features sitting in the repo in a feature branch. This correct ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-sf-private] -dev eats mails
On Tue, Jan 24, 2012 at 8:20 PM, dak180 dak...@users.sourceforge.net wrote: On 2012/01/24, at 3:19 PM, Per Inge Mathisen wrote: On Tue, Jan 24, 2012 at 8:42 PM, Christian Ohm chr@gmx.net wrote: On Monday, 23 January 2012 at 21:04, buginator wrote: Eh ? where did this come from, I see no mail from dak180 anyplace, so no idea what the context of this was. Seems they get eaten by the mailing list. So what now? A new gna list, where we hope that'll not start eating things? A google group? A sf list (mirrored to a google group for usable archive)? My vote goes to a google groups list. Another option that I was just made aware of is that launchpad.net also has mailman based lists so we might want to take a look at that. In particular pabs3 tells me that Canonical employ one of the mailman developers, so it likely has good support. Ok, why is it, it only eats some of your mail ? Anyway, launchpad.net might not work, since in https://help.launchpad.net/Teams/MailingLists says 'Postings by people who are not Launchpad members are immediately discarded. ' If I understand that correctly, it means that you need to have a launchpad account there...not sure if that makes a difference to us or not. For googlegroups, I guess we can do a test to see how it is like. warzone-2100-...@googlegroups.com is the test group to see how it deals with all the stuff. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The dirt trail to 3.1
On Fri, Jan 20, 2012 at 12:49 PM, Christian Ohm chr...@gmx.net wrote: So, ehm, do we have a plan for 3.1? From my suggestion: - Scrap the current 3.0. - Update mingw-cross-env to sdl 1.2.15. - Integrate quesoglc. - Make a new 201201xx snapshot. - Possibly fix stuff. We are currently here. Is the template/hq stuff now fixed in git (or could it be done in the scripts now)? Or should we revert the changes for 3.1 and keep them only for master? Anything else that needs to be done? Are Safety0ff's buffer swap and vexed's lobby patches final? The lobby patch works as intended, but, the backend infrastructure needs to be fixed. The last time I tried Safety0ff's patch, it did fix the issues I saw/had. - Possibly wait for the official sdl 1.2.15. http://www.libsdl.org/download-1.2.php It is out. Maybe we don't have to wait for that... - Then branch 3.1, and do a beta1 release immediately. And for this, git-flow or the old way? A properly done git-flow has the advantage of commit hashes being the same in different branches, making changelog writing easier. If we keep the old way, I guess I'll only do it for 3.1, not master. I am not sure what needs to be done, we keep doing commits (bug fixes) to master like always, and have new features in their own branch, and then finally merge that back into master and remove that branch. If so, that could be quite the challenge trying to get everyone on the same page, and up to speed. It becomes hellish switching to new branches because of compiler cache files and there is currently no way for git to 'pack up' these files when you switch to the new branch, so things become clobbered. Anyway, the main thing about this is, that we are a very small group, and I just don't see people creating feature branches for the heck of it, since most of us just work locally, and when done, we either throw a patch on trac, or just commit it anyway. The only exception to this would be if they are going to alter Warzone in a way that most people wouldn't like, so for major changes, that needs to be in a branch. Since you already made 3.1, I just want to make sure we are clear on how we will handle this going forward. Namely, once we start up on the 'beta cycle', there will be no new features allowed, it will be locked down, and only bug fixes are applied. In the meantime, those same bug fixes were already applied to master (and whatever feature branch the person is currently working on--and don't forget to rebase once you pull all the changes down from master!) On Fri, Jan 20, 2012 at 1:54 PM, Christian Ohm chr.x...@gmx.net wrote: On Friday, 20 January 2012 at 13:39, dak180 wrote: I would prefer to wait for that for three reasons: I don't think it's necessary for a beta, if we get to that before the SDL release, and any rc/final will be after that anyway. Eh ? where did this come from, I see no mail from dak180 anyplace, so no idea what the context of this was. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 932d45: Generate the quickstart guide and add it to the ap...
On Thursday, 5 January 2012 at 7:48, nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/Warzone2100/warzone2100 Commit: 932d45244dd74dc61a208cf738be2b78e8a3b035 https://github.com/Warzone2100/warzone2100/commit/932d45244dd74dc61a208cf738be2b78e8a3b035 Author: dak180 dak...@users.sourceforge.net Date: 2012-01-05 (Thu, 05 Jan 2012) On Thu, Jan 5, 2012 at 6:12 PM, Christian Ohm chr@gmx.net wrote: Why do the generated files have to be in git? Good question, not to mention all the other mac related stuff that seems totally unnecessary. I purpose we drop all mac stuff that isn't the main project files, and just have a dev package like all the other build systems have. This is extra noise for no real purpose. Why should we care if lib X got updated to a new version, this should ALL be in the dev package. One the same subject, I also think we should nuke the .gitattributes file that specify some mac only files. It just makes merges much more painful for no real purpose besides to annoy the person who is doing the merges. If those files can't be handled gracefully by the normal git merge routines, they must be edited anyway, and since there is only one person that can fix those issues, I see no reason at all to block git from attempting to merge it in the first place. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 579e15: Add possibility to balance weapons against body ty...
On Sun, Dec 18, 2011 at 6:44 PM, nore...@github.com wrote:
Branch: refs/heads/master
Home: https://github.com/Warzone2100/warzone2100
Commit: 579e1502cb20cb4ffdd1b669837ee921a6deb2fe
https://github.com/Warzone2100/warzone2100/commit/579e1502cb20cb4ffdd1b669837ee921a6deb2fe
Author: Per Inge Mathisen p...@wz2100.net
Date: 2011-12-18 (Sun, 18 Dec 2011)
Changed paths:
M src/ai.cpp
M src/projectile.cpp
M src/stats.cpp
M src/stats.h
M src/statsdef.h
Log Message:
---
Add possibility to balance weapons against body types, not just propulsion
types.
Why was this added/needed, I don't really see a need for this ?
It also trashes memory since sizeof(asWeaponModifier) != sizeof(
asWeaponModifierBody)
I guess you can hack it via:
if (j = SIZE_NUM)
{
asWeaponModifierBody[i][j] = 100;
}
to fix the issue, but, do whatever.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 19f785: Make sure that PACKAGE stings get defined even wit...
On Sun, Sep 25, 2011 at 2:29 PM, nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/Warzone2100/warzone2100 Commit: 19f7851c0034d01dbc7317b4eaedce237efa2571 https://github.com/Warzone2100/warzone2100/commit/19f7851c0034d01dbc7317b4eaedce237efa2571 Author: dak180 dak...@users.sourceforge.net Date: 2011-09-25 (Sun, 25 Sep 2011) Changed paths: M lib/framework/wzglobal.h Log Message: --- Make sure that PACKAGE stings get defined even without the presence config.h. This should make MSVC builds work again. Fixes #2897. This still doesn't make sense, why have all those defines if the *only* place that uses them for anything are autot-tools, which means linux the CC build environment. We don't need them in the source for anything, so why add them ? Also, can you please stop abusing git notes ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Videos have been re-encoded
Forum member Ezio has re-encoded the video files. The thread is located here: http://forums.wz2100.net/viewtopic.php?f=6t=7796 They have done: 480pv3 4:3 919 MB and 720p 4:3 1.04 GB Right now, we have low quality and standard quality. We could drop the standard, and have low 480p (don't think there is much demand for 720p because of the problems discussed in that thread) or go with low / std / high. What do you all think ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 6dd85b: Merge branch 'refs/heads/topic/QJson'
On Mon, Jul 11, 2011 at 9:50 PM, nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/Warzone2100/warzone2100 Commit: 6dd85baedfc6bb8b50d48d49a7f5e05ca6dfe798 https://github.com/Warzone2100/warzone2100/commit/6dd85baedfc6bb8b50d48d49a7f5e05ca6dfe798 Author: dak180 dak...@users.sourceforge.net Date: 2011-07-11 (Mon, 11 Jul 2011) Log Message: --- Merge branch 'refs/heads/topic/QJson' Can we please stop doing these worthless commit messages ? It doesn't take that long to make a commit message that can be easily parsed so we know what is going on. Again, we have no idea what is being done without looking at all the changes. p.s, Thanks, but no thanks, there will be no bastardization of the normal operators with the alternative operator representations--requires special header file should NEVER be used in our code. die, alternative operator representations, die! ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Reorganization of maps
On Mon, Jul 11, 2011 at 10:33 PM, Fastdeath fastde...@pc-dummy.net wrote: On 2011-07-11 23:52, Per Inge Mathisen wrote: 1) All map files contain amap name.ini file - this replaces the currentmap name.gam file and the map's addon.lev entry. 2) Maps are moved to data/maps/ which containsmap name.ini and either amap name.zip OR amap name/ directory for each map 3) On game binary startup, the maps/ directory is iterated for .zip files that do not have a corresponding .ini file. Each of them are mounted, and the .ini file is extracted. This way we have a complete .ini coverage of all maps. 4) In pregame, only the .ini files are consulted for GUI purposes. The maps are never mounted before one is selected (for preview). I completely agree with 1. it will make things a lot simpler. For 2,3,4: I think its easier to load ALL maps in the GUI and read the ini's from the zip's. That why we don't have to keep the ini's in sync (update/removal). My proposal: 1.) Keep all maps as .zip file including the internal ones. 2.) Mount all .zips and read the ini's at the GUI. 3.) Tell the binary which .zip to load at game startup. Yes, all maps should (and need) to be in the basic zip file. The rest is pretty much how it does things now, but it needs to be rewritten to be more saner. However, since we are talking about ini file for this stuff, I did have a plan that looked like this: Type: [map or mod or mapmod or music] MapName [full Map name that can be up to 250 length] InternalMapName [Max of WZ's current limit]--however, since savegames are being rewritten, this may not be needed Version [starting at 1, incremented on each new revision by 1] DefaultWells: [low / med / high] (still thinking about this) CRC checksum [MD5 hash of the data] Description [1 line description, 80 chars max] License [whatever license type they picked for said map] Author [,,,] Compiled Data [...] Compiler Version [...] Standalone: [yes/no] ModRequired: [which mod (if any) is required to use this map] PreviousAuthors [...maybe] MaxTechLvl [...] CustomDataSet [... used to point to a directory INSIDE the zip file that should be used.] (NOTE: this can be toggled off!) and of course, the normal WZ data that it needs: level Test1-T1 players 2 type14 dataset MULTI_CAM_1 gamemultiplay/maps/2c-Test1.gam datawrf/multi/skirmish2.wrf datawrf/multi/fog1.wrf ... and so on. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 793c30: Merge branch 'bsonlobby' into master
On Fri, Jul 8, 2011 at 12:02 PM, nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/Warzone2100/warzone2100 Commit: 793c30a862627427282630bed87af8a3774bf719 https://github.com/Warzone2100/warzone2100/commit/793c30a862627427282630bed87af8a3774bf719 Author: Rene Jochum from_github@net Date: 2011-07-08 (Fri, 08 Jul 2011) Changed paths: A 3rdparty/bson/Makefile.am A 3rdparty/bson/bson.c A 3rdparty/bson/bson.h A 3rdparty/bson/numbers.c A 3rdparty/bson/platform_hacks.h Note, it seems that the license for this stuff is Apache 2, and that doesn't mesh well with our license, so, I believe, that we can't have this in our repo. It doesn't look like having static or dynamic version of this changes anything either. From a quick look at bson I don't really see any version that meshes well with GPL v2... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 793c30: Merge branch 'bsonlobby' into master
On Fri, Jul 8, 2011 at 12:02 PM, nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/Warzone2100/warzone2100 Commit: 793c30a862627427282630bed87af8a3774bf719 https://github.com/Warzone2100/warzone2100/commit/793c30a862627427282630bed87af8a3774bf719 Author: Rene Jochum from_github@ Date: 2011-07-08 (Fri, 08 Jul 2011) Log Message: --- Merge branch 'bsonlobby' into master Conflicts: macosx/Warzone.xcodeproj/project.pbxproj A heads up would have been nice before the merge, this touched a lot of things, and changes things around, and requires new libs. The bigger problem is, that commit message tells us nothing. What does this patch do, how are things changed, and what the new files (*.pem) will be used/generated for, and finally, a bit more info on the SSL connections and connections that don't use that ? Oh, speaking of SSL, is the master server's code ready on that end ? It also seems like you didn't pull in master and rebase your patch on top before the push. The graph looks pretty screwy now, since you didn't rebase when you tried to pull in some past checkouts. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Raycasting algorithm
On Fri, Jul 8, 2011 at 2:03 PM, Safety0ff safety0ff. wrote: I was looking in raycast.cpp on other business and I noticed that the callback could potentially be called twice for one tile, or not at all, depending on how the ray crosses the tile. So I'm wondering whether anyone has noticed this before and if there are opinions about changing/fixing this. Nope, and no opinion at this time. Too busy with other stuff. :( ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] adding a linear algebra library
On 5/19/11, Safety0ff @gmail.com wrote: On 19/05/11 05:41 AM, Per Inge Mathisen wrote: I am, but I think we should use the recently released Eigen 3, which is still not much supported on linux distros. Not sure if that means we should inline it in our own distribution for a while. By the time master is stable for release, Eigen 3 is probably everywhere, and we can drop our own copy of it. - Per That is exactly what I was thinking. Sounds like a plan. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Using Qt for a front end for Warzone ?
I was pondering, if switching to a Qt frontend for Warzone would be a good idea or not ? All current menus the lobby screen would be using Qt's GUI. Warzone will then be launched from the frontend. Anything that needs configuring would be written to the config file (or perhaps we can pass things via command line if really needed). Can anyone think of any reason not to do this ? I guess we can use Qt Creator to do most of the work, but I am unsure how skinning works with Qt, and how we will get our famous 'Warzone Blue' into the GUI. :) Any other ideas ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On 4/24/11, Kreuvf kre...@warzone2100.de wrote: One thing is missing: a map editor. A new map format is of little value without an appropriate map editor or in other words: people need to be able to switch to the new format. The only map editor that we have anyone maintaining is flaME. So we would need to work with him, since that editor is written in visual basic I believe, and most people don't use that, or have access to it. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On 4/24/11, Christian Ohm chr@gmx.net wrote: On Sunday, 24 April 2011 at 10:04, Per Inge Mathisen wrote: This will have some consequences, like not being able to aim for a stable release from master in a while, I've wondered if the concept of stable release is actually useful for us. Looking at 2.3, it seems to languish mostly, while people work on new stuff. I am of the same opinion, 'stable release' is a misnomer. So, proposal for a more git-like workflow: -1. Get master into a reasonably stable state. 0. New features are developed in feature branches. Bugfixes to a specific feature go into the feature branch as well, even after it got merged. (Generally, merges go only in one direction, no back-merges from master into other branches.) 1. Merge feature branches deemed ready. 2. Test and get them really ready. 3. Release. 4. Goto 1. That way new features get released reasonably quickly, and we don't have to keep care of an outdated release branch. Also, work on features doesn't destabilize master before they're merged, and if they do after merging, they can be unmerged relatively easy again. Could maybe be enhanced with a wip branch where all currently worked on feature branches get merged regularly, to see how they work together. If a bugfix release is needed before the next proper release, it can just be branched from the release as needed. * We merge Qt branch into master immediately. No objections from me. Right, that is mostly what we do, or have done in the past, is it not ? The issue(s) are that we have no good way to test things, and things slip through the cracks. There was a ton of changes done to get the netcode working, then a ton more changes to get Qt integrated, and a ton of changes before either of those that never was really widely tested. This leaves us with what we have now. One huge codebase that needs lots of fixing to get back to working order for both SP MP--however, I feel that MP is more or less working, so doing MP only releases will get more people playing those releases, since the vast majority of our userbase is using 2.3.X. Doing a MP only release (no SP/skirmish), we don't have to worry about savegames, and we can see how well the netcode is working (which still hasn't been widely tested). Once all this stuff is stabilized, then we can go back to the 'old way'--though, we still have no good way to test things. The main issues I see are: Savegames Script system Rendering / map format Mac issues / 0 mac developers. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] demote Asserts to LOG_INFO
On 4/24/11, Per Inge Mathisen xxx...@gmail.com wrote: On Sun, Apr 24, 2011 at 6:36 AM, buginator xxx...@gmail.com wrote: Unless there are any objections, I plan to demote ASSERT_FAILURE() to use LOG_INFO instead of LOG_ERROR. The main reason for this is that LOG_ERROR is meant for serious errors, and all LOG_ERRORs are echoed to the in game console on all platforms. LOG_INFO is still on in both debug release builds. The other option is LOG_WARNING, which is only enabled in debug builds. Objections ? I thought an assert error was a serious error. At least most serious error nowadays are reported in the form of an assert(_or_return). Maybe we should remove some asserts and / or fix some bugs instead? There is a difference between when we get those errors, and the end-user. We don't dump any useful information most of the time, and the only way to see what is going on is have a deep stack dump along with all vars. As Kreuvf pointed out, having a log with a bunch of asserts really does not help us do anything, since we can't replicate it, and even if we can replicate it, some of those can't easily be fixed since they happen in the gamestate before the current one, and we don't have a stack dump that goes that far back. In short, we have asserts that fire, and we *know* there is a issue, but can't get at that issue for multiple reasons. No need to spam the in-game console with assert messages. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] demote Asserts to LOG_INFO
Unless there are any objections, I plan to demote ASSERT_FAILURE() to use LOG_INFO instead of LOG_ERROR. The main reason for this is that LOG_ERROR is meant for serious errors, and all LOG_ERRORs are echoed to the in game console on all platforms. LOG_INFO is still on in both debug release builds. The other option is LOG_WARNING, which is only enabled in debug builds. Objections ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Partial merging of Qt branch
On 4/16/11, Per Inge Mathisen per.mathi...@gmail.com wrote: Hello, Qt branch still appears to have some issues that need to be looked at, but also is collecting work that makes it diverge rapidly from master. I am in particular thinking about my own recent work on savegames (using QSettings) and javascript (using QtScript). These do not depend on the Qt mainloop, and could be merged into master without dropping SDL/quesoglc for drawing. It also includes the use of QString. It would mean dependency bloat, but it is not meant to be a permanent solution. I think if we do this, we can aim for a 3.0 release based on SDL/QuesoGlc and bits and pieces of Qt, with a new savegame format and the beginnings of a new scripting system at the end of summer holidays. That is very optimistic. The brakes were put on a 3.0 release for more reasons besides the savegame format scripting issues. We still have the terrain rendering issues at hand, that throws everything off, and to fully fix that, we need a better map format, among other things. This would give us some more time to polish the Qt branch and for Qt 4.8 to get out the door and into distributions. I think the improved OpenGL support in Qt 4.8 might help us quite a bit, and we might also look into using Qt Quick for GUI widgets. Opinions? Not sure what is in store with Qt 4.8, but we can only hope it gets faster in the areas we need. In the end, if it saves us headaches, then I don't have objections. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Intent to merge, intent to destroy
On 3/30/11, Per Inge Mathisen per.mathi...@gmail.com wrote: The QtScript branch (perim/qtscript) now has a working implementation of javascript for scavengers. The old scripting system runs fine side by side with it. Saving and loading works as well. The code should be short and easy to understand, but I have been writing it incrementally by myself, so it is inevitable that I have overlooked obvious things that ought to have been documented or explained better. Or have added bugs alongside features. Or made really poor API choices. The latter is perhaps the least worrisome. If the merger is approved and completed, I will start explaining and documenting the new javascript API on the forums, and take suggestions for improvements, as it is fleshed out. I would like for someone to review the changes in the branch, if possible. I would also like to merge it into the qt branch very soon. Any objections to this should be voiced now. If you think it is ready, and the old scripts still work as before, then I have no real objections. Will this always be the case though ? Will the old scripts still be supported after Qtscript is finished ? Are we going to offer some kind of conversion utility ? As for code review, we need more hours in the day. :( On 3/30/11, dak180 dak...@users.sourceforge.net wrote: Instead of deleting or freezing lua as a tag, after having talked it over with cybersphinx on irc I think that we should move dead branches to a clone on sf.net set aside for this purpose. I would suggest something based upon attic or graveyard for the name. What would be the point of this ? Even if you delete lua, it is still in the repo, so we can just do what we do with all the other branches that are done/not-used/experiment-that-failed. Tag them, and then do :branch-name ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Savegame format changes
While discussing the current savegame format, it was brought to my attention that we currently have this ticket about a proposed new format. http://developer.wz2100.net/ticket/652 Unsure of the status, and if we want to go that route or not. Another possible idea, is stuffing everything into a sql database, and handle savegames that way (one database file per savegame) Yet another idea was to use BSON. sidenote: the tagfile stuff should be nuked as well. The changes by abomination were a bit overzealous, since in a72c41aeec0136c86007739a97ccc9ed508c0283, BOOL was a sizeof(int), and now it is a sizeof(byte), and that is fubaring the savegame structures that in the past were of sizeof(int) (4 bytes), and now are sizeof(bool) (1 byte)... Do we care about breaking SP savegames ? Comments ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Backend system (SDL or Qt) + GUI comments
Qt's future is ??? SDL 1.3 (2.0) future is good, now that Sam is doing this full time, and has other people working for his company. Converting to SDL 1.3 won't be that difficult AFAICS. Converting to Qt is mostly all done, it (did) mostly work on MSVC, and linux when I tried, but haven't tried in awhile. We still have major mac issues I believe, with both keyboard input and output (Display keys). We also have the issues mentioned in http://developer.wz2100.net/ticket/1549 to deal with. The GUI is more or less ok for in-game, and crap everywhere else. I think we can use Qt's GUI for all the setup/lobby screen, and forget about the current way we use the current GUI for this stuff. I would also like to bring back FBO support, so we can render the map into a texture, like what SupCom does for that map preview. If we go the SDL route, then we would use a 3rd party lib for the GUI, or keep hacking the current one. Comments ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] request to remove 3rd party libs that we embed
Pabs3 mentioned that we should remove all embedded 3rd party libs, and I am OK with this. This would mean we remove glee from source, as well as miniupnp. I think the iniparser stuff is custom, though I am not 100% sure. Objections ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] codebase early spring cleaning ?
Since most everything in master is now changed so pretty much all old patches don't apply cleanly anymore anyway, I would like to take this time to fix a few remaining issues from the conversion to C++. Namely, BOOL -bool. Yes, I know there are lots of them, but the issue is bool != BOOL. In windef.h (windows header file) we got typedef int BOOL; and in C++ this is a byte, that is why we currently have tons of unsafe conversion warnings. While we could squelch it, it is also possible that this is indeed a issue someplace, and would be very difficult to track down. The other issue is, with more people submitting patches, I think we should run astyle on the codebase to save us lots of reformatting fixes. This will allow us to accept patches 'as is' and just clean it with astyle when it is committed. It will save us all lots of time. We keep putting this off, but I really think it is time we just 'do it'. Lastly, all the headers need to be updated to 2011 :) Are there any other changes that need to be done ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 3.0 Beta 3 has been released.
3.0 Beta 3 has been released. Changelog: 2010-11-14: Version 3.0 beta 3 * General: * Change: Make map preview faster (commit:5f42d0032a9c8dc0b4de60cbef7f9bba8b0b70f0) * Fix: Prevent memory corruption in the scripting code (ticket:1656, commit:1a6fb8a7547f23ce2bd7af153ac839cba999e2b0) * Fix: Fix rearming pads to actually repair units (ticket:2313, ticket:2234, commit:6421c81d7958e67334e2a3cfa190f24b40e9eb02) * Fix: Fix unit explosion color for turret (ticket:2294, commit:f4e8221ef53c4f9af6b3f5f2af3c7e5b28c89654) * Fix: Make armour work again (ticket:2273, commit:75a6c766063c6773840177d17d2ca2d5e9008100) * Fix: Don't crash in the unit design screen when using unicode strings (ticket:2209, commit:3012fde61ef92151e0ec5125551a7b3481f05fb8) * Graphics: * Fix: Rocky tileset decals (ticket:2285, commit:6f5392f14947f0c44cedd40165031f4eb4a819a7) * Campaign: * Fix: Make sure terrain textures and water height are correct when coming back from away missions (ticket:2262, commit:b859c3d6997a9860662b1be8753c643fc48f2a72) * Fix: Don't allow controlling the transport to prevent the scripts from getting confused (commit:92256b2e8906c15acd418417a6628e8c38e4a918) * Multiplayer: * Change: Make game difficulty setting not affect skirmish games (commit:4db5d00784dc59ec34830d8f4c63fd0a4808112f) * Change: Use the host's SP color as the default color when hosting games (commit:09ea0be7c30236809536db332be78b2967d3114d) * Fix: Make power generator output not depend on the game difficulty setting (commit:8707a2a84542de52155b4334cf5e637b4b43fcce) * Translations: * New: Turkish (ticket:2261, commit:255a0e2413eb5691f9398ae2ff65680e776fce04) * Updated: Spanish (ticket:2214, commit:16e015ddcff475e79066a04f9bafecbf243f2bbc) * Updated: Romanian (ticket:2246, commit:52b86d4af1aec305d96dc4c358fccd9f23a1af8b) * Updated: French (ticket:2268, commit:97a244d4a5007ee337fb3b99c7f9ee4f23f2b66b) * Updated: Polish (ticket:1347, commit:f62457fc197d70f5fb249853ee47f5f9332962bd) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Removal of 3.0 beta 1 downloads
On 11/12/10, Kreuvf wrote: Heyho, 1. Who removed the 3.0 beta 1 downloads from Sourceforge? 2. Why? All builds that are not current get killed (well, the tarball is still there), but that is it. The reason is space concerns, as I posted before. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Breaking savegames for 3.x ?
What do you all think, should we break savegames for 3.x or not ? Issue here is: http://developer.wz2100.net/ticket/2173 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] The gitorious repo sucks because it's missing history
On 11/3/10, Christian Ohm wrote: On Wednesday, 3 November 2010 at 18:22, Per Inge Mathisen wrote: How much lost history are we talking about here? Almost everything in the svn tags, i.e. the stuff we actually released, and its branch points. I only see 2.3.2, 2.3.3, 2.3.4, 2.3.5, 3.0-beta1 in git, everything else is missing (even 3.0-beta2...). The way we are doing things (at least, as I understand it), is, we make a new branch for a release, (like 3.0-beta2), then we push whatever changes for release, then we tag it, and finally delete the branch. For the lost history, I thought Cyp just used tags instead of branches, which is why you don't see them ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] pre-3.0 -3.0 and master 'testing' builds clarification
I wasn't sure the best way to handle these new builds we are about to do. Do we rename pre-3.0 to 3.0 then tag it with pre-3.0. Or do we just make a new branch from pre-3.0 and name it 3.0 ? Once that is done, we make a new branch, 3.0-beta1, and use that to build from. We still need a tag name for master though. Any ideas ? Then we can make builds from that one as well. Once that is taken care of, and the permissions on the build server are fixed, we can then release 2 builds, the 3.0-beta1 and a master 'testing' version with whatever new tag name we can think of. I don't think it should be specific version number though, that is going to confuse people. Hence, we should tag with a codename of whatever we pick. mst-testing-.01 ? *shrug* Anything else ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Final textures ready to be merged ? / New 3.0 Branch / + misc
I was thinking this weekend would be a good time to include the new textures into the repo. What new textures ? In case you haven't looked at them yet, then read http://forums.wz2100.net/viewtopic.php?f=1t=6765start=0 and download the tarball or whatever for the platform you are on. This would mean, that we would actually make a new branch from pre-3.0 and call the new branch 3.x, and put the textures in that, and also commit them to master as well. The textures weigh in at 90,323,606 bytes. Sound good ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Textures done, planning on a 'testing' build this weekend
On 10/15/10, dak180 wrote: On Oct 14, 2010, at 11:06 PM, buginator wrote: Everyone OK with a release this weekend ? Before we do any release that we want any sort of feedback on http://developer.wz2100.net/ticket/2220 needs to be taken care of. While it would be nice if we could get that done, it isn't a blocker for doing a testing build. We could just hardcode the revision # for this testing build. On 10/15/10, Guangcong Luo wrote: On Fri, Oct 15, 2010 at 3:06 AM, buginator wrote: MaNGusT has completed his work on the textures, so, it would be best to put out a 'testing' build ASAP and get feedback. Once that is done, we can commit the textures to git. Did he incorporate Jorzi's cliff textures yet? We should really get working cliff textures ASAP. Nope, and if nobody does it, then it will sit on the forums, until the time someone does it. I also think http://developer.wz2100.net/attachment/ticket/2151/pre-3.0.patch should be applied as well, we really need feedback on those changes. Is that all the patches combined? You should really be more specific with your patch descriptions. :/ It is, the way he had it, for his last patch. I just fixed the formatting mostly. For the name ... I thought it would be obvious to which one is was from. :P ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Textures done, planning on a 'testing' build this weekend
On 10/15/10, Giel van Schijndel wrote: On Fri, Oct 15, 2010 at 06:56:32PM +0200, Per Inge Mathisen wrote: I'm a bit out of the loop, I guess, on the git stuff. Are we now all using gitorious, or are some people still hanging out at sf.net? If gitorious is so horrible, perhaps we should try github? I use that for another project at work with rather large data files, and it seems snappy. I believe GitHub used to have a space limit, I don't think they've got one right now, though. In fact their website claims they don't have any hard storage limits, instead they're using soft limits. Depending on what they mean with soft limits I think using GitHub (instead of gitorious) is probably a good idea. So unless there are some other reasons to prefer GitHub above Gitorious which I'm unaware of I think moving to GitHub might be a good idea. Shortly after I was having issues (slow!) with gitorious, I asked the Guthub guys about the soft limit, and they said nothing yet. Dak then mirrored the gitorious repo on SF so I can do pulls from there. Has anyone tried the SF git repo besides Dak I ? That is much faster than gitorious for me. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] mainline - master: 1 commits.
On Wed Oct 13 17:49:59 2010 +0200, wrote: Commit: 569fb996937bcfcab5547cb44431f781bcaa3b4b Author: Cyp c...@wz2100.net Date: Sun Oct 10 17:18:13 2010 +0200 Also fix MSVC *.vcproj files that somehow ended up in lib/ instead of win32/, remove the last part that touches macosx. What do you mean by that ? The *.vcproj files are more or less like the makefile.am that we have in each lib... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] git changelog refs + pre-3.0 is alive
Any thought on how we are going to handle the changelog now that we reference commits by SHA-1 ? We can't really use only the first 8 characters or so to make links like the old r ones. Do we just drop it from the changelog ? We also need to specify the full SHA-1 in commit messages if we need to reference that in tickets or whatever. I think someone needs to make a tinySHA-1 that we can use ;) Also, pre-3.0 is alive on both gitorious + SF. It still is using the old textures from trunk, until the new ones are finished. This branch is intended to be used as a texture playground, then when we finally decide on the best textures, we can make the 3.0 branch. The models are also using TCmask, so please test / comment on how you like them. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Removing popt from pre-3.0
I am planning on removing popt from pre-3.0 and using trunk's err mainline's code instead. Objections ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] ATTENTION all warzone developers / those with commit access!
As you may have noticed, SVN access has been terminated. We have decided to start using git. Everyone who doesn't already have an account at gitorious, please do so ASAP. http://gitorious.org/ Our project is at http://gitorious.org/warzone2100 You can clone with git://gitorious.org/warzone2100/mainline.git You need SSH keys uploaded for commit access. If you have any questions on git, or anything else related to this subject matter, please tell us ASAP. Thanks. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Reordering data layout
I would like to split all the terrain (perhaps decal textures as well?) out of data/base and instead shove them in data/textures, and while I am at it, move mp back into base, and rename base back to warzone.wz. (data/warzone) It would be: data/warzone data/textures data/sequences The main reason for this, is we could offer texture packs, with a standard high version that the person can pick from the installer options. This is to prevent whining about the file size that the new textures will result in, and also help with the lower end systems that don't have a lot of VRAM. The same could be done for the standard and high poly count for the new models ? This will be for the new 3.0 branch. Objections / Comments ? Screenshots of the new branch, since I am still waiting for git -svn stuff, and how that is going to be handled. http://imagebin.us/images/r5ekut4tthzcmqlt0idb.png http://imagebin.us/images/3sydjhv7bzidbftuissn.png http://imagebin.ca/view/9qK4-L3.html ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] A quick question about the project.
On 9/28/10, Per Inge Mathisen wrote: On Tue, Sep 28, 2010 at 5:25 AM, buginator wrote: On 9/27/10, buginator wrote: It was said that it would be a good idea to get a CVE. http://cve.mitre.org/cve/obtain_id.html Anyone care to chime in on this one way or the other ? Since I was just a tad bit too terse... the reason for this is: So we can have some co-ordination with the security team of all the distros who are distributing wz. See their FAQ entry: http://cve.mitre.org/about/faqs.html#a4 I am confused. You have a security issue you are going to need to go public with? It would be for the buffer overflow issues that we fixed, though we didn't do this in the past, it is just a 'nicer'(?) way to handle these type of things. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] (Need response ASAP!) The new branch and what we all need to decide on, and some comments about git.
For the project, I have been using git to port over the terrain + TCmask support over from trunk, as to a test case for windows users. I already did a test case with hg when I did qt-trunk merge. Hg is much more polished in the GUI department, you hardly ever need to drop down to the shell to execute commands. Git's GUI is ... well, passable for simple things, but anything more complex, and you need to drop down to the shell and work there. Both are better than svn in terms of work flow, but svn is pretty much idiot proof from the GUI (tortoiseSVN). Tortoisegit was crashing way too much to be useable, and I noticed they mention that Please avoid use msysgit 1.7.2.3 with 1.5.3.0. So I have only been using msysgit which comes with gitgui gitk front ends. I did a test push to gitorious (origin/2.3-terrainTCmask) to see how that ends up on the svn side, with just a simple .gitignore change, and a few other minor changes to see what it does. NOTE:This is only a temp branch, I want to see how this will work with our svn repo before I do the other ~60 commits. Having said that, gitorious was *VERY* slow (35-40K/sec) when I did the initial clone, not sure how fast it will be when I upload the textures. I was first thinking we should create a temp branch (like I did), and use that as a playground where we can all decide on what textures (trunks or what we have sitting in trac or whatever combination of each), and what pie models (original or the TCmask originals) we should use. Then we will create the real 3.0 branch--which will be 2.3's codebase + new terrain + tcmask. But, this will inflate out repo a bit (or a lot, depending how we handle the textures), so another option is to just make a clone on gitorious (or maybe github if gitorious is too slow) on my own personal repo, and, as long as everyone has a git client, we can work on things there, then Cyp or whomever can pull that repo into the main git repo, and hopefully, it will be OK in the svn repo. (Not one huge commit like the other times). So, for feedback, please answer these questions ASAP. 1)Should we just use the temp branch I already created on gitorious, knowing what I said above about the issues involved or should I create my own repo on gitorious(or github) and we can pull from that when the time comes to make the final 3.0 branch ? 2) Which terrain textures should we use, or what combination of textures should we use ? 3) Should we use the original models or the original models with TCmask enabled ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Deciding how to handle what revision to be in Debian stable (if we want a revision to be in stable)
Since we have fairly frequent releases, the builds in Debian stable end up being quite old. This also means that Ubuntu will pull in old versions, and on down the line. Should we just not be in stable, and only be in testing, or doesn't it matter much? My opinion on this is, we should just be in testing, we don't support old builds anyway, and I see no reason for us to have a version in Debian stable. What do you all think ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11676] trunk/data/base/shaders/tcmask.vert
On 9/17/10, muggen...@users.sourceforge.net wrote: Revision: 11676 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=11676view=rev Author: muggenhor Date: 2010-09-17 09:35:29 + (Fri, 17 Sep 2010) Log Message: --- vertex shader: don't use deprecated ftransform() Replace the usage of the depecrated ftransform() function with an equivalent expression along with the invariance guarantee. Let the shader compiler deal with optimising this expression. Modified Paths: -- trunk/data/base/shaders/tcmask.vert error |10:33:24: [loadShaders] Vertex shader compilation has failed [shaders/tcmask.vert] error |10:33:24: [printShaderInfoLog] Shader info log: 0(7) : error C: syntax error, unexpected ';' at token ; 0(7) : error C0501: type name expected at token ; 0(7) : warning C7022: unrecognized profile specifier gl_Position 0(7) : warning C7022: unrecognized profile specifier invariant info|10:33:24: [screenInitialise] Can't use shaders, switching back to fixed pipeline. This is with latest Nvidia (windows) drivers. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] What other changes should happen in 2.4 ?
Since I have implemented map support for X players, (where X = 2 through 8), this will require a slight change in how maps are made. The thread for this is located here: http://forums.wz2100.net/viewtopic.php?f=5t=5309start=165#p69854 I feel it would be best to do a major version bump from the current 2.3.5 to 2.4. And, since we will have a 2.4, is there any other change that people want to be put in this? So far, I think CorvusCorax's patch http://developer.wz2100.net/ticket/2151, the map patch mentioned above, the transport patch mentioned in this thread: http://forums.wz2100.net/viewtopic.php?f=5t=6237start=30#p69718 and then some more net code changes (and GAMESTRUCT--which also means master server changes). Anyone working on anything else ? Also, to make it clear, would we make a new 2.X branch form the current 2.3, or abuse 2.3 to also be 2.4 ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.5 (final) release plan
First off, we need everyone to vote which icons to use for Cyp's changes. (no VTOL, no Cyborgs, and no tanks, and the kick icon) http://forums.wz2100.net/viewtopic.php?f=33t=6439 I also think we should include the intel vids from sequences.wz along with novideo.ogg file (which has been in all the release candidates.) The files are pretty small anyway, and they won't add that much more to the final build. For the balance changes, I assume since nobody has really said anything that I can tell in the balance feedback thread, or the 2.3.5_rc4 thread, that it is OK now ? Is there anything else before we tag ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11668] branches/2.3/lib/widget/editbox.c
On 9/15/10, Giel van Schijndel wrote: On Mon, Sep 13, 2010 at 11:53:06PM +, buginator@ wrote: Log Message: --- Fix edit boxes so they correctly calculate the string's pixel borders. Motivation of this patch was because of some whiny guy on IRC. ;) Not to be whiny but, you didn't give the motivation of that patch there, only a vague reference to the source of that motivation. So please include the motivation (which you already did: fix X so it correctly does Y) or at the very least an *exact* source reference (e.g. IRC channel + timestamp of message). Yours whiningly, ;-) Hey, don't blame me that svn logs can't show sarcasm. And thanks for whining, now I am motivated to create more commit messages that cause more whining, and perhaps transfer the whining to the changelog as well! ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] How to handle 2.3?
On 9/12/10, Christian Ohm wrote: The way I'd do 2.3 releases is: 0. Make Fastdeath's server build daily SVN snapshot builds, so hopefully the changes in current SVN get a bit more exposure before being in a RC. 1. Branch a release branch off from 2.3 (either abusing a tag, or making a separate branch and tag from that), branches/2.3.6 for example. 2. Prepare the first RC and release that. If using branches/xxx, the tag is only a copy of the current branch without further changes. 3. Commits go to 2.3, and only those fixing problems discovered in the rc are backported. 4. Goto 2. until no new problems appear and the last rc becomes the release. That allows normal commits into 2.3 as usual, without delaying them until after the release. It also means fixes need to go into two (or three, including trunk) branches, but that should serve as an incentive to keep the rc cycle short :P. As for going to 2.4, I currently don't see much reason for it. We're doing more than pure bugfix releases, but not enough new features to justify the higher number imo (or we do that for every release...), so I prefer staying with 2.3.x for now. Or does anyone have features planned that need a new version? Our repo doesn't behave like a normal repo anymore, where 'trunk' is used for testing, and then branch from that for the next release. I was going to change GAMESTRUCT to add more requested enhancements, and that will require a masterserver change... However, that doesn't really mean we need a new major version for that. It is just that I was thinking that 2.3.x will only get bug fixes only (from now on), and all new features will go into a new 'base' branch that we can use like a trunk, and then have snapshots (weekly or as needed) out for testing. I know this was tried before, and things (features) kept slipping in, but the way things are working out isn't really maintainable. I rather not have multiple fixes that fix fixes since it was a new feature, and not strictly a bug fix for a 'stable' branch. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.5_rc1 has been released.
2.3.5_rc1 has now been released. Have fun testing. :) Changelog: 2010-09-02: Version 2.3.5RC * General: * Change: Show a placeholder video of where to get the videos when they were not installed (r11566, ticket:2052) * Change: Don't allow sensor/weapon range display in MP games (r11501) * Change: Change default video display to 2x (r11576) * Fix: Disable dragging when in-game menu/popup is up (r11565, ticket:2086) * Multiplayer: * Change: Add in-game kick via the 'scoreboard' - hold LMB+RMB over the channel icon of the player you want to kick (r11490) * Change: Only clear player name when needed (r11495) * Change: Show score as '(cheated)' instead of 0 when people have cheated (r11558) * Change: Don't display scoreboard widgets when players are dead (r11504) * Change: Allow @ in chat now (r11545) * Change: Add numeric ping values in the hosting screen for the host (r11559) * Change: Show map / game name / hosted by in the tooltip for the lobby (r11546, ticket:2121) * Fix: Make sure players can't impersonate others (r11449) * Fix: Try to make the password box more idiot proof (r11492) * Fix: Host will not pass on bogus messages * Fix: Non-host players now get info about the research in progress by allied AIs (r11556, ticket:1478) * Graphics: * Update: New detailed weapons textures - new version of page-17-droid-weapons.png (r11534, ticket:2115) * Multiplayer balance (r11560, r11569): * VTOL balance has been shaken up a bit: * Removed: Cyclone turret * Added: AA Flak Cannon (and Emplacement and Hardpoint) * Flak Cannon is a medium-reload splash weapon * Prerequisites: Hyper Velocity Cannon * Added: Sunburst AA Rocket Array (and Site) * Sunburst is a slow-reload salvo weapon * Prerequisites: Lancer * Machinegun is now less overpowered in the early-game: * HMG now requires APDSB Mk2 instead of TMG * APDSB Mk1 now requires TMG instead of APDSB Mk1 * Flamer now requires Engineering instead of FIE+MG * The mini-rocket and rocket subclasses have been merged: * Mini-rockets and rockets are now affected by the same upgrades * The merged subclass has 9 damage upgrades (+25% each), 3 accuracy upgrades (+10% each), and 3 ROF upgrades (-15% reload time each) * Lancer, TK, BB, Cyborg Lancer, and Super TK Cyborg have their damage adjusted so that their fully upgraded damage remains the same * These changes should mainly help make MRA more viable * Slight buff to Heavy Laser, Avenger, and Vindicator damage * Require HQ for every weapon structure, not just MG Tower * Mods: * Fix: Nexus Total War Ai Slider Bug, and update image for name change (r11508) * Translations: * Fix: More strings (r11539, r11549) * Updated: German (r11441, r11541, r11551), Korean (r11498, r11544, r11555) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.5 RC ETA in 1-2 days?
On 9/2/10, Guangcong Luo za...@wz2100.net wrote: On Thu, Sep 2, 2010 at 12:24 AM, buginator wrote: We need to kick this release out ASAP--we are already late. This release does change lots of stuff, and 1-5 day additional testing by as many people as we can get is sorely needed. I see no valid reason waiting for mac builds at this time, so I would have to say objection(s) overruled. This is a RC release, not the full 2.3.5. Oh, sorry, didn't see the RC. That's fine with me, then, though you should check with dak180. Please test my balance changes extensively! But, for future reference, do you have standing to overrule dak180/me? o_O I think we have to at least talk it over some more and get the opinions of some other devs first. It depends. :) For the most part, yeah it is good to get input from everyone, but in this case, I think the call was correct. For future reference, I don't really see the need to hold back all releases just because we don't have a build ready for the least used platform. Sure, it is always nice to have all releases done on the same day, but it isn't always possible. You know, you could have overruled my overrule and then we could make a poll about it! ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.5 RC ETA in 1-2 days?
On 9/2/10, Guangcong Luo wrote: On Wed, Sep 1, 2010 at 11:54 PM, Daniel Kliman wrote: I object on the grounds that I will be gone until next Tues. night. Unless of course, someone else wants to make the mac builds? I won't have a Mac until Friday night, so we may have to postpone until then. And in case someone is entertaining the possibility, I object to the idea of releasing a Windows and Linux build before a Mac build. -Zarel We need to kick this release out ASAP--we are already late. This release does change lots of stuff, and 1-5 day additional testing by as many people as we can get is sorely needed. I see no valid reason waiting for mac builds at this time, so I would have to say objection(s) overruled. This is a RC release, not the full 2.3.5. Note, I am not trying to be anti-mac here, these things happened in the past, and I am sure they will happen again in the future, but we *really* need people to start testing this stuff. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11491] branches/2.3/lib/netplay
On 8/18/10, Per Inge Mathisen wrote: On Wed, Aug 18, 2010 at 1:22 AM, buginator wrote: On 8/17/10, Per Inge Mathisen wrote: On Tue, Aug 17, 2010 at 6:19 AM, wrote: Add a banned IP list to the game. All people that are kicked will be entered into the file. People using the same IP can *never* enter the game again. All attempts are logged. ... Isn't this overkill? Someone kicks someone else for fun, or by accident, and does not understand that kicks are forever, will be seriously lost. ... I would prefer that we have kick / ban buttons, but we have no room for that in the lobby screen, and for the in-game 'scoreboard' screen, Zarel mentioned that we could shrink down the other fields that we use to make some room. I still think this will make for some very unhappy players as they realize that their joke-kick turns out into a I-can-never-play-with-that-player-again action, which they may be unable to undo without pestering us for detailed instructions. Could you please explain what motivated this overzealous change? BTW, the lobby screen can be expanded. Nobody uses 640x480 anymore. This is the same behavior it always had, as in, kicks = bans, the only difference is that it is permanent, so you don't have to keep kicking the same people over over again, it is saved to a file and reloaded when they host. See r10465 'Add ability to ban IPs when the host kicks a player. ...' In -games, lots of people complained, so I made the change to a permanent list. I know this only works for static IPs, but, it is better than nothing. Believe it or not, I still use 640x480, since it helps with debugging on small windows :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11491] branches/2.3/lib/netplay
On 8/17/10, Per Inge Mathisen wrote: On Tue, Aug 17, 2010 at 6:19 AM, wrote: Add a banned IP list to the game. All people that are kicked will be entered into the file. People using the same IP can *never* enter the game again. All attempts are logged. There is currently a limit of 1000 entries. ** *All entries must be hand edited if you wish to delete them.* ** Isn't this overkill? Someone kicks someone else for fun, or by accident, and does not understand that kicks are forever, will be seriously lost. - Per All that stuff is written down in the logs, and for now, all kicks are really kick-bans. I would prefer that we have kick / ban buttons, but we have no room for that in the lobby screen, and for the in-game 'scoreboard' screen, Zarel mentioned that we could shrink down the other fields that we use to make some room. Of course, as with everything else, it will take somone to actually do this. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11489] branches/2.3/src/configuration.c
On 8/17/10, Guangcong Luo wrote: On Tue, Aug 17, 2010 wrote: Change FMVs to be 1x for default instead of full screen. At higher resolutions, the FMVs are just too blocky. 1X is native, which has the best image quality on the 320x200 source FMVs. Isn't this overkill? I mean, on a modern screen, 320x240 (which is, btw, the actual resolution of the source FMVs), 1x looks like this: http://imagebin.ca/view/Fw4AOiWu.html Even 1.00-1.10 displayed the FMVs at 2x, because they were designed to be upscaled. They also had scanlines to make the upscaling less obvious, but the videos look fine at 2x with or without scanlines. I vote for 2x as default, minimum. The reason I picked 1x instead of the other options is, that people would then actually look at the menu options, and pick the one they want. While 2x is better than FS, it still looks blocky/crappy at high resolutions I could go either way though, anything but FS. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.4
On 8/10/10, Christian Ohm wrote: I don't know who put the release date for 2.3.4 in trac to the end of this month - I intend to release it soon, since the burn damage bug is quite severe imo (possibly making the campaign unplayable or at least way more difficult). Objections to tagging later today, release tomorrow? That was me, and it is because, you need to make a new milestone so you can assign tickets to the next version. As far as the date, it more or less follows what we have been doing in the past. We don't really have strict deadlines, and it tends to float. Just guesses, nothing more. As far as doing a release, no real objections. The fix works this time right ? ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.3 has been released!
Sorry, forgot to post this to the ML: = Today, we release 2.3.3, and we strongly urge you to upgrade immediately, since it corrects a memory corruption bug that has been present throughout the 2.3 series. The two problems of 2.3.2, errors with burn damage and map loading, have also been fixed, though that means that for now, the Sk- prefixes are back. This release will not be able to load skirmish games saved in 2.3.2, but the next release will be able to. 2010-08-01: Version 2.3.3 * General: * Fix: Prevent out of bounds access of player stat arrays that would corrupt random memory (r11322, ticket:2029) * Fix: Burn damage calculations (r11303) * UI: * Revert: Don't show Sk- and -T1 in the map chooser (r2, r11202, r11206) * Translations: * New: Korean (r11349) * Updated: Polish (r11348) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Special builds are now available
Thanks to Cybersphinx and Dak180 for making available builds for the proposed new textures from ticket: http://developer.wz2100.net/ticket/2013 Please vote on how you like these new textures. http://forums.wz2100.net/viewtopic.php?f=6t=6101 We also have ticket: http://developer.wz2100.net/ticket/1757 waiting for people to vote on, but, as to not overload our community with more 'Special builds', I think we should wait until next week before doing more 'Special Builds' with the tcmask modifications. This patch adds tcmask to all the *original* models. Nothing more, nothing less. This will at least help with the backlog of patches that we have in trac. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Release 2.3.2a or 2.3.2.1 or 2.3.3?
On 7/27/10, Per Inge Mathisen wrote: Let's keep our cool for a bit and see if more bloopers surface before we rush to re-release anything. Then we can push out 2.3.3 next weekend, hopefully this time with some actual testing done. Although I cannot promise anything in that department -- Starcraft 2 just came out. Just a note, the blockers that are left are: http://developer.wz2100.net/ticket/2029 (trivial fix, didn't check for player 9 (features)) and http://developer.wz2100.net/ticket/2037 (which is a big issue, since people can't continue the SP game.) For the fix on this one, we can either revert all fixes, and the original patch, http://developer.wz2100.net/ticket/1971 or we won't be able to do a release tomorrow. Zarel is working on this though, and perhaps he can come up with a fix. Anyone else know of anything else that is still a blocker ? On another note, there is another issue, that has to do with TCP, and how it blocks. The fix for this isn't so easy, even setting all sockets to non-blocking, and use polling to determine if done won't solve all the blocking issues that can happen. I don't think newnet does anything different in this area either. We could spawn a thread for each player and have a main network handler event loop that queues everything up to prevent blocks, but this isn't easy to code, and would pretty much force us to enter beta mode again (2.4 beta 1 or ??). Other ideas is, use raknet, or switch to UDP, but those also force us to enter beta mode as well. Other options ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.2a (or whatever) timeout period for sockets
On 7/27/10, buginator wrote: Currently, we wait 2500ms for some sockets, and wait forever for other sockets (which you may have noticed when the game froze on you), so the question is, for reading the sockets, do we wait 2500ms as well, or make it more or less ? Remember, the higher the value, the longer the game waits for a response. The lower the value, then the higher chance of people getting kicked / dropped because of a lack of a response. Scratch this, I misread the function, a NULL structure would cause us to wait forever, a 0 value means don't wait. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.2a (or whatever) timeout period for sockets
On 7/27/10, Guangcong Luo wrote: On Tue, Jul 27, 2010 at 10:41 PM, buginator wrote: Currently, we wait 2500ms for some sockets, and wait forever for other sockets (which you may have noticed when the game froze on you), so the question is, for reading the sockets, do we wait 2500ms as well, or make it more or less ? Remember, the higher the value, the longer the game waits for a response. The lower the value, then the higher chance of people getting kicked / dropped because of a lack of a response. Can't we just thread them, so we can wait as long as we want without freezing? Not for 2.3.x That would require tons more work / testing. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Renaming sequences.wz
On 7/24/10, Kreuvf kre...@warzone2100.de wrote: Guangcong Luo wrote: On Sat, Jul 24, 2010 at 1:32 PM, Stephen Swaney sswa...@centurytel.net wrote: On Sat, Jul 24, 2010 at 01:05:28PM -0500, Guangcong Luo wrote: It's just that videos-standard.wz and videos-lowquality.wz seemed a bit long as filenames go. Are you repeatedly typing them in by hand? Readability and meaning seem more important than brevity here. Good point. Sure, let's go with that. I'd vote for videos-standardquality.wz and videos-lowquality.wz for a more uniform naming scheme. No way, think of all the DOS people, and the 8.3 limitation! ;) NOTE, if we do a simple rename, then don't forget the NSIS changes. p.s, I could also go with videos-stdquality.wz. Then you can have a built in joke! ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.2 release this weekend ?
On 7/22/10, Christian Ohm wrote: On Thursday, 22 July 2010 at 15:23, buginator wrote: Using SF trac, I have come up with these changes so far, I think we should try for a 2.3.2 release this weekend. Fine by me, probably. As you might have noticed, I've updated the Debian packaging so we can offer .debs, let's see how much feedback that gets. We would then make both tarballs and .debs ? Isn't that what Pabs3 does ? Proposed Changelog (so far, I know I have missed some stuff): If you just list the svn messages, let me do it. It's easier to add lines than to look if a change is already mentioned. Yeah, that is basically what I was doing, so be my guest. :) On another note, still no net access, and thanks to the storms that passed last night, no power either. :S I am not sure when I can get 'normal' access again, but, not much I can do besides wait for the repair crews to fix things. I still rather see a 2.3.2 this weekend, instead of next, but, I can understand if this happens. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.2 release this weekend ?
On 7/22/10, dak180 wrote: On Jul 22, 2010, at 9:19 PM, Guangcong Luo wrote: At the same time, I'd like to consolidate the video location to one place. To do that, however, we'd need to get PhysFS to search /Library/Application Support/Warzone 2100/sequences.wz, which I can't seem to be able to do. Can you help me with that? Yeah--if I can get net access again to make a correct patch. In init.c, 329 374, just change tmpstr to point to that full path, then do PHYSFS_addToSearchPath( tmpstr, PHYSFS_APPEND ), flanked by OS_X guards. Don't forget to remove those as well, in the correct area. You can also stick it in the config dir area, and that should work as well. For my solution to work properly it would need to have different names for the lo and hi qual sequences. I still don't see the reason for this. If it is a script, then it can rename whatever version the person wants just like we do for windows installer. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11231] branches/2.3
On 7/18/10, zare...@users.sourceforge.net wrote: Revision: 11231 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=11231view=rev Author: zarelsl Date: 2010-07-18 23:38:56 + (Sun, 18 Jul 2010) Log Message: --- Fix bug #1994 - hack some `#ifdef`s to fix text alignment issues relating to using different fonts in OSX and Windows. Bug is fixed less hackily in trunk, but it's not the kind of change I want to introduce to a stable branch. Modified Paths: -- branches/2.3/lib/widget/editbox.c branches/2.3/src/console.c branches/2.3/src/intdisplay.c The way you did it here is with magic numbers, that can't possibly work with whatever font the user picks... I also don't recall any tickets about this issue before, so what changed ? What exactly is the hack part of it in trunk ? It just looks like you are using the same font as the rest of us have been using for a very long time. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.2 release this weekend ?
Using SF trac, I have come up with these changes so far, I think we should try for a 2.3.2 release this weekend. Objections ? Proposed Changelog (so far, I know I have missed some stuff): 2010-07-24: Version 2.3.2 * General: * Change: Save settings when receiving an SDL_QUIT event. (r11128, ticket:1964) * Change: Save screenshots as JPG and PNG. (r11131, ticket:23) * Fix: Prevent overlapping sounds when looking at intel information. (r11147, ticket:60) * Fix: Prevent division by 0 when a object has 0 original hit points. (r11186, ticket:1711) * UI: * Change: Make the fixed radar unblurred at full zoom steps, also increase radar zoom range to 0.5-4x. (r11130, ticket:1923) * Change: Add challenge descriptions. (r11181, ticket:1986) * Add: Add option for rotating with middle mouse button (LMB+RMB also works). (r11224, ticket:2003) * Map: * Fix: Fix a missing cliff tile on 8c-Wheel (r11145, ticket:1935) * Change: 2c-Startup rebalanced, files replaced with the files from 2c-startup2 (r11145) * Add: Pyramidal map (r11190) * Multiplayer: * Change: Sync timings made more aggressive (r11016) * Fix: Network logging having incorrect byte count (r11065) * Fix: When a player drops, everyone should be correctly notified of the event. (r1, ticket:1020) * Change: Remove Sk- and -T1 from map names in map chooser (r2, ticket:1971) * Translations: ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Merging newnet to trunk
On 7/14/10, Cyp wrote: Hi, I'm planning on merging the newnet branch to trunk in a day or two, unless there are objections. This should fix all synch issues (such as units mysteriously exploding, and units moving in different directions on different clients, or players disagreeing on who won the game, or destroyed buildings reappearing, and artillery fire not being visible for all players, or the game pausing for some players but not others, and insert very long list of stuff here). The current diff is at: http://pastebin.ca/1900573 With local testing via LAN, with custom maps (since normal maps didn't work), I still had sync issues with the game after a few mins. Correct me if I am wrong, but once a desync happens, then there is no way to fix this, and the game is over correct? The other issue was, when moving units, the motion wasn't smooth, it was stuttering. Unsure what causes that. Because of the lack of time for more testing, I request you put this on hold until the weekend, if at all possible, so we can get more testing done. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] svn/2.3 feature locked status, and what should happen with it
On 6/24/10, Per Inge Mathisen wrote: On Thu, Jun 24, 2010 at 5:40 AM, buginator wrote: If we start to add features that do require beta testing, what are we going to do ? We could do beta testing... I was hoping for less work, not more, with the upcoming release of the 3.0 beta, doing more betas for 2.3.x doesn't seem like a wise move. If we backport some major features, it would also require us to bump it to 2.4 (or whatever). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] svn/2.3 feature locked status, and what should happen with it
On 6/23/10, Per Inge Mathisen wrote: One thing we should consider backporting to 2.3 is the wavecast code, which makes visibility a ton faster in trunk than in 2.3. Though, that doesn't answer the question on what we should do with the 2.3 branch. If we start to add features that do require beta testing, what are we going to do ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] svn/2.3 feature locked status, and what should happen with it
Currently, I was assuming that 2.3 was feature locked, and we would only be doing bug fixes. However, it has been expressed that the branch shouldn't be feature locked. Do we make a new branch, which would be the current 2.3 base (and name it something like branch/2.x, delete the current branch/2.3) and continue to work that way (with 2.4, 2.5 and so on), or do we just forget about it being feature locked, and start up with the beta cycles again (with 2.3.2 beta 1?) ? Do we take codename (which was trunk, and pretty stable the last time I tried it) and use that as a new base for the next release (3.0 ?) ? Anyone see another way around having all these branches floating around ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.1a release and some other comments about the other branches.
Greetings all, it looks like the 2.3.1 windows build wasn't built that way we expected it should have been built, since we have the mouse cursor issue again. More details are here: http://forums.wz2100.net/viewtopic.php?f=4t=5627start=0 Do we make a 2.3.1a release, (only for windows?) or just do a hotfix ? For the Qt branch, the only (known) blockers are: 1) No CC builds so we can't test anything our usual way. 2) The lack of full screen resolution switching. 3) Not really a blocker per se, but quesoGLC is back, in case you haven't noticed, and well, it makes it so we can't make MSVC static builds. For the lua branch, we have had quite a few complaints about the way we are handling this branch. For the most part, the details are here: http://forums.wz2100.net/viewtopic.php?f=35t=4733 Basically, I have to agree with what has been said. We should commit the generated scripts now, and have people submit patches for those, and whoever wants to fix the generator itself, can do that. It isn't perfect, but better than no work being done. For newnet, we really need to get rid of all the floating point requirements compiler switches, it just isn't working on all platforms. For the codename branch (which is trunk - most recent additions), I think we should make some test builds of that, and throw it out for testing ASAP. We need testing done on trunk, or we will fall into the 2.3 trap once again. Note, we must make builds from a 32bit machine, or we will hit this: http://developer.wz2100.net/ticket/1786 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
On 5/18/10, Christian Ohm wrote: On Tuesday, 18 May 2010 at 21:48, Per Inge Mathisen wrote: On Tue, May 18, 2010 at 9:07 PM, Christian Ohm wrote: How about releasing 2.3.1 soon? There have been quite a few commits since 2.3.0, arguably the most important being Dydo-AI's license. If that is the most important thing that has been done, then surely there is no hurry? Well, Pabs said he's waiting for 2.3.1 to upload to Debian, so if you're ok with 2.2.4 for their next release... Anyway, there was other stuff, like making the movie subtitles translatable and translation updates. And it also doesn't seem like there is much else planned for 2.3.1, so what would we be waiting for? I don't really have objections, since I do want to see 2.2.4 die (in all distros)... so, does this mean you want to be the release manager for 2.3.1? :) You got a specific date in mind ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt merge results + what to do on the mac
On 5/18/10, dak180 wrote: On the font corruption issue, as the Qt example programs seem to have on issues on the mac and that it only effects the menu title text and not any of the others I doubt that it is a driver issue. Actually, looking at the examples, none of those do what we do, so that isn't really a valid comparison. Possible Qt bug, or driver, or it is just a quirk that it works on windows linux. On the mater of input issues my take is that the way Qt does things is the right way to go. Where one would use the ctrl key on other operating systems one uses the cmd key on the mac; for example to paste on the mac one uses cmd+v, not ctrl+v. Since this is working right now and making it work otherwise would involve ugly hacks I do not think this should be changed. The only thing to keep in mind is that there are three reserved shortcuts: cmd+q (quits the program), cmd+h (hides the program) opt+cmd+h (hides all other programs). The mac option (⌥) key is traditionally a tricky beast as it preforms the functions of both the alt key and the altgr key, as such the option key is never used by its self in a shortcut but rather in combination with the cmd (⌘). Either way, we will have to have mac specific hacks, and if we go the non SDL way, then we need to update the docs for mac users. The reserved key issues is also troublesome, and we are getting into more mac specific hacks to avoid those (if that is possible). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt merge results + what to do on the mac
On 5/18/10, buginator wrote: Actually, looking at the examples, none of those do what we do, so that isn't really a valid comparison. Possible Qt bug, or driver, or it is just a quirk that it works on windows linux. Possibly related? http://bugreports.qt.nokia.com/browse/QTBUG-9706 https://bugs.launchpad.net/stellarium/+bug/521134 So far, it seems that in wzapp.cpp, line 206 bold.setFamily(DejaVu Sans); bold.setPixelSize(21); bold.setBold(true); if you do bold.setFamily(DejaVu Sans); bold.setPixelSize(21); // bold.setBold(true); It is a bit better, but it is looking more more like a mac Qt bug. I also am curious if Dak and or Zarel could try: bold.setFamily(DejaVuSans); bold.setPixelSize(21); // bold.setBold(true); and see if the issue is still there or not, if not, re-enable the setBold line, and see if that works. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Qt merge results + what to do on the mac
For those that haven't been looking at the commit logs, we have two new branches. qt-trunk = svn/trunk + svn/qt (imagine that!) codename = svn/trunk @ r10808 Both need to be kept in sync with svn/trunk, until we can kill off qt-trunk when the mac issues are fixed. The main reason for the codename is, we do not know if we will use SDL or if we will just use Qt, then once we decide, we can branch into 3.0 or whatever. Now, for the mac, the main issues left are, the font textures get corrupted as can be seen in this ticket: http://developer.wz2100.net/ticket/1549 Dak's screen shot with the corruption is here: http://developer.wz2100.net/attachment/ticket/1549/2010-05-15at3.44.04PM.png Speaking of corruption, Segg2 also posted a corrupted image here: http://developer.wz2100.net/attachment/ticket/1549/qt-ss02.png I *think* the issue in both of those might be driver related, it doesn't happen on linux or windows. Well, Segg2 is also on linux, but I still think that is driver related. The input issues for the mac are a bit more confusing. The issue is, on macs (using Qt), ctrl key = cmd key, and cmd key = ctrl key, and alt key = option key. This is NOT the way SDL had it, SDL had it ctrl=ctrl and alt=alt on the macs. If we stick with the SDL way, then we must remap the input key so ctrl = ctrl. If not, then we remap cmd=ctrl and ctrl = cmd. I prefer we keep the SDL way, since that requires less code changes, but I am not a mac user. Mac users, speak up on what you want, or the default will be the SDL way. Lastly, the final (and most important) issue for the mac is, it don't seem to handle ALT+h (for example), it shows the alt key was down, but the h key gets lost...ctrl +1 works (cmd+1) ... and it works OK on windows linux so ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] team colors for old models
Anyone have any objections to this patch: http://developer.wz2100.net/ticket/1757 ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Release plans
On 5/12/10, Per Inge Mathisen wrote: 2.3.0 has so far seemed like a pretty solid release, and there is no desperate need for a 2.3.1 yet. Discussions of new features seem to have moved to trunk. How about we try to schedule a 2.3.1 bug-fix-only release for mid-June? We are a bit passed the 'bug-fix only' mantra, since some of the stuff that is currently in svn/2.3 are not really bug fixes per se, but that release schedule sounds OK. Trunk seems rather stable at the moment, and branching it as a possible release point before merging any of the big 3 feature branches may be a good idea. One idea is to branch is to a codename branch, start merging the feature branches, and depending on how stable or unstable trunk becomes after that, either proceed to release from the codename branch, or from trunk after the merges (nuking the codename branch). While I haven't personally tested trunk in a long time, Zarel mentioned that the pathwalking is broken. Yeah, I know there is a ticket (http://developer.wz2100.net/ticket/1649) but I haven't really had the time to look into this more. The trunk test builds that we threw up haven't really gotten any feedback at all, and with the new web site style, it isn't exactly easy to change things, since we rely on one person, and the information on how to fix/change it, hasn't exactly been forthcoming. We have 3 big feature branches that we need to merge before accelerating bitrot makes merging even more difficult. The merge priority that we have discussed earlier for the big 3 feature branches is 1) Qt branch, 2) newnet, and 3) lua. Last comes last because it seems most unfinished yet, and Qt branch first because it has seemed closest to completion and has the most developers familiar with the new code. However, we can easily change the merge order - there are no interdependencies between them. I think we need to clear up some things about these branches. 1) Qt. - we don't really have anyone that is well versed in Qt for the current issues. Those are, on the mac, the input state is swapped from our normal routines. Currently, we can hack around that, however, we still have text issues, and the fact that we can't get key map screen to show Ctrl or Alt like it does on windows / linux for whatever reason. AFAIK, Alt should work like it does on windows / linux, but it doesn't show Alt + letter like it should. The Main menu / in game menus suffer from a state conflict. That is, when we set modes, (pie_SetRendMode() pie_SetTranslucencyMode()), it looks like we are conflicting with the way Qt is handling the window/widget. Qt suggest to use beginNativePainting()/endNativePainting(), but that causes a big performance hit, and didn't really fix anything when I tried some tests with that. While experimenting with Qt Designer for a new lobby screen, I don't see a easy way to match the current color scheme / style of warzone, and if we go this route, the issue then becomes how easy is it to maintain? I have not done any svg tests, so unsure how smooth this will go. As of right now, I can only think of one advantage to Qt, and that is for the hardware colored cursor support. The lack of a dedicated mac Qt expert person to help us trying to fix this doesn't make things easy, and it gets annoying, since we must waste more time digging into tons of docs hoping to find out the cause, then waiting for feedback. With SDL, we are pretty much at, it just works for all the platforms, so people can concentrate on other issues at hand. 2) newnet. Besides the problems listed in http://developer.wz2100.net/ticket/1786, I don't really understand the main reason for having such a high requirement for precision. (I haven't really looked at the code either) Compiler issues are the main problem here, though, I haven't really played with it enough to see if it has other problems. We can't release test builds of this until that is fixed, and we won't merge to trunk, until we know it works as it should. 3) Lua. The last I recall, the state of lua was about 50-55% done, and the forum thread : http://forums.wz2100.net/viewtopic.php?f=35t=4733 shows that the conversion script is buggy / broken for some things. We don't really have anyone who is a lua expert either (since Gerard was about the closest thing we had, and he isn't around much), so that is slowing things down drastically as well. 4)Beta widget Yeah, I know this wasn't mentioned, but, it appears there is lots of confusion of the shape this is in. It uses deprecated lib(s), and would add lots more dependencies, and trying to compile those deprecated lib(s) on anything but unix is a huge PITA. It never really got past the (pre) alpha stage, before it fell by the wayside. The thinking to revive this was to use Qt for the SVG routines, but, there have been no tests at all, so we are not even sure if this would be a good move or not. Everything is in theory, it should work. If we proceed to
Re: [warzone2100-dev] Warzone-dev Digest, Vol 54, Issue 11
On 5/12/10, manofli...@gmail.com manofli...@gmail.com wrote: 2.3 is a solid release except for the bug that causes it to pause for long periods of time thus making the game unplayable. other than that. its great. Have you made a ticket about this ? I have never seen this happen. We need tons more info about this, like system specs, how many players, what map, any error/warning messages, how to replicate, and all that good stuff. http://developer.wz2100.net/newticket in case you don't know. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1847: Preliminary qt-trunk merge patch
On 5/10/10, Warzone 2100 Trac wrote: #1847: Preliminary qt-trunk merge patch ---+ The ETA on the merge should be this weekend or maybe next weekend, or whenever Cyp has time to do this on gitorious and then push to svn. I don't see a way to get added to gitorious, so I can push things to svn, once the merge is made. This has been postponing indefinitely, until we get a working CC version (I forgot all about this), and we can get a mac developer who has time to find out what the problem is with Qt on the mac. Also, for the main menu, somehow our openGL states are being reset / ignored with Qt's upkeep of the screen, and I don't know enough about Qt internals to know why. We still can do a merge from trunk into Qt though, to keep it up to date. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] hg (mercurial) test repo is up and running @ SourceForge, bzr is up and running @ LaunchPad
We have a hg test repo of the Qt branch up and running here: ssh://usern...@warzone2100.hg.sourceforge.net/hgroot/warzone2100/qt_test Have at it. :) If you never used if before, then this is a good tutorial: http://hginit.com/ (everyone says this is the best one) If you rather watch a video from the guy that made it, then: http://video.google.com/videoplay?docid=-7724296011317502612 and the final test candidate: bzr is already available at launchpad. bzr branch lp:warzone2100 That is all you need to clone the repo, lp:warzone2100 Some tutorials for bzr: http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ http://wiki.bazaar.canonical.com/Tutorials Note, you start the gui client by doing 'bzr explorer' from the command line, or select the menu option in the start menu, or icon on the desktop. We *really* want feedback on what is working the best for you! ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1270: Random freezes happens in some games.
On 5/7/10, Kronos wrote: while i didn't wanted to extend this discussion here, the same problem happens here, and worse, it was happening at multi-play. Last time it happened, the game completely froze off, and the only way to exit the game was rebooting my machine. Seriously, I don't believe that this could be a heat issue, as the max temperature in WZ I've got was 69º for the GPU and 50-54º in the CPU. Still, the game is getting pretty neat, and i'll try it again as soon as the QT or Newnet branch merges in. Good luck out there. The game itself can't cause a system freeze, we don't do any direct kernel hacking. All system freezes are the result of either heat or drivers (sound / video) or hardware issue (CPU / RAM). I don't think Qt will fix the issue you are having. As for not extending the discussion here... meh I don't mind, not much traffic going on the list, since trac is broken. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1270: Random freezes happens in some games.
On 5/5/10, james wrote: It happening with me in a single player skirmish mode with sk-cocktate. and they are getting longer the longer the game goes on. its at 6:20 hours but I have saved and rebooted several times and it just keeps getting worse. the mouse still moves around the screen but doesnt move you around the map. It happens no matter what I am doing. even if I am just sitting there waiting for something to build it just locks for ahile. I am running on a dell 5100 laptop with a 32 meg radeon video card. its a 2.4 ghz desktop processor. I am running it under micro xp. so it doesnt seem to be limited to an os. I started with 7 AIs and now its down to 3 (2 tiny and 1 huge.) also two other things when I go to the edge of the map I see these shadow replections of buildings that arent on the map. at least not near by. I am running the official 2.3 , btw I love the dragons. Any reason why you didn't post this in the ticket? Anyway, for laptops, it can be a heat issue that makes it freeze. For reference, there are many people who have played the game for hours on end, so, if it doesn't crash, then it looks to be a issue on your end, could be video or sound drivers, or heat, or ... or... The shadows at end of map are a known issue. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] git test repo active (also for hg/bzr users)
On 5/3/10, Gilles J. Seguin se...@videotron.ca wrote: what is missing from git://gitorious.org/warzone2100/mainline.git ? what is problematic ? who is lost ? the administrators or the users Are you asking if we are using that? Officially, not really. We are still using SVN. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] git test repo active (also for hg/bzr users)
On 5/3/10, Christian Ohm wrote: Since there seems to be no winner in the RCS discussion, we have basically two choices: 1. stay with SVN, 2. Decide on one of them (as backend at least). From what I've read, it seems it is easily possible to access a git repository with both hg and bzr. So I've set up a git repo for testing. Not sure if other windows people have been trying tests or not, but it looks like, the main problem with using HG+git or BZR+git is that it isn't working, besides the initial clone. Could be errors in dulwich, or perhaps hggit itself. Using msysgit and or TortoiseGit (which needs msysgit installed), the results are somewhat better, you can push, but, I ran into a fatal issue, that I couldn't resolve. It still is unstable, unless all you do is basic commands, like pull, commit, and push. Once you start doing branches, tags, merges, then all bets are off. SVN does have its own set of problems, but it is far more stable than using git. The other options are, either use hg, or bzr, or we just keep hammering away with SVN with a possible move to the beta SVN server (with the limitations previously mentioned), or hope they can fix the issues with HG+git. Anyone else care to pipe in? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] More on fixing the Qt branch
On 4/30/10, Christian Ohm wrote: On Thursday, 29 April 2010 at 22:45, buginator wrote: After some more tinkering with the code, I finally found the issue that MSVC was having. In short, a bool in c is a int, and in c++ a bool !=int. It was always returning 256 on false, and -858993663 on true. For those that don't see what that is, here: false = 0x0100, true = 0xcc01 make sense ? No. Is this another Microsoft stupidity? Evalutating true to 1 and false to 0 seems to be required by the C++ standard We are not using C++, we are using mixed C C++, and in the pre C-99 standard there is no bool type. It is a typedef to a int for MSVC. In C++, the bool type is 1 byte, not a int, in MSVC. In order to use cross-platform friendly types, then we must not use the C++ bool type, and instead use a typedef that will work fine in pre C-99 code, hence it should be a int, which is why my patch uses BOOL, since we already use that in the codebase, and that is a int on all platforms. 'bool' (in the C code) is typedef to a int as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Let's git going
On 4/29/10, Christian Ohm wrote: On Wednesday, 28 April 2010 at 18:34, NoName wrote: I do still vote for Mercurial. How about accessing a git repo with hg? http://candidcode.com/2010/01/12/a-guide-to-converting-from-mercurial-hg-to-git-on-a-windows-client/ I belive you can do that with bzr as well using bzr-git. The only thing that won't work is svn. How about we set up both a git and a hg repo on SF, for testing, and see how the speed everything else goes with those ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] More on fixing the Qt branch
After some more tinkering with the code, I finally found the issue that MSVC was having. In short, a bool in c is a int, and in c++ a bool !=int. It was always returning 256 on false, and -858993663 on true. For those that don't see what that is, here: false = 0x0100, true = 0xcc01 make sense ? Good. The plan fix is to change the .cpp bool to BOOL, which will work on all platforms. With that out of the way, and a actual running Qt codebase, the next issue is with the keymaps. I don't really understand why we are *not* using Qt:Key_XYZ and using values that only sometimes match the Qt::Key assignments. The ASCII codes mostly all match, the rest are not even close. KEY_LALT = 308 for us, and Key_Alt = 0x0123 for Qt::Key. Got around this by doing a lookup function, so now, the keymap display is more or less working as it should, but it has issues on linux still. It is showing ALT+meta+- for example, and on windows it shows ALT+-. The bigger problem is, the branch is pretty much fubared. When trying to do a reintegrate back to trunk, it spits out: Reintegrate can only be used if revisions 8502 through 10747 were previously merged from https://warzone2100.svn.sourceforge.net/svnroot/warzone2100/trunk to the reintegrate source, but this is not the case: branches/qt Missing ranges: /trunk:8502-9707,9709-9867,9870-9897,9899-9918,9920-9947,9949-9974 branches/qt/win32/libs/iconv Missing ranges: /trunk/win32/libs/iconv:8823-9707,9709-9867,9870-9897,9899-9918,9920-9947,9949-9974 We also don't have the original history when the first mass merge was done on svn, and all subsequent mass merges as well. Bottom line is, we need to either do: A) restart from square 1, go back to the original git repo, and start applying those patches one by one (to get the history back), and then switch over to the svn commits, and apply those one by one to retain the history of those onto a new trunk branch. b) try to fix the above missing merges, but that still leaves us with no history from the git repo. c) something else. Any opinion on what would be the best course of action for us ? P.S, yes, the MSVC builds are now 100% static, so no real rush for fixing the CC builds, but that still needs to be done. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Let's git going
On 4/28/10, dak180 wrote: On Apr 28, 2010, at 2:58 AM, Per Inge Mathisen wrote: That leaves only the question of whether git is good/user-friendly enough on Windows/Mac. For a number of reasons I would prefer mercurial, of which I think the most important is that the mac gui for git has not been worked on since last oct. where as the one for mercurial had a new release within the last two weeks. My personal experience shows me that git is too unstable on windows. The other issue with git is that it requires cygwin or MSYS, which are both pretty crappy. Sure, you can hide the shell with tortoisegit, but it still is too unstable. Hg is much better supported, since it isn't as hacky as git is on windows. Bzr is also not bad, and is a bit more polished that Hg on windows. While svn is showing its age, the main issue is with the server is it not ? We could switch to the beta SVN server, (then locally, you can use git-svn or hgsvn or bzr-svn for commits) but I just don't have the bandwidth to upload a 1.4GB+ repo without it being down for quite a few days. Yes, SF allows us to use git or hg as well, but I am unsure if this will fix the main issue or not. If the problem is that the (old) SVN server is overloaded, or if it is a connection issue of some kind. Which could mean, switching to another host again. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Qt branch issues
Because of the way some of the merges were done in this branch, it is very difficult to find out what the exact change was that broke some stuff in qt. I think it would be much easier for us to rebase qt from trunk, and apply the qt specific patches to a new branch. I count around 74 patches, with some of those being the huge merges to sync it up. Can anyone think of a better way to 'fix' the qt branch? There is still a lot of work committing all the patches, but I don't see a better solution. Status so far, no CC support (it doesn't want to acknowledge that it is a cross-compiler, and not unix, even after telling it via the switches that it is a windows build) , and MSVC builds on VS2k5 VS2k8 are not working correctly so far. I would also suggest we stop doing mass syncs to the other branches as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.0 has been released
On 4/27/10, Dylan Dog dyd...@googlemail.com wrote: Hello Sorry for the late response to you PM on the forum. Yes, please help me to close the current DyDo thread, I`ll then open a new one. I do not know how to close the actual thread but it seems I do not have the rights... Done. Which folder on svn I have to update (for DyDo AI) now that we have relased the WZ 2.3? Ah...I missed to update the DyDo on the 2.3, next time we are near to release a new version of WZ I`ll ask you what I have to do. I kept updating the branch but maybe I had to update a TAG? thanks! No, don't worry about the tags, those should only be touched for build system changes, nothing else. Stick with updating trunk 2.3 and whatever else is active. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Rename .img files to .csv?
On 4/26/10, Zarel wrote: On Mon, Apr 26, 2010 at 4:19 PM, Per Inge Mathisen wrote: It will break mods... - Per And if one does, well, my recent cursor additions (not to mention your new icons for ECM stuff - at least, I think they're yours) will break it anyway. :P It's somewhat of a problem, yes. The bigger problem is that there's no need to falsely pretend the files are disk image files whey they clearly aren't. For a temp solution why not do ln -s source_file target_file, as in ln -s intfac.img infac.csv (or whatever) ? I don't really have a issue with the rename, except for what Per mentioned. If we are going to break mods, then I would like to rename all intfac* to interface* ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.0 has been released
2.3.0 has been released, windows source tarball have been completed, and the mac builds are pending. Thanks for all the hard work you all have done in getting 2.3.0 out the door. We now move on to better things. :) Here is a full changelog for 2.3.0 (you can thank me later!) 2010-04-24: Version 2.3.0 * General: * Fix: Make sure the config directory is populated before any write calls are made.(r10624) * Translations: * Updated: Brazilian Portuguese (r10645), Italian (r10649), Ukrainian (r10695) 2010-04-17: Version 2.3 RC 1a * General: * Change: Supress system dialogs when in full screen mode (r10605, ticket:1776) * Fix: Actually use saved experience for new droids (r10604, ticket:251) * Fix: Various build fixes (r10558, r10561, r10563, r10586, r10595, r10606) * Multiplayer: * Fix: When using a passworded game, prevent connection to anyone but the host, until verified. (r10572, ticket:1611 * Mods: * Change: DyDo AI updated to version 2.1.1 * Translations: * Updated: Spanish (r10598), German (r10599), Croatian (r10588), Polish (r10577) 2010-04-10: Version 2.3 beta 13 * General: * Change: Crash report and log files now will reside in a UAC friendly directory for windows (r10532, ticket:1759) * Change: All platforms will have stderr routed to configdir/logs/WZlog*.txt (r10532, ticket:1759) * Change: Use system dialogs for reporting errors on Mac (r10474) * Change: Change most references to plural mods to singular mod, to discourage using multiple mods (r10498) * Fix: Oil features were not being added back to the game when oil derricks were destroyed (r10489, ticket:1726) * Multiplayer: * Change: Ban IP addresses when kicking people from games (r10465) * Fix: Crash during game hosting (ticket:1745, r10480) * Fix: Missing cyborg legs in games with 8 human players (r10527, ticket:1740) * Campaign: * Fix: Crash when cleaning up memory usage between missions (r10476) * Mods: * Change: DyDo AI updated to version 2.1, and includes its own challenges * Balance: (r10537) * Remove Cobra prereq from Inferno * Increase Plasma Cannon range to 10 and damage to 500 * Plasma Cannon and Archie can no longer fire while moving * Increase HPV weight * Decrease Assault Cannon/Twin Assault Cannon weight * Increase Lancer/TK damage by 10 * Increase Bombard damage by 10 * Heavy Laser damage and reload time increased (overall slight buff) * Heavy Cannon and Medium Cannon range increased 0.5 * Cyborgs sped up a bit 2010-03-29: Version 2.3 beta 12 * General: * Change: Double-clicking trucks will now select them for consistency (r10391, ticket:1472) * Change: let users toggle level name via 'showlevelname' console command (r10366) * Change: Template loading code changes for backward compatibility with older mods (r10418, ticket:1686, r10425) * Fix: Multiple zooming of radar fixes / changes (r10346) * Fix: Stop landing VTOLs even if they are below the map height (r10051) * Fix: Fix adding more body points than possible when repairing (r10040) * Fix: Memory leaks and crash fixes (r10246, r10247, r10248, r10249, r10251) * Fix: When failing to load a message, remove it from the message queue to avoid a crash later (r10392, ticket:1660) * UI: * Change: Improved loading bars (r10102) * Campaign: * Fix: Fix Tank Killer angle bug in campaign (r10212) * Fix: Make sure that for campaign, we always set the is human flag correctly on savegame load (r10081, ticket:1628) * Multiplayer: * Change: AI script fixes for trucks grabbed on duty, distance limits, power limit for factories, placement checks (r10293, r10323, ticket:1626) * Fix: Make sure all templates get all weapons. This hopefully fixes the cyborg leg issue (r10352, ticket:1687) * Fix: On new player joining, init the struct before setting flags (r10331, ticket:1688) * Fix: Make use of new AI script function pickDroidStructLocation (see below) to fix AI not building a power generator (r10323, ticket:1626) * Fix: When droids are taken over, don't send droid count, since droid count isn't read, making the message unparsable (r10038, ticket:894) * Fix: Use isFlying instead of isVtolDroid for checking AA targets, AA can now also shoot down transports (r10319) * Fix: Only let host set player position/colour, send new players info about unallocated slots too. (r10218) * Fix: Fix droid frustration so that droids do not start the game frustrated, make sure that scavs never fire at features (r10085) * Fix: Fix the game getting completely messed up if anyone changes position or colour, and then someone leaves (r10069) * Fix: Update Dydo-ai to 2.0.8 (r10214) * Fix: Update NTW (r10354, r10356, r10357, r10359) * Scripts: * Added: Add new AI script function that gives position to build a structure while checking that a given droid can build it (r10323) * Translations: * Fix: Translations now work on the mac (r10316,
[warzone2100-dev] Pruning a unnecessary directory
If no objections, since we don't use it, we should kill \pkg\dpkg. Any objections? Looks like it was used when we made debian builds, but all the files in that directory are pretty much old / unnecessary. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] lack of syncs for newnet / lua / Qt
Since the sync bot is MIA again, (and it looks like it was skipping patches as well) would it be ok to start doing mass syncs to those branches, or will that hose up the history when we merge things back to trunk ? Is there a better way to handle syncs ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10689] trunk/macosx/Resources
On 4/23/10, dak...@users.sourceforge.net wrote: Revision: 10689 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=10689view=rev Author: dak180 Date: 2010-04-23 04:12:19 + (Fri, 23 Apr 2010) Log Message: --- Distinguish between different types of .wz files Um, when did we decide on this ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Disable mutli-turrets (again) for 2.3.0 ?
Since we still have issues with multi-turrets, that have never been fixed, I think we should disable them once again for 2.3.0. Main issues, it still can look like crap, and the range issue for the turrets, and I am sure there are some other issues hiding. Objections ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Disable mutli-turrets (again) for 2.3.0 ?
On 4/23/10, Guangcong Luo wrote: On Fri, Apr 23, 2010 at 7:21 PM, buginator wrote: Since we still have issues with multi-turrets, that have never been fixed, I think we should disable them once again for 2.3.0. Main issues, it still can look like crap, and the range issue for the turrets, and I am sure there are some other issues hiding. ...aren't we in freeze? Let's not do anything that major now. The turrets aren't as big of a deal as we make them out to be. They don't look like crap at normal zoom. Code freeze, yeah, but this would only change the txt file, so no code is involved. As for not being a big deal, I was just thinking that it would prevent us form getting bug reports, since I don't think we want to mention that multi-turrets are still somewhat broken in the ChangeLog ? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Proposed patches for tags/2.3.0
On 4/22/10, Christian Ohm wrote: On Sunday, 18 April 2010 at 13:21, buginator wrote: ** DO NOT COMMIT into tags/2.3.0 without ML or IRC approval *** Things we might possibly want to include in 2.3.0: http://developer.wz2100.net/changeset/10659 - fix compilation with gcc 4.5, only needed for debug compiles though. http://developer.wz2100.net/changeset/10681 - draw subtitles with shadows, improves readability. http://developer.wz2100.net/changeset/10682 - remove the allowSubtitles variable, which prevented the subtitle option from working. http://developer.wz2100.net/changeset/10683 - retry in windowed mode (could be snipped after the first change in screen.c). None of those are really critical, just nice to have, but I think there's very little risk in incuding them. I more or less agree, however, I also have that nagging feeling back in my head saying we shouldn't put anything else besides bug fixes at this late stage. I know I was for it when we first talked, but thinking about it a bit more, makes we want to wait until 2.3.1. If the others want these patches in 2.3.0, then I am fine with that as well. I tested 10681, and it does make it more readable, the others, I haven't really tested. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] getting user art in the game
On 4/20/10, Per Inge Mathisen wrote: On Tue, Apr 20, 2010 at 11:36 PM, Stephen Swaney wrote: An idea worth stealing? Indeed. Note that such images should not have the logo written into the image itself, as we draw it over the image anyway. Nor we need to pretend Pumpkin Studios has anything to do with this game anymore. While they don't have anything to do with the game anymore, I see it as more of a token gesture of thanks for getting the source out in the first place. The current credits.png needed to be redone, to correct the incorrect information in it. I also like those images as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] getting user art in the game
On 4/20/10, Guangcong Luo wrote: As I've mentioned several times, there are ways of gesturing thanks that don't mislead users into thinking Pumpkin Studios made 2.3 (and since they're defunct, Warzone must be a dead game). I mean, there is something wrong if Pumpkin Studios gets more attention than Warzone 2100 Project. I think the least misleading would be to put Based on the game by Pumpkin Studios in the fine print. Hmm... ok, that works for me. Save the pumpkin :P Resize it to 20 pixels ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10523] branches/2.3/data/mods/multiplay
On 4/12/10, Dylan Dog wrote: ok, sorry but I have very low knowledge about svn. I had downloaded the two mentioned files, modified them locally then when I tried to commit them TortoiseSVN always gave me an error back (file already exists ??) which avoided the update on the branch. That is the reason why I deleted them first. Next time before doing something new to me I will ask if this is ok. Just to give you an example of how bad is my knowledge of SVN...I do not even understand then meaning of : all you need to do is merge it from trunk (or whatever) Maybe few words (really few) on the meaning of TAG, BRANCHES and TRUNK could help me a bit. Trunk is more or less, a base of operations. We branch from trunk to create a specific revision, like 2.2 or 2.3. When we do releases, we then create a tag from the branch, and that is the 2.3 beta xyz or 2.3.0 stuff you see. Here is just some general info. The easiest way to handle svn, is to edit the files in svn directly, (as in, make all changes to your mod in your local svn repo) and you may mark things to add or remove via the menu item commands. Don't just delete them via hitting the delete key, or dragging it to the trash, and don't just drop new files first, without doing the svn add menu command. If you are changing things outside the repo, most of the time, you can just copy over the files into the repo itself, and TortoiseSVN will pick up the changes, and you can commit that way. This will only work, if files of the same name are there. If not, you need to use the svn add command. For merges, again with TortoiseSVN, once you commit to trunk or a branch, and you need the same patches to another location, you just select merge, and tell it the source url, and then check the 'ignore ancestry' to make it not do the 'merge info:' changes, then it will report if OK or if conflicts. If conflicts, you just edit them via the 'edit conflicts' menu item. You can't merge things from a branch if you copy stuff to your local svn repo before the merge, or you will get that file already exists error. Let svn handle all the file copys, and don't do it by hand if you do merges. Sorry if this is a bit wordy, but if you have any question, either e-mail us, or get on IRC, freenode, #warzone2100-dev and ask. :) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
