New Resource & Building-Output Types Discussion

[Spocks-cuddly-tribble]

Nice work! Vanilla-ish icons for ECM don't fit in the esthetics of GALM.

EDIT: Btw you could also change the resource type from asteroid to any other (e.g. alloy + dilithium in GALM).

[Tethys]

It's possible in the future (I just found my Celestia files) that icon pack 2.0 could happen. But man, 1.0 was hard work and gigabytes of images...

I would take more care to attach visible atmospheres to the planets, and also probably do all the stars as well.

In GALM, there is kind of a 3 tier resource. Dilithium might make a comeback. Tier 1: Regolith (darker asteroids), Tier 2: Alloy (dilithium) only, Tier 3: (shiny) Regolith, Alloy, Dwarf star

Tier 1 has the refinery complex. Expensive to build and maintain. But will get you 1 Alloy if you can't find cheaper alloy nearby. I am probably going to change this to a duranium mine with a decent industry bonus
Tier 2 your every day joe schmo alloy refinery. Cheap to build and maintain.
Tier 3 cream of the crop; enjoys both refineries, and also gets a very lucrative mining facility (particle fountain) 500% "credits" for that system

Crazy times for GALM right now. Non-planetary nebulae have "structures" now, as do some anomalies. I have also somehow managed to make the Combat Drone (Empok Nor) stationary, hailable, and firing weapons if attacked (Edo code).. so I'm not going to mess with that anymore unless I really have to (Edo race check last issue I think).

Most of it is thanks to you, without you and the other codemasters GALM would be dead a long time ago. Thanks for keeping me going

[Spocks-cuddly-tribble]

But you still need to fix patch code for your new habitable anomaly IDs, right?

This means extra (relocation) code here:

Star Type

004B7C24     8A4E 31        MOV CL,BYTE PTR DS:[ESI+31]
004B7C27     80C1 0E        ADD CL,0E
004B7C2A     90             NOP
004B7C2B     90             NOP

First check if object ID is (red giant=04, orange=05, yellow=06, white=07, green=08, blue=09)

4B7C27 -> jump to new relocation code

@ new relocation code

cmp cl, 3
jle check habitable anomaly
cmp cl, 0A
jge check habitable anomaly
ADD CL,0E -> jump 4B7C2C  // old star type

ELSE (new habitable anomaly): 00 = blackhole, 01 = X-ray pulsar, 02 = nebula, 03 = neutron star, 0A = wormhole, 0B = radio pulsar

loc_check habitable anomaly

cmp cl, 0
JE -> MOV CL,11 -> jmp 4B7C2C  // 00 = blackhole
cmp cl, 0A
JL -> add cl, 0D -> jmp 4B7C2C  // 01 = X-ray pulsar, 02 = nebula, 03 = neutron star
add cl, 2 -> jmp 4B7C2C   // 0A = wormhole, 0B = radio pulsar

But if you create new extra objects with ID 0xC+ via UE it will still break the bitmask code and set wrong system features.


If you want to disable code for adjacent sector anomalies (since your new habitable anomalies now use the feature):

004B7C1F         call    for_wormhole_pulsar_s__building_bits // remove this via nop 9090909090

[Tethys]

Icons Uploaded

[Flocke]

But if you create new extra objects with ID 0xC+ via UE it will still break the bitmask code and set wrong system features.

I warned you not to mess with code replacement of UE. It uses code space best as possible and you can add many more stellar types. Both ihnabitable and non-inhabitable....

I also reported before that there are more code locations to fix, when you want to configure system features and such. That is not supported by UE yet.

[Spocks-cuddly-tribble]

code replacement of UE. It uses code space best as possible and you can add many more stellar types. Both ihnabitable and non-inhabitable....

Yes, the modder needs to select a subset collection of those object IDs he wants to affect the new system buildings requirements bitmask and adapt the feature manually. This is not your problem in UE. Also my patch issues this warning:

Code expects vanilla planet, anomaly, star & atmosphere object/category IDs!

@ Tethys: Just look in saved games @ [systInfo+31h] for the IDs used by all habitable anomalies currently featured in GALM and post them here.

Plus all other star types in [systInfo+31h]. Same for all anomaly IDs in [sector.lst+0A].

I also reported before that there are more code locations to fix, when you want to configure system features and such. That is not supported by UE yet.

