[Python] doCommand/setImmobileTimer

[jkp1187]

Here's the situation: I am trying to script an event where a randomly selected Worker unit will be immobile for 2 turns. The EventInfos.xml file has a field for making a selected unit immobile, but for some reason, it isn't working with a worker unit.

I looked through the API under CyUnit, and found these two commands that looked likely. I'm guessing that the second "setImmobileTimer" is the same function that the XML is trying to call, so that's probably no good. "doCommand" seems like it might be correct. Can someone point out to me where I might find examples of the sorts of unit commands that could be forced using doCommand?

Thanks.

void doCommand (CommandTypes eCommand, int iData1, int iData2)
void (eCommand, iData1, iData2) - force the unit to perform eCommand
 
 
 
void setImmobileTimer (int) BtS Only
void (int)

 

[jkp1187]

After investigating the SDK, I suppose not. This is what I found:

    case COMMAND_PROMOTION:
            promote((PromotionTypes)iData1, iData2);
            break;

        case COMMAND_UPGRADE:
            upgrade((UnitTypes)iData1);
            bCycle = true;
            break;

        case COMMAND_AUTOMATE:
            automate((AutomateTypes)iData1);
            bCycle = true;
            break;

        case COMMAND_WAKE:
            getGroup()->setActivityType(ACTIVITY_AWAKE);
            break;

        case COMMAND_CANCEL:
            getGroup()->popMission();
            break;

        case COMMAND_CANCEL_ALL:
            getGroup()->clearMissionQueue();
            break;

        case COMMAND_STOP_AUTOMATION:
            getGroup()->setAutomateType(NO_AUTOMATE);
            break;

        case COMMAND_DELETE:
            scrap();
            bCycle = true;
            break;

        case COMMAND_GIFT:
            gift();
            bCycle = true;
            break;

        case COMMAND_LOAD:
            load();
            bCycle = true;
            break;

        case COMMAND_LOAD_UNIT:
            pUnit = ::getUnit(IDInfo(((PlayerTypes)iData1), iData2));
            if (pUnit != NULL)
            {
                loadUnit(pUnit);
                bCycle = true;
            }
            break;

        case COMMAND_UNLOAD:
            unload();
            bCycle = true;
            break;

        case COMMAND_UNLOAD_ALL:
            unloadAll();
            bCycle = true;
            break;

        case COMMAND_HOTKEY:
            setHotKeyNumber(iData1);
            break;

        default:
            FAssert(false);
            break;

Oh bother. Well, does anyone have an idea about how I could go about temporarily immobilizing a worker...?

 

[snarko]

You could set the domain to immobile. Might require having two versions of workers, one immobile and one not.

 

[Seven05]

Here is your problem...

In CvUnit.cpp:

bool CvUnit::canApplyEvent(EventTypes eEvent) const
{
	CvEventInfo& kEvent = GC.getEventInfo(eEvent);

	if (0 != kEvent.getUnitExperience())
	{
		if (!canAcquirePromotionAny())
		{
			return false;
		}
	}

	if (NO_PROMOTION != kEvent.getUnitPromotion())
	{
		if (!canAcquirePromotion((PromotionTypes)kEvent.getUnitPromotion()))
		{
			return false;
		}
	}

	if (kEvent.getUnitImmobileTurns() > 0)
	{
		if (!canAttack())
		{
			return false;
		}
	}

	return true;
}

Since workers can't attack, the check on canApplyEvent returns false. You could modifiy this code in the SDK to allow workers but I wouldn't just eliminate the check all together or you'll be immobilizing great people, spies, work boats, etc.

If you don't want to mess with the DLL you can try your own code in canMove() but you'll have to intercept the event code somewhere and that won't be pretty in Python.

 

[jkp1187]

Pshaw. Didn't realize it would be so involved. I definitely do not want Great People, etc., to be eligible for immobilization, as that would just open a huge can of worms with other random events (and who knows what else.)

I am trying to avoid messing with the SDK (not least of which because I don't have the necessary compiler,) and going for python just doesn't sound like it will be worth the investment in time and effort for just this one event.

Oh well, I guess I'll just take this random event in a different direction. Thanks for the help...sometimes it's good to just know what I can't do...