.

[member66170]

.

 

[Gerikes]

I am trying to use the SDK to select a square, in much the same way as you do for air missions, but I have a problem. I can't get the engine to return the square which has been selected. In the code below, pPlot is the square the unit is, and not the square selected. Also, the game runs castRangeSpell(pPlot) before I have even selected a square.

    if( lResult == 2)
    {
        gDLL->getInterfaceIFace()->setInterfaceMode((InterfaceModeTypes)GC.getActionInfo(12).getInterfaceModeType());
        pPlot = gDLL->getInterfaceIFace()->getSelectionPlot();
        castRangeSpell(pPlot);
        return true;
    }

I think that getSelectionPlot will return the plot that the currently selected unit/city is on, but I'm not sure.

Typically, I've set bVisible to true on the XML, giving you a button to click to start a mission, but I think this way of setting the interface mode should work too. However, I think that the call will change the interface mode, but it's not going to block the code execution and wait for the user to click, and then continue running the code. Instead, it will set the mode and go right to the next line after setting the interface mode, and thus you're probably going to call the function on the plot the unit is on.

What happens instead, is that when in the interface mode the user clicks a plot, CvSelectionGroup:: pushMission is called, using the arguments of the mission that is under the "Mission" tag in the interface xml, and the plot x and y values. Then, you go through the CvSelectionGroup:: pushMission function (which inevitably will call insertAtEndMissionQueue, activateHeadMission, startMission, and possibly continueMission. All you need to be worried about is pushMisison, startMission, and possibly continueMission).

Check out how the other missions are handled in these functions, and put your code there. This spell seems to be a one-time thing, so you'll probably just need to add some code to startMission, as continue-mission is normally used for doing multiple things (for example, MISSION_MOVE_TO will move one plot for each continueMission call. It then calls itself again to move to the next plot, or if the unit is out of moves, simply escapes the sequence and on the unit's update call continueMission again). If you haven't already, you might need to change canStartMission, because otherwise the mission will be deleted as soon as you start startMission, since it checks that before it even starts the mission.

 

[Gerikes]

Rather than start a new thread, I felt I'd just continue this one, since my question is about the same thing.

Why isn't there a getInterfaceMode() function? Is there some way to mimic the effect of this, by looking at some other telltale sign, or have I completely missed where the function is completely?

 

[Dale]

Lord Olleus:

You need to capture the plot being pointed at in CvSelectionGroup::canDoInterfaceModeAt(InterfaceModeTypes eInterfaceMode, CvPlot* pPlot). Setup a new CASE for your interface then pass pPlot out to your own function. I've implemented a new interface in my ranged bombardment code if you want a look.

Gerikes:

"int CvActionInfo::getInterfaceModeType() const" do?

 

[Gerikes]

Lord Olleus:

You need to capture the plot being pointed at in CvSelectionGroup::canDoInterfaceModeAt(InterfaceModeTypes eInterfaceMode, CvPlot* pPlot). Setup a new CASE for your interface then pass pPlot out to your own function. I've implemented a new interface in my ranged bombardment code if you want a look.

Gerikes:

"int CvActionInfo::getInterfaceModeType() const" do?

That will get the interface mode of a particular action, so when you click the button for that action the exe will set that interface mode. What I was hoping for was a function that will return the current interface mode that the game is in.

For example, the CvDLLInterfaceIFaceBase has the function:

virtual void setInterfaceMode(InterfaceModeTypes eNewValue) = 0;

But, there is no getInterfaceMode() to go along with it. I doubt that extending this class and intercepting all the calls to setInterfaceMode would work, but I might give that a shot later.