[Script] TerraCorps Fleet Package

[jumbled]

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...

Yeah, I figured that might be a problem for some...sorry, I tend to get a bit winded.

Also, some of my previous post might just have become obsolete already as I just tested some alternatives to it. (sigh)

I also still haven't looked at the scripts lately. Bear with me, I'm a bit busy with other stuff at the moment.

I understand. I'll just keep plugging away at things. I'm still cleaning up a lot of obsolete and legacy stuff, and trying to make what's in here more consistent. Like, in a few scripts, I cleaned up a lot of extra, redundant variables all trying to do the same work in different parts of the script. I don't know about the rest of you, but my editor is very laggy (it misses at least half of my keystrokes unless I t.y.p.e..v.e.r.y..s.l.o.w.l.y... Grr. So the less to have to scroll through, the better.

I'm also solving, at least for now, the problem of version updates vis-a-vis the tracker and safety scripts.

Where, previously, you needed to change the whole package version and re-run the game to update, if only for a small change in one script, now I'm using the command "<if> is a new script version available" to update things on-the-fly as I tweak and refine these always-running scripts. It's working quite well and no full restarts. When we release the new update, we'll need the legacy code, but this is good for my re-writes.

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?

Beta stuff...? Do you mean that AL set for the FBC? That's the only thing I remember, ATM. I got that last year and still have a copy of it laying around here... Been putting off studying up on AL processing till I can get a few others straightened out first.

I'm basically making incremental changes till I get something right and working properly. My current project being an almost complete re-write of the TF assault stuff.

BTW, I just tested out a portion of my ship Friend/Foe process. I decided to...um..."volunteer" a passing Paranid M3 weapons transport for some field testing (you know these Paranid...always willing to help out the less fortunate ). I set him to "foe" with commands of "Kill ship x", then again as "kill all", and lastly "Command None" (to let race AI take back control), and see what happens with one of my cpilot ships in the area. Each time, my pilot saw the errant ship and deactivated the foe status since he was marked as "friend" in the ship config (not the command menu switches, my internally stored copies of data from the last update).

So...no more friendly-fire, oops, you've lost recognition...problems.

Of course, if you WANT to make war on the Paranid (or anyone else in your ship command F/F switches), you can just change the setting, re-update, and blast away. This is now all monitored in plugin.cpilot.gocombat, which, BTW, I'm also going to make more of a permanent feature, like the tracker, only put to sleep on occasion (like if docked or "resting"). So pilots who get left out in the cold may look like they're sleeping, but it'll be more like dozing off with one eye open.

Combine an always-running gocombat and cpilots with F/F awareness, in ALL ships out on patrols (including menu "Patrol Sector" commands), and it would've fixed a problem I was having a long time ago where ships were making war on several race ships all over the place and I couldn't figure out why. Also, it can provide a way for cpilots to be used on sector patrols without any extra coding (the Patrol Single/Multi Sector cmds should do the trick).

And I'm willing to break it... umm .. I mean test, ya test it.

As soon as I finish up with some of my current ideas (which is hard since I keep getting new ones as I move along), I'll let you know.

[jumbled]

A little suggestion and some other stuff (I'll try to keep it short this time).

I'm getting kind of tired looking at the...um..."jumbled" mess in these text files. For instance, I want to edit some stuff, like the cpilot report text, but can't hardly find anything since it's all mixed up in there as new pieces were added onto the end of the existing list. So what I want to do is re-organize the files and group similar stuff together to make it easier to find related items. No biggie there, just need to be sure I change all the "read text" lines in the code.

On the other hand, I'm wondering, since the various "pieces" of the TCCP are much more of a "set" nowadays than one thing with several "add-ons", what do you say if we try to combine the different files into one, so all we need to do is work on ONE text file, rather than struggle trying to search and cross-reference between 3 or more (cpilot name list can stay where it is, though). That means files 8069, 8071 and 7430 get combined into, say, 8069 (it's the biggest with all the primary cpilot stuff in it).

Similarly, some of the TF stuff is calling out to plugin.cpilot code, and I'm working a bit more functionality of the TF to use more "common" plugin.cpilot material, which might also be used either by the player in command menu mode, or by the FBC (giving us one set of files to edit/debug, rather than so many like now).

The cpilot "safety" script, which runs continuously, seems to make special concern if a ship is in HOL. I understand some of the "ancient" lore behind this, but since cpilots are hired anywhere/everywhere now, does it matter any more? The way I'm re-writing things, portions of this could be recycled for other uses.

The cpilot tracking device and gocombat scripts are obsolete now. The TD is now a "manager", functionally the same but with a more intiuitive name. However, gocombat is ungoing a major re-write and massively evolving into a full combat AI shell, now called plugin.cpilot.autonomy, which is just like it sounds. It'll control how the cpilot reacts to certain situatiuons based on an evolution of the cpilot.taskforce.job variable on ships (now cpilot.job), which itself now supports a few more job types (to be scripted in later).

EDIT:
I'd like also to secure a new fight command slot for a multi-sector patrol option (we have one for single sector now with the Combat Tour). Fight 42 is used by an unsigned copy of Bunny's Attack Rocks cmd, which may be available (that one now uses a signed version), or Fight 43 seems to be open. What do you think?

[dminor]

Dude I don't know programing but i do know sports. The QB has just been sacked, the ball pops loose and lands in your arms. Run with it

[jumbled]

Briefly (I promise)...

My family and I will be leaving on a 1 week vacation to the coast starting this weekend. I'm not sure how much I'll be able to do while away, but I'm loading up the laptop with my work "just in case" I get some down time. I've got too many ideas in my head and I still need to get a few ends tied up before I turn into one of my cpilots, who, it seems, have mysteriously forgotten their names! Not sure how it happened, if it's one of my many edits somewhere that got caught in the processing loop before it was ready, or if I did some testing somewhere that unset the pilot name... Hmm. Need to check an earlier save to see if I can find where/when it happened, or if it's in my current set of files.

Strange thing is, nothing, other than the "getname" script sets that particular variable, and it looks just fine to me.

I'm working on combining the 2 automove scripts used by the TF leader to move pilots to new ships. I'm sure we can do it better, and in ONE file.

A thought... In cases where a TF leader has too few docking bays for follower ships and needs to move pilots up...how about if he can make use of a transporter (if available) to "beam" things over? Especially if he were to move pilots between big ships (so far he only moves fighters)?

[eladan]

Beta stuff...? Do you mean that AL set for the FBC?

That, plus the patrol code, plus assorted other bits and pieces that I had lying around being worked on.

This is now all monitored in plugin.cpilot.gocombat, which, BTW, I'm also going to make more of a permanent feature, like the tracker, only put to sleep on occasion (like if docked or "resting"). So pilots who get left out in the cold may look like they're sleeping, but it'll be more like dozing off with one eye open.

The issue with this, that I never found a satisfactory solution for, is: what happens if you want to run another combat-related command on the cpilot ship? E.g. say you want to have a cpilot ship as a wingman running "Protect my ship". With gocombat running permanently, your wingman will go haring off into the distance at the first sign of a hostile, which is clearly at odds with what you want him to do.

If you can think of a generic solution to this, I'd be very interested to hear it.

...so all we need to do is work on ONE text file, rather than struggle trying to search and cross-reference between 3 or more (cpilot name list can stay where it is, though). That means files 8069, 8071 and 7430 get combined into, say, 8069 (it's the biggest with all the primary cpilot stuff in it).

If you're volunteering to combine it, I won't stand in your way, though I think you'd find it's a bigger job than you might guess. Having three files hasn't bothered me that much, since it hasn't really caused any inconvenience.

The cpilot "safety" script, which runs continuously, seems to make special concern if a ship is in HOL. I understand some of the "ancient" lore behind this, but since cpilots are hired anywhere/everywhere now, does it matter any more? The way I'm re-writing things, portions of this could be recycled for other uses.

Legacy code. (Does it even run it?) Not needed.

Fight 42 is used by an unsigned copy of Bunny's Attack Rocks cmd, which may be available (that one now uses a signed version), or Fight 43 seems to be open. What do you think?

Shouldn't matter - either should be fine.

A thought... In cases where a TF leader has too few docking bays for follower ships and needs to move pilots up...how about if he can make use of a transporter (if available) to "beam" things over? Especially if he were to move pilots between big ships (so far he only moves fighters)?

Sounds ok, but it might get messy. Too many conditionals makes for fun code.

[Litcube]

What does this script do?

[eladan]

@Litcube - sorry about the delay. Basically, it lets you hire pilots for your combat ships, who will gain in skill and abilities as they gain experience and levels. You can create task forces if you have suitably experienced pilots, who are able to command a task force, and the task force can be used to provide security for a group of sectors, as the TF leader will send out scouts and patrols throughout those sectors.

The readme may also be helpful.

[jumbled]

Beta stuff...? Do you mean that AL set for the FBC?

That, plus the patrol code, plus assorted other bits and pieces that I had lying around being worked on.

I don't recall any patrol code or anything other than the AL thing for the FBC. Which, BTW, brings me to the point where I'm currently working on trying to combine 5 different versions of sector patrol scripts (between the player menu command, one for the FBC and a few more from the TF files...ugh) into one generic file that I can use for everything (do param and error checking external to the "guts" of the patrol script). What is it that you had in your set? (might be worth taking a look before I get too deep)

What I'm going to do is combine features of the existing scripts, give an array of wingmen (optional number for different size patrol squads) plus a target sector. The wing leader will run it from the start, so no more guessing who's the highest rank inside the script since the TF member array will be pre-sorted with highest member running the script and pulling in several of the lowest members from the same array. I also want to try to work in giving "better" pilots (with better traits) the lead so they build up leadership to get into bigger ships.

This is now all monitored in plugin.cpilot.gocombat, which, BTW, I'm also going to make more of a permanent feature, like the tracker, only put to sleep on occasion (like if docked or "resting"). So pilots who get left out in the cold may look like they're sleeping, but it'll be more like dozing off with one eye open.

The issue with this, that I never found a satisfactory solution for, is: what happens if you want to run another combat-related command on the cpilot ship? E.g. say you want to have a cpilot ship as a wingman running "Protect my ship". With gocombat running permanently, your wingman will go haring off into the distance at the first sign of a hostile, which is clearly at odds with what you want him to do.

I'm working on this and have a few ideas in mind already.

First, let's say, you have a standard patrol (FBC/TF managed). Each pilot has a "job" recorded in his ship computer. If he's a patrol leader, he'll go run down a red with wingmen in tow. The wingmen, on the other hand, set to "Attack Same" will see their orders (job="patrol") and stay on their leader's target, whatever that target is, even though they may also be picking up reds (same or different) in their own scans. This is how it should work for patrols, IMO, rather than each ship taking on the nearest red by itself.

Next, lets say you have an escort job (like a trader escort). The pilot will guard the TS and only attack if a red targets the TS for attack (and probably I'll also have to have him watch his own back, too), so he won't go running off attacking everything in the sector that otherwise isn't a threat to his mission.

Let's also say you have a scout (now using a job called "recon"). He won't engage at all (so no more M5's taking on M1's )...rather he's going to report back to central, if there's no other patrol in the sector, and ask for backup. He'll work it either of two possible ways (depending on how I program it)... 1) He'll simply stay away from it ("evade" tactic) and continue his duty, or; 2) go into "decoy" mode -- run up to it and get it's attention, then fly in circles on the edge of scanner range while he calls in for a "strike team" to come kill the bogie. The strike team will be a replacement to the original Attack script, which was really nothing more than a modified patrol and no better at killing stuff than any other patrol (I once watched as an "attack squad" was called in and just went in circles missing the intended target it was sent after). The strike team will home in on the bogie based on signals from the scout, who is basically leading the reds into an ambush.

Strike teams may also be used to target ships scanned by "friendly" assets (player ships, stations and sats).

So far, "evade" and "decoy" are still just ideas I need to work on, but it's a job that'll have to wait till later after I get a few other parts running properly.

As for your idea... I've also considered the prospect that the player might call one or more ships to his own side, like as wingmen or guards. In this case, he should have them leave any FBC/TF control (otherwise they might go running off under FBC/TF direction. In this case, I'll be working on improving the AI to look for an "unattached" condition and "active orders". Their internal "job" will probably have to be programmed to reset itself to a default (like job="none") if they're not in a TF or FBC, and any ship commands (what the player orders them to do) will make the AI "assume" the player is doing something, in which case default orders will kick in depending on the situation. For instance, if you give them "Protect Me" orders, they'll go into something similar to the "escort" job mode, etc. (try to re-use existing code in this case.)

This will also have to wait till I can test the early steps.

BTW, I'm going to put the TF leader to work having him do sector patrols around the home sector in his list (the first one you give him), with standard rest breaks in-between. His personal guard (mine often places several M6's in formatrion with him) will be on "sentry" duty...another form of "escort".

...That means files 8069, 8071 and 7430 get combined into, say, 8069 (it's the biggest with all the primary cpilot stuff in it).

If you're volunteering to combine it, I won't stand in your way, though I think you'd find it's a bigger job than you might guess.

Well, I think I'm done. I got time during my trip to do a lot of major conversion work, and I -think- I got all the references changed over. I still need to run the game properly through to test things, but I moved files 7430 and 8071 into 8069, with all cmds and messages copied and renumbered. I also renamed all addon.cpilot.tf.* files into plugin.cpilot.tf.* and changed all references there. Plus I did a huge conversion of all local variable names to prefix "cpilot.*" onto them, to make naming more consistent and meaningful and not to have any accidents with other scripts using similar names.

Fight 42 is used by an unsigned copy of Bunny's Attack Rocks cmd, which may be available (that one now uses a signed version), or Fight 43 seems to be open. What do you think?

Shouldn't matter - either should be fine.

At the moment, I'm using Fight 42 (key 342) for my new command. Still need to finish converting the script, but I'll get to it.

A thought... In cases where a TF leader has too few docking bays for follower ships and needs to move pilots up...how about if he can make use of a transporter (if available) to "beam" things over?

Sounds ok, but it might get messy. Too many conditionals makes for fun code.

Actually, the way things are written, I don't think it'd be too bad...just need to make sure that, instead of docking, the ships are within 5km of the carrier before continuing.

Which brings me nicely on to another new task I'm giving to my pilots... "assemble", a special command to be stacked along with any other orders (going into a kind of pseudo-queue) where the pilots will take care of their own business, rather than making a TF or FBC leader "wait" for them. Just tell them "pull yourselves together and do...this" type of thing. We'll see how it works once I get it up and running.

Oh, and did I mention I gave my pilots the ability to do police scans in times of "peace"? Just give them a freight scanner, and be sure they're flying patrols in race sectors where you have a police license, and they'll have a random chance of doing scans to uncover pirates. I've been waiting for any of mine to actually find one, though. I might have to ramp up the chance to 100% and script in a few just to try it out.

[eladan]

I don't recall any patrol code or anything other than the AL thing for the FBC.

I've mentioned it quite a few times... maybe you just haven't been around when it's come up. I sent it to RRRoamer at one point when he was looking to clean up the TF code, but real life got him.

What I'm going to do is combine features of the existing scripts, give an array of wingmen (optional number for different size patrol squads) plus a target sector.

Which is pretty much what I did. I don't seem to have your email address any more, so if you PM me with it, I'll send what I have.

I won't respond in detail to the rest, other than to say it sounds good.

[jumbled]

I don't recall any patrol code or anything other than the AL thing for the FBC.

I've mentioned it quite a few times... maybe you just haven't been around when it's come up. I sent it to RRRoamer at one point when he was looking to clean up the TF code, but real life got him.

I do remember RRRoamer was working on some patrol code, but since he's not around ATM, I'll give it a whack...I'm already part-way there now. I'll send my email to you in PM.

A couple other questions have come up in the meantime. I've found a use for a few "library" files I found in my X3 install, but I'm unsure if these are part of the base X3, or the bonus pack, or some other add-on I installed some time.

Can you check for me if the files lib.cm.policelicense and lib.by.emptyscript are part of X3 or something else? Thanks. If they're not something normally found in the vanilla install (i.e. not something the "average" player might have without installing something extra), I may have to build my own library of odd small stuff to include with my patch, unless we can be allowed to include these with future versions of TCCP (I wouldn't want to step on any toes...heh).

Speaking of RRRoamer, I've patched his TF Additional Commands add-on to work with my own upgrades. I'll have to include a zip with that once I get my other stuff ready. Once I get something ready, I'll probably send it off to you in a zip to review and package into an installer file. The upgrade is going to require a complete uninstall of the old and re-install of the new, but I'm writing a patcher script to hopefully upgrade everything in-game so we have minimal disruption to things.

BTW, I would like to suggest we re-write the docs for this thing. There's a lot of old stuff in there that needs modernizing.

[jumbled]

I'm going to experiment wth the "pilot aggression" setting, to see how that affects things. I was looking over the defaults on a bunch of my ships, and it came up between 8 and 14 on a dozen or so ships I had handy to look at, whereas I see pirates (XTM style) running into the 20's. Hmm....

I tested a sample on a pirate ship to attack me, setting his level at 1 vs at 30. It seemed he made more efforts at direct attacks on the higher setting. I think he even threw a big missile at me, but my turrets got it before I could be sure what it was, blowing half his tail pipe off his ship.

I'm going to try starting pilots off at level 6 and bump it up by 3 per rank level, in keeping with the feel of how the fight skill works.


@Eladan
Please take a look at the ranksets file for me and give me an opinion on all the commented-out stuff referring to ship bonuses and such in there. Looks like a lot of old code, some of it now duplicated in the Signal Killed file. The old code seems to give bonuses based on ranks <=7, but the new stuff does it based on the all.kills value for pilots and medals they receive. Do we still need the old stuff, or is this one of those "works in progress"? I think we should settle on one idea or another and stick with it.

EDIT:
Also, I need to ask you about the logic in this part of the traitrun script:

Code: Select all

 048  * Trait = 1 - Very tough
 049  trait1:
 050  if $dieroll < 19
 051    $xp = $xp + 1
 052    $ship -> set local variable: name='cpilot.combat.xp' value=$xp
 053    return null
 054  else
 055    $galaxy.age = get global variable: name='global.cpilot.age'
 056    $birthday = $birthday + 4
 057    if $birthday < $galaxy.age
 058      $birthday = $birthday - 5
 059      $xp = $xp + 1
 060      $ship -> set local variable: name='cpilot.birthday' value=$birthday
 061      $ship -> set local variable: name='cpilot.combat.xp' value=$xp
 062      return null
 063    end
 064  end
 065  return null

Birthday is set to the "year" (in global.cpilot.age) on new pilot creation.

Say galaxyage is 6 and birthday is 4. In the pilot report, he would calculate his age as galaxyage - birthday + 17 = 19 years old.

However, using the above, birthday + 4 = 8, which is > galaxyage, making him underage to fly (galaxyage - birthday + 17 = 15) . So you need to correct that. BUT, only if birthday is < galaxyage do you make any sort of "correction".

If we changed it such that if birthday > galaxyage corrects it, then we make birthday - 5 (8 - 5 = 3), then galaxyage - birthday + 17 now puts him at 20! Is this guy supposed to be going up or down in years?

Alternately, if galaxyage = 7 and birthday = 2 , the pilot reports his age as 22 normally. If birthday + 4 = 6 and still < galaxyage, we take 6 - 5 = 1, so now galaxyage - birthday + 17 = 23. Maybe he suffers from rapid aging, but I was originally under the impression this was to REDUCE the age, not add to it. Am I wrong? How is it supposed to work? Is he supposed to age faster or slower than normal?

[eladan]

Can you check for me if the files lib.cm.policelicense and lib.by.emptyscript are part of X3 or something else? Thanks.

the emptyscript one is vanilla, I think, but not the policelicence one.

Please take a look at the ranksets file for me and give me an opinion on all the commented-out stuff referring to ship bonuses and such in there.

A lot of that is legacy, and probably can be gotten rid of. I do have a (probably bad) habit of commenting out old code rather than removing it. Wouldn't be so bad if I then made a comment to the effect of what it was and why I was commenting it out!

I tend to keep WIP stuff separate from released code, so there shouldn't be any commented out WIP code.

Also, I need to ask you about the logic in this part of the traitrun script:

...

Maybe he suffers from rapid aging, but I was originally under the impression this was to REDUCE the age, not add to it. Am I wrong? How is it supposed to work? Is he supposed to age faster or slower than normal?

Age has no effect, so it's pretty much useless anyway. The code was left there because it wasn't hurting anything to do so.

[jumbled]

the emptyscript one is vanilla, I think, but not the policelicence one.

I think the police license is from FCS Mk3, since it seems to fall in line with similar files from that set. I can always copy the gist of the workings from it into my own, if needed. It's not that big, and the principle is simply to find which license is for what race from the ware set.

Please take a look at the ranksets file for me and give me an opinion on all the commented-out stuff referring to ship bonuses and such in there.

A lot of that is legacy, and probably can be gotten rid of. I do have a (probably bad) habit of commenting out old code rather than removing it.

I'll probably re-work some of it anyway. I've already re-formatted the file, grouping parts with similar intent together. I also found a bug that can happen in rare cases...

Say you have a Commodore TF leader in an M7 and a Captain in an M6, (*cough*) like what happened to me just recently. If the Cpt is ready to promote, he shows a msg that he can't because of the Como's rank. It's supposed to store a little flag in the pilot ship to only show this msg ONCE, but I was getting it repeatedly. I found the code was going on to the next section where it checked ship types to promote into, in which the Cpt. can go into an M7 now, so it automatically reset the msg flag to clear any condition that THAT section might have had that he needs to be in a bigger ship to promote (if, perhaps, he might be in an M3, it would give a msg to go M6 or better). But since the "promotion" was cancelled from the above TF leader check, the process ended when it got to the rank increase section. Ergo, next time the TF leader cycles, it goes back in and does the TF check, etc. again and gives me new msgs.

Back to ranksets, I think I'll re-enable the part to use medals when setting/resetting ship bonuses, rather than depend on Signal Killed to bump things up on a kill (I'm trying to reduce the overhead in that file to keep it short, placing things in utility scripts instead). When ranksets is run, it'll reset a ship to "flat" max, then re-calculate bonuses based on...whatever is the current method (medals, ATM). This will also clean up some stuff in the tracking device (cpilot.manager), allowing me to make a simple script call rather than duplicating code all over. I'll keep the other set of bonus code (the short version) based on rank, for now, as a backup.

