(39) 's Extra Blueprint Nodes for You as a Plugin, No C++ Required!

[Rama]

The Challenge of Supporting Non-Release Engine Versions

@RhythmScript;476813

EDIT: In fact, flexed my tiny C++ muscles to comment out those lines (IImagewrapper.h and the other line right below it) and recompile the plugin, seems to work fine now.

Now, I have absolutely no idea what those lines DID, or whether I’ll spectacularly break anything by using the plugin in state, so I’m not really going to mess with it, but it’s absolutely those two lines causing the.

@Dannington;476989

You need to change the include paths. Change ‘Developer’ to ‘Runtime’ at the start of both IImageWrap includes. (I think it’s runtime, I’m not in front of my PC now.

@RhythmScript;480360

Busted again as of 4.11 preview 6 (first I’ve ever seen the plugin report a “wrong engine version” file on a small version number increase, ever)

Apparently Epic decided to move or delete something to do with the Vorbis encoder and now Victory Plugin can’t see it and it breaks everything spectacularly.

IDK how to code and I’m out of my depth on . Commenting out the offending lines in the Victory source doesn’t do anything because of subsequent dependencies and I have no idea how to properly fix it.

EDIT: hang on, I sorta got it… for those who aren’t using Vorbis decode, anyway:

int32 UVictoryBPFunctionLibrary::fillSoundWaveInfo(class USoundWave* sw, TArray<uint8>* rawFile)
{
	FSoundQualityInfo info;
//	FVorbisAudioInfo vorbis_obj = FVorbisAudioInfo();
//	if (!vorbis_obj.ReadCompressedInfo(rawFile->GetData(), rawFile->Num(), &info))
//	{
		//Debug("Can't load header");
		return 1;
	}

//	if (!sw) return 1;
//	sw->SoundGroup = ESoundGroup::SOUNDGROUP_Default;
//	sw->NumChannels = info.NumChannels;
//	sw->Duration = info.Duration;
//	sw->RawPCMDataSize = info.SampleDataSize;
//	sw->SampleRate = info.SampleRate;
//
//	return 0;
//}

Just force the plugin to always return that the file in question isn’t an ogg vorbis. Prevents breakage down the line that occurs if you try to skip the loading check entirely.

Obviously for people who need functionality I didn’t fix it but it does at least let me open my game again.

@Nup;479834

I’m having similar issues, can’t get any unreal versions or projects to work with the plugin at right now.

So it would seem that the challenge of supporting a non-release engine version has emerged, incremental new testing builds from Epic are not binary compatible and involve significant code changes!

What I uploaded compiled great for me in 4.11.4, but 4.11.5 and 4.11.6 have since become binary incompatible and are the source of the errors you are reporting.

I am upgrading to 4.11.6 now so I can address these issues.
**
I guess in general you should be prepared for stuff to break between increments of an unofficial engine test build like 4.11 currently is**, and let me know when occurs.

I primarly work in released engine versions but I am planning to have Victory Plugin go with the pre-release test engine builds, but frequent binary incompatibility. appears to be one side-effect of that choice.

I really dont think that once marketplace plugins are live that Epic will be able to convince developers to keep pace with every single incremental test build for unreleased engine versions, due to high probability of code changes causing binary incompatibilities.

You are going to be feeling spoiled at me supporting Victory Plugin for each test build increment

Please note I can only ever support the most recent incremental pre-release Engine build, seeing as each version could and seems to tend to be binary incompatible.

I hope you are seeing the complexity of the choice I was compelled to make by popular demand, supporting a test engine build is a lot of work! Donations are appreciated.

PS: Btw, IImageWrapper going from Developer to Runtime is a great thing! And thanks for reporting that Dannington, and confirmations from John and RhythmScript!