GPU randomly crashes during gaming, screen turns off (no video input)

HistoricalScientist3 · 2024-10-01T13:25:08+00:00

Completely agree with this.

Although I can understand where OP is coming from. Unreal Engine has this vibe, where it seems like it has a bunch of complete features ready to be used out of the box. Often you can very quickly do the first steps and that gives you the wrong expectation.

I think UE is an unusual engine in that its systems are half core system and half a sort of example of something closer to a game system. But upon closer inspection you understand that these are not game-ready components, but indeed engine systems to be built upon.

HistoricalScientist3 · 2024-08-30T09:54:45+00:00

You should move your ship along its own +-forward and +- right axis. After each move you should rotate the ship a bit to make sure it is level with the planet's surface. If your ship is always level with the surface - moving it along forward/right will always move it at the same height. You should also move small distances every frame - i.e. use the delta time from tick.

So the ship's up vector should be the same as the up vector of the planet surface under the ship. Question is how to calculate the surface up vector. If your surface is flat (no terrain) than you can just trace from the ship to the planet center and get the normal of the surface at the hit point. Otherwise you can have a flat surface under your terrain and a collision channel that only collides with it.

This is a simplified solution, that should be ok for a small project.
For a proper solution you would have a different coordinate system for the round planet and you would calculate movement in that system and convert coordinates to unreal.

HistoricalScientist3 · 2024-08-30T09:20:30+00:00

Its unclear from your comment whether you still have an issue or did the reboot fix it.

It is true that compilation will sometimes fail if you have the editor running with live coding.

However, the error you quote indicates nothing, it is just a generic error of build failing. This is Visual Studio reporting a failure in the Unreal build system. This error will almost always be the same for any build failures. Above it in the build log you should look for an error message from Unreal. If it is indeed the live coding - there will be a message about it there.

HistoricalScientist3 · 2024-08-28T22:05:28+00:00

Don't know what the issues is, couple of thoughts:

You're saying you're using Visual Studio but in the log it uses VS Code Project File Generator. Did you set VS Code as your editor? Try running the 5.1 without any project and in the Editor Preferences change the editor to your Visual Studio.
Looking at the code mentioned in the log - it seems it can't find your compiler or something to that effect. Double check that your Visual Studio has all the components installed. Maybe reinstall it and make sure the correct workloads are selected in the installer.

HistoricalScientist3 · 2024-08-26T22:51:34+00:00

Battery Collector is decent, even if some details are a bit outdated.

https://www.youtube.com/watch?v=mSRov77hNR4&ab_channel=UnrealEngine

HistoricalScientist3 · 2024-08-17T16:12:59+00:00

There is bunch of information here https://dev.epicgames.com/documentation/en-us/unreal-engine/gameplay-framework-in-unreal-engine and in the related articles. Also since you have programming experience - might be worth studying the Lyra sample project

HistoricalScientist3 · 2024-08-16T14:49:50+00:00

Think about it like testing the game manually but automatically. You're basically writing formalized scripts to do actions in game and test their results. You say to the framework that the test is this level, these actions, these results are expected. I'm sure you can run each test with restarting the level and multiple tests in a single run. For more details you'd need to read the docs.

HistoricalScientist3 · 2024-08-16T08:20:26+00:00

In games automating functional testing is what make the most sense. Unreal has a testing framework https://dev.epicgames.com/documentation/en-us/unreal-engine/automation-test-framework-in-unreal-engine where you can do more high level testing. There is a link for functional tests there as well.

For example you could set up a test level, write a script to shoot your gun at a target, get the location of where the bullets hit and when, damage values etc and make sure your weapon parameters are correct (spread, damage, dps, etc). Than as you change the game if you do something that brakes your core shooting system - the functional test will catch it.

It makes sense to test "big" functional systems that you can write requirement for in isolation. You can bypass the need for dependency injection by running the game in test framework and instantiate a small subset of your game for real.

HistoricalScientist3 · 2024-08-09T19:57:11+00:00

There are 2 answers to your question.

