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

[j.harshaw]

Thanks, jth. Should be a straightforward fix. I'll let the team know on Monday when people are more likely to take a look. If I forget, and you remember, would really appreciate it if you give me a poke on Monday. You'll know I haven't if I don't list it in the OP or acknowledge it here as noted.

@UniTrader, as far as I know the order in that particular case still shouldn't matter. It's probably just to make the structure more consistent to facilitate easier reading. I'll ask around the office on Monday to be sure, though.

[j.harshaw]

Updates:

10) When using <move_to boost="true"/>, ships start boosting immediately rather than rotating into a good orientation before boosting. - Marvin Martian

- MM confirmed that it works for flightcontrolmodel.spline

clarification: <move_to boost="true"/> does only boost if it has a straight-line path and the way is unobstructed. This means that rather than the old behavior where ships about to boost stop and turn before boosting, they'll turn and maneouver the way they normally do until it is safe to boost, and will do so only in that case.

HOWEVER, ships will only do so if they are using flightcontrolmodel.spline. This is the default flight control model, so if this is not overridden by either specifying a different fcm, or using forcesteering="true" ships will use this.

Important note about forcesteering: if forcesteering is set to true at ANY point in the controlling entity's (usually captain or pilot) history, fcm is changed, even if forcesteering is later set to "false." In this case, setting fcm back to spline by using

Code: Select all

<set_flight_control_model object="$ship" flightcontrolmodel="flightcontrolmodel.spline"/>

should get them back on using fcm spline.

In any other flight control model, ships are much less selective about when to boost, and will tend to do so immediately when the move_to is called.

@Adrian, if any of this is wrong, please feel free to correct.

@Marvin, thanks for the report, and for testing and confirming that it works as described.

.......
11) Plot-triggered station construction in DeVries does not begin until player is in-zone. - YorrickVander

- being investigated

.......
12) Stations constructed in DeVries via plot-trigger do not upgrade, so do not have shields nor turrets. - YorrickVander

- being investigated

[Marvin Martian]

I think that the translation system is unhappy with me

do you use a master 0001.xml or only a file for each languageID?

[jth]

I think that the translation system is unhappy with me

do you use a master 0001.xml or only a file for each languageID?

Both, the 0001.xml catches the languages that I haven't got an individual file for and 0001-L049.xml for German

Plus a file for French, English, Spanish and Italian which all seem to work.

Most of the German works and the bit that doesn't is actually not in my extra file at all as its coming from {1016,72} and I am just substituting into it

Its weird as my Station Recycle uses the same approach in terms of files and I have never had any problems with it. I think that I ought to retry it again too.

The GetText(pageid=40000, textid=5) TextID not found messages and getting $ZONE$ in the middle of a message is what triggered my conclusions

jth

[X2-Illuminatus]

It also seems to affect some of the messages that I am creating

Code: Select all

            <substitute_text text="$logtext" source="{1016,72}" comment="Assigned $ENTITYTYPE$ $ENTITYNAME$ to (ship)$OBJECT$.">
              <replace string="'$ENTITYTYPE$'" with="$NewNPC.type.name"/>
              <replace string="'$ENTITYNAME$'" with="$NewNPC.name"/>
              <replace string="'$OBJECT$'" with="$ActorDock.component.name"/>
            </substitute_text>

In English its saying in the log and on the screen

Assigned commander Pok Keppel to Entertainment District

In German its saying in the log and on the screen

commander Pok Keppel zu Vergnügungsviertel in $ZONE$ zugewiesen.

I think that the translation system is unhappy with me

Regards

jth

That's actually a pure translation error. The line was changed in English (the "in $ZONE$" part was removed), but the change was not properly taken over into German and Chinese translations (where the "in $Zone$" part is still there) for some reason. This will be fixed for the next beta version.

[jth]

It also seems to affect some of the messages that I am creating

Code: Select all

            <substitute_text text="$logtext" source="{1016,72}" comment="Assigned $ENTITYTYPE$ $ENTITYNAME$ to (ship)$OBJECT$.">
              <replace string="'$ENTITYTYPE$'" with="$NewNPC.type.name"/>
              <replace string="'$ENTITYNAME$'" with="$NewNPC.name"/>
              <replace string="'$OBJECT$'" with="$ActorDock.component.name"/>
            </substitute_text>

In English its saying in the log and on the screen

Assigned commander Pok Keppel to Entertainment District

In German its saying in the log and on the screen

commander Pok Keppel zu Vergnügungsviertel in $ZONE$ zugewiesen.

I think that the translation system is unhappy with me

Regards

jth

That's actually a pure translation error. The line was changed in English (the "in $ZONE$" part was removed), but the change was not properly taken over into German and Chinese translations (where the "in $Zone$" part is still there) for some reason. This will be fixed for the next beta version.

