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

[UniTrader]

so its an Issue with the Game itself - therefore

*** moving to official Modding Bug Reports Topic ***


just that everything is in place because the Devs are watching this Topic

[j.harshaw]

Thanks for the report, Simoom. Looks like those two weapons were overlooked. Fixed internally, but no idea when or if it'll make its way out.

[Simoom]

Thanks for the report, Simoom. Looks like those two weapons were overlooked. Fixed internally, but no idea when or if it'll make its way out.

Thanks for looking into it j.harshaw!

By the way, found another bug (I think):

• The MD function <create_engineer> doesn't seem to assign the spawned engineer to the specified ship properly (the NPC is created, but reports "None" as the word order).
  The functions <create_pilot> and <create_defence_officer> work fine, though, so probably a simple oversight for the engineer only.
  
  Curiously, if the NPC is spawned with the ship itself (e.g. <create_ship><engineer/></create_ship>), the Engineer is properly assigned in this case. But not if the ship is created first, then an engineer is created afterward.

[UniTrader]

Thanks for the report, Simoom. Looks like those two weapons were overlooked. Fixed internally, but no idea when or if it'll make its way out.

Thanks for looking into it j.harshaw!

By the way, found another bug (I think):

• The MD function <create_engineer> doesn't seem to assign the spawned engineer to the specified ship properly (the NPC is created, but reports "None" as the word order).
  The functions <create_pilot> and <create_defence_officer> work fine, though, so probably a simple oversight for the engineer only.
  
  Curiously, if the NPC is spawned with the ship itself (e.g. <create_ship><engineer/></create_ship>), the Engineer is properly assigned in this case. But not if the ship is created first, then an engineer is created afterward.

you could try to start the engineer script on him after creation, Command for this:
<start_script name="'engineer.ai'" object="$engineer" />
(except for player.primaryship where the Script to be started is 'engineer.player' )

[Simoom]

you could try to start the engineer script on him after creation, Command for this:
<start_script name="'engineer.ai'" object="$engineer" />
(except for player.primaryship where the Script to be started is 'engineer.player' )

