New Resource & Building-Output Types Discussion
Moderator: thunderchero
- Spocks-cuddly-tribble
- Code Master
- Posts: 1961
- Joined: Sun Apr 27, 2008 2:00 am
Re: New Resource & Building-Output Types Discussion
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).
EDIT: Btw you could also change the resource type from asteroid to any other (e.g. alloy + dilithium in GALM).
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
- Tethys
- Past Administrator
- Posts: 2404
- Joined: Fri Jul 18, 2008 2:00 am
- Location: Your mom's bed ;)
- Contact:
Re: New Resource & Building-Output Types Discussion
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
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
- Code Master
- Posts: 1961
- Joined: Sun Apr 27, 2008 2:00 am
Re: New Resource & Building-Output Types Discussion
But you still need to fix patch code for your new habitable anomaly IDs, right?
This means extra (relocation) code here:
If you want to disable code for adjacent sector anomalies (since your new habitable anomalies now use the feature):
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 NOPFirst 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 typeELSE (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 pulsarBut 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
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
- Flocke
- BORG Trouble Maker
- Posts: 3258
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: New Resource & Building-Output Types Discussion
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....Spocks-cuddly-tribble wrote: ↑Fri Oct 06, 2023 4:27 pm 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 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 Master
- Posts: 1961
- Joined: Sun Apr 27, 2008 2:00 am
Re: New Resource & Building-Output Types Discussion
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].
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].
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
- Flocke
- BORG Trouble Maker
- Posts: 3258
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: Extending System Bonuses & Sun Icons - edifice.bst+71h requirements
Hmn, Vanilla environ.est lists following sequence:Spocks-cuddly-tribble wrote: ↑Thu Oct 27, 2022 10:38 pm08 - 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
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 oxygenAnd when I edit a vanilla save game planet to type 8, it shows up as "Methan". 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
- Code Master
- Posts: 1961
- Joined: Sun Apr 27, 2008 2:00 am
Re: Extending System Bonuses & Sun Icons - edifice.bst+71h requirements
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).
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#p61192Flocke wrote: ↑Wed Feb 28, 2024 5:23 pmAnd 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.
My new edifice.bst+71h = 19h (None Atmosphere) checks for [planet arry+49h] = 9 (cf. loc_4AFF4C).Flocke wrote: ↑Wed Feb 28, 2024 5:23 pmThe "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.
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.
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
- Flocke
- BORG Trouble Maker
- Posts: 3258
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: Extending System Bonuses & Sun Icons - edifice.bst+71h requirements
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. 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.Spocks-cuddly-tribble wrote: ↑Thu Feb 29, 2024 4:08 pmUnfinished 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#p61192Flocke wrote: ↑Wed Feb 28, 2024 5:23 pmAnd 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.
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.
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 wrote: ↑Thu Feb 29, 2024 4:08 pm 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.
- Spocks-cuddly-tribble
- Code Master
- Posts: 1961
- Joined: Sun Apr 27, 2008 2:00 am
Re: Extending System Bonuses & Sun Icons - edifice.bst+71h requirements
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.Flocke wrote: ↑Thu Feb 29, 2024 6:03 pmthe 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.
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
Could also be a sorting mistake for none/methane, since vanilla gas giants support no pop, growth and TForm features?
Same here, I meant it's not reasonable atm.
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
- Flocke
- BORG Trouble Maker
- Posts: 3258
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: Extending System Bonuses & Sun Icons - edifice.bst+71h requirements
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.Spocks-cuddly-tribble wrote: ↑Thu Feb 29, 2024 6:54 pmCould also be a sorting mistake for none/methane, since vanilla gas giants support no pop, growth and TForm features?
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.