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 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 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] [Warzone2100-commits] [Warzone2100/warzone2100] 845d42: Add a 'Need more resources' indicator in the power...
On Thu, Feb 16, 2012 at 4:04 AM, GitHub wrote: > Commit: b18b76ea8a553b06c4f7258fc8432c7db280b9aa > > https://github.com/Warzone2100/warzone2100/commit/b18b76ea8a553b06c4f7258fc8432c7db280b9aa > Author: vexed > Date: 2012-02-15 (Wed, 15 Feb 2012) > > Changed paths: > M src/qtscript.cpp > > Log Message: > --- > Don't hide possible misnamed or non-existent function calls in qtscript's > backend. We now give a LOG_WARNING to notify us of the possible error. NOTE: > might be better to promote this to LOG_ERROR, so we can tell in-game that we > have issues instead of parsing log files. A script should not get a warning for every event it does not implement. If you want to warn about misnamed timers, this function needs an additional bool parameter that is not set for events. If you want to warn about misnamed events, then we could check for functions named event*() but not in the set of defined events on load (could be a job for lint, but not sure if that is the right tool for the job anymore). - 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 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
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 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
[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] [Warzone2100-commits] [Warzone2100/warzone2100] 4a227a: Add a map preview tool, fix various things in tool...
On Wed, Jul 27, 2011 at 2:40 AM, 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 .ini file - this replaces the current .gam file and the map's addon.lev entry. 2) Maps are moved to data/maps/ which contains .ini and either a .zip OR a / 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// 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 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
Re: [warzone2100-dev] adding a linear algebra library
On Tue, May 17, 2011 at 7:44 PM, Safety0ff wrote: > Is everyone still on board with this? I am, but I think we should use the recently released Eigen 3, which is still not much supported on linux distros. Not sure if that means we should inline it in our own distribution for a while. By the time master is stable for release, Eigen 3 is probably everywhere, and we can drop our own copy of it. - Per ___ 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 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
[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] Using Qt for a front end for Warzone ?
On Tue, May 3, 2011 at 3:22 AM, buginator 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 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 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 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 9:47 PM, buginator 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
Re: [warzone2100-dev] Plan proposal
On Sun, Apr 24, 2011 at 12:43 PM, Christian Ohm 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] Plan proposal
On Sun, Apr 24, 2011 at 2:13 PM, Safety0ff 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
[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] demote Asserts to LOG_INFO
On Sun, Apr 24, 2011 at 6:36 AM, buginator 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] 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 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 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 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?
Safety0ff: is windows 2000 > or < windows xp in terms of compatibility? Windows 2000 < Windows XP i think windows xp is a good lower bound for supported windows platforms 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) from wikipedia: "Unsupported as of 13 July 2010" (for 2000) 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 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 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 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 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, 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, 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
[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
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, wrote: > Branch: refs/heads/3.0 > Home: https://github.com/Warzone2100/warzone2100 > > Commit: cc0756a10adaf59e67dd29e13ad60cdd75e43514 > > https://github.com/Warzone2100/warzone2100/commit/cc0756a10adaf59e67dd29e13ad60cdd75e43514 > Author: safety0ff > 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
Re: [warzone2100-dev] 2.3.6
On Wed, Nov 24, 2010 at 5:43 PM, Christian Ohm wrote: > That commit is not the one in 3.0, it should only affect terrain, not > buildings. Not sure about the exact effects it will have though. It will still hobble the AI, since it does not understand that firing at terrain does not do much good. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] 2.3.6
I saw in the changelog to 2.3.6 that this fix had been included: * Fix: Projectiles going through terrain due to bad terrain height calculations, terrain shading (commit:08f9fa58789d20c64ed8eaa0e9076b08d4cf8947) Given the number of problems with the side-effects of this fix (cannot shoot over buildings, AI keeps shooting at terrain), I would strongly urge that this fix is not included. Otherwise we might have to do a 2.3.7 later on to fix all its complications. - 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 2:17 PM, Cyp 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
Re: [warzone2100-dev] [Warzone2100-commits] mainline - master: 2 commits.
On Mon, Nov 1, 2010 at 1:34 PM, Cyp 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
[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] Textures done, planning on a 'testing' build this weekend
I'm a bit out of the loop, I guess, on the git stuff. Are we now all using gitorious, or are some people still hanging out at sf.net? If gitorious is so horrible, perhaps we should try github? I use that for another project at work with rather large data files, and it seems snappy. - Per ___ 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. 10f2bdede638766ed0ea198d750a00af95fbf110
I am a little confused by these commit messages. First, why are so many sent by dak180, even though he is not the committer? Second, I really really miss the ability to see the diff in trac with a link from the email. That was so helpful for a quick post-ex-facto code review. Since we do not have this link, it would be especially important to have a reference to the change's ticket. And to use the ticket system to allow code review before making changes. Changes like the below trigger my uh-oh filter, but by the time I get back to my dev box, I will have forgotten about it. - Per On Wed, Oct 13, 2010 at 2:20 AM, dak180 wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "Warzone 2100 Project.". > > The branch, master has been updated > via 10f2bdede638766ed0ea198d750a00af95fbf110 (commit) > from 5923c455936febbf4303e80f22ac2c8ae431c6a1 (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log - > commit 10f2bdede638766ed0ea198d750a00af95fbf110 > Author: Giel van Schijndel > Date: Wed Oct 13 00:10:03 2010 +0200 > > scriptfuncs: store (possibly) signed values in signed variables > > Store map coordinates in a pair of signed integers as that's how > map_coord returns them. > > Signed-off-by: Giel van Schijndel > > --- > > Summary of changes: > src/scriptfuncs.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > > hooks/post-receive ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
[warzone2100-dev] Qt branch
I was told by Zarel and cybersphinx earlier that you absolutely needed resolution changing before qt-branch could be merged, and now that I've started working on it, you tell me you do not want it anyway? (http://forums.wz2100.net/viewtopic.php?f=4&t=6611) Instead you come up with new arguments why windowed fullscreen is unacceptable, which would have been nice to hear before we spent a ton of time polishing qt-branch to be merge-worthy. Really. Disappointing. So where does this leave Qt branch? Writing our own support for true fullscreen may be tough. I am not sure if using another library to set true fullscreen then leaving it to Qt to control is even possible. But I could look into it. However, if you see any other problems with Qt branch, then please put them forward now, here, not hide them away for surprises later that you can drop into a random forum thread. Or maybe I should just play Starcraft2 instead. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] SVN repo @ SF decision
On Sat, Oct 9, 2010 at 10:00 PM, Giel van Schijndel wrote: > If by delete everything you mean 'svn rm' style deletion (i.e. a commit > to remove everything from svn HEAD) then I agree. That means if you do 'svn up' by accident on an old checkout, your entire working tree is totally FUBAR. Please don't. At least not yet. - 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 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] (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 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] A quick question about the project.
On Tue, Sep 28, 2010 at 5:25 AM, buginator wrote: > On 9/27/10, buginator wrote: >> It was said that it would be a good idea to get a CVE. >> http://cve.mitre.org/cve/obtain_id.html >> >> Anyone care to chime in on this one way or the other ? >> > > Since I was just a tad bit too terse... the reason for this is: > > So we can have some co-ordination with the security team of all the > distros who are distributing wz. > > See their FAQ entry: http://cve.mitre.org/about/faqs.html#a4 I am confused. You have a security issue you are going to need to go public with? - 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 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] adding a linear algebra library
On Mon, Sep 20, 2010 at 4:05 PM, Giel van Schijndel wrote: > I would like to propse to add a linear algebra library as a dependency > to Warzone. One library I have in mind (and have had good experience > with in the past) is Eigen [1]. Eigen is really nice. However, it requires turning every piece of code it touches, and the matrix code touches quite a bit of code, into C++. I also could not find any info on whether it would solve our determinism issues wrt various compilers doing floating point rounding slightly different. Not that it has to solve this, we can keep avoiding this problem by avoiding floating point in game logic code. - 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 1:42 AM, Giel van Schijndel wrote: > Moreover, *why* does it need to be in fixed point? Did you miss all of the discussion about how the FPU rounds differently on some platforms in some cases? We need fixed point to get determinism. Epsilons do not help. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] piematrix: prepare for removal of fixed point math
On Sun, Sep 19, 2010 at 10:59 PM, Giel van Schijndel wrote: > Do you have any pointers regarding *where* it is used for game state? Projectile code. > Is it used by newnet only, or by trunk as well? Newnet is trunk. BTW, do you ever look at your IRC window (or however you visualize your presence there)? It is somewhat frustrating to try to talk to someone who pretends to be present but never responds. - 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:[11708] trunk
On Sun, Sep 19, 2010 at 10:13 PM, wrote: > Log Message: > --- > piematrix: use floats instead of fixed point DEG degree values for rotations > > Allow passing of degrees as floats to the pie_MatRot[XYZ] functions. > > This commit further helps in getting rid of fixed point math. You should post such patches for comment before doing such things. I suggest you wake up on irc for once and talk to us before doing more of these changes. - 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 Sun, Sep 19, 2010 at 10:12 PM, wrote: > Log Message: > --- > piematrix: prepare for removal of fixed point math Careful! I believe some of this math is used for game state, and that needs to be in fixed point, or else newnet will break. - 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 Thu, Sep 16, 2010 at 6:00 PM, Giel van Schijndel wrote: > Considering that most places we use "SDL_opengl.h" we only use it to > properly include "gl.h" and "glu.h" we could probably take that part > from "SDL_opengl.h" (which is independent of SDL) and move that into a > wrapper header in lib/framework/ or lib/ivis_opengl/. That would > additionally make porting to GLESv2 (OpenGL ES 2.0) slightly easier by > requiring the addition of preprocessor conditionals to only that header. > > How would you feel about that approach? I'm reasonably sure it will > even reduce the Qt branch's breakability with respect to the GL/SDL > combination. If what you are suggesting is to make a new OpenGL header wrapper header file (mmm, I like the sound of that), then by all means feel free, as long as you fix the resulting breakage in Qt branch while you're at it :-) - 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, wrote: > Log Message: > --- > Replace #ifdef(APPLE) #include <$path/gl.h> sections with > 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, 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 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, 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 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] Our next release plan?
On Mon, Jul 26, 2010 at 9:37 PM, Guangcong Luo 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] 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 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] 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
[warzone2100-dev] Launchpad bugs
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 -- Forwarded message -- From: "Paul Wise \(Debian\)" <500...@bugs.launchpad.net> To: warzone-...@gna.org Date: Mon, 26 Jul 2010 20:24:43 - Subject: [Bug 500843] Re: Warzone freezes during single mission I just uploaded 2.3.2 to Debian sid, please test it when it reaches Ubuntu. -- Warzone freezes during single mission https://bugs.launchpad.net/bugs/500843 You received this bug notification because you are a member of Warzone 2100 Project, which is subscribed to warzone2100 in ubuntu. Status in “warzone2100” package in Ubuntu: New Bug description: Binary package hint: warzone2100 Playing with Warzone 2100 2.2.2+dfsg1-1 on my Dell Latitude D620, Karmic, all patches applied. During a single mission the screen freezes, the cursor moves and sound cycles, but I'm unable to switch to desktop and kill the game. Working in 1024x768. If this can help I was obtaining support troops with the space ship. I had to switch to another terminal, login and shutdown -r now. I don't know if this problem is somewhat related to Bug #428828. The problem occurs both with Compiz enabled or disabled. ___ 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 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
[warzone2100-dev] Suggestion for a distributor notice
I felt like writing a suggestion for a note to distributors, intended to be a new file "DISTRIBUTORS", summarizing some of the info and advice that I've given various distributors over the years. Please take a look and comment. - Per A note to distributors == We are very happy to have a number of organizations and websites that distribute the game that we are working so hard to improve. There are a few guidelines we would like to ask you to follow, which will make life easier and better both for us, you and for your users. If you distribute unmodified binaries = If you wish to distribute unmodified binary builds made by the Warzone2100 team, such as on a CD/DVD or a website, feel free to do so according to terms of the licenses on the product. There are multiple licenses, and the strictest is the GNU GPL (see COPYING). It is our belief that if you are compliant with the requirements of the GNU GPL, then you will also be compliant with every other license (for a list of these other licenses, see COPYING.NONGPL). For you, this means in particular: * You can distribute the game for free or for charge as you like. * You need to distribute the source code of the game along with the game binary. This is required by the GNU GPL. * If you distribute from a website, it is sufficient to offer the source code as a download from the same location as the binary. * If you distribute on physical media (eg CD/DVD), you need to include the source code on the physical media, or a written offer to send them the source code. * You do not need to advertise the presence of the source code, but we would like to ask that you include a note saying that it is the source code, and that the user can get the latest version by going to our website (http://wz2100.net/). Please make sure you distribute the latest stable version. This will make your users so much more happy. Note that we are not able to give you permission to distribute the game under any other terms. We will under no circumstances give any assurances, guarantees or indemnifications of any kind. If you wish to read more about the legal history of the project, see COPYING.README. If you wish to distribute rebuilt versions == This is for those who would like to make and distribute their own builds of the game, for instance Linux distributions. You must likely already know how to deal with licenses and have your own procedures in place to handle this; if not, read the above section for advice. Please follow these guidelines: * Use a stable release. Do not use a snapshot of one of our development or release branches. This is a multiplayer game, and users like to play against each other. To do this, they need the same version. If you use a random snapshot of our tree, you may cause problems for other users as well are your own. It will also annoy us greatly when your users report bugs against versions we never intended as a stable release. * Please use the latest stable release. Users like to play against each other, and out of date versions will have few if any users online. * When running ./configure, add your own --with-distributor= flag, where is the name of your distribution. Please DO NOT use "wz2100.net", even if you are merely rebuilding unmodified source code. * Please do not modify the game's behaviour in any way. This may cause out of sync issues in multiplayer games. It will also make it harder for us to respond appropriately to bug reports. * Please add your distribution and version of the game distributed, and any modifications you have done, to http://developer.wz2100.net/wiki/Distributors If you have your own bug reporting system that receives bug reports from your build, please add a link to it. Note that if your distribution has space issues, you do not need to package the large video sequences in the main game package. The game will run fine without them. ___ 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] 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] Breaking netcode compatibility?
On Sun, Jul 4, 2010 at 11:00 PM, Guangcong Luo 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] svn/2.3 feature locked status, and what should happen with it
On Thu, Jun 24, 2010 at 5:40 AM, buginator wrote: > If we start to add features that do require beta testing, what are we > going to do ? We could do beta testing... - 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
One thing we should consider backporting to 2.3 is the wavecast code, which makes visibility a ton faster in trunk than in 2.3. - 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, 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] Endianness function reorganization proposal
On Mon, Jun 21, 2010 at 7:37 AM, Safety0ff 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 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
Re: [warzone2100-dev] Qt branch - final call
On Mon, May 24, 2010 at 9:34 PM, Christian Ohm 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
[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] 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 10:11 PM, Christian Ohm 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] 2.3.1?
On Tue, May 18, 2010 at 9:07 PM, Christian Ohm wrote: > How about releasing 2.3.1 soon? There have been quite a few commits since > 2.3.0, arguably the most important being Dydo-AI's license. If that is the most important thing that has been done, then surely there is no hurry? - 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 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] low polygon buildings
On Thu, May 13, 2010 at 1:22 PM, Sebastiano Giuseppe D'Agata 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] Release plans
On Thu, May 13, 2010 at 2:20 AM, buginator 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
[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
Re: [warzone2100-dev] [Warzone 2100 Trac] #1847: Preliminary qt->trunk merge patch
On Wed, May 12, 2010 at 3:51 AM, buginator 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] 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] Rename .img files to .csv?
On Mon, Apr 26, 2010 at 6:18 PM, Guangcong Luo wrote: > Currently, we have two text files in data/base/images/, intfac.img and > frontend.img, which have the .img extension. > > Unfortunately, .img means "Disk Image" in Mac OS X, and means "disk > image", "bitmap graphic", etc in several other obscure programs. This > makes it rather difficult to open in a text editor, and I'd rather not > reassign the default application since I do have disk image files with > that extension. > > The simplest solution is to rename the extension. .txt or .csv works > for me. What say the ML? It will break mods... - 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 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] Debian and warzone2100 2.3.0 issues (Dydo-AI etc)
On Sun, Apr 25, 2010 at 3:49 PM, Paul Wise 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 8:58 AM, Paul Wise 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] Disable mutli-turrets (again) for 2.3.0 ?
On Sat, Apr 24, 2010 at 5:32 AM, Guangcong Luo 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 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 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 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
