Author Topic: Script trace w/ commentary  (Read 4783 times)

Offline Firestorm

  • Sergeant
  • **
  • Posts: 19
    • View Profile
Script trace w/ commentary
« on: November 28, 2015, 08:03:19 am »
With the focus now shifting from TFTD back onto X-Com, I've started diving back into writing my own mod (it's still in the early design phase, don't hold your breath yet).  So I've been going back over the rulesets to refresh my memory and learn some of the more in-depth stuff, but I still had a lot of questions and uncertainty with the documentation provided at  https://www.ufopaedia.org/index.php?title=OpenXcom.  So after pouring over this forum looking for answers, I think I've caught onto most of it, but I'm still needing some clarifications on many things.  So I've decided to post my rendition of a typical walkthrough down the mission chain, including along the way a few (of my many) questions, and I'm hoping the community will help answer them, as well as point out any grievous errors or omissions in my process.

So without further ado, let's create a mission:
missionScripts.rul
   If firstMonth, LastMonth, conditionals, executionOdds, minDifficulty, researchTriggers, and maxRuns all pass, schedule a mission.
   If mission-, race-, or regionWeights are specified, they override any values listed in the regions or alienMission rulesets.  In our example, we'll say we're using those defaults.
   Region is chosen based on weights given to each in their ruleset.
   Mission is chosed based on that region's weighted odds for each appearing there.
   Alien race is chosen based on the alienMission's weighted odds of that mission being carried out by each race.
   Questions:
      Labels:  The documentation states that each label should be unique in the command list, which I originally took to mean within each script file. However, based on the arguments over claiming particular number ranges in this thread  https://openxcom.org/forum/index.php/topic,3782.15.html, I now understand that ALL labels have to be unique, including within any mods the player might be running.
      startDelay: Mission scripts run at the beginning of the month (12 midnight on the 1st, I presume).  Is this value the only thing stopping the mission from beginning immediately? Because I always thought that the mission was scheduled for some date/time during that month, but in either of those cases, I don't really see how startDelay ties in here, because the numbers I'm looking at being used for it are far too small to have any significant impact.
      useTable: I read in the docs that missions are scheduled based on a deck pick.  That is, it draws a mission from all possible choices, runs it once, and then never runs that same mission again until all other missions have been exhausted.  It then puts them all back into the deck and reshuffles them.  I'm assuming that this value tells the game whether or not this mission is drawn from that deck, or is an "extra" mission to run in addition to it?

So, we have our assigned mission, race, and region. Now we move on to:
alienMission.rul
   Objective tells us what what happens if the mission is a success, whether it's (1) the country the ufo's land in leave the CFN, (2) a new base is constructed, (3) a special mission is created, (4) an X-Com base is searched for and attacked, or (5) a supply mission to an alien base.  I'm guessing the 5 is needed to tell the ufo to go specifically to an alien base and not simply pick a random point in the mission zone?
   spawnZone: Tells us the random area in which the creation of "something special" happens.  4 is used to determine where to place a base, whether it's a direct base mission or the side-effect of a successful alien infiltration. 3 is used for terror missions, but since there's no "area" within these zones, they happen on the only point available within the zone chosen, the city itself.  The docs suggest that this is the only possible zone for terror missions, but what I read in this thread https://openxcom.org/forum/index.php/topic,3811.msg49888.html#msg49888 tells me that it's really just the only vanilla zone that meets the necessary criteria, and that by creating new set of mission zones comprised of single points, there are more options for terror and other "special" missions to be generated.  However, I also read in the docs that OXC only supports 6 sets of missionZones, and since vanilla uses 5 of them, that only leaves 1 for modders to play around with.
   raceWeights: Although at this point in our hypothetical mission these weights have already been looked at and a race chosen, one thing to add here.  They're listed by month, but only have listings on odd months, so my deductive reasoning tells me that the lower-month is used until a new entry is reached, or in other words, it uses whichever satisfies: this listing <= current month < next listing.

