Bobchillingworth Wrote:I have combined them before with success, although it's certainly a very difficult combination.
How did you do it? It seemed to be a very cool way of playing. First, it'd solve the problem of getting those Erebus script Khazad starting position in the first switch, in an all hill capital. Second, it'd make the timing of the switch important too. I was very frustrated when it didn't work out.
Hmm, it has been a while, but I think I just selected both options per usual, and ran the game with an advanced era start (one era in). I had actually already created the high-to-low + final five scenario over a year ago, but I never ran it because the switches for some reason were always to the same people, which made no sense. I lost the WB file when my laptop HD died last year, but I might still have it saved somewhere in my inbox, since I remember having emailed it to Sareln or someone for review. I could forward it to you if you want, provided I can find it. It would have been just for regular FFH.
Ichabod Wrote:How did you do it? It seemed to be a very cool way of playing. First, it'd solve the problem of getting those Erebus script Khazad starting position in the first switch, in an all hill capital. Second, it'd make the timing of the switch important too. I was very frustrated when it didn't work out.
This is fairly offtopic, but your post reminded me that I've been meaing to ask the FFH crowd, "Are Erebus Continent maps always filled with mountains, with nearly every civ pseudo-isolated, or have I just been having bad luck?"
Merovech's Mapmaking Guidelines:
0. Player Requests: The player's requests take precedence, even if they contradict the following guidelines.
1. Balance: The map must be balanced, both in regards to land quality and availability and in regards to special civilization features. A map may be wonderfully unique and surprising, but, if it is unbalanced, the game will suffer and the player's enjoyment will not be as high as it could be.
2. Identity and Enjoyment: The map should be interesting to play at all levels, from city placement and management to the border-created interactions between civilizations, and should include varied terrain. Flavor should enhance the inherent pleasure resulting from the underlying tile arrangements. The map should not be exceedingly lush, but it is better to err on the lush side than on the poor side when placing terrain.
3. Feel (Avoiding Gimmicks): The map should not be overwhelmed or dominated by the mapmaker's flavor. Embellishment of the map through the use of special improvements, barbarian units, and abnormal terrain can enhance the identity and enjoyment of the map, but should take a backseat to the more normal aspects of the map. The game should usually not revolve around the flavor, but merely be accented by it.
4. Realism: Where possible, the terrain of the map should be realistic. Jungles on desert tiles, or even next to desert tiles, should therefore have a very specific reason for existing. Rivers should run downhill or across level ground into bodies of water. Irrigated terrain should have a higher grassland to plains ratio than dry terrain. Mountain chains should cast rain shadows. Islands, mountains, and peninsulas should follow logical plate tectonics.
I'm similarly interested in trying one out but not for EitB. Though count my vote extremely low for that since I've a bad habit of becoming distracted by new shinies and never completing something I start.
I'll be sticking with EitB for any FFH Adventure I make, for a few reasons-
* While the AI in EitB is still generally inept, it is significantly improved from the malignant incompetence regularly witnessed in FFH.
* The "Balance" part of EitB enables a wider breadth of strategies for the typical FFH game (due to saner tech costs and fewer "always correct" options), which means more opportunities for more interesting scenarios.
* EitB has become the RB standard for FFH events, largely due to the point above. I don't want to force players to return to the base mod, which many may have by this point otherwise abandoned. I admit that I'm mostly basing this off of personal experience.
That said, if somebody has a regular FFH event concept in mind, feel free to run it by me. I have no problem with some of RB's FFH Adventures using only regular FFH, I just won't be making those games myself.
Adventure map is essentially complete. I'm fairly pleased with how it turned out, although I need to actually test it. It'll probably launch Monday.
Question, though- does anybody know how I can get the Portal map feature to warp units to coordinates other than the default 0,0?
The relevant portions from Kael's "Modder's Guide" seem to be the following:
Quote:Python functions:
The following functions exist in the ScenarioFunctions.py file. This file is only used when a scenario is running (so these checks don't effect the normal game) and allow us to apply special rules for a specific scenario. Every scenario has a gameoption specified for it so that we can distinguish between different scenarios in this functions.
[...]
onMovePortal- Exactly as the onMoveJungleAltar, but for portals.
Quote:Special Objects:
Portals- The portal improvement will trigger the onMovePortal function (which is scenario specific). The plot itself holds the portal destinations which are typically set in gameStart, though its possible to change them at anytime with python commands.
pPlot.getPortalExitX()
pPlot.getPortalExitY()
pPlot.setPortalExitX(int iNewValue)
pPlot.setPortalExitY(int iNewValue)
I tried copying in the " pPlot.getPortalExitX()
pPlot.getPortalExitY()" and "onMovePortal" commands into the WB file via Notepad (after adding in the desired coordinates), but it didn't do anything. I don't understand what the "Python functions" paragraph wants me to do, is there a separate file I have to edit or something? Is it possible to make portals move units to specific tiles just by editing the WB file alone?
Edit: There's more info from the guide I should have posted-
Quote:onMoveJungleAltar- If a unit moves onto a jungle altar feature and the plot is Python Active (see new SDK functions below) this will trigger. We use the game option of the scenario + the coordinates of the plot to trigger different results for different altars.
[...]
Python Active- Python active plots will process any onMove python scripts form improvements or features in them. If a plot has its python active disabled those onMove python scripts won't trigger. We use it to make a Python onMove function only trigger once (such as with the Guardian of Pristin Pass).
pPlot.isPythonActive()
pPlot.setPythonActive(bool bNewValue)
Does this mean that I first need to copy in the "PythonActive" code lines, then the "onMovePortal", and finally the "pPlot.getPortalExit" stuff? If so, where do I insert it into the WB file? Are there variables I have to specify in the "PythonActive" lines, or can I copy them in unaltered? I obviously know absolutely nothing about coding.