Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Fri, Feb 17, 2012 at 3:10 AM, buginator buginato...@gmail.com 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. 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. 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. Some scripts will then contain a few functions of real code, and dozens of no-op functions. Ugly. We definitely should be warning/throwing out errors on all missing triggers or events. Triggers, yes. Events, no. So far, the debuggability of javascript seems not much better than that of wzscript, maybe integrating a QScriptEngineDebugger would help there. Feel free. I do not see the need, personally. if we still want to stick with JS Not doing that is such a stupid idea at this point, I don't really know how to respond. - Per ___ 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 2:49 PM, Christian Ohm chr@gmx.net 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. 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. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] -dev eats mails
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. Same amount of external spam that sf.net has, from my experience. But without the in-email spam that sf.net generates itself, which is the spam that I find the most annoying, because there is no easy way to filter it, and takes the most amount of cognitive filtering to not read (IMHO). - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Unused techs
The current MP tech tree contains a lot of techs that cannot be researched, since none of their prerequisites are ever enabled. Unless someone objects, I will be pruning the tech tree and remove them. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Building both the Qt and SDL version
I think the default version (which is going to be SDL, barring sudden bugs) should be the warzone2100 executable. - Per On Mon, Dec 26, 2011 at 5:56 PM, Christian Ohm chr@gmx.net wrote: https://github.com/cybersphinx/warzone2100/commits/master builds both versions (if the needed stuff is available). That results in src/warzone2100qt and src/warzone2100sdl, and possibly leaves an old src/warzone2100 around to confuse people. Do we want to make one of the new ones take over that name? Probably needs menu entries for both versions as well. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 4a227a: Add a map preview tool, fix various things in tool...
On Wed, Jul 27, 2011 at 2:40 AM, nore...@github.com wrote: Add a map preview tool, fix various things in tools/map. I'm not sure what editor you use, but it totally screws up indentation. Please fix it. I'm not sure why cmake was chosen. It seems a bit out of place. It also does not build here: [per@localhost map]$ make Scanning dependencies of target map2lnd [ 7%] Building CXX object CMakeFiles/map2lnd.dir/map2lnd.cpp.o In file included from /work/warzone-git/tools/map/map2lnd.cpp:9: /work/warzone-git/tools/map/maplib.h:7:20: error: config.h: No such file or directory In file included from /work/warzone-git/tools/map/../../lib/framework/types.h:75, from /work/warzone-git/tools/map/maplib.h:8, from /work/warzone-git/tools/map/map2lnd.cpp:9: /usr/include/stdint.h:41: error: conflicting declaration ‘typedef long int int64_t’ /work/warzone-git/tools/map/../../lib/framework/types.h:42: error: ‘int64_t’ has a previous declaration as ‘typedef long long int int64_t’ /usr/include/stdint.h:56: error: conflicting declaration ‘typedef long unsigned int uint64_t’ /work/warzone-git/tools/map/../../lib/framework/types.h:38: error: ‘uint64_t’ has a previous declaration as ‘typedef long long unsigned int uint64_t’ make[2]: *** [CMakeFiles/map2lnd.dir/map2lnd.cpp.o] Error 1 make[1]: *** [CMakeFiles/map2lnd.dir/all] Error 2 make: *** [all] Error 2 - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Reorganization of maps
As I am nearing completion on my savegame port, I see the need to reorganize the way map / savegame files (hereafter only called map files) are stored and mounted for increased sanity and clarity. This is the plan: 1) All map files contain a map name.ini file - this replaces the current map name.gam file and the map's addon.lev entry. 2) Maps are moved to data/maps/ which contains map name.ini and either a map name.zip OR a map 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). 5) The map is mounted on data root. Internally to the zip, map data is stored in maps/map name/ and other files may override to allow mods. 6) For savegames, a master .ini file maps the save names to the directories of each savegame. The directory structure is numbered. We do not want user-entered data as directory names (either security and bug risk, OR failure to i18n). 7) I also intend to store autogame saves between levels in a similar fashion, but one for each level, and without asking for user description of save. This to allow replay of any level. A conversion tool on the web is provided to convert user maps. My tools/map/mapconv tool will convert included maps. Comments? - Per ___ 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 Sat, Jul 9, 2011 at 6:21 PM, buginator buginato...@gmail.com wrote: 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. That is unfortunate. It is a gray area, and not everyone agree with the FSF's interpretation of the situation (most notably, Apache). Could we ask upstream for a more clear cut license? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Test post
Ignore me. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Campaign resource loading
WIP proposal on how to redesign the campaign loading: New Campaign menu - list of menu items, loaded from directory campaigns, one ini file describing each. In addition, the old campaign, since it is unlikely that we will finish porting it in time for a stable release. Tutorial menu - list of menu items, loaded from directory tutorials, one ini file describing each. (This is btw how challenges are implemented.) Old (current) campaign is loaded using resource files as now. The ini files contain: [General] name = Basic Tutorial Difficulty = Easy Map = data/base/wrf/tutorial/newtut.gam Script = script/tutorial/tutorial.js Data = data/base/wrf/tutorial/newtut.wrf (using a wrf for Data or now -- but this should be changed to something else later) Everything else, including level transitions, is handled through scripts. When one script and level is done, it calls a level change function that specifies what level to load and how. The function can be almost like in wzscript: startMission(int type, string level); the type is passed into the game loading code, and level is the .gam file from which the data is to be loaded. That leaves data changes. This too can be handled through scripts. A new function loadData(string type, string name) can specify a data resource to load, using the resource system (but bypassing the WRF stuff). Example: loadData(SMSG, multiplay.txt); (In fact, this is example is taken from actual code now in master, used for the new AI loading.) Opinions? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Campaign resource loading
On Sun, May 8, 2011 at 8:34 PM, Christian Ohm chr@gmx.net wrote: Is the ini loader able (to be hacked) to ignore _() around string values? Then we could just have lines like name = _(Basic Tutorial) which automatically get added to the po files. I guess for the integrated iniparser in 2.3 that'd be not that much of a problem, not sure if that'd work on master tough. Automatically stripping might be a problem. I can make a convenience function to strip it from individual fields, though. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Using Qt for a front end for Warzone ?
On Tue, May 3, 2011 at 3:22 AM, buginator buginato...@gmail.com wrote: I was pondering, if switching to a Qt frontend for Warzone would be a good idea or not ? IMHO, we should look into using Qt Quick to reimplement the pre-game dialogs first, then use that experience to reimplement the in-game GUI later. No need for a separate executable. It is already separated quite well (to the extent that anything is) in the Warzone source. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.8 and Milestones
On Sat, Apr 30, 2011 at 12:59 PM, Christian Ohm chr@gmx.net wrote: No other changes that should be done for 2.3.8? Well, there was some talk about balance adjustments. I believe there was one range change for which there was pretty universal agreement. Zarel? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Tue, Apr 26, 2011 at 10:24 PM, Christian Ohm chr@gmx.net wrote: I think the feature branches model is our best bet to achieve that. master won't ever have unfinished stuff delaying a release, and features can be developed in a branch as fast or slow as wanted without delaying a release. I still remember lua branch, qt branch, netsync branch, and terrain branch that festered like bad wounds while we struggled with lack of testing and little idea what to do with them until they were merged more or less untested (less true for netsync than the others, but it still had a long way to go after merging). I do not believe this is a silver bullet. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Sun, Apr 24, 2011 at 10:04 AM, Per Inge Mathisen per.mathi...@gmail.com wrote: * We merge Qt branch into master immediately. The commit message may not have looked like much, but the merge has now been done. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] demote Asserts to LOG_INFO
On Sun, Apr 24, 2011 at 6:36 AM, buginator buginato...@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? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Plan proposal
The attempt to do a partial merging of Qt branch into master ran into some problems that required major surgery of master in order to work. The question was posed if we should be spending so much time fixing up master, when we could just be focusing our efforts on making the Qt branch work instead. That is, merge Qt branch into master and go full steam ahead. I now think this is the way to go. This will have some consequences, like not being able to aim for a stable release from master in a while, but if we are serious about the map renderer needing a rewrite first anyway, that is what we would be looking at at any rate. So this is the plan I suggest then: * We merge Qt branch into master immediately. * First order of priority is to convert over to a new savegame and map format. I am working on this, but I need help, especially with review, evaluation and testing. * We need a way for users to convert old maps to the new format. I will write a command-line app to do it, and Fastdeath has offered to set up a php service for it, using that app. * Once a new map format is ready, we can start experimenting with a new map renderer. Of course, these things go together, so I assume that the new map format will have a few revisions before it is stabilized. * The new map renderer should use shaders, but not require as much hardware as the current. Consider this statement ironical? Only if you have made a habit out of thinking that poor drivers mean weak hardware. But lots of recent weak/cheap hardware now have quite decent OpenGL ES 2 drivers. The new map renderer needs to be fast, maintainable, and extensible. * Meanwhile, we also need to get rid of the old scripting system, and I am on the way there with the QtScript port. I am hoping that I can concentrate on this, while someone else have a go at the map renderer. This task does not need to be finished before stable release, but the new script API should be stable by then. * QtGame (support for resolution changing) needs to be finished. * Finally, we should be looking at utilizing Qt for making a new GUI, like we were thinking with betawidget. This task also does not need to be finished before stable release. Other items that would be nice to have before a stable release: * Login support for the game and masterserver. * Observers. * Replay. * Support for adding additional campaigns (in menu, as mod without screwing up original campaign). Ok, comments. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Sun, Apr 24, 2011 at 2:13 PM, Safety0ff safety0ff@gmail.com wrote: Last time I checked, for Qt widgets to work properly on all platforms with Opengl we need to use a qgraphicsview and a qglwidget subclass, and set the glwidget as the background for the graphics view (like this: http://www.qtcentre.org/wiki/index.php?title=Accelerate_your_Widgets_with_OpenGL ). Maybe. The way I see it, we have 3 choices for Qt with GUI: 1) Subclass existing Qt widgets in some way (perhaps as suggested above) 2) Use our own GUI classes, using Qt graphics as basis; eg betawidget 3) Use Qt Quick I know very little about Qt Quick, but it seems worth exploring further before a decision is made. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Plan proposal
On Sun, Apr 24, 2011 at 12:43 PM, Christian Ohm chr@gmx.net wrote: I've wondered if the concept of stable release is actually useful for us. It is useful for users. We should definitely aim for quicker releases later on. Not really sure how to do this. I think this is mostly dictated by what we want to do and how much time people have, anyways. Shouldn't that just read renderer? I think our speed problem is still mostly model rendering. I am not so sure anymore, the problems people are reporting with scrolling quickly sound like they are terrain-related. You said that scripts don't need to be deterministic because they can just run locally and send the results to other players. So a new way to cheat is to just run a custom script? Yes, but they only run on host. I've been thinking that what we can do in the future is to create a dedicated server service on wzhost, which runs the scripts and checks for cheating. But that is a bit off into the future yet. I've had this idea of having a git repository for each savegame, with a save committed every game tick. That could allow to replay, rewind and bisect games. (Maybe every tick is too much, even with a background thread though.) The problem with saving is that it is a stop-the-world event, which cannot easily be run in the background, and definitely takes more time than the current savegame approach can handle. However, if you somehow only save the parts that change between ticks, and use a database, and ... something, maybe. But then why not just save user events, like in Cyp_'s replay patch? And when we have e.g. libgit2 integrated anyway, we could use it as autoupdate mechanism. A new release gets committed to the repo, the game automatically pulls it. Can also be used to detect manipulated data files. Though we might have to use single files instead of zip archives for the data, I think git doesn't do binary changes well (bup might help though: https://github.com/apenwarr/bup). That does sound like an interesting idea. I think the linux distros would hate it, though. They don't like apps having their own update mechanisms. But maybe if it was just for data (including scripts)? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] demote Asserts to LOG_INFO
On Sun, Apr 24, 2011 at 9:47 PM, buginator buginato...@gmail.com wrote: 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. Then stop sending LOG_ERROR to the console? Perhaps make a new LOG_CONSOLE that goes to console? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Partial merging of Qt branch
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. 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? - Per ___ 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 Fri, Apr 1, 2011 at 1:50 AM, buginator buginato...@gmail.com wrote: 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 ? That is up to us. Personally I think we should support it for a little while, but eventually nobody sane would want to keep using wzscript. Are we going to offer some kind of conversion utility ? I'm not going there. As for code review, we need more hours in the day. :( I heard Cyp is working on a way to fix that. - Per ___ 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 Thu, Mar 31, 2011 at 5:08 AM, Safety0ff safety0ff@gmail.com wrote: PS The new javascript scavenger script is attached as an example for those too lazy to look in the qtscript branch. From the script: And we can use the built-in Math library switch (Math.random() * 10) How does that work with Cyp's determinism work? Shouldn't it use our deterministic rng ? Each script runs only on a single player and communicate only outputs to other players, and therefore they do not need to be deterministic. This removes the need to address so many potential issues that I do not think this will or should ever change. (The Spring engine require deterministic scripts, and they ran into some nasty issues with Lua not being deterministic in all corner cases. I could not find a single scripting system that could promise determinism, and I have no idea if QtScript is deterministic.) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Intent to merge, intent to destroy
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. Note that the API itself is far from feature complete. I only implemented the parts that I needed for scripting the scavengers. However, this meant implementing all the difficult parts -- objects, groups, globals, timers, triggers and events. So what remains is merely porting of the old scripts and adding the functions they need. I do not think that a 1:1 porting of the old scripting functions should be done -- it is better to see what is needed for the scripts, and see if we can do them better. If you review the branch, note how the new scavenger script is nearly half the size of the previous script, while doing exactly the same thing. And I dare say it looks better. 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. - Per PS The new javascript scavenger script is attached as an example for those too lazy to look in the qtscript branch. scavfact.js Description: JavaScript source ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Savegame format changes
On Fri, Mar 18, 2011 at 1:30 AM, buginator buginato...@gmail.com wrote: 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. Status - needs more work, but work-in-progress patch and partial conversion tools already exist. Support for droids, buildings, effects, etc. is still lacking. I think the way it saves map data is near optimal in regards to size, and is very flexible for the future. Saving everything else as .ini is certainly something I'm willing to discuss in light of better alternatives. Another possible idea, is stuffing everything into a sql database, and handle savegames that way (one database file per savegame) Even map data? Ugh. For everything else - why not. sidenote: the tagfile stuff should be nuked as well. The sooner the better. However, it is currently used to same some stuff. 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 ? I've been breaking them in the past for master, so... I guess not. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] How long will we officially maintain Windows 2000 compatibility?
per Safety0ff: is windows 2000 or windows xp in terms of compatibility? Safety0ff Windows 2000 Windows XP per i think windows xp is a good lower bound for supported windows platforms per usually i'd say we shouldn't aim to support platforms that the manufacturer has ceased support for, but in the case of windows xp i think i'd make an exception, since so many people refuse to upgrade (for various good reasons) Safety0ff from wikipedia: Unsupported as of 13 July 2010 Safety0ff (for 2000) Safety0ff XP is still supported, so what you would have said still applies - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Cross compiling qt branch
On Sat, Mar 5, 2011 at 6:39 AM, Safety0ff safety0ff@gmail.com wrote: I successfully cross compiled the Qt branch using mingw-cross-env. Awesome! I had to merge master, and I pushed it here: https://github.com/Safety0ff/warzone2100/commits/qt Feel free to push to origin (?) qt branch. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] codebase early spring cleaning ?
On Sun, Jan 30, 2011 at 8:26 AM, buginator buginato...@gmail.com wrote: 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 There is a difference between does not apply cleanly and will have to be rewritten from scratch, though. Right now, I think the only huge things that are not merged is the lua branch and the qt branch. We can presumably run the same operations on these branches as we do to master, though. I have an ECM jammer patch that touches a few files (visibility, map, display3d, ivis). What do other people have? BOOL -bool. Ok. I guess we have to bite the apple, cucumber or whatever fruit that goes into the saying and just do this. astyle We can run this on files that nobody has patches against (probably most files). Running it on everything would be very bad. headers need to be updated to 2011 :) We can do that to files we touch anyway. - Per ___ 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 Fri, Jan 28, 2011 at 2:10 AM, Safety0ff safety0ff@gmail.com wrote: Next subject: Opinions on moving miniupnpc from lib/netplay to somewhere else? I don't really care either way. If you feel like moving it, I'm fine with that. - Per ___ 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 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. 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. This is not cool. Specifically, I do not see a good reason for this change. Compiling parts of a codebase to a temporary library is quite normal practice, and I like having the code available in a shallow structure. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 4af4b8: Use Vector2i in MOVE_CONTROL.
On Sat, Jan 8, 2011 at 2:53 PM, nore...@github.com wrote: Fix autogame AIs building on top left corner of map, if not running on host. What is the difference between NetPlay.maxplayers and game.maxplayers? And shouldn't they be the same (be merged)? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Terrain redesign
We need to discuss how to make the terrain code a bit more sane. The current mess is unmaintainable. I do not have a clear idea about the issue that Buginator found, so I hope that he can write a bit about those. I will focus on the conversion issue. Currently the old (current) map format is loaded, then converted on load using conversion tables in data/base/tileset into lookups into the old terrain tile directories to find decals, and into texpage directory to find the new terrain tiles. Most of the tiles in the old terrain tile directories are now unused, but not removed, just taking up space. Some of the old terrain tiles are converted into decals, with alpha blending added to the tile, and these are chaotically interspersed with the old, unmodified and unused tile files. Nor can the old files merely be removed, since that would break the loader, and if simply renumbered, would break the conversion tables. So there is some work here. What I suggest we do is simply make a clean break. I can modify the mapconv utility I made to break up the game.map file into five, tiny grayscale png files containing terrain map (value + some constant = texture index), height map, rotation map, flip map and decal map. The utility will do the job of breaking down the current map format using conversion tables, so we can take those out of the game. Then I can run the mapconv utility on all current maps and commit those. Perhaps we can even run the utility over all maps in addons, to generate master-compatible addons. Perhaps also make a Windows app out of mapconv to help people convert. Once this is done, the current hard-coded distinction between arizona, rockies and urban will be gone, and their tiles and decals can be used interchangeably. We should also add to the list of decals the delivery points and the VTOL rearm pad. This will make them be drawn properly aligned with the terrain (and remove one more case of the awful manual vertex flattening that is preventing us from using VBOs). If you have other opinions and information about the terrain renderer, please add them in comment. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Need review of order/action change
This is arguably more correct, since micro-AI should not change orders, and fixes #2391, but could have side-effects I am not aware of. So please comment if you suspect something might get fishy. Patch: http://developer.wz2100.net/attachment/ticket/2391/aishoulduseactions.diff - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] 71d5f8: Remove all traces of the utterly useless apsOilLis...
On Fri, Dec 10, 2010 at 5:07 PM, nore...@github.com wrote: Remove all traces of the utterly useless apsOilList. This deletion spree was inspired by the fact that the condition psStruct-type == REF_RESOURCE_EXTRACTOR can never be true for structures, since OBJ_STRUCTURE ≠ REF_RESOURCE_EXTRACTOR. While it was never used, I did have plans for it. I'd appreciate a heads up before stuff I only recently added is nuked. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] [Warzone2100/warzone2100] cc0756: Use the stats to determine struct height and clea...
On Sun, Nov 28, 2010 at 10:21 PM, nore...@github.com wrote: Branch: refs/heads/3.0 Home: https://github.com/Warzone2100/warzone2100 Commit: cc0756a10adaf59e67dd29e13ad60cdd75e43514 https://github.com/Warzone2100/warzone2100/commit/cc0756a10adaf59e67dd29e13ad60cdd75e43514 Author: safety0ff safety...@users.sourceforge.net Date: 2010-11-28 (Sun, 28 Nov 2010) Changed paths: M src/projectile.c Log Message: --- Use the stats to determine struct height and clean up establishTargetHeight function. This should improve shooting over structures in 3.0. Refs #2331. Can you say a little bit more about why you think this is a good solution? To me, this looks like a huge hack. Stats height values 1 have never been used before, AFAICT, so they might be random for all I know. Instinctively I would think that it is better to find the height from the model, instead of looking some number up in a stats file (which sounds like unnecessary duplication of data). - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Shaders - intent to change
Hello, I am working on improving the model renderer with extensive use of shaders. The reason for this is that model rendering in Warzone is highly dynamic, and trying to fit it into the VA/VBO model without shaders is just not going to work. And without VBOing the models, the new artwork being produce will struggle with performance. The downside is of course that non-shader rendering will be removed. Since further work will require extensive code and model data changes, keeping the non-shader rendering path around will be extremely painful. For more detailed info, see http://developer.wz2100.net/ticket/2310 If there are no objections, I will go ahead with this. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] OpenGL on Windows warning dialog
Hey, I tried to play Warzone 3.0 beta on a friend's fresh Win7 installation, and noticed that the game quit right away. Since I knew there would be an error log file, I figured out that the system lacked proper OpenGL drivers. However, less experienced users would not figure this out as easily, and most likely would uninstall the game. Could someone with Windows write a small warning dialog on the OpenGL error condition, properly #ifdef'ed, that tells Windows users about this issue, and what to do? I think this is a rather critical issue, which should be fixed before 3.0 final. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Breaking savegames for 3.x ?
I suppose the reason why you think savegames will be broken is because you are modifying the scripts? But you can do some script modifications without breaking savegames. As long as you do not change the order of initialization or the number of variables and/or functions, things should be fine. - Per ___ 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
How much lost history are we talking about here? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] mainline - master: 2 commits.
On Mon, Nov 1, 2010 at 1:34 PM, Cyp c...@wz2100.net wrote: Fix power generation speed in multiplayer depending on game options difficulty level. Basically, any player that changed the game difficulty level to help them beat the campaign would end up accidentally cheating 10% extra power in multiplayer... As far as I can tell, the fix will make the campaign difficulty modifier still apply to single player skirmish games. I am not sure if this is intended? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] mainline - master: 2 commits.
On Mon, Nov 1, 2010 at 2:17 PM, Cyp cyp...@gmail.com wrote: Should the modifier affect damage in single-player skirmish? IMHO, no. This is a campaign-only setting. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] trac bug
http://developer.wz2100.net/ticket/1906 No changeset 0054f1c83268bd07b5c9faaf83e2f0b4b64b976e in the repository Huh? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Reordering data layout
On Sat, Oct 2, 2010 at 6:28 AM, buginator buginato...@gmail.com wrote: 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) I do not really see the point. We can easily downscale textures before loading them, and keep low-poly models around always since they do not take much hdd space anyways. - Per ___ 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 Tue, Sep 28, 2010 at 5:25 AM, buginator buginato...@gmail.com 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? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] (Need response ASAP!) The new branch and what we all need to decide on, and some comments about git.
On Tue, Sep 28, 2010 at 4:58 AM, buginator buginato...@gmail.com wrote: Having said that, gitorious was *VERY* slow (35-40K/sec) when I did the initial clone It has been slow for me as well in recent days. Hopefully this is a temporary problem. I kind of assume so, because they host things like Qt there, and I cannot imagine they will put up with slowness for long. 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 ? You know best. (Yes, I know, very helpful.) 2) Which terrain textures should we use, or what combination of textures should we use ? I believe Zarel intends to merge the two sets? 3) Should we use the original models or the original models with TCmask enabled ? We do not have simply original models with TCmask enabled anywhere. The one ticket I saw that claimed to have this turned out to be 1) containing other stuff as well, and 2) had several issues that were never resolved. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11707] trunk
On Mon, Sep 20, 2010 at 10:17 AM, Giel van Schijndel m...@mortis.eu wrote: Except that we never used floats to store HP, experience or power (and never should use floats for that), so those points are moot. Except we did. We used floats all over the place for movement/position calculations, power, experience (still do!), etc., and changing that probably created or exposed some of the bugs that trunk is currently suffering from. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11671] trunk/lib/ivis_common/tex.h
On Wed, Sep 15, 2010 at 9:08 PM, muggen...@users.sourceforge.net wrote: Log Message: --- Replace #ifdef(APPLE) #include $path/gl.h sections with SDL_opengl.h which handles this already Please do not mess around too much with SDL related stuff, if you do not strictly need to, since it breaks Qt branch. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11570] branches/2.3/data
On Thu, Sep 2, 2010 at 6:36 AM, zare...@users.sourceforge.net wrote: Log Message: --- 2.3: Rebalance 0.8.1: - Removed Cyclone turret Did you check that Cyclone is never referenced by the AI(s)? I can't check right now (or for a few days, probably). - Per ___ 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 Wed, Aug 18, 2010 at 1:22 AM, buginator buginato...@gmail.com 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. - Per ___ 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 Tue, Aug 17, 2010 at 6:19 AM, bugina...@users.sourceforge.net 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 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.4
On Tue, Aug 10, 2010 at 2:06 PM, Christian Ohm chr@gmx.net 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? No objections. Perhaps throw in/improve some new maps, if there is time? We could ask if anyone on the forum/irc could add basic/advanced start bases to battle, mischief, cockpit and cockate maps, and include/fix those. - Per ___ 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?
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. - Per ___ 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 Tue, Jul 27, 2010 at 3:22 PM, Per Inge Mathisen per.mathi...@gmail.com wrote: next weekend I mean this weekend. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Our next release plan?
On Mon, Jul 26, 2010 at 9:37 PM, Guangcong Luo za...@wz2100.net wrote: You'll notice on the forums quite a few people disagreed with the trunk power system. I saw only quite a few people saw no reason to change anything, none of whom said they had actually tested trunk. That is only the to be expected level of conservatism in a game this old. As far as _I_ can tell, you are the only person who is making a big fuss about staying away from the 2.3 power system. Well, you and JDW on the forums. The thing I am make a big fuss about is a large change without adequate reason and what I see as spurious arguments. Note that I was also initially sceptical of the new power flow system, but Gerard managed to convince me that it was a good idea. I think that is a strange cop-out, since all of your arguments against the trunk power system apply equally to the 2.3 power system. My largest objection to the trunk power system: - I never know how much power I have, or whether or not I have enough power to do something, since the rate at which it increases/decreases changes several times a minute. This is why I don't want to use it in competitive multiplayer specifically: It's much more important there to know exactly how much power I have. Direct-debit-power-queue and 2.3 are identical as long as no more than one thing is on the queue at a time. See, I do not buy this argument at all. You said yourself that all power systems are essentially identical if you are only producing one thing at a time, and this is true. Hence the claim that 2.3 and direct debit is identical in this case is irrelevant. The only interesting case is the real case -- when you are producing multiple items at once. Here 2.3 and trunk are very similar, and can both be confusing to someone used to thinking in direct debit terms. The case where they differ the most is when multiple items are produced, and expenses are bigger than income. Here 2.3 and trunk are identical, while direct debit is very different. Most of your arguments have been about this last case. That is why now turning about and wanting a return to 2.3's power system makes no sense to me. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Our next release plan?
On Mon, Jul 26, 2010 at 4:22 AM, Guangcong Luo za...@wz2100.net wrote: Ye gods, the last time our current release branch was branched from trunk was two years and two major versions ago. I really don't want to continue that. At least that branch is stable and playable, which is more than can be said for trunk. There is a lot of work ahead of us before trunk is in a release state, no matter what development branches we do or do not merge in. Though I no longer believe that power flow is objectively inferior, I still contest it on the basis that it's a controversial major departure from 2.3. Everyone appears to be in agreement that the trunk power system is inferior to all others We seem to be hearing different things from the same people. In fact, as far as I can tell, you are the only person who is making a big fuss about it. The rest of us have been playing trunk power system happily for a long while now. , and in lieu of a clear winner between the four proposed power systems on the forums, the 2.3 power system should win by default. I think that is a strange cop-out, since all of your arguments against the trunk power system apply equally to the 2.3 power system. I also contest it on the basis that I am nominally the lead balancer here, and power system is arguably a balance-based decision. I disagree that it has anything to do with balancing. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Replacing the power flow system
There has been some discussion about this issue in the ticket ( http://developer.wz2100.net/ticket/1970 ). I suggest follow-ups are posted here, or that we move the discussion over to the forums. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Sending compressed paths over the network
For newnet, we need determinism, and the old multiprocessing framework for path-finding where paths were generated in a separate thread at its own leisure breaks that. However, running path-finding in lock-step with the main thread introduces a very narrow bottleneck in the game that we will always be fighting against. Even if we fix path-finding performance today, we will run into problems tomorrow, when path-finding has become more advanced. So I am proposing we instead send path results over the network, and let the path-finding thread run free again. The problem with that is, of course, the size of paths. Currently each step is a Vector2i, or 64 bits. This means that pathing from one side of a max size (250) map to the other requires us to send a 2000 byte array for the path - and that is if it drives straight ahead. Most paths will be much smaller, though. The best solution to this problem is to compress the path when it is sent over the network. Since paths are now contiguous, all we need is the start coordinates (64 bits, and we have those already), and a 3 bit per tile to indicate the direction of the next tile. This will compress the above mentioned path from 2000 to 75 bytes. Most paths will fit in a single uint64_t (up to 21 tiles). I do not think it is a problem to send this amount of data over the network. Anyone see anything objectionable about such an approach? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Breaking netcode compatibility?
On Sun, Jul 4, 2010 at 11:00 PM, Guangcong Luo za...@wz2100.net wrote: First: I believe that incrementing netcode version in a stable branch is a big thing. I think that incrementing netcode version should always be mentioned in the commit log (no matter which branch), and if done to a stable branch, should be brought up in at least the ML. In addition, patches that break netcode compatibility should note this in the tracker. Can we agree to make this policy? I thought we had already agreed that we break netcode compatibility with each release to be on the safe side. The problem is that every small game-play affecting code deviation between versions will cause out of sync issues. For 2.3 this may drown out in the noise of other sources of out-of-sync-ness, but every source counts, and when newnet hits the streets, this will be absolutely essential. I do not think that requiring people to use the same versions to play together is a big deal. All other games that I know of do this already. For example, changing how fire damage works definitely should count as breaking netcode compatibility. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Replacing the power flow system
I will post my thoughts later. Can you (Zarel) post this on the forums as well to get input from users? And please mention while you are at it how it compares to the current (2.3) power system (which has what I would call two phase power flow system). And it is not at all fair to imply that gerard_ did a stealth commit of the power flow system. It was posted to http://developer.wz2100.net/ticket/386 and left there for a week before it was committed. It was also discussed on the IRC channel. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[11022] branches/qt
On Wed, Jun 23, 2010 at 5:03 AM, bugina...@users.sourceforge.net wrote: Qt dies on this date, Tuesday, June 22, 2010. R.I.P Is this supposed to be some kind of practical joke? - Per ___ 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 Thu, Jun 24, 2010 at 5:40 AM, buginator buginato...@gmail.com wrote: If we start to add features that do require beta testing, what are we going to do ? We could do beta testing... - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Endianness function reorganization proposal
On Mon, Jun 21, 2010 at 7:37 AM, Safety0ff safety0ff@gmail.com wrote: endian_* word (defined in endian_hack.h, inline functions that swap using pointers, used ~511 times) This will go away once we replace the current savegame format. I think we should rename endian_hack.h to wz_endian.h and turn it into the single header that provides all the declarations to deal with endian swapping (for network and other code.) What do you guys think? I am not sure I see a benefit. Anyways, even if you disagree with doing the above, SDL_swap* should be removed in favor of the PHYSFS_swap* and hton* ntoh* ( for nettypes.c). I'm ok with that. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
On Thu, Jun 10, 2010 at 9:52 PM, Christian Ohm chr@gmx.net wrote: Since noone else proposed any maps, suggestions by just looking at the preview (all from the addons page): 2 player: Arena #22, Battle, Stripmine 4 player: Arena #14 (for Dydo-AI), Garond Valley, Spiral Mountain 8 player: Hamilcar, Mischief I did at least a quick test of some maps. Some I have also played a game on. Disliked or broken: Arena #22, Stripmine, Garond Valley, Spiral Mountain, Hamilcar. Please do not include any of these, at least not at this point. Liked, and at least one other person recommended it: Battle (2p), Pass Assault (2p), mischief (8p), Startup2 (2p, might replace existing Startup). I think we can include any or all of these. Once ATWb (4p), the Americas map, has been given a license, and maybe some balancing, I think we can include that as well. It is really cool, although probably not (yet) for competitive playing. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Qt branch - final call
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. This does not mean that I have given up getting Qt to draw the text, just that we may need some more time to pull it off properly, and there is no need to make that delay merging the Qt branch, in my opinion. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt branch - final call
On Mon, May 24, 2010 at 9:34 PM, Christian Ohm chr@gmx.net wrote: Two problems I've noticed: 1. Video playback is very jerky (SDL is smooth). I got the impression it is worse for the first video when several are played (view intro for example, or the campaign start), but maybe it's just more noticeable in the first one. 2. Fullscreen performance is lower. Not when comparing at the same resolution, but since Qt lacks resolution switching I can't switch to a lower resolution to get higher FPS (e.g. on fast play I get 60 fps with trunk at 1024x768, 30 fps with qt at 1600x1200). Can you try now? I removed some text-related hacks in qt branch that fixed performance problems on my end. Also, 3. Qt branch crashes deep inside QuesoGLC somewhere when exiting the program. I have no idea why, and the trace looks really odd when it does. I may need some help with ideas on what is going wrong here. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
http://developer.wz2100.net/ticket/1581 must be fixed before 2.3.1 can be released. If anyone have some suggestions for new maps to include, that would be a nice bonus. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
On Tue, May 18, 2010 at 9:07 PM, Christian Ohm chr@gmx.net 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? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3.1?
On Tue, May 18, 2010 at 10:11 PM, Christian Ohm chr@gmx.net wrote: 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 have no objections. (Although, I just have to point out, pabs can bake in the license fix into 2.3.0 and use that in Debian. This is the kind of thing that package managers do.) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] team colors for old models
On Fri, May 14, 2010 at 3:12 AM, Stephen Swaney sswa...@centurytel.net wrote: On Thu, May 13, 2010 at 08:43:45PM -0400, buginator wrote: Anyone have any objections to this patch: http://developer.wz2100.net/ticket/1757 ? I say apply it. Team colors is the direction we are heading in. I'm fine with the idea. Are the new PNGs much larger now? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Release plans
On Thu, May 13, 2010 at 2:20 AM, buginator buginato...@gmail.com wrote: While I haven't personally tested trunk in a long time, Zarel mentioned that the pathwalking is broken. It is, but there are (too) many patches to fix this problem. This needs to be sorted out, but I do not see this as a long-term problem. 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. The new web page is really nice, but this situation is unacceptable. Easily maintainability must be priority #1. 1) Qt. ... 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 With Qt style sheets? I am not sure why you would want to do that, since it does not give you nearly enough control over how things look. In a game you would typically superclass existing Qt classes to make your custom looking widgets, but where Qt does the record keeping and handling for you. As of right now, I can only think of one advantage to Qt, and that is for the hardware colored cursor support. Hardware colored cursor support was just an accidental improvement along the way. The reason for the Qt port is that Qt offers a much richer base to build upon than SDL. This is what it does now: - No more quesoglc and its dependencies - Better fullscreen handling (ok, cybersphinx disagrees on this one) - Better cursors However, what it does now is not the important thing, but what it can do in the future. Right now the things I can think of are: - SVG support, needed for betawidget - signals/slots, for better handling of multi-threading, eg of scripts - improved network code - widget control, can be used for new widget code - general portability (we can dispense with a lot of our custom portability layer in lib/framework since Qt have these things, also for C code) - a nice base for future c++ porting 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. The most important part of 'Betawidget' to me is the series of ideas that went into it, which I believe are really good, and in order to get there we need the Qt branch, since the original plan depended on a string of icky library dependencies that was simply not workable. The existing betawidget code can be rebased on top of Qt, or we can rewrite it to utilize more of Qt so we have to do less state maintenance ourselves. We really need to get feedback about the current trunk builds, so, we need to start telling people they can download test builds *now*. I agree, but now meaning once we have sorted out the path walking problems. The next biggest problem is, (and I already know there is no easy fix for this), is that everyone still basically does what they want to. We are not pooling all our resources/talent into the same pot. I don't even think this is solvable in a open sourced project. This is not something I would want to fix. What we should do, though, is to make sure we do not accept new changes without discussion, and for larger changes this discussion should go before the implementation. This is not always easy. The Qt port, for example, started off as a simple experiment and grew by enthusiasm as worries over performance and other potential problems were put to rest. Heck, the other problem is, I don't even know the status on what anyone is doing. One day, a commit will be made, and then you know what that person has been up to. That would be completely contrary to the commit guidelines and the way things are supposed to work. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] low polygon buildings
On Thu, May 13, 2010 at 1:22 PM, Sebastiano Giuseppe D'Agata s@gmx.de wrote: Some days before I, visited your homepage and I' ve seen, that you are searching for somebody, who is able to create houses and ruins... for warzone. I know this game and I like to play it sometimes. I'm a draftsman, and I have made gdl- objects and ( Visualisierungen) in the context of my work. I have no experience with games, but I'm interessed to try. So I worked the last days to create low polygon model buildings, inclusiv texture etc. I send you two renderings, one with Gi and one illuminated only with the automatic light of cd4. If you like it, I would like tocreate some more buildings. Hello! Thanks for the interest in drawing buildings. What number of polygons is used for these buildings, and what model formats can you export them to? - Per ___ 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 Wed, May 12, 2010 at 3:51 AM, buginator buginato...@gmail.com wrote: 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. This situation is very unfortunate. I have postponed all of the interesting things that I wish to work on waiting for the big three branches to be merged, because I need their features or to avoid generating massive conflicts. I understand that cyp is also waiting for a newnet merge. The situation is getting worse since our only active mac developer is unwilling to help get the Qt branch working on Mac, and is instead devoting his time to making a patch that will conflict massively with newnet. Can people please help out with fixing and merging the three branches (qt, newnet and lua) instead of doing other stuff? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Release plans
There has been some talk on IRC about future release plans, and I thought we should get that discussion started here. 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? 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). 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. If we proceed to make a release from present trunk, we can probably start the betas for that quite soon and maybe aim for an July/August release. That depends on no last minute large rewrites of anything hitting trunk first. That means: June - 2.3.1 (bug fix only) August - 3.0 (current trunk) December - 4.0 (qt, newnet, lua, new savegame format) Any other ideas? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Let's git going
Ok, sorry about the really bad pun. The point is, I think it is about time to leave the barren wastes of svn behind, and head for the promised lands of git. I've been looking into the newline issues, and I am convinced that they can be properly terminated. That leaves only the question of whether git is good/user-friendly enough on Windows/Mac. Given the amount of cross-platform projects that have converted to (g)it, I think we should manage, too. Anyone else have an opinion? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Debian and warzone2100 2.3.0 issues (Dydo-AI etc)
On Sun, Apr 25, 2010 at 8:58 AM, Paul Wise p...@debian.org wrote: [Please CC me on reply, I'm not subscribed] I just started reviewing the changes between 2.2.4 and 2.3.0 so I could upload warzone2100 2.3.0 to Debian. Unfortunately I noted that the new mod Dydo-AI is CC-NC-SA licensed I suggest you drop it until this has been resolved. Also the embedded miniupnpc and iniparser copies are missing their LICENSE files. For iniparser, this is a license violation. Can you fix this by including the LICENSE file in your distribution copy? Then we will fix this for 2.3.1. In future, I'd really really prefer that you add stuff to devpkg instead of adding embedded code copies like iniparser, miniupnpc, GLee, sqlite and parts of others like BFD, SDL_framerate. Our iniparser is a heavily modified fork and needs to be included. GLee is a single file and meant to be included; it also has some local modifications. We no longer use or include sqlite, if you still have it as a dependency that would be an error on your part. SDL_framerate is not a library, it is a (to be heavily modified in Qt branch) ripped out code from some SDL aux library, so it cannot be externalized. I do not know what BFD is. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Debian and warzone2100 2.3.0 issues (Dydo-AI etc)
On Sun, Apr 25, 2010 at 3:49 PM, Paul Wise p...@debian.org wrote: Folks on IRC suggested that would be easy to resolve so I was going to wait for 2.3.1 to be released. There is no plan for when that is supposed to happen yet. Our iniparser is a heavily modified fork and needs to be included. Any plans to get the relevant changes merged upstream? No, because it is an adaptation to use it with the physicsfs library, and the upstream maintainer has not shown much willingness to integrate such things. (Or much of anything. Upstream has been idle for two years now.) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Debian and warzone2100 2.3.0 issues (Dydo-AI etc)
On Sun, Apr 25, 2010 at 4:20 PM, Paul Wise p...@debian.org wrote: On Sun, 2010-04-25 at 16:16 +0200, Christian Ohm wrote: http://developer.wz2100.net/browser/tags/2.3.0/lib/netplay/miniupnpc says the license file is included, but maybe it's missing from the tarball. Aha, so Makefile.am just needs an EXTRA_DIST line. I see the same thing also applies to iniparser. The AUTHORS, README and LICENSE files are there in the repo, but missing mention in the Makefile.am - Per ___ 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 Sat, Apr 24, 2010 at 5:32 AM, Guangcong Luo za...@wz2100.net wrote: They don't look like crap at normal zoom. Most configurations look like crap even at max zoom out. - Per ___ 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
A release candidate should either be dropped back into beta, or stay in code freeze, which means nothing but build fixes, documentation changes or translations go in. Let's maintain some self-discipline now and ship this thing without further fixes. Then we can focus on making 2.3.1 and trunk great. - Per ___ 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 Tue, Apr 20, 2010 at 11:36 PM, Stephen Swaney sswa...@centurytel.net 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. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10640] trunk/build_tools/changelog2bbcode.sh
On Mon, Apr 19, 2010 at 7:27 AM, Kreuvf kre...@warzone2100.de wrote: Oh what? I tested it with a piece of ChangeLog and it was okay D: Could you describe the problem, per? The headers did not get their [b]...[/b]s set. The -r made everything I learned about sed wrong, so I had to remove that. Please be nice to me and don't put it back ;-) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] 2.3 code freeze until 2.3.0 branch, 2.3.0 release target date 4/24/10
On Sun, Apr 18, 2010 at 2:52 AM, buginator buginato...@gmail.com wrote: Ok, I am fine with either a tag or a branch, as soon as Per OKs it, I'm ok with that. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10607] branches/2.3/data/mods/multiplay/dydo-ai
On Sat, Apr 17, 2010 at 3:11 PM, dydo...@users.sourceforge.net wrote: maps for dydo challenges Added Paths: --- branches/2.3/data/mods/multiplay/dydo-ai/maps/ branches/2.3/data/mods/multiplay/dydo-ai/maps/4c-AllEqual.wz branches/2.3/data/mods/multiplay/dydo-ai/maps/4c-Arena_14.wz branches/2.3/data/mods/multiplay/dydo-ai/maps/CNCAssualt.wz Who made these maps? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
I don't think reverting, re-reverting, re-commiting, re-implementing, etc this 'feature' is doing us any good. Let's just keep it as it is until we have know where the real problem is and have the time to fix it properly. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Bugs for next beta
On Sat, Apr 10, 2010 at 7:01 AM, buginator buginato...@gmail.com wrote: When our game crashes (mingw builds) then it doesn't throw up a dialog at all. Only on MSVC builds it does that. Was 2.3-beta12 built with MSVC? If we got a Fatal dialog, then yeah, screen goes black first, then user must switch back to the desktop to see what it was. :( The other option is run wz as a window that takes up the full screen. Qt branch does this. IMHO this works much better. I still think the current system is better than nothing though. I don't agree. My first instinct was to reach for the reset button... - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Beta 13
I think we should try to push out a beta 13 this weekend. Unless I hear any objections, I will be tagging tonight. - Per 2010-04-00: Version 2.3 beta 13 * General: * Change: Use system dialogs for reporting errors on Mac (r10474) * 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 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Ticket #1746
On Wed, Apr 7, 2010 at 4:56 PM, Zarel zare...@gmail.com wrote: Adds a feature. You keep using that phrasing. For the purposes of deciding whether or not a change should be postponed, I don't think a crash fix should count as adding a feature. ... I have never understood how fixing a crash could ever have any side effects that could justify avoiding committing a fix. Have you ever seen that happen? Ever? I do not like how this kind of heated rhetoric appears again and again every time we try to say no to a change you want pushed into a release immediately. Just two weeks ago in http://developer.wz2100.net/ticket/1702 you argued yourself that this was not a bug. Nor do I think the codebase is as brittle as you claim. So why are we at beta 12 then? Yes, and the standards for inclusion should be _sane_. If we're not going include a crash fix in the next beta, what are we going to include? This problem (loading savegames crash w/o their mods loaded) has been present in every release there has ever been. Why do we need to fix it RIGHT NOW all of a sudden? We have more urgent problems, like fixing the legs bug and a release process that has gone completely haywire. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] A really awesome way to use git...
Apparently, this is _not_ an April's fool: http://github.com/blog/626-announcing-svn-support They are working on full write support. That should take care of the I-must-use-a-GUI issue with GIT. So if anyone know a way to ensure we do not get line-ending problems, we should be set. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Launchpad: Validate your team's contact email address
On Tue, Apr 6, 2010 at 1:43 PM, Kreuvf kre...@warzone2100.de wrote: https://launchpad.net/token/N4wdzvRLDTDlZMSxX4C0 Did anybody follow this link already? ^^ Try it and find out ;-) - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Qt branch merge?
On Mon, Apr 5, 2010 at 11:54 AM, Guangcong Luo za...@wz2100.net wrote: Perhaps we merge Qt+newnet into a new experimental branch, then? That only helps if all the developers start working on that branch, instead of trunk. The new 'experimental branch' would then be the new trunk. So what you are in effect suggesting is to copy trunk into a new to-be-stable branch, before merging in Qt and newnet. That only makes sense if we are planning to release a 2.4 from current trunk without Qt and newnet, and I do not think we are. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.2.4
On Sat, Apr 3, 2010 at 9:26 PM, buginator buginato...@gmail.com wrote: Hey all, just wanted to update a few things about the project. First off, 2.2.4 should be dead. Really. It serves no useful purpose for us at all. I am a bit uncomfortable with that. I do not think we want linux distros etc to use a random 2.3 beta. If I had any idea that the 2.3 series would have dragged on this long, I'd have kept backporting fixes to 2.2 branch and pushed for a 2.2.5 already... Something went awfully wrong on the planning of 2.3 - it was only supposed to be 2.2.4 + the new trunk netcode :-( - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Warzone's direction for 2.3 series
On Mon, Apr 5, 2010 at 9:17 AM, C yp cyp...@gmail.com wrote:
3 possible solutions:
1. Get windows to do floating point correctly.
2. Convert everything to C++, and typedef float Float; on Linux/Mac,
and class Float { ... }; on windows.
3. Use integers only. (Fixed point, that is.)
What parts of the game state still relies on floating point? I can
think of experience, power, movement (though I have an almost complete
patch for changing that, just need someone to up the precision), and
not much else? I do not think this option should be so hard.
- Per
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10489] branches/2.3/src/multijoin.c
On Mon, Apr 5, 2010 at 5:24 AM, bugina...@users.sourceforge.net wrote: Revision: 10489 http://warzone2100.svn.sourceforge.net/warzone2100/?rev=10489view=rev Author: buginator Date: 2010-04-05 03:24:05 + (Mon, 05 Apr 2010) Log Message: --- As a temporary solution to the oil features not being put back. How is this fix supposed to work? - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Bugs for next beta
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?) We should also take a look at http://developer.wz2100.net/ticket/1696 which is related. The well known bugs http://developer.wz2100.net/ticket/1740 (legs - is there more than one report of this happening in beta12?) and http://developer.wz2100.net/ticket/1726 (oil rigs) need to be further investigated. We should also check out http://developer.wz2100.net/ticket/619 (campaign map limiting), and apparently the network code still has issues: http://developer.wz2100.net/ticket/1715 and http://developer.wz2100.net/ticket/1716 Is bug http://developer.wz2100.net/ticket/1039 (WSS) fixed now? Dydo needs the http://developer.wz2100.net/ticket/1736 bug closed before it can be in the release. Unfortunately, I will probably not have much time to look at bugs this week. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] New beta?
Hello all, Even though we are quite short on manpower at the moment, I think we should try to push out a new beta for/during Easter. The reason for this is simply to get more testing of the latest bugfixes, given that beta11 is getting old with lots of fixed bugs. Closing already-fixed-but-not-released bug reports is not fun. Who is around capable of building the various architectures? I can fix the changelog and make linux tarballs, but need help with the mac/windows builds. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] New beta?
On Mon, Mar 29, 2010 at 3:29 PM, Christian Ohm chr@gmx.net wrote: On Monday, 29 March 2010 at 10:58, Per Inge Mathisen wrote: Hello all, Even though we are quite short on manpower at the moment, I think we should try to push out a new beta for/during Easter. The reason for this is simply to get more testing of the latest bugfixes, given that beta11 is getting old with lots of fixed bugs. Closing already-fixed-but-not-released bug reports is not fun. Who is around capable of building the various architectures? I can fix the changelog and make linux tarballs, but need help with the mac/windows builds. I can do a Windows build, though I'm not sure about Easter. How about later today/tomorrow? Fine by me. If nobody has any objections, we can tag today, then people can make builds at their leisure, and we release when all are done. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Make atomic commits, please
Hello, When committing to the svn repository, please make sure, to the extent possible, that each commit compiles and runs. Do not split a commit into pieces where some revisions may not work. The reason this is important is because non-working revisions will make bisecting (going back in time to find when something stopped working) much, much harder. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone2100-commits] SF.net SVN: warzone2100:[10395] trunk/src/map.c
On Sun, Mar 21, 2010 at 6:24 PM, i-...@users.sourceforge.net wrote: Include leftmost and topmost tiles into ground type calculation (#332 and #743). Hint: If you write fixes ticket:332 then it will auto-close that ticket for you and include a reference in the ticket to this commit. Very handy for generating traceability. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1678: Floatingpoint support for texture coordinates in PIEs
I had not really considered the option of keeping two rendering paths for models, one for PIE2(/3) and one for a newer format. It is an interesting idea, since it will keep compatibility with pieslicer and older works. However, none of the difficult issues are solved this way. The biggest issue is how to implement all the hacks that is currently used, like stretching defensive structures to the map, without killing performance. The only way I see is to use vertex shaders, and that requires OpenGL 2.0. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] [Warzone 2100 Trac] #1678: Floatingpoint support for texture coordinates in PIEs
Perhaps I should say something more about my plans. I realized a while ago that moving over to WZM all at once would be really difficult, due to the incredibly complicated model drawing system in Warzone. So I began upgrading PIE models and drawing code simultaneously bit by bit. Removing support for the face full flag was the first step. PIE3 was the next, basically just a way to define what parts of the old PIE format that is currently supported. Then I removed all duplicate vertices in existing models. To be done: - precalculate the tex coords used for frame animation and team colours. - tessellate all non-triangle polygons in existing models, and remove support for them (planned as PIE4) - add clipping to in-game structure menu to cut off z-direction less than zero polygons - add art rework of all defensive bases so that they plunge through the ground And probably some things I've forgotten. At the current rate these plans will be finished (if done by me) at the same time to world ends in 2012 (if that movie is to be believed). - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
