[Script] TerraCorps Fleet Package

The place to discuss scripting and game modifications for X³: Reunion.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

dmichailcz
Posts: 170
Joined: Thu, 18. Jun 09, 13:18

Post by dmichailcz » Thu, 25. Jun 09, 16:07

I've just bought TC (couple of days ago) - does TerraCorp script exist in TC?
I am not very good in english, so please, forgive me...

eladan
Posts: 7168
Joined: Sat, 7. Jan 06, 16:01
x4

Post by eladan » Thu, 25. Jun 09, 16:27

It's been ported across by BlackRain, though it's not complete. Thread is here. He suggests that CODEA would be better though.

Mahijiru
Posts: 17
Joined: Mon, 24. Oct 05, 09:29
x3

Post by Mahijiru » Thu, 25. Jun 09, 16:55

eladan wrote: Drafts for which? The patrol scripts are essentially finished - what RRRoamer was doing was integrating them into the current version - which still requires some work, as the scripts work a little differently than the current ones. I have various completed or partly done work on various other scripts scattered all over the place. The FBC is essentially finished, having been redone as an AL plugin. It's not a complete rewrite, mind, just changes the bits that required being run on the station. Incidentally, I believe that would fix the FBC stopping problem. Other bits here and there aren't in any decent shape.

If you're asking about the code for running the combat script full time, I haven't done anything on that. The problem I had is that it needs to run with, and gracefully handle, other combat-type commands running. E.g. if you have a cpilot on a ship that you have set as a wingman, with a "protect my ship" order, you don't want the cpilot script taking over and having the ship hare halfway across the sector to attack a ship which is no threat to yours... This is a surprisingly difficult issue to find a solution for without hardcoding specific exceptions, which I really, really want to avoid.
Actually I meant the code for running combat script full time when I asked for drafts. Well, when outlining what had to be done (at least theoretically) and thinking about that A probably calls for B which calls for C I got to know my limitations and tried the easy way. It was worth a try...
About the patrol scripts: Do I get it right, there are newer scripts which are NOT part of the package v. 1.53e? If so, are they available? :wink:

Well, you said already that there are no further plans for TCP. Not even integrating the essentially finished FBC AL-plugin? Hey, that would squash this well hidden bug definitely. Please forgive my tenacity but I have to try. I could even throw in an expanded 8070 t-file, now with 800 last names and 200 first names. I got annoyed with the third Cdt. Queenie Yuan and my last business trip was mostly a chronology of delays.

To anyone interested: In the German X2-forum - http://forum.egosoft.com/viewtopic.php?t=244459 - I found a tool which improves the readability of the 8069.txt-file (list of cpilots) significantly. In my game I added the trait info to the logfile and this tool enables me to retrieve this info without getting headaches.

eladan
Posts: 7168
Joined: Sat, 7. Jan 06, 16:01
x4

Post by eladan » Fri, 26. Jun 09, 02:55

Mahijiru wrote:About the patrol scripts: Do I get it right, there are newer scripts which are NOT part of the package v. 1.53e? If so, are they available? :wink:
Yes, there are newer scripts. I was sick of the fact that there were four different patrol scripts, and also wanted to make them a bit more flexible, to allow, e.g., >3 ships in a patrol and multi sector patrols possible. They're available in the sense that I don't have any problem with giving them to anyone. But as I said, they do things slightly differently than the current patrol scripts, and there's other code in various places which would need to be rewritten to make the new script work. Again, RRRoamer had been working on it, but RL got 'im.
Well, you said already that there are no further plans for TCP. Not even integrating the essentially finished FBC AL-plugin? Hey, that would squash this well hidden bug definitely. Please forgive my tenacity but I have to try.
You're forgiven. :) Since people have got me thinking about it, I'll have another look at things. At this stage, I won't promise anything (I hate disappointment too!) but if I get the bug again, I'll see what I can do.
I could even throw in an expanded 8070 t-file, now with 800 last names and 200 first names. I got annoyed with the third Cdt. Queenie Yuan and my last business trip was mostly a chronology of delays.
I'll see your 200/800 and raise you ~5000/4000. Yes, I got sick of the same names appearing as well, and expanded it to (IIRC) about 5000 names for each. Sorry... :)
I found a tool which improves the readability of the 8069.txt-file (list of cpilots) significantly. In my game I added the trait info to the logfile and this tool enables me to retrieve this info without getting headaches.
Terrific! Thanks, I'll have to take a look at that.

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Tue, 7. Jul 09, 15:22