My talent for finding rare issues still works

Thanks for the reassurance. I manually edited {1016,72} in the German file and the "in $ZONE$" is gone.

That has given me the confidence to keep the German translation in.

The "GetText(pageid=40000, textid=5) TextID not found" messages remain at the moment but don't "seem" be be causing me problems .... yet

jth

[jth]

This happens in both 3.61 and 4.00 Beta 4 HF1

The ai script that it removes is command.collect.cargo and the mod that is affected is FormatThousands v0.03.

Go into Cargo Collect mode and in the debug.log you get

[Scripts] *** aicontext<player.default,0x17655>: Start collect cargo mode...
[General] ======================================
[=ERROR=] Error in AI script player.default on entity 0x17655: AI script name 'command.collect.cargo' not found
* Expression: 'command.collect.cargo'

You don't actually need any crates to pick up although you will need a suitable cargo ship in your squad.

There is nothing in the debug.log at the patching point to say that anything went wrong

Background

What I am doing is to insert an ai script as a patch

There is a Catch 22 situation where you can only modify a script that already exists and the name of your patch file must be the same as that of the script that you want to modify or you get Ignoring root node 'diff'

To get around this I pick an arbitrary ai script and piggy back in via it.

Essentially it selects the root node of an ai acript and then inserts my ai script before it as another sibling. It should have absolutely zero effect on the other ai script.

The ai script that I picked was command.collect.cargo

The diff file is

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<diff> 
  <!-- Add the format.thousands ai script if not present use command.collect.cargo as trojan horse -->
  <add sel="/aiscript[@name='command.collect.cargo' and not(format.thousands)]['FormatThousands library already present']" pos="before" silent="true">
    <aiscript version="2" name="format.thousands" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="aiscripts.xsd" priority="10">
     .......
    </aiscript>

  </add>
</diff>

There is probably one other innovation in there that may look odd and that is ['FormatThousands library already present']. This is being used as a comment to help diagnosing later issues. ['FormatThousands library already present'] is always true so it doesn't affect the outcome and if something goes wrong its readable without scrolling to the right. If this is removed the issue remains.

This is probably a fairly unusual sel statement so the effect of this issue on other scripts is likely to be minimal.

EDIT
I thought that pos="after" fixed it but all it does is not insert the FormatThousands ai script instead

I am going to have to issue another fix to get the FormatThousands back again. I think that I am just going to put the FormatThousands ai script in as a script for the moment and remove the command.collect.cargo diff

Regards

jth

[UniTrader]

Erm... Inserting an AI Script as patch does not make any sense at all..

Yes, you can add it without the game complaining - but it won't have any effect since the game doesn't expect something like this and it will be ignored then.
Also you suppressed possible patching errors with the silent attribute

[jth]

Erm... Inserting an AI Script as patch does not make any sense at all..

Yes, you can add it without the game complaining - but it won't have any effect since the game doesn't expect something like this and it will be ignored then.
Also you suppressed possible patching errors with the silent attribute

The reson that I tried it was so that the ai script could be inserted by two different mods and the newest version would win. If you just add it as a file then the first to be found wins. I wanted to use this method rather than have a dependency. I don't like lots off dependencies.

It did actually work with pos="before". I suspect that it actually replaced command.collect.cargo

looking at it from a pure patching xml viewpoint it should be possible

Good point about suppressing errors but I am pretty sure that it didn't say anything when doing pos="before" when the silent was not there. It was suppressing when I did pos="after" so not sure if that does create an error

jth

[YorrickVander]

A low priority and classic omission came up in skype chat today : HoA licences and the lack of any owned zones or HoA police for the npc generator even if we mod the ownership to HoA. Maybe give them a break and let them own Exhaustless Mines in vanilla?

[j.harshaw]

@jth, you could set the mod with the newest version of the file as an optional dependency. That way, if that mod is present, the files from that mod will be loaded first. Bit of a bother if you'll have several mods using the file, especially if the mod with the latest file changes; but if you keep your newest file consistently in one mod and make the rest optionally dependent on that one, you'll just have to maintain the file in that one mod. And your other mods will still be functional by themselves albeit with older versions of the file.

Did that make sense? It's getting late.

[lubatomy]

not sure if this is a good place to report this one as it may just be a general bug in and of itself. It is something that i have fixed to my belief in how it should work a few times via making my own mods to correct it.

move.jump seems to be written in a poor manner.

what move.jump script does from my reading and following:

step 1 - check for jump drive. if no jump drive then call correct move script. if jump drive exists but is broken, fail with broken jump drive as reason. If jump drive exists and works go to step 2

