Expensive Vanilla Scripts

[Litcube]

EDIT: Litcube. Can you point me in the direction of a good tutorial for editing jobs? I just need to know what i'm looking at. Sadly I dont own Excel so im going to have to do some tweaking via notepad.

Uhh. I don't know where any tutorials are for job editing. They're self explanatory in Xeditor 2, though.

[joelR]

EDIT: Litcube. Can you point me in the direction of a good tutorial for editing jobs? I just need to know what i'm looking at. Sadly I dont own Excel so im going to have to do some tweaking via notepad.

Uhh. I don't know where any tutorials are for job editing. They're self explanatory in Xeditor 2, though.

Ok easy enough.

1 question though. Why would your edited scripts begin a game with more running script processes than the vanilla game? Is it that leadshipwingmonitor thing? Do more processes necessarily mean decreased performance?

[Litcube]

EDIT: Litcube. Can you point me in the direction of a good tutorial for editing jobs? I just need to know what i'm looking at. Sadly I dont own Excel so im going to have to do some tweaking via notepad.

Uhh. I don't know where any tutorials are for job editing. They're self explanatory in Xeditor 2, though.

Ok easy enough.

1 question though. Why would your edited scripts begin a game with more running script processes than the vanilla game? Is it that leadshipwingmonitor thing? Do more processes necessarily mean decreased performance?

Yes. It's the monitor script. The lead ships are running a script on task 587. In vanilla they are not.

[joelR]

EDIT: Litcube. Can you point me in the direction of a good tutorial for editing jobs? I just need to know what i'm looking at. Sadly I dont own Excel so im going to have to do some tweaking via notepad.

Uhh. I don't know where any tutorials are for job editing. They're self explanatory in Xeditor 2, though.

Ok easy enough.

1 question though. Why would your edited scripts begin a game with more running script processes than the vanilla game? Is it that leadshipwingmonitor thing? Do more processes necessarily mean decreased performance?

Yes. It's the monitor script. The lead ships are running a script on task 587. In vanilla they are not.

Ok thanks. One last question if you dont mind. When editing a job where it says "max number of jobs" I assume that means the entire universe?

[Litcube]

Yes.

[Treelor]

I just wanted to pop into the thread to say that this is a fantastic script so far, and seems to work rather well with Improved Races for me. I don't seem to be having any issues what-so-ever (but its possible I've had the job glitch from v29, but have never observed it). Keep at it! FPS improvements in X3 are always welcome.

[glenmcd]

I took V0.30b for a run starting with a 42 minute vanilla PP, through to 5 hours. All the HQ sectors I looked at are now normal and framerate is good. Perhaps better as I seem to need to jerk my mouse just that little bit more to snap out of SETA. I find that's a good test of "smoothness", which isn't exactly the same as framerate.

I'm still getting a bunch of Escort ships in Heretics End that I don't remember seeing anything more than a month ago. May well be nothing to do with follow replacement but I'm going to verify this with another vanilla run. 25 identical escort ships that spawn in a shipyard sector, change sectors and then superimpose again isn't something I recall from way back. By superimpose I mean occupying the exact same point in space, no matter how much you zoom in.

EDIT:
I tried a run through PP with all my usual mods except follow replacement. I still got the 25x ATF Escort Thor group so this means that they're nothing to do with Litcube's follow code. Yay!
Going back for more V0.30b testing..

[glenmcd]

Litcube this V0.30b is working just great. With all NPC ships destroyed I get 390 fps in UK sector. With NPC ships as normal, it's sustaining 360+ fps. Less than ten percent increase in framerate with all NPC ships destroyed? Seems pretty amazing to me. And I hadn't seen over 300 fps sustained before either. I started the current mod'd game from a 52 minute vanilla save and now 17 hours and 144 sectors in with Terran missions complete. The more I played, the smoother and faster it became. Perhaps if I'd used V0.30b from the start it would be even better? The performance increase hasn't levelled off yet. Makes me think V0.30b is doing some killing of its own hehe. j/k

[joelR]

