Steampipe fix [1187: Episode One] Released
Context
Since the Steampipe update (2013), many Source engine based
game modifications have stopped working correctly, which
required to do special editing to make them at least
launchable.
Still, this method has proven not to work in special cases
such as mods containing custom compiled code,
.i.e Dangerous World 1 & 2, Korsakovia, along with many
others.
About two weeks ago, I put on a beta for this patch, and
was expecting feedback from users who would test it.
It turned out that I received no response from anyone,
so I am unable to differentiate between if people were
actually interested in participating, or because they
simply did not find any bugs or decided not to provide
feedback and wait for the full release.
Release
Today, I announce the official release for the 1187 patch
I promised a few weeks ago. People can now download it at
the following link:
Additional information
This is possibly the largest patch I have released at this time,
but also this is the one that took a long time to make.
Users who have already downloaded and played it have inevitably
noticed missing features such as in-game menu manual,
or altered level flow as seen in both first and second levels.
I tried to implement the manual and sadly, it ended up not working
properly, as it uses an HTML page to display it's content, which seems
to work improperly in the current Source SDK branch (2013). As such,
I had to remove it in the patch.
As for altered levels, these changes were necessary due to improper model
processing that caused game to crash. In the Readme.txt, I stated that
the cause of these crashes is unknown. This is because these explanations
would be too technical for people to even understand. Thus, I needed a
simple reason that users would take for granted.
The last paragraph explains in depth the problems I encountered, in a more
technical way. Readers can safely skip to the conclusion.
Starting in level 1, and 2, when walking through the corridor on second floor,
the game started crashing arbitrarily, so I made several tests to try to locate
the source of the problem. I began by putting the debugger and monitoring the
call stack in Visual Studio, which reported that the crash (access violation)
was coming from StudioRender.dll. Sadly, I did not have any source code for
this module, as Valve never released it. I was unable to generate debug information
and get to the actual location where the crash happened. For a bit more precision,
the module StudioRender.dll is responsible for processing model rendering, as it's
name implies. This led me to believe that a model was the actual cause of this
problem. At first, I thought it was related to human models, which would fail to load
in the model viewer, but would draw properly in game. There were over 100 models both
levels, at this single location, so it would have taken a long time to try to suppress
each model and try to see which one was causing the crash. I had to find a solution to
get around this problem, so this is why I altered level flows, to prevent players from
accessing these areas that would crash the game. I understand these are 'cheap' methods
and I wish I would have had not to modifiy the original levels. Perhaps it used not to
be a problem in previous versions of Source engine, but as for now things have not been
working properly. Users who downloaded other patches such as Rock 24, City 7: Toronto,
would notice some of my 'methods' to overcome these obstacles, because otherwise levels
would not play properly.
Conclusion
Once again, I would like to thank users for their patience, providing constructive
feedback and ways to improve these patches. This one was a tough patch to make and
deliver.
Have fun!
