https://sourceforge.net/p/xconq/feature-requests/Recent changes to feature-requestsenFri, 23 Mar 2007 15:37:29 -0000https://sourceforge.net/p/xconq/feature-requests/148/Currently, when a human player orders a unit to add/remove\_terrain, if the unit has insufficient acp or material, the action fails silently \(at least with the tcltk interface undel linux\). Ideally, a set of move/resupply/rest tasks should be set for the unit so that the action can be completed. Less ideally, the player should be notified that the action is not performed and why. Massimo CampostriniFri, 23 Mar 2007 15:37:29 -0000https://sourceforge.netab89ef61e588793191a5b9a58f57fe78b0fe16a8https://sourceforge.net/p/xconq/feature-requests/147/An offset connection is basically a cross between a border and a connection. It can impede movement like a border, and it can make movement easier like a connection. The basic idea is that the connection runs through a cell, but stays close to the edge \(let's say it's about halfway between the center of the cell and the edge\). A unit that can travel along it \(as per mp-to-traverse\) is assumed to be on it, while any other unit is assumed to be at the center of the cell. Thus, it may impede movement in a given direction for some units \(like a border\) and enhance movement for others \(like a connection\). The application I have in mind for offset connections is rivers in a low-level tactical game. By using an offset connection, land units can require extra effort to cross a river \(if they can cross it at all\), while naval units can use it to travel inland.Lincoln PetersWed, 05 Jul 2006 21:33:27 -0000https://sourceforge.net028032ca3315c937e37b3c43bf079504b074b2cahttps://sourceforge.net/p/xconq/feature-requests/146/As an added option allow for a Tactical Combat Screen. When non-allied unit stacks enter the same HEX take all units in that HEX and any adjacent HEX and move them to a Tactical Combat Screen. Allow them to move / fight here. \(See Master of Magic or Age of Wonders for an example\).SammualWed, 12 Apr 2006 19:50:51 -0000https://sourceforge.nete048c765fe34a832d7843111b5a6a2e3ce30ee76https://sourceforge.net/p/xconq/feature-requests/145/It will be possible to have a linux ppc port in the future?AnonymousThu, 17 Nov 2005 00:19:30 -0000https://sourceforge.net165c5e98563cb1d0cff6e0a95a645a4b122096c6https://sourceforge.net/p/xconq/feature-requests/144/The "design mode" dialog box in the Tcl/Tk interface has a prominently positioned button marked "Done". It's tempting to press this button to confirm some operation - for instance, after typing in a new feature name - because it looks like an "OK" button that would be used for that purpose. The "Done" button also has default input focus, so pressing "Enter" in the dialog box will trigger it. Type something into an entry field and hit "enter", and the button will be triggered. It is thus very easy to trigger the button by mistake. When pressed, it dumps you out of design mode completely. You can get back by choosing "design" again from the menu, but whatever you were typing at the time, as well as settings like which type of terrain you were painting with the paint terrain command, will be lost. Exiting design mode \(while remaining in Xconq\) isn't even something you'd want to do in normal operation at all - normally, once you go into design mode, you want to stay that way permanently until you exit the program entirely. It's relatively rare that someone would want to go into design mode temporarily and then play the game afterward. Different users will have different usage patterns, of course, but I figure I accidentally exit design mode at least five times for every time I deliberately exit the program while in design mode, and I think I've only ever once or twice wanted to exit design mode without exiting the program. So it shouldn't be so easy to do something that you almost never want to do and is annoying if you do it accidentally. Entering design mode requires going through the menu. The menu command to enter design mode is already a toggle with check box indicator; you can exit the mode by selecting it a second time. That makes sense and is hard to do by accident. I think the interface would be pleasanter to use if the "Done" button were simply deleted entirely from the design dialog box, and this function left to the menu item. I can probably do this myself - mentioning it here to see if anyone else has an opinion. Matthew SkalaSat, 13 Aug 2005 03:09:29 -0000https://sourceforge.net33ede438744f7af960ddc38fb5eaa2a9fa8dae53https://sourceforge.net/p/xconq/feature-requests/143/There's some room for debate as to what's the correct behaviour here, which is why I'm filing this as an RFE instead of a bug, but: If I click on an enemy unit to attack it, the UI code will make a capture attempt if capture is possible at all; and a capture attempt means no attack attempt occurs. On the other hand, if I explicitly request an attack \(not capture\) I get the capture attempt afterwards anyway, and for free with no ACP cost. When capture is available as a choice, then attack will only be availabe if explicitly requested. If \(as is the case in one game I'm working on\) the chance of success with an attack is high, but the chance of success with a capture is low, then just clicking around on the map means I'll be wasting my effort in seldom-successful capture attempts. I'd rather have the default when I click be "attack", and do an explicit capture command when I want to attempt a capture without doing damage. That seems more intuitive and useful. It might be possible to simulate in the GDL by using the "surrender" mechanism rather than the "capture" mechanism, but that may have different semantics, it means capture as a separate action without attack is no longer possible, and I don't know whether it would connect with the changed-type-if-captured table. I think the simplest way to make this change would be to move the capture logic that starts around like 3336 of ui.c, to after the regular-attack logic, but I haven't tested that carefully. Matthew SkalaThu, 11 Aug 2005 13:42:52 -0000https://sourceforge.net256323603f970e6fb08a4825222d911e584059dbhttps://sourceforge.net/p/xconq/feature-requests/142/If a unit type image has subimages created with the \(x\) form in the IMF then it'd be nice for the "multiple images per unit type" code to pick that up and use them as alternatives, instead of the designer having to describe each alternative as a separate IMF and list them in the unit's image-name property. At present, a unit type IMF with subimages will lead to incorrect behaviour \(I get large black squares in the Tcl/Tk interface at the highest magnification\), but I'm not flagging that as a bug because it's not documented as something that should be possible anyway. I did expect it to work, though. Matthew SkalaSun, 07 Aug 2005 12:45:19 -0000https://sourceforge.net1327f1ccd8b090cdf3701d98715f50b35daa2acbhttps://sourceforge.net/p/xconq/feature-requests/141/As well as occupant-multiplies damage, this seems like a natural addition. If the table itself honored dice specs, it would open the door to weapons. It would also open the door to an alternate attribute system, as such: \(table occupant-adds-damage \(Low-Strength u\* -2\) \(High-Strength u\* 3\) \(Giant-Strength u\* 6\) \(Titan-Strength u\* 10\) \(Demigod-Strength u\* 15\) \) Or somesuch. It would need to be cumulative, which raises issues with a unit having multiple weapons, but there are easy workarounds regarding this problem using capacity.Elijah MeeksWed, 03 Aug 2005 01:34:23 -0000https://sourceforge.net27f6ca3f88af27c2874dc07613fdc20fae9ee79ahttps://sourceforge.net/p/xconq/feature-requests/140/This table would charge a unit the movement cost charged to that unit's occupant for various terrain. This is most obviously an item or system unit implementation, so that special sails, mountain-climbing or desert-survival gear would change a unit's ability to move in and out of terrain. If set to true, then the cost for u1 to enter any terrain would be the cost of u2 to enter that terrain. This is a cumbersome approach, with immediately obvious issues \(What if I have a unit equipped with Desert survival AND mountaineering gear, where can it go?\). However, though I doubt any implementation would resemble the request here, I think there's some way to have this feature and that it is a useful feature.Elijah MeeksWed, 03 Aug 2005 01:28:53 -0000https://sourceforge.netac65ab36fa68b86a1d528f823f92e2682de77b89https://sourceforge.net/p/xconq/feature-requests/139/At some point I'd like to have a library of games that demonstrate how to work the various features within XConq. What I envision is a simple base game with a handful of units, followed by various modifications to the game for the various groups of features, such as: An occupant game showing how to set protection, ferry-entry/exit, occupant combat/modifiers, et cetera. A change-type game, demonstrating CxP, occupants-to-change-type, manual, et cetera. An advanced unit game, showing how to set terrain value, growth and all that. And so on and so forth. Now, I know that various games demonstrate this functionality, but specifically built tutorials, with decent commenting, would be a better starting point for designers new to the engine.Elijah MeeksSun, 17 Jul 2005 18:00:17 -0000https://sourceforge.net3a3f8a91a287bfd20a38945b0543ab2e004b8196