[MD][Dev] Xenon P Capture Raid

[skadoink]

Ok, so I'm relatively new to this, so excuse me if my netiquette is poor....

Abstract:
A set of Mission Director files to provide a mission arc that climaxes in a raid to capture a Xenon P

Current Status:
Chapter 5: working, 99% complete.


Overview:
Introduction
Without going into too much detail of my reasoning behind this, I wanted to create a fun but extensive mission arc, which allowed the capture of a Xenon P (and building of them if you have a Headquarters) in a fairly standard game. Yes I know there are various mods and scripts which allow them, I try to use as few scripts as possible (bonus pack and jump fix for me)

Anyway - without revealling too much about the plot line, there are six chapters, which can be categorised as:

Chapter 1. (The Rumour)

Chapter 2. (The Investigation)

Chapter 3. (The Escort)

Chapter 4. (The Preparations)

Chapter 5. (The Raid)

Chapter 6. (The Revenge)



Please feel free to leave comments, help or suggestions in this thread. If you choose to download and use it, be aware this is DEV status. It is not ready for release. I highly recommend NOT saving over any of your usual game saves.

If anyone does try it, please post the observed behaviour, and any comments you may have. Any feedback is much appreciated.

[skadoink]

Any current Challenges/Issues/Questions I may have regarding this project listed here

a) Balancing the 3rd convoy and the attack in Getsu Fune

b) been trying out <play_cinematic> and fade out & in's for polishing reasons, not actually got them to work yet - anyone have experience with these?

c) similarly, I'd like to show a warping effect when the player warps. Not seen any way of doing that yet - anyone have any ideas?

[skadoink]

Latest code: v0.63

Notes:
a) DEV VERSION - do NOT save over live savegame slots.
b) This chapter (5) of the mission arc, including various alternate outcomes is working.
c) This is intended to be for a player fighter, now enforced
d) Hint: Wrecks do not show up in the sector scan
e) Various aspects still remain for testing purposes. Like jumpdrives and free energy
f) As it's a dev/test version, various timers are set to trigger in minutes rather than hours, eg, retry after a failure.
g) Expect just under an hours play, start to finish, about 1.5 hrs game-time
h) I feel the 3rd convoy and the attack in Getsu Fune are not quite tough enough.... your thoughts?

Dowload from Filefront:
http://www.filefront.com/15128413/X3R_X ... _v0_63.zip

v0.63:
* A countdown occurs just before a mission initiated player warp (lifted from the MD manual)
* A temporary gate is created in the unknown sector to act as a reference spawn point
* Other small polishes

v0.62:
* FIX: Failure due to destruction of the unclaimed ship before capture now will trigger the delayed retry cue.
* Mission now deals with situation where player is pilotting prize ship on docking.

[Ketraar]

Have a break!

Before you now go and do all the code and stuff, you need to slow this one gear down and have a thought or two.

1. Use a XML editor which can read schema files. Everything else is just playing Russian roulette. Stuff like <cancel_cue name="SB_XenonP_Cap_ch5_p4a" /> would have come to your attention as they get underlined. (its cue= instead of name= )

2. Go over the Basics Manual again, and/or look up some other MD files to get an idea on how they are build up. As an example you have cue SB_XenonP_Cap_ch5_p1_check and SB_XenonP_Cap_ch5_p1 with similar conditions, so when you fly a fighter BOTH cues will trigger at exact same time.

3. Use t-file for Incoming messages, keeps the code smaller and they are easier to edit and translate if one would want to.

And last but not least, host the file with the code, keeps this topic cleaner.

MFG

Ketraar

[skadoink]

Well, that's one reason why it's unpolished.

One thing (for example) I would like to do at some point is make a bunch of library routines to make the code a little less unwieldy.

Wrt hosting the file, I don't have a site to do so - hence my hope that scroll-bars would be used for code tags.

At this point, I'm still learning the language and syntax - I only started this three days ago - for now I'm just focusing on getting the thing working with desired results. Future development can be a bit prettier, sure, but right now I learn more by doing and discovering.

