[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 .