Hi all, I'm back. Sorry for dropping out like that, but I got hit hard with some RL troubles and I had to stop playing X3 for a long time.

I see you got a new update out with those AL files for the FBC. I vaguely remember trying to work on something, but I haven't been able to find all my changes yet. I'll see about trying to merge your new stuff into my setup and see what happens.

I don't know if anyone else was trying this, but I did just recently make up a new callsign script, though. This one seems to work better than my last one, but you need to use a little imagination to get anything out of it. Since there's so little space available in the ship names, I cut it down to size to just letters/numbers in an ascending pattern for each new patrol, with alternate patterns for different types of patrols (scouts, escorts, regular). So it looks a bit like "(x:y:z)" where x, y, & z are alphanumeric. My patrols come up like "(A:2:E)", representing (if using NATO codes again), Alpha-Two-Echo, and so on.

It's easy to edit if you want something different, and only requires a small local variable on the homebase to manage the numbering sequence. (which rolls over when you hit the top for a particular coding type). At present, I'm trying out number-letter-number for scouts, letter-number-number for escorts and letter-number-letter for regular patrols.

With potential for 1000's of combos, I'm not going to worry about trying to maintain a database on the TF/FBC leader of what's in use, just increment things and let nature take its course as patrols cycle through.

I also remember trying to look over the FBC code, but my neck and eyes are killing me these days so I don't know how much I can get done right away. I still need to find my original files and figure out what I was trying to do last time I was in here.

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Tue, 7. Jul 09, 20:22

Has anyone done anythiong different with the ship naming script (as we once were talking about), and/or the movepilot scripts? I've been using my own ship naming script to auto-name everything with nice colors, but I don't know what the end result was on this with other people working on it at the same time.

Also, I just installed the new 1.53e upgrade (accidentally wrote over some of my own stuff in the process, so need to fix that), and see much is still the same with obsolete files and dups all over the place. Looks like it's time to roll up the sleeves again. :)

eladan
Posts: 7168
Joined: Sat, 7. Jan 06, 16:01
x4

Post by eladan » Wed, 8. Jul 09, 02:42

jumbled wrote:Has anyone done anythiong different with the ship naming script (as we once were talking about), and/or the movepilot scripts?
Since when?

I don't think there have been any major changes to either since your gender code was added though.
Also, I just installed the new 1.53e upgrade (accidentally wrote over some of my own stuff in the process, so need to fix that), and see much is still the same with obsolete files and dups all over the place. Looks like it's time to roll up the sleeves again. :)
Yes, the package is a mess. :)

dminor
Posts: 1083
Joined: Sun, 14. Oct 07, 00:16
x3tc

Post by dminor » Wed, 8. Jul 09, 09:16

Welcome back Jumbled. Now if we could just coax RRRoomer out of the wood work. :roll:
" I'm a Sexy Shoeless GOD of WAR " Belkar

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Wed, 8. Jul 09, 15:43

dminor wrote:Welcome back Jumbled. Now if we could just coax RRRoomer out of the wood work. :roll:
Yeah, I was kinda hoping to see his great new patrol script by now. Oh well...

As for my shipname script, I recall last time I was in here that he was also mentioning something he was working on, too. But since he's not been on for so long, maybe nothing new has happened in that area. We were also talking about call signs at one time. After installing 1.53e, I'm checking what I've done to mine recently, to make sure it works, and may have something stable soon. I'm going to take a quick look at the movepilot scripts next for the FBC and manual cmd modes.

I have noticed several places where the plugin.cpilot.shiptype is called by the FBC (haven't looked very far outside that area yet), and see where the tests are looking for conditions that simply aren't going to return values since that one script only tests for the (now obsolete) Discovery bug and returns M5 if it is. I might replace that file with my more-complete shiptype file that tests for everything and returns values. I've been replacing the calls to it in some scripts, but the more scripts I find with calls, the more I think it needs to go into the plugin file rather than my original fighter.base file.

I've also noticed in the FBC automate file some strange lines that I still haven't figured out what they're supposed to be doing... But I've seen some strange behavior in my FBC lately, so it could be an indication of an unfortunate illness. I think my fighter base commander needs a new neural chip implant or two. :)