I am aware of that; I do that already in my script (I use <create_platform_actor> since my current method of spawning NPC's based on race specified in choiceparam limits me to create NPCs separately from the ship).

I was originally using the <create_pilot/defence/engineer> option, then noticed the engineer is bugged. Since I prefer to be able to see my crew on the ship's dock, I had extra code in there to move the generated NPCs to the dock. Having to add the codes assign/start_script for the engineer AND move all the crew to the dock was pretty much as troublesome as doing the <create_platform_actor> route in the first place, so I went with <create_platform_actor> (it also solves another minor issue, which is that the NPC's created via <create_pilot/defence/engineer> or ones spawned directly with the ship will DISAPPEAR if you assign a replacement crew to the ship. NPC's created via <create_platform_actor> do not disappear and come aboard the Skunk properly if replaced).

[Simoom]

BTW not sure if this has been mentioned before, but setting an object's hull to 0 doesn't destroy it for some reason...

Code: Select all

<set_object_hull object="event.param2.{3}" exact="0"/>

I want to give the players the ability to select an object and destroy it instantly. I ended up having to use <destroy_object> and set the explosion flag to "true", but in the process I had to disallow players from selecting stations (since using <destroy_object> on stations creates all kinds of problems).

I would have preferred setting hull to 0 because it while it would destroy ships, it should only temporarily disable stations without creating any issues such as strange masstraffic... or the fact that NPC stations simply respawn on the next load anyway (and potentially mess up masstraffic even more)

[Marvin Martian]

egosoft uses at the plot

Code: Select all

          <get_control_entities groupname="$Entities" object="$Station"/>
          <destroy_group group="$Entities"/>

          <set_owner object="$Station" faction="faction.ownerless"/>

          <find_object_component groupname="$PMC_Station_Modules" object="$Station" multiple="true">
            <match_parent class="class.station"/>
          </find_object_component>
          <destroy_group group="$PMC_Station_Modules" explosion="true"/>

          <!--Destroy summarised components-->
          <set_summarised_adsign_state object="$Station" state="wreck" exact="$Station.summary.numadsigns.all"/>
          <set_summarised_efficiencyupgrade_state object="$Station" state="wreck" exact="$Station.summary.numefficiencyupgrades.all"/>
          <set_summarised_shield_state object="$Station" state="wreck" exact="$Station.summary.numshields.all"/>
          <set_summarised_surfacedestructible_state object="$Station" state="wreck" exact="$Station.summary.numsurfacedestructible.all"/>
          <set_summarised_turret_state object="$Station" state="wreck" exact="$Station.summary.numturrets.all"/>

[Simoom]

Hey guys, several things to report:

1. Not sure if this is the intended behavior, but ShipGenerator outputs error to the debug log if no engineer or defence officer is created with a ship (odd thing is it doesn't spit out any error for spawning a ship with no pilot).

   Code: Select all

   Error in MD cue md.[...]: ShipGenerator: <engineer> node missing. Ship [...]macro (using group/ref/[...]).
   
   Error in MD cue md.[...]: ShipGenerator: <defence> node missing. Ship [...]macro (using group/ref/[...]).

2. I think since the last patch I've been getting a weird output in debug. Not sure what this is. I don't have any mod that modifies the Skunk's cockpit macro, so...

   Code: Select all

   [=ERROR=] 61.22 Invalid SoundID "hash(958769488)" on macro: "units_player_cockpit_1_macro"! No definition found in SoundLibrary.

3. Also, not necessarily a bug but... could potentially be a design issue: I wrote a station-spawning script. It's somewhat based on the failsafe segment in Plot_ep1_ch2.xml, and uses its Build Location logic:

   Code: Select all

   <set_value name="$BuildLocation" exact="player.zone.freebuildlocations.random"/>

   My code has an added segment that creates a boundingbox and checks for obstruction around the build area (similar to how an Architect does it under normal building conditions). Once the boundingbox is clear, the script then spawns the station, followed by a CV (similar to how it was done in Plot_ep1_ch2.xml). After the CV is spawned and the crews are assigned, I made sure the CV is attached to the station with:

   Code: Select all

   <connect_to_build_location object="$CV" buildlocation="$BuildLocation"/>
   <set_buildanchor buildmodule="$CV.buildmodule" object="$Station"/>

   Here are the problems...
   • For some reason, the game does not consider the Build Location where the station has been spawned occupied. If I execute the script again, it has the chance to spawn another station right on top of the existing one (instead of using one of the other unoccupied Build Location in the zone).
   • The dialogue options of the Architect on the CV indicates that she doesn't think the CV is attached to the station, which could mean an issue with the <connect_to_build_location> and <set_buildanchor> commands, but I fail to see how (more likely just a dialogue tree issue)
   Now, I've been wondering about this: Just what exactly does the game do to mark a Build Location as occupied? The only time a Build Location is marked as claimed is when a build command has been issued, and the CV is on its way. Once the CV arrives and construction starts, the claim is removed.
   
   Yes, the CV is attached to the Build Location via <connect_to_build_location>, but that's really the only thing that would indicate to another Architect (on another CV) that the build location is occupied. If an attached CV were destroyed or somehow detached (via mod), what exactly is stopping another CV from "building" at a build location already occupied by a station? As far as I can tell, the station itself is not attached to the build location in any way.
   
   I was also looking at move.buildership.xml, and it has a safety check for $BuildLocation.child, but I am assuming the "child" in this case is the presence of a buildmodule (contained on another CV) that's attached to the build location, rather than the presence of a station...
   
   So back to the trouble with my script: If I spawned a station at one of the build locations, regardless of whether or not a CV is attached... how do I indicate to the game that build location is occupied? So that when "freebuildlocations" is looked up again, that build location doesn't show up in the results?

[YorrickVander]

For the npc on ship nodes, iirc you just do = null to satisfy the complaints. There's examples in vanilla i'm sure.

For the build locs, this happens in the free list for player + npc locs. Appears to be either a bug or legacy code. Using this check :

Code: Select all

<do_if value="not $BuildZone.freenpcbuildlocations.{$i}.child">

however will find if a loc is in use It is looking at the location, not a cv module so will not care if a cv is present or not.

[Simoom]

For the npc on ship nodes, iirc you just do = null to satisfy the complaints. There's examples in vanilla i'm sure.

For the build locs, this happens in the free list for player + npc locs. Appears to be either a bug or legacy code. Using this check :

Code: Select all

<do_if value="not $BuildZone.freenpcbuildlocations.{$i}.child">

however will find if a loc is in use It is looking at the location, not a cv module so will not care if a cv is present or not.

Looking into the Architect dialogue issue. I think the problem may be that I used <create_platform_actor>, which does set up a dialogue tree that properly detects if the actor is on a construction vessel. However, because the CV was already connected to the station on spawning, no player build action was performed (which is necessary for triggering the cue "BuildActionPerformed" which subsequently set up the appropriate dialogue options).

I will do a <signal_cue_instantly cue="md.NPC_Architect.Base" param="[$Architect, false, true]"/> to see if it resolves the issue.

As for the build location issue... I'll try the iteration method, but according to scriptproperties.xml:

Code: Select all

    <property name="buildlocations" result="List of build locations" type="list" />
    <property name="freebuildlocations" result="List of free build locations" type="list" />
    <property name="npcbuildlocations" result="List of NPC build locations" type="list" />
    <property name="freenpcbuildlocations" result="List of free NPC build locations" type="list" />

So "freebuildlocations" is supposed to select a random unoccupied build location in the specified zone, I think (am I misunderstanding this?), which should check for any .child at the build locations and eliminate them from the list.

I thought perhaps this function isn't working properly, which warranted a report in this thread.

I still think the $buildlocation.child refers to the buildmodule, though, which is contained within the connected CV... which again, begs the question, what marks a build location as occupied if no CV is connected to it (but a station was already built there). As far as I can tell, the station itself is not associated with the build location in any way; only the CV is.

[Simoom]

Okay, successfully resolved both issues. Definitely have a few bugs or possible game script improvements to report now.

1. The value freenpcbuildlocations definitely doesn't work as intended. It does not take into account any $buildlocation.child (connected build module) that's present. As it stands, it appears to simply generate a list of player buildlocations, which makes it indistinguishable from the value buildlocations.
   
   Currently the only workaround is for the coder to innumerate through a list of build locations in the zone and find ones without a child element:

   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>

2. The NPC_Architect.xml currently does not generate the proper dialogue options in the following scenarios:
   • An Architect was created via <create_platform_actor> on a CV that's already connected to a station. Since the cue BuildActionPerformed was not triggered, the Architect is stuck thinking that it is working on an unconnected CV.
   • An Architect working on a CV that has been disconnected from its parent station. The dialogue tree does not do a re-check of of the state of the CV when it is triggered, so it's stuck thinking that the Architect's CV is still connected to the station (even though the buildmodule has already been cleared and no buildanchor is present).
   At the moment, the simplest workaround for both issues I came up with is to trick the game into thinking the Architect has just arrived at the CV by transport (which triggers the cue OnDroneArrival, which then does a check on the state of the Architect's CV):

   Code: Select all

   <signal_objects object="$Architect" param="'remote_passenger_arrived'"/>

   But a better CV status detection routine in NPC_Architect.xml could be useful in the future.
3. Minor oversight report: In extensions\ego_dlc_2\assets\structures\landmarks\terracorp_hq_01_macro.xml, the ID tag has a space in the value brackets (it's not supposed to contain any spaces):

   Code: Select all

   name="{20102, 8501}"

   Not sure if this affects the game's ability to read back the name.
4. Minor oversight report: In assets\props\WeaponSystems\macrosweapon_invisible_lb_khaak_macro.xml (beam weapons used on Kha'ak fighters), the <identification> tag is missing. The game fails to display any name or description for the weapons, so just displays their macro value.

[Simoom]

Some new weirdness to report...

The previously-mentioned <signal_objects object="$Architect" param="'remote_passenger_arrived'"/> method works fine in re-establishing the architect dialogue if the CV were detached from its parent station, or if an architect were spawned on a CV that's already attached to a station. However, it creates a weird issue where the architect thinks she's on board the Skunk (I think). If you tell her to "come back on board", instead of getting into a transport drone, you see an animation where she just walks up the Skunk's ramp.

Subsequently, if you tell the architect to go back to the CV from where she came, she will enter a transport drone, leave the Skunk, then promptly fly back to the Skunk (making re-assignment impossible).

Additional weirdness includes that the "Call Architect" button isn't available when the CV is hailed, and clicking on a build location and telling the undocked CV to build there won't properly trigger a build action.

Looking into this issue now...

[XGamer]

Didn't read the topic, so sorry if this is already in here

the mk attribute of the unit subsection for create_ship doesn't accept variables, only numeric literals.

Code: Select all

<set_value name="$droneCount" exact="20"/>
<create_ship name="$ship" macro="units_size_xl_cargo_hauler_3_macro" zone="player.zone">
    <owner exact="faction.player"/>
    <pilot group="argon.pilot">
        <owner exact="faction.player"/>
    </pilot>
    <defence group="argon.defence">
        <owner exact="faction.player"/>
    </defence>
    <engineer group="argon.engineer">
        <owner exact="faction.player"/>
    </engineer>
    <units>
        <unit category="unitcategory.orecollector" mk="2" exact="$droneCount"/>
    </units>
</create_ship>

will result in a ship with 20 MK2 Collector drones.

But:

Code: Select all

<set_value name="$droneCount" exact="20"/>
<set_value name="$droneLevel" exact="2"/>
<create_ship name="$ship" macro="units_size_xl_cargo_hauler_3_macro" zone="player.zone">
    <owner exact="faction.player"/>
    <pilot group="argon.pilot">
        <owner exact="faction.player"/>
    </pilot>
    <defence group="argon.defence">
        <owner exact="faction.player"/>
    </defence>
    <engineer group="argon.engineer">
        <owner exact="faction.player"/>
    </engineer>
    <units>
        <unit category="unitcategory.orecollector" mk="$droneLevel" exact="$droneCount"/>
    </units>
</create_ship>

will result in a ship without any drones on board.

pilot, engineer and defence nodes within create_ship are present to avoid nasty error messages in log as well as to make sure the ship would be operational in case there is something weird going on in case it doesn't have that stuff. Except for log messages it doesn't make any difference though.

Edit:
Also it seems that

Code: Select all

<destroy_object object="$ship" explosion="false"/>

does not actually get rid of the ship. At least not when they're player owned and / or created and destroyed in a loop (tested OOZ).

Code: Select all

<do_all exact="100" counter="$idx" comment="Not sure the counter is required, it's not being used">
<!-- Insert create ship block from above -->
<destroy_object object="$ship" explosion="false"/>
</do_all>

[Simoom]

the mk attribute of the unit subsection for create_ship doesn't accept variables, only numeric literals.

Same with actor groups (used to specify macro selection on actor spawn) - only takes literals, doesn't accept variables. :/ Several of my scripts could be a bit shorter otherwise.

pilot, engineer and defence nodes within create_ship are present to avoid nasty error messages in log.

Reported this one earlier. I don't think missing the <pilot> node generates an error message, but <defence> and <engineer> do, which is annoying since I use <create_platform_actor> to generate the crew for my scripts.

[XGamer]

Same with actor groups (used to specify macro selection on actor spawn) - only takes literals, doesn't accept variables. :/ Several of my scripts could be a bit shorter otherwise.

didn't know the group attribute for actors behaved the same.
In any case, depending on the situation, you should be able to work around that by patching the character groups to have the macros you want, or use the macro attribute with a list (if that works as advertised at least).

Reported this one earlier. I don't think missing the <pilot> node generates an error message, but <defence> and <engineer> do, which is annoying since I use <create_platform_actor> to generate the crew for my scripts.

Yes, both (as in you reporting it and pilot not causing errors in the log) are correct (I did actually see you reporting it, as it was on this page of the thread). I just thought I'd mention it to explain the rather lengthy code example .

[Simoom]

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.

[YorrickVander]

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.

[Simoom]

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.

[Simoom]

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.

[Simoom]

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)