All in one 2.0.1 beta 5 available

[thunderchero]

Just a matter of taste, but all mods use the vanilla 1.0.3 base files?
So new Borg button, or separate load/save buttons, cause extra work for AIO for all mods with custom GUIs (e.g. GAL mod, UDM)?

I reckon a final AIO update around christmas with new UE features. If you are short on time you might want to wait until then and contemplate all options?

Yes every mod first loads the base files (German/English) depending on language selected.

after that depending on mod/option selected files will be overwritten by mod files in base files

here is my current inno setup script (text format)

inno_setup_script.txt

(190.34 KiB) Downloaded 50 times

[Flocke]

I reckon a final AIO update around christmas with new UE features. If you are short on time you might want to wait until then and contemplate all options?

What features?

I still need to catch up on your latest discussions and save game files. Nonetheless I'm already far beyond the UE additions I planned for and just miss some final minor polishing. Will need some testers soon.

Even tried ECM (from aio2 beta5) now. I feared to face countless patch conflicts but it showed none at all. Looks to be perfectly compatible with my latest UE modded_save_detection build. Both for stbof.res and for trek.exe changes as well as the save game files.

[Spocks-cuddly-tribble]

Don't stress yourself, mod compatibility, auto-fixing certain saved game errors and the ability to edit map sectors/ships without messing up the saved game are great features to many users (dev version -> stable release).

My notes on saved game files are just for research purposes. ECM has fewer deviations to vanilla saves than before (removed one alienInfo workaround), different shiplist.sst IDs/sorting still being the main deviation (otherwise we could use vanilla saves with ECM).

[thunderchero]

I reckon a final AIO update around christmas with new UE features. If you are short on time you might want to wait until then and contemplate all options?

problem is you would never get any real testing with manual added patches, last night I was able to collect all the res files, but will need to add a few lines of script for needed resolution files. So I hope to be able to have beta 6 ready by this weekend or first of next week.

not sure if you are interested, but when I was going though some old files I found my edited tga files for the *marker.tga's

marker.jpg (89.87 KiB) Viewed 1757 times

_mbof.rar

(63.18 KiB) Downloaded 44 times

One other thing that would be simple is editing opening screens by adding to logo like this

cc_bkgd.jpg (151.84 KiB) Viewed 1752 times

I still need to catch up on your latest discussions and save game files. Nonetheless I'm already far beyond the UE additions I planned for and just miss some final minor polishing. Will need some testers soon.

just wondering did you ever look at structure upgrades? From my observations UE only understands main structures with 9 upgrades (vanilla) or no upgrades (using tech level %). Mods like bop and MUM use less than 9 upgrades and UE tends to break upgrades by changing a working upgrade list.

Ok I am interested why the "inno_setup_script.txt" is being downloaded so much, I expected maybe 2-3 downloads but currently it is up to 10
I guess there are more people like me who just look under the hood of things.

[Flocke]

just wondering did you ever look at structure upgrades? From my observations UE only understands main structures with 9 upgrades (vanilla) or no upgrades (using tech level %). Mods like bop and MUM use less than 9 upgrades and UE tends to break upgrades by changing a working upgrade list.

No, but there indeed seems to be a larger issue that didn't spot my attention yet. Doing some testing on the one hand the main building id ranges seem to get messed. On the other hand at least the MinorRaceBldUpgradeIDs segment is fixed to 9 upgrades all the time and might cause issues too. I'll take a closer look at both of them.

Ok I am interested why the "inno_setup_script.txt" is being downloaded so much, I expected maybe 2-3 downloads but currently it is up to 10
I guess there are more people like me who just look under the hood of things.

One is by me, and I immediately deleted it again after I took a glimpse. What a mess!

One thing that still bugs me is that Comodo still flags each extracted .tmp file as "CloudScanner.Trojan.Gen@2@1", even when not executed and renamed to .exe. Same time, uploading it to virustotal shows not a single virus detection to flag the file, not even Comodo. Might be the free version I'm running.
Doing some web search that generic false positive detection message is a common issue with Comodo for years... just like I experience with AIO2.

Since it is still a beta release, I don't care on it for now. But would be great when you add the SHA or MD5 hash codes to verify the file after download.

[Spocks-cuddly-tribble]

not sure if you are interested, but when I was going though some old files I found my edited tga files for the *marker.tga's

I'd need to re-download and install the game for comparison, but for my taste something seems off?

One other thing that would be simple is editing opening screens by adding to logo like this