Yes, but its not that complicated, this will be addressed in future patches loading special effect codes via object IDs from [systInfo+31] and [sector.lst+0A].

[Flocke]

08 - None (no system requirement)
09 - Asteroid (random & Planet Killer)
0A - Asteroid Belt Dilithium (resource level 10)
0B - Dilithium
0C - Near Worm hole
...
18 - Methane Atmosphere
19 - None Atmosphere
1A - Oxygenrich Atmosphere
1B - Sulfuric Atmosphere
1C - Thinoxygen Atmosphere

Hmn, Vanilla environ.est lists following sequence:

00 - arctic
01 - barren
02 - desert
03 - gas giant
04 - jungle
05 - oceanic
06 - terran
07 - volcanic
08 - methane <--
09 - none <--
0A - oxygen rich
0B - sulfric
0C - thin oxygen

And when I edit a vanilla save game planet to type 8, it shows up as "Methan".

PlanetType8.jpg (52.5 KiB) Viewed 378 times

Type 9 = "AUS" (disabled/none)
Type A+ = "Other"

Given in environ.est "methane" is listed prior to "none" and given there is an actual textual planet type display, I assume that 'methane' actually was meant to be a planet type, rather than an atmosphere type. Therefore in UE save game editing I'll add methan planet type 8.

The "AUS" (disabled/none) entry in environ.est on the other hand might be nothing more than a separator to differentiate atmosphere types in environ.est. At least I see no other data value to distinguish planet types and atmospheres here. And UE yet uses frequency 0 to determine the type, which clearly is no good choise for disabled planet types.

Still vanilla edifice.bst building requirements indeed use system requirement type 8 = "AUS" (disabled/none) for all buildings that have no requirement. A strange mismatch.

edit: clarified system requirements mismatch

[Spocks-cuddly-tribble]

Vanilla environ.est lists following sequence:

I can't check this right now, might be a typo or mistake. It's the same sub-sorting based on default values read from the systInfo planet array (+0x48 planet type +0x49 Atmosphere), my new IDs just determine position in the extended bitmask via bit shift.
The new sequence of the source categories maintains the vanilla defaults of system requirements in edifice.bst+71h (Arctic 00 to X-Ray Pulsar 0E).

And when I edit a vanilla save game planet to type 8, it shows up as "Methan".
PlanetType8.jpg
Type 9 = "AUS" (disabled/none)
Type A+ = "Other"

Given in environ.est "methane" is listed prior to "none" and given there is an actual textual planet type display, I assume that 'methane' actually was meant to be a planet type, rather than an atmosphere type. Therefore in UE save game editing I'll add methan planet type 8.

Unfinished vanilla glitch code where they confused different planet traits. Just ignore or use for exploit patches extending the range of panet types (features like random events and monster attacks need extra work). viewtopic.php?p=61192#p61192

The "AUS" (disabled/none) entry in environ.est on the other hand might be nothing more than a separator to differentiate atmosphere types in environ.est. At least I see no other data value to distinguish planet types and atmospheres here. And UE yet uses frequency 0 to determine the type, which clearly is no good choise for disabled planet types.

Still vanilla edifice.bst building requirements indeed use system requirement type 8 = "AUS" (disabled/none) for all buildings that have no requirement. A strange mismatch.

My new edifice.bst+71h = 19h (None Atmosphere) checks for [planet arry+49h] = 9 (cf. loc_4AFF4C).

Vanilla 8 just means skip bitmask go OK.

---

Problem is my new extended bitmask doesn't work for changed/extended feature ranges (e.g. GALM by Tethys), so he needs new custom bitmask code and lable pointer after each object ID edit. And I see now way UE could support this.

[Flocke]

And when I edit a vanilla save game planet to type 8, it shows up as "Methan".
PlanetType8.jpg
Type 9 = "AUS" (disabled/none)
Type A+ = "Other"

Given in environ.est "methane" is listed prior to "none" and given there is an actual textual planet type display, I assume that 'methane' actually was meant to be a planet type, rather than an atmosphere type. Therefore in UE save game editing I'll add methan planet type 8.

Unfinished vanilla glitch code where they confused different planet traits. Just ignore or use for exploit patches extending the range of panet types (features like random events and monster attacks need extra work). viewtopic.php?p=61192#p61192

