Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Firestorm

Pages: [1] 2
Resources / Now available at a dealership near you
« on: December 07, 2015, 03:20:53 am »
Just in time for the holidays, for those who want Moriarty Power Armor, but DON'T want to pay "Moriarty Power Armor" prices.

Inquire at your local retailer for more details.

Coming soon in a variety of colors and fashions!

Yep, you could no longer print a line of 150 waypoints one next to another.

Do people actually do that?  I don't even release a NORMAL weapon unless I have at least a very strong suspicion that there's a target in the impact area, let along a high-value one like a blaster bomb.  If I have a weapon that capable of mass destruction, I want to make sure I use every gram of that "mass" I can, like for those BIG kills, either one or two very serious threats, or a dozen smaller ones....

Suggestions / Re: SUGGESTION/REQUEST: New weapon Sentry Cannon
« on: December 05, 2015, 04:48:36 am »
Won't it take more than 3 tu to spin to hit something behind it?

By "guided" missiles, I assume he means launched using waypoints, in which case it means they can be fired in any direction and navigated on-target.

But more importantly, I just wanted to say that those are some awesome graphics!

Open Feedback / Re: Research: Dependencies & Requirements
« on: December 03, 2015, 02:07:41 am »
Always unlocks one. Usage of 'getOneFree' also has a side effect which is that the research topic will always be available for research, even with dependencies.

Are there any plans to remedy this in the future?  Further testing on my example above has shown that listing a requirement under an alien interrogation will lock it, as I've described, but there does not appear to be any way to unlock it once the requirements have been met.  And I'd much rather use dependencies anyways, as they're simpler, more direct, and less prone to complications as have been described throughout this topic.

Open Feedback / Re: Research: Dependencies & Requirements
« on: November 30, 2015, 05:10:53 am »
the divide between the corpses and the autopsies is intentional - medics will unlock certain autopsies, but they won't grant any associated research, whereas the corpse itself will still be available, and WILL.

for example: deep ones.
if you capture an aquatoid medic, he might give you information on live deep ones, but that won't give you access to aqua plastics, you still need to go out and get a physical sample.

So... Just to be crystal clear, you're saying that if I had

Code: [Select]


Then interrogating the medic will give me the autopsy report, but will NOT unlock the thingamajig, because I didn't do the actual legwork on the CORPSE myself.  However...  If I did this instead:

Code: [Select]

and again, I got that autopsy from an alien medic, that WOULD still satisfy the requirements, yes?

I'm pretty sure live aliens are exempt from normal research limitations. You can always interrogate them.

Just tested this and it is not entirely true.  While they do appear to be exempt from dependencies, they are, however, still unavailable to research if any requirements are not yet met.  Further testing may be advisable though to make sure everything flows as it should throughout the process.

Work In Progress / Re: Script trace w/ commentary
« 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.,3222.msg36870.html#msg36870

Work In Progress / Re: Script trace w/ commentary
« 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 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
10 = URBAN14
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]
      - 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...

Work In Progress / 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  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:
   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.
      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,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:
   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,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 (,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:
   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!
   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.

   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:
   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 (,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:
   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!

What about using live aliens as a component in manufacturing?  Anyone tried that yet? (wrings hands together evilly)

Suggestions / Re: more advanced map scripting (for vanilla)
« on: December 21, 2014, 03:58:33 am »
LOL Oh yeah.  I guess my math is wrong even when it's right  :-\

Suggestions / Re: more advanced map scripting (for vanilla)
« on: December 21, 2014, 03:16:04 am »
Okay I keep looking at how these scripts are being coded, and maybe I don't know enough about the underlying code, but I keep getting a nagging in the back of my brain that they're not being coded correctly.  So someone check my math and explain to me the errors?

Trying to run 1 of 3 scripts.
The example above says:

33% chance of running script 1.
If that script is not run, 33% chance of running script 2.
If neither script runs, 100% chance of running script 3.

Now, if script 1 fails, script 2's probability of running is independent of script 1's chance, so it's only given a 33% TIMES 33% chance of running, or 1/6 chance, because the first test has no impact on the second.
The remainder of the time, of course, the final script runs.

Shouldn't it look more like this?

33% chance of running script 1
if script 1 fails, 50% of REMAINING probability of running script 2.
Otherwise, run script 3.

Or is my math and/or understanding of the code faulty?

Suggestions / Re: traits for aliens
« on: December 20, 2014, 09:06:35 pm »
Aren't most of the Aliens basically bred to their genetic maximum before being augmented ?

Some things may also be mutually exclusive.  Is it possible for a strongman competitor to also be as flexible as a gymnast? Seriously, I'm asking, because I don't know. 

But the aliens' genetic and cybernetic augmentation also mean that they're highly adaptable.  I've always dreamed of the aliens (AND their equipment, UFO's, etc) being randomly generated.  Maybe they counter your increased use of plasma to higher resistances to it and new, different weapon types.  It would really make autopsies useful again to anyone who's played the game before and now only does them for the points when there's no longer any useful technology to unlock, plus keeping a pool of scientists necessary past the first quarter or two.

Open Feedback / Re: Playable Dev Build of TFTD?
« on: December 20, 2014, 08:59:16 am »
Got it. Any chance we get videos or screen-shots of geoscape, just to let us now how work on it is moving along?

What exactly would you be hoping to see? UI appearance aside, TFTD geoscape is pretty much the same as UFO.  The only thing that really changes is the textures.  I wouldn't be surprised if the vast majority of code remains the same (although I also wouldn't be surprised to find out I was wrong, either.)

Suggestions / Re: Soldiers to recruit.... elite....
« on: December 20, 2014, 08:29:36 am »
Well, X-Com is a game first of all - not a simulator of military action. This means that gameplay rules should always be in a priority. As for system of hiring new troops - it should be definitely more clear. Maybe something like Griswold shop in Diablo. You have a list of recruits with shown parameters that (list, not parameters ^_^) change regular. Maybe something like - the oldest offer (if the list is full) leaves the list and the new offer appears in the list every in-game day.

This has always been my opinion.  I mean, I'm the leader of a (somewhat) prioritized multi-national defense force.  Are you telling me I can't even see the soldiers I can get before they arrive?  I'd expect to at least be able to see a list of potential candidates before I decide who I recruit, and not just settle for whatever dregs the governments scrape off the bottom of the barrel (even if it IS the very nicest of barrels).  Then I can pick who I need based on priority.  Maybe increase the range of both caps, so if I want that guy who can thread a needle with a bullet, I have to accept the fact that his target can run a marathon before the shot ever comes. My thought was more to have a set number of candidates each month, and the next month replace them with new applicants, or maybe just fill in the gaps.  If you use all up your wannabes before then, then you DO have to accept whatever random guys (and gals) the feds can conscript to your cause.  Although I do like the idea of adding one (or some) more each day.  Either way works, really.

Oh, and as for the "Stats improve more when they're lower or not" debate, you have to be more specific.  Primaries (accuracy, reactions) don't, but your secondaries DO improve faster at lower levels (statistically speaking, of course).

Work In Progress / Re: [Question] Landing map blocks and walls?
« on: December 19, 2014, 01:32:58 am »
See now that obviously looks wrong with a skyranger there, but swap it for a medium scout or something, and it'd look like the UFO crashed into the side of the building coming in too hot.  But from what I'm hearing from Warboy, it would have to be carefully created maps explicitly for that purpose.  Although that does give me ideas about landing a skyranger on rooftops...

Pages: [1] 2