Also, I'm going to change ranksets (now renamed to cpilot.bestowment) so it applies medals based on total kills after a pilot finishes a tour, or other "job", since we need to allow for a little Pomp and Circumstance for the medals to be awarded. Signal Killed will still apply medals for pirate/xenon/khaak on a kill. I think we could use this setup later for future expansion if other "awards" are created for the pilots.

I'm finding truckloads of small glitches from the original code where pilots are missing xp/kill points and losing data from other errors. One case was in Signal Killed where if a pilot had no xp on making a kill, he gets nothing from the kill. Lots of little things, but I'm smoothing it all out as I go along.

Also, I need to ask you about the logic in this part of the traitrun script:

Age has no effect, so it's pretty much useless anyway. The code was left there because it wasn't hurting anything to do so.

But is he supposed to gain or lose a year as the result of the chance "bonus"? One could argue, since this is "very tough", that time doesn't affect him as much, so he gains a year. But then, the additional wear & tear he goes through, though it might not cause as much harm to him, ages him a bit faster. Hmm.

I've sorted and renumbered the traits to allow me to run a sorting algorithm on that and rank. Sorting ships by rank/trait will put better pilots at the top of the list when selecting ships for patrols, giving such qualities as "brilliant" and "born leader" first chance at building leadership skills. Lower pilots will be pulled off the bottom of the list to fill in as wingmen. I fixed (hopefully) all scripts to point at the new trait numbers when checking or adding bonuses. The "trouble maker", will now actually cause trouble, on rare occasion. Someone apparently once had a bit of code in there to have him bring in a bad-guy ship to attack him, but it was disabled. No longer.