Like I said in the previous, I will be going the VWD20008 route - sooner rather than later - but not right this second.

Well spotted on the cue<>name! Thanks for that!

The specific example SB_XenonP_Cap_ch5_p1_check you mention is part of the code dealing with the player turning up in something other than a fighter that I alluded to in (c) of the notes. The cue fires, the message displays, but for now (testing purposes) the cue does NOT fail the mission and allows the flow to go straight to SB_XenonP_Cap_ch5_p1 to deal with the rest of the mission. The difference in timing for those cues is deliberate.

[Xenon_Slayer]

Oh and a little message for Xenon_Slayer, if he's watching....

I've moved on from notepad - I'm now using Wordpad! yeah yeah! gimme time!

You poor guy

VWD has pointed out that you have two <position/> nodes in some <create_ship/> actions. Lines 129, 163 and 219. Creating SB_XenonP_Cap_ch5_Xm6_a, SB_XenonP_Cap_ch5_Xm6_b1 and SB_XenonP_Cap_ch5_Xm6_c1. I'm not sure what that would actually do in the game.

Code: Select all

<create_gate name="SB_XenonP_Cap_ch5_RaidTransitGate" gate="up" typename="up" race="argon" known="1" comment="destination is the Unknown Sector NW of Getsu Fune [y value is 25x1000(m)x500(MDfactor)]">
            <position x="0" y="12500000" z="0" />
            <sector sector="{sector.name@argonprime}" />
            <destination x="16" y="0" gate="east" />
          </create_gate>

'typename' is the code we give to objects to tell them apart. You've used them correctly for but this gate one is incorrect. It probably would default to the first on the list, probably SS_WG_NORTH.

Position values can have 'm' or 'km' units to make it easier for you. So I expect you want y="125km".

{sector.name@xxxx}" will return the text name of a sector. I expect you got this example from the html document. For this variable to work, you first need to find a sector with the MD. You can do the following:
<find_sector name="The Argon Prime Sector" x="1" y="3"/>
After you do that, {sector.name@The Argon Prime Sector} will return 'Argon Prime'. {sector.y@The Argon Prime Sector} will return 3.