step 2 - check fuel level. if low fuel, try to refuel (either self refuel or ask player to allow refuel). If cant refuel, sit in place for 10 minutes (or whatever current value is) so that jump drive can charge with no fuel. go to step 3.

step 3 - check next destination. if location is beyond a jump gate then fly to jump gate and fly through it (a process that should not use fuel because the jump gate is what powers the flight, not the jump drive), otherwise jump to next location in route.

I believe that the order is wrong and that the script should do something like this:

step one - check next step in path. if next step is flying though a gate, then fly to gate and use it, then continue as usual.

step 2 - if next step requires a use of jump drive, then check if jump drive exists and is working as current script does.

step 3 - check for fuel like current script does. if no fuel and no re-fuel then wait for jump drive slow charge up time.

step 4 - jump to next step and continue as usual.

the method by which i fix this has changed each time the game has been patched and the move.jump script changes. recently I have taken to adding labels and resume label commands to reorder the process but it is likely not the best way to do thing (I do this to avoid moving wait commands and the like around as i know that can do bad things).

This has been this way for as long as i can remember and is still present in the current beta (without HoL as i am not in that beta).

[j.harshaw]

Hey lubatomy, good idea, except move.generic already filters for that.

Code: Select all

            <do_if value="$jumppath.{1} == this.sector and $jumppath.{2}.isclass.gate">
              <set_value name="$jumpgate" exact="$jumppath.{2}" />
              <run_script name="'move.generic'" sinceversion="3">
                <param name="destination" value="$jumpgate" />
                <param name="nojump" value="true" />
                <param name="debugchance" value="$debugchance" />
              </run_script>
              <!-- we should have gone through the gate and be in the correct cluster now -->
              <do_if value="$jumpgate.destination.cluster != this.cluster">
                <debug_text text="'failed going through gate!'" chance="$debugchance" />
                <!-- TODO: try again? -->
              </do_if>
              <remove_value name="$jumpgate" />
              <!-- move forward to a safepos to make sure the gate exit area is clear -->
              <get_safe_pos object="this.ship" direction="quadrant.front" radius="this.ship.size" angle="45deg" result="$safepos" zone="this.zone" />
              <move_to object="this.ship" destination="this.zone" usehighways="false" finishonapproach="true" abortpath="true" sinceversion="6">
                <position value="$safepos"/>
              </move_to>
              <remove_value name="$safepos" />
            </do_if>
            <do_else>
              <debug_text text="'Long distance trip. Using jump drive...'" chance="$debugchance" />
              <run_script name="'move.jump'" result="$jumpresult">
                <param name="destination" value="$destination" />
                <param name="position" value="$position" />
                <param name="skipcharge" value="$skipcharge" />
                <param name="ignorefuel" value="$ignorefuel" />
                <param name="autorefuel" value="$autorefuel" />
                <param name="debugchance" value="$debugchance" />
              </run_script>
              <do_if value="$jumpresult" exact="false">
                <debug_text text="'ERROR: Jump to %1(%2) failed'.[$destination.knownname, $position]" />
                <set_value name="$nojump" exact="true" />
                <wait min="10s" max="1min" />
              </do_if>
            </do_else>

So if a ship has to move through a gate in the current sector, it shouldn't call move.jump at all.

Checking for travel through a gate comes later in move.jump because the first step is assumed to be a jump, possibly followed later on by gate travel. Looks like it makes sense.

A pity you didn't participate in the HoL beta. We could use more good testers.

[lubatomy]

im only level 3 so had no clue it existed until i saw someone posting about it. I will double check but i assume the HoL installs as an extention just like Teladi Outpost. If it does then yes I am not in it unfortunately.

[j.harshaw]

Update:

5) Reservation handling like get_ware_reservation does not distinguish between incoming and outgoing trades. - Marvin Martian

- CHANGED as of 4.0 Beta 4 HF2

http://forum.egosoft.com/viewtopic.php?t=366346

Did I miss anything, or can I mark this noted up to this point?

[YorrickVander]

A suggestion rather than an actual bug, I notice that Jump Drive Coolant is not flagged as .israre although it is probably the rarest drop in the game as it stands. Just as a cosmetic thing for those that make use of such flags, could that be added please?

[j.harshaw]

A suggestion rather than an actual bug, I notice that Jump Drive Coolant is not flagged as .israre although it is probably the rarest drop in the game as it stands. Just as a cosmetic thing for those that make use of such flags, could that be added please?

Done. Thanks for the reminder.

[YorrickVander]

ty santa harshaw

[j.harshaw]

Oh, wait! You're on the naughty list! (What to do now... Hmm...)

[Sparky Sparkycorp]

Create new condition?

.israre.ifnot.yorrick