After the last couple of weeks of coding and major conversion work, I'm doing a little bit of alpha testing on some of the stuff I've done so far. I applied my own patch to my game and have been testing some of my work to get at least a few things running. The FBC and TF now use common code for hiring new pilots and moving pilots, and I'm working on making up a set of "job" scripts for other stuff. Each job will end by putting the pilot in "standby" mode waiting for his next orders and sending a "report" to his homebase (either the FBC or TF, if he's part of one), which will then queue up and get processed.

The pilot uses an interface for issuing orders to centralize the script processing, rather than, say, like I'm looking at now in so many odd scripts, everything doing the same work and "reinventing the wheel". A big one is sending a ship home, where almost every script takes up a dozen or more lines per ship in each script it runs to determine if there is a home, if there is docking space in that home, and whether or not to dock or maybe go into Protect mode around it if no space. Ugh... I now have one Job script to do all this and the others only need to give orders to "go home". This'll cut huge sections out of the other scripts and make it all so much easier.

[Valen68]

Glad to see someone continuing this work! How soon will it be before you have a playable version?

[eladan]

I'm finding truckloads of small glitches from the original code where pilots are missing xp/kill points and losing data from other errors. One case was in Signal Killed where if a pilot had no xp on making a kill, he gets nothing from the kill. Lots of little things, but I'm smoothing it all out as I go along.

