using on_entering_wormhole to delete wormhole pair, wont cause errors?

[Pancakelord]

I'm trying to refine my personal FTL balance mod to put on the workshop, part of that involves tweaking the bypasses, for wormholes I'm looking to do two things:

1. Have an N% chance to delete a wormhole after a ship has flown through it.
2. Spawn another pair of wormholes somewhere else in the galaxy (in systems that dont already have wormholes... or L-cluster flags, I guess).

This would mean that wormholes would regularly collapse and re-open around the galaxy as ships use them.
I'm looking at hooking in to an on_action to do this:

# Called upon entering FTL (on-action name scripted on the Bypass type)
# THIS = Fleet
# FROM = System jumping to
# FROMFROM = System jumped from
on_entering_wormhole = {
    events = {
        achievement.4
    }
}

achievement.4 is:

Now that block is called "on_entering", and seems to mostly reference the fleet entity doing the FTL jump, though looks like it could be re-routed to the host system, then back down to select (and delete) the wormhole.

But my main concern is if I tie in to that and instruct the game to delete a wormhole "on_entry" it might delete the wormholes before the ship can make the jump, or it might delete the WH whilst the ship is jumping (in the 1 day it takes) which may cause a crash... it may also be totally fine and i've mis-interpreted how this thing works. If nothing else adding a 2 day delay would be a (messy) solution I guess.
Wondering if anyone else has tried using this on action to screw with wormholes? before I get started and pin an event to it.

Essentially my event would:

1. fire each time a ship or fleet enters the WH and roll a 1-20.
   1. if it rolls 2-20 (95% chance) nothing happens, event aborts.
   2. if it rolls a 1 (5% chance), trigger wormhole is destruction, new WH pair creation.
2. if a 1 was rolled,
   1. fire event 2 - delete the wormhole pair (use from/fromfrom to scan for wormhole entities, need to double check how wormhole creation is handled and work backwards to prevent orphans)
   2. then fire event 3 - pick two other random star systems, which do not have wormholes already and are at least 2 systems apart, and spawn a new WH pair.
   3. if this spawned in your space maybe throw a notification at top of screen mentioning a new wormhole has appeared and is ready to be explored.

 

[G S Palmer]

Just try it and see what happens. Having the game crash while modding isn't the end of the world.

 

[OldEnt]

Are you using real bypasses or "just" ambient objects like MEM Vazuran raiding parties? Because I could not find a way to remove real bypass. I am really interested.

 

[Pancakelord]

Are you using real bypasses or "just" ambient objects like MEM Vazuran raiding parties? Because I could not find a way to remove real bypass. I am really interested.

Real. I dont like faking things, if I can use a real bypass, i'll use a real one. "effect remove_megastructure = this" will delete out any selected gateway, so thats an easy work around, for megastructure based bypasses (this is important as its the only type of bypass container i've confirmed being able to delete and remake so far, see below).

• Bypasses, are held "within" their parent StellarObjects, this is why removing a gateway megastructure will handily kill off the associated bypass connection, parent object gone ergo bypass gone.

