Discussion 0m/s seta lag IS combat freezes

The place to discuss scripting and game modifications for X³: Terran Conflict and X³: Albion Prelude.

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

User avatar
Litcube
Posts: 4254
Joined: Fri, 20. Oct 06, 19:02
xr

Post by Litcube » Wed, 14. Jul 10, 01:54

LV wrote:it being a cpu issue is not really the question, the question is is it a cpu issue because i've written ****** coding
LV,

Apologies if this isn't relevant:

I don't believe you've written shit code, but I alsofeel that this isn't a CPU issue. I strongly believe that run on a super computer, anyone would experience the very same "0m/s issue"

The engine has a limit as to how many script can simultaneously fire at the same time. And I believe your code and mine use the same default fight.attack.object, and the same vanilla turret scripts for NPC ships.

While OOS, a single ship, regardless of its turret configuration, is a single (1) script footprint on the script run engine.

Throw the same ship into an active sector, and in the case of a capital ship, it's now an 8 script footprint. So how in an LV's RRF vs. Litcube's Revelations, you now have about 250 ships times an average of 6 turrets. That's a 1500 script footprint.

Not only that, but the script they're running are worst case scenario: turret scripts have the smallest @wait= window of all vanilla scripts. And I suspect there's an upper limit for script "waiting" to get their turn. If that upper limit is met, the engine says %$# it, we continue, because we can't wait for those losers, and we can't use valuable CPU time, lagging the players experience.

I would suspect that adding 15 secconds between target aquisition checks in the vanilla turret scripts would significantly reduce the issue, but I've yet to test it. Maybe I should.

