Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: WMCoolmon on March 29, 2007, 01:01:08 am
-
Latest Build
C03282007 (HEAD) (http://fs2source.warpcore.org/exes/latest/C03282007.zip)
- Improved Linux error-reporting support
- Fixed one silly bug that's been around since practically day 1.
- Optimized internal hook variable get/set/removal algorithms.
- "+Override:" field is now definitely fixed.
- Added "On Splash Screen" and "On Game Init" conditional hook actions
- Added "Version" conditional hook condition
- Added "Shields.CombinedLeft" and "Shields.CombinedMax"
- Replaced subsystem:getName() with .Name; added the ability for subsystems/turrets to have a name independent of the original model name to support the variable. This name will be used for the targeting computer and SEXPs.
- Added "Self" and "Object" variable pair to all collision sequences to allow for easier generic collision actions.
- Tweaked drawString so that when it's called without any position arguments (eg gr.drawString("Hello")) it will write another line below the previous one. It starts at (0,0) by default
- Added "Self" hook variable for the HUD hooks.
Added *tentative* support for model textures. This works but does not support glow or spec maps and so may be revised. This will be removed in following builds following taylor's recommendation.
- Added getFilename() method for textures
- Replaced setTarget with gr.CurrentRenderTarget variable
- Changed "Object" hooks of warp hooks to "Self"
-
Does this one corrupt pilot files as well?
and the link is down
-
uhmm, links busted
-
Extra 'b' removed.
-
removed provi... provius.... pro... thingy question to replace it with this:
The FREDDED!!! build crashes evertime on mission commence, no matter of feauteres and mods installed.
-
removed provi... provius.... pro... thingy question to replace it with this:
The FREDDED!!! build crashes evertime on mission commence, no matter of feauteres and mods installed.
Ugh. I don't know what's up with that; I didn't make any FRED changes, but I guess I must've hit something indirectly.
FRED does have scripting enabled, by the way. I believe the global hook(?) will show stuff in the main FRED viewport. It's been awhile since I did that. That being said, I guess it's no wonder it was affected. :p
I'll look into it next time I work on the scripting stuffs.
-
If I may be so bold, and if the general populace (read: me) would be capable of understanding it, just what was that "from day one" bug?
-
im, taking a wild guess and say the spacing bug, where code wouldnt work once and by simply adding or removing whitespace yo could make it run.
that one that is crossed out, is that supposed to be for the thing i requested for manipulating textures for 3d hud gauges? or is that something else entirely?
-
If I may be so bold, and if the general populace (read: me) would be capable of understanding it, just what was that "from day one" bug?
In order to feed the text from scripting.tbl into the Lua parser, I had to read it into memory and then call the Lua parser. Since day one, I've had an inexplicable problem where I could assign the memory, load the text into it, and run the parser, but when I tried to tell the system that I was done with the memory and it was OK to use it for something else, FS2 would always crash.
Buried in one function, I found that one of the things I'd done was add a character on to the end of the text that would mark it as the end of the text. Unfortunately, I hadn't taken this into account when specifying the size of memory I needed, so that errant character kept on being written to a piece of memory that I wasn't technically supposed to have access to. (Probably not being used for anything else, either.)
It might have been the whitespace bug. When FS2_Open requests memory for anything, there's a relatively low chance that it's going to actually get a block of empty memory that's the exact size as it wants. Typically, it'll get apportioned a block of empty memory that's much larger, so writing an extra byte isn't going to hurt anything else. But if you fiddled with the whitespace you would change the size being allocated, thus thanks to random chance, you would be more likely to hit a block of memory next to another program's block of memory. FS2 would try to write the extra byte and the OS would throw an access violation.
-
removed provi... provius.... pro... thingy question to replace it with this:
The FREDDED!!! build crashes evertime on mission commence, no matter of feauteres and mods installed.
Ugh. I don't know what's up with that; I didn't make any FRED changes, but I guess I must've hit something indirectly.
FRED does have scripting enabled, by the way. I believe the global hook(?) will show stuff in the main FRED viewport. It's been awhile since I did that. That being said, I guess it's no wonder it was affected. :p
I'll look into it next time I work on the scripting stuffs.
I didn't mean FReespace EDitor actually, FRED is now my new curse word. with the build I ment the Nromal FreeSpace2 build.
EDIT: Same for FRED
-
CTD without any suspicious debug messages.
Right when I see the first frame of a mission.
This happens with standard FS2, as well as with SoL.
-
CTD, happened with retail, mediavps and SoL.
OpenGL Error: lasku ei kelpaa
!!DEBUG!! OpenGL Errors this frame: 1
Frame 1 too long!!: frametime = 1.714 (1.714)
That is the only error i managed to get..
lasku ei kelpaa is something like Calculation is not valid or something
-
^what they said^
Apprently someone really fredded up the build...
-
I too was getting a crash to desktop, but I thought it was related to something I broke while table editing. Guess not it seems.
edit: I'll try to be more useful, and see if running the debug build gives any useful information, when I get a chance.
-
it doesn't, that one crashes to desktop to before it can give any debug info.
I already checked out all possibilities, retail, mediavps, direct3d, opengl, 640X480, 1024x768, no freatures, all features, software mode, all troubleshoot on...
it doesnt work.
Too much to handle?
-
Too much to handle?
:lol:
Indeed, thanks for checking out all those possibilities.
I am trying to get around to this, but it seems everyone and everything want a piece of my time these days...
-
I got some improvement, adding scripting.tbl (with scripts!) did something, now I get a lot of errors...
Got it to work! it seems that the absence of scripting.tbl causes the build to crash, so everyone, add scripting.tbl to your data/tables folder (if possible, with scripts).
-
Bad WMC! Bad! That's not the way to get more people using scripting. :p
-
:lol:
Sweet, my compiler can read my mind and tell what my subconscious desires are. It's just like that one Michael Chricton story. :D
Oh wait, a bunch of people died in that one...
-
:lol:
Sweet, my compiler can read my mind and tell what my subconscious desires are. It's just like that one Michael Chricton story. :D
Oh wait, a bunch of people died in that one...
*WMCoolmon suddenly notices that Joshua sticked a lunch pakket and a Shivan attractor to his back, and can't get it off...*