Litcube this V0.30b is working just great. With all NPC ships destroyed I get 390 fps in UK sector. With NPC ships as normal, it's sustaining 360+ fps. Less than ten percent drop in framerate with all NPC ships destroyed? Seems pretty amazing to me. And I hadn't seen over 300 fps sustained before either. I started the current mod'd game from a 52 minute vanilla save and now 17 hours and 144 sectors in with Terran missions complete. The more I played, the smoother and faster it became. Perhaps if I'd used V0.30b from the start it would be even better? The performance increase hasn't levelled off yet. Makes me think V0.30b is doing some killing of its own hehe. j/k

I have a pretty old rig, but relative to my computer there is a noticeable increase in performance. I recently made some major cuts to the "unleashed no civs for SRM" jobs file that vkerinav wrote and it runs incredibly well. I use IR, PG and Brennans Triumph Tortuga and all of these can add a ton of ships so thats why I trimmed down the jobs. I am also using the no convoy test mod you created glen.

So yeah, runs really smooth so far.

[Litcube]

Good to hear everything is running smoothly. Thanks for the detailed reports, guys. I really appreciate it.

[joelR]

Good to hear everything is running smoothly. Thanks for the detailed reports, guys. I really appreciate it.

I keep thinking something terrible is going to happen. How is it this was never discovered earlier?

[djrygar]

Another thing: Saw a pirate M1 with 35 docked in Nopilieos Memorial getting hammered on by several Xenon ships. None of them launched. Could this be a bug?

Litcube,

It appears that the M1s that hang at 0ms with a full load of docked fighters are ones spawned by IR. Its the ships with "Response" in their names. So it may be an IR bug although I have not seen it reported in the IR thread so im leaving it here in case its a conflict with your scripts. I can confirm that when attacking other M1 they launch their docked fighters normally.

-joelR

I just noticed that

I have spent weeks tracking this down, and I thought I am the only one that experienced this, now I read your post, as I decided to go trough entire thread as scripts seems great

Yep, there is 0m/s bug. But the problem is - I havent installed this script!

Yet, this problem started to appear few weeks ago. After I installed updated:
SRM + CMOD + some accompanying scripts
JObs + EES

after some debug-loggin here is what I found:
IR scripts that are affected are
plugin.ir.job.jumper (the response ship)
plugin.ir.job.striker (assault ship)

and it only concerns ships with carrier bays

particularly this subroutine:

Code: Select all

UnloadDocked:
$len = size of array $Docked
while $len 
  * = wait 10 ms
  dec $len =
  $ship = $Docked[$len]
  if not $ship 
    remove element from array $Docked at index $len
    continue
  else if not $ship->exists
    remove element from array $Docked at index $len
    continue
  else if $ship->is docked
    = wait 50 ms
    $x = [THIS]->get x position
    $y = [THIS]->get y position
    $z = [THIS]->get z position
    $ship->put into environment [SECTOR]
    $ship->set position: x=$x y=$y z=$z
  end
  if not $target->exists
    break
  end
  $ship->start task 0 with script 'plugin.ir.job.carrier.fighter' and prio 99: arg1=$target arg2=$this arg3=null arg4=null arg5=null
end
endsub

actually the line:

Code: Select all

  $ship->start task 0 with script 'plugin.ir.job.carrier.fighter' and prio 99: arg1=$target arg2=$this arg3=null arg4=null arg5=null