EDIT: Maybe splitting this off to a seperate thread would generate some interest in the issue (if you feel it's not relevant, that is).

User avatar
Serial Kicked
Posts: 3823
Joined: Fri, 12. Aug 05, 20:46
x3tc

Post by Serial Kicked » Wed, 14. Jul 10, 02:20

If i may, I'd vote "yes" to a specific topic related to default script speed improvement and reducing job count and related ideas.

I've followed what you were telling in your own topic Litcube and knew about the changes made by [forgot his name] to the jobs file. Lot of good stuff. On the other hand, i have a kinda crappy computer and even by spamming tons and tons of fighters (in the hundreds) I've yet to see ships completely halt. The whole game slow down a lot of course, but i've never seen ships going to a 0m/s (apart from a random docking issue/bug, unrelated to processing power).

In my experience, the wait time is a window of opportunity for another (or several) script(s) to kick in. If the script that took the hand takes longer than the wait.time then, the initial script will only have to wait longer. So i don't really see how it would cause the game to start skipping scripts or objects. Slow down i understand very well, but stop i don't know.

The "Fleet Fest" contest in the general board made several battles with "spam" fleets (like 300 fighters vs several capital), causing a general slowdown of turrets and the whole game (apparently) but here again there's apparently no 0 m/s (reported at least, which is not a proof i admit).
X3:TC/AP Pirate Guild 3 - Yaki Armada 2 - Anarkis Defense System

Anarkis Gaming HQ
Independent Game Development
X3 Scripting and Modding Station

Ragemaster9999
Posts: 240
Joined: Mon, 17. May 10, 08:53
x4

Post by Ragemaster9999 » Wed, 14. Jul 10, 02:45

I experienced this 0 ms issue, I considered it only a minor issue as I was crashing and getting lots of other wierd problems, but it all started when argon invaded interworlds, who the paranid had captured earlier in the game. I stuck around to see what was up, I saw three M1 carriers each with 100 fighters, though some of them were named as drones. Then there was about 5 strikeforce destroyers, that were attacking the paranid trading dock. Many more assorted frigates and 10+ corvette size ships all running amok in interworlds. paranoids initially had only 2 destroyers and mostly fighters in the system but RRF brought in 10+ paranid capital ships. It actually brought the game to its knees perhaps overdoing x3tc engine..

I actully had to jump out of system because being in system was causing too many problems. Though I did notice that some of the capital ships started "freezing" during the battle, the 5 strikeforce destroyers on the paranid station actually stopped fireing at 10% structure and kind of just froze in time. The carriers seemed to be pulling all the game resources, 3 for argon and 3 for paranid with 600+ combined fighters it was real laggy to say the least. I checked the perfmon for my pc to see , and the game wasnt even running at max memory or cpu... so maybe the x3 engine was simply pushed past its breaking point?

User avatar
Litcube
Posts: 4254
Joined: Fri, 20. Oct 06, 19:02
xr

Post by Litcube » Wed, 14. Jul 10, 05:00

Serial Kicked wrote:On the other hand, i have a kinda crappy computer and even by spamming tons and tons of fighters (in the hundreds) I've yet to see ships completely halt. The whole game slow down a lot of course, but i've never seen ships going to a 0m/s (apart from a random docking issue/bug, unrelated to processing power).
Totally surprised to hear this from someone with your experience. In actual fact, I can reproduce this issue with purely Vanilla scripts. I can throw 300 ships in the center of a sector with default loadouts, !fight.attack.object, and eventually, 50% of them will stop. You have to pay attention, though. View them, and F3 the camera. This issue is very real, but the environment in which it takes place is entirely uncommon. Did you.. count the ships when you experienced the same environment?
Serial Kicked wrote:In my experience, the wait time is a window of opportunity for another (or several) script(s) to kick in. If the script that took the hand takes longer than the wait.time then, the initial script will only have to wait longer. So i don't really see how it would cause the game to start skipping scripts or objects. Slow down i understand very well, but stop i don't know.
In Reunion, if you ran too many scripts, OOS ships would sometimes stop moving. It's as though the game has a threshold for it's "queue" (the scripts waiting for a @=wait). Total conjecture.
Serial Kicked wrote:The "Fleet Fest" contest in the general board made several battles with "spam" fleets (like 300 fighters vs several capital), causing a general slowdown of turrets and the whole game (apparently) but here again there's apparently no 0 m/s (reported at least, which is not a proof i admit).

Few things on the 0m/s issue:

1) This happens in sector only
2) Confirmed with default vanilla scripts. !fight.attack.object, !turret.killenemies.adv, !turret.missiledefense.adv
3) Starts happening at roughly 1000 - 1500 script footprint in the sector at a time (total number of turrets in the sector)

I mentioned in another thread that I rewrote the !fight.attack.object script and increased the delays of the turret commands.

Before script rewrite: up to 90% ships 0m/s'd out.
After script rewrite: No ships at 0m/s

(confirmed with a global script displaying the count of the number of ships in the sector flying at 0m/s, updated by subtitle text every 1 second.)

User avatar
LV
Sith Lord
Posts: 8255
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by LV » Wed, 14. Jul 10, 16:54

Split topic :)

Interesting, never thought to look behind the vanilla code until now, fight.a.o and acp.f.tacs hold muchos coding

The thing for me is i've had a shed load of ships IS and no issue (only getting 0m/s now with seta on)

then yesterday a couple of rrf ships and a hefty invasion fleet and 0m/s

i don't know much about turrets at all but i also am wondering what missile spamming effects.

I;d be happy to test a simpler fight script is someone was to make one

going off to test having no rrf bombers and have a look at the fight logic in a simpler fashion

In addition my turrets are MARS controlled

Finally i'm still of the opinion that using any form of jump command may link into the issue, no other reason than my force powers telling me as such
LV's TC Scripts
Readme's For All My Scripts


I felt a great disturbance in the forum, Like millions of voices cried out in terror, then were silenced

si tacuisses, philosophus mansisses

User avatar
Gazz
Posts: 13244
Joined: Fri, 13. Jan 06, 16:39
x4

Post by Gazz » Wed, 14. Jul 10, 18:39