dminor
Posts: 1083
Joined: Sun, 14. Oct 07, 00:16
x3tc

Post by dminor » Wed, 8. Jul 09, 23:59

Good to hear. I'll reinstall XR when your close to releasing to help test. As for the rolling R he poped his head up around chrismas and said he might have some time June July if RL didn't get a hold of him again.
" I'm a Sexy Shoeless GOD of WAR " Belkar

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Fri, 10. Jul 09, 16:19

From a scripting point of view, what differences are there between X3:R and X3:TC? I see a whole new forum with selections of scripts that have been "ported over", and just wondering if things are so different that older X3:R scripts might not work any more.

Back to my FBC updates, I've pulled the FBC "move pilot" script and the manual version (which is also used by the TF leader) into one script, changing the FBC file into something resembling a shell. I'm now using ONE file to do the pilot moves with shells for the three options of how you enter it (manual, FBC and the TF with it's own method, which I'm thinking of taking a whack at to clean up a bit).

I've also cleaned up several other FBC files, adding comments and generally tidying things up to make them easier to read. I'm collecting a set of updates to send off once I finish some part of this and test it out, so Eladan can review and include it as part of the next release.

I'm also officially retiring the files fighter.base.get.rank and fighter.base.subcode.lookup. I can't see any use for either of them, especially the subcode lookup file (and also the code in the setup file for the same purpose) since the only place I've seen anything look to check ship type was plugin.cpilot.shipclass, which, itself, is obsolete since it only checks the old Discovery bug, which (by now) should be ancient history. Unless there's something I'm missing, I'm replacing all such calls with a simple "x = ship -> get object class" which should be sufficient.

A passing thought... When installing/replacing stuff using Cycrow's Plugin Manager, if you install "on top of" an older set, does it remove the older file set before replacing with the new ones? Specifically, if you remove certain files from a release, do they get removed from older installs so as not to have a lot of orphaned files left behind?

One other thing I need some clarification on...

Between the main movepilot and the FBC movepilot scripts, there's a section some ways down setting the ship command signal for COMMAND_CPILOT_TF to "global default behavior". The FBC file uses it, but the manual/TF file has it commented out. What does it actually do? I see the menu cmd in either case on all my cpilot ships (in and out of the FBC, though that doesn't mean the FBC is working properly). The only difference is the ships inside the FBC complain about rank and ignore the use of the command whereas others will either complain about rank or about already being in a TF.

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Sun, 12. Jul 09, 00:12

Eladan,

Since I haven't heard from you on the last few Q's, I thought I'd throw a few more on top of you. :)

I'm dipping my hands into almost everything over here to restructure and comment all these files so someone can actually read them. I'm working on a set of the TF files and so far have re-made the TF.addtoo, addtoo.carrier and TF.disband (fixing a few problems I saw along the way).

You have another TF.addtoo here that says "Dont use" in the filename... Any reason why it's in here and why we shouldn't use it? The only thing I see different here is, in the file we're using, you do NOT reset homebases on ships with pre-existing ones (which bombs if you tell them to "go home", and they're hb'd at a station or other carrier), whereas the "dont use" file would set homebases to the TF leader regardless (which makes much more sense to me).

Which way are we supposed to be leaning (my vote is to set homebases on everything that can have a homebase set, so the TF knows who belongs to it)?

And one other thing that's bugging me. When I try giving the commands "ship -> set destination..." and "ship -> set command..." while using the movepilot command manually (menu option), I see the second ship set the values, but the issuing ship (the one I'm giving the command to), only sets the destination param, not the command when I look in the properties display.

Only if I set the command description indirectly (i.e. through a different ship or a manually run script), will it show up in the ship properties window, but not, apparently, in the same ship issuing the command, even if the process starts another task that calls it. Is this a bug or just a really annoying "feature"?

