Loadout Design

Handling ship subsystems is a bit tricky because Flux does not let POG see critical object properties (like x,y,z position) and the class type of the subsystem.

Flamineo wrote a subsystem handling layer when he created his Damage Mod that is both good code and the best documentation to date on subsim handling. He was trying to write a mod compatable with the old game. We have the luxury of being able to rename subsystems to fit our design (since we can read names, we can make name and INI file match for instance). We can also move INI files to known locations.

The largest problem for a loadout GUI is knowing where to place weapons. There are two approaches: The standard PS solution is to put mountpoints in the ship, and then loadout replaces these mountpoints with working subsystems. (and vice versa). The problem is that there is no POG function to do this replacement. The only subsim placing code must know x,y,z position and orientation. But there is no way to read this information (that I have discovered).

So that brings us to solution two, which is putting the mounting data into the ships INI file. I call this mounting data a "hardpoint" to make it clearly different from the Flux mountpoint.

Here is a small example. I have a document describing hardpoints in detail.

; Weapons template and null entries (just like normal).
template[7]=ini:/subsims/systems/nonplayer/nps_pbc
null[7]=fwd_pbc_hardpoint

;New Matching Hardpoints
hardpoint_type[7]=med_gun
hardpoint_loc[7]=(3,5,7)
hardpoint_orient[7]=(0,1,0)

Once the hardpoint design is selected, we need a way to get hardpoint data into the ship INI files. Rather than do this by hand, I had asked a forum member to write a Perl script to pull the data from the lightwave setup files. I can provide that script.

As far as how to structure a POG GUI for loadout, EricMan64 coded the most complete loadout as part of his Gold Rush mod. It is worth looking over. A more complex version (not recommeded until a simple button version is working) would put the buttons in x, y position over the image of a ship. Thus allowing the player to "place" objects on his just like the old game FreeSpace.

Saving and restoring subsims is easy, once the hardpoint data is attached to the subsim.

A Freespace mounting system would be very, very cool. Of course, that'd definitely be a ways down the road.

Cute part of EricMan's Gold Rush code:

I'll look into this and get back to you if I feel up to it. My grandmother recently passed away and I do have a mid-term exam and a few other things coming up, but after those things are resolved I should have some free time.

I'm guessing that the implementation here will be directly tying into the UniGUI system that appears when you're in a base, and not to the iLoadout code which is probably too intimately connected with Flux to be easy to overwrite completely. I suppose I'm at a bit of a disadvantage coming into the editing so late in I-War2's lifetime because I'm not aware of what's been done before and what hasn't.

_______________

It's my belief that these sheep are laborin' under the misapprehension that they're birds. Observe their behavior. Take for a start the sheeps' tendency to 'op about the field on their back legs. (off-screen baa-ing) Now witness their attempts to fly from tree to tree. Notice that they do not so much fly as...plummet.

Sorry to hear about your Grandmother.

Don't worry, you won't be left to drowned alone. Our target release for this feature is after Unstable Space, so don't feel rushed. I would rather not scare you off! We need more programming talent on this project.

Yes, the loadout would be done as a UniGUI screen. And it would be coded pretty much from the ground up, using only the lowest level POG libraries. Download the PS POG SDK if you have not already. The help files in there are invaluable.

I've written a couple POG scripts already, which pretty much necessitates having downloaded and interpreted the SDK.

I wrote a combat-sensitive music system for Torn Stars (basically patching-in music which starts up when you have hostiles on your contact list versus when you've actually opened fire or had someone shoot you, just like the original EoC). It works well enough, although after some time, for whatever reason, the music doesn't play any more.

I also wrote a random trades system for the default Edge of Chaos, but it looks like I lost the source code except for an early backup, so that's a kick in the nads. [edit]Ooh, found the most recent version. June 18th, as opposed to the start of June.[/edit] It was intended to give random commodity-for-commodity trades to the trade screen because I was always kinda sick how you had to get everything through direct piracy. In general, the mod would usually ask for a higher value cargo and giving a lesser-value cargo in return, although on somewhat rare occasions you'd get equal-value-for-equal-value, and on very rare occasions you'd get lower-value-for-higher value. The mod, incidentally, taught me a lot about the default cargo handling. I almost know enough about the guts to be able to create a "universal blueprint" cargo type from scratch which can be used to spend your manufacturing points to manufacture any other object in the game.

Anyway, neither of the mods worked perfectly, and I got disinterested in POG scripting before I got too far into debugging them. This was around June some time. I'll probably only really get back into it once Unstable Space hits the bandwidth-shelves.

_______________

It's my belief that these sheep are laborin' under the misapprehension that they're birds. Observe their behavior. Take for a start the sheeps' tendency to 'op about the field on their back legs. (off-screen baa-ing) Now witness their attempts to fly from tree to tree. Notice that they do not so much fly as...plummet.

I have noticed the same problem with Torn Stars' music. After some time it just doesn't play anymore. I suspect it is an issue with flux, and there may be no getting around it. You should make that sound mod available at the Torn Stars site, if you think it is good enough for others to play with.

GrandpaTrout and I are already itching to get on with all the features we have dreamed up for the next release. So we are trying to get Unstable Space into everyone's hands as soon as we can. But of course, we can't rush it. No sense putting something buggy and unfinished out. If you jump back into scripting at that time, you will be in good company

One of our major issues with subsims is that we don't always know the class of the subsim. This means we cannot always tell two types of subsims apart. And we don't know the template that created the subsim, so if we want to read properties out of the subsim file, we could not.

One of the more annoying examples is capsule drives. We have this wonderful new jump simulation, but no way to read the capsule drive strength out of the capsule drive subsim.

Until today.

Sometimes it takes years to see the obvious. All the subsim templates are in the ships template file. And we can read that file. So today I wrote a little bit of code that matches up the subsims on the ship with the template entries in the ships INI file.

Problem solved. This will give Damage Mod a boost. It will give us new ways to mod subsims. And it solves a major issue for changing the loadout of an existing ship. Specifically: What kind of cargo do you put back into the inventory when you pull a subsystem off a ship.

The only requirement to use this technique is that two different subsims cannot use the same name on the same ship at the same time. So you can't mount two different kinds of PBC's but call them the same name. Not an overly tough requirement.

It is a technique that also fails on the player ship, if the player ship was created by the standard games loadout. This is because the subsystems in the player ship template will not match the ship.