So we have our mission, and we know what we're doing with it.  Enter the UFO's:
Waves (included in alienMissions.rul)
   Number and type specified of ufo's are created for the first wave.  The timer tells us how long until the next wave arrives, but does it start as soon as the ufo arrives?   When it leaves?  What if it's shot down before then?.  In any case, am I correct in assuming that by this point in the mission (and indeed, well before it), success is pretty much automatic for the aliens?  A base WILL be built.  A country WILL be infiltrated. A terror site WILL be... Well, okay.  For terror sites, shooting down the terror ship before it triggers the site will prevent it  (assuming there is a terror ship GENERATED. for some special missions, this may not always be the case.  More questions on this to follow later).  But otherwise, shooting down any, and indeed all, of these ufos does nothing but to earn X-Com score, (potentially) deny the aliens same, and possibly increase the wave timer?
   Trajectory: THIS is the reason that missionZone 5 is always UFO entry/egress points, 3 is always terror sites, 4 is always alien bases, etc.  Because every trajectory says "Start and end at 5", "Go to (3/4) and do your thing."  And just to be certain, since I've seen some inconsistent data from... somewhere, the speed and altitude are adjusted AFTER that waypoint is hit, not on the way TO it, yes?  Not really sure why the final waypoint (egress) even needs them, but perhaps it's simply to avoid exceptions and that's the source of all my misunderstanding.
   Objective: Why do supply ships need it? Is it just to say "insert the coordinates of an alien base into your trajectory and land there"?  But my main issue with this one is this: Warboy says in the thread I mentioned above (https://openxcom.org/forum/index.php/topic,3811.msg49888.html#msg49888) that this mission site may or may not have an associated ufo fly to it to create the mission.  My question is, what makes that distinction?  Is it by whether or not I provide a valid UFO for the objective wave, "If ufo: is a real ufo, have it fly there and generate this mission.  Otherwise, just generate the mission anyways."?

Alright.  We now have UFO's flying all around and doing stuff.  Let's shoot one down and go in for a closer look:
globe.rul
   First we look and see in what kind of environment this battle takes place.  Each texture on the globe has an id which directly corresponds to a name, which will later reference the terrain to use.  But before we do that...  Here is the reason all cities have a constant -1 in their definition, and all (and only) terror sites generate in urban terrain.  That -1 points to this entry in the textures definitions.  I'm guessing the value is negative because there are no corresponding textures to display on the geoscape; it is a terrain that is only used for special mission sites that generate within this missionZone (which, again, as no area and thus cannot be landed in unless explicitly defined to).  Also, since there is no UFO in terror sites, and consequently no corresponding alienDeployment to reference, we have to specify the deployment(s) we want to use for them, and the... percent chance of each one appearing? Or is that 100 just a weight?

So we know what the battlefield is, let's create it!
terrains.rul
   name: This is a direct lookup from the name entry we just examined in globe.rul's texture definitions.
   mapBlocks: lists all the blocks we'll use to generate this terrain
   mapDataSets: lists all the tile information the aforementioned blocks will use.
   Any listed civiliansTypes: will also be generated randomly once we know where we are, but first we need to find out where we are by running any scripts listed.

mapScripts.rul
   Soooo many questions here.  But they mostly deal with how to use each individual command, and do so effectively, so maybe they'd be more appropriate in another thread in which this script is more the focus, rather than just part of a general overview as in this one.  So... Let's keep it simple for now.
   We know we're at a UFO crash, so first we addUFO.  That goes into ufo.rul, looks up what ufo we're invading, adds its mapBlocks and mapDataSets to our battlefield, then loads in the named UFO map files.  This is where my questions start to get a bit more complex.  Specifically, is it possible to include a (sub)script to THIS map (in ufo.rul)?  I'd love to be able to randomly generate the layout of a UFO, perhaps by breaking it down into smaller chunks and having a bunch of different possible layouts for each one.  But this would be even more difficult considering the smallest mapBlock it appears you can use is 10X10, which wouldn't permit me to, say, break a scout down into 4 5X5 quadrants and randomly generate a different section for each. But c'est la vie.  Perhaps in the future...
   So we have a UFO to head towards, now we need a drop point for ourselves, so we addCraft or addBlock for X-Com units to spawn in.  Since this is a downed UFO, we addCraft for our dropship.  We take a peek at crafts.rul and find data laid out in exactly the same format as our UFO, so we just drop it in with identical fashion.
   Then for pretty much all terrains, we simply just color in the blank spots with fillArea.  My issue here is, I'm totally lost on what the listed block indices are actually INDEXING.  I thought at first that it was their order of appearance in terrains.rul, but that can't be it because there are gaps in the urban block set, and those gaps are reflected in the indices here in the script.  So... does it take it from the number at the end of the block name?  Or is that from somewhere deeper in the actual data files?  And then there's the question of how it knows that block 20 means to use whatever map is assigned to that base facility in defense missions. [edit: Looking back now, I'd say the facilities are probably added in automatically, and that block 20 is just there to throw dirt in on top of the unused portions of the map.]