Thank you, looks very professional, but I find it a bit convoluted and I'd like to keep it as simple/clear/default as possible.

the MinorRaceBldUpgradeIDs segment is fixed to 9 upgrades all the time and might cause issues too

No, for the UE issues at hand (number of tech levels and/or upgrades) just ignore minors:

- 10 Evolution Levels do not restrict number of tech levels used in game
- fake upgrades (old main buildings removed, new random type/number via tech levels from EL table):

At asm-58FFAC is a table with the first resp. lowest IDs of minor main buildings and at asm-58FFD4 the corresponding last IDs: 2 byte building IDs * 4 groups (Industry, Food, Energy & Research) * 5 major race types * 2 first/last ID = 80 bytes, 40 building IDs in total

Food might start with tech 0 Primitive Farms (better double-check)?


For the empire upgrade issue I'd keep the unedited vanilla sorting order (in case UE re-sorts the main buildings for better human perception).

IIRC thunderchero pointed out that even in BoP the reduced upgrades still have some trek.exe code issues (not due to UE)?

Problem might be determining whether certain parts of upgrade codes with a range from 1-9 refer to tech levels or relative building IDs?

I am interested why the "inno_setup_script.txt" is being downloaded so much

One is by me, and I immediately deleted it again after I took a glimpse.

Yeah, very disappointing, no nude Dabo girls. But we have many hillarious downloads for nonsensical files, some might be bots/spiders/crawlers?

Can't assist with the setup. Looks like a compromise between structure simplicity and total file size (some redundant double files in favor of less work/code lines).

[thunderchero]

Problem might be determining whether certain parts of upgrade codes with a range from 1-9 refer to tech levels or relative building IDs?

I think it is building ID only, but for so many year it was thought of as tech level.

I thought about changing size of upgrade table but knew this would cause even more issues with UE.

the only thing that worked in game properly was to;

example cards industry upgrades

Code: Select all

      
tech1 |        42 
tech5 |        43 
tech10 |       44
tech15 |       45 
tech20 |       46 
not used |     46 
not used |     46 
not used |     46 
not used |     46

I use 4 upgrades (5 total structures) then to fill table I repeat the last upgrade ID.
this works in game and minor seem to properly upgrade as well.

IIRC thunderchero pointed out that even in BoP the reduced upgrades still have some trek.exe code issues (not due to UE)?

BOP has different upgrades for each type

intel and research has vanilla 1 - 9
food and energy has no upgrades
industry has 3 upgrades (4 total)

but I have never looked at how BOP has his upgrade table

BOP has an issue when UE views structure with code at 0x0505d1 for "basic dilithium source"

here is BOP code changes

Code: Select all

>> 0x0505d1 85 C0 75 0C BA 06 00 00 00 89 C8 E8 0F 4C FF FF
>> 0x0505e1 8B 84 24 62 01 00 00 BA 06 00 00 00


<< 0x0505d1 66 8B 84 24 60 01 00 00 E8 A6 94 FE FF 89 C2 90
<< 0x0505e1 8B 84 24 62 01 00 00 90 90 90 90 90

UE can not find/don't match for the dilithium refinery id of BA 06 00 00 00

[Spocks-cuddly-tribble]

BOP code changes UE can not find/don't match for the dilithium refinery id

And there is no need for UE to change this pointless/redundant code: viewtopic.php?p=17859#p17859
Just disallow changing certain building IDs like OB, SH, bunker network, refinery, yards, emergency morale programs...

Your fix code for a MUM/BoP issue when cross upgrading into other race type: viewtopic.php?p=52106#p52106

Also I never tested the 'Upgrade foreign structures automatic-build function fix': viewtopic.php?p=46492#p46492
Or this claim:

one of the annoyances I find about the auto build is it continues to build and upgrade research stations despite reaching the end of tech (level 9).

[Flocke]

I use 4 upgrades (5 total structures) then to fill table I repeat the last upgrade ID.
this works in game and minor seem to properly upgrade as well.

Great, answers the first question that came to me when I started to analyse the written upgrade ids for BOP.

As I found, BOP did not change any of the trek.exe MinorRaceBldUpgradeIDs starting at 0x0018EDE8 ( asm_590FE8, viewtopic.php?f=264&t=2299 ), they are still set to vanilla values.
When UE saves any Edifice changes, it overwrites these ids and fills any missing values repeating the last upgrade ID.

By your comment above the fixture is correct. I will however add some integrity checks and presumably change the code to already apply those changes when the view is closed. And I think I'll add a checkbox for whether to update trek.exe.

