Originally posted by redmenace
Ok. I have done all that. I read the readme. Other mods such as a special mod for the glow points work fine. and the BWO demo also works fine. I also tried taking the info from the \freespace2\TBP and placed it in the Data directory. Then ran 3.5 version of the SCP. However one other problem I experienced was one that I cannot get the debug version to work well when using the TBP. It cannot commit in some versions and others cannot get to the briefing and other times cannot load the mission period. It is probably a problem with my computer. But please tell me what you think.
The debug versions, is not a god tool to test Total Conversions on.
The TBP project for instance uses several different "background" images, which are oversized if you look at how the standard Volition ones is sized.
Debug means also mean that you check for nearly all limits, while release versions may not have these checks (checks cost CPU time). And some instances are not allowed in the debug versions, while they are ok in the release versions. Because back at release time in 2001, Volition thought of only their TBL files, in short, only their data, so they knew the limitations and what not to check for.
Most checks are aimed at the artist’s (modelers, Textures), which might “forget” the limits.
There are properly in the range 10.000 places in the code that are enclosed by special Debug definitions, to look them all up and make them work with all the things we want to, will/would be a huge task.
And most of us are dedicating our free time, to coding, something into the release versions or hunt bugs. While standard stuff "like oversized pictures" that already works in the release, but might not in the Debug versions, is not considered “Worthy”
of our time.
Often when you alter a limit or something inside a DEBUG define, you have to go hunt all the other things that are dependant on the settings, in that debug define.
Often you can generate a bug, that is not immediate apparent, but will show in time, and since then people might have committed 50 more changes to the code.
Sometimes it easy, you just have to disable a check, but also sometimes this check is there to prevent something like “the blue screen of death”, which gives you absolutely no clue to what went wrong. Unexpected error means something the programmer did not take into consideration.
C/C++ is very memory efficient, it needs to know how much space to allocate for all of the functions. This is both its strength and weakness. These boundaries are set at Compile-time. At run time these can be crossed, but will cause an error, if they are. Most checks are there to check that these boundaries are not crossed. When they do, you just get an unexpected error of some sort.
So if such a bug is generated, we have open email to see who committed what, open each email, and open each attachment, in order to understand if this specific commit has something to do with the bug.
For instance, When i was tracing the Shield/beam bug(caps ship beam fire would Zap fighters shield strength), I had to put in about 5 messages in order to trace back where to the bug originated, and read trough 30-40 emails attachments in order to see who altered what.
The Code was fine, only not complete, and it was not immediately apparent that this could cause the bug, since the code was not committed /coded by the bug-hunter "me".
So when you report about errors, bugs, relate to the release versions, not the debug versions.
When debug version are released you should only test light stuff, like models, and changes that are released to see if a new enhancement like Glow-maps is working. Debug versions should not be used to test Total conversions.
This is not aimed at only you, but to everybody who has a bug to report.
Think, "Could it be, that this bug was caused by me"
In this case yes, since you where using a debug version.
Phew, long post here.