The "0 m/s" issue is from the attack run instruction running out and the script not getting into the "CPU queue".

The attack run has a timeout. If that runs out, the ship stops. That part works as designed.
This timeout must be rather small because it's also the rate of fire for a fighter's cockpit lasers.

The same happens with the turret instruction "turn turret toward X".

The interesting bit is, that pending attack and turn turret instructions have a lower priority than others.

When MARS detects that the turret scripts have frozen, it temporarilly switches into "bug override" mode, where the turn turret instruction is outsourced to another task which has no other function than show. If it hangs - so be it. The script doesn't care and is no longer affected by this instruction locking up the whole script.

Turrets still work normally when that happens, which leads me to believe that not certain task IDs are prioritized but particular script instructions.

Trouble is, how do you replace the attack run instruction? =P
My complete script download page. . . . . . I AM THE LAW!
There is no sense crying over every mistake. You just keep on trying till you run out of cake.

User avatar
Nafensoriel
Posts: 486
Joined: Mon, 3. May 10, 20:30
x4

Post by Nafensoriel » Wed, 14. Jul 10, 19:32

(feels like a chihuahua surrounded by mastifs)

This is not entirely limited to IS. It takes a ton more abuse but you can get OOS ships to stop dead in their tracks while SETA is active. Found this out rather late in my first round when I learned about the "SETA+UT=make money" exploit or whatever term seems appropriate. I found that this was an impossibility for me because on SETA random ships would just stop dead and do nothing as long as SETA was active. It is amusing to watch an M5 literally
blow up a destroyer entirely by itself over several minutes.

As a question though.. and pardon my stupidity for asking this.. but why is a timeout needed? To prevent a 200km attack run?
"A Tradition is only as good as it's ability to change." Nael

User avatar
LV
Sith Lord
Posts: 8255
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by LV » Wed, 14. Jul 10, 19:38

Hmn, just re-wrote a fight script so rrf does not use vanilla, all i did was below and i expected jack to come from it, i even managed to candy it up with defensive moves and such

i didn't link the enemy checks which are covered by other scripts

Code: Select all

014   while $enemy -> exists
015    $sec = $ship -> get sector
016    $ensec = $enemy -> get sector
017    skip if $sec == $ensec
018     return $anull
019    $attacker = $ship -> get attacker
020    if $attacker -> exists
021     $spc = $ship -> get shield percent
022     if $spc < 65
023      $rv =  = random value from 1 to 11 - 1
024 @    = $ship -> defensive move: type=$rv, intensity=99, timeout=2343ms, avoid object=[TRUE]
025 @    = wait randomly from 2400 to 2700 ms
026     end
027    end
028 @  $run = $ship -> attack run on target $enemy : timeout=30000 ms
029    $i = 0
030    while $i < 5
031     skip if not $ship -> is $enemy in firing range of turret 0
032      = $ship -> fire lasers on target $enemy using turret 0
033     inc $i = 
034    end
035 @  = wait randomly from 100 to 200 ms
036   end
up to now it's working very well and doing everything expected although rrf covers many things hidden in fight.attack.object and it's child scripts

i'd say something positive here but that would only mean the next time i load up rrf i get a ctd so i'm saying nothing
LV's TC Scripts
Readme's For All My Scripts


I felt a great disturbance in the forum, Like millions of voices cried out in terror, then were silenced

si tacuisses, philosophus mansisses

User avatar
Serial Kicked
Posts: 3823
Joined: Fri, 12. Aug 05, 20:46
x3tc

Post by Serial Kicked » Wed, 14. Jul 10, 19:39

@litcube:
Overloading the game with tons of jobs is counter-intuitive to me, that's why :p still, I dunno how i missed it before.

