Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Valve engine issues...fixed yet?
#1

I am at work and cant access the stream powered forums...but can access SoP forums. If they stream another update or publish a fix, can someone copy/paste the data here?
Reply
#2

Fix for what.
Reply
#3

After the hatless update, many users are getting a 'load library' engine failure at TF2 launch. Some are reporting it on Portal as well. Some have used a work around at disabling muti-core support. Since you cant get into the game you would have to add a command to the launch options i would assume.

Cant troubleshoot myself till 5 pm est (at work)
Reply
#4

Ibby, I see you on here...get some research going...lol
Reply
#5

I'd like to say that this is an issue but it doesn't bother me much, what pisses me off is moronic tf2 players saying "see what happens when you do a hatless tf2 update, needs more hats ws;'bj[qodns [;kndp " Just stupid shit like that, plus valve has always broken something when they do a big update like this. I read that updating through windows and installing the new net4 and c++ updates have fixed it for some people so you can try that.
Reply
#6

Will give it a go. I just reformatted and reinstalled xp sp3, so I am running somewhat barebone atm.

The first legit OS i buy in over 10 years (win 7 pro) and i lose the damn product key...lol.

So gonna try to add -matqueue_0? (cant recall ther exact spelling atm) to launch commands to kick to solo processor support.

Add c++ and net updates
Reply
#7

this will set it true singlecore.

Code:
mat_queue_mode                      "0"  // def. "-2", The queue/thread mode the material system should use(options/video/advanced/ "Multicore Rendering"):
                                         //  -2 = legacy default
                                         //  -1 = default
                                         //   0 = synchronous single thread
                                         //   1 = queued single thread
                                         //   2 = queued multithreaded
                                         //   This setting determines the threading mode the material system uses.
                                         //   Value of 2 uses multi-threaded mode. Many users report performance
                                         //   increases on multi-core systems when setting this variable to a value of 2.
host_thread_mode                    "0"  // def. "0", Run the host in threaded mode, (0 == off, 1 == if multicore, 2 == force)
r_threaded_client_shadow_manager    "0"  // def. "0",
r_threaded_particles                "0"  // def. "1", Determines whether the particle system is multi-threaded. This should be set to 1 on systems with multi-core CPUs.
r_threaded_renderables              "0"  // def. "0", Determines whether part of the rendering system is multi-threaded. This can be set to 1 on systems with multi-core CPUs to potentially improve performance.
r_queued_decals                     "0"  // def. "0", Offloads a bit of decal rendering setup work to the material system queue when enabled. on(1)/off(0)                                        
r_queued_post_processing            "0"  // def. "0",
r_queued_ropes                      "0"  // def. "1",
cl_interp_threadmodeticks           "0"  // def. 0, Additional interpolation ticks to use when interpolating with threaded engine mode set. 1 for better. 0 for stability.
cl_threaded_bone_setup              "0"  // Def. 0, Enable parallel processing of C_BaseAnimating::SetupBones()
cl_threaded_client_leaf_system      "0"  // def. 0,
Reply
#8

The mat_queue_mode command didnt work, at least not as a launch option (couldnt boot so couldnt drop into console). Looks like value kicked TF2 over to single core support by default...this allowed me to get in.

Clusterf***k fps drop seems worse than normal after this update...keeps up, I might have to go back to getting my ass kicked on the rotation servers...lol
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)