BOP has an issue when UE views structure with code at 0x0505d1 for "basic dilithium source"
...
UE can not find/don't match for the dilithium refinery id of BA 06 00 00 00

I fixed that one a week ago with the MandatoryDilithiumFix

Thanks for the input both of you. I'll keep investigating the UE BOP trek.exe upgrade id changes when editing edifice and report back.

[Flocke]

the MinorRaceBldUpgradeIDs segment is fixed to 9 upgrades all the time and might cause issues too

No, for the UE issues at hand (number of tech levels and/or upgrades) just ignore minors:

- 10 Evolution Levels do not restrict number of tech levels used in game
- fake upgrades (old main buildings removed, new random type/number via tech levels from EL table):

At asm-58FFAC is a table with the first resp. lowest IDs of minor main buildings and at asm-58FFD4 the corresponding last IDs: 2 byte building IDs * 4 groups (Industry, Food, Energy & Research) * 5 major race types * 2 first/last ID = 80 bytes, 40 building IDs in total

When I understand your explanation correct, that is exactly the reason why NOT to ignore MinorRaceBldUpgradeIDs. The IDs must be of correct type and be reasonable. UE however writes the EL table like it was tech levels!

Not sure how to fix this. UE might need another menu here to individually select a proper structure for each evolution level.

Food might start with tech 0 Primitive Farms (better double-check)?

For EL table UE indeed starts with the tech 0 Primitive Farms, for major races there is special handling and it starts with tech 1 farms instead.

For the empire upgrade issue I'd keep the unedited vanilla sorting order (in case UE re-sorts the main buildings for better human perception).

UE does not sort those entries, and it doesn't even check whether they are in sequence. It even misses integrity checks on the upgrades to be in sequence yet.

[Flocke]

Regarding the BOP main structure IDs, UE compares the group types here to determine the ID spans. While BOP kept unused main structures in the structure list and didn't update the trek.exe ID spans, it changed unused structure groups to 'Other', which is causing UE to 'mess' or better say 'update' the main structure ID ranges.
This counts for food, energy and industry.

What indeed gets messed is the main industry AND food range. Now that there are unused factories of group type 'Other' preceding the farms, it already stops range detection at the last main industry building.

That brings me to the following questions:

• Are those obsolete fake main structures listed in BOP still required by something or could they be removed?
• Isn't it a bug to still list them by the minor race EL table 0x0018EDE8 (asm_590FE8) and the building limits at 0x0018DDAC (asm_58FFAC)?
• Must the group be changed? Isn't it enough to unset the upgraded structure id and make them not buildable by any empire? (should be the preferred patch if possible)
• How should the correct range be determined by UE?
• And for what strange reason is there a combined main industry and food ID range (emp0 type begin: 0x8597B / asm_48657B, end: 0x85B05 / asm_486705)?

Main buildings of a specific group and race need to be grouped together in edifice.bst. This means Cardassian main food buildings need to be placed one after the other. Same goes for the other groups of main buildings.

Main industry and food buildings of a race also need to be grouped together (industry first, food second).

UE does not yet test for these things so be careful. It takes the first group it finds (test for empire, pop req and group).

edit: I guess first question is answered by:

The problem is still that slots of manned buildings (i.e. the 25 main structure groups) can't converted into unmanned special buildings (some corresponding trek.exe or edifice.bst parts aren't complete found/hacked).
I've tried to use four of the five primitive farms slots for that -> no way to reach a proper functionality.
And AFAIK nobody solved that yet.

[Spocks-cuddly-tribble]