Re-tried today in a simulated environment, with the head clear from days of unrelated coding. Double ships (300 vs 300 dual turret ships; in roid heavy sector; attack.all + turrets orders). And I managed to reproduce the issue, several ships went 0m/s, the sector map skips a bunch of frame refreshes too. I also noticed that most ships in my list did 0m/s, accelerated to 10-20m/s before halting again. The less ship still alive, the more it accelerated before going back to zero. so yeah the 'attack run' (attack run for xxx ms) is unable to accelerate the ship before the countdown runs out.

Gazz's right as usual. All the move/turn ship/turret commands seems to be affected.

Has someone tried to increase the attack.run and other "low level" move / turn commands timers (a lot) instead of increasing the wait times in other parts of the script ? (yes i guess i could right now) - LV did :)

Edit: LV, why the lines 29-34 ? IIRC "attack run" returns a "FireFree" if the ship is ready to fire.

Edit2: Another untried random idea:

In sector, wait times and timeouts in "vanilla" scripts could be proportional to the amount of ships in the current sector. It may help too (yeah i know it's processor dependent but still).
Last edited by Serial Kicked on Wed, 14. Jul 10, 20:32, edited 2 times in total.
X3:TC/AP Pirate Guild 3 - Yaki Armada 2 - Anarkis Defense System

Anarkis Gaming HQ
Independent Game Development
X3 Scripting and Modding Station

Guest

Post by Guest » Wed, 14. Jul 10, 20:07

you know to really test to see if its the engine having a cap on the amount of simultaneous scripts alowed to run, why not make a mod that has everything in very very low definition. i mean like a destroyer being a big cube and a fighter being a little cube, so that there is only a little pressure on the actual computer since tthere are barely any graphics to load. if when 500 ships are present, the computer is still running fine and some ships start to fail, that would be hard evidence pointing at a cap.

User avatar
Gazz
Posts: 13244
Joined: Fri, 13. Jan 06, 16:39
x4

Post by Gazz » Wed, 14. Jul 10, 20:07

What might help is to restructure the script so attack run and cockpit lasers run on separate tasks.

If the attack run can work on a 30k timer like in LV's example, the "critical" bit would have a high chance of remaining active because it doesn't need to catch the script interrupt very often.
Under normal conditions the attack run would probably always run until the "break away" condition kills it.
It wouldn't fix the actual "bug" issue, only cover it up more carefully.

Weapon fire and "is $enemy in firing range of turret" would obviously require a pretty fast timer but not all the time.
If we allow for some reaction time, the script might check for "in range" every 2 sec. Only if that happens, it enters the faster autofire loop.

On the whole this might actually save a lot of CPU time because atm, the fight script has to run fully everytime a bullet can potentially be fired.
This is the simplest way to organise it but... madness.

In the MARS script I made a plan for which script would do what, on which task, and on what kinda timer to minimize the CPU use.
Target acquisition is centralised for the whole ship and firing turrets use a system much like described above.
Tactical decisions like switching targets or checking whether the target is still in turret range (= a lot of math) run on a slow timer while the task that does little but pull the trigger runs on a rather fast one.

So the task that runs often is a tiny script where one "pass" does very little, especially no 3D math, range checks, or anything lengthy.

It's the only way MARS can work at all.

why is a timeout needed? To prevent a 200km attack run?
Any instruction without a timeout has the potential to get stuck when it encounters an impossible condition, like being unable to catch the target.
My complete script download page. . . . . . I AM THE LAW!
There is no sense crying over every mistake. You just keep on trying till you run out of cake.

User avatar
Serial Kicked
Posts: 3823
Joined: Fri, 12. Aug 05, 20:46
x3tc

Post by Serial Kicked » Wed, 14. Jul 10, 20:31

This is the simplest way to organise it but... madness.
why the "madness" about seperate shoot/move commands ? It's just an additional task which could be directly called by the altered vanilla script if not already found running on the object. I find this solution quite elegant tbh.
Target acquisition is centralised for the whole ship and firing turrets use a system much like described above. Tactical decisions like switching targets or checking whether the target is still in turret range (= a lot of math) run on a slow timer while the task that does little but pull the trigger runs on a rather fast one.
This is more or less what I'm doing to coordinate anti missile lasertower activity around a pirate base (in the unreleased PG version) to avoid cpu overload due to flail missile spam. The base has a relatively slow timer and gives small lists of targets to the different LT (who becomes nothing more than mindless automatons). Works wonder.
Last edited by Serial Kicked on Wed, 14. Jul 10, 21:38, edited 1 time in total.
X3:TC/AP Pirate Guild 3 - Yaki Armada 2 - Anarkis Defense System

Anarkis Gaming HQ
Independent Game Development
X3 Scripting and Modding Station

User avatar
Gazz
Posts: 13244
Joined: Fri, 13. Jan 06, 16:39
x4

Post by Gazz » Wed, 14. Jul 10, 20:44

Serial Kicked wrote:why the "madness" about seperate shoot/move commands ? It's just an additional task which could be directly called by the altered vanilla script if not already found running on the object. I find this solution quite elegant tbh.
The current way is, with each cycle executing large parts of the whole fight script until it gets to the one fire laser line that matters.

That's a lotta lines to pass through an interpreter.

OTOH, I gotta admit that it is the simplest way to organise the script. One script, no branching, easy to debug.
Planning and tuning a compartmentalised script and the communication between the subscripts take a lot of coding time and there are always... surprises. =P

It's typically the coder's boss who decides that simple (and making the deadline) is better than perfect...
My complete script download page. . . . . . I AM THE LAW!
There is no sense crying over every mistake. You just keep on trying till you run out of cake.

User avatar
LV
Sith Lord
Posts: 8255
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by LV » Wed, 14. Jul 10, 22:39

Serial
29-34 were simply because i have not played with fight scripts before and i saw an m6 messing about 1 shotting a ship so it thought i'd give it a try, maybe it was irrelevant, maybe it came in handy who knows when you poking your hand into the abyss

all i know is during my testing my rrf m6's did much better attacking but x has the abilty to lure you into a false sense of coding before shafting you for no reason
LV's TC Scripts
Readme's For All My Scripts


I felt a great disturbance in the forum, Like millions of voices cried out in terror, then were silenced

si tacuisses, philosophus mansisses

User avatar
ezra-r
Posts: 3420
Joined: Fri, 14. Oct 05, 21:04
x4

Post by ezra-r » Thu, 15. Jul 10, 00:36

Excuse my interruption people, I have no idea about coding.

The only scripts I have installed in my game are MARS, the abandoned ship spawner, and the complex packager by gazz, rest is just pure modding.

And even so the game AI reduces full throttle back and forth while on SETA, not much, but I can notice.

My cpu is a Intel Core Duo e6600, so it's not a weak cpu.

Could it be an engine limitation rather than *** script coding?

User avatar
Serial Kicked
Posts: 3823
Joined: Fri, 12. Aug 05, 20:46
x3tc

Post by Serial Kicked » Thu, 15. Jul 10, 00:55

I'll try to explain that in non cryptic terms because you've misundertood our discussion. It's not crappy script coding it's more an overload of the game engine by extension your CPU due to the amount of jobs it has to do.

Ship jobs and scripts don't really execute simultaneously, in fact we tell the engine when our scripts / jobs can be interrupted by another one with a command called "wait xxx ms". Script A will do a few instructions, then script B will kicks in, then C, then it'll be the turn of A to resume. It gives you the feeling that all jobs are run at the same time, but it's not in fact. The system works relatively well under normal circumstances (at least when a noob scripter don't make mistakes). This is only a part of the issue here.