The ".name" variables are only useful for the players to see as it is pure text. The MD needs 'Object IDs', the internal code given to every object in the universe. For example, {sector@The Argon Prime Sector} would return the object ID, something like -352. The same can be said for Actors and other objects (ships, stations, asteroids e.t.c) with their own {actor@ and {object@ variables.

The MD can be clever in some cases to save on typing. Let's use the create object code as an example.
<create_object..............blah>
<sector/>
</create_object>

In the sector node, you can use several things such as:
<sector sector="{player.sector}"/> (The players current sector)
<sector sector="{object.sector@That Ship}"/> (A MD saved objects current sector)
<sector sector="{sector@The Argon Prime Sector}"/> (A MD saved sector though a variable)
<sector sector="The Argon Prime Sector"/> (A MD saved sector name)
<sector x="1" y="3"/> (co-ordinates)

Err, yeah. There are several more variations and combinations you can use. It all really depends on the situation. All these options usually annoy real programmers who are used to only one way to getting a piece of data. We're spoilt.

Anyway, back on track. The cue 'SB_XenonP_Cap_ch5_p1' could probably do with <match_object object="{player.ship}" class="fighter"/>. That way it won't trigger when the player enters in a non-fighter ship.

<Create_xxx/> class attributes are no longer needed as the typename does this automatically. So things such as class="m4" can be safely removed. They are still useful on things such as find_object and match_object.

If you are doing something many times, you can use <do_all/> to loop. A good example is in some of your create_ship actions where you add many ships to a group.

Code: Select all

<do_all exact="5">
  <create_ship group="Xenon Group" ....blah...>
      blah
  </create_ship>
</do_all>

If you want one special ship, such as a leader, either create one extra ship outside of the loop or use something like:
<set_group_leader group="XenonGroup" object="{group.object.random@XenonGroup}"/>

I'm gonna head off to code some MD myself, but I'll take another look later. Hope that stuff is useful to you.

Owen

[skadoink]

Heyas! 1stly, thanks for posting.

VWD has pointed out that you have two <position/> nodes in some <create_ship/> actions. Lines 129, 163 and 219. Creating SB_XenonP_Cap_ch5_Xm6_a, SB_XenonP_Cap_ch5_Xm6_b1 and SB_XenonP_Cap_ch5_Xm6_c1. I'm not sure what that would actually do in the game.

Hmm, the offending code is:

Code: Select all

	 
<create_ship name="SB_XenonP_Cap_ch5_Xm6_b1" group="SB_XenonP_Cap_Ch5_Xm6_Convoy2" class="m6" race="xenon" racelogic="0" typename="SS_SH_X_M6" capturable="1" leader="1" >
    <position x="-22km" y="-12km" z="0" />
    <equipment loadout="default" />
    <command command="moveposition">
        <sector x="17" y="0" />
        <position x="0" y="0" z="0" />
    </command>
</create_ship>

I assume the message refers to the two position nodes here, but as one is in the command node I'm guessing no problem? certainly none in testing.

'typename' is the code we give to objects to tell them apart. You've used them correctly for but this gate one is incorrect. It probably would default to the first on the list, probably SS_WG_NORTH.

so I'm guessing SS_WG_UP is the way to go - I'll try it in a moment. Incidentally, if you could point me in the direction of a reference listing typenames and what they are.... that'll be awesome.

Position values can have 'm' or 'km' units to make it easier for you. So I expect you want y="125km".

I knew I left that one in.... ok ok - I'll kill it!

/snip Err, yeah. There are several more variations and combinations you can use. It all really depends on the situation. All these options usually annoy real programmers who are used to only one way to getting a piece of data. We're spoilt.

Actually, most of that makes perfect sense - just a question of getting used to it. Thanks for the petit-seminar

Anyway, back on track. The cue 'SB_XenonP_Cap_ch5_p1' could probably do with <match_object object="{player.ship}" class="fighter"/>. That way it won't trigger when the player enters in a non-fighter ship.

In that version (0.50) it was infact deliberate for testing purposes. I wanted to check the message and cue triggered, yet still carry on with the mission when I turned up in a m6 and blasted Xenon into teeny bits. In the latest version (0.60) I've made it as live would be, and disabled 'SB_XenonP_Cap_ch5_p1' in the check cue, allowing the flow to go straight to the failure sequence. Functionally it's the same, but whether it has a performance impact in the way MD works behind the scenes, I'm not qualified to judge.

<Create_xxx/> class attributes are no longer needed as the typename does this automatically. So things such as class="m4" can be safely removed. They are still useful on things such as find_object and match_object.

I thought that may be the case - just saw it in the examples and did the same. Thanks.

If you are doing something many times, you can use <do_all/> to loop. A good example is in some of your create_ship actions where you add many ships to a group.

Code: Select all

<do_all exact="5">
  <create_ship group="Xenon Group" ....blah...>
      blah
  </create_ship>
</do_all>

If you want one special ship, such as a leader, either create one extra ship outside of the loop or use something like:
<set_group_leader group="XenonGroup" object="{group.object.random@XenonGroup}"/>

Once I got it working I was going to go back and 'prettify' it by using library cues and the such, and this gives me some big clues for it. Particularly that last bit. Way better than what I was considering... Sweet!

I'm gonna head off to code some MD myself, but I'll take another look later. Hope that stuff is useful to you.

Owen

It is. Thanks. .

A main thing I haven't yet done is to deal with capital ships that stray too close to the captured prize. The psuedo code I have for it right now is:

Code: Select all

<!-- when prize enters Xenon 534, create a group of all Xenon capital ships in sector. -->

<!-- when a member of that group enters within 20km of prize, give it orders:none, or orders:move (0,0,40), maybe turn racelogic=0 would suffice. In any event, we must ensure that we can reverse it in cleanup and allow Xenon capital ships to be nasty again. -->

It'll probably be next on the list of things todo, and get looked at and investigated over the weekend. Speaking of which - have a good one!

[skadoink]

RATS!! SS_WG_UP wasn't it. Or at least it didn't work....

Incidentally, regarding the addtion of the 'fighter' condition. I think I may have finally realised what you're getting at. Functionally, it may work without, but it would still be the case the the trigger conditions for both cues are satisfied at the same time on entry to the sector. So the main sequence cue starts, but the functional code is delayed by the timing, so that nothing actually happens before the main sequence cue is cancelled by the check cue. Not necessarily best-practice. Probably best to ensure one fires, or the other, not both (even if the 2nd will never actually get run)......

...... Or have I totally missed it..... lol, ah well - next time!

[Xenon_Slayer]

You are correct about the extra <position/> nodes. I didn't see that they were in the command node. VWD sometimes shows nodes as incorrect if they are placed in a strange order. For some reason, it doesn't like <position> below <sector>. It doesn't make any difference in game though.

As for the gate typename, no, we don't have _UP or _DOWN typename variations. Sorry, I should have explained that better. I would suggest using the SS_WG_NORTH. The only problems with that is that it will be rotated in the North direction, instead of what 'Up' should be like (pointing down). Also, it will have the 'N' map icon.
The rotation problem can be solved with the <rotation alpha="" beta="" gamma=""/> node. This can accept things such as beta="180deg". TBH, I'm not sure what would be best for your situation. I would expect beta="90deg". For other typenames, Visual Web Developer will give you a list.

As for your TODO code keeping ships away. You'll need some things which probably are not in the document, which is pretty old.
One thing is the 'delay' attribute. This is the time interval in between condition checks. This is mainly used in the polishing phase to improve performance, but no harm in doing it now. You can only use it is on value checking conditions such as <object_position/>, <check_value/> or <object_is_docked/>. These are not based on events such as <object_docked/>, <object_changed_sector/> or <object_destroyed/>. An example would be:

Code: Select all

<cue name="Position Check" delay="5s">
  <object_position....blah/>
</cue>

This condition will only be checked every 5 seconds. As distance checks can be expensive, it may help performance. Especially if the objects are several sectors apart.
Again, be careful not to include that with event conditions. An event will only happen for a split second, so you may miss it. Unfortunately, events are not really split up from other events so you'll need to find out which are which. Again, the VWD will give you extra info for each condition.

[skadoink]

Ok, the xml for v0.61 is now above.

I tried the <rotation> thing, but no joy. Is it TC only?

Regarding the 'keep capital ships away' TODO, I spent some time on it trying the method I mention above, and although I kinda got it working, I realised it would be very clunky, so tried a different approach.

In the following, we have an initial cue which essentially just lets the main cue start working. The main cue is set to execute every 20s for an hour or so (yuk!) and just finds the nearest capital ship within 20k of the prize. If it finds one, it warps it away. As soon as the flow gets to the next sector (or indeed in cleanup for whatever reason) we <cancel_cue> the polling cue (not shown).

Code: Select all

<!-- Some additional subcues to warp capital ships away if they get within scan range in Xenon 534 -->
            <cue name="SB_XenonP_Cap_ch5_GetXenonCapShips" comment="detects we're in Xenon 534 so that the next cue can start polling for nearby capital ships">
              <condition>
                <check_all comment="do when prize enters Xenon 534" >
                  <object_changed_sector object="SB_XenonP_Cap_Xm6prize" />
		      <object_sector object="SB_XenonP_Cap_Xm6prize" exact="0">
		        <sector x="17" y="0" />
		      </object_sector>
                </check_all>
              </condition>
              <timing>
              </timing>
              <action>
                <do_all>
                </do_all>
              </action>
              <cues>
                <cue name="XenonGetsNearV2" comment="polls every 20s to see if there's a xenon capital ship within 20km of the prize, if so, it warps it away to the other side of the sector">
                  <condition>
                    <check_all>
                      <cue_is_complete cue="SB_XenonP_Cap_ch5_GetXenonCapShips" />
	                <object_sector object="SB_XenonP_Cap_Xm6prize" exact="0">
	                  <sector x="17" y="0" />
	                </object_sector>
                    </check_all>
                  </condition>
                  <timing>
	              <count exact="240" />
                    <time exact="5s" />
                    <interval exact="20s" />
                  </timing>
                  <action>
                    <do_all>
                      <remove_object object="ClosestShip" />
                      <find_ship name="ClosestShip" nearest="1" class="m2" race="xenon" >
                        <position object="SB_XenonP_Cap_Xm6prize" />
                        <sector x="17" y="0" />
                        <distance max="20km" />
                      </find_ship>
                      <do_if value="{object.exists@ClosestShip}" exact="1">
                        <warp_object object="ClosestShip">
                          <position x="0" y="0" z="30km" min="1km" max="10km" />
                        </warp_object>
                        <play_subtitles text="Found {object.name@ClosestShip}..." />
                      </do_if>

                      <remove_object object="ClosestShip" />
                      <find_ship name="ClosestShip" nearest="1" class="m1" race="xenon" >
                        <position object="SB_XenonP_Cap_Xm6prize" />
                        <sector x="17" y="0" />
                        <distance max="20km" />
                      </find_ship>
                      <do_if value="{object.exists@ClosestShip}" exact="1">
                        <warp_object object="ClosestShip">
                          <position x="0" y="0" z="30km" min="1km" max="10km" />
                        </warp_object>
                        <play_subtitles text="Found {object.name@ClosestShip}..." />
                      </do_if>
                    </do_all>
                  </action>
                </cue>

              </cues>
            </cue>
<!-- End of 'deal with nearby capital ships in Xenon 534' sequence.... -->

PS I'll remember the delay thing - I'm sure it'll be useful another time...

Anyway - v 0.61 seems pretty stable, and is essentially complete from a functionality point of view (it cleans up after itself on success/failure, and allows retries upon failure)

However, it is still development/test status. The most apparent is that certain 'consequence' cues (like a retry) happen within minutes rather than hours, and jumpdrives/energy is still available on the prize.

It would be great if anyone would like to give it a go (as I said before, don't save over your 'live' games!) and give me feedback. particularly on the 3rd convoy difficulty, and the attack wave in Getsu Fune. I'm thinking they're too easy now - but since I've played this mission out umpteen times... /shrug I want them to be hard, but possible without wingmen.

To help with testing, I use a custom start and then use this MD to give me a decent fighter:

Code: Select all

<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet href="director.xsl" type="text/xsl" ?>
<director name="test" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="director.xsd">
  <documentation>
    <author name="SB" alias="skadoink" contact="" />
    <content reference="SB_Init4Test" name="Init4Test" description="Gives upgrades to allow more testing of other content - intended for a start game" />
    <version number="0.0" date="today" status="tool" />
  </documentation>
  <cues>
    <cue name="SB_Init4Test">
      <condition>
	  <check_all>
          <check_age value="{player.age}" min="5s" />
	  </check_all>
      </condition>
      <action>
	  <do_all>
          <incoming_message text="Your new ship is nearby, and fully loaded - Enjoy!" />
	    <reward_player>
		<money exact="250000" />
		<notoriety>
		  <relation race="argon" exact="10000" />
		</notoriety>
		<property>
		  <ship name="this.NewShip" class="m3" typename="SS_SH_S_M3_2" capturable="1" highlight="1">
		    <position exact="4km" object="{player.dockobject}"/>
                <equipment loadout="maximum">
			<ware typename="SS_WARE_TECH213" exact="15" />
			<ware typename="SS_WARE_TECH246" exact="15" />
			<ware typename="SS_WARE_TECH251" exact="100" />
			<ware typename="SS_WARE_TECH209" exact="30" />
			<ware typename="SS_WARE_WARPING" exact="1" />
			<ware typename="SS_WARE_SW_NAV_1" exact="1" />
			<ware typename="SS_WARE_SW_FIGHT_1" exact="1" />
			<ware typename="SS_WARE_SW_FIGHT_2" exact="1" />
		    </equipment>
		    <cargo>
			<ware typename="SS_LASER_PR_BETA" exact="4" />
			<ware typename="SS_LASER_LS_BETA" exact="2" />
			<ware typename="SS_WARE_ENERGY" exact="100" critical="1" />
		    </cargo>
		  </ship>
		  <stationary class="advancedsatellite" known="1">
		    <position x="0" y="0" z="0" />
		  </stationary>
		</property>
	    </reward_player>
	  </do_all>
      </action>
    </cue>
  </cues>
</director>

The above MD is free for anyone to use for whatever purposes whatsoever. Anyway - like I say, any feedback much appreciated - have fun!

[skadoink]

version 0.62 has been uploaded - post #3 above for download link and notes.

[Xenon_Slayer]

Doh, sorry. I keep forgetting where I am. Yes, the rotation node is in TC only, as are 'delays' I described above.

[skadoink]

Doh, sorry. I keep forgetting where I am.....

hehehe, it happens..... usually due to beer....

Ok, 0.63 should be up soon, it's really just a little more polish rather than anything else. And that'll be it I'm afraid for a little while: I'm on the road for a few weeks, and although I may write stuff, I'll have no way of testing.

As always, feedback and suggestions always welcome....

[skadoink]

Ok, Version 0.63 has been uploaded - post #3 above for download link and notes.

At this stage, I'm keeping the development tags on it, if nothing else as the other chapters have not been written yet, and will need to be integrated together. Having said that. It's a long time since I've come up with anything critical in testing. As always - I am still recommending that any live saves are not overwritten.

Personally, I've enjoyed the mission runs, although I know them a little too well now. Some interesting battles, some less so. About the best one was, when in the middle of fighting a Xenon attack wave, someone's hornet missile destroyed an asteroid, flying rocks everywhere, at the same time a regular wave of Xenon M & Ns came by and joined in. Fun!

As mentioned, I'm on the road for the next few weeks; but what I'm intending to do is draft some of the other chapters, and I will be keeping an eye on this thread. So any feedback or results will be noted.

Btw, I finally got VWD2008 a couple of days ago! Certainly makes things a little easier. Ah well! Back to wordpad soon!

*edit* One question: are MD files 'forward compatible'? ie, do X3R MD files work in X3TC? I know the opposite is not the case.

[Stu Austin]

*edit* One question: are MD files 'forward compatible'? ie, do X3R MD files work in X3TC? I know the opposite is not the case.

Yes. All I had to do was test them and change some things around in them to bring them up to TC standards.

[skadoink]

Ok, firstly, many apologies on the lack of activity for the past few months.

I was expecting to be away for a matter of a few weeks, and it turned into something a little longer. As is usual when this happens, when I got back ten million things were crying out for attention and good intentions turn into vaporware.

At this point, I only have about two million things on my list, so things are improving. But realistically, scripting MD is not on the horizon for quite some time. In addition to that, it did not seem that there was much interest in it anyway, at least for X3:R.

In the meantime, the file is available for anyone to download and use, and I will occasionally check back to this thread for any comments on it, but no more development is likely for a long time.

http://www.filefront.com/15128413/X3R_X ... _v0_63.zip

Finally, I would like to thank those who did make comments or suggestions - One of the primary reasons for me to do this was to learn the system. I learned a lot, and enjoyed it too! Maybe by the time things calm down round here I'll have a new PC and be able to run X3:TC - you may see more from me then.

Till then, Have Fun Everyone!

Skadoink

[rkrisher]

Link on the prior post is no longer working. While it seems some have moved on to X3:TC, not all of us have or some have moved back. Some of us use the linux version of X3 for which there is no TC port. And while TC works in wine better than in windows, it's over-bloated with too many scripts and makes it chunky. It gets worse as you expand your universe. We can't always rush out and get a new PC that can handle the computational requirements of additional scripts and a bigger universe. The x universe is slowwww to navigate and I've been playing the game for years before I'm finally at the point I want to learn how to do more with this game. Without the addition of other authors missions, like yours, the game starts to become humdrum. Please re-post your files for us leftover gypsies of the X3 Reunion/XTM universe!!