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 23, 2008, 08:38:53 pm
-
Changes:
Everything from C03222008 (http://www.hard-light.net/forums/index.php/topic,52871.0.html) plus...
- Fixed bug involving ships with animated textures
- On Warpin and On Warpout now On Warp In and On Warp Out to standardize things
- transpose and interpolate matrix functions now getTranspose and getInterpolated to standardize with vector
- Added model.BoundingBoxMin and model.BoundingBoxMax
- Added ship:giveOrder(), with 18+ orders. Docking and waypoints do work.
- Added gr.getVectorFromCoords, which returns a vector in 3D space from screen coordinates and a depth
- Added $On Mission Start and $On Mission End hooks
- Optional handle arguments in functions can be skipped with "nil"
- Fixed WaypointList handles
A few words:
The focus for this build was pretty much all of the RTS requests.
ship:giveOrders works using the goals system, which is a more specific way of saying that it does the same thing as the player menu, but adding some of the capability of SEXP goals. You can't do anything with wings right now; at the point that it becomes an issue, I'm going to consider upgrading the scripting system so that you can just specify the wing in place of the target ship, rather than have an extra variable for wings.
Player priority is 1.0, while player orders to wings are .95, and initial orders taper out at .85 or so. I'm using floating point numbers to try and standardize things in Lua, since factors require one less calculation than percentages.
See orders_test-sct.tbm for an example script. When Mo warps in, Mo attacks Curly, Larry tries to dock with Mo, and Curly tries to evade Mo, while the Guide follows the waypoint list called Path.
getVectorFromCoords also has a lot of potential. gvfc_test-sct.tbm locks the targeted ship into your mouse cursor, much akin to the Half Life 2 gravity gun. :D Left-click and hold to increase the lock distance, right-click to decrease it.
Links:
The build (http://fs2source.warpcore.org/exes/latest/C03232008.zip)
Scripting.html (http://fs2source.warpcore.org/exes/latest/scripting.html)
[attachment deleted by ninja]
-
I think you mean http://fs2source.warpcore.org/exes/ (minus the "latest") or to move it.
-
:sigh:
FTP, I stab at thee...
Uploading now, try downloading in ~5 min. :)
-
Moah for teh fail. First crash is regular, second crash is at misson end in debug:
errorlog.txt (http://zacam.ueuo.com/scp/errorlog.txt)
fs2_open.log (http://zacam.ueuo.com/scp/fs2_open.log)
-
First crash looks like it's going to be a 'duh' moment due to a null pointer, but I can't match up the numbers in the file with the .map file. What were you doing at the time/what scripts were you using/what mission were you playing?
The second one was easier to find, but it's apparently a known bug:
// TODO: I think this Int3() is triggered when a wing whose ships are all docked to ships of another
// wing departs. It can be reliably seen in TVWP chapter 1 mission 7, when Torino and Iota wing depart.
// Not sure how to fix this. -- Goober5000
Int3();
-
The second crash was using the debug build (because the regular performs the first crash immediately on launch) and I had just gotten the "Return To Base" message on SM103.
3.6.10 Beta mvp's. No other applications open (for a change).
-
It looks like the bug is basically not a bug - the problem is that the function was noticing that the number of destroyed ships wasn't equal to the number of ships that arrived. That works pretty well unless the wing doesn't get slaughtered :D
I fixed the check and played through the TVWP mission in question, as well as SM-103, and it seems to be fixed now. (Fix is in SVN)
What about the first crash?
-
What about it? I launch the normal exe and in the middle of the SCP logo splash I get a M$ "Do you want to send an error report". Hence why I ran debug and got the second crash.
On your comments regarding the cause of the 2nd crash: All wings of enemy ships were destroyed as were the two NTF cruisers and both cargo vessels. So, unless I absolutely was not supposed to loose a wing man OR the cruisers (either of them) were supposed to spawn ships but didn't because they died before doing so, it should not have failed.
I did notice that the mission seemed to progress really fast in comaprison to other builds though.
-
What I meant was that I was able to fix the second bug. The first bug remains a mystery; I have been able to determine that it occurs somewhere in parse_ship, but not on the first ship. I tried commenting out the changes that were just committed to ship.cpp and that made no different.
-
thanks alot, i thought my rts mod was another dead end :D
cant seem to get it to start. the debug build works ok with the fsrts, just got to unscale the output of getScreenCoords(). while im at it im gonna mess around with some of the orders and see if i can make anything cool happen.
-
Well, it looks like the first bug by Zacam was fixed as well. I don't know exactly why, but I was able to reproduce it, and now I can't. Still happens with the old build, though. So I'm going to assume, for now, it's a compile bug and hope it doesn't crop up again.
Here's a quick update so there's a working release build.
Changes:
- Mystery bug "fixed"
- Multiplication/division for vectors. This isn't defined mathematically, so it just does x/x,y/y,z/z.
- Camera stuff has been tentatively moved to graphics. If this breaks any release scripts, I'll move it back. This will make much more sense when the new camera code gets into stable.
- drawPolygon, which is currently only partly working. Textures don't seem to render at full opacity and it only works in certain hooks (eg works for On Object Render, but not for On Frame). It doesn't crash when it doesn't work, you just won't see anything.
Screenie:
http://fs2source.warpcore.org/temp/wmc/myrmidon_x.jpg (47KB)
Build:
http://fs2source.warpcore.org/exes/latest/C03242008.zip (7.2MB)
-
build works good. im currently adding some useful commands to the fsrts now. no major problem thus far, but it will be some time before i can test everything.
-
Well, it looks like the first bug by Zacam was fixed as well. I don't know exactly why, but I was able to reproduce it, and now I can't. Still happens with the old build, though. So I'm going to assume, for now, it's a compile bug and hope it doesn't crop up again.
Here's a quick update so there's a working release build.
Changes:
- Mystery bug "fixed"
- Multiplication/division for vectors. This isn't defined mathematically, so it just does x/x,y/y,z/z.
- Camera stuff has been tentatively moved to graphics. If this breaks any release scripts, I'll move it back. This will make much more sense when the new camera code gets into stable.
- drawPolygon, which is currently only partly working. Textures don't seem to render at full opacity and it only works in certain hooks (eg works for On Object Render, but not for On Frame). It doesn't crash when it doesn't work, you just won't see anything.
So far, no crashes in either build by any previously known mothed to produce. :-)
Now that I can launch it, I can now test it. I can almost forgive this build not having normal maps....it has speed and looks GREAT doing it. F'n kudo's to all that made this possible.
Now if you will excuse, I'm going to beat this build with everything I have.
-
Update to this series:
http://fs2source.warpcore.org/exes/latest/C03292008.zip
One change:
- Removed restrictions on cf.openFile write mode so it has access to all FS2 directories, rather than just root folder
Do not **** around with this. Use it very carefully, and make absolutely certain that you know what the modes are (see fopen (http://www.cplusplus.com/reference/clibrary/cstdio/fopen.html)). If you open a file with "w+" you will permanently delete the contents of that file. As should be obvious, I highly recommend backing up your FS2 directory tree but best of all, moving everything to a different directly entirely to experiment with this function. This is because of the many pitfalls of the CFile system, and the unexpected things that can happen when you use the -mod command line. (see this thread (http://www.hard-light.net/forums/index.php/topic,52721.0.html))
Basically I don't want somebody to accidentally wipe out a mission or model that they spent hours on. And finally - I didn't test this with VPs; it may be possible to write to files in VPs, in which case all hell will break loose and some other file(s) in the VP will get corrupted, if not the entire VP, if the file size changes.
I'm not going to leave this in future builds until it can be made a bit safer/more reliable, but since there are some definite uses for this that will take time to develop, I'm releasing this build as a temporary solution.
EDIT: Also, don't use the build with unread scripts from people who don't like you.