The other part of the issue is related to low level script commands (defensive move, follow ship, attack run, etc etc.) used by most, if not all the jobs and ship commands. Those commands come with a timeout (defensive move for XXX milliseconds) so we (and vanilla scripts) can take back control after the order. The issue, when the computer is over stressed, is that they reach the timeout way before they even started to do anything. And so the 0m/s "bug" appears.

I hope it's clear enough :)


EDIT: See Below, good example about noob dangerous mistakes. Still contrary to what djrygar just said, if you delete all the related task in the script global task manager (delete key) it should clear the issue (don't quote me on that) without having to restart.
Last edited by Serial Kicked on Thu, 15. Jul 10, 07:42, edited 5 times in total.
X3:TC/AP Pirate Guild 3 - Yaki Armada 2 - Anarkis Defense System

Anarkis Gaming HQ
Independent Game Development
X3 Scripting and Modding Station

djrygar
Posts: 1841
Joined: Mon, 10. Aug 09, 02:09
x3ap

Post by djrygar » Thu, 15. Jul 10, 01:27

ezra-r wrote:, the abandoned ship spawner,
remove this one, it will choke script engine after long time (check your 'running scripts' in script editor to see for yourself), its bugged and does not finish after launched by AL, so after longer time of play you will have hundreds of tasks running. New gamestart needed ;)