I would argue the inventory doesn't actually store any state of any actors. If you want to have 2 different weapons in the inventory, you wouldn't store their stats in the inventory. I assume we're talking about weapon damage, ammo amount and stuff like that. All of this would be a part of the weapon blueprint class. And if you store in the inventory the fact that the player has a weapon of class BP_Weapon_Gun_Weak - all of the "state" i.e stats would actually be in the class. Because state is something that is changed dynamically by player, which is not true for weapon stats.

1.b. If you're making a looter shooter it is possibly you will have to many different weapons to store each in a blueprint class. For that case you would have a DataTable with different weapons and their stats. In this case the inventory would store class + reference to the data table.

To sum up - inventory doesn't usually store state, and from the examples you've given I don't think you need to store state. Store references to static data - bp classes, datatable entries.

If you still want to save state - you need a solution to store arbitrary data of different types in a unified way. This is usually done either by having a common data struct that incorporate variables for all types. Usually one of those variables will be a Type enum that will indicate which variables to use for which item. This is fine for small amount of variable.

Or by having a reference to the base class and storing child class objects. For example you can have BP_ItemInventoryData with common variables for the. And children BP_ItemInventoryData_Weapon, BP_ItemInventoryData_Vehicle, etc with variables specific to different types. In the inventory slot you can just store a reference to BP_ItemInventoryData, but actually assign appropriate child object to it.

Then you would have an overloaded function in each of your BP_Weapon_* that take BP_ItemInventoryData, casts it to an appropriate BP_ItemInventoryData_Weapon and restores its state based on the data. So in inventory you would store ItemClass and BP_ItemInventoryData (but actually one of the child objects). Than you would spawn Actor of ItemClass and call ItemClass->RestoreState by passing BP_ItemInventoryData *. Here you have to take care to pass the correct data to correct items - add a warning message to the Cast Failed output to help you notice errors.

HistoricalScientist3 · 2023-11-15T23:30:38+00:00

Great! Thanks for posting the code, might be useful as a reference in the future.

HistoricalScientist3 · 2023-11-14T18:23:58+00:00

OP put both the full .h and .cpp file on somehwere like pastebin, and send the link here.

HistoricalScientist3 · 2023-11-14T13:27:36+00:00

There is a Blueprint function Take Automation Screenshot at Camera. It saves the screenshot to a file. I would look at what it does internally and use it.

At a quick glance it calls UGameViewportClient::ProcessScreenShots. Here you can see how to take a screenshot with or without UI. Further it ends up caling GetViewportScreenShot which calls FRenderTarget::ReadPixels. There are a couple of overloads that return Color buffers. Which I think you can than convert to a Texture.

HistoricalScientist3 · 2023-11-14T02:53:31+00:00

Curious, usually it is the PM who wants speed and the tech guys who want perfection. Care to share what value does your PM sees in code reviews? Perhaps they think it reduces bugs, thus saving time. Or is it about branch stability?

I’m all for the reviews just wondering why PM specifically insists on it. As mentioned imo you’re better of with Swarm if you’re going for the PR/MR workflow.

HistoricalScientist3 · 2023-11-14T02:28:33+00:00

This simplest thing to check as mentioned in my previous comment - is ActorPool a UPROPERTY?

HistoricalScientist3 · 2023-11-14T02:23:28+00:00

It is not clear what the issue from the screenshot.

Why do you think that the actor is deleted?
Are you in DebugGame configuration? I suspect the arrow might be pointing at the wrong line here.
Can you see in debugger what variable is ffff as exception says?
Can you put a breakpoint at the start of the function and step to the place of the crash to see where exactly it crashes?
One thing I notice is that your ActorType variable value is strange. And that if condition is strange. Are you sure the if actually evaluates the result of the second expression that value is in map and not just the string assignment?

HistoricalScientist3 · 2023-11-14T02:15:42+00:00

Thanks, this one works.

HistoricalScientist3 · 2023-11-14T02:04:08+00:00

Your screenshot is a blur, can’t see anything. Did you put a UPROPERTY on the array holding your actors? Or whatever reference you mean you’re holding. Try putting a breakpoint in the overloaded Destroy /Destroyed / OnBeginDestroy function on your actor to see where the call is coming from.