crashes both scripts. plugin.ir.job.carrier.fighter was normally naunched with prio 70 I changed it to 99 for tests (originally it was 99 as 7ate wrote it, but I changed it to 70 following SerialKicked's advice)


So, above line after installing EES crashes the script that controls carrier
I have yet to determine it for 100%, I just have set up new install without wkerinasv's jobs and ees, then I'm going to add it again

[Litcube]

actually the line:

Code: Select all

  $ship->start task 0 with script 'plugin.ir.job.carrier.fighter' and prio 99: arg1=$target arg2=$this arg3=null arg4=null arg5=null

The reason you're seeing a crash is because the coder is removing elements from an array during iteration in that loop you just posted. This is a no-no, and it's probably trying to START scripts on an invalid object, which will cause a crash. This is caused by removing elements from an array during iteration. Which is a no-no.

[Jack08]

actually the line:

Code: Select all

  $ship->start task 0 with script 'plugin.ir.job.carrier.fighter' and prio 99: arg1=$target arg2=$this arg3=null arg4=null arg5=null

The reason you're seeing a crash is because the coder is removing elements from an array during iteration in that loop you just posted. This is a no-no, and it's probably trying to START scripts on an invalid object, which will cause a crash. This is caused by removing elements from an array during iteration. Which is a no-no.

The removal of elements in an array during Reverse Iteration is fine... as the code is using reverse iteration ($Size to 0, not 0 to $Size), nothing will be invalid

Forward iteration however, yes that would be a problem

[djrygar]

The reason you're seeing a crash is because the coder is removing elements from an array during iteration in that loop you just posted. This is a no-no, and it's probably trying to START scripts on an invalid object, which will cause a crash. This is caused by removing elements from an array during iteration. Which is a no-no.

no, because invalid object wuld result in script running on null, and because it has additional check inside (skip if [this] -> return null) and terminate. No problem with that
besides, there are 2 check prior to running it

and:
this part is actually very old code, it was written by 7ate and working for years. I dont think there is something wrong with it.

I have poked around EES and see nothing that could interfere with IR, as in original version there is no EES support (Jack introduced it in IR:CE if I'm not mistaken). Only idea that I have and havent checked is to check for next available task, will do that.

one thing for sure:
VanillaRewriteV0.30b or earlier have nothing to do with those 0m/s carriers, so you may check this out of list

edit:
if I find out if EES has some problems or not with IR, will post about it in EES thread

[aka1nas]

The reason you're seeing a crash is because the coder is removing elements from an array during iteration in that loop you just posted. This is a no-no, and it's probably trying to START scripts on an invalid object, which will cause a crash. This is caused by removing elements from an array during iteration. Which is a no-no.

no, because invalid object wuld result in script running on null, and because it has additional check inside (skip if [this] -> return null) and terminate. No problem with that
besides, there are 2 check prior to running it

and:
this part is actually very old code, it was written by 7ate and working for years. I dont think there is something wrong with it.

I have poked around EES and see nothing that could interfere with IR, as in original version there is no EES support (Jack introduced it in IR:CE if I'm not mistaken). Only idea that I have and havent checked is to check for next available task, will do that.

one thing for sure:
VanillaRewriteV0.30b or earlier have nothing to do with those 0m/s carriers, so you may check this out of list

edit:
if I find out if EES has some problems or not with IR, will post about it in EES thread

I thought IR:CE has CWP integrated, rather than EES?

[TrixX]

I thought IR:CE has CWP integrated, rather than EES?

Correct

[mod.man@verizon.net]

EDIT4 : Added more information about possible cause of problem
EDIT3 : Added possible fix i hope. Please check my work and make sure i'm not doing something stupid that makes it appear to fix the bug.
EDIT2 : Removed extra /code tag cause im noob
EDIT1 : Added Stack Information

I started a new game using 0.30b and ran into a problem that i can reproduce. I haven't looked into the script to see if i can find the problem yet but that will be step 2.

// UPDATE 1
I did some more checking and a single fighter will dock correctly using the same commands. But when the same fighter is added to a wing it will exhibit the bug. Revised steps to cause the bug to happen.

1) spawn Cerberus or any MT i assume will work.
2) spawn a rapier fighter and make sure it has fight-command software mk1 and 2
3) add fighter to blue wing
4) set there command to attack target nearest the Cerberus

//Steps to cause problem - Vanilla install patched to 3.1 with 0.30b and LV's //cheat scripts
//1) spawn Cerberus or any MT i assume will work.
//2) spawn 8 rapier fighters and make sure they have fight-command software mk1 and 2
//3) add all 8 fighters to blue wing
//4) set there command to attack target nearest the Cerberus

