Slipstream Mod Manager v1.9.1 (2018-01-07)

[Vhati]

A large collage image? Where would that go?

Would it help if I mocked it up?

That would be helpful.

Keep in mind the description area is plaintext. There could be a hyperlink to show a popup, or the lower section of the main window could have a vertical divider with the image on the left, a row/column of little buttons below/beside the text area, etc., but the image can't be inserted among the text ( * in the technically possible but strongly discouraged sense).

It could just be done as a standard name and filetype, say thumbnail.png in the mod-appendix folder.

That's what I've got in mind. I'm just making sure I understand what you're suggesting for the GUI, that it'd generally be useful in practice, and that I can implement it well, before I get started.

But couldn't you say the same thing about the existing metadata? Why bother including text at all when you could just include only a link and have them go to that forum page?

*chuckle*
Before adding support for embedded xml, the mod manager's metadata feature was originally created because many authors weren't bothering to write basic information on their own threads, and what info there was was wildly inconsistent. I wrote/edited it all myself.

Have you ever used the captain's mod People pack or use a lot of ships?

*Looks at the CE People Pack*
*Sees 82 individual mods*

If you REALLY wanted to add a "power feature", you could support multiple "patch set" configurations which could be flipped between.

Hmmmm...

[jep]

*Looks at the CE People Pack*
*Sees 82 individual mods*

Exactly.

This is the extreme case (but it has to be that way so you can mix and match them however you want). But I would think it would be a bit similar if you added a bunch of custom ships.

I'll work more on the mockup a bit later when I get more time.

[RAD-82]

I'm really liking the <mod-append:...> feature. It's much nicer to append choices rather than completely replace events.

Wrong code example:

Code: Select all

<mod:findName type="event" name="START_BEACON">
  <mod-append:choice req="engines" lvl="1">
      <text>See stuff?</text>
        <event>
          <text>Free stuff!</text>
          <autoReward level="HIGH">augment</autoReward>
        </event>
    </choice>
    <choice req="engines" lvl="1" hidden="true">
      <text>Unknown?</text>
        <event>
          <text>Free stuff!</text>
          <autoReward level="HIGH">augment</autoReward>
        </event>
  </mod-append:choice>
</mod:findName>


Right code example:

Code: Select all

<mod:findName type="event" name="START_BEACON">
  <mod-append:choice req="engines" lvl="1">
      <text>See stuff?</text>
        <event>
          <text>Free stuff!</text>
          <autoReward level="HIGH">augment</autoReward>
        </event>
  </mod-append:choice>
  <mod-append:choice req="engines" lvl="1" hidden="true">
      <text>Unknown?</text>
        <event>
          <text>Free stuff!</text>
          <autoReward level="HIGH">augment</autoReward>
        </event>
  </mod-append:choice>
</mod:findName>


Even though it might be a little messier, I feel like that "wrong code example" should have worked. That append feature is stricter than what I expected. It looked like it creates an open tag and a close tag, including everything between them, but apparently it isn't that simple. Not really a problem...

[Vhati]

I'm really liking the <mod-append:...> feature. It's much nicer to append choices rather than completely replace events.

Glad to hear it.

That append feature is stricter than what I expected. It looked like it creates an open tag and a close tag, including everything between them, but apparently it isn't that simple. Not really a problem...

Under the hood, the meaning of the XML is interpreted as a tree of abstract elements (each element has attributes and a list of child elements, which in turn have their own). The tags you write, "<event>...</event>", represent the boundries of a single "event" element, containing a "text" element and an "autoReward" element.

The same happens with "<mod-append:choice>": it must be closed by an identical tag so the XML library understands where the element begins and ends. A plain "</choice>" will not close it.
.
.
Btw, I see you're editing START_BEACON in particular.

You may want to look at kartoFlane's "Universal Starting Beacon" framework (link) if you want your mod to play well with others.

[RAD-82]

Btw, I see you're editing START_BEACON in particular.

That was just a test for my dual choice appending, and also the hidden attribute, since I wasn't quite sure what that did. It answered both for me.

You may want to look at kartoFlane's "Universal Starting Beacon" framework (link) if you want your mod to play well with others.

I did a search on that USB framework, and it doesn't seem to be used much. I only found two ships that used it, one by kartoFlane and the other by me. I think that framework should be included in the SMM download like those beginning and engi scrap mods are, even though it isn't widely used yet.

My next mod is appending choices to most of the start and empty beacons for use with a custom weapon that will create missiles at these useless beacons.

If I append these choices to the START_GAME_CHOICES from the USB framework, does that force dependency on the USB framework, or can this particular append be ignored if the event is not found due to the user not using the USB?

<edit>
My question also implies that I have no idea what happens if an event can't be found. I have to do most of my modding work on a lesser computer that doesn't run the game and mainly use the better computer for Superluminal, which I don't always have access to, so I can't always test things myself right away.
</edit>

