ThunderPipe

[brave root]

for like the whole PropertyGroup

[strong coyote]

OHH

I understand now

[brave root]

ye

[strong coyote]

Would it be smart to have the doc for them there in comments?

[brave root]

I actually love that MSBuild has great logs when adding -fileLogger

[brave root]

eh, it's hard to find them, there is no Ctrl+Click functionality for MSBuild afaik

and probably no xmldocs type of thing

but I could be wrong

[strong coyote]

There is

But GOOD LUCK

[brave root]

in that case it could be nice

[brave root]

oh?

[strong coyote]

.xsd

Have fun

[brave root]

is it terrible? lol

[strong coyote]

Yes

[brave root]

forget it then lmao

[strong coyote]

Making it is hard, using it is hard

Fuck msbuild

[brave root]

real

[strong coyote]

Either make a PR or something. I will do it when I come home

[brave root]

this is basically the only thing I like about MSBuild. It was super easy to debug the problem of why they get set, it just literally says it in the logs

/home/suni/.nuget/packages/thunderpipe.sdk/0.1.2/Sdk/Sdk.props(5,3): message : Property reassignment: $(ThunderstoreHost)="" (previous value: "https://thunderstore.dev/") at /home/suni/.nuget/packages/thunderpipe.sdk/0.1.2/Sdk/Sdk.props (5,3)

I actually love that

[strong coyote]

Good thing the sdk works

[brave root]

ye I'll make a PR

[strong coyote]

Except that bug

[brave root]

ye

[strong coyote]

Not too hard to use?

[brave root]

it's quite easy to use, but I'm very biased because I also tweaked the usage stuff so I also know exactly how the interface works for the MSBuild integration

[strong coyote]

Shushh

[brave root]

here's the PR https://github.com/WarperSan/ThunderPipe/pull/65

[strong coyote]

Biggest PR

[brave root]

real

[strong coyote]

Thought about it but I advice you to use a specific version of the sdk

It would be unwise to use "the latest version"

[brave root]

oh yeah that's a communication mistake, I ofc would not use a floating version for this, but would use the latest version which is pinned

so like the version added initially is not already outdated

[strong coyote]

I forgot to tell, but v0.1.3 of the SDK is out

[brave root]

oh ye I did notice

[brave root]

I looked a bit into MSBuild targets, and I believe that "PostBuildEvent" would be more appropriate than "Build" for the pre-existing targets for ThunderPipe.Sdk

• https://stackoverflow.com/a/6128761
• https://learn.microsoft.com/en-us/cpp/build/how-to-use-build-events-in-msbuild-projects?view=msvc-170

I'll probably open a PR soon-ish about that

I think it's still fine to do breaking changes like this as it's very new and at least I haven't yet released a template which makes use of ThunderPipe. The version number should just signify the significance of the change (at least if following SemVer)

[strong coyote]

I have a hard time understanding the last part about the version number

[brave root]

just following semver rules https://semver.org/

but really, it's an extremely small change and will only affect if someone has some msbuild setup with targets that depend on very specific ordering

so probably could get away with not even marking it as a breaking change in the version number

[brave root]

I also wonder if it could be made user configurable. I'll look into that

like using AfterTargets="@(ThunderPipePackAfterBuildTargets)"

[brave root]

if this works, I guess we could just have a new property which is RunThunderPipePack (and RunThunderPipePublish ofc) and those can be configured when the uh when it should run

[strong coyote]

Originally, I was planning to go from 0.1.3 to 0.1.4. However, i thought you wanted me to go to 0.2.0

[brave root]

yeah I'd probably go to 0.2.0 but actually since the major version is still 0, you can actually do anything you want

so just go with 0.1.4

I misread the version as starting with 1 originally

[strong coyote]

Its technically not yet released

[brave root]

yep

[strong coyote]

Actually, when do you plan on updating your template?

I might release a v1.0.0 (even without any change) before it and for it

[brave root]

uh, not sure, but there's one change I'm planning to do and after that I'll probably release PEAKModding.BepInExTemplate v2.0.0

so could be today or tomorrow, or later

[strong coyote]

God damn

[brave root]

but ofc I also want this target change done because I realized it might be better for configuring more targets, like for example using NetcodePatcher

[strong coyote]

PostBuildEvent?

[brave root]

and it doesn't really matter if it takes a day or two

[strong coyote]

Or the AfterTargets

[brave root]

AfterTargets="PostBuildEvent"

[strong coyote]

This or PostBuildEvent

I much prefer the latter

[brave root]

not sure rn

[strong coyote]

I understand you want to make it as customizable as possible

[brave root]

so PostBuildEvent?

[strong coyote]

But I feel adding a property just for that is kinda pointless

[brave root]

I think it can make sense, like if we set a default value there which is PostBuildEvent

[strong coyote]

PostBuildEvent can be done. I would wait for this

[brave root]

do you care when I should open the PR? Because I could implement that change right now

[strong coyote]

Im not sure to understand your question

Wdym if I care?

[brave root]

like if you would prefer I open a PR now or later today?

[strong coyote]

Doesn't matter

Up to you

[brave root]

oke I'll do it a bit later 👍

[brave root]

actually, it seems that after Build is later than after PostBuildEvent. The later the target runs, the more likely the timing for it works for the use case of ThunderPipe.Sdk's targets, I believe. So actually, it's fine as is, and probably better as is