The fighters will attempt to dock with the Cerberus and there active command will switch between attack nearest target and dock at Cerberus. This will cause the ships to stutter back and forth and never dock at the Cerberus when there are no bad guys around.

If you dock the ships manually and then set them to attack nearest target of the Cerberus they will stay docked. So my very uneducated guess is the error happens because the docking script is returning before the ships actually dock and are going into the idle state of the attack nearest target command before they dock. I am going to take a look at the scripts and see if i can locate the problem.

If someone else can reproduce this error i would be grateful. That way i know i'm not screwing it up myself somehow.

Stack States for the states they are swapping between

// Fighter State 1

Code: Select all

---Script Task ID = 0 ------
PID = 428508
Prio = 0
Interrupts = Enabled
IntReq = no
Stack Depth = 2

Current Stack: [script at bottom runs]
1: !ship.cmd.attacknearest.pl prio=0
2: !ship.cmd.attacknearest.std prio=0
3: !move.follow.template prio=0

// Fighter State 2

Code: Select all

--- Script Task ID = 0 -----
PID = 426805
Prio = 0
Interrupts = enabled
IntReq = no
Stack Depth = 4

Current Stack: [script at bottom runs]
1: !ship.cmd.attacknearest.pl prio=0
2: !ship.cmd.attacknearest.std prio=0
3: !move.follow.template prio=0
4: !ship.cmd.movestation.std prio=0
5: !move.movetostation prio=0

// Stack state for Cerberus

Code: Select all

---Script Task ID = 587 ----
PID = 279273
Prio = 10
Interrupts = enabled
IntReq = no
Stack Depth = 0

Current Stack: [script at bottom runs]
1: Lib.Cmd.LeadShipWingMonitor prio=10

// Update 2
Reset scripts folder back to default and installed version 0.26b to create a log file just in case it helps. Problem occurred in .26b using same steps as above. http://pastebin.com/qP5Ef5Ni Log file was bigger then paste-bin site allowed so i copied only the entries that occurred once my ship showed up in the log.

// Update 3
Either i fixed the bug or i broke the game so badly that it now works correctly. So if i packed the script correctly (my first time making a pck file) then this fixed the bug. Not sure why invoking the base function directly fixed it while calling the wrapper didn't work correctly. Please check my work.

!move.follow.template

Code: Select all

  if [THIS]->has same environment as $Lead
    if $Lead->is docking possible of [THIS]
      = [THIS]->call script '!move.movetostation' : targetstation=$Lead   <-- changed it to this line instead of the one below.  
      * mod= [THIS]->call script '!ship.cmd.movestation.std' : object=$Lead
      if [ENVIRONMENT] == $Lead 
        [THIS]->set pirate cover state to [FALSE]
        = wait 999999 ms
      end
      continue
    end
    [THIS]->set pirate cover state to [FALSE]
    = [THIS]->escort ship $Lead
  end

// Update 4
I think i found the line of code that causes the problem with the wrapper function.

!ship.cmd.movestation.std

Code: Select all

[THIS]->set command: {COMMAND_DOCKAT}  target=$object target2=null par1=null par2=null 

[THIS]->set destination to $object 
= [THIS]->call script '!move.movetostation' : targetstation=$object 
[THIS]->set destination to null 
return null 

The first line of code [THIS]->set command: {COMMAND_DOCKAT} target=$object target2=null seems to be the problem.
If i comment out this line and repack the file and use the original 0.30b scripts everything works perfectly. I don't know enough about the system to make a informed decision as to why this line of code causes a problem. But calling the base function seems to solve the problem so no need to change this really. Who knows what might break if it gets changed.

From the MSCIHandbook the set command function is really for information purposes only so why is it affecting the state of the object??!

[joelR]

This is interesting. I recently noticed that when issuing an attack command from my homebased fighters docked at my TM they will invariably revert to a "dock at xxx" if there are no enemies. Not sure if its related to 30b or not though.

[Litcube]

EDIT3 : Added possible fix i hope. Please check my work and make sure i'm not doing something stupid that makes it appear to fix the bug.

Modman, fantastic science. I will reproduce and fix this.