the trek.exe MinorRaceBldUpgradeIDs starting at 0x0018EDE8 ( asm_590FE8

MinorRaceBldUpgradeIDs is an epic mislabel. Minor starting buildings (not upgrades) is the least important purpose of this important shared code.

that is exactly the reason why NOT to ignore MinorRaceBldUpgradeIDs. The IDs must be of correct type and be reasonable. UE however writes the EL table like it was tech levels!

Not sure how to fix this. UE might need another menu here to individually select a proper structure for each evolution level.

Miscommunication wrt to:

- MinorRaceBldUpgradeIDs
- EL table (all tech levels for each of the 10 Minor Evolution Levels)

Asm-58FFAC/58FFD4 is just first/last main building IDs depending on number of upgrades (see my format description), but this pseudo code is not conected with any other trek.exe upgrade issues. NOT an EL (evolution level) table, but yes, by default used when reaching a new EL.


The 10 Minor ELs table (all tech levels for each EL in racetech.tec?) is shared for:

- starting tech levels (via random/trek.exe EL)
- pseudo research progress (new techs via EL)

Total number of ELs should remain 10, but the max tech level(s) for/in each EL should be unrestricted.

I guess first question is answered

It's a very old comment and I think the issue was solved by Peter1984 (after the last BoP release)?
But I never edited main buildings or patched any of the codes and don't know if UE supports all modding options of the various main building patches.

'a priori' no one can answer some of your above questions, Gowron just used the easiest, working setup at the time. But again two epic mislabels:

the minor race EL table 0x0018EDE8 (asm_590FE8) and the building limits at 0x0018DDAC (asm_58FFAC)?

As told: 0x0018EDE8 (asm_590FE8) -> shared main building code (not minor)
building limits at 0x0018DDAC (asm_58FFAC) -> minor fake upgrade -> main buildings min-max IDs -> yes looks like a BoP bug (not analysed at the time)

for what strange reason is there a combined main industry and food ID range (emp0 type begin: 0x8597B / asm_48657B, end: 0x85B05 / asm_486705)?

Take a wild guess based of the XREF: (intel code)

Code: Select all

sub_486550 main_ind_food_ener_bldg proc near                 ; CODE XREF: intel_stuff_e_output_types

[Flocke]

As told: 0x0018EDE8 (asm_590FE8) -> shared main building code (not minor)
building limits at 0x0018DDAC (asm_58FFAC) -> minor fake upgrade -> main buildings min-max IDs -> yes looks like a BoP bug (not analysed at the time)

I will rename those files then. Makes sense to have a shared main building upgrade table that is neither bound to evolution levels nor to tech levels.
It just happens to be the size of 10 per structure by the vanilla building upgrade tech requirements.

'a priori' no one can answer some of your above questions, Gowron just used the easiest, working setup at the time.

Then let's forward the question to the originator for changing the building group type:

but found one race trying to build a structure "N\A" not sure how it was displaying this but it was. to fix this I set all unused structures so nothing was selected for "can be built by" and "needed race on system". Then they stopped tring to build "N\A" structures also all unused structures were set to "other" type.

Note: N\A only happened after AI took over home system of another race. and in tool tips it showed upgrade for one of the new buildings when building had no upgrade? this was very strange behavior even for this AI.

This is what troubles UE here, and to my belief the better fix would be when that can be avoided.

UE depends on the group type to determine the building sequence, and other values like the category are also used by special buildings.
In case it is required, I'll patch UE to include all buildings that come in between industry and food, and check that the expected count is matched as well as the category and 'other' group type. That should do fine, but means unnecessary mess in case setting the 'other' group type actually is no requirement.

[Spocks-cuddly-tribble]

It just happens to be the size of 10 per structure by the vanilla building upgrade tech requirements.

It's bizarre/inefficient code leading to the many strange exception bugs discussed above.

Most upgrade codes check:

- current type/ID of main building
- next upgrade via table (vanilla current building tech requirement +1, but no hardcoded tech +1 requirement) -> cross/race-type upgrade bugs
- current tech level of system owner (automatic-build bug)


EDIT:

As you say, for UE the technically best option would be to force all mods to be upgraded with above fixed special building IDs and to update outdated edifice.bst upgrades in older mods like BoP.

But updating mods is a lot of time/work for editing plus extended testing for errors (hence thunderchero rather keeps strange MUM morale buildings) and updating/testing all BoP issues/bugs (without creator permission btw) would be a lot of work....

[thunderchero]

I wish I had more input on tech stuff above.

in my experience I have not had any issues with the "starting technology" page. It works properly with extended tech levels, even before it did not display above tech 10 (dropdown selections fixed )

but if you have any thing to test let me know.

as for BOP long time ago I tried to list code changes Gowron made but many were still left unexplained and Gowron never really explained many of his mod changes. Just another example he has some unknown map generation changes (had issues setting up widescreen).

in my opinion if BOP loads in UE and does not error on saving "UE is good on BOP".

The modified lexicon.dic in combination with the rest of the mod is INCOMPATIBLE with all Ultimate Editor versions that are older than version 0.6.1c. If you use an older version of UE to edit this mod, then you must use the original lexicon.dic while you edit the rest of the files. You can then edit the modified lexicon.dic with the Ultimate Editor separately.
Further modifying trek.exe with the Ultimate Editor can corrupt trek.exe. In particular, the number of ships in the game must not be increased using the Ultimate Editor.