I'm making a conditional section out of the movepilot "transfer wares" code, which (later) I may try to put into a config menu. I've also included some lines to support the FCS MK3 code that Erilaz made, and the GAIUS docking computer (if you have either installed), plus moving the XTM shields (need to test all this, but it's in there). It just seems like we're getting a lot of "add-ons" and it makes more sense to include stuff in the core code with the option to select on/off modes for it.

eladan
Posts: 7168
Joined: Sat, 7. Jan 06, 16:01
x4

Post by eladan » Sun, 12. Jul 09, 03:13

jumbled wrote:Since I haven't heard from you on the last few Q's, I thought I'd throw a few more on top of you. :)
Sorry mate :) To give you the response you needed, I'd have to go over the code again, which I just haven't been able to do lately. If you bear with me, I'll try to do so soon.

I'll answer what I currently can, and hopefully that will be of some help.
Which way are we supposed to be leaning (my vote is to set homebases on everything that can have a homebase set, so the TF knows who belongs to it)?
Ideally, yes. It may cause issues, however, that not all TFs will allow you to assign a homebase to your ships. So if you rely on homebase settings, it can come unstuck.
And one other thing that's bugging me. When I try giving the commands "ship -> set destination..." and "ship -> set command..." while using the movepilot command manually (menu option), I see the second ship set the values, but the issuing ship (the one I'm giving the command to), only sets the destination param, not the command when I look in the properties display.
Can't immediately think what the issue might be there. Might be a good question to ask the general community, since it's not specifically a TFP issue.
It just seems like we're getting a lot of "add-ons" and it makes more sense to include stuff in the core code with the option to select on/off modes for it.
On/Off is fine, but I'd prefer that it was also smart enough to know the situations when the addons aren't needed, and turns them off in those situations, rather than relying on the player.
From a scripting point of view, what differences are there between X3:R and X3:TC? I see a whole new forum with selections of scripts that have been "ported over", and just wondering if things are so different that older X3:R scripts might not work any more.
There aren't too many differences, but the ones there are can be a bit painful. I haven't done much scripting in TC as of yet, but the differences, and how they would relate to TFP, would be as follows, as I understand it:

