Changing any package mechanism's enum to hacking doesn't show the screen

[Const1702]

I tried adding a Wall_Control_Package in the ENG_TowPlatform level, but noticed that when changing the "FrontMechanism" enum to 5 the screen is blank and it is not hackable.

This doesn't happen for existing control packages. I also tried using the "Material" string parameter and manually putting "screenBlueTextScroll->screen_anim_int_12" like I saw in one existing hackable "Wall_Control_Package" in DLC\ChallengeMap16, but it didn't work. Here is a screenshot of the parameters for the "Wall_Control_Package" (I also tried this without the "Material" parameter:

Same problem occurs with the mechanisms for the newly added doors:

I used the "Select level" from the Debug Checkpoints mod to apply the changes properly, but it didn't fix it.

OpenCAGE version: 0.9.3.5
This issue was posted by an accident early and was closed temporarily and then re-opened after it was finished.

[MattFiler]

Interesting problem! This definitely seems like a material mapping issue - I imagine the screens are actually set via the MVR file and not read from the Commands. What I would try is editing the actual mechanism composite where it references the model for the screen and setting the material in the resources editor there to screen_anim_int_12. Might work?

[Const1702]

Seemed to fix the screen problem:

but the hacking tool problem still occurs:

Both the door and the wall_control_package have a hacking_difficulty assigned.

[MattFiler]

Huh, that's super weird - I'll have a look into that this weekend!

If you figure anything else out sooner, drop it in this thread :)

[Const1702]

Thought it would be a good idea to share what exactly I did to fix the screen only (not the hacking tool, it is still black):

• Added a "Material" string parameter directly on the "Wall_Control_Package" composite and set it to "screenBlueTextScroll->screen_anim_int_12"
• Went to "ARCHETYPES\MISC_SUBARCHETYPES\WALL_CONTROL_PACKAGE" and changed the default state of the string paramater "Material" there to "screenBlueTextScroll->screen_anim_int_12" (I don't think this is required, but just in case)
• Went to "ARCHETYPES\MISC_SUBARCHETYPES\DOOR_MECHANISM" and changed the default state of the string paramater "Material" there again to "screenBlueTextScroll->screen_anim_int_12" (I don't think this is required, but just in case)
• Went to "ARCHETYPES\GAMEPLAY\KEYPADHACKING", clicked on the entity "[OVERRIDE] KeyPad_New_1 -> VDU_20_25cm"
• and set its "material" string parameter to "screenBlueTextScroll->screen_anim_int_12"
• This might be the most important: Like you told me I went to "AYZ\CONTROLS\KEYPAD_NEW", selected entity "VDU_20_25cm (ModelReference)" -> Clicked on "Edit Resource References" from the "resource" parameter -> This is what opened:
  
  -> As shown on the screenshot, the selected entity in the material list was changed from "screenBlueTextScroll->InactiveScreen" (its initial selection by the game devs) to "screenBlueTextScroll->screen_anim_int_12"

I think the hacking tool is controlled with the "HackingGame" function entity. I have only found an entity like this in "ARCHETYPES\GAMEPLAY\KEYPADHACKING":

The problem is that I can't just click "Go To", because it is a function entity and not a composite to be inspectable. The "Resources" button is available for "HackingGame", but it opens an empty window:

[MattFiler]

Thanks for the extra info!

RE the resources screen - you can add new resources down the bottom left if they are missing on entities, but only certain entities actually utilise them. For example, ModelReference entities will utilise RENDERABLE_INSTANCE through a resources parameter. I'm working on making it more explicit where resources should and shouldn't be used, and hope to auto populate them eventually (some already are as of the latest update - but there's more to go!).

[Const1702]

Managed to fix the hacking tool!

• Went to REQUIRED_ASSETS\WEAPONS\HACKING_TOOL\BASE
• Selected Screen (ModelReference)
• Clicked "Edit resource references" from "resource" parameter
• Changed "screenBlueTextScroll->InactiveScreen" (the default option set by the devs for some reason) to "screenBlueTextScroll->screen_anim_int_11" from the material editor

I'm still wondering why are the default options for the hacking related screens are set to "...InactiveScreen". The inactive screen seems to become active with existing composites (initially in the game), but not with newly added ones.

Unfortunately fixing the screens only applies to the level you are on. If you want to do this everywhere you have to go to every level and repeat the steps.

[MattFiler]

Nice! When overrides are working you'll be able to set this per instance of the hacking composite too.

I imagine this is an MVR related thing: the MVR entry probably applies the correct instance specific material for all the ones already in the level. Similar to the issue with doors and how collisions are applied currently. You'll see the same issue with the posters in-game, the default poster composite is a blank poster, and then the actual materials are applied via the MVR instances.

I'll leave this thread open to remind myself about the wider problem, linked to #95.

[Const1702]

I have a theory that the "material" string parameter should have more priority than the "resource" resource parameter. If you go to AYZ\CONTROLS\KEYPAD_NEW VDU_20_25cm (ModelReference) click "References" you will see that it is overrides with a different string parameter, not a resource one. That means the developers created logic for the string parameter to be more powerful than resource and light up the screen. The resource parameter is just there for the screen model to exist and as a fallback material (InactiveScreen most of the times) in case there is no string parameter. AYZ\CONTROLS\KEYPAD_NEW is instanced multiple times in other composites (ex: ARCHETYPES\GAMEPLAY\KEYPADKEYCARD, ARCHETYPES\GAMEPLAY\KEYPADHACKING) and you'll see overrides changing the string only. So judging by the logic everything should be fine, but in-game you can run into this screen problem. I think if somehow priorities are inverted so "material" is more powerful than "resource" with new entities this problem would not occur at all (hacking tool, keypads, rewire...).

[MattFiler]

This is a good spot, I've seen this sort of parameterised material application before. It's possible that the value is an override, which is applied at the level's compile time and exported out to MVR (and not read from commands). There are some other things like this too, like the SoundNetwork nodes which I think generate to a file and are not read from Commands at runtime.