Re: [warzone2100-dev] Plan proposal
On Apr 26, 2011, at 4:10 PM, Christian Ohm wrote: On Sunday, 24 April 2011 at 21:28, dak180 wrote: It sounds like the development model described in http://nvie.com/posts/a-successful-git-branching-model/ Mostly it is influenced by the Linux kernel development process (arguably the group of users most familiar with git). I have yet to see a clear illustration of how the kernel development is managed can you point to what you would consider to be the best such? -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Apr 24, 2011, at 3:19 PM, buginator 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. While it might be the only one currently maintained there is also: https://github.com/dak180/WZME If someone wants to resurrect it. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Apr 24, 2011, at 3:40 PM, buginator wrote: * 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. The no Mac developers is the only real sticking point for me, since it implies an inability to resolve issues as apposed to the other stuff which are issues that can be resolved. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Apr 24, 2011, at 6:43 AM, Christian Ohm wrote: 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. 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. It sounds like the development model described in http://nvie.com/posts/a-successful-git-branching-model/ Is that what you would like to see us move towards? -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Partial merging of Qt branch
On Apr 16, 2011, at 8:59 AM, Per Inge Mathisen wrote: 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. I think that I would want to see a test branch so I can see what you describe also, exactly which frameworks do you see us using for such an endeavor? -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ 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 Mar 30, 2011, at 3:23 PM, Per Inge Mathisen wrote: And if the above is approved, lua branch will no longer be needed. So once qtscript is merged, I intend to remove the lua branch. Any objections to this should also be voiced now. 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. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] request to remove 3rd party libs that we embed
On Mar 17, 2011, at 8:38 PM, buginator wrote: 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 ? I think that we should figure out how we want to switch to glew and use that to rip out glee. For miniupnp I would want some agreement as to which version I should be putting in the mac builds first. Also I am not sure that all linux distros have miniupnp in them yet, but I may be out of date. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Directory layout changes for future build system
On Jan 15, 2011, at 4:01 AM, Per Inge Mathisen wrote: On Sat, Jan 15, 2011 at 7:18 AM, Safety0ff safety0ff@gmail.com wrote: While working on a CMake build system I took the opportunity to move the contents from lib to src. I have no objection to the reorganising of the code base; in fact I am in favor of it. Generally, I am worried that we are now making so many huge changes to the codebase that all existing patches soon have to be written from scratch. Generally this is why I am in favor of using feature branches in personal forks instead of patches; no mater the changes made they will still be able to be rebased onto the apropreate branch (or merged if there has been a significant change of contents). -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ 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 Nov 3, 2010, at 12:33 PM, Christian Ohm wrote: he git repo on gitorious doesn't have all the history from svn, which makes it somewhat painful to retrace old changes. My local git-svn repo was way better in that regard. Is there a way to redo the repo from svn, doctor the transition from old to new svn (berlios to gna) to give continuous history, clean it up with svn2git, and put all new commits on top of that? This is git, (so in keeping with git=MacGyver) there is a way (perhaps even more than one); the real question is what is the cost of doing so and is the outcome worth that cost? Being far more of an hg person than a git person I have no idea what those ways and their costs might be. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [SF-Git]Warzone 2100 Project. branch, master, updated. a31521f75eb1ec4a27d04667ab46d06488437381
On Oct 16, 2010, at 1:28 AM, Stephen Swaney wrote: Corrections (to me) are welcome if I am mistaken. This was the correction; the master branch had been moved onto lua2 as an accidental result of the recent merge, this corrects that. -- My Web Sites: http://dak180.users.sourceforge.net/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Launchpad bugs
On Jul 27, 2010, at 3:01 AM, Per Inge Mathisen wrote: Hello list, I am seeing a lot of bug coming from launchpad to this list now. They are posted each with a unique email address (like 500...@bugs.launchpad.net), that are rejected since they are not subscribers. How should we handle these? (The admin panel shows 40 launchpad bug report emails awaiting approval from the last month or so.) - Per I suggest connecting launchpad with trac, then all the tickets will be in trac and can be dealt with normally. See https://help.launchpad.net/Bugs/TracPlugin and https://launchpad.net/trac-launchpad for details on how it could be set up -- My Web Sites: http://dak180.users.sourceforge.net/ ___ 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 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? For my solution to work properly it would need to have different names for the lo and hi qual sequences. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt branch - final call
On May 24, 2010, at 4:19 AM, Per Inge Mathisen wrote: I put the Quesoglc text renderer back in again in the Qt branch, and now text drawing should work as good as before on every platform. Possible other problems related to clobbering OpenGL states should be fixed as well. Can platform maintainers (or others) please update build files and check if there are any further remaining problems before we can merge the Qt branch? Thank you. I have added QuesoGLC back to the mac build; all text issues appear to be gone. When this gets merged back into trunk please just use the macosx directory as it is in the qt-trunk branch; I will fix any issues arise after the merge. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
On May 18, 2010, at 4:11 PM, Christian Ohm wrote: And it also doesn't seem like there is much else planned for 2.3.1, so what would we be waiting for? I would not mind getting the launcher applet finished for the mac so it can download the videos on first run. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ 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 May 17, 2010, at 8:31 PM, buginator wrote: 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. 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. 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 (⌘). The ctrl key is primarily used on the mac with the mouse to generate a right-click event; which I can tell you already works as expected on the mac. On the topic of what do other game do, particularly ones that are cross platform, my experience has been that if they use modifier keys at all they do not use them as modifier keys, only as normal key presses. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Let's git going
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 Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ 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 Apr 22, 2010, at 6:17 PM, Christian Ohm wrote: Things we might possibly want to include in 2.3.0: http://developer.wz2100.net/changeset/10690 - Distinguish between different types of .wz files -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Bugs for next beta
On Apr 5, 2010, at 3:58 PM, Per Inge Mathisen wrote: I did some testing on Windows this Easter, and the crash report dialog when running in fullscreen is worse than useless, it freezes the entire game, giving a black screen. This needs to be fixed, or the dialog can just as well be removed altogether. (How does this work on X11/Mac now?) Not having tested it fullscreen I suspect it could do Bad Things™ on the mac too depending on the exact method used. Additionally after having looked into how we are doing the alert on the mac to see if we could get clickable urls I found that this is not something we can keep as it will not work in 64 bit. It should be replaced with an alert built on NSAlert in trunk, though for 2.3 since we will not be doing a mac 64 bit release it does not matter so much. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] More png Crushing
On Mar 24, 2010, at 9:25 AM, Stephen Swaney wrote: Nine hours work to reclaim 100kb of disk space hardly seems like a good idea ever. The point was not primarily to save disk space (though it is a nice benefit) but rather to rearrange the why that data is stored in the png files to allow for less overhead in reading them and to cut down on overall network transfers (which has a cumulative effect over time far beyond the disk space saved). -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Clang analysis results for 2.3
On Feb 26, 2010, at 2:57 PM, Christian Ohm wrote: A build with the Clang static analyzer (scan-build ./configure scan-build make) gave the following output: http://the_cybersphinx.users.sourceforge.net/warzone-2.3-r10022/ A lot of the results are false positives because of the... creative... use of pointers, but a lot of valid stuff as well (for example, the deltaX stuff can still divide by 0). Sourceforge says they have no quotas for their web space, let's hope that includes 200 MB of formatted source... ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev I did something similar for trunk a while back: http://dak180.users.sourceforge.net/throwfiles/m6afd7c17.txt (somewhere between 9784 and 9795 or thereabouts) Note though, that the Clang static analyzer cannot yet parse c++ code so anything that depends on a cpp file is likely a false positive. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Rail Guns are Misnamed
Rail Guns as described and as depicted in the in-game modules are actually Coil Guns. We should probably rename them to reflect this, as that would be easer than redoing the descriptions and modules. http://en.wikipedia.org/wiki/Railgun http://en.wikipedia.org/wiki/Coilgun -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] *If* we move to a new SVN server, then these restrictions apply
On Feb 11, 2010, at 10:17 PM, Stephen Swaney wrote: On Fri, Feb 05, 2010 at 09:33:11PM -0500, buginator wrote: = Note that this new environment has the following up-front limitations: * No integration with the trac hosted app * No stats tracking -- changes that occur while this is in test stage may not ever get reflected in the site stats. * Links on the site won't reference the instance (though the permissions in the project admin pages are still applied) * Hooks configured via the site admin interface will not be applied to this test instance (you can manually configure them via the direct shell access) * Developer access will be via svn+ssh:// protocol * Anonymous access will be via svn:// protocol * URLs and file paths will be different * Multiple repositories per project will be supported * Direct repository access will be provided via the shell service (adminrepo will not be needed) * The web interface is WebSVN The lack of Trac integration would seem to be a stumbling block. The configurations issues are an annoyance - at least for the administrator. The rest is not a problem. We do not actually use the hosted trac on SF. I am more concerned about svn+ssh, looking at the svn manual they do not recommend using it. For full encryption they recommend svnserve with SASL encryption instead. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.choosing.html#svn.serverconfig.choosing.recommendations -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Don't commit 'devpkg' files to svn
On Feb 2, 2010, at 5:59 PM, Guangcong Luo wrote: On Tue, Feb 2, 2010 at 4:05 PM, buginator buginato...@gmail.com wrote: This is very annoying, all dev packages should belong where we have all the rest of the dev packages. Namely, here: http://download.gna.org/warzone/development/devpkg/ I would prefer if we moved everything off gna.org, but otherwise I would be fine if a Mac devpkg were externalized and placed in Sourceforge, Giel's server, or wz2100.net. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev As I do not have access to upload anything to the gna site, (and from reading their docs setting up to do so seem like it would be a pain) I would definitely vote for putting dev packages elsewhere. Given the options that Zarel presented I would vote for putting them on SF if for no other reason then the other options would generally mean more work for someone (I am a huge fan of less work). -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] VCS / DCS changes?
On Jan 29, 2010, at 10:39 PM, buginator wrote: Now, since it looks like most of the new guys, and the old guys like git better anyway, we won't bother with hg. The question is, do we want to give the new BETA svn server a shot, or should we just switch to git and hope all goes well for everyone? As someone who has never used git before I would vote for sticking with svn for now at least. The other issue is (am I the only mac person that does not use another os?) there are not many GUIs for git on osx yet and only one that is out of alpha, gitx which is still in beta. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Merging the Qt branch
On Jan 29, 2010, at 10:16 PM, buginator wrote: I can take care of the MSVC files, that shouldn't be a problem. I have made Qt stuff before with it. I have run into some issues trying to get the qt stuff working with xcode (my first time working with qt, so ok); you (or anyone else) would not happen to know anyone who has successfully integrated qt into an existing xcode project? From what I can tell the only officially supported method to use xcode with qt is to have qt generate the xcode project; this would not work well for warzone for a number of reasons (qt does not support making xcode projects with many features we need: separate settings for debug builds for one example). I may be able to make it work but it will take quite a bit of time and I worry how hackish the result will be. Any help in making this work would be most welcome. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Merging the Qt branch
On Jan 28, 2010, at 7:48 AM, Per Inge Mathisen wrote: Hello, The Qt port branch has come a long way recently, and now runs entirely without SDL and QuesoGLC (and all its dependencies). I would like to merge it into trunk soon, so I would encourage everyone to take the branch for a test run, and see if you can find issues in it that need to be addressed first. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev I have been trying to get the QT branch to work on the mac, however I have hit two snags so far. The first one is in 'piepalette.h:95,107'; UINT8_MAX apparently does not get declared in that scope (I have no idea how that happened). The other one is a link error in 'wzapp.o'; it throws the following: Undefined symbols: vtable for WzMainWindow, referenced from: __ZTV12WzMainWindow$non_lazy_ptr in wzapp.o Any ideas about what is at the root of these would be welcome. Additionally since we are no longer using SDL we may want to rename 'SDL_framerate.(c|h)' (at first I thought they were extra files that had been left behind). -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Dropping Support for Building on OS X 10.4
On Jan 16, 2010, at 4:00 PM, dak180 wrote: I would like to drop support for building on OS X 10.4; this will allow changes that will speed up builds. Additionally I would like to get a feel for when we want to drop support for 10.4 entirely; this would allow for many changes including better compiler choices and the potential for 64 bit binaries (intel only), it would also potentially allow us to use the clang static analyzer. -- My Web Sites: http://dak180.users.sourceforge.net/ ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev It has been a week and no one has responded so shortly I will commit this to trunk. I would like some feed back for some idea of when we should drop all support for 10.4. -- My Web Sites: http://dak180.users.sourceforge.net/ smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] New mod system
Simpler for the end user is a plus in my book. it would also make things better for me with defining mods (and their subtypes) vs. maps on the mac. In that same vain I would suggest that maps be named '*.map.wz'. -- My Web Sites: http://dak180.users.sourceforge.net/ On Jan 20, 2010, at 1:57 PM, Zarel wrote: Much easier on users, and simpler directory structure since these mods can go directly in mods/. We can still support the old mod directory format, and any mod not ending in one of these extensions in the new directory will just be treated as a global mod. Thoughts? -Zarel smime.p7s Description: S/MIME cryptographic signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