So now we have the terrain laid out.  Let's fill it with aliens:
alienDeployments.rul
   Now first off, I think I went out of order here, but I might have done so anyways even had I noticed, for the sake of clarity.  If I'm not mistaken, this actually executes BEFORE any scripts, and possibly even before the terrain is loaded?  I say this because I know from this thread (https://openxcom.org/forum/index.php/topic,3138.msg38176.html#msg38176) that the map size is already known by the time the script runs, and that's determined by alienDeployments.  So the aliens are already created, they just don't actually spawn, of course, until after all the aforementioned runs because they don't have any actual spawn points yet.  But regardless, moving on...
   We start by looking up the UFO we just shot down and using that to determine what the map size is, X, Y, and Z.  Then for each alien rank listed, we spawn the minimum number of aliens based on difficulty, plus a random number of additionals based on dQty and/or extraQty, and determine whether they are inside or out of the UFO based on the percentages.
   Next we give them gear by looking up the current month in alienItemLevels.rul, and assigning to each one the itemSets for whichever percentile that the RNG saw fit to give them.

But wait, we're not done with fleshing out the aliens just yet:
units.rul
   By now, we know the race, rank, and quantities of all the aliens.  So now all that's left is to give each one the stats and characteristics of his (or her) respective race/rank combination.  Slap on some armor for appearance's sake, and you now have your very own invasion force perfect for conquering earth!  Let the battle commence!
« Last Edit: November 28, 2015, 09:07:25 am by Firestorm »

Offline Hobbes

  • Commander
  • *****
  • Posts: 2101
  • Infiltration subroutine in progress
    • View Profile
Re: Script trace w/ commentary
« Reply #1 on: November 28, 2015, 05:21:19 pm »
So after pouring over this forum looking for answers, I think I've caught onto most of it, but I'm still needing some clarifications on many things.  So I've decided to post my rendition of a typical walkthrough down the mission chain, including along the way a few (of my many) questions, and I'm hoping the community will help answer them, as well as point out any grievous errors or omissions in my process.

At the beginning you tried separating the specific questions, next time try to keep up with it, it really saves time not having to read everything :)

      useTable: I read in the docs that missions are scheduled based on a deck pick.  That is, it draws a mission from all possible choices, runs it once, and then never runs that same mission again until all other missions have been exhausted.  It then puts them all back into the deck and reshuffles them.  I'm assuming that this value tells the game whether or not this mission is drawn from that deck, or is an "extra" mission to run in addition to it?

If useTable: true, then use the mission table (deck pick) to determine region and mission type to pick the mission region. If useTable: false, then you'll need to define those (region and type) on the entry.