Extra info about my signature: My ship that I mentioned that already uses the USB framework is the one on the right in my signature, Frankenstein. The current ship I'm working on with the choices for the custom weapon that I'm asking about is that pirate Zoltan ship under the OUTLAW. It is the type B to the Enforcer (above LAW), a ship mod that 5thHorseman made for me back when I couldn't mod because I didn't have the game then.

[agigabyte]

Can you pack mods with this?

[kartoFlane]

If I append these choices to the START_GAME_CHOICES from the USB framework, does that force dependency on the USB framework, or can this particular append be ignored if the event is not found due to the user not using the USB?

Yes, it forces dependency on USB. When an event or blueprint can't be found, the game crashes.

Can you pack mods with this?

Nope. You have to pack stuff into a .zip yourself.

[Vhati]

Can you pack mods with this?

For distribution, no.
Archiver tools like 7-Zip make it trivially easy to select stuff, right-click, and "Add to Archive..." though.

But during development, power users can wield the command line to bypass zipping for themselves.

• Have "SMM/mods/MyExample/" containing img/, data/, etc folders.
• Bring up a command prompt (as admin to be able to patch, if necessary) and cd to Slipstream's dir.
• modman.exe --validate MyExample
• That folder will be treated for the moment as if it were an *.ftl.
• To repeat the test after quick edits, hitting up then enter in the prompt will run that command again and again.

[jep]

In the USB thread, I made a feature suggestion for SMM that would allow USB to be able to not have to be a standalone mod. Basically, I proposed an additional attribute invert="true" which could be added to findName (and findLike/findComposite, I suppose) to say "if the find failed, then do the following with the existing context node as the context node for the expression.

Well, just for grins, I took a whack at trying out my idea in the SMM code. I added the following code to XMLPatcher.java:handleModFind (line 125):

Code: Select all

List<Element> matchedNodes = new ArrayList<Element>( contextNode.getContent( searchFilter ) );

boolean invertSearch = getAttributeBooleanValue( node, "invert", false );
if ( invertSearch ) {
    if ( matchedNodes.size() == 0 ) {
        matchedNodes.add( contextNode );
    }
    else {
        matchedNodes.clear();
    }
}

if ( searchReverse ) Collections.reverse( matchedNodes );


The first and last lines are the original code just to give some context.

It uses my syntax proposed in the other thread, which I'm not in love with but might be fine. Basically, invert="true" says that if it does NOT find a match, then it should use the contextNode as the result. Here's an example:

Code: Select all

<mod:findName type="event" name="APPEND_TEST">
    <mod-append:event name="APPEND_TEST">
        <text>If #1 comes first, it will win!</text>
        <choice>
            <text>Continue...</text>
        </choice>
    </mod-append:event>

    <mod-append:event name="APPEND_TEST_FRIEND">
        <text>And here is #1's friend.</text>
    </mod-append>
</mod:findName>

<mod:findName type="event" name="APPEND_TEST" invert="true">
    <mod-append:event name="APPEND_TEST">
        <text>If #2 comes first, it will be the winner.</text>
        <choice>
            <text>Continue...</text>
        </choice>
    </mod-append:event>
   
    <mod-append:event name="APPEND_TEST_FRIEND">
        <text>And here is #2's friend.</text>
    </mod-append>
</mod:findName>


In this example, only the #1 APPEND_TEST will wind up getting added as a top level event. It would also add #1's APPEND_TEST_FRIEND. If you swapped the two arround, you'd get #2 and #2's friend. I tested this out with my code and it works like a charm.

This change would allow USB to turn into the following boilerplate code that you insert into your own events.xml.append (in addition to the existing USB sector_data.xml.append boilerplate):

Code: Select all

<!-- USB Boilerplate starts here -->
<mod:findName invert="true" type="event" name="START_GAME_BEACON">
    <mod-append:event name="START_GAME_BEACON">
        <choice>
            <text>Continue...</text>
            <event load="START_GAME_CHOICES" />
        </choice>
    </mod-append:event>

    <!-- Append your start game <choices> or optional actions to this event -->
    <mod-append:event name="START_GAME_CHOICES">
        <text>You are about to set out on your journey.</text>
    </mod-append:event>
</mod:findName>

<!-- My extension for my mod goes here -->
<mod:findName type="event" name="START_GAME_CHOICES">
  <mod-append:choice>
    <text>Go about your business</text>
    <event>
      <text>Suddenly, someone appears on your ship and demands to join your crew!</text>
      <crewMember amount="1" />
    </event>
  </mod-append:choice>
</mod:findName>


What do you think? I think it's cool not just for USB but for having other mods that can add stuff while still avoiding clobbering existing. And I think the change I proposed wouldn't break any old USB installations (as long as they had USB first like they were supposed to anyway).

[kartoFlane]

Interesting idea, I've been thinking about something similar sometime ago. But as you said yourself, USB would still have to be downloaded anyway to overwrite the starting sector (or the mod author would have to overwrite it themselves).