[TOOL] X3 Customizer 3.15

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

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

Post Reply
TechSY730
Posts: 115
Joined: Tue, 26. Jul 16, 02:51
x3ap

Post by TechSY730 » Tue, 31. Jul 18, 20:39

One minor nitpick. The glowy trimming for gates in the hub, IIRC, are supposed to yellow/amber (maybe the fields too, but it is hard to tell if they really changed color or its from the ambient light from the yellow bits) But the new models make them blue like normal gates. Is there any easy fix for that?

SirNukes
Posts: 384
Joined: Sat, 31. Mar 07, 23:44
x4

Post by SirNukes » Tue, 31. Jul 18, 20:54

The options I like to use (and will be swapped to defaults in the next version):

Adjust_Gate_Rings(
standard_ring_option = 'use_plain_ring',
hub_ring_option = 'use_reversed_hub',
)

The hub gates have a quirk where one side has full protrusions for ships to collide with, and the other side has short stubs. By flipping the gate around, the stubs face the inside of the hub and should be a lot safer for traffic. Since it is the same gate, highlights will be unchanged, still amber. The portal field itself is the same blue as for normal gates.

TechSY730
Posts: 115
Joined: Tue, 26. Jul 16, 02:51
x3ap

Post by TechSY730 » Fri, 3. Aug 18, 05:25

Thanks for the setting tip. Those settings do indeed preserve the yellow trimming of the Hub gates.

Are you taking requests? If so, you know how some things that are technically classified as ships (like laser towers and orbital defense platforms) nevertheless keep their positions known if they go out of sensor range? If so, could you add an option that enables or disables this "stays known like a station would" property for arbitrary ships?

I think this would require obj changes, cause I can't find anything in the T files that seem to control it, but if it is a simple txt file tweak, let me know.

SirNukes
Posts: 384
Joined: Sat, 31. Mar 07, 23:44
x4

Post by SirNukes » Fri, 3. Aug 18, 08:50

Sure, I can take requests. It's my pleasure to serve, as long as I have a couple free hours I can set aside.

Updated to 3.11, adding Hide_Lasertowers_Outside_Radar.

I tracked down the related code, and it was indeed in the obj file as suspected. When ships are being checked for display on the sector map, a class group including lasertowers, satellites, beacons, and mines will skip the player ships' radar checks and just display if the object is known. I swapped the class group check to just cover satellites and beacons, so that jump beacons will still show up.

Initial in-game tests looked good, treating lasertowers like normal ships for sector display.

For orbital platforms, I am not sure where they are handled specially. A quick test in game, at least for XRM, has platforms disappearing when off radar. Edit: also tested vanilla and platforms disappear there as well.

TechSY730
Posts: 115
Joined: Tue, 26. Jul 16, 02:51
x3ap

Post by TechSY730 » Sat, 4. Aug 18, 16:43

I could of sworn that OWPs were preserved when "unseen but known" too.

Anyways, it sounds like the logic is only for certain kinds of flying wares. I was hoping it could work for ships too, and we could get a way to turn it on or off for arbitrary ships and wares, but I guess I was wrong.

Anyways, thanks for the tweak. :)

TechSY730
Posts: 115
Joined: Tue, 26. Jul 16, 02:51
x3ap

Post by TechSY730 » Sat, 4. Aug 18, 17:05

Oh, one more request.

Would it be possible to add an option for force "infinite loop detection" on for all script tasks? Or if that would be too high of a CPU burden, all tasks running on ships in the active sector (and global)? Or perhaps an option? (This would be in addition to the normal condition of "if the script asks for it")

I'm currently encountering a random freeze occasionally, and it is really hard to know which script is causing it. I imagine I am not the one that is having troubles like this. Being able to force infinite loop detection on would be very useful for debugging this.

EDIT: And there should be a way to turn it back off once you have found your issue
EDIT2: though I suppose that could be as easy as deleting the cat and running again

SirNukes
Posts: 384
Joined: Sat, 31. Mar 07, 23:44
x4

Post by SirNukes » Sat, 4. Aug 18, 23:37

Fortunately, I found the related code pretty quickly while heating up lunch. Infinite loop detection works by setting up a counter that decrements from 10k down to 0, then rolls back to 10k and reads the current game time. If time didn't advance between two instances of the the count hitting 0, this is considered an infinite loop. I'm not 100% sure, but the decrement might happen on any instruction, not just conditional loop branches.

Detection is disabled by setting the counter to 0. I can modify this 0 check to redirect to the post-decrement code (instead of skipping the entire detection section) to force loop detection on. Turning detection back off is more problematic. It can be disabled globally, but I don't see any way to preserve detection on scripts which manually turned it on.

If you are okay with only being able to turn it on globally for some debugging, I can set up a patch and test it a little later today.

TechSY730
Posts: 115
Joined: Tue, 26. Jul 16, 02:51
x3ap

Post by TechSY730 » Sat, 4. Aug 18, 23:49

Is the counter unique per task? Or is it a single global counter (aka, any script turning on infinite loop detection turns it on for all scripts)?

