xconq-hackers Mailing List for Xconq
Brought to you by:
elijah_meeks,
matthewskala
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(11) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(22) |
Feb
(6) |
Mar
(9) |
Apr
(27) |
May
(9) |
Jun
(23) |
Jul
(35) |
Aug
(24) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2007 |
Jan
(2) |
Feb
(2) |
Mar
(8) |
Apr
(12) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
From: SourceForge.net <no...@so...> - 2008-12-30 16:00:15
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=5933483 By: eric_mcdonald Jeff - I believe your observation about the level of project activity is correct. I certainly haven't been doing anything on it in the past few years. The state of the documentation is not very good at present. Before I got burnt out, I was restructuring the code and improving the internal documentation and API documentation as I went. Documentation is just one of the many areas that this project could use improvement - meaning volunteers. Basically, you are looking at a bunch of source code from the mid-to-late nineties (some of it has a heritage even a decade earlier than that). Stan Shebs was its creator and original maintainer, but he was last active near the beginning of this century. Since then, various others have come along with different ideas, styles, priorities, and objectives, and the code has lost some of its original coherence and structure. I would call this "hacking" rather than "software engineering". In many ways xConq is now out-classed and obsolete, but I think it does still have some redeeming qualities, especially in the flexible game engine and GDL department. As someone who has poked around with The Battle for Wesnoth, I find that GDL is far easier and less fatiguing to wield than WML (Wesnoth Markup Language), and that even though the Wesnoth engine is much better documented, it still seems more difficult to modify than the xConq one. (This is partly because the Wesnoth engine is much more intended for a very specific family of games, whereas xConq is more generalized. So, maybe its apples and oranges....) If you think xConq's merits are worth capitalizing on, then I would encourage you to contribute to the project. (Yes - there is a bit of a learning curve.) At this point, I can't see myself implementing any more features, continuing the reorganization and documentation process, or fixing any more bugs. But, volunteers are definitely welcome.... ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=422595 |
From: SourceForge.net <no...@so...> - 2008-12-29 20:53:14
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=5927693 By: cpu-write It would do hackers a LOT of good if there was some kind or road map for the source code. When I was in college, I was taught to prepare a README file that listed the names and contents of the various source files. Mind you, I haven't seen a lot of activity on this list, so I'm going to assume that no one is currently (around New Year's Day of 2009) actively working on this project. If that's not true, let me (and, by extension, everyone else on the Source Forge Forum) know about this. I explicitly indicated the date because I expect this message to hang around in the forums for a while. I've got some work I'd like to see done on the game, but, quite frankly, wading through the source code (in a mishmash of 3 or more programming languages (I've NOTICED C, C++ and TCL)) without any documentation is too much like working. In fact, I can find so little documentation on the code itself that I'm going to be making up my own names for things. If there are other terms that are standard, point 'em out to me and I'll use 'em from then on, but you're stuck with 'em in this message. For an example, let's start with something that SHOULD BE simple. The current combat map scrolling scheme sucks. You put the cursor on an edge of the window and it scrolls--and, if you happen to be moving the cursor to one of the buttons on the left side of the game, say, to put a unit to sleep for one turn, it scrolls anyway. Sometimes, this scrolling throws the game out to the point where I send my troops to places where they never should go. Solution: use a scroll bar on the combat map window, like the other games do. (For that manner, the mini-map on the left side of the screen could VASTLY benefit from the same technique.) So...where's the code to set up the combat map window? Is it in the TCL stuff, is it in the C stuff or is it in the C++ stuff? Where is this documented? ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=422595 |
From: SourceForge.net <no...@so...> - 2008-04-17 13:01:27
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=4910897 By: okleist Hello, are there any *.imf utilities for DOS/Windows ? if there are where can i get them ? keep up the good work ;) Greets Olaf ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=422595 |
From: Brian D. <bf...@sb...> - 2007-05-05 04:35:02
|
When unit A attacks unit B which is transporting units C,D,E,F, then a single hit can hit B plus each of the units inside of B, possibly allowing a single hit to destroy five things at once. A single fighter attack on a city can destroy two armies, an armor, and three fighters. Is there a logic behind this, or is this a bug? It makes for intereting tactics where you can greatly reduce an enemy strength if they are holed up. Could logic be added to have everyone flee the container if possible when under attack? Should things which are being carried or contained have extra defenses? --- Meanwhile, an interesting story... I like setting up games against three computer opponents, giving each of them a 2x advantage, and seeing if I can survive. Recently I had a game where i was just about to lose everything when all the sudden a city way across the ocean revolted to my side. After a few more turns I had lost my entire original continent but from that one rebel city I had regained another continent. The computers eventually won, but that sure was quite a time! |
From: Elijah M. <eli...@ya...> - 2007-04-30 17:45:34
|
The SDL interface only shows the units that the selected unit can build. This is preferable, especially when the game in question has a hundred unit-types or if units are meant to be special/hidden. --- ms...@an... wrote: > On Fri, 27 Apr 2007, Massimo Campostrini wrote: > > If a unit (or terrain, or material) type cannot > appear in a game > > (i.e., it is not present and it can't be created > later on), don't > > report the type at all in the interface, neither > in the help screens, > > nor in the unit/material summary... > > I think the current interface is actually meant to > work that way; but as > you've noticed, it doesn't quite work. Part of the > problem is that it's > not necessarily obvious which units and other types > can or can't exist. > To get the right answer you have to trace > recursively through which units > exist at setup time, which units they can construct > (including issues like > "this unit supposedly can create that unit, but > doing so would require > more construction points than it can ever actually > have"), which units can > change to other types as a result of wrecking and > capture, and so on. I > think the current interface tends to err on the side > of caution - it shows > types if it thinks there's ever a possibility of the > type existing, even > if it can't actually. > > This would be a fun use for Prolog, actually - we > could get the whole > theorem-proving thing going for whether a given type > can ever exist. > > Anyway, I'd certainly be in favour of improving this > aspect of the > interface, though my expectation is that it might be > tricky. > -- > Matthew Skala > ms...@an... Embrace > and defend. > http://ansuz.sooke.bc.ca/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 > express and take > control of your XML. No limits. Just data. Click to > get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Xconq-hackers mailing list > Xco...@li... > https://lists.sourceforge.net/lists/listinfo/xconq-hackers > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: <ms...@an...> - 2007-04-30 17:04:43
|
On Fri, 27 Apr 2007, Massimo Campostrini wrote: > If a unit (or terrain, or material) type cannot appear in a game > (i.e., it is not present and it can't be created later on), don't > report the type at all in the interface, neither in the help screens, > nor in the unit/material summary... I think the current interface is actually meant to work that way; but as you've noticed, it doesn't quite work. Part of the problem is that it's not necessarily obvious which units and other types can or can't exist. To get the right answer you have to trace recursively through which units exist at setup time, which units they can construct (including issues like "this unit supposedly can create that unit, but doing so would require more construction points than it can ever actually have"), which units can change to other types as a result of wrecking and capture, and so on. I think the current interface tends to err on the side of caution - it shows types if it thinks there's ever a possibility of the type existing, even if it can't actually. This would be a fun use for Prolog, actually - we could get the whole theorem-proving thing going for whether a given type can ever exist. Anyway, I'd certainly be in favour of improving this aspect of the interface, though my expectation is that it might be tricky. -- Matthew Skala ms...@an... Embrace and defend. http://ansuz.sooke.bc.ca/ |
From: Massimo C. <Mas...@df...> - 2007-04-27 11:45:11
|
I have thought a very simple feature that would help maintaining game variants: If a unit (or terrain, or material) type cannot appear in a game (i.e., it is not present and it can't be created later on), don't report the type at all in the interface, neither in the help screens, nor in the unit/material summary... E.g., if in the steppes game you disable the construction of ships, (table can-build add (cities ships false)) the player will not even notice that ship types are defined (similarly for unused terrain types). Simple variants to the standard game (say) could then be allowed by defining in stdunit and stdterr the most likely additions (like a fighter-bomber unit or a hills terrain) as "empty" types (without non-default properties, table entries, etc.) and not allowing them to appear in the game. ... (unit-type fighter (image-name "trident-fighter") (help "interceptor to get those nasty bombers")) (unit-type fighter-bomber) (unit-type bomber (image-name "trident-bomber") (help "long range aircraft, carries infantry and bombs")) ... (define ok-u (i a f b d s t c b n B T @)) ... I know, you could obtain a similar result by (unit-type fighter-bomber ...) (include "stdunit") ... (table hit-chance add ...) The problem is that the new types appear before the standard ones, not where you would like them. In fact, I have a "standard game + fighter-bomber" sitting on my computer, and I ended up with copying stdunits.g rather than including it. What do you think? Regards, Massimo |
From: Eric M. <mcd...@ph...> - 2007-04-08 19:55:52
|
Greetings xConquerors, Here's a quick update on the status of xConq development. Please (re-)welcome Massimo Campostrini to the xConq development team. Massimo worked on xConq in the previous century. He has recently contributed a number of bug fixes and behavior changes. He has also contributed an implementation of an A* pathfinder, which promises to greatly improve unit movement and AI play. I have placed his contributions on a new branch in CVS, and have given him CVS write access. For those who use CVS, you can follow his progress by checking out the BRANCH_MCAMPO_PATH branch. To do so anonymously (read-only), you can do something like this via the standard command-line CVS client: cvs -z3 -d:pserver:ano...@xc...:/cvsroot/xconq co -r BRANCH_MCAMPO_PATH -d xconq-MCAMPO_PATH -P xconq Eric |
From: Eric M. <mcd...@ph...> - 2007-04-05 16:35:28
|
Lincoln Peters wrote: >> I think if we were going to go that route we might be better >> off just writing a small, simple interpreter from scratch ourselves and >> integrating it tightly - or using an existing open-source interpreter that >> can be embedded. I'm aware of Perl, Prolog, Scheme, TCL, and several >> other such interpreters that can be used that way. > > That might be reasonable. Lua seems to be currently popular among a number of FOSS game developers. It's a relatively simple language and has some following. And, it certainly commends itself to table manipulation, which we do in fair abundance. I'm not necessarily advocating it, but just pointing out some potential merits. >>> Besides, even without changing GDL, we could probably clean up the kernel >>> code and replace all of the linear searches with binary searches. That >>> would provide a huge increase in speed. >> My impression is that a lot of stuff is currently stored in unsorted >> arrays that can't really be searched except with linear search. I think >> significant data structure work would be needed to make the current kernel >> signficantly faster. > > Which is yet another reason that the code needs significant clean-up. Even if > the arrays cannot easily be sorted into e.g. a binary search tree, we could > probably create multiple trees, each of which holds a pointer to an array > element. And with C++ templates, it should be easy to build a generic binary > search tree that will work with ALL of the different data structures that > Xconq supports. I had several reasons for pushing xConq towards C++. One of them was, indeed, the advantage of using pre-built, already-tested templates, such as those provided by STL and Boost. xConq has a number of custom linked list implementations, for example, and it would be nice to replace them with something more standard. (And, in some cases, something other than a linked list -- for performance reasons!) (Another reason for the push towards C++ was simply one of perception. At this date, I think that most people now perceive C code as inferior and as legacy code (even if that is not necessarily the case!) There are some potential developers who are probably turned off by code which does not use "proper" encapsulation, etc....) > Or if IPC is the way to go, I suppose we could off-load all these arrays to an > SQL database, and let some other developers figure out how to optimize it. > But that's an even more radical change than using IPC to talk to a Prolog > interpreter, so I highly doubt we'll go there any time soon. If by IPC, you mean inter-process communication, then I think that it is a very shoddy solution. If an interpreter can't be embedded, I wouldn't want to use it. Topic change: As far as SQL goes, I actually have a strong interest in merging xConq with a SQL-queryable database backend. Not only does one get the advantage of having an efficient B-tree (or somesuch) implementation for data management, but I think it would ease some of the pain involved with searching and filtering objects that we now experience (take the views code in 'side.c', for instance). I've contributed some to the Litesql project (http://litesql.sourceforge.net), because I see it as a potential vehicle for achieving this aim. Litesql effectively seeks to be something akin to Hibernate, but for C++ instead of Java. It can talk to MySQL, PostgreSQL, and SQLite3 backends. I am particularly interested in talking to a SQLite3 backend via LiteSQL, because that could be shipped with the game and would not require a standalone DB server to be run. There is another possibility in the form of QoF (Query Object Framework: http://qof.sourceforge.net), but that is not tightly-coupled to a DB backend. It is also a C-based solution, and so it is not quite as wieldy as dealing with objects as direct actors/agents. >> This kind of layered approach means we need clearly-specified interfaces >> between the parts, and that would probably be a good thing anyway. A >> more precisely-described protocol for the network game would be nice, too. > > Just to be clear: based on what little kernel hacking I have done, I am quite > aware that the Xconq code is a huge mess, with different parts scattered all > over the place. I'm not really sure if it would be better to clean up the > code and then make these kinds of radical changes, or to just throw away the > current code and start over. Well, I've been debating cleanup vs. rewrite for a long time. I've done some exploration as far as rewriting goes, but I've also made actual efforts as far as cleanup and separation of interfaces goes. Last year about this time, I had a few weeks between jobs and felt ambitious enough to actually work on interface separation and full internal documentation. What I was able to get done is in the 'src' and 'cvs_hist' directories in CVS. Unfortunately, I now have neither the time nor the energy to complete this exercise. Given another few weeks and some corresponding ambition, I think I could complete the documentation and interface separation. (As a bonus, xConq would also be fully autotoolized and would have a suite of dynamically-loadable libraries better suited for writing lightweight tools, and for being shared among various GUI frontends.) Of course, there is still plenty of work to do after that. One of the things I would like to pursue is the decoupling of serialization/deserialization from GDL. I would prefer to use a generalized framework such as provided by Boost or Stephen Beal's s11n for performing ser/deser, and then making GDL a particular ser/deser target to use in the framework. One particular advantage to doing things this way is that we could ser/deser across the network with little additional effort, and essentially rid ourselves of much of the nuisance of making special network functions for the transfer of various objects (such as the tasks), as xConq has now. I believe this would address Matthew's concern about the network protocol, a concern which I definitely share. Just some musings, hopes, plans.... Discussion and implementation help are always welcome. Eric |
From: Lincoln P. <sa...@sb...> - 2007-04-05 06:29:41
|
On Wednesday 04 April 2007 05:49, ms...@an... wrote: > Well, then we probably face the issue of having *no* current developers > familiar with the language... I'm not sure how good an idea it is to > choose a language none of us are familiar with and settle on writing > significant amounts of code in it. Fair enough. My point was that if we pick a language that doesn't really fit what we want it to do, it might take more effort to get it to work than it would to learn a new language. > > > The last time I checked, SWI-Prolog was only available for Windows, so > > I'd > > That must have been a while ago; I use it under Linux exclusively, and to > be honest, I'd be more concerned about whether it would *really* be as > compatible with Windows and MacOS as it claims to be. My mistake; I was thinking of Strawberry Prolog. > > I think it would be really nice if we could have the GUI and other code > more closely integrated than what we currently have; it seems like we > spend more effort trying to integrate the TCL with the other stuff, than > we should. For that reason I'm hesitant to say that it's a good idea to > run something in a separate process and interact with it via IPC; there'd > have to be some really compelling benefit. Do you think that having a > full Prolog (or similar) interpreter for game designs would really be such > a benefit? What I'm thinking is that, if possible, we should have a clear layer of abstraction between the GUI and the mechanics of the game. That way, if for some reason Prolog turned out not to fit some game designer's plans, it would be possible to use something else (e.g. a Scheme interpreter) without the same nastiness that switching to Prolog now would take. > I think if we were going to go that route we might be better > off just writing a small, simple interpreter from scratch ourselves and > integrating it tightly - or using an existing open-source interpreter that > can be embedded. I'm aware of Perl, Prolog, Scheme, TCL, and several > other such interpreters that can be used that way. That might be reasonable. > > > I suppose we could consider building some kind of Just-In-Time (JIT) > > compiler, > > Aiee! I don't want to have to write that! But if you, or someone else, > does, great, let's go for it. I don't have time for that, either. But if we're talking about maximizing performance, that's probably the way to go. Eventually. > > > like .NET uses, but I'd leave that for the future. As long as it's > > faster than it is now, I don't think it's worth worrying about now. > > I'm concerned that it might not be. I didn't explain that very well. What I meant was that if *Prolog* would be faster than what we have now, it's currently not worth worrying about speeding up further, e.g. using a JIT compiler. > > > Besides, even without changing GDL, we could probably clean up the kernel > > code and replace all of the linear searches with binary searches. That > > would provide a huge increase in speed. > > My impression is that a lot of stuff is currently stored in unsorted > arrays that can't really be searched except with linear search. I think > significant data structure work would be needed to make the current kernel > signficantly faster. Which is yet another reason that the code needs significant clean-up. Even if the arrays cannot easily be sorted into e.g. a binary search tree, we could probably create multiple trees, each of which holds a pointer to an array element. And with C++ templates, it should be easy to build a generic binary search tree that will work with ALL of the different data structures that Xconq supports. Or if IPC is the way to go, I suppose we could off-load all these arrays to an SQL database, and let some other developers figure out how to optimize it. But that's an even more radical change than using IPC to talk to a Prolog interpreter, so I highly doubt we'll go there any time soon. > > > I see a Prolog(?)-based Xconq as more than just a rewrite of the current > > rules. The real goal is to simplify the rules, so that they gain more > > flexibility. Using Prolog (or something similar) to define game rules is > > simply a means to an end. > > Understood... but that does mean that something of equal power to the > current hardcoded rules would have to be written and debugged in whatever > language we use, whether it's written as part of the kernel/interpreter or > in the new-GDL on top of the kernel/interpreter. Otherwise, the average > non-programming user won't see an advantage to switching. It has to be of GREATER power than the current hardcoded rules. Otherwise there is no incentive for game developers to switch from GDL. > > > I once tried to write a parser in Prolog. It was such a nightmare, I > > finally gave up and wrote it in C++. > > I put off learning Prolog's "definite clause grammar" support for a long > time myself because I was concerned that it would be nightmarish, but I > ended up being forced to use it for a paid-work project about a year ago, > and I think I've conquered the learning curve; I think I can write parsers > in Prolog now without too much fuss. I think I'll leave that to you. > > This kind of layered approach means we need clearly-specified interfaces > between the parts, and that would probably be a good thing anyway. A > more precisely-described protocol for the network game would be nice, too. Just to be clear: based on what little kernel hacking I have done, I am quite aware that the Xconq code is a huge mess, with different parts scattered all over the place. I'm not really sure if it would be better to clean up the code and then make these kinds of radical changes, or to just throw away the current code and start over. I think we need a much better idea of what exactly we'd be doing in Prolog (or another logic-oriented language), and how it differs from what GDL currently allows, before we can make that decision. -- Lincoln Peters <sa...@sb...> Fame lost its appeal for me when I went into a public restroom and an autograph seeker handed me a pen and paper under the stall door. -- Marlo Thomas |
From: <ms...@an...> - 2007-04-04 12:41:55
|
On Tue, 3 Apr 2007, Lincoln Peters wrote: > it's really the best solution. What I would like to see is some form of > logic programming that is more object-oriented, since it would be much easier > to think about the different things in an Xconq game as objects and object Well, then we probably face the issue of having *no* current developers familiar with the language... I'm not sure how good an idea it is to choose a language none of us are familiar with and settle on writing significant amounts of code in it. > The last time I checked, SWI-Prolog was only available for Windows, so I'd That must have been a while ago; I use it under Linux exclusively, and to be honest, I'd be more concerned about whether it would *really* be as compatible with Windows and MacOS as it claims to be. > prefer to avoid it. A more flexible (but possibly more cumbersome) solution > might be to run GNU Prolog in a separate process, and interact with it via > pipes or sockets (kind of like how a typical web application interacts with > an SQL database). I think it would be really nice if we could have the GUI and other code more closely integrated than what we currently have; it seems like we spend more effort trying to integrate the TCL with the other stuff, than we should. For that reason I'm hesitant to say that it's a good idea to run something in a separate process and interact with it via IPC; there'd have to be some really compelling benefit. Do you think that having a full Prolog (or similar) interpreter for game designs would really be such a benefit? I think if we were going to go that route we might be better off just writing a small, simple interpreter from scratch ourselves and integrating it tightly - or using an existing open-source interpreter that can be embedded. I'm aware of Perl, Prolog, Scheme, TCL, and several other such interpreters that can be used that way. > I suppose we could consider building some kind of Just-In-Time (JIT) compiler, Aiee! I don't want to have to write that! But if you, or someone else, does, great, let's go for it. > like .NET uses, but I'd leave that for the future. As long as it's faster > than it is now, I don't think it's worth worrying about now. I'm concerned that it might not be. > Besides, even without changing GDL, we could probably clean up the kernel code > and replace all of the linear searches with binary searches. That would > provide a huge increase in speed. My impression is that a lot of stuff is currently stored in unsorted arrays that can't really be searched except with linear search. I think significant data structure work would be needed to make the current kernel signficantly faster. > I see a Prolog(?)-based Xconq as more than just a rewrite of the current > rules. The real goal is to simplify the rules, so that they gain more > flexibility. Using Prolog (or something similar) to define game rules is > simply a means to an end. Understood... but that does mean that something of equal power to the current hardcoded rules would have to be written and debugged in whatever language we use, whether it's written as part of the kernel/interpreter or in the new-GDL on top of the kernel/interpreter. Otherwise, the average non-programming user won't see an advantage to switching. > I once tried to write a parser in Prolog. It was such a nightmare, I finally > gave up and wrote it in C++. I put off learning Prolog's "definite clause grammar" support for a long time myself because I was concerned that it would be nightmarish, but I ended up being forced to use it for a paid-work project about a year ago, and I think I've conquered the learning curve; I think I can write parsers in Prolog now without too much fuss. > Ideally, you could have two or more databases per game: one defining the game > rules, the other defining the AI behavior. But I don't think you'd want to > write an Xconq AI in Prolog (it's too rigid), so it should be possible for > these databases to have completely different implementations. This kind of layered approach means we need clearly-specified interfaces between the parts, and that would probably be a good thing anyway. A more precisely-described protocol for the network game would be nice, too. -- Matthew Skala ms...@an... Embrace and defend. http://ansuz.sooke.bc.ca/ |
From: Lincoln P. <sa...@sb...> - 2007-04-04 05:45:07
|
On Tuesday 03 April 2007 07:05, ms...@an... wrote: > Re-doing the whole works in Prolog would be interesting. Perhaps, but that's not quite what I had in mind. > I have a fair > bit of experience with Prolog and I think most of the kernel would be easy > to implement that way. It also would be really easy (maybe one weekend's > work to get the basics) to read the current GDL format as Prolog facts. > Despite the original claim that it's LISP-based, the things we do in > GDL are already very much like Prolog code anyway. Hence my original suggestion. I should mention that, although Prolog is the only logic programming language I know (I used it for a class), I'm not sure it's really the best solution. What I would like to see is some form of logic programming that is more object-oriented, since it would be much easier to think about the different things in an Xconq game as objects and object types. A quick Google search turns up several object-oriented Prolog variants, but they're all probably too obscure. I think the most complex thing I ever wrote in Prolog that actually worked was a genetics solver, which I used occasionally in a biology class. And it wasn't a very complicated program. > > However, I think the GUI would be a problem. There's a lot of weird stuff > in the current TCL/TK GUI - in particular, drawing the map is handled by a > complicated piece of code that I don't think any current developer really > understands. That's why the "connections and borders don't display at > maximum magnification" bug has gone unfixed for so long, for instance - > it's somewhere in that mysterious display code. Although current > SWI-Prolog, which is what I'd use, comes with a sophisticated > cross-platform GUI toolkit, I think it would be a lot of work to get a > working GUI for the game out of it. The last time I checked, SWI-Prolog was only available for Windows, so I'd prefer to avoid it. A more flexible (but possibly more cumbersome) solution might be to run GNU Prolog in a separate process, and interact with it via pipes or sockets (kind of like how a typical web application interacts with an SQL database). > On the other hand, the current GUI is > only marginally acceptable, and does need to be rewritten one way or > another. Another significant issue might be speed. Some of the logic > we're doing would actually go faster if we did it in Prolog because we > could, for instance, benefit from behind-the-scenes hash lookups in tasks > that we're currently solving by linear search. But the language as a > whole, being interpreted, is likely to take its toll on overall speed. I suppose we could consider building some kind of Just-In-Time (JIT) compiler, like .NET uses, but I'd leave that for the future. As long as it's faster than it is now, I don't think it's worth worrying about now. Besides, even without changing GDL, we could probably clean up the kernel code and replace all of the linear searches with binary searches. That would provide a huge increase in speed. > > There's also the general issue that it's harder to find developers who > know exotic languages; C++ has a much bigger base of potential volunteers. > And we'd be spending a lot of time reimplementing basics that could have > gone to new features in the existing framework. That would have to be > balanced against the idea that a better framework would eventually mean > that new features would be easier to add. The way I see it, Xconq has the advantage that you can specify a game in terms of how it should work, rather than how to make it work that way (as you would have to do in C++). Logic programming is built on the same idea, so it seems like a good fit, even if you DO have to learn a new language to use it. > > I think that it might be better to think of a Prolog- (or other language) > based XConq-like game as a separate project rather than as part of XConq. > Would you be willing/able to work on such a project? Would others on this > list? It does sound pretty interesting to me, and I think I have the > skills, but I wouldn't have enough time to do it alone. And I wonder how > much bang for the buck it would provide, in terms of being helpful to > users. I see a Prolog(?)-based Xconq as more than just a rewrite of the current rules. The real goal is to simplify the rules, so that they gain more flexibility. Using Prolog (or something similar) to define game rules is simply a means to an end. If it were to go where I envision it going, the current GDL-based Xconq would become little more than a historical curiosity. > > If we went ahead with it, I think the first three steps I'd suggest would > be: > > - code to load GDL files (which implies some data-structure work; easy) I once tried to write a parser in Prolog. It was such a nightmare, I finally gave up and wrote it in C++. Since the Prolog idea (in my view) is really just a way to improve the tools available to Xconq game developers, I think that if we're going to go this far, we shouldn't limit ourselves to a single obscure language that's really good at some things but awkward at other things. In fact, I could imagine that doing so might eventually lead to a similar problem to the one we have now. In fact, as I think about it, we could probably achieve enormous flexibility if Xconq were reworked to use a layered architecture like this: * User interface * Game state * Database driver * Rules database Note that when I say database, I'm not necessarily referring to an SQL-based system (I've heard Prolog described as a form of database). Ideally, you could have two or more databases per game: one defining the game rules, the other defining the AI behavior. But I don't think you'd want to write an Xconq AI in Prolog (it's too rigid), so it should be possible for these databases to have completely different implementations. As a side note, I recently built an artificial neural network that plays Othello (a.k.a. Reversi). It's interesting from a technical standpoint (and it could easily be adapted to almost any board game), but it never played very well (it contained only the most rudimentary of pattern-recognition abilities). It might be possible to build a learning Xconq AI using a similar idea, but the time-space complexity is very high, and would require a significant amount of optimization (I used MySQL to store all the data points). > - code to display a (fully defined) map read from GDL files (implies > having a map-display widget; hard) I think I'd rather code the GUI in C++ using e.g. SDL and use the pipe/socket trick I mentioned earlier to talk to a Prolog interpreter. At least then we can be sure it's cross-platform. > - code to do random map generation (testbed for other "kernel" stuff; > medium) Unless you know an easy way to do this in Prolog, I'd rather do it in C++, simply because I'm much more familiar with C++. -- Lincoln Peters <sa...@sb...> BOFH excuse #332: suboptimal routing experience |
From: <ms...@an...> - 2007-04-03 13:57:54
|
On Sun, 1 Apr 2007, Lincoln Peters wrote: > The way I envision it right now is to transform GDL into a Turing-complete, > logic-oriented language (like Prolog or Haskell), which would essentially > allow a game designer to write a game by specifying types and the > relationships between them. Ideally, higher-level functionality (such as AI > rules) or more specialized functionality (such as the tables you describe) > could be defined as "include" files, in much the same way that in C++, you > can include <string> or <list> to gain access to pre-built string and linked- > list objects, respectively. Most importantly, this functionality could be > defined purely in GDL, without having to modify the Xconq kernel (unless you > wanted to optimize for certain behaviors, or something like that). Re-doing the whole works in Prolog would be interesting. I have a fair bit of experience with Prolog and I think most of the kernel would be easy to implement that way. It also would be really easy (maybe one weekend's work to get the basics) to read the current GDL format as Prolog facts. Despite the original claim that it's LISP-based, the things we do in GDL are already very much like Prolog code anyway. However, I think the GUI would be a problem. There's a lot of weird stuff in the current TCL/TK GUI - in particular, drawing the map is handled by a complicated piece of code that I don't think any current developer really understands. That's why the "connections and borders don't display at maximum magnification" bug has gone unfixed for so long, for instance - it's somewhere in that mysterious display code. Although current SWI-Prolog, which is what I'd use, comes with a sophisticated cross-platform GUI toolkit, I think it would be a lot of work to get a working GUI for the game out of it. On the other hand, the current GUI is only marginally acceptable, and does need to be rewritten one way or another. Another significant issue might be speed. Some of the logic we're doing would actually go faster if we did it in Prolog because we could, for instance, benefit from behind-the-scenes hash lookups in tasks that we're currently solving by linear search. But the language as a whole, being interpreted, is likely to take its toll on overall speed. There's also the general issue that it's harder to find developers who know exotic languages; C++ has a much bigger base of potential volunteers. And we'd be spending a lot of time reimplementing basics that could have gone to new features in the existing framework. That would have to be balanced against the idea that a better framework would eventually mean that new features would be easier to add. I think that it might be better to think of a Prolog- (or other language) based XConq-like game as a separate project rather than as part of XConq. Would you be willing/able to work on such a project? Would others on this list? It does sound pretty interesting to me, and I think I have the skills, but I wouldn't have enough time to do it alone. And I wonder how much bang for the buck it would provide, in terms of being helpful to users. If we went ahead with it, I think the first three steps I'd suggest would be: - code to load GDL files (which implies some data-structure work; easy) - code to display a (fully defined) map read from GDL files (implies having a map-display widget; hard) - code to do random map generation (testbed for other "kernel" stuff; medium) -- Matthew Skala ms...@an... Embrace and defend. http://ansuz.sooke.bc.ca/ |
From: Lincoln P. <sa...@sb...> - 2007-04-03 05:24:47
|
On Sunday 01 April 2007 01:38, Brian Dunn wrote: > Sometimes I wonder if the decision making logic could be redone much more > simply with some fuzzy logic rules. I'm not an expert on fuzzy logic, but based on what I do know, I think fuzzy logic rules would be appropriate for AI programming, but not for defining the rules of the game. But I wouldn't necessarily try to stop a game designer from using fuzzy logic outside of AI programming, since there are always ways to use tools that the creators of those tools never expected (I know I surprised some of the previous Xconq developers with my ideas on several occasions!). If I'm lucky, I'll have some time to work on Xconq starting in June. -- Lincoln Peters <sa...@sb...> Remember: use logout to logout. |
From: Brian D. <bf...@sb...> - 2007-04-01 08:37:24
|
> Perhaps what we > need to do is come up with a much simpler but highly flexible set of rules, > from which all of Xconq's current capabilities can be produced. Sometimes I wonder if the decision making logic could be redone much more simply with some fuzzy logic rules. Brian |
From: Lincoln P. <sa...@sb...> - 2007-04-01 07:17:52
|
I meant to post this over a week ago, but I've been having electrical problems at home that prevented my computer from running reliably. On Thursday 22 March 2007 08:43, Massimo Campostrini wrote: > Some proposals: > * adjacent-terrain-dislikes t1 t2 -> n > * material-lost-in-movement u m -> n > * border-blocks-connection t1 t2 -> t/f > * capture-attack-terrain-effect u1 t -> n% > * capture-defend-terrain-effect u2 t -> n% > * can-be-ferried-over u2 t1 -> t/f > * can-ferry-over u1 t1 -> t/f I have to say: I have not been involved in development of the Xconq kernel itself except on a few extremely rare occasions, but I've been doing a lot of work lately to improve my programming skills, and I'm starting to wonder if having all these tables for different interactions, all of which require support to be written into the kernel, is a losing battle. Perhaps what we need to do is come up with a much simpler but highly flexible set of rules, from which all of Xconq's current capabilities can be produced. The way I envision it right now is to transform GDL into a Turing-complete, logic-oriented language (like Prolog or Haskell), which would essentially allow a game designer to write a game by specifying types and the relationships between them. Ideally, higher-level functionality (such as AI rules) or more specialized functionality (such as the tables you describe) could be defined as "include" files, in much the same way that in C++, you can include <string> or <list> to gain access to pre-built string and linked- list objects, respectively. Most importantly, this functionality could be defined purely in GDL, without having to modify the Xconq kernel (unless you wanted to optimize for certain behaviors, or something like that). I don't have time at the moment (and I don't have a clear idea of how this would work on a technical level), but if I can find time in the next few months, I'm willing to get involved in Xconq again. -- Lincoln Peters <sa...@sb...> It's a small world, but I wouldn't want to have to paint it. -- Steven Wright |
From: Massimo C. <Mas...@df...> - 2007-03-30 16:28:25
|
I posted to the patch tracker the results of my hacking on xconq. I was lucky to have time to dedicate to it, but I don't know when it will happen again... The most interesting thing is the implementation of path finding; path finding itself is clean, but the interface to the game is deep inside the mess of task.c... I spent some time debugging it, and it seems to work nicely. It needs testing for networked games, I guess. I posted a tar.gz file, including a set of patches, a new task.c, 3 new code files, and a README. Best regards, Massimo Campostrini |
From: <ms...@an...> - 2007-03-24 21:42:52
|
On Thu, 22 Mar 2007, Massimo Campostrini wrote: > I am designing a World War I game, including of course trenches and > barbed wire. After some experimenting, I decided to use terrains for > them, a coating for trenches and a border for barbed wire. Coatings haven't been tested very much, so it won't surprise me if you find a lot of bugs related to them. Reports and fixes would be welcome. > implementing border/connection - cell compatibility using a single table > * adjacent-terrain-dislikes t1 t2 -> n > it is possible to add a connection or border terrain tx > between cell terrain t1 and cell terrain t1 if > adjacent-terrain-dislikes(tx,t1)+adjacent-terrain-dislikes(tx,t2) < 100 As you probably know (based on the names) there's a series of adjacent-terrain tables already, and there's a statement in the manual "Incompatible types may not be juxtaposed, either at game setup time or by unit action during a game."; but at the moment, those tables don't seem to have any effect except during setup. So it makes sense that there should be tables in that series that will affect unit terrain-modification. I wonder if the table you describe could be extended to also cover compatibility between different border and connection types. Here's what I'd propose: * call it "terrain-compatibility" to express that it covers more than just cell terrain disliking border/connection terrain * when you try to add a connection or border, it checks the new type against both adjacent cells and all existing connection or border types on that edge * if the sum is more than 100, fail. That way you can set (road (sea shallows plains) (100 90 0)) and get roads that go into the shallows for one cell but not into the sea, as in your example; but you can also set (road trench 100) and get no possiblity of making a road over a trench; and you can combine the two so that a border or connection makes it harder, but not impossible, to build another border or connection. Thought: would there ever be cases where you'd want compatibility in the other direction - like "you can't build a road unless there's already a bridge" so that the bridge *allows* instead of *forbidding* the road? That might be possible by the use of negative numbers in the terrain-compatibility table. Also, although this isn't an issue you brought up: it seems like maybe the adjacent-terrain-effect table should take effect when a unit changes a cell terrain type. Probably just by being applied immediately, like wrecking. The terrain-compatibility table as described will also have a lot of unused entries relating to cell-cell interactions; I wonder if it would make sense to try to apply it to determining where units can or cannot change cell types. (For instance, allow changing cell type only if the sum of all the entries crossing the new type with the six it would be adjacent to, is zero.) There's a lot to be said for having the map-generation stuff defined by one table and the unit-action stuff by a different table. > A worker would need 5 turns to add a road from plains/desert to > anything and 10 turns from forest/mountains to anything. The problem > is that a worker can stockpile concrete before (or while) moving to > the construction place. A simple solution would be a mechanism to Another option would be to make the consumption-per-move table behave that way - movement will consume material if available, but lack of material doesn't block movement. The "lack of material blocks movement" effect could then come from the material-to-move table. I don't particularly advocate that, though, because it would probably break a lot of existing games, the AI, and other code. If it comes to that it would probably be better to just add another table as you describe, though I'm not happy with even the existing two "material for movement" tables - I've already spent a lot of time and annoyance trying to debug games that were using one when they wanted the other, and a third seems likely to make it even more complicated. I wonder if this issue could be resolved instead by using the (cell) terrain to store the material. You can allow the terrain to store concrete, and not allow the unit to store concrete. When the unit is sitting in terrain, it'll manufacture concrete which goes into the terrain; when it tries to build a road, it should (if not, this is probably a bug) draw the concrete from the terrain, having no concrete storage of its own. That would have a side effect of concrete remaining in the cell if the engineers are called away, to be potentially used by other engineers (maybe even enemy engineers!) who try to build in the same spot. You could make the unused concrete evaporate by making the terrain consume it (then the engineers, when present, would produce it fast enough to overcome the consumption); but it might even be more realistic that if one group of engineers starts preparing a site to build roads, another could come along and finish the job. This general issue is one I've struggled with in other games; the basic issue is that terrain alteration should usually be a very time-consuming operation compared to stuff like movement, so it's hard to model in a game where the terrain alteration has to eventually be considered to happen on some specific turn; you have to give the engineers something to do to take up their time as the terrain alteration nears completion. Something I've tried, though it's less elegant from a user interface perspective, is to have the engineers build a "road" unit, which cannot move, and once built, the "road" unit actually builds the road, destroying itself by material exhaustion in the process. There's a lot of support for stuff like "tooling" which can be used to handle the time delay. > It could be possible for borders to block connections: > * border-blocks-connection t1 t2 -> t/f > if t, units are charged their mp-to-traverse border t1 > even if they are on connection t2 > (this should be displayed graphically by drawing > border over connection / connection over border) In such a case, should the connection be allowed at all? I think there is already some official order of drawing terrain types (probably earliest defined type has lower priority). As far as I know, there isn't any really well-defined rule for what happens when there are two or more connection/border types applicable. Would it make sense to simply have the rule be "the highest-priority one is the one that applies" and clarify the rule that determines which one is highest priority? > A cell/border terrain could affect capture on/across it: > * capture-attack-terrain-effect u1 t -> n% > * capture-defend-terrain-effect u2 t -> n% I like this idea. Should it be the attacker's terrain, the defender's terrain, or each their own terrain? > perhaps, if t1 and t2 are connected by ty, factor in tx effects only > if border-blocks-connection(tx,ty) is t. At the moment, movement seems to use whichever route allows the mover to get there in fewest points, assuming they're allowed to use it. I'd be inclined to think that combat, both attack and capture, should follow the same rule as movement - use whichever terrain maximises the chance of success, subject to the attacker being allowed to use that route. > (BTW, attack-terrain-effect and friends could also factor in > border effects.) Yes, they should. And connection effects, too. If possible, they should also be able to handle *increasing* the chance of success - much easier to fight an enemy on the other side of the river if there's a bridge in between. > Finally, ferry could have a per-terrain component, e.g., > * can-be-ferried-over u2 t1 -> t/f > if f, u2 entering/leaving a transport u1 in cell terrain t1 is not > ferried over the cell even if ferry-on-entry/departure would allow it, > likewise for ferrying over a border tx. > For sake of completness, we could also have > * can-ferry-over u1 t1 -> t/f > ferrying is done only if all three of > ferry, can-be-ferried-over, and can-ferry-over allow it. This seems very similar to the existing ferry-on-entry and ferry-on-departure tables, which don't allow you to specify individual terrain types but do allow you to specify whether borders in general should be ferried over. Is there a case where those tables aren't adequate and you need to specify different settings for different border types? -- Matthew Skala ms...@an... Embrace and defend. http://ansuz.sooke.bc.ca/ |
From: SourceForge.net <no...@so...> - 2007-03-23 11:28:30
|
Bugs item #1686661, was opened at 2007-03-23 11:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=698372&aid=1686661&group_id=124062 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Game Engine: General Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Massimo Campostrini (campo) Assigned to: Nobody/Anonymous (nobody) Summary: mp-to-enter-unit 0 not implemented correctly Initial Comment: mp-to-enter-unit 0 is not implemented correctly: units are charged at least 1 mp to enter a transport E.g., in the standard game, an armor uses 2 mps to enter a nearby town, instead of 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=698372&aid=1686661&group_id=124062 |
From: Massimo C. <Mas...@df...> - 2007-03-22 16:12:02
|
Eric McDonald <mcd...@ph...> writes: > Hi Massimo, > > > How should I proceed? Can I post patches and bug reports to this > > list? > > Sure. And, if you have a SourceForge user account, I will add you to > the list of xConq developers and give you CVS access, if you > wish. There is also a Patches tracker on the project site, and you can > submit patches there, if you want. I submitted my patches (vs. xconq-7.5.0-0pre.0.20050612) to the patch tracker. Tomorrow (hopefully) I'll post some bug reports. I don't know about CVS access: I don't think I'll have much time to work on xconq and I plan to use it to update my old games and develop another one or two. Regards, Massimo |
From: Massimo C. <Mas...@df...> - 2007-03-22 15:43:20
|
ms...@an... writes: > On Tue, 20 Mar 2007, Eric McDonald wrote: > > (You may want to discuss connection/border things with Matthew Skala, > > since he did some work with them a while back, IIRC.) > > Yes. It's been a while since I looked at that, but I'd certainly be > interested to hear what you have in mind. It's possible that some of it > may already be covered by existing tables and just not documented - I know > I added a couple of tables already dealing with what kinds of terrain can > and cannot appear together, though I'd probably have to go back and look > at the changelogs to figure out what I actually did. I am designing a World War I game, including of course trenches and barbed wire. After some experimenting, I decided to use terrains for them, a coating for trenches and a border for barbed wire. Trenches work pretty well: setting coating-depth-min to 0 you prevent digging trenches in sea, swamp and ice; combat and movement effects are modeled by defend-terrain-effect, fire-defend-terrain-effect, mp-to-enter-terrain, and mp-to-leave-terrain. I would like to have barbed wire as an impassable barrier which has to be removed before it can be crossed, but I have problems: there is no naturay way to prevent adding barbed wire in unwanted terrain (like sea), it doesn't interrupt roads, cities will ferry over barbed wire (or they will not ferry over rivers, there is no terrain-dependant ferry-on-xxx table). I am also experimenting with road construction. With some material trick we can restrict the cell terrain where the builder sits, but not the cell terrain where the new road will end. Multi-turn road construction is also not easy to achieve. Some proposals: implementing border/connection - cell compatibility using a single table * adjacent-terrain-dislikes t1 t2 -> n it is possible to add a connection or border terrain tx between cell terrain t1 and cell terrain t1 if adjacent-terrain-dislikes(tx,t1)+adjacent-terrain-dislikes(tx,t2) < 100 example: (table adjacent-terrain-dislikes (road (sea shallows swamp desert plains forest mountains ice) (100 90 50 0 0 0 0 90))) would allow to build stretches of roads of length 1 through shallows (bridges) and ice (tunnels) but not through sea. Using material-to-add-terrain / consumption-per-add-terrain to slow down add-terrain, with a "counter" material which must be accumulated slowly before the add-terrain action is possible, is "almost" working: (material-type concrete) (unit-type worker) (table material-to-add-terrain (worker concrete 10)) (table consumption-per-add-terrain (road concrete 10)) (table unit-storage-x (worker concrete 10)) (table base-production (worker concrete 2)) (table productivity (worker (sea shallows swamp desert plains forest mountains ice) ( 0 0 0 100 100 50 50 0))) (table in-length (worker concrete -1)) ; don't get concrete from other units A worker would need 5 turns to add a road from plains/desert to anything and 10 turns from forest/mountains to anything. The problem is that a worker can stockpile concrete before (or while) moving to the construction place. A simple solution would be a mechanism to burn a material when either a unit or its transport moves; base-consumption + consumption-as-occupant is not quite right, because I would like to accumulate a material while sitting in a standing transport (building a road starting from a city); consumption-per-move is not right either, because movement should be possible even without this material. I propose * material-lost-in-movement u m -> n (amount of material lost if either the unit or its transport moves, movement is possible even without the material) (table material-lost-in-movement (worker concrete 10)) It could be possible for borders to block connections: * border-blocks-connection t1 t2 -> t/f if t, units are charged their mp-to-traverse border t1 even if they are on connection t2 (this should be displayed graphically by drawing border over connection / connection over border) A cell/border terrain could affect capture on/across it: * capture-attack-terrain-effect u1 t -> n% * capture-defend-terrain-effect u2 t -> n% If u1 on cell t1 tries to capture u2 on cell t2 across a border tx, capture-attack-terrain-effect(u1,t1)*capture-attack-terrain-effect(u1,tx)* capture-defend-terrain-effect(u2,t2)*capture-defend-terrain-effect(u2,tx) are factored in the capture chance; perhaps, if t1 and t2 are connected by ty, factor in tx effects only if border-blocks-connection(tx,ty) is t. (BTW, attack-terrain-effect and friends could also factor in border effects.) Finally, ferry could have a per-terrain component, e.g., * can-be-ferried-over u2 t1 -> t/f if f, u2 entering/leaving a transport u1 in cell terrain t1 is not ferried over the cell even if ferry-on-entry/departure would allow it, likewise for ferrying over a border tx. For sake of completness, we could also have * can-ferry-over u1 t1 -> t/f ferrying is done only if all three of ferry, can-be-ferried-over, and can-ferry-over allow it. I hope I explained this well enough... Ciao, Massimo Campostrini |
From: <ms...@an...> - 2007-03-20 21:19:51
|
On Tue, 20 Mar 2007, Eric McDonald wrote: > (You may want to discuss connection/border things with Matthew Skala, > since he did some work with them a while back, IIRC.) Yes. It's been a while since I looked at that, but I'd certainly be interested to hear what you have in mind. It's possible that some of it may already be covered by existing tables and just not documented - I know I added a couple of tables already dealing with what kinds of terrain can and cannot appear together, though I'd probably have to go back and look at the changelogs to figure out what I actually did. -- Matthew Skala ms...@an... Embrace and defend. http://ansuz.sooke.bc.ca/ |
From: Eric M. <mcd...@ph...> - 2007-03-20 16:50:58
|
Hi Massimo, Massimo Campostrini wrote: > Hi there! This seems to be the first non-spam post of the year > to this list ;-) Wouldn't surprise me.... > I used to work on xconq development, quite a few years ago... I recognize your name. Welcome back! > How should I proceed? Can I post patches and bug reports to this > list? Sure. And, if you have a SourceForge user account, I will add you to the list of xConq developers and give you CVS access, if you wish. There is also a Patches tracker on the project site, and you can submit patches there, if you want. > My game could benefit a couple of additional GDL tables defining > cell/connection and cell/border compatibility; is GDL for 7.5 > already frozen or "simple" additions can still be considered? Nothing is frozen, except the hackers. ;-) No one (myself included) seems to have any interest in working on xConq ATM. (You may want to discuss connection/border things with Matthew Skala, since he did some work with them a while back, IIRC.) Best Regards, Eric |
From: Massimo C. <Mas...@df...> - 2007-03-20 15:04:40
|
Hi there! This seems to be the first non-spam post of the year to this list ;-) I used to work on xconq development, quite a few years ago... Lately I found some time to play with xconq-7.5.0-0pre.0.20050612. I am developing a game (if you are curious, it's a World War I game) involving (auxiliary) terrain manipulation, which triggered a few (unreported?) bugs and misfeatures, some of which I managed to fix. How should I proceed? Can I post patches and bug reports to this list? My game could benefit a couple of additional GDL tables defining cell/connection and cell/border compatibility; is GDL for 7.5 already frozen or "simple" additions can still be considered? Best regards, Massimo Campostrini |
From: Tracie E. <ju...@m8...> - 2007-02-25 13:51:52
|
Hi, Chaepest CALIS and VAGRA online. http://parkerokay+now.com Remove "+" from the link. to Sirius, telling him that nothing out of the ordinary had happened, and that they were still waiting for an answer from Percy. Hedwig didnt return until the end of the Easter holidays. Percys |