- No BBS. So the code I added for hiring an experienced CP at startup becomes useless (and breaks the package.)
- Colours are no longer \033 codes, but [red][/red] [green[/green] etc. However, the worst bit is, that messages containing colour codes will result in a blank entry in the message log.
- Fairly minor, but t file names have changed. Rather than 448069.xml, they are now L044-8069.xml (I think that's right.)

BlackRain has already ported it across, and has dealt as well as he could with those issues. There are other issues that I'd be wondering about as well though, such as the Egosoft code that is called by the package for things such as fightskill determination, which may have changed since Reunion.
A passing thought... When installing/replacing stuff using Cycrow's Plugin Manager, if you install "on top of" an older set, does it remove the older file set before replacing with the new ones? Specifically, if you remove certain files from a release, do they get removed from older installs so as not to have a lot of orphaned files left behind?
I don't *think* it removes any that aren't replaced. I seem to recall an issue where a file wasn't included in a release, and when people upgraded, it used the old file... Best, and fairly easy to do, would be just check it. :)

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Mon, 13. Jul 09, 02:56

Eladan wrote:
Which way are we supposed to be leaning (my vote is to set homebases on everything that can have a homebase set, so the TF knows who belongs to it)?
Ideally, yes. It may cause issues, however, that not all TFs will allow you to assign a homebase to your ships. So if you rely on homebase settings, it can come unstuck.
As far as I can tell, M6 and above can allow smaller ships to homebase with them. Fighters cannot accept homebasing, but I believe there is still some code in there to cover the occasion of "no homebase", and give an alternate action, like COMMAND_PROTECT or COMMAND_ATTACK_NEAREST. I'll just have to make sure this is in there and it covers the situation.
And one other thing that's bugging me. When I try giving the commands "ship -> set destination..." and "ship -> set command..." while using the movepilot command manually (menu option)...
Can't immediately think what the issue might be there. Might be a good question to ask the general community, since it's not specifically a TFP issue.
I found another cmd called "set script command" which seems to help, at least partially. My thoughts are if you control a ship remotely from the ship you're isssuing cmds to, it shows the "set command" (I guess this is for ACTION command) in the properties screen. But the ship you're controlling is technically in a script mode, so that property is not on display...instead showing the current SCRIPT command, which is apparently another item. However, if you recall, the plugin...movepilot shell sets up a task for the ship to run the actual move process, which isn't part of the original script you run from the menu. The script command, therefore, shows up only briefly until the task takes over and the menu command exits. This resets the property display to show no command (no script command). I think I once saw the FBC use this action and both ships did show the movepilot command, but this was in terms of a third party remotely controlling the ships and the ACTION command was on display at the time. Grr. I'll check the boards to see what they say on this.

The whole purpose of my concern is not just cosmetic, but also to give the FBC and/or TF something to look at to show if the ship is "busy" with anything. The FBC, in particular, is a cruel mistress and doesn't let anyone finish what they're doing if they don't show they're actually doing something. :twisted: Having the task ID in the ship (set up from the shell) is at least a start, but I also found the original scripts didn't clear it when the move was done, giving potential for false positives if that's all you tested for. Needless to say, I'm still working on it, and have a few ideas yet to try out.
It just seems like we're getting a lot of "add-ons" and it makes more sense to include stuff in the core code with the option to select on/off modes for it.
On/Off is fine, but I'd prefer that it was also smart enough to know the situations when the addons aren't needed, and turns them off in those situations, rather than relying on the player.
I should probably ask you to clarify your meaning here...

Currently, since I'm still in the early stages, it's just a script "x = TRUE" or "x = FALSE" and then later on "if x == TRUE...<do this>" to turn it on/off. But I hope to put this into a menu to have the user choose if they want the FBC/TF to automatically do this work (me personally, I manually config everything before I give it to the FBC). I will probably default it to off, to start with, and the user could turn on the auto-move/auto-install as they wish. Naturally, tests will be in force to be sure we don't put something in that already exists (you already have a section in the movepilot script that checks if something is missing and move it from old to new).

Ideally, I was thinking of a menuing system a little like what I was working on for the FBC "advanced" menu for choosing what types of ships of what race/type, that you want the FBC to buy. In this case, however, have it allow you to chose what upgrades you want in your ships and have it custom-config things the way you want, not just "add everything in sight and let God sort it out later". For instance, of what use is Trade Command Software in a fighter ship? But it's in the old code to move it. Also, I don't use JD's in my FBC (they're just flying in circles right outside the station), but in the TF it might be useful.
From a scripting point of view, what differences are there between X3:R and X3:TC?
There aren't too many differences, but the ones there are can be a bit painful. I haven't done much scripting in TC as of yet, but the differences, and how they would relate to TFP, would be as follows, as I understand it:

- No BBS. So the code I added for hiring an experienced CP at startup becomes useless (and breaks the package.)
- Colours are no longer \033 codes, but [red][/red] [green[/green] etc. However, the worst bit is, that messages containing colour codes will result in a blank entry in the message log.
- Fairly minor, but t file names have changed. Rather than 448069.xml, they are now L044-8069.xml (I think that's right.)
Well, no BBS kinda spoils things for a lot of people, I'm sure. Lots of BBS-related stuff out there, with options found for using features of certain scripts.

I'd like to know how we're supposed to do color in TC if not in the way we were before. I can use things like [yellow]...[/yellow] easily enough, but if it doesn't show up anywhere... Are you saying this is if we use it from the text file, or if it's this way inside a sprintf statement, too?
BlackRain has already ported it across, and has dealt as well as he could with those issues.
I saw his posts in the TC forum. Might be a good idea to ask him if he knows anything more on the issues of color, since we use so much in our messages and ship names.

Basically, I'd hate to think we'll need a complete re-write if we ever decide to port the whole thing over to TC one day.
A passing thought... When installing/replacing stuff using Cycrow's Plugin Manager, if you install "on top of" an older set...
I don't *think* it removes any that aren't replaced. I seem to recall an issue where a file wasn't included in a release, and when people upgraded, it used the old file...
I'll try it another time, but I hate leaving orphaned files behind, even though PC's nowadays come with great gobs of HD space, it's messy if you have to wade through tons of stuff that has no purpose. Probably, the best method is uninstall the old before installing the new. I suppose we might need to do that when we try out that AL system for the FBC.

I had a new idea hit me which I wanted to ask everyone about... The FBC uses a tender (well, sometimes, mine isn't at the moment) to bring in goodies to equip fighters. What if, since the FBC has a tendancy to charge extra for so many other "services", to instead have it simply "order" a delivery from a nearby EQ by a third-party "friendly" ship (after all, business is business in the X-Universe) and then use this to swap over to the fighter as needed?

I don't know how often most people have the FBC buy new empty ships, or how often the user might feed new ships into it, but I would imagine it probably wouldn't be TOO often, and easier to have an occasional ship make deliveries than trying to micro-manage your own to go out and find stuff, then sit forever waiting for someone who actually needs something. This could also open up a possibiity to program support for either an EQ or PHQ as the FBC and supplying directly. A simple CAG ship could keep the station supplied and take the work away from us.

Jeez, sorry for the long post...

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Mon, 13. Jul 09, 20:21

A useful suggestion...

I just decided to pay a visit to my FBC and check out the FPS in the sector after clearing it out of space trash and rubble (mine is in Three Worlds -- lots of rocks up there).

On entering, and given a moment or two to start looking around, I see some floating boxes, which look like I got in just as a pirate was getting his butt handed to him by my recruits. :thumb_up:

I pull up the properties screen to see who's doing what, and see several cpilots with "Attack Argon Police" in their action commands. Uh Oh! My guess is a little friendly fire got in there along with the pirate attack.

Suggestion... If a cpilot is marked with race F/F settings to "friend", and it gets attacked by something, it should do like I would do in the comms and basically say "Sorry...", then turn off the Foe status on both ships. This only really applies for IS battles (OOS wouldn't probably have this happen). It can thoroughly screw up one's notoriety if you are IS and your cpilots start attacking everyone in sight just because of a little friendly fire.

The thing is, I'm not sure where you're going to find a "clean" copy of the F/F unless you try the global settings or somehow save a copy of the F/F before the cpilot gets into trouble. Maybe if you could add a section into the "generate report" for a pilot to update with the then-current settings to refresh the pilot on his current orders and racial stance?

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Sat, 18. Jul 09, 07:59

Am I the only person talking in here? Hello? :o

Just so you all know, I've been getting my hands dirty with just about every script in the package, so far, making everything from small tidying-up changes to major re-writes of some stuff. I still need to test some of it, but so far it's going ok. I only crashed my game a few times, so far, but that was mainly my fault (writing comments with contractions using an apostrophe and letting scripts run that weren't fully ready, but the pilots picked up on them before I could finish). :oops:

Some stuff I did was to cut the size of the TF.assault file down by half, using loops instead of the long-hand stuff in there before...a LOT easier to read now. And I'm re-working the TF assault routines to see if I can make them a little better. For instance, the "pointmen" created and dispatched inside TF.assault will have a new SIGNAL_KILLED handler so if something nasty happens, their escorts won't just be left hanging. Instead they'll all fly back and rejoin the leader's formation.

Also, when making pointmen, we now scan more than just M1's and M6's. First it looks for M2's, then M1's, then M7's and M6's, picking out the 3 best choices...or at least that's how it's supposed to work. None of my TF's have M1's or M2's involved, so I need to test this part still. But if it works on M7's and M6's, the rest should also be ok. (still coding part of it)

When assembling the TF, ships are given orders to dock, or at least fly and join in formation to the leader (they weren't doing this consistently before). In addition, virtually every ship that can set a homebase (including M6/M7) can and DO set homebases to whatever type leader ship can have homebased ships on it (everything M6 and up). I've also checked and tested that homebased ships already on a ship joining a TF also get added and re-homebased (recursively).

Assault groups process rejoining when assembling to organize and when leaving. I sent one group off in testing, watched as they flew en-masse to and from, sweeping the sector like a cloud of pestilence, leaving only flying boxes and a few bailed ships in their wake. :twisted:

I had a thought that if the pointmen involve big caps, I might have them split off in different directions rather than hang in one area or all go out in the same direction after the same targets. The only condition might be if enemy caps are in the sector, then everyone gangs up on them. Heh... Just an idea so far. Wouldn't be too difficult, though.

I'm going to try using formation patterns on ships. Even though it might not matter OOS, it'll look cool IS. I'm setting up 2 new local vars on each ship to hold it's "default" formation type (what you set on the ship before you put a pilot in it), along with the ship's F/F race switches. These will be set as a new pilot is put into a ship (move or hire), or updated, when you run a pilot report, based on the then-current settings.

The F/F stuff is from my last suggestion. Just putting the pieces into place on that now. I'll probably need a new SIGNAL_ATTACKED handler for every cpilot to take the first look at things and then if they find the attacker is "supposed" to be friendly, turn him off from Foe status. I hate it when I start getting voice-overs saying "...your ships are under attack...and, oh, by the way, you're now a hated enemy of the race you had just spent the last 3 months trying to build up a high rep with...have a nice day." Grr. Such things can really only happen if you are IS and your ships lay a little "friendly fire" on race ships...they really have NO sense of humor! :shock:

I'm also fixing several issues that I found along the way...in MANY files... that either weren't making sense to me or seemed inefficient, impractical, unnecessary, or inadequate for the situation. I figure either the original code was written a long time ago using an older scripting engine, or whoever did it was...um...well, very inefficient in their methods. Either that, or too much legacy code is getting in the way of newer changes.

In my copy, I've also changed the version number to 1.54 due to the fact that I've made some minor tweaks to the trackers, and they need to update to new versions now. I'm not finished yet, so we'll see how much more I put in there.

Since RRRoamer hasn't showed up lately, and I don't see much else going on in here, I'm just taking free license to have a whack at everything. Hope you don't mind. I'll probably have a complete re-write before I'm done. I'm also thinking of trying out my own ideas for multi-sized patrols, at least for the FBC. Not sure on the TF's yet. Been waiting for RRR to do that, since at least word, he had something in progress...

User avatar
frosty_dd
Posts: 65
Joined: Fri, 27. Jan 06, 16:48
x3

Post by frosty_dd » Sat, 18. Jul 09, 21:45

jumbled wrote:Am I the only person talking in here? Hello? :o
Long time since I posted (I played the game in 2006; just recently got hooked again) and so far this is the only script I'm running (next to the bonus pack).

I remember that the first time I played X3 I used balogt script (real pilots), which also made it possible to hire pilots, who - if I remember correctly - could gain experience and become better fighters.

Now, the reason for my post: I just find it great that after 3 years, there are still people scripting & modding for this game, and I'm looking forward to future updates on this script!
That's the difference between me and the rest of the world! Happiness isn't good enough for me! I demand euphoria!
(Calvin & Hobbes)

jumbled
Posts: 320
Joined: Mon, 28. Jun 04, 08:22
x4

Post by jumbled » Sun, 19. Jul 09, 00:17

Eladan (or anyone willing to give this a try)...

I'm having some recurring troubles when changing version numbers, like for the cpilots section (setup.plugin.cpilots) and then, I suppose, when the ship trackers get the update.

I had this once before the last time I had to update the trackers and it caused a game CTD. I don't think it's a coding error (it's simply trying to close the old and restart). I had to update them again, and once again it's doing another CTD on me.

Thing is, I somehow managed to get through it the last time and see no reason it shouldn't work again.

Could it be an overload of trackers running the update process, all of which are running the updater as a task assigned to a "null" object, and X3 choking on it? Could someone else give this a try just by testing what would happen by changing version numbers on the setup.plugin.cpilots file and the plugin.cpilots.tracking.device file to see what happens? Maybe it's not me, or maybe it's something unrelated to the actual scripts.


EDIT:
Nevermind, I found it... Dratted safety script again. Now I remember this was my problem before...forgot to update versions on it, as well as the tracker. It must've been running in circles with itself when I updated the global version and it couldn't decide what to do. :roll:

eladan
Posts: 7168
Joined: Sat, 7. Jan 06, 16:01
x4

Post by eladan » Sun, 19. Jul 09, 03:10

jumbled wrote:Am I the only person talking in here? Hello? :o
I'm not on as often as I'd like lately, and don't have a huge amount of time when I am on. Combine that with you writing a book every time you post, and, well... :wink:

I also still haven't looked at the scripts lately. Bear with me, I'm a bit busy with other stuff at the moment.
jumbled wrote:I'm just taking free license to have a whack at everything. Hope you don't mind.
I don't mind. Do you have my beta stuff? If not, do you want it?

dminor
Posts: 1083
Joined: Sun, 14. Oct 07, 00:16
x3tc

Post by dminor » Sun, 19. Jul 09, 09:30

And I'm willing to break it... umm .. I mean test, ya test it.
" I'm a Sexy Shoeless GOD of WAR " Belkar

Post Reply

Return to “X³: Reunion - Scripts and Modding”