In any case, yes, any sort of way to force it on would be great. Even if it alters the save, I can just save right before the problematic situation and turn this on. It WILL cause false positives (since some legitimate loops do have to go over 10k instructions, like setup and uninstallation scripts). Maybe add a big disclaimer noting that this will probably break some longer running processing tasks, and it should be turned off before attempting those?


But if it is a single counter shared by all scripts, then something like this can be rather easily, albeit racy, unreliably, and inefficiently, implemented in MSCI only (have an infinite loop that sets infinite loop detection on and then waits 0ms to yield for other tasks). But having a reliable option would be nice.


EDIT: Oh, maybe a way to make the counter be set to different values (primarily higher) when infinite loop detection is enabled would allow for more robust, less false positive prone detection?

SirNukes
Posts: 384
Joined: Sat, 31. Mar 07, 23:44
x4

Post by SirNukes » Sun, 5. Aug 18, 07:11

Updated to 3.12, adding Force_Infinite_Loop_Detection.

Use with caution. As you pointed out, it would be best not to apply this to your main save; just use it for debugging on some test save. Any scripts that trigger a false positive are killed off, which can cause whatever related bugs.

The counter is per script instance. The 10k count can be changed, but it's written as a 2 byte value, so can only be bumped up to ~32k or so very easily. A simple idea for how to go higher occurred to me just after I pushed 3.12, so there might be a followup 3.12.1 if that idea pans out.

In my own brief test with XRM, I had 6 scripts false-positive on loading with the 10k limit, dropping to 3 false-positives with the 32k limit: OK Traders, SCS, and one XRM script failed. I didn't get much playtime in, though.

SirNukes
Posts: 384
Joined: Sat, 31. Mar 07, 23:44
x4

Post by SirNukes » Sun, 5. Aug 18, 10:30

Updated to 3.12.1. The Force_Infinite_Loop_Detection transform now takes 1 input argument: the number of operations between detection checks. This can go up to 2 billion or so, and is set to 1 million by default. In brief testing, this was enough to stop any false positives in my modded game.

A sample infinite loop ("while True end") still gets caught within a third of a second or so, though that is not using any complex operations. I'm not sure how long a real-life infinite loop would take to get caught; it depends on what it is doing.

In the background, the patching framework has been updated to support insert and delete patch operations. This was needed so that I could do a code shift to make room for the larger integer, while still being somewhat agnostic to the moved code so that the patch will be somewhat version independent (eg. works on LU).

TechSY730
Posts: 115
Joined: Tue, 26. Jul 16, 02:51
x3ap

Post by TechSY730 » Sun, 5. Aug 18, 22:39

Thank you so much. This should make it actually feasible to debug next time I get a freeze.

kecin25
Posts: 36
Joined: Sun, 13. Aug 17, 19:58
x4

Post by kecin25 » Thu, 23. Aug 18, 22:45

Ok so it keeps freezing and won't unfreeze even though the script is running

SirNukes
Posts: 384
Joined: Sat, 31. Mar 07, 23:44
x4

Post by SirNukes » Thu, 23. Aug 18, 23:50

Just to clarify on what's happening:

When you run the customizer, it should print "Succesfully ran Force_Infinite_Loop_Detection". This produces a new cat/dat pair, which will be loaded the next time you boot up the game. (Side note: if you "-clean" out the changes, the cat/dat are removed and the game needs to be rebooted again, otherwise it will fail to find the prior cat/dat pair when trying to load a save game and will print a false message about save game corruption.)

If you want to verify Force_Infinite_Loop_Detection is working, you can create a new script in game, call it something like "test.infinite.loop", and fill it with an empty "while [True] ... end". Running that will ping the log with the infinite loop detection message if things are working right, otherwise will freeze the game if the infinite loop detection isn't turned on.

The goal is to get that message to pop up for whatever LU script is freezing your game. One quirk of the infinite loop detection is that it works by counting the number of operations done by a script in a single time step, and comparing to some threshold. If the threshold is set too low, it falsely think some long scripts are infinitely looping when they aren't; if the threshold is too high, an infinitely looping script will pause the game for a long time before being terminated. You can adjust this threshold value using the argument to the Force_Infinite_Loop_Detection function, eg. Force_Infinite_Loop_Detection(100000) sets it to 100k. I have it set to default to 1 million operations to avoid false positives, but you can lower it to get bad scripts to fail out faster.

kecin25
Posts: 36
Joined: Sun, 13. Aug 17, 19:58
x4

Post by kecin25 » Thu, 23. Aug 18, 23:53

ok, where would I find the scripts that could be causing the problem? will they be in a folder or file somewhere?

SirNukes
Posts: 384
Joined: Sat, 31. Mar 07, 23:44
x4

Post by SirNukes » Fri, 24. Aug 18, 00:55

They are in addon/scripts as xml files. Editing is done with the in-game script editor or a tool like X-Studio (that may need an extra file for LU commands). I'm not sure how interested you are in messing with the script directly, but once you know which one is getting stuck in a loop then maybe someone else can help with patching it.

Post Reply

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