There's bound to be, given the mess that the code's in. I'm sure I've introduced my share. You probably will too. Good to be finding some to eliminate though.

But is he supposed to gain or lose a year as the result of the chance "bonus"? One could argue, since this is "very tough", that time doesn't affect him as much, so he gains a year. But then, the additional wear & tear he goes through, though it might not cause as much harm to him, ages him a bit faster. Hmm.

Oh, it's supposed to remove a year, I'm confident. Very tough, so lives longer.

The "trouble maker", will now actually cause trouble, on rare occasion. Someone apparently once had a bit of code in there to have him bring in a bad-guy ship to attack him, but it was disabled. No longer.

Are you sure you're working on the very latest version? That was something that was broken, but I thought I'd fixed it in the latest version. Of course, I could be going insane.

I now have one Job script to do all this and the others only need to give orders to "go home". This'll cut huge sections out of the other scripts and make it all so much easier.

Sounds like you're doing everything that I had planned to do... but one better (you're actually doing it. ) Sounding good.

[dminor]

Hey Valen68. Its playable now. Jumbled is improving the script.

[Valen68]

yeah that is what I meant, how close is he to finishing improving the script?

[eladan]

You can never finish improving the script.

I'll leave that for jumbled to answer, but it'll depend on when he finds a point that he can sanely clean things up for a stable release.