Quote
   Objective tells us what what happens if the mission is a success, whether it's (1) the country the ufo's land in leave the CFN, (2) a new base is constructed, (3) a special mission is created, (4) an X-Com base is searched for and attacked, or (5) a supply mission to an alien base.  I'm guessing the 5 is needed to tell the ufo to go specifically to an alien base and not simply pick a random point in the mission zone?

The 5 is needed to tell the engine which missions to use when performing a Supply mission (which is hardcoded - you can't edit those on missionScripts).

Quote
   spawnZone: Tells us the random area in which the creation of "something special" happens.  4 is used to determine where to place a base, whether it's a direct base mission or the side-effect of a successful alien infiltration. 3 is used for terror missions, but since there's no "area" within these zones, they happen on the only point available within the zone chosen, the city itself.  The docs suggest that this is the only possible zone for terror missions, but what I read in this thread https://openxcom.org/forum/index.php/topic,3811.msg49888.html#msg49888 tells me that it's really just the only vanilla zone that meets the necessary criteria, and that by creating new set of mission zones comprised of single points, there are more options for terror and other "special" missions to be generated.  However, I also read in the docs that OXC only supports 6 sets of missionZones, and since vanilla uses 5 of them, that only leaves 1 for modders to play around with.

Where did you read this about OXC only supporting 6 sets? Technically I don't think there's a limit (and vanilla uses all the 6 defined)

Quote
   raceWeights: Although at this point in our hypothetical mission these weights have already been looked at and a race chosen, one thing to add here.  They're listed by month, but only have listings on odd months, so my deductive reasoning tells me that the lower-month is used until a new entry is reached, or in other words, it uses whichever satisfies: this listing <= current month < next listing.

Yup, works like that. Vanilla only uses odd numbers but you can use even numbers on your mod.

Quote
So we have our mission, and we know what we're doing with it.  Enter the UFO's:
Waves (included in alienMissions.rul)
   Number and type specified of ufo's are created for the first wave.  The timer tells us how long until the next wave arrives, but does it start as soon as the ufo arrives?   When it leaves?  What if it's shot down before then?.  In any case, am I correct in assuming that by this point in the mission (and indeed, well before it), success is pretty much automatic for the aliens?  A base WILL be built.  A country WILL be infiltrated. A terror site WILL be... Well, okay.  For terror sites, shooting down the terror ship before it triggers the site will prevent it  (assuming there is a terror ship GENERATED. for some special missions, this may not always be the case.  More questions on this to follow later).  But otherwise, shooting down any, and indeed all, of these ufos does nothing but to earn X-Com score, (potentially) deny the aliens same, and possibly increase the wave timer?

Shooting down UFOs increases the timer for the next UFO in the wave by 50%, IIRC. You can never stop infiltrations or alien bases, as you described.

Quote
Objective: Why do supply ships need it? Is it just to say "insert the coordinates of an alien base into your trajectory and land there"?  But my main issue with this one is this: Warboy says in the thread I mentioned above (https://openxcom.org/forum/index.php/topic,3811.msg49888.html#msg49888) that this mission site may or may not have an associated ufo fly to it to create the mission.  My question is, what makes that distinction?  Is it by whether or not I provide a valid UFO for the objective wave, "If ufo: is a real ufo, have it fly there and generate this mission.  Otherwise, just generate the mission anyways."?

It's not the Supply Ships that need it, but the mission generator that needs to know which UFO wave to activate when running a Supply mission.

Regarding missionSites, everything is defined on the ruleset. In the case of the Artifact Sites on TFTD, they are generated on MissionZone 0, not on MissionZone 3, since they use the Artifact region, which only has MissionZone 0 defined, since no UFOs are spawn. 

Quote
I'm guessing the value is negative because there are no corresponding textures to display on the geoscape; it is a terrain that is only used for special mission sites that generate within this missionZone (which, again, as no area and thus cannot be landed in unless explicitly defined to).  Also, since there is no UFO in terror sites, and consequently no corresponding alienDeployment to reference, we have to specify the deployment(s) we want to use for them, and the... percent chance of each one appearing? Or is that 100 just a weight?

Mission zone 3 areas are used by UFOs on Infiltration missions to land, on the last wave.

If you don't set any weights, then the game will randomly choose between the alienDeployments listed, giving them the same weight.

Quote
   We know we're at a UFO crash, so first we addUFO.  That goes into ufo.rul, looks up what ufo we're invading, adds its mapBlocks and mapDataSets to our battlefield, then loads in the named UFO map files. 

You can also use 'addUFO' on terror sites or any other mission that doesn't involve UFOs. This command basically tells the engine to add a specific map block (defined in 'ufos'), but the map block doesn't have to be a real UFO - it can be a building, a mountain, etc.

Quote
This is where my questions start to get a bit more complex.  Specifically, is it possible to include a (sub)script to THIS map (in ufo.rul)?  I'd love to be able to randomly generate the layout of a UFO, perhaps by breaking it down into smaller chunks and having a bunch of different possible layouts for each one.  But this would be even more difficult considering the smallest mapBlock it appears you can use is 10X10, which wouldn't permit me to, say, break a scout down into 4 5X5 quadrants and randomly generate a different section for each. But c'est la vie.  Perhaps in the future...

You can create several different versions of the UFO, and then one of those will be selected when placing the mapblock, LukeExtraUFOs and other mods already do this. I'm thinking it might be possible to have subscripts for UFOs bigger than 10x10, where you could define individual 4 10x10 map blocks to compose a 20x20 UFO. 5x5 might not be possible because everything is set to work in multiples of 10, plus if you wanted to create a Battleship you'd need 36 individual 5x5 mapblocks AND the variations for each 5x5 map blocks. That is a lot of work just for a a single UFO.

Quote
   So we have a UFO to head towards, now we need a drop point for ourselves, so we addCraft or addBlock for X-Com units to spawn in.
 

You can also use addUFO to spawn XCom units. Check my UFO Redux, the Complex YY-18 mission.

Quote
My issue here is, I'm totally lost on what the listed block indices are actually INDEXING.  I thought at first that it was their order of appearance in terrains.rul, but that can't be it because there are gaps in the urban block set, and those gaps are reflected in the indices here in the script.  So... does it take it from the number at the end of the block name? 

The gaps are not referenced on the index used by the script, if I am understanding you correctly. Looking at Urban, there's a gap on the map blocks, so there isn't any URBAN10-13 maps. So the mapblocks and the actual index will start to differ once you reach entry number 10:

0 = URBAN00
1 = URBAN01
(etc)
10 = URBAN14
(etc)
14 = URBAN18
« Last Edit: November 28, 2015, 06:23:48 pm by Hobbes »

Offline Firestorm

  • Sergeant
  • **
  • Posts: 19
    • View Profile
Re: Script trace w/ commentary
« Reply #2 on: November 28, 2015, 09:23:56 pm »
Where did you read this about OXC only supporting 6 sets? Technically I don't think there's a limit (and vanilla uses all the 6 defined)

The first line under mission zones on the ufopaedia https://www.ufopaedia.org/index.php?title=Alien_Missions_in_Enemy_Unknown_(OpenXcom) says that regions "can" have up to 6. I read that as "allows", but maybe it's intended to mean that vanilla "may use".

The 5 is needed to tell the engine which missions to use when performing a Supply mission (which is hardcoded - you can't edit those on missionScripts).

So the engine says "Okay, it's time for a supply mission.  Which one do I use?" And it looks at the list of missions and picks one that has objective 5.  Think I got it now.

Regarding missionSites, everything is defined on the ruleset. In the case of the Artifact Sites on TFTD, they are generated on MissionZone 0, not on MissionZone 3, since they use the Artifact region, which only has MissionZone 0 defined, since no UFOs are spawn. 

So looking at the scripts for artifact sites, from what I'm seeing, if there's no actual UFO to spawn, then in its place I list the alienDeployment for the special mission I want instead, which also includes all the nuts and bolts for a special mission, what to call it, what to say when it comes up, etc.  Missed that part in my synopsis.  But that all seems to go along with the examples in the thread I was referencing above, so it makes sense.  However, after seeing that in TFTD, and then going back to XC1, I'm now noticing that I don't see the link between the terror mission (which DOES have a ship) and the deployment.  I see where it says in alienMissions that terror generates a special mission, and I see said special mission in alienDeployments, but I don't see where one points to the other saying "That is the special mission that this alienMission will generate" or vice-versa...

Mission zone 3 areas are used by UFOs on Infiltration missions to land, on the last wave.

Really just for flavor though, to say "The aliens are making contact with the populace."  I guess I don't really see the need for the -1 at all, since special missions define their own terrain specifically in their deployments, and don't need a lookup on the globe terrains.  Unless it's just to keep them all together.

You can create several different versions of the UFO, and then one of those will be selected when placing the mapblock, LukeExtraUFOs and other mods already do this. I'm thinking it might be possible to have subscripts for UFOs bigger than 10x10, where you could define individual 4 10x10 map blocks to compose a 20x20 UFO. 5x5 might not be possible because everything is set to work in multiples of 10, plus if you wanted to create a Battleship you'd need 36 individual 5x5 mapblocks AND the variations for each 5x5 map blocks. That is a lot of work just for a a single UFO.

I wasn't going to break down the larger UFO's into 5x5.  With enough variety, using 4 different 10x10 maps would be plenty.  I just mention the 5x5 because options are limited for randomizing the ones that are already in that smallest block size.  I've seen Luke's UFO pack (downloaded it, in fact), haven't used it yet, but I will.  My theory though is, given enough time, any finite number of UFO's will eventually get predictable, even if it doesn't start doing so until after you open the outer hatch and say "Okay, I know where we are now."  But with randomized UFO's, you don't know what's behind any (or almost any) door until after you open it. 

The gaps are not referenced on the index used by the script, if I am understanding you correctly. Looking at Urban, there's a gap on the map blocks, so there isn't any URBAN10-13 maps. So the mapblocks and the actual index will start to differ once you reach entry number 10:

0 = URBAN00
1 = URBAN01
(etc)
10 = URBAN14
(etc)
14 = URBAN18


DOH, I guess my first analysis was correct...  The values in mapScripts:

Code: [Select]
    - type: fillArea
      # URBAN set is lacking blocks 10-13, so the numbers don't correlate properly here,
      # because these are references to the block numbers within the sets, not the file names.
      blocks: [3, 4, 10, 11, 12, 13, 14]
      freqs: [3, 3, 2, 2, 2, 2, 2]

DO correspond with the index of their appearance in terrains:

Code: [Select]
    mapBlocks:
      - name: URBAN00
      - name: URBAN01
      - name: URBAN02
      - name: URBAN03
      - name: URBAN04
      - name: URBAN05
      - name: URBAN06
      - name: URBAN07
      - name: URBAN08
      - name: URBAN09
      - name: URBAN14
      - name: URBAN15
      - name: URBAN16
      - name: URBAN17
      - name: URBAN18

I guess what threw me off was that the list in the script's blocks file was so much smaller then the total list for the urban terrain.  But had I looked closer I would've seen why.  0-2 are the roads reserved for use in the addLine commands (I got that part), and blocks 5-9, which were what was throwing me off, were already added each individually through the addBlock command.  Since they're 20x20, they need to go in earlier so we can be sure there's room for them to fit, before we randomly fill in any smaller patches remaining...  I guess that question was just carelessness on my part...

Offline The Reaver of Darkness

  • Commander
  • *****
  • Posts: 1510
    • View Profile
Re: Script trace w/ commentary
« Reply #3 on: November 28, 2015, 11:18:08 pm »
Quote
This is where my questions start to get a bit more complex.  Specifically, is it possible to include a (sub)script to THIS map (in ufo.rul)?  I'd love to be able to randomly generate the layout of a UFO, perhaps by breaking it down into smaller chunks and having a bunch of different possible layouts for each one.  But this would be even more difficult considering the smallest mapBlock it appears you can use is 10X10, which wouldn't permit me to, say, break a scout down into 4 5X5 quadrants and randomly generate a different section for each. But c'est la vie.  Perhaps in the future...

You can create several different versions of the UFO, and then one of those will be selected when placing the mapblock, LukeExtraUFOs and other mods already do this. I'm thinking it might be possible to have subscripts for UFOs bigger than 10x10, where you could define individual 4 10x10 map blocks to compose a 20x20 UFO. 5x5 might not be possible because everything is set to work in multiples of 10, plus if you wanted to create a Battleship you'd need 36 individual 5x5 mapblocks AND the variations for each 5x5 map blocks. That is a lot of work just for a a single UFO.

You could get creative with the 10x10 block the craft starts on: load in map elements from other parts of the map and fit the craft into them, then save as a separate map unit attached to that UFO instead of the terrain. For instance you could have it landed among the hay bales on one of the farmhouses, or crashed through the big farmhouse and sitting on the inside. Or you could just put it in a 5x5 quadrant of that 10x10 space. It's a bit more tedious and you get fewer total possibilities, but it can work out pretty well.

Offline Firestorm

  • Sergeant
  • **
  • Posts: 19
    • View Profile
Re: Script trace w/ commentary
« Reply #4 on: November 29, 2015, 12:00:53 am »
You could get creative with the 10x10 block the craft starts on: load in map elements from other parts of the map and fit the craft into them, then save as a separate map unit attached to that UFO instead of the terrain. For instance you could have it landed among the hay bales on one of the farmhouses, or crashed through the big farmhouse and sitting on the inside. Or you could just put it in a 5x5 quadrant of that 10x10 space. It's a bit more tedious and you get fewer total possibilities, but it can work out pretty well.

I've actually considered doing something similar in a more simplified way, but there were too many complications.
https://openxcom.org/forum/index.php/topic,3222.msg36870.html#msg36870

Offline Hobbes

  • Commander
  • *****
  • Posts: 2101
  • Infiltration subroutine in progress
    • View Profile
Re: Script trace w/ commentary
« Reply #5 on: November 29, 2015, 06:59:31 am »
You could get creative with the 10x10 block the craft starts on: load in map elements from other parts of the map and fit the craft into them, then save as a separate map unit attached to that UFO instead of the terrain.

Have you tried this? Could you elaborate a little more on how you would implement it?

Offline The Reaver of Darkness

  • Commander
  • *****
  • Posts: 1510
    • View Profile
Re: Script trace w/ commentary
« Reply #6 on: November 29, 2015, 01:16:33 pm »
Have you tried this? Could you elaborate a little more on how you would implement it?
I'm having trouble making a working demonstration because a lot of the terrain maps use two tilesets but I can't figure out how to load a second tileset into a craft map, let alone the third I'll eventually need. If anyone can tell me how to do that, I should be able to provide an example.

Offline Hobbes

  • Commander
  • *****
  • Posts: 2101
  • Infiltration subroutine in progress
    • View Profile
Re: Script trace w/ commentary
« Reply #7 on: November 29, 2015, 06:40:57 pm »
I'm having trouble making a working demonstration because a lot of the terrain maps use two tilesets but I can't figure out how to load a second tileset into a craft map, let alone the third I'll eventually need. If anyone can tell me how to do that, I should be able to provide an example.

Are you using MapView?

Offline The Reaver of Darkness

  • Commander
  • *****
  • Posts: 1510
    • View Profile
Re: Script trace w/ commentary
« Reply #8 on: November 30, 2015, 01:09:07 am »
Are you using MapView?
Yes. Sorry, I should have stated this.