[MODCOMP] New sentry actions for units
- Thread starter Pep
- Start date
EmperorFool
Deity
I noticed while adding this to BULL that there are also new options to allow city governors to build workers and workboats.
1. Do these apply only to the human players?
2. If no, are they on by default for the AI players?
1. Do these apply only to the human players?
2. If no, are they on by default for the AI players?
They apply only to the human players.
Thanks for the advice! I have uploaded the files again and the links now seem to work correctly.
EmperorFool
Deity
I found a possible bug while trying to track down the stack attack crash in BULL. Let me say up front that I rewrote most of this modcomp when merging it with BULL because a) I wanted to make part of the changes optional (sentry actions and governors) while leaving the rest mandatory (safe moves), b) I fixed safe moves so that they work on reload, and c) some other reason I'm forgetting right now. You may not have the stack attack crash as I may have caused it in my tinkering. The issue I'm reporting now, however, is in the original BTS code.
At the start of CvSelectionGroup::continueMission() the group is checked to see if it should attack units it runs into while on a MOVE_TO mission. I think you want to add in MOVE_TO_SENTRY as well. Original code:
New code
Note that the code checks if the order was issued this turn. Currently, if the player clicks Move To And Sentry and selects a plot with an enemy, the unit will move up to the enemy but not attack. Perhaps that's what you want, and after writing this up (and doing a test in BUFFY), this may actually make the most sense.
Even with this change, I think the unit would attack the unit and if victorious would cancel the mission anyway. I think I've already made my decisions to retract the change. What do you think?
At the start of CvSelectionGroup::continueMission() the group is checked to see if it should attack units it runs into while on a MOVE_TO mission. I think you want to add in MOVE_TO_SENTRY as well. Original code:
Code:
if (headMissionQueueNode()->m_data.eMissionType == MISSION_MOVE_TO)New code
Code:
if (headMissionQueueNode()->m_data.eMissionType == MISSION_MOVE_TO
[B]|| headMissionQueueNode()->m_data.eMissionType == MISSION_MOVE_TO_SENTRY[/B])Note that the code checks if the order was issued this turn. Currently, if the player clicks Move To And Sentry and selects a plot with an enemy, the unit will move up to the enemy but not attack. Perhaps that's what you want, and after writing this up (and doing a test in BUFFY), this may actually make the most sense.
Even with this change, I think the unit would attack the unit and if victorious would cancel the mission anyway. I think I've already made my decisions to retract the change. What do you think?
EmperorFool
Deity
I was looking at the code to fortify/airlift new units built in a city and had some ideas I'd like to run by you. I was going to implement them when merging with BULL, but if you're interested in these I'd rather help to get them into your mod directly as I've looked at the places where the calls should happen.
You set a rally point for cities by selecting them and shift-clicking on the desired rally point. We could extend this by adding
We can even change the color or shape of the rally point ring: red means go to and fortify, bracketed square means airlift, and red square means airlift-and-fortify. CONTROL + SHIFT + CLICK on the same city would clear the rally point as usual but also set the fortify-on-build flag.
I feel the immediate visual feedback will make using this method easier to use and remember than key combinations. Those could be left in of course for toggling without having to set the rally point again.
The rally point setting is in CvCity::doTask() which receives bool values for the keyboard modifiers. The plot drawing code is in CvGame::updateColoredPlots() and a pretty simple change. Even if you don't want to add the mouse behavior, I recommend changing the icons on the map for selected cities.
Edit: Oh yeah, and the last piece is that we could add an icon above the city bar indicating if there is a rally point and the fortify/airlift states. A flag would make a good rally point icon with something to indicate that the unit fortifies when it arrives. A parachute could mark cities that airlift new units. Actually, the fortify upon arrival setting probably isn't needed on the map; the hover would work well for that.
You set a rally point for cities by selecting them and shift-clicking on the desired rally point. We could extend this by adding
- CONTROL - Fortify when rally point reached
- ALT - Airlift to rally point
- BOTH - Airlift to rally point and fortify
We can even change the color or shape of the rally point ring: red means go to and fortify, bracketed square means airlift, and red square means airlift-and-fortify. CONTROL + SHIFT + CLICK on the same city would clear the rally point as usual but also set the fortify-on-build flag.
I feel the immediate visual feedback will make using this method easier to use and remember than key combinations. Those could be left in of course for toggling without having to set the rally point again.
The rally point setting is in CvCity::doTask() which receives bool values for the keyboard modifiers. The plot drawing code is in CvGame::updateColoredPlots() and a pretty simple change. Even if you don't want to add the mouse behavior, I recommend changing the icons on the map for selected cities.
Edit: Oh yeah, and the last piece is that we could add an icon above the city bar indicating if there is a rally point and the fortify/airlift states. A flag would make a good rally point icon with something to indicate that the unit fortifies when it arrives. A parachute could mark cities that airlift new units. Actually, the fortify upon arrival setting probably isn't needed on the map; the hover would work well for that.
I think adding MISSION_MOVE_TO_SENTRY is not necessary because in this mode you never attack the enemy units. The movement stops when a unit in the stack sees the enemy units.
I don't agree. The keys CTRL and ALT are already used to select multiple cities and it could be confusing. I chose keys not used in any commands to avoid this. Changing the rally point and adding an icon is a good idea to enhance the user interface.
EmperorFool
Deity
EmperorFool
Deity
I only have a couple minutes here, so let me say that I fixed the stack attack problem in BULL/BUFFY. I implemented a few things differently, but I think this part is straight from this NSE's source.
In CvSelectionGroup::groupMove() near the very top a boolean (bSentryAlert) is set and checked inside a loop. Actually, I may have made the local variable to store the value, but the bug may still be there in your mod.
This causes a null pointer exception when the stack gets split up. The fix is easy:
In CvSelectionGroup::groupMove() near the very top a boolean (bSentryAlert) is set and checked inside a loop. Actually, I may have made the local variable to store the value, but the bug may still be there in your mod.
Code:
bool bSentryAlert = isHuman() && headMissionQueueNode()->m_data.eMissionType == MISSION_MOVE_TO_SENTRY && sentryAlertSameDomainType();This causes a null pointer exception when the stack gets split up. The fix is easy:
Code:
bool bSentryAlert = isHuman() && [B]NULL != headMissionQueueNode() &&[/B] headMissionQueueNode()->m_data.eMissionType == MISSION_MOVE_TO_SENTRY && sentryAlertSameDomainType();This modification makes great sense.
I has found some original BtS behavior which makes me wonder.
- If the next queued order after a mission which run out movement points (e.g. Pillage or Build a Improvement, etc) is Sleep (, Sentry, Fortification, or Skip a turn), the next (and left) orders are all cleared at the next turn.
- When you give a command to the unit which has already run out movement points, active unit focus is not sent to a next unit unusually. (Doubled commands will do.)
Exceptionally, if a given command is Sleep (, Sentry, Fortification, or Skip a turn), active unit changes, but the command is cleared at the next turn.
How do you think these behavior?
EmperorFool
Deity
Select one or more cities then SHIFT + CLICK on a tile (or maybe CONTROL + CLICK?) to set it as the waypoint for all units built in all selected cities. SHIFT + CLICK on one of the selected cities to remove the waypoint for them. This mod adds new capabilities with those cities selected: hitting keys to change how the waypoint works (read instructions in mod).
I have a request which seems to fit in with the idea of this modcomp.
When you set a group of workers to build an improvement (or chop, roads etc.) when they finish there can be workers with movement points left that do not enter the unit cycling queue for awaiting orders.
e.g. Set 9 workers to build an improvement that takes 10 turns. On the second turn, 8 of them will not do anything unless you manually select them.
The end turn button even goes red.
Anyway, the request is (perhaps obviously) for there to be some way that workers with movement points left separate from their group so they can perform other tasks. I'm pretty sure this would help in worker micromanagement a fair bit.
If workers are automated in a group this might be a bit more complicated because you might not want them separating from the group. Personally when I want to automate workers I don't put them in groups but this is why it could perhaps be an option.
Would this request be more suited in the BUG project?
When you set a group of workers to build an improvement (or chop, roads etc.) when they finish there can be workers with movement points left that do not enter the unit cycling queue for awaiting orders.
e.g. Set 9 workers to build an improvement that takes 10 turns. On the second turn, 8 of them will not do anything unless you manually select them.
The end turn button even goes red.
Anyway, the request is (perhaps obviously) for there to be some way that workers with movement points left separate from their group so they can perform other tasks. I'm pretty sure this would help in worker micromanagement a fair bit.
If workers are automated in a group this might be a bit more complicated because you might not want them separating from the group. Personally when I want to automate workers I don't put them in groups but this is why it could perhaps be an option.
Would this request be more suited in the BUG project?
EmperorFool
Deity
I think it makes sense here. I would prefer that instead of breaking up the group automatically groups of Workers with at least one with MPs left be included in the normal unit cycling. You can then easily CTRL + CLICK one of them to select just the ones with MPs left and issue new orders or hit CTRL + W to leave until later in the turn or SPACE to skip until next turn.
Heck, make it an option:
Heck, make it an option:
- Consider whole group "active"
- Split into two groups
Similar threads
- Locked