[jumbled]

I'm finding truckloads of small glitches....

There's bound to be, given the mess that the code's in. I'm sure I've introduced my share. You probably will too. Good to be finding some to eliminate though.

Oh, I think I've done a bit already... Gotta take more breaks and rest my eyes.

The "trouble maker", will now actually cause trouble...

Are you sure you're working on the very latest version? That was something that was broken, but I thought I'd fixed it in the latest version. Of course, I could be going insane.

The copy I was working on had it commented out...dunno if this was supposed to be a new or old copy, but I think it came in the last spk.

I now have one Job script to do all this and the others only need to give orders to "go home". This'll cut huge sections out of the other scripts and make it all so much easier.

Sounds like you're doing everything that I had planned to do... but one better (you're actually doing it. ) Sounding good.

Piece by piece it's coming together.

@ Valen68
I think it'll still be a while before I can get enough of it back together to make anything "stable". The patrol scripts are in a shambles after my cpilot patch. The only one I got working is for the FBC, but that's only a temporary fix to change variable names, not an actual upgrade yet. I'm only beginning to get to the point of testing a few of the smaller pieces. Just tonight, I observed as I...um..."lured" a Khaak swarm near a TF fleet as they were resting. The poor sap that did the luring didn't like it too much, but his call for help got the TF leader up and helping out, which got the others going.