User avatar
Aro
Posts: 2765
Joined: Tue, 15. Jul 03, 00:35
x4

Post by Aro » Thu, 15. Jul 10, 01:35

Max script footprint seems to be based on the users computer.

Is it possible to get vanilla-like behavior in an optimized fight script?
If only there was a way to determine an individual computer footprint then limit battles to be within a safety margin.

Could also use that to figure out maximum fleet configurations for the next XFF.

User avatar
Nafensoriel
Posts: 486
Joined: Mon, 3. May 10, 20:30
x4

Post by Nafensoriel » Thu, 15. Jul 10, 03:32

I'm more interested if all scripts impacted by this load issue can be bypassed in a manner similar to MARS. Sadly I think it might be a bit much to ask donated rewrites of the vanilla scripts after looking at them.

However if this little snag is solved it might go a long way to reducing many peoples problems with performance especially on lower end processors. At the very minimum it might at least allow more complex scripts with less visual impact.
"A Tradition is only as good as it's ability to change." Nael

Kadatherion
Posts: 1021
Joined: Fri, 25. Nov 05, 16:05
x4

Post by Kadatherion » Thu, 15. Jul 10, 12:05

Serial Kicked wrote:I also noticed that most ships in my list did 0m/s, accelerated to 10-20m/s before halting again. The less ship still alive, the more it accelerated before going back to zero
Which seems the same issue I experienced with some RRF ships after a (rather small in ships number) engagement some days ago. As I reported to LV in his RRF thread, it affected a Python+his fighters after they cleaned out a small xenon invasion triggered by Race Invasions.

The strange thing here, for what I could understand of the problem from a scripting virgin point of view, is that in that case I didn't see any issue while the actual combat and related scripts were running, that strange behaviour began after the xenon were wiped out. As such, I don't think the RRF ships had any reason at the moment to try any "attack run", and in any case there shouldn't have been that much going on under the roof since the sector was cleansed... unless there were some "blue" enemies to the split I didn't notice :roll:



As for what I've experienced with Litcube's Revelations, should it ever mean something useful to the scripting gurus here trying to crack down the issue, in that case I had the full 0m/s behaviour without any hiccup moving, but it looked like the engine began stopping the smallest ships first. With also RRF installed, in fact, most fighters got to an halt while the battle ensued while M6s and bigger ones seemed to work fine; when I took RRF out and thus lightened the script load, however, it happened again in almost every battle, but affecting only M5s.

I've got also to say I didn't spot at the same time turrets stop working, but in that chaos it could very well have happened to smaller crafts turrets (like M3s) without me being able to notice. I'm not using MARS at the moment, but Gazz's much simplier "antimissile" turret script, Missile Defense Mk2, which replaces only turret missile defence and turret attack enemies commands.


Anyway, just summarizing my experiences with this annoying issue in the last days here in a single place, should there be any useful clues somewhere. :wink:

Post Reply

Return to “X³: Terran Conflict / Albion Prelude - Scripts and Modding”