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

[j.harshaw]

But if I
use "start_script" within the aiscript to start "player.default", I get the error "Script attempts to abort itself via
<start_script>". If I move the start_script into a md cue that gets called when I send a specific signal via the
aiscript, I get a similar error "Script indirectly attempts to abort itself via <start_script>".

Was probably done to avoid a situation where an aiscript infinitely resets itself then sets itself again. I do know that start_script works if called from an md cue that has nothing to do with the ai script that it's cancelling, although your description of your problem sounds like you're doing something specific where this won't suffice.

Will try to ask Adrian tomorrow if he has time. Would be best if you could give us a clearer idea what it is you're trying to do though. PM if it's top secret.

[UniTrader]

i would guess he wants to add some kind of uninstall procedure which restores Vanilla behavior..

and Clownmugs solution would not work in this case afaik since this would cancel the mod script and all scripts it has called when the mod script is removed.. so it would only work while the mod is still active, but not suffice for a clean uninstall..

[Phipsz]

@UniTrader: again, same error. thanks though.

@clownmug: had thought about that, but ' set_command command="null" ' does not work sadly and I don't want to increase the command-depth as well...

@j.harshaw: I thought there was a valid reason to block it. what I'm trying to do is simply cancel a script and instead start player.default again on that entity. the exploration script is, as opposed to most other scripts started via "start_script", no looping script, but instead ends at some point. to avoid the ship being unresponsive to vanilla orders, I'd like to start player.default again. the option to stop the script via a "stop order" signal is optional, but would be quite nice to have as well. I'd guess the simplest solution would be to implement all of it as an interrupt for player.default, which in return would allow me to use all vanilla signals as well.

edit:
I worked around my problem by setting the script as an interrupt handler for player.default, indeed working as I intended now. I'd still be interested in how to initiate "player.default" from another aiscript though, if possible and if you'd still be willing to enlighten me there

[j.harshaw]

Hi Phipsz,

just had a talk with Adrian, and the dangerous thing about start_script is if an entity were allowed to cancel and start the same script on itself.

You can, however, use start_script from an entity onto another entity (starting a different script), or from an md cue that starts a different ai script. You cannot call start_script to start the same ai script.

[jth]

Something that I noticed a while ago but was in too much of a hurry to report

If you have a hot key linked to the in-game command line and you use it while a menu with a slider is on the screen then the in-game command line doesn't appear.

If you start the in-game command line and then open a menu with a slider then you can type into it with a slider present

not sure if this is as designed or not

Regards

jth

[Phipsz]

Hi Phipsz,

just had a talk with Adrian, and the dangerous thing about start_script is if an entity were allowed to cancel and start the same script on itself.

You can, however, use start_script from an entity onto another entity (starting a different script), or from an md cue that starts a different ai script. You cannot call start_script to start the same ai script.

Thanks for the info! I thought as much. As I already mentioned I already fixed it though, I consider this even to be much better than my previous try. I was planning on using an interrupt handler but just thought that it'd be much harder to do than it actually was. So yeah, nice job with the api, it keeps surprising me

[j.harshaw]

@Phipsz, hope that answered your question though. I think it did, but I'm still not entirely sure.

@jth, I asked if it was WAD or a bug earlier and Klaus gave me the enigmatic reply "possibly neither." This is only speculation but I think that means that it isn't working precisely as intended, but gets the job done well enough that it isn't considered a bug.

[Phipsz]

@Phipsz, hope that answered your question though. I think it did, but I'm still not entirely sure.

Yes, you did. Although it was not the answer I was hoping to get but the one I expected. I think it's a good design decision to block aborting the own script, although I think it has been working before 4.00. Well, it is nothing that could not be worked around in a better way, so I don't mind the change. Thanks for looking into it

[Clownmug]

I've got some more crashing problems with my Random Universe mod. It's seems that save files within the mod's universe start to cause crashing when the file size grows to a certain point. After loading the files the game will run fine for about a minute, and then it will just suddenly crash to the desktop. I don't know if it's related to the crashing caused by destroying regions, but the way it crashes without any error messages is similar.

Here's a link containing some problematic save files and related crash dumps: Crash Stuff

[YorrickVander]

While i see a comment in vanilla mining scripts indicating this is a known issue, it is also affecting correct assignation of mining ships that will function when player is in zone for my YAT mod.

This code :

Code: Select all

<find_object_component object="$oThisShip" name="$miningturret" multiple="true" class="class.turret" weapontype="mining"/>

 <do_if value="(not @$miningturret.{1}.exists) and ($oThisShip.cargo.{ware.ore}.max and $bGotDrones)">
     .... (do stuff)

is a fail point if the ship being selected to mine is not in zone with the player in some cases. Testing with debug output shows that any attempt to test for existing equipment is only relaible for a ship in visible attention.

While not a gamebreaker it would be very nice if this could function in any attention state.

[YorrickVander]

Following on from this, I think I see why I did not see the initial bug.

When testing I would build a miner, test the menu in zone, fly to a new zone with miner waiting. The menu showed correctly after laser exists test. New sector, laser exist test passed. Ju mp to another cluster, again laser test passed and menu displayed correctly. However when opening the menu to assign for the first time with the ship out of zone the test does not pass.

I would ask again if this is really working as intended. I can post a save or 2 to demonstrate this but it will not be applicable if YAT 2.03 not installed to see the effect.

[Clownmug]

I've got some more crashing problems with my Random Universe mod. It's seems that save files within the mod's universe start to cause crashing when the file size grows to a certain point. After loading the files the game will run fine for about a minute, and then it will just suddenly crash to the desktop. I don't know if it's related to the crashing caused by destroying regions, but the way it crashes without any error messages is similar.[/url]

