fre-sch / starfield-toolbox

Various scripts for xedit and Blender, and documentation on how to mod specific things in Starfield
GNU General Public License v3.0
3 stars 1 forks source link

create new part.pas: WEAP inside GBFM is skipped (fix attached) #1

Closed remosito closed 8 months ago

remosito commented 9 months ago

Howdie,

LuxZg sent me link to your wonderful script. It works magnificiently well and will save me so many hours of work. Thank you!

I am making new weapons and the script didn't copy the WEAP linked form in GBFM. So I had a quick look at the script and extended it:

aab Create new part.txt

(had to change .pas to .txt as github does not allow attachment of .pas files)

I would definitely triple check my stuff...haven't touched pascal in a quarter century. And never done any xEdit scripting

cheers and thanks again for your work. Sooooo helpful

PS Apologies for not going fork/pull (or was it push?) request or however it works to give you the changes inside github. But figured as it's just a few lines inside one file. Attaching my version would be usable enough...

fre-sch commented 9 months ago

Thank you for contributing.

Those changes were easy enough to merge, I only removed some unused variables. Those won't cause any issues, just a bit cleaner to remove them.

Out of curiosity, can you give me an example FormID for GBFM that links a WEAP?

remosito commented 9 months ago

you are most welcome :-)

how very typical of me to not clean up the code properly ;-)

SMA_Weapon_Particle_Vanguard_Obliterator_Auto_UC01 [GBFM:00004244]

is one example. pretty much all the ship weapons are like that.

For my mod I need to make copies of a few dozen ship weapons. Your script is kinda half-independently running on each selected COBJ seperately. The UI for options and destination esm is popping up for every selected COBJ again. Albeit it remembers the inputs chosen for the previous run. So it's just a few mouse-clicks.

Still would be neat if it asked for options only just once. Then runs with the same options on all selected COBJ.

Another script I found "modifyString.pas" does that by doing the options UI call from within Initialize..instead of Process functions (I assume that are the default API ones called by xEdit?).

If you think this would be another useful addition to your script I could give it a shot!

attached the other script.

aaa_modifyStrings.txt

remosito commented 9 months ago

Howdie again,

couldn't resist... :-/

Went a slightly different way than using initialize as call location for the UIs as that would preclude multi-select different objects. and then running each with different options. As is possible right now.

Instead added a new checkbox "use same options for all selected objects" and if it is checked. the options UI calls are skipped with an if statement in all successive passes of Process function...

aac Create new part.txt

just realized that I forgot to use your improved version form commit ac93685 :-/

so those unused variables you cleaned up are still there...apologies

cheers

fre-sch commented 9 months ago

SMA_Weapon_Particle_Vanguard_Obliterator_Auto_UC01 [GBFM:00004244] is one example. pretty much all the ship weapons are like that. For my mod I need to make copies of a few dozen ship weapons.

I see, yeah, I've never messed with the weapons at all, but I see how that's useful then.

About the way the options are initialized, I have considered changing this multiple times. However, due to the renaming functionality, and how some part EDIDs contain orientation (of flips), I personally use the script one COBJ at a time to change the EDIDs each time.

For example I often want to duplicate something like SMOD_Struct_Foo_AftBtm as SMOD_Struct_Foo_PortBtm, and the chain of records (GBFM, PKIN, CELL, MSTT) often all contain AftBtm and I want each to update.

Instead added a new checkbox "use same options for all selected objects" and if it is checked. the options UI calls are skipped with an if statement in all successive passes of Process function...

Thank you again. I'll have a look later, that sounds like a good way to have both workflows supported.

remosito commented 9 months ago

Howdie again ;-)

for the longest time couldn't decide if I wanted my own PKIN/CELL copies or not. My mod covers weapons but only changes dmg/power/requirement stats. Not the visuals. So don't really need my own PKIN/CELLs. As your script copies those as new I went with that. until I realized that it makes the preview in weapon list get lost.

So I went back and decided I dont want my own PKIN/CELL as the visual preview in the list is quite handy.

As your script doesn't do that yet. Extended it with a new option "Copy PKINs linked by GBFM". If it is deselected it will not copy PKIN. And as CELLs seem to only be referenced by PKINs. Those neither.

Weapon stats, names, requirements are spread over COBJ,GBFM,WEAP. So anybody who wants to change only these wouldn't need PKIN,CELL copy either.

Not sure how generally useful to as many ppl as possible you want your script to be...

aad Create new part.txt

no pressure to add my changes to your version. I have my own that does what I need. :-)

cheers

fre-sch commented 9 months ago

Just to give context to what I intended to achieve with this script, the main point of the script was to create copies of ship parts for making flips or just making any changes in CELLs fast and reliably. It's meant as starting point for the next step: using the Blender-Export and Blender-Import-Update script to make CELL changes in Blender in a more visual manner. So the whole point was to copy the in-game visuals. But I also don't think your added options conflict with that idea.

until I realized that it makes the preview in weapon list get lost. I dont want my own PKIN/CELL as the visual preview in the list is quite handy.

For some background info on these menu icons: the game uses ESM form ids to find a texture file as menu icon, those aren't live previews. For most ship parts it's the GBFM, for outpost parts I think it was the PKIN. Unfortunately, the way it's currently implemented in the game, it requires problematic hacks/workarounds for mods wanting to include their own icons.

On the topic of contributing: I'm glad you want to contribute and I appreciate that. When it was just a small change and a few lines, I didn't mind you providing the whole file, I can just copy/paste this over my version of the file and use Git to check for changes. I could continue doing that, but at this point a Pull-Request on your side would be quite helpful as it highlights those changes right here on Github. And I don't have to reset my own project to the last version in the main branch just to get a clean view of the changes you're wanting to contribute.

So I'm glad you find my script useful, even just as basis for your own scripts, but I'd really appreciate it if you could take the time and use a Github fork and pull-request. Github and Github Desktop have come quite a ways, and they're both pretty helpful in doing this, they'll show you hints on what you need to do for a fork/pull-request. You might even find this useful yourself, as a more organized backup of your own changes.

remosito commented 9 months ago

Howdie,

yeah, tried to implement my changes so they would only add functinality without kneecapping what it already does.

gave the fork/pull-request a shot. Did it all within github:

hope I did that right. Was much easier than I thought. So it is either that easy. Or I missed sth ;-)

For ship weapons the menu icons seem to be either based on PKIN or CELL. As if I make my own copies of them. No menu icon. If I use existing vanilla ones. There is a menu icon.

cheers

fre-sch commented 9 months ago

Thank you, you did it correctly, and I've merged it.

remosito commented 8 months ago

excellent :-)

thank you again for all your work.

closing this issue then :-)