@ Eladan
After much pain, I got your new names list incorporated, sorted, cleaned, verified and a few other things... Here's the stats:

3088 first names, 1546 Male, 1542 female
5000 last names.

An example of the longest male name I pulled up is Constantine Hollingsworth, and for the ladies, Wilhelmina Hollingsworth. Better stay away from that family...the time it takes for you to pronounce the name alone is enough to get you killed! They seem, so far, to fit inside the data fields, barely... I'll test it a bit more as they rank up. Longest rank is either VAdm or LtCdr (fully spelled out, of course).

If it's alright with everybody, since I'm removing color from the lines in the 8070 file (and subsequently need to change some scripting code to handle it), I think it's easier, rather than try to clean the existing names in the ships of color codes, instead issue new names. I did it here on mine, to try it, and Wow! It sure looks better... No more inbred Drummonds and Underwoods. It looks like an actual society now!

[eladan]

The copy I was working on had it commented out...dunno if this was supposed to be a new or old copy, but I think it came in the last spk.

Not sure. May have been another in my fixed-but-not-yet-released pile.

After much pain, I got your new names list incorporated, sorted, cleaned, verified and a few other things...

<shakes head and applauds> That would have taken some effort. Well done.

An example of the longest male name I pulled up is Constantine Hollingsworth, and for the ladies, Wilhelmina Hollingsworth. Better stay away from that family...the time it takes for you to pronounce the name alone is enough to get you killed!

I did it here on mine, to try it, and Wow! It sure looks better... No more inbred Drummonds and Underwoods. It looks like an actual society now!

Yeah, I had mine running with the names (before your gender patch torpedoed my effort! ) and it made a huge difference.