I discovered the cause of the crashing which may also be responsible for causing stuttering throughout the game in general. It seems the problem is caused when escort ships get separated from their commanders across multiple zones. The constant pathfinding of all the ships trying to reach their commander seems to significantly reduce the performance of the game. I was able to fix the problem by either warping the ships to the commander's zone or just killing them off.

[Sparky Sparkycorp]

I wonder if the Flee mechanic and/or Very Hard Difficulty is pushing things over the edge by creating more disassociated [fighter] escorts.

It would be nice if escorts travelled in formation generally and if fighter escorts jumped and boosted alongside their commander capitals. Although that's perhaps a bit outside a vanilla fix.

[Clownmug]

I wonder if the Flee mechanic and/or Very Hard Difficulty is pushing things over the edge by creating more disassociated [fighter] escorts.

It would be nice if escorts travelled in formation generally and if fighter escorts jumped and boosted alongside their commander capitals. Although that's perhaps a bit outside a vanilla fix.

I think jumping with the commander would be fine as long as all the ships involved are in low attention.

[Clownmug]

Ok, now I'm really lost. I re-saved the files yesterday after applying the fix and now today the updated save files are crashing again. This time it's not even an delayed crash, it just occurs almost instantly after loading. The file sizes are also much smaller than the previous saves, so that probably rules out that being the cause. If anyone is interested here's a link to the new save files and crash dumps: More Crashing

Edit: Now things got a little weirder. After trying several times I actually managed to get save_008 to load without crashing. I also waited to see if it would crash after about a minute. Since everything seemed fine I decided to save the game, then this happened:
http://steamcommunity.com/sharedfiles/f ... =640621108

And on the save/load menus I see this now:
http://steamcommunity.com/sharedfiles/f ... =640621358

I'm also getting access denied errors when I try deleting the file outside the game.

Edit 2: After restarting my computer the save file has now mysteriously disappeared.

Edit 3: I figured it out, it's the region destruction problem again.

Edit 4: I've given up. Seems like it doesn't matter if I warp the player or not. It's almost completely random whether a save file will crash, freeze or run perfectly fine each time I start up the game.

[YorrickVander]

Small and silly one : DV Water Distillery has no admin dock. Priority so low it's buried.

[jth]

I get a couple of errors every time I click on an encyclopedia ware button since 4.00 came out and the change was made to the parameters that feed this script

[=ERROR=] 1495019.22 Error in MD cue md.Encyclopedia.EncyclopediaStart<inst:22e8a>: Property lookup failed: ware.wares
* Expression: ware.{event.param2.{3}}
[General] 1495019.22 ======================================
[General] 1495019.22 ======================================
[=ERROR=] 1495019.22 Error in MD cue md.Encyclopedia.EncyclopediaStart<inst:22e8a>: Failed to retrieve description text ID of null
* Expression: ware.{event.param2.{3}}

This looks to be caused by line 28 of Encyclopedia.xml which is still using event.param2.{3} when it should now be event.param2.{4}

Code: Select all

<do_elseif value="event.param == 'gEncyclopedia_ware'">
  <add_npc_line speaker="player.computer" view="closeupdetailmonitor">
     <description value="ware.{event.param2.{3}}" />
  </add_npc_line>

Its possible that line 43 also has the same issue

Code: Select all

<do_elseif value="event.param == 'gEncyclopedia_faction'">
    <add_npc_line speaker="player.computer" view="closeupdetailmonitor">
         <description value="faction.{event.param2.{3}}" />
     </add_npc_line>

The change seems to have been made to other entries further down the script

Regards

jth

[YorrickVander]

Not sure if this is a bug or if I'm misunderstanding the use. Setting up a captain on an npc ship with this code :

Code: Select all

<create_platform_actor name="$Commander" type="entitytype.commander" dockingbay="$Dock.component" ref="trader_omicron_lyrae_random">
    <owner exact="faction.heartofalbion"/>
</create_platform_actor>

Leaves the npc with the standard comms for a hireable npc. Using the command

Code: Select all

<set_comm_handler actor="$Commander" customhandler="false" />

reads as though it should set the default handler only from conversations.xml (surrender etc) but in fact leaves the npc trying to respond in both instances and giving the original (I would like to hire you option etc) menu. The npc also vocally greets the player twice.

The debug log output is as follows :

Code: Select all

[Scripts] 61.38 *** Context:md.MainMenu.SectionHandler<inst:1df2b>: Next section: gMain_charOrders
[Scripts] 61.95 *** Context:md.NPC_Staff.DefaultComm<inst:1dfa8>: Staff conversation started: default, actor=0x1a6a3, Leo Cheram
[Scripts] 61.95 *** Context:md.Conversations.DefaultComm<inst:1dfa9>: event_conversation_started: default, actor=0x1a6a3, Leo Cheram
[Scripts] 64.22 *** Context:md.MainMenu.SectionHandler<inst:1e098>: Next section: gMain_charOrders
[Scripts] 65.98 *** Context:md.Conversations.SectionHandler<inst:1e5c4>: Next section: g_cancel

[KlausM]

<set_comm_handler> doesn't create or remove a custom comm handler, it just provides the information whether one exists. Effectively the standard handler is suppressed if the customhandler flag is set. If it's wrongly set, you'll get wrong results.

<create_platform_actor> instantiates a handler script that includes a custom comm handler. It doesn't care whether the flag is set or not - after all, nobody else is supposed to mess with it.

If you want to remove the custom handler, either you have to cancel it, or better, don't use <create_platform_actor> in the first place. Instead, you could use a sequence of <create_cue_actor>, <add_actor_to_platform> and <remove_cue_actor>.

[YorrickVander]

Thanks for confirmation Klaus