30 replies to this topic

[ScuD]

Ah, I'm not expecting any problem, NI reports it as corrupted if checking. It is not corrupted after WoP.
And having checked with WORLDMAP instead of WORLDM25 I really think the issue is in the WeiDU function, not in the way you use it.

[Wisp]

Ah, I'm not expecting any problem, NI reports it as corrupted if checking. It is not corrupted after WoP.

. Oh, that. It's (probably) harmless (in this particular case). A link is referenced from two different places and NI doesn't approve. The game doesn't seem to mind, at any rate.

Edited by Wisp, 14 November 2010 - 02:40 AM.

[Wisp]

Clicked 'Reply' instead of 'Edit'

Edited by Wisp, 14 November 2010 - 02:39 AM.

[ScuD]

OK, just wanted to know. For the sake of consistency
I'll ask thebigg about the macro.

[Wisp]

On the topic of the BP-BGT_Worldmap mod, I'll try to have it available from SHS sometime soon [1], in case someone's impatient.

[1] "Soon" can be roughly estimated to occur around the "20th or so".

Edited by Wisp, 14 November 2010 - 02:20 PM.

[DrDreh]

Why the size is 26Mb while v7 is 96Mb?

ou can upgrade from earlier versions. To do so you need to uninstall the old version of BP-BGT_Worldmap and manually delete its mod folder. You then extract v8 of BP-BGT_Worldmap into your installation directory and install the mod. If you have saved games you wish to update you can (and should) do so with the save-updating component. The process is analogous for switching back to v7.1.

Where do I find the save-updating component?

[Wisp]

Why the size is 26Mb while v7 is 96Mb?

Because v8 is à la carte, whereas v7 included all the Italian stuff, German stuff etc, regardless of what language you were going to use.

Where do I find the save-updating component?

It's the third and last component of the mod.

[the bigg]

Is the WMP corruption a problem that should be fixed in sc#addWmpAre, or is the bug caused by improper coding in another mod?

[Wisp]

Is the WMP corruption a problem that should be fixed in sc#addWmpAre, or is the bug caused by improper coding in another mod?

The stuff ScuD pointed out is caused by sc#toNewAre. In this case it adds links from AR3000 to the new area and the end result is that East has 1 link starting at index 3 and South has 8 links starting at index 2. On the subject of correct indexing I should point out this.

I've been meaning to look into it but I have been strapped for time and/or forgotten.

[the bigg]

Probably fixed.

--- /home/vbigiani/sources/WeiDU/src/tph/include/sc#addwmpare.tpa       2010-11-06 11:42:51.722301800 +0100
+++ tobr/sc#addwmpare.tpa       2010-11-30 19:05:37.975932900 +0100
@@ -184,7 +184,11 @@
         DEFINE_PATCH_MACRO ~tb#sort_swap~ BEGIN
           SET tb#sort_val_i = EVALUATE_BUFFER $tb#sort_value(~%tb#sort_i%~)
           SET tb#sort_val_j = EVALUATE_BUFFER $tb#sort_value(~%tb#sort_j%~)
-          PATCH_IF (tb#sort_val_i < tb#sort_val_j) BEGIN
+          SPRINT tb#sort2_val_i $tb#sort_value(~%tb#sort_i%~)
+          SPRINT tb#sort2_val_j $tb#sort_value(~%tb#sort_j%~)
+          SET tb#sort2_val_i = EVALUATE_BUFFER ~#%tb#sort2_val_i%~
+          SET tb#sort2_val_j = EVALUATE_BUFFER ~#%tb#sort2_val_j%~
+          PATCH_IF (tb#sort_val_i < tb#sort_val_j || (tb#sort_val_i = tb#sort_val_j && tb#sort2_val_j > tb#sort2_val_i)) BEGIN
             SPRINT tb#sort_tmp $tb#sort_value(~%tb#sort_i%~)
             SPRINT $tb#sort_value(~%tb#sort_i%~) $tb#sort_value(~%tb#sort_j%~)
             SPRINT $tb#sort_value(~%tb#sort_j%~) ~%tb#sort_tmp%~

Edited by the bigg, 30 November 2010 - 10:21 AM.

[Wisp]

Probably fixed.

Yes, it takes care of the problem.

Edited by Wisp, 30 November 2010 - 11:26 AM.