spawning gateways and wormholes back in is also easy, although for some reason I cant find the main game initialisation event that handles gateways for galaxy generation.
"effect activate_gateway = yes" also ... activates gateways (ideally you'd want to do gateway restoration as it also fixes the 3d model).

activate_gateway acts upon the bypass entry attached to the gateway, rather than the gateway entity itself, this means even though that GW is wrecked (i had to console activate another broken one too)my science ship can now use it. You can even see the icon has changed to be active.

For wormholes, actual ones, spawning them is easy,

spawn A, Spawn B, link.

My tests with scripted connections showed it's possible to sever a wormhole and not have the game crash (I set up WHs using a ripped L-gate connection script with no nexus or node points to see what would happen ... nothing happened because they were unlinked or "orphaned" as the comments in the files refer to them) so in the event that I could somehow delete a wormhole, it wouldnt brick the game with an unhandled exception, which is nice.

So this all leads me to the idea that remove_natural_wormhole should in theory work, if I can scope to the wormhole in a system (for there is only ever one), select it and remove it... that should work.

• But in practice there seems to be a remove_planet and remove_megastructure command, but no remove_natural_wormhole command.
• IDK how natural_wormholes are defined in the game but they are definitely not planets or megastructures.

Theres also the hassle that comes from testing this as wormholes are special entities, so special i cant actually find where they're (natural_wormhole) defined, they cannot actually be selected in game and will auto move you to their mirrored counterpart unless you have not yet explored them:

there is also no remove_bypass = ID command or equiv.

So it is possible to remove bypasses - by removing the solar entity containing them (e.g. a megastructure [remove_megastructure] - or even a planet [remove_planet], such as setting up a "black hole network" or some BS), but it is currently impossible to remove natural_wormhole entities, specifically, because they do not seem to be planets, or megastructures and there is no specific command for removing them that I could find. Lord knows why.

• Fun fact - the only other things I've been able to find that are so un-alterable like this are
  • stellar classes (not the same as stellar types, stellar classes inform the solar graphic on the gal map),
  • solar systems themselves cannot be deleted
  • and empire flags cannot be changed directly from within game [you can save edit] as far as I know.
• Pretty much everything else in the game can be altered or deleted in some way.

So i'm currently moving on to plan B - cheat.
I've got 3 options here:

1. (unlikely to work, just an idea) - rather than deleting and re-making the wormholes, I move them to other star-systems and re-set them to need exploration. This would fundamentally do the same thing.
   • But as I cant find a move command anywhere for solar objects, and 30 mins of googling turned up no solutions to moving planets between solar-systems (just a lot of depressing requests to add Quarian-like moving world ships to the game),
   • I'm left with the sad, likely fact that this isn't workable.
2. Wait for Paradox to expand moddability for bypasses or enrich FTL some more (or add a remove_natural_wormhole command)
   • Lol
3. Look in to making a megastructure that uses the wormhole graphic and tweak accordingly (i.e. nonbuildable, always active etc), then overwrite the game_startup.31 event to use this instead of natural wormholes. That way I can spawn the thing in and delete it at my leisure and it'd function as a normal bypass.
   • The problem, then, of course is in figuring out if it's possible to affix the "exploration" mechanic to a megastructure.
     • Or if that is something that is hardcoded into the natural_wormhole StellarObject
     • requires_exploration = yes/no is a function in 00_bypasses, and you can set bypass type in the megastructure file, just changing the gateway bypass type and activating it doesnt work, this might be a deeper hardcoded issue, or it might just be an incumbent/overlapping game rule stopping doing weird stuff.

Currently looking in to #3

 

[Pancakelord]

It looks like the solution - due to a web of spaghetti-code / limitations and my oncoming migraine, is the following:

1. Vanilla gateways - leave as is
   • (possibly add a planetary decision to gateways, which triggers a special project, to shut them down as I'm also planning to disable closed borders)
2. Vanilla Wormholes - replace their mesh with a gateway mesh (maybe scaled down) - these will be the new "secondary gateways"
   • it turns out megastructures do not support one_to_one (paired) connections as there isnt any script to link them, so gotta repurpose wormholes.
3. Wormholes 2 - A new megastructure that looks and quacks like a wormhole
   • It will - via a pulsed variable MTTH event - spawn & despawn randomly in the galaxy and have a chance to collapse when a ship uses it.
   • Because of megastructure limitations it would basically turn wormholes in to a randomly appearing and disappearing secondary gate network,
   • Making the appearance of a wormhole a very big security risk, as you dont know who or what will spill out of it (but with a % chance to collapse it by sending ships through - or waiting till it dissipates - this could be countered)
     • (I also need to make sure 2 gate-nets can exist so you dont get ships entering a gateway and coming out of a wormhole by using a one_to_all method - otherwise will need to copy how L-gates work but add special flags to these MSes when spawning (and clear on de-spawn) to set them apart from regular gateways)

What a massive hassle. And all because we lack

1. a simple command to kill a wormhole off.
2. the ability to pair megastructures up.

And i've not even touched on how half the variables in the 00_bypasses text file dont seem to do much - or get overwritten by the megastructure file. My grander ideas of adding gate-casting (letting you "launch" your ships at nearby stars) or attaching bypasses to ships (for mobile gateways - as we cant have mobile MSes or planets) are effectively dashed by these limitations too.

I understand now why PDX dont touch, or expand upon, FTL / bypasses with a 10 foot pole. It's such a mess organisationally and technically.

 

[OldEnt]

This is fascinating read and something I'll explore myself (I want that badly, like many others).

While experimenting I found this:
You can link existing wormholes to any other.

# fire this effect from planet/fleet scope to affect mother system. Should work with event_target too. Preset star_flag first
solar_system = {  # wormhole1
            random_system = {
                limit = {
                    has_star_flag = wormhole2  # wormhole2
                }
                link_wormholes = prev # links wormhole2 with prev solar_system (wormhole1)
            }
        }

Naturally, there can be only one natural_wormhole in a system. Orphaned this way wormholes will become unusable until linked to something again.

That said, in theory one could create a new bypass type with connection_type = one_to_one and embed it within megastructure/ambient_object. Then link it to new bypass type instance elsewhere, assuming link_wormholes effect works with it.

BTW Trying to set_location of natural_wormhole as ambient object results in crash, trying to set_location of megastructure fails.

EDIT: I used set_location effect on fleet with a delayed event to effectively emulate jump drive/warp/gate/wormhole transit in one of my mods.

 

[OldEnt]

I had a closer look at connection types:

any_other
one_to_one
scripted_connection

If linking one_to_one (used in wormhole) is for some reason not possible in custom bypasses one could create a bypass type with scripted_connection (used in lgate) which is *very* flexible. I'd imagine we could even create multiple clones of these so they could act as individual pairs instead of a web (like lgates).

Such pairs could be reserved during the jump and freed, if intended to be used like wormhole drives etc.

 

[OldEnt]

Regarding mobile bypasses attached to ships:
You can do that by event_locking ship and spawning a bigger ship/station without engines on top of it when in deployed mode (if you want it to have HP points). Hiding would look kind of how Guilli hides a leviathan in Living Planet.

 

[Pancakelord]

BTW Trying to set_location of natural_wormhole as ambient object results in crash, trying to set_location of megastructure fails.

Yeah I still cant work out what a natural_wormhole is, but it seems to be an entirely separate class of object from anything else in the game, that fleet/ambient command probably wont work on it.

EDIT: I used set_location effect on fleet with a delayed event to effectively emulate jump drive/warp/gate/wormhole transit in one of my mods.

I think i've bashed my head against that problem too much (whilst trying to retain vanilla functionality). Have tried adding jump drives:

• via a station or even titan aura (failed) - with the idea being to let you build a "jump drive cannon" that sends ships on one way trips, or let a JD equipped titan drag an escort fleet along with it.
• via statuses and effects (failed) - Jump drives seem to be intrinsic component properties and cant be edited at all after start up [and probably hyperdrives too - no STL ships + farcaster gates a la sword of the stars' Hivers].

One possibility is to spawn megastructure-wormholes at the edge of a system whenever a ship is given orders and force a re-path, then collapse the wormhole after it's gone through... but that would probably be as far from performance efficient as you can get if its handled by script.

Alternatively, there is possibly a way to bring back the old wormhole drives/stations, almost exactly as they were.

Tell a constructor to build a megastructure (a "wormhole station") like how it builds a gateway, and upon completion it would need to execute a new script:

1. Setup the station as the nexus point.
2. all stars within @euclidian_distance of that initial system would need to spawn invisible/incorporeal megastructures as egress points, set up as node points.
3. A scripted_connection based on the L-gate nexus/node tree would then need to dynamically (counting is the difficult bit) link all of those spawned invisible points back to the parent MS. the setup would be 2-way like the old wormholes.
4. a final script would need to spawn a polygon on the galactic map, oriented around the home star, to show a circle for the jump radius - as we cant render that after the old code was cut in 2.0 (though it still renders for jump-drives, but I have never figured out how to make it appear for other things).
5. Ships would then be able to travel back and fourth, an extra "wormhole drive" can be added that just exists to fulfil a potential {} check for the scripted_connection, only letting wormhole_drive ships ride along it, not hyperlane or jumpdrive ones. [an extra check can prevent hostile wormhole nations from using them too]
6. If the station is blown up or destroyed, a script would have to cull all of that stuff.

There may be some other technical limitation preventing that but I dont think there is. The wiki mentions no node-node or nexus-nexus transfers, so by flagging the invisible points as nodes and building a web of stations(nexuses) you should be able to handle this all on a single bypass type, with the ships jumping around automatically.

If the above works as I've typed it out, even the AI would be able to path along it, it would need extra instruction sets on building wormhole stations whenever it hits a system that is at the edge of its bubble (this could rapidly lead to check-bloat & long pathing calculations as the network grows, though)

any_other
one_to_one
scripted_connection

yeah the wiki also mentions one_to_many, not sure if that's a typo by someone but it does sound like the expression with multiple wormhole links you mentioned above.

scripted_connection (used in lgate) which is *very* flexible.

True. For now all i've done is screw with the node-nexus example from the L-gate (which has a few limitations, on the wiki, but I have a feeling I can get around no node-node transfers by using if-statements to specially define the nexus) but there is very little documented beyond the node-nexus hierarchy (I presume most script will fit within those two blocks, but ive not found any other words besides "node" or "nexus" that do anything, unless someone has a guide on its operators that i've missed somewhere)

Regarding mobile bypasses attached to ships:
You can do that by event_locking ship and spawning a bigger ship/station without engines on top of it when in deployed mode (if you want it to have HP points). Hiding would look kind of how Guilli hides a leviathan in Living Planet.

Thats a pretty interesting solution, I'm not sure if the AI could learn to use it ... maybe if the script automatically deploys the gateway after the ship's been idle for, say, 7 days in enemy territory? With it folding back up if the AI tries to move the ship/if the ship moves X>N distance in the solar system?
I doubt you can "bridge" bypass types, so either it'd have to dial into the wider gateway network, making it extremely powerful in a war, or you'd need to build a dedicated "departure" gateway in your space to accompany it on its own (one way?) scripted connection.
Will need to think about that.

 

[OldEnt]

I was unable to reliably identify edge of a solar system, main reason my solution used "abandoned wormhole station" ambient_object over a planet as an anchor point for fleets to arrive (wormhole drives much?), just without range check because I probably did not get something right. If anyone knows how to find edge of gravity well I'd be grateful.

There is a new interesting exhibit on Workshop now Escalation : Warp Drive, although that's not exactly bypasses.

The amount of spaghetti considered here is spectacular.

 

[G S Palmer]

I cant find the main game initialisation event that handles gateways for galaxy generation.

That's because it's not an event, it's a system initializer in common/solar_system_initializers/apocalypse_initializers.txt.

 

[Pancakelord]

I was unable to reliably identify edge of a solar system, [...] If anyone knows how to find edge of gravity well I'd be grateful.

Finally had a slow day at work to look into this - at first glance it looks like all star systems have exactly the same sized gravity well.... but it's more complex than that.

Spoiler: Me rambling along as I figure out how solar system scale works.

System scaler mods use a ton of weird hacks like shrinking the size of planets (or shrinking ships) and SYSTEM_SPACE_SCALE_MULT which ... shrinks everything from what I can see. But the overall outer and inner Gravity well radius dont change (I've not found it but I bet there are special hidden scalers for binary & trinary systems to make those systems feel bigger, without actually being bigger).

SYSTEM_SPACE_SCALE_MULT = 10 (default) (look in bottom left, time to complete transit = 114 days)

SYSTEM_SPACE_SCALE_MULT = 1000 (default) (look in bottom left, time to complete transit is still = 114 days)

At 1k system scale you get a lot of graphical artefacts and a shakey camera - likely a breakdown of the floating point precision used to dynamically scale things.

This is also why some system scaler mods will also slow down ship speed or directly re-scale planets (all entities have their own scalar settings buried in the GFX files, separate from the meshes/textures) to compensate for this upper effective cap on system scaling.

There is a defines for setting the outer orbital bounds from what I can find.
SYSTEM_INNER_RADIUS_OFFSET = 30
SYSTEM_MIN_INNER_RADIUS = 150
SYSTEM_OUTER_RADIUS_OFFSET = 100

^ is what happened when i randomly tried
SYSTEM_INNER_RADIUS_OFFSET = 300
SYSTEM_MIN_INNER_RADIUS = 450
SYSTEM_OUTER_RADIUS_OFFSET = 500 #######
Interestingly the ships are still hardcoded to travel only so far:

I tried RMBing on the orange rings on opposite sides of the system and they will still only path so far so i think there is some kind of hard-coded real bound on system size.

panning around in observer mode I noticed that wormholes and gateways were still spawning at (what I estimate) is the approx edge of a vanilla system

SYSTEM_INNER_RADIUS_OFFSET = 0
SYSTEM_MIN_INNER_RADIUS = 150
SYSTEM_OUTER_RADIUS_OFFSET = 0 #######
Will get this:

The gravity well "ring" and the orange system-limit ring are now equal
this means the default width of the gravity well is equal to 100 units or (SYSTEM_OUTER_RADIUS_OFFSET = 100)
From this it also implies that the minimum size of a solar system is
30 Offset(nothing can spawn near the star)+150 (the main solar system, upto the gravity well edge)+100 (gravity well upto system limit) = 180 gravity well, or 280 system size.

Now there does seem to be some slight deviance in my tests (despite what I wrote above, as this is just one long rambling post) and there doesnt seem to be an expressed


A "scientific" way to test this would be to eliminate ships from the equation

• spawn a custom solar system with, say, 30 planets,
• each one having an orbital radius equal to N+10 then see what happens,
  • does the solar system grow to accommodate them? (unlikely given that the defines can scale the system as much as it wants but ships will refuse to path beyond "some distance")
  • do they spill over the edge of the gravity well?
    • And if so, what distance do they spill-over at?
    • That will give you the (more or less) average radius(R) of all systems in the game - based on (SYSTEM_OUTER_RADIUS_OFFSET = 100), the gravity well will then be located at R-100. You can then hard-code that into your mod going forwards (Dist Min = R-Offset Max = R-1).
    • I wouldnt be surprised if this is how it was done by PDX, a lot of values appear either hard-coded or at least soft-locked in scripts / not dynamic.

.

I'm too lazy to reformat the above spoiler, some of it's wrong as I was working things out as I go but has a few interesting screenshots

But the gist of it is Solar system size is given by the following entries in 00_defines.txt, with some caveats:

SYSTEM_INNER_RADIUS_OFFSET = 30

Determines minimum radius to start spawning planets / padding for stars.​

SYSTEM_MIN_INNER_RADIUS = 150

Determines Gravity well radius (e.g. minimum distance you can drop a gateway at) "Min" is important here, as planetary orbits can superceed this, theoretically to an unlimited distance (in practice probably you'll get floating point errors or ships failing to path after "some" distance).​

SYSTEM_OUTER_RADIUS_OFFSET = 100

This is extra "padding" on top of the gravity well out to the orange dashed ring or "system limit" as I call it (this "doughnut" shape is where you can put gateways).​

Gravity well radius = 30 units + Greater of 150units OR the orbital radius of the outermost planet & its moon )
Entire system radius = Gravity well + 100

Examples / proof:
For these I set up the constants in defines as below to have a simplified test environment
SYSTEM_INNER_RADIUS_OFFSET = 0
SYSTEM_MIN_INNER_RADIUS = 10
SYSTEM_OUTER_RADIUS_OFFSET = 0 #######
1.

This systems gravity well is dictated by its outer most planet so
Gravity well Radius =

• Greater of 10 and
• 0 (I set min radius to 0 rather than 30) + Planet radius

2.

Inner radius will equal Ebrxinda VI distance (which is technically radius, but is called distance in the solar system scripts) + Ebrxinda VIa's orbital distance from its parent
In other words
Gravity well radius =

• Greater of 10 and
• 0 (I set min radius to 0 rather than 30) + Planet radius + Moon radius

So, to bring this back to your original question about calculating the gravity well distance, you need to write a custom search script. I'll paste in the important values again for reference, but substitute in greek letters

SYSTEM_INNER_RADIUS_OFFSET = 30 "α"
SYSTEM_MIN_INNER_RADIUS = 150 "β"
SYSTEM_OUTER_RADIUS_OFFSET = 100 "γ"

You need to find

1. The outer most planet in a solar system
2. Does it have a moon Y/N?
   1. If No
      • Get the distance (Pr) of that planet to it's star
        1. IF Pr < β, take β
        2. IF Pr > β, take Pr
        3. sum α + Greater of β and Pr
           • Finish = you have your gravity well radius.
   2. IF Yes,
      1. Get the distance (Pr) of that planet to it's star
      2. Then determine which is it's furthest out moon (if it has multiple) and
      3. Get the orbital distance of that moon (Mr) from its host planet
         • Then Sum α + Greater of β and (Pr + Mr)
           • Finish = you have your gravity well radius.

The radius of "deep space" (gateway build zone) is just γ,

• finding the system's absolute maximum range (the orange ring) would be to solve for the gravity well + γ

Binary and Trinary systems are a further step removed if they are treated as sub-systems
(some like below SS are treated as a single star with 2 off center meshes, so above will still work ),

But if each Star is treated like a separate system, the game fudges this by treating them like planets orbiting an empty central object.

• So you'd have to simultaneously solve each solar "tree"
• To see which star + furthest planet of that star + furthest moon of that furthest planet around that furthest star gives you the greatest distance (D)
• Then test D vs β to give you the radius of the gravity well for that system.
• 
  E.g. Gravity well radius = A (or α+ Sr) + B(Pr)

I dont think you can even perform all those maths operations with "Stellaris script", there may even be a simpler way to compute all this (it's probably structured like a tree in the game's data files) though I've not tried so I could be wrong. Non-unary systems might be a total pain in the butt to solve for, but unaries should be fine (and make up 80%+ of a galaxy usually).

 

[Pancakelord]

Small update
I've now got the wormholes looking like gateways (except for the fact that they lack textures for some reason?)

and have edited some localisation files + techs to fit the whole "binary gateway" "networked gateway"(vanilla) system i've got going. Still need to figure out what localisation file contains the name for wormholes ("Starname" Wormhole) and replace it with ("Starname" Binary Gate)

Not sure what's causing the textures to not show up though i'm coyping in the right asset file (otherwise the gateway mesh wouldnt be showing) and just subbing in the fungoid gateway for the "natural_wormhole_entity" (natural_wormhole_entity preserving the name, as i've not found where the natural wormhole entity is defined, its not kept in the bypass or defines file, but just replacing the script within that entity with the gateway's one "should" work... and mostly does except for the shader)

Spoiler: FTLGateway_Rebalance\gfx\models\add_ons\_add_ons_entities.asset

###GFX replacement for wormholes into binary gateways
entity = {
    name = "natural_wormhole_entity"
    pdxmesh = "gateway_mesh"

    default_state = "idle"
    state = { name = "idle" animation = "idle"
        start_event = { trigger_once = yes sound = { soundeffect = "megastructure_gate_way_station_hum" stop_on_state_change = yes } }
        start_event = { trigger_once = yes sound = { soundeffect = "megastructure_gate_way_portal_hum" stop_on_state_change = yes } }

        event = { time = 0 node = "light_locator_01" particle = "ship_light_blue_effect" keep_particle = yes trigger_once = yes }
        event = { time = 0 node = "light_locator_02" particle = "ship_light_blue_effect" keep_particle = yes trigger_once = yes }
        event = { time = 0 node = "light_locator_03" particle = "ship_light_blue_effect" keep_particle = yes trigger_once = yes }
        event = { time = 0 node = "light_locator_04" particle = "ship_light_blue_effect" keep_particle = yes trigger_once = yes }
        event = { time = 0 node = "light_locator_05" particle = "ship_light_blue_effect" keep_particle = yes trigger_once = yes }
        event = { time = 0 node = "light_locator_06" particle = "ship_light_blue_effect" keep_particle = yes trigger_once = yes }
    }
    scale = 0.6 #60% the size of a networked gateway
    state = { name = "death" animation = "death" looping = no
        event = { time = 7.63 node = "root" particle = "dreadnought_explosion_particle" keep_particle = yes }
        event = { time = 2.1 node = "root" particle = "gateway_portal_death_residue_effect" keep_particle = yes }
  
        event = { trigger_once = yes sound = { soundeffect = "megastructure_gate_way_station_death" stop_on_state_change = yes } }
    }

        meshsettings = {
            name = "gateway_bottomShapeShape"
            index = 0
            texture_diffuse = "fungoid_01_gateway_diffuse.dds"
            texture_normal = "fungoid_01_gateway_normal.dds"
            texture_specular = "fungoid_01_gateway_specular.dds"
            shader = "PdxMeshShip"
        }
  
    attach = { portal_joint = "gateway_portal_entity" }
}

Also noticed that these will have to be "activated" permanently, unless I can figure out some way to trigger different animation states via on_actions or some sort of trigger (e.g. only spawning in the central portal once any ship has explored/used the wormhole/binary gate at least once) - it'd be real cool if the portal would only flare up and turn on if a ship gets close, rather than being on 24/7.
Edit: "bypass_effect = "" " exists in the bypasses file, perhaps that can be instructed to play the portal animation just as the ship enters(for N animation days), so the portal isnt playing 24/7. will have to test.
Otherwise i'll just write an event popup explaining these away as "precursor gates" - a simpler yet more robust design than the network gates, but only able to link to one other destination, rather than many.

 

[OldEnt]

Wow, that's a lot of useful information it will come in handy, thanks!

I believe these keys govern galactic map locales but unsure (main loc fie, l_english.yml etc):
BYPASS_WORMHOLE:0 "$NATURAL_WORMHOLE_GALACTIC$" BYPASS_GATEWAY:0 "$GATEWAY_GALACTIC$"

GATEWAY_GALACTIC:0 "Gateway"
GATEWAY_GALACTIC_DESC:0 "This system contains a §YGateway§!"
GATEWAY_COUNTRY_CANNOT_USE:0 "$TRIGGER_FAIL$ The §Y[From.GetName]§! has denied us access to their gateways"
NATURAL_WORMHOLE_GALACTIC:0 "Natural Wormhole"
NATURAL_WORMHOLE_DESC:1 "This system contains a §YNatural Wormhole§! connected to $DEST|Y$"
NATURAL_WORMHOLE_DESC_UNEXPLORED:0 "This system contains an §Runexplored§! §YNatural Wormhole§!"
NATURAL_WORMHOLE_COUNTRY_CANNOT_USE:0 "$TRIGGER_FAIL$ The §Y[From.GetName]§! has closed their borders to us"

 FLEETORDER_EXPLORE_BYPASS_ORDER_LABEL:0 "Explore $BYPASS_TYPE|Y$"
 FLEETORDER_EXPLORE_BYPASS:0 "Explore $BYPASS_TYPE|Y$ in system $SYSTEM$"
 FLEETORDER_EXPLORE_BYPASS_DESC:0 "Go through the $BYPASS_TYPE|Y$ in $SYSTEM$ and find out what lies on the other side."
 BYPASS_DESTINATION_SELECTION_PICK:0 "Pick a destination system"
 FLEETORDER_TRAVEL_THROUGH_BYPASS:0 "Traveling to $DESTINATION|Y$ through $BYPASS_TYPE|Y$ in $SYSTEM|Y$"
 USE_BYPASS_INVALID:0 "$BYPASS_TYPE$ is invalid"
 USE_BYPASS_INACTIVE:0 "Requires Activation"
 USE_BYPASS_UNKNOWN_TYPE:0 "$BYPASS_TYPE|Y$ has never been encountered before"
 USE_BYPASS_NEVER_EXPLORED:0 "$BYPASS|Y$ has never been explored before"
 USE_BYPASS_UNKNOWN_DESTINATION:0 "No known destination"
 USE_BYPASS_INACTIVE_DESTINATION:0 "$DESTINATION|Y$, the destination of $BYPASS|Y$ hasn't been activated yet."
 USE_BYPASS_BYPASS_NOT_CONNECTED_TO_DESTINATION:0 "$DESTINATION$ isn't connected to $BYPASS|Y$"
 FLEETORDER_TRAVEL_TO_ORDER_LABEL:0 "Travel to $DESTINATION|Y$"
 FLEETORDER_USE_BYPASS_ORDER_LABEL:0 "Travel through $BYPASS|Y$"
 FLEETORDER_USE_BYPASS:0 "Travel through $BYPASS|Y$"
 FLEETORDER_USE_BYPASS_DESC:0 "Travel through the $BYPASS_TYPE|Y$ in $SYSTEM$"
 EXPLORE_BYPASS_NOT_NEEDED:0 "$BYPASS_TYPE|Y$ don't need to be explored"
 EXPLORE_BYPASS_ALREADY_EXPLORED:0 "$BYPASS|Y$ has already been explored before"

 

[neptunehs]

re you using real bypasses or "just" ambient objects like MEM Va

This is fascinating read and something I'll explore myself (I want that badly, like many others).

While experimenting I found this:
You can link existing wormholes to any other.

# fire this effect from planet/fleet scope to affect mother system. Should work with event_target too. Preset star_flag first
solar_system = {  # wormhole1
            random_system = {
                limit = {
                    has_star_flag = wormhole2  # wormhole2
                }
                link_wormholes = prev # links wormhole2 with prev solar_system (wormhole1)
            }
        }

Naturally, there can be only one natural_wormhole in a system. Orphaned this way wormholes will become unusable until linked to something again.

That said, in theory one could create a new bypass type with connection_type = one_to_one and embed it within megastructure/ambient_object. Then link it to new bypass type instance elsewhere, assuming link_wormholes effect works with it.

BTW Trying to set_location of natural_wormhole as ambient object results in crash, trying to set_location of megastructure fails.

EDIT: I used set_location effect on fleet with a delayed event to effectively emulate jump drive/warp/gate/wormhole transit in one of my mods.

When I try to make a one-way bypass(failed),I found megastructure can't be save as a event_target,I wonder if you use save_event_target to megastructure?

 

[OldEnt]

When I try to make a one-way bypass(failed),I found megastructure can't be save as a event_target,I wonder if you use save_event_target to megastructure?

Saving and executing event_target works only as an event written prior to the game being loaded, you cannot use it via console in game like an effect, at least that's my experience.

 

[neptunehs]

Saving and executing event_target works only as an event written prior to the game being loaded, you cannot use it via console in game like an effect, at least that's my experience.

But I can't do it in the events too...well not this thread to discuss.

 

[OldEnt]

But I can't do it in the events too...well not this thread to discuss.

You sure it's not a scope issue? PM me if needed.