Having checked planet.pst atmosphere types, it looks like a coding glitch. However, the label is read from lexicon.dic 641 as I have just confirmed by editing the label. Searching trek.exe for the hex value "81 02" I found sub_4FBAD8 which explictly sets labels for the planet types.

type8planetType.jpg (203 KiB) Viewed 331 times

You hardly can call this a coding glitch. It might be miscommunication, yes, it might also be they reconsidered on the planet type, but the label is used nowhere else but was explictly choosen for planet type 8.

That given I think both is valid. Planet and atmosphere type. While only the atmosphere type finally was picked. Likely for a while they were undecided whether 'methane' should become a planet type or an atmosphere. Still methane planets have some remains at least for the labels.

Furthermore, choosing methane atmosphere for all the gas giants and only them doesn't make much sense either. Usually I'd rather expect hydrogen atmospheres for the gas giants.

Problem is my new extended bitmask doesn't work for changed/extended feature ranges (e.g. GALM by Tethys), so he needs new custom bitmask code and lable pointer after each object ID edit. And I see now way UE could support this.

There of course are ways, but I doubt it's worth the effort to support custom coding of it. At some later time by chance.

[Spocks-cuddly-tribble]

the label is read from lexicon.dic 641 as I have just confirmed by editing the label. Searching trek.exe for the hex value "81 02" I found sub_4FBAD8 which explictly sets labels for the planet types.

You hardly can call this a coding glitch. It might be miscommunication, yes, it might also be they reconsidered on the planet type, but the label is used nowhere else but was explictly choosen for planet type 8.

That given I think both is valid. Planet and atmosphere type. While only the atmosphere type finally was picked. Likely for a while they were undecided whether 'methane' should become a planet type or an atmosphere.

Yes, glitch in the sense of unfinished/dysfunctianal code. I guess the implementation of the concepts were unclear and changed during game development. Then they just hotfixed planet slot ID 8 as skip code.

You can see similar confusion with systInfo/stellInfo object IDs, and some codes indicate sectors were supposed to allow both features at the same time.

Files with nonesensical ongoing/shared object IDs:

- systInfo star type vs stellInfo anomaly type (+ unused star types in lexicon dic)
- planet types / atmosphere type -> methane both ID 8 (this ID overlapping is unusual) + skip ID 8

choosing methane atmosphere for all the gas giants and only them doesn't make much sense either. Usually I'd rather expect hydrogen atmospheres for the gas giants.

Could also be a sorting mistake for none/methane, since vanilla gas giants support no pop, growth and TForm features?

I doubt it's worth the effort to support custom coding of it.

Same here, I meant it's not reasonable atm.

[Flocke]

choosing methane atmosphere for all the gas giants and only them doesn't make much sense either. Usually I'd rather expect hydrogen atmospheres for the gas giants.

Could also be a sorting mistake for none/methane, since vanilla gas giants support no pop, growth and TForm features?

Unlikely. environ-est 00-07 perfectly match the planet types, including gas giants. Even the 'none' entry 09 matches the planet type switch list above.

It is rather a case where in later development they decided to reuse the methane planet type entry as a none-visible atmosphere type but kept old sorting.

Stupid however it becomes with the "none" entry used in the switch list. At first thought it possibly got renamed, but the 'none' label is a shared label used in many locations. And it can't be a default value either, since there already is a hardcoded default for the 'other' label.
'None' obviously was picked from the atmosphere types. The coder must have been drunken!

Edit: Oh well, possibly it got messed with the idea, that indeed there could be empty planet placeholders to simulate different orbits.

Whatever, the vanilla implementation now is 08 = methane planet type and 10 = none in the sense of asteroids or space anomalies and since you can edit save game planet types I'll carry it over to UE in that sorting.

Edit2: I checked unknown values of environ.est again. There's an unknown_1 4-byte array for each of the entries, that must be used by some calculation for habability or something. The interesting part is, the 4th value for all the planet types 0 to 7 is set to 87, while the atmospheres specify:
oxygen rich: 50
thin oxygen: 5
methane: -15
sulfric: -25
none: -50

Therefore the environ.est entry clearly was meant to be atmospheric.

environ_87.jpg (38.21 KiB) Viewed 264 times