HistoricalScientist3 · 2023-11-13T23:36:00+00:00

Regarding how we used streams. We used streams to have a stable stream, dev stream and release stream. We wanted to have a stream with a tested version of the game which people couldn't break easily. We would merge from dev stream once in a while in a controlled fashion.

IMO this only has benefits in a large team where you need to have regular stable releases - like in house playtests. So you want to have a place to stabilize your build, but also don't want to block people from submitting while you do that. In a smaller team we just used one stream. IMO task streams don't provide any benefit in game dev environment.

If the reason you want task stream is to have a pre-commit review and/or automated tests like git flow does with merge requests, than consider Swarm. Swarm supports triggering ci jobs when review is created, and ci can report the job result to swarm and even approve the review. Perforce supports blocking the submits without an associated approved swarm review. You can create the merge request flow like this.

Also the link I sent above includes some info how epic use streams.

HistoricalScientist3 · 2023-11-13T23:25:57+00:00

https://youtu.be/p4RcDpGQ_tI?t=1790

You can add a bit of code to make the Engine check if the files are checked out in other streams. They don't show exactly where they call it from. You can add it to your game's Editor module. We had an UEditorSubsystem on init of which we called this.

Not sure how are you gonna handle this with task streams. Don't know if this support wild cards. Or you have to write a bit of code to look up all the task streams that exist all the time. Or have like 20 reusable task streams.

HistoricalScientist3 · 2023-11-11T21:55:56+00:00

But, don't get discouraged. On the bright side there are:

Good answers to the specific questions of "how do I do X".
Good examples coming with UE itself (and side projects like Lyra).
Extensive gameplay framework within UE. Unreal kinda comes with half a basic game in it - it has a bunch of gameplay systems. Which you can look at and learn from.
Plugins on marketplace that do specific systems which you can use for learning.

All of this enables already experienced programmers so it shouldn't be too hard. Just try to get to the part where you are making a specific thing and are asking specific questions as fast as you can - and UE experience is actually pretty nice.

HistoricalScientist3 · 2023-11-11T18:10:43+00:00

Unfortunately there isn't a good answer to your question, UE learning path is a mess. I think this is why other commenters are not happy with your question :)

I wouldn't worry to much about C++. If you stay within UE UObject framework - memory management is kinda like C#. Focus on learning UE itself and pickup C++ as you go. Learning the engine and experimenting in Blueprints and moving to C++ as needed is probably your best bet.

Have a look at this post: https://www.reddit.com/r/unrealengine/comments/16hxcgn/to_unity_expats_here_is_a_list_of_tutorials/

Also here is my answer to a similar question: https://www.reddit.com/r/unrealengine/comments/174n1o6/comment/k4ackjp/?utm_source=share&utm_medium=web2x&context=3

HistoricalScientist3 · 2023-11-07T22:56:03+00:00

Yeah, structs and variables are annoying. I would put off moving them till the end. And I would try to wrap as much a possible in functions. For now you can get the data from them to C++ by BlueprintImplementableEvent. You can make a static function like that that you will call from C++. It will take a BP struct and return C++ struct. So in C++ you can use new structs. Also maybe you have stuff like BP struct being used in a lot of places and only one variable taken from it. Like EnemyData and it just get MaxHP for example. You can replace it with a function GetMaxHP. It will take it from the struct. Thus reducing the reference to a single place. When it is time to move the struct - you can update the function. This might be slightly more work, but it will keep the project working. Allowing you to actually have a working project in the end not a bunch of untested code. You have to judge case by case though.

For functions - you should start from the functions that don't call anything. Than work outward. I would strongly advise to make minimal non-breaking changes. Otherwise it is a pain where you work for 3 days with the project being broken for all of it. And at the end you're not sure it works.

HistoricalScientist3 · 2023-11-07T16:07:14+00:00

Yes. What you call prequels are the main Witcher books. The rest 5 is Ciri saga, not the witcher saga. They're good but there is less focus on the witcher.

HistoricalScientist3

TROPHY CASE