OK. First. How the hell can a noob be useful to another noob?
Well, by describing the common pitfalls which are often known institutionally or documented, but not necessarily clear to someone doing all this for the first time. And by describing the thought process that led to a mistake, then the reasoning behind why it's a mistake, and then the actual method to success.
This might be kinda disorganized and full of disparate concepts at first, but as I figure out more solutions to noob problems, I'll try to keep it organized by updating this post! But by all means, feel free to contribute your own if you're in the same boat (or remember noob mistakes you made when you were still one of us, or encounter certain questions all the time).
First, and this is evidently a very common one:
Why is the sexp I want to use grayed out?tl;dr: You need to be sure the sexp you are trying to use makes logical sense within the context of your event structure. Some sexps evaluate true/false, some return integers, some act as qualifiers for something else, etc., and you are trying to use one in a place where FRED expects something else, like a true/false where it expects an integer. You may also be using a sexp that
does something instead of a sexp that
evaluates (i.e. checks conditions of) something.
Here was my goal: Send a "thanks" message from a friendly escaping ship when it got within x meters of its jump-out point.
What I tried: First, I created a new event. I went to replace the
true part with a sexp that would make sense in this situation. I went to Status --> Distance and Coordinates, then saw
distance-from-nav and a lightbulb went off in my head. Aha! The key to everything, EVERYTHING! I expected I'd be able to use this sexp, set the object, what object it's checking the distance from, and then the distance value itself. BLERRRRRRRRRRP nope!
First mistake: nav points. I'm not using those. Just your plain old
waypoints! Nav points are something different and not necessary for pretty much any standard mission. So that already points at another sexp. Which would that be? Just plain ol'
distance.
Second mistake: But but but,
distance is grayed out too, and I can't use it in place of
true! Horror! Obviously, there is a conspiracy against my efforts to make a mediocre mission where a ship says "thanks" a few meters before it leaves.
Actual method: With help from Axem and MjnMixael in IRC, it all became clear to me.
You don't simply do:
when
·· distance
···· <Object1>
···· <Object2>
···· <DistValue>to get your true/false check. You instead do this:
when
·· <
···· distance
······ <Object1>
······ <Object2>
···· <Number>What's the difference? You are checking if something is less than something else, and you use
distance as the
argument for the less than operator, not as standalone operator.
distance tells you
what you are comparing, and nothing else. The preceding logical operator is what you use to get the true/false response. This actually makes things in FRED a hell of a lot more flexible than you might expect! Further, the original example wouldn't have allowed for nearly as much flexibility. How would you specify greater than or less than, or equal to, or any other logical condition with a
distance check otherwise?
What really happens here is the event becomes true when a number is less than X, and the number we're checking is the distance between Object1 and Object2. Not so complicated now, huh? Maybe it's a bit more fancy-looking in the event editor, but it's actually easy to understand once you grap this core concept. And it clarifies a lot of grayed-out sexp situations to boot.
Why isn't my table edit actually sticking?tl;dr: Be sure that your edits are in your mod's
.tbm file, and that you override all other
.tbms that may be modifying the same object. Including
.tbms in the MediaVPs or whatever dependencies you have! For example, if your mod lists MediaVPs_2014 as a dependency in your
mod.ini file, then you need to check those too, not just stock.
From what I've gathered, this is the
table load order (someone correct me if I'm wrong about this), where the last table to load gets the final say in modifications:
- Stock .tbl file
- Dependency mod's .tbl file
- Your mod's .tbl file
- Dependency mod's .tbm file(s)
- Your mod's .tbm file(s)
Here was my goal: Make the SSG Belial appear in the tech database from the get-go. Simple, right? I just added
"in tech database" to my
$flags: field in my mod's
ships.tbl file. It worked for basically everything else I modified! But it didn't work for the Belial, Trident, Shivan Comm Node, Knossos, or Mjolnir. Why not?
What I tried: Renamed the Belial (which worked, but seemed like a bad idea), appended a
#tag to the stock name (which didn't work), cloned the Belial (which also worked, but seemed like overkill).
Mistakes: I didn't take into account that since my mod depends on MediaVPs_2014, I was subject to any and all
.tbms contained within that mod. Sure enough, there was a
.tbm which modified the flags for the Belial, Trident, and a few other things I'd been having trouble shoving into the Tech DB from the start.
The fix: This was easy! I didn't have to move my Belial entry out of
ships.tbl at all. Instead, I created a new entry for it in my
ch-shp.tbm with the
+nocreate flag, then added just the
$flags: field with
"in tech database" added to the list. Boom, done!
Why does this work? Well, because it's
.tbm and is loaded after all the other stuff. Since MediaVPs_2014 is a dependency, that gets loaded before the mod. Then, the mod loads, and it pulls up the mod's own
ships.tbl. Changes from there are processed on top of the stock
ships.tbl. But all
.tbl files are loaded before
.tbm files, so after this happens, the MediaVPs_2014
.tbm files load. Those make further changes. Finally, my own
ch-shp.tbm file loads, further making changes on top of what has already been changed.
Also, a note: why even have a
ships.tbl and ch-shp.tbm? Why not put everything in the latter?
I wanted to keep the ships.tbl file handy for reference on what all ships' stock parameters are. I also used this to modify fluff-related things and added names to turret subsystems ala Blue Planet (AAA Beam or Main Beam / Beam Cannon instead of Beam Turret, etc). But otherwise, I made no gameplay-affecting changes in this file.
Instead, for the few ships where I did want to change actual stats, like power output, afterburner speed / fuel, rotation time, etc., I used my .tbm for that. I would add ships with +nocreate flags and modify only the stats I needed to change, also with the originals commented out after the new ones, so I could see at a glance what was changed and by how much.Example:
; //========================================================================================================
; // GTB Medusa -- Swapped Prometheus R turret for Prometheus S
; //========================================================================================================
$Name: GTB Medusa
+nocreate
$Subsystem: turret01a,5,1.0
$Alt Subsystem Name: Turret
$Default PBanks: ( "Prometheus S" ) ;; Stock: Prometheus R
Meanwhile, the Medusa entry in the ships.tbl file has all the stock parameters intact, with the only change being the Description text indicating the turret has been upgraded.[Edit] AdmiralRalwood made a good point below to just push all of your changes, no matter how small, into your own single
.tbm file. This is what I've switched to doing!
How do I know which docking point is which on the goddamn Arcadia?!tl;dr: The textures on the model itself actually identify the dock region pretty well! The dockpoint names largely match up to where you see the identification letter / number on the installation.
You can also get a definitive answer with
POFCS2. Not all models will spell out the names of the points on the texture, so you'll want to use a tool to be sure if you have more than a few and trial-and-error isn't your favorite way to spend 20 minutes.
The process: There are a **** ton of dockpoints on the Arcadia installation, and there are a lot on some bigger warships as well. Identifying which is which in FRED is often not possible if you aren't in the know. Fortunately, there is a tool that helps you do this!
POFCS2 is a model viewer for Freespace. You can export any model file, i.e.
.pof file, and load it up in there, then check out the dock points easily.
To export the model in question, you'll want to pull up the MediaVPs_2014 (or stock if you are not using the latest and greatest stuff for whatever reason) in
a VP tool. I've been using QuickVP for simple extraction operations, and it works a treat.
So, how exactly do you export a model and check its docking points?
- Open up your VP tool of choice
- Load up the MV_Assets.vp file from your MediaVPs_2014
- Go to the data >> models folder and find the model(s) you want to inspect
- Select and extract those files to a folder
- Open POFCS2
- Load the model
- Select "Docking Points"
- Select a given point in the sublist (click the [+] next to Docking Points), then find it on the model -- it'll be glowing yellow.
- There you have it! Screenshot: http://i.imgur.com/f5G7C7Z.png
Now you know exactly which point is which, no trial-and-error required. Huzzah!
Since creating a campaign file, a custom weapon is now reverting ingame the Subach HL-7. What???tl;dr: Your pilot file itself could be referencing outdated stuff! Clone or delete and recreate, and then this should clear up.
What I did: I had created a new custom weapon and preassigned it to the player ship in my first mission. It was working just fine! I later created a campaign file and added said mission to it. At this point, my custom weapon reverted to the Subach HL-7 for mysterious reasons.
I had ensured it was available in the campaign loadout and the mission loadout hadn't changed. Further, when I copied the mission file and played the copy in the tech room simulator, it worked just fine. It was strictly broken in the campaign-loaded version of the mission. Why?
The fix: I'm not 100% sure why this happened, but I do know what fixed it!
<MatthMcGeekFace> clear your pilot file
Boom. Turns out, if you had a pilot file for your mod-testing already set up before creating your campaign file, there's potential for Something To Go Wrong(TM) somewhere. Simply create a new pilot file, and then you should be set. If not, then you probably broke something else somewhere else!
I'm following this excellent custom Main Hall interface tutorial, yet none of my buttons are functional!tl;dr: Your mask is probably borked. If you did your color palette editing in Photoshop, your index probably is inverted. When you go to edit the color table, you get a grid of 256 cells. Counterintuitively, the grid is
ordered in reverse, meaning the first cell is for index 255 rather than index 0.
To fix, simply put your 255,255,255 color, 254,254,254 color, etc. in reverse order starting with the very last cell. Thanks Axem for the pro-tip on this one!
