|
From: SourceForge.net <no...@so...> - 2005-08-06 19:13:32
|
Feature Requests item #1252895, was opened at 2005-08-06 00:53 Message generated for change (Comment added) made by eric_mcdonald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1252895&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: pre-7.5 CVS / prerelease Status: Open Resolution: None Priority: 5 Submitted By: Matthew Skala (matthewskala) Assigned to: Nobody/Anonymous (nobody) Summary: Can't create starving unit Initial Comment: This is an odd one: it appears that you can't create a unit (by ACP-independent or ACP-consuming construction, it doesn't matter) if the newly created unit would be in a state of starvation. It is possible that it's actually the "completion" action, not "creation", that's the problem. I noticed it on units which ought to be completed in a single action. Attached game file demonstrates it. Attempt to create a second army, and your turn ends without a new one being created. Try again, and the game will run out of control. Looks like it may be a plan-related issue, since the creating unit seems to become "busy" in some way (thus the turn ending). If you comment out the last time (the one that causes starvation), everything works fine. Another guess would be that maybe somehow the "starvation check" code is being run before the unit's HP are set, but I haven't been able to catch that actually happening in the debugger. I know this worked circa March 2005, which is the last time I looked at my XcCity game; it seems to have been broken by some update between then and now. ---------------------------------------------------------------------- >Comment By: Eric McDonald (eric_mcdonald) Date: 2005-08-06 19:13 Message: Logged In: YES user_id=1158352 What you say may certainly be true as far as additional problems regarding units under construction, and I will look into them. But, in the course of testing my patch to address improvement (2) in my previous reply on this thread, my analysis was shown to be correct. The supply alarm was in the set state, which resulted in the clearing of the task agenda and the resetting of the supply alarm. The patch that I am about to check in will notify the player's side whenever the task agenda is cleared due to low supply. You will be able to see the notification if you try to create an army in your test case, as well as when you try moving an aircraft too far in the Default game. ---------------------------------------------------------------------- Comment By: Matthew Skala (matthewskala) Date: 2005-08-06 18:48 Message: Logged In: YES user_id=1167698 That explanation seems applicable to the case where a starving unit is creating another starving unit, but (although my first example game file is a situation where both units are starving) the problem seems to be based on whether the unit *under construction* is starving, not whether the unit *doing the construction* is starving. I get the same problem when a non-starving unit is creating a starving unit, and I don't get it when a starving unit is creating a non-starving unit. See attached game file. Armor doesn't starve, armies do. Both of them can create armor, and neither of them can create armies. I don't get why the starvation status of the under-construction unit should affect the planning for the constructing unit, but if it does, I wonder if it would be possible to code a work-around to override this behaviour when the constructing unit is one that can never move - or even whenever the task in question is a non-movement task. I agree that there are problems with the current low-supply behaviour, but I'd think the current behaviour only even sort of makes sense when it's dealing with fuel-based movement. Another possible workaround which I may be able to implement on the GDL level, and will investigate, would be changing the supply levels so that these units never go low-supply even when they are starving. I don't approve (and I imagine you don't either) of making the low-supply levels hard determiners of what actions are possible at all, but in the particular instance I think I could get away with setting them to zero or less without breaking other things. ---------------------------------------------------------------------- Comment By: Eric McDonald (eric_mcdonald) Date: 2005-08-06 18:21 Message: Logged In: YES user_id=1158352 The passive plan (which is responsible for executing tasks that the player has set), checks to see if supply is low. If an unit is not already headed for resupply, and the supply alarm is in the set state, then the supply alarm is unset and the task agenda is cleared. This wipes out the construction task the first time. Now, the second time you set a construction task, the supply alarm is in the unset state, and so construction attempts to proceed. This may seem odd, but consider the case of an unit moving to some point. Along the way, it reaches a low supply state, and the supply alarm is set. This halts its movement to the destination point. In order to proceed, the user must reissue the order to continue to the destination point, because the task agenda was cleared when the movement was interrupted by the passive plan. You can think of the movement halt as being a prompt, "do you really want to continue?", and the reissued order as being an override, "yes, I really do want to continue (or do something else, such as head to a resupply point)". On the one hand, this behavior is a really annoying PITA, when you are trying to, say, fly an aircraft from one far way base to another, and have enough fuel to get between the two points, but the points are farther apart than the "midpoint" or turnaround radius for refueling. (It also can seem like a bug in certain circumstances; witness the bug report that prompted this discussion.) On the other hand, this prevents the player from accidentally crashing his/her unit by giving orders to fly too far. I wish to note that I was not the one who designed this "feature", and I certainly think that we could be doing better. Here are some of the things I think we could be doing better: (1) If an unit is obviously headed towards a desination that is capable of resupplying the material it is low on, then the supply alarm should not be set. This would allow long distance movement between two resupply points to proceed uninterrupted by crossing the turnaround radius. However, this seems to be a potentially complicated issue as another critical supply may become low further along the path, and if the destination cannot resupply the second material, it may be too late to turn back (assuming the origin could have resupplied the second material). (2) There should be a side notification indicating that the task at hand was interrupted due to reaching a low supply condition. This would help prevent confusion such as what led to this bug report. (3) Ultimately, the 'waiting-for-tasks' flag should be set _without_ clearing the task agenda. This would (with appropriate UI controls in place) allow an user to resume a task that was suspended due to the supply alarm being set, __without the need to reissue an order to create the task anew. I think I can do something about (2) now, but (1) and (3) will have to await until the appropriate time comes to deal with them. ---------------------------------------------------------------------- Comment By: Matthew Skala (matthewskala) Date: 2005-08-06 16:41 Message: Logged In: YES user_id=1167698 Sorry, I think I selected the file to upload but forgot the check the "attach this file" check box. Here it is. ---------------------------------------------------------------------- Comment By: Eric McDonald (eric_mcdonald) Date: 2005-08-06 14:53 Message: Logged In: YES user_id=1158352 The save file seems not to be attached to this tracker entry. If you can provide it, I would be very interested in fixing the problem. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1252895&group_id=124062 |
