[Official Mod Development Bug Reports] A Thread for Mod Creators

The place to discuss scripting and game modifications for X Rebirth.

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

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Thu, 28. Apr 16, 12:55

Hey folks, sorry if I am spamming this thread, but just confirmed a new issue (which is definitely related to the current station-building design).

Remember I mentioned earlier about how only construction vessels are linked to a build location in any way, and the stations themselves aren't? Well, turned out my observation was correct.

The only thing that marks a build location as "occupied" is a construction vessel's buildmodule. That is what $buildlocation.child refers to. The station built by a buildmodule is connected to it ($buildmodule.buildanchor), BUT once a buildmodule is cleared (either by detaching the CV or if the CV is destroyed), there's absolutely nothing that marks the build location on which the station is built as "occupied".

Theoretically this means it's possible even in the vanilla game for a player to tell an Architect to build a station at a location that ALREADY has a station - if that station's CV has been destroyed (the player may have some difficulty selecting said build location since it's likely to be obstructed by the station's hull, but still, it's a possibility).

In modding terms, however, not being able to link a station to a build location itself is highly problematic. For example, I wrote a station-spawning script that locates an unoccupied build location in the zone, and generates a station there. As long as the build locations have a CV connected to it, the script will mark them off as unavailable (tested and confirmed).

However, if a CV has been detached from one of the stations, said spawning script WILL spawn a new station right on top of the other one (I could use "safepos" to avoid hull clipping, but there are plenty of reasons why one may not want to use safepos - for example I don't want my stations to spawn far away from the actual build locations).

I know this is somewhat of a minor scenario since most players will probably leave their CV's connected to their parent stations, but I definitely think implementing some sort of direct station-build location connection is good for safety reasons.

User avatar
YorrickVander
Posts: 2682
Joined: Tue, 29. Oct 13, 22:59
x4

Post by YorrickVander » Thu, 28. Apr 16, 13:38

This doesn't sound correct - the buildloc.child is used in a function i made for BR + Rubini and appears to be working fine for npc built stations. The way it works is to detect the last stage completion and run move.die on the cv. I'll nudge BR to check on this however in case it is not working the way i think it is and run a test or 2 my end.
X Rebirth - A Sirius Cybernetics Corporation Product

Split irritate visiting pilot with strange vocal patterns.

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Thu, 28. Apr 16, 15:20

YorrickVander wrote:This doesn't sound correct - the buildloc.child is used in a function i made for BR + Rubini and appears to be working fine for npc built stations. The way it works is to detect the last stage completion and run move.die on the cv. I'll nudge BR to check on this however in case it is not working the way i think it is and run a test or 2 my end.
Is it possible that you didn't disconnect your CV before telling its pilot to move.die? But even then once it self-destructs, it shouldn't matter.

This is my code for detecting an unoccupied build location:

Code: Select all

        <do_all exact="player.zone.buildlocations.count" counter="$Counter">
          <do_if value="not player.zone.buildlocations.{$Counter}.child">
            <set_value name="$BuildLocation" exact="player.zone.freebuildlocations.{$Counter}"/>
          </do_if>
        </do_all>
When the zone's build locations are all taken up by stations (with CV's attached), the script will output the "No free build location in zone" error message on the event monitor, which I programmed it to do. All of this works properly.

But the moment I detach a CV from a station, the script WILL create a station right on top of the one where the CV just disconnected from; and the only explanation is $buildlocation.child refers to a connected CV.

If you look at the NPC_Architect script, you can also see that the station-building logic in no way associates the station itself with the build location:
  • <connect_to_build_location> connects a CV to a build location.
  • <set_buildanchor> connects a buildmodule (on a CV) to a station.
  • The construction vehicle is the container of the buildmodule. $CV.buildmodule refers to the buildmodule directly and buildmodule.container refers to the CV.
  • You can use the station to locate a buildmodule via $Station.buildingmodule, but it is not the container of the buildmodule. $Station.buildingmodule.container refers to the CV.
  • Proper CV detachment procedure involves <clear_buildmodule> and <disconnect_from_buildlocation> (from NPC_Architect script), both of which only involves the CV (only a CV can be specified for <connect_to_build_location> to begin with).
I think Egosoft's scripting logic was simply that CV's aren't meant to be detached anyway, and that even if it somehow did (or died), players can't target the build location anyhow (due to obstruction by station hull).

I am currently looking for other ways to mark off build locations... the only thing I've found so far (possibly) is <claim_build_location>, but I am not sure if that actually does anything (looking over the NPC_Architect script, at no point does an Architect actually check if a build location is "claimed". They only look for connected CV's in determining if a build location is still free). This makes me think all <claim_build_location> does is make the build location un-clickable by the player (since that's the only way for the player to initiate a build action); don't think the architects themselves know any better.

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Sat, 30. Apr 16, 00:38

Hey folks,

Did some further investigation into the station-build location association issue. Think I found something new.

I've been looking over the NPC_Architect script again, and discovered a single reference to station-build loc association, in this cue:

Code: Select all

            <cue name="DeployToStation_Arrived">
              <conditions>
                <event_object_signalled object="$actor.ship" param="'move.buildership'" param2="true"/>
              </conditions>
              <actions>
                <debug_text text="'Connecting %1 (actor %2) to station %3'.[$actor.ship, $actor, $DeployedStation]" />
                <cancel_cue cue="DeployToStation_CheckStation" />
                <remove_from_player_squad object="$actor.container" />
                <connect_to_build_location object="$actor.container" buildlocation="$DeployedStation.buildlocation"/>
                <restart_build object="$DeployedStation" buildmodule="$BuildModule" updatebuild="true"/>
                <remove_value name="$location" />
                <set_value name="$station" exact="$BuildModule.buildanchor" />
                <do_if value="$station.isoperational">
                  <set_object_commander object="$actor.container" commander="$station" type="entitytype.manager"/>
                </do_if>
                <signal_cue cue="BuildFinished_Wait" />
              </actions>
            </cue>
Here it does presume that the station itself can point to a build location, but keeping in mind that there are no MD script command to connect a station to a build location, I went back and looked closer at the normal station creation process:

Code: Select all

                      <do_else>
                        <debug_text text="'Build area free, building'" />
                        <debug_text text="'Connecting %1 (actor %2) to build location %3'.[$actor.ship, $actor, $location]" />
                        <remove_value name="$obstructioncheck" />
                        <remove_blocked_area blocker="$actor" zone="$actor.zone" />
                        <cancel_cue cue="ValidateDestinationFree" />
                        <remove_from_player_squad object="$actor.container" />
                        <connect_to_build_location object="$actor.container" buildlocation="$location"/>
                        <construct_station object="$actor.container" macro="$selectedMacro" buildlocation="$location" buildplan="$Buildplan" updatebuild="true"/>
                        <remove_build_location_claim buildlocation="$location" />
                        <remove_value name="$location" />
                        <set_value name="$station" exact="$BuildModule.buildanchor" />
                        <signal_cue cue="BuildFinished_Wait" />
                      </do_else>
And the key appears to lie in <construct_station>, under which you CAN specify a build location value.

So I think this is what's going on:
  • Egosoft expects stations to only be tied to a build location under "normal" building circumstances, so station only gets associated to a build location via <construct_station>.
  • <create_station> is probably meant for generating special mission-related objects and normally not meant for player use, and therefore no option is provided for tying a generated station to a build location.
Unfortunately this does create some problems for certain situations where a coder may wish to replace a normally-constructed station with a script-generated one. The moment the "normal" station is destroyed, its link to the build location is lost and there's no way to replace it other than having a CV built a replacement normally using its buildmodule.

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Sun, 1. May 16, 03:48

Quick update on the status of the upcoming release:
  1. Ship dealers on player-spawned shipyards confirmed to work! They run on standard NPC ship dealer scripts, and to get them to work properly they simply have to be NOT player-owned (it's fine if they are located on a player-owned station though). This means no modified/added game asset, which means you can safely remove this mod even after building player-owned shipyards with it - the ship dealers will continue to function.

    One side effect of this (ship dealers being NPC-owned) is that you WILL have to pay credits to build ships, even at your own shipyards (in addition to using up the shipyard's resources, which your shipyard manager already paid YOUR money for). This effectively means you are paying more than you typically would at an NPC shipyard, if you build a ship at one of your own.

    This probably is of little consequence since most people will probably just turn the shipyard over to an NPC faction to generate economy sink anyway, but just wanted to point that out.
  2. "Canteran Plot Station" feature tested and works. Currently ironing out some event monitor issues (I want to dynamically generate a list to show what stations were created; the list works, but it's not displaying in a format I want).
  3. Implemented some new codes to dynamically-generate specialists for production-capable stations spawned by "Summon Stations". Tested and works. :)
  4. Ironing out issue for dyanamic-generation of ammo for capital ships (already works for stations, not sure why the same code isn't working for capships)

jth
Posts: 296
Joined: Wed, 4. Jan 06, 00:31
x3

Post by jth » Sun, 1. May 16, 12:25

Simoom wrote:Hey folks,

Did some further investigation into the station-build location association issue. Think I found something new.

I've been looking over the NPC_Architect script again, and discovered a single reference to station-build loc association, in this cue:

And the key appears to lie in <construct_station>, under which you CAN specify a build location value.

So I think this is what's going on:
  • Egosoft expects stations to only be tied to a build location under "normal" building circumstances, so station only gets associated to a build location via <construct_station>.
  • <create_station> is probably meant for generating special mission-related objects and normally not meant for player use, and therefore no option is provided for tying a generated station to a build location.
Unfortunately this does create some problems for certain situations where a coder may wish to replace a normally-constructed station with a script-generated one. The moment the "normal" station is destroyed, its link to the build location is lost and there's no way to replace it other than having a CV built a replacement normally using its buildmodule.
Hi Simoom

create_station did not have a buildlocation before 4.0 but Xenon_Slayer very kindly added it into 4.0 so it does now :)

http://forum.egosoft.com/viewtopic.php? ... ldlocation

Have a look at the common.xsd from 4.0

<xs:element name="create_station">
...
<xs:attribute name="buildlocation" type="expression">
<xs:annotation>
<xs:documentation>
Build Location ComponentMacroSlot to connect the station to
</xs:documentation>
</xs:annotation>

I have used it in my Station Structural Rebuild mod

http://forum.egosoft.com/viewtopic.php? ... ldlocation

but haven't published it yet ...

jth

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Sun, 1. May 16, 12:45

You are a lifesaver jth! :D Went and fixed my scripts. Thanks!

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Tue, 3. May 16, 17:44

Hey everyone, have two things to report (one is suggested improvement, the other is a prickly issue that seems to be related to random NPC generation aboard stations)
  1. The first issue has to do with the ChracterDB (/libraries/characters.xml). This file appears to have been written before all the available character groups were made (/libraries/charactergroups.xml), and does not utilize most of the available chracter groups (for appropriate macro selection).

    This is a problem because character groups, at current, cannot be defined dynamically in MD (if you create an actor, and try to define the "group" attribute, it expects a namestring). Only the CharacterDB can be defined dynamically (which allows you to specify the character's faction and job, and then supposedly selects an appropriate macro for the actor) - but it doesn't select an appropriate macro in most cases. Further, several Ego scripts use the CharacterDB to define actor macro selection (several plot scripts, job scripts, and most notably, InitUniverse.xml). This is the very reason we often see on NPC stations and ships Managers with the Pilot macro, and Commanders with the Trader macro, etc.

    Here's the list of incorrect character macros:
    <character id="argon_civilian" group="argon.trader">
    Category tags should not include any of the professions such as "pilot", "commander", and specialists, etc.
    <character id="argon_smuggler" group="argon.trader">
    Should be using the character group "argon.shadyguy".
    <character id="argon_criminal" group="argon.trader">
    Should be using the character group "argon.shadyguy".
    <character id="argon_ownerless" group="argon.pilot">
    Should be using the character group "argon.trader" or "argon.shadyguy".
    <character id="fighter_albion_random" group="albion.pilot">
    Category tags should not include any of the professions such as "pilot", "commander", and specialists, etc.
    <character id="pmc_fighter" group="albion.pilot">
    Category tags should not include "commander" and "defencecontrol".
    <character id="pmc_trader" group="albion.trader">
    Category tags should not include "pilot".
    <character id="hoa_fighter" group="albion.pilot">
    Category tags should not include "commander" and "defencecontrol".
    <character id="sos_generic" group="albion.pilot">
    Should be using the character group "argon.trader" or "argon.shadyguy". Category tags should not include any of the professions such as "pilot", "commander", and specialists, etc.
    <character id="equipment_trader_omicron_lyrae_random" group="argon.trader">
    Category tags should not include "pilot".
    <character id="trader_omicron_lyrae_random" group="argon.trader">
    Category tags should not include "pilot".
    <character id="fighter_omicron_lyrae_random" group="argon.pilot">
    Category tags should not include "commander" and "defencecontrol".
    <character id="hev_generic" group="argon.pilot">
    Should be using the character group "argon.trader" or "argon.shadyguy". Category tags should not include any of the professions such as "pilot", "commander", and specialists, etc.
    <character id="canteran_fighter" group="devries.pilot">
    Category tags should not include "commander" and "defencecontrol".
    <character id="canteran_trader" group="devries.trader">
    Category tags should not include "pilot".
    <character id="rei_fighter" group="devries.pilot">
    Should be using the character group "devries.trader" or "devries.shadyguy". Category tags should not include any of the professions such as "pilot", "commander", and specialists, etc.

    ALL factions listed in the CharacterDB needs at least two additional categories for "Commander" and "Defencecontrol" (right now these job categories are set to use the generic "race.trader" actor group).

    Also Teladi faction now has more character models, and should have them properly defined by the CharacterDB and character groups (instead of throwing all the models in for random selection). For example the more geeky-looking Teladi with the eyepiece - that should be used for Engineer and specialists only. The one with the armored shoulder pad should be used for Defense and Marine, etc.
  2. The random NPC generation system for stations seems to, on rare occasions, incorrectly target assigned station crew. I have encountered this issue on two occasions, but have not been able to identify the cause (yet).

    The first time I noticed it was when using alexalsp's CHEAT MENU, which has integrated w.evans Station Engineer. The engineers assigned to player stations would always immediately disappear when the player leaves zone. It did not matter if the engineer was hired from an NPC station or if it was spawned by the cheat mod. However, the curious thing is an Engineer spawned directly with a station (CHEAT MENU allowed station spawning) did NOT disappear when the player leaves zone.

    The second time I noticed it was in my own mod. The symptom is similar: If a station is spawned with crew already onboard, then that crew will work on the station and not disappear when the player leaves zone. However, if a new set of crew is assigned to the station, then they will simply vanish when the player leaves zone.

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Tue, 3. May 16, 18:30

Quick update on issue 2) I posted previously.

I tracked down the cause of the issue to the way the crew is generated. I was using my own cheat mod to spawn crew to assign to the station, and these crew would disappear when I leave the zone.

However, crew hired "normally" from NPC stations do not disappear when I leave the zone.

I am still unsure why this would be... I am using the standard <create_platform_actor> command for crew spawning:

Code: Select all

            <create_platform_actor name="$Crew" dockingbay="$Dockingbay" group="argon.architect" type="event.param2.{1}">
              <owner exact="faction.player"/>
            </create_platform_actor>
Is there something I need to specifically set to tell the game that this is an essential NPC that shouldn't be removed in low attention?

Edit: Been investigating further, and I think I found the cause.
The problem lies in all NPC handling scripts, but I'll use NPC_Staff.xml as an example.

The issue has to do with the way the NPC handling scripts categorize the actor as "Normal" or "Persistent":

Code: Select all

        <cue name="NormalActor" onfail="cancel">
          <conditions>
            <check_value value="not $actor.iscontrolentity" />
            <check_value value="not $customactor?"/>
          </conditions>
          <cues>
            <cue name="StaffTimeout" ref="md.GenericMissions.PlatformActor">
              <param name="BaseCue" value="OnPlatformPopulation_Staff" />
              <param name="Actor" value="$actor" />
              <param name="TimeoutMin" value="10min"/>
              <param name="TimeoutMax" value="20min"/>
            </cue>
          </cues>
        </cue>

Code: Select all

        <cue name="ControlEntity" onfail="cancel">
          <conditions>
            <check_value value="$actor.iscontrolentity" />
            <check_value value="$actor.owner != faction.player"/>
          </conditions>
          <cues>
            <cue name="ControlEntityHandling" ref="md.GenericMissions.PersistentPlatformActor">
              <param name="BaseCue" value="OnPlatformPopulation_Staff" />
              <param name="Actor" value="$actor" />
            </cue>
          </cues>
        </cue>
As you can see, any actor who is NOT a control entity, and NOT a $customactor, gets set as a "Normal" actor (who will expire the moment it exists in a different zone as the player).

The problem is $customactor is only set if a custom staff cue is signalled - it is NOT set for <create_platform_actor> events under any circumstances:

Code: Select all

        <do_if value="event.name == 'event_platform_actor_created'">
          <set_value name="$actor" exact="event.param" />
          <set_comm_handler actor="$actor" customhandler="true" />
          <include_actions ref="FeeCalculation" />
        </do_if>
        <do_elseif value="event.name == 'event_cue_signalled'">
          <set_value name="$actor" exact="event.param.{1}" />
          <set_value name="$fee" exact="event.param.{2}" />
          <set_value name="$customactor" exact="true"/>
          <assert value="$actor.type == entitytype.pilot or $actor.type == entitytype.commander or $actor.type == entitytype.manager or $actor.type == entitytype.defencecontrol"
                  text="'Actor is not of a valid type for this hander'"/>
          <assert value="typeof $fee == datatype.money" />
        </do_elseif>
Now, under normal gameplay circumstances, all non-controlentity NPC actors on NPC stations are set to despawn (timeout), BUT this behavior is cancelled when the player hires the NPC:

Code: Select all

                <do_if value="StaffTimeout.state == cuestate.complete">
                  <cancel_cue cue="StaffTimeout" />
                </do_if>
Unfortunately, all of these still mean the following scenario falls through a crack: An player-owned actor is spawned directly on the Skunk via <create_platform_actor>.

In this scenario, the actor is NOT a control entity, but also NOT a $customactor. It is therefore considered a "Normal" actor and assigned a timeout value. This timeout value is NEVER cancelled because the player never "hired" the actor. If this actor later becomes a control entity (e.g. player assigns him to a station), it still does NOT properly cancel the timeout status (since the "Normal" actor type was already set). This is why the actors I spawn using <create_platform_actor> keep disappearing.

The only way to bypass this issue, it would seem, is to use <create_cue_actor>, which flags the $customactor status. But may be an additional check should be implemented so "NormalActor" is only set for non-player-owned actors?

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Thu, 12. May 16, 05:15

Dear Egosoft,

As the development of my mod nears maturity, I have compiled a list of bugs/oversights and suggested improvements for your consideration. I hope this will benefit both your own in-house development and all XR modders.
  1. Upkeep Missions - The current Upkeep mission system has several glaring issues, especially when modding comes into play.
    • Upkeep mission creation for stations does NOT take into account things like if a station can have drones (in deciding if "Deliver Units" mission type should be created), or if it has any production/storage capability (in deciding if "Assign Subordinate" mission type should be created). It flat-out presumes all stations needs drones and subordinate trading ships, which creates problems when a mod allows players to own stations that may not have drone or production/storage capacity.
    • "Assign Subordinate" Upkeep missions currently do not allow mining and trading ships to be used interchangeably, and it really shouldn't make the presumption that mining ships should only be used for mining, and vice versa (the Onil makes excellent traders, while the Hermod makes for excellent miners).
    • "Deliver Unit" Upkeep missions currently force players to stick by the mining/trading ship specialty as well (so you MUST deliver mining drones to a mining ship). This does not take into account that a player may wish to use a mining ship as a trader.
    • "Extend Station" Upkeep missions should be eliminated entirely, since players may NOT wish to fully-extend a station, and it's annoying to have these stay in the mission log forever, and can't be aborted.
    • Upkeep mission cancellation/cleanup currently do not trigger as it should when ownership of the mission object changes. The condition for activation is <event_object_changed_owner>, and it seems to not behave as intended (selling a capship with unfinished Upkeep missions to a ship dealer, for example, does not remove its Upkeep missions). This creates issues if a mod allows players to hand over player assets to an NPC faction. But I know the cancellation/cleanup routine itself works fine (because I built a backdoor via XML patch to execute the routine when the mission object is signaled, and that works perfectly), so <event_object_changed_owner> is the definite culprit.
    • My personal suggestion: Until Upkeep mission creation (and cancellation) routines are improved, you could implement a very simple workaround, which is allow players to abort an Upkeep mission manually. An aborted Upkeep mission will then be marked off by UpkeepManagement scripts, never to be generated again. This will allow players to manage their own Upkeep missions as they see fit.
  2. Architect Dialogue Context Detection - Architect dialogue management currently do not properly detect the following conditions:
    • A construction vessel (with Architect on board) is spawned in a state that's already attached to a station. The Architect will fail to detect the connected station in this case, and present dialogue options meant for an un-deployed CV.
    • A construction vessel (with Architect on board) is detached from a station it built (doable through mods). In this instance, the Architect will continue to behave like the CV is still attached to the station, and present dialogue options for "Supply Options" and "Show Construction Plan".
    • My personal suggestion: This should be a simple fix. When a conversation is initiated with an Architect, the cue should check for the "buildanchor" value to see if a station is connected. If there is, assign $Station variable and activate the appropriate handlers. If there isn't, reset the appropriate handlers.
  3. Actor Timeout / Persistent Actor Status - There's currently an oversight in NPC_Staff.xml and NPC_Marine.xml, in which a player-owned actor created through <create_platform_actor> can be inappropriately assigned a timeout value (actor despawns after a timer, or immediately if it enters low attention). Additionally, NPC_Engineer.xml suffers from the worst oversight of all, and will despawn the generated NPC regardless of the creation method used:
    • The issue for NPC_Staff.xml and NPC_Marine.xml stems from the cue responsible for assigning timeout values NOT performing a condition check to see if the actor's owner faction is the player. It affects any mod that spawn a player-owned actor using <create_platform_actor> and then does not immediately assign the spawned actor as a controlentity (which is the condition for excluding the actor from being assigned a timeout). The only workaround is creating the actors via <create_cue_actor>, which sets a $customactor status that bypasses the timeout assignment.
    • NPC_Engineer.xml suffers the worst issues. Not only does it lack the player faction condition check in assigning a timeout value, it also fails to set a $customactor flag when a Custom Engineer is created. This effectively means there's no way to generate a player-owned Engineer entity who does NOT immediately despawn when entering low attention, if not immediately assigned to duty when spawned!
    • Architects, curiously, are not affected by this issue because they have a player faction condition check for their timeout value assignment (different script author may be?)
    • Specialists are not affected because they are not assigned a timeout value under any circumstances.
    • My personal suggestion: All NPC scripts need serious tidying... especially the section handling actor assignment upon spawn.

      "Custom" actors (if the NPC script is signalled by <create_cue_actor) should ALWAYS have the following flag set:

      Code: Select all

          <set_value name="$customactor" exact="true"/>
      "Normal Actor" assignment (for timeout values) should ALWAYS check for the following:

      Code: Select all

          <check_value value="not $customactor?"/>
          <check_value value="not $actor.isplayerowned" />
  4. Referencing Command & Object Structure Hierarchy - This isn't a bug/oversight, just a suggestion...
    • Currently there's no easy way in script to reference the "true parent object" of a surface element or module. For example, if a station or ship has multiple modules, and I want to reference the station or ship itself via a surface element on one of the modules, then I have to do "$SurfaceElement.parent.parent".
    • Same issue with command trees: If a commander unit has subordinates, and those subordinates have subordinates of their own, then there's no easy way to reference the sub-subordinates via the commander, or the commander through the sub-subordinates. One would have to do "$Commander.subordinates.subordinates" or "$Sub_Subordinates.commander.commander". This is particularly an issue if one wishes to apply an operation to ALL subordinates (including any sub-subordinates or sub-sub-subordinates or however deep the rabbit hole goes) under the commander unit sitting at the top of the command hierarchy.
    • My personal suggestion: Add a script expression that allows direct reference to the object located at the top of a structural or command hierarchy ("trueparent" and "truecommander", respectively). And for subordinate units, have a script expression that can find all subordinates working under one "truecommander".
  5. Weapon Mods - Currently there are no MD script functions that allows for customization of the stats for a spawned weapon mod. This issue should be addressed so that a coder can specify:
    • Which weapon macro the weapon mod should be for.
    • What attributes a weapon mod has and their corresponding modifier values.
  6. Ship Secrecy Level Unlock - Ships with secrecy levels (most combat vessels) currently do not unlock their info as they should when <reveal_object> or <set_object_scanned> is used (stations unlock their info just fine). There seems to be an additional layer of secrecy check in place that's only met when a player activates Ship Scanning mode in game, but I cannot find any reference to what this might be in any of the relevant scripts. This creates some headache for modding - for example I might wish to spawn some NPC ships and monitor if they are executing the proper orders I scripted for them, except I can't because all their info shows ???.

User avatar
Simoom
Posts: 1100
Joined: Sat, 30. Oct 10, 14:14
x4

Post by Simoom » Tue, 17. May 16, 03:21

Found another bug...

If the Skunk is set to invulnerable via <set_object_min_hull>, that status gets reset the moment player enters remote control:

Code: Select all

          <set_object_min_hull object="player.primaryship" exact="100"/>
          <set_object_min_shield object="player.primaryship" exact="100"/>
I am guessing because when the player enters remote control, the drone that the player is piloting becomes "player.primaryship"? But it shouldn't... It's really odd.

iforgotmysocks
Posts: 1205
Joined: Fri, 8. Nov 13, 23:35
x4

Post by iforgotmysocks » Fri, 15. Jul 16, 11:56

Engineer gets stuck repairing a ship with certain hull values.
9.700.000 for example.

The engineer script is using funny calculations when coming up with the bonus repair percentage, can't pin down the error completly (i've been away from modding X-R too long) can just guess.

U wanna calc stuff there like: 100f * 5 / $Defensible.maxhull

And then u basicly wanna set:
<set_object_hull object="$Defensible" exact="5,154639175257732e-5" />

If i remember right the float type thats used here doesn't support 16 decimal places. So it must be rounding. However, there must be a rounding error whenever it doesn't produce a non-infinite number. All .7 values won't work for hull hp. Like 16.7 million. Or 9.7 million.

Now this wouldn't occure with a hull values of x.6, cause this would only produce 8 decimal places unlike x.7m with 16 dec places.

Could be wrong and the error is somewhere else, just a suggestion.
But nontheless, the bug is somewhere in there. :D

Clownmug
Posts: 270
Joined: Wed, 11. Dec 13, 03:39
x4

Post by Clownmug » Sat, 30. Jul 16, 09:28

I noticed a minor issue with <create_station>. Using the sector attribute is supposed to create temporary zones for stations when necessary, but instead it seems to be creating regular map zones. The zones also don't need to be discovered, they are immediately visible on the map upon creation.

Clownmug
Posts: 270
Joined: Wed, 11. Dec 13, 03:39
x4

Post by Clownmug » Tue, 9. Aug 16, 10:13

I discovered a strange issue today with <create_presentation_cluster>. Apparently when the map already contains several dozen clusters (ones added by mods) it causes the game to freeze for a few seconds every time a new presentation cluster is created or destroyed. You can see an example of this by repeatedly opening and closing the mission briefing for anything with a cutscene, like the "Rigged Asteroids" or "Searching For Justice" missions.

Edit: Viewing the encyclopedia also has the same problem when showing an object cutscene.

UniTrader
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 13949
Joined: Sun, 20. Nov 05, 23:45
x4

Post by UniTrader » Tue, 9. Aug 16, 16:22

regarding Create Station: not using it directly, but using create_ship instead to create a CV first, and then attach my current mod Station to an Buildspot there - and the created Zone always has 7 buildspots, which is an unique property of Temp Zones and i assume this is the same for Creating Stations in a Sector

regarding presentation Cluster: it is just a workaround, but if you save and reload this should be resolved because presentation clusters are not Save-Persistent (except you say explicitly they are) - found this out the hard way...
if not stated otherwise everything i post is licensed under WTFPL

Ich mache keine S&M-Auftragsarbeiten, aber wenn es fragen gibt wie man etwas umsetzen kann helfe ich gerne weiter ;)

I wont do Script&Mod Request work, but if there are questions how to do something i will GLaDly help ;)

Post Reply

Return to “X Rebirth - Scripts and Modding”