Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Bobboau on November 25, 2006, 11:55:27 am
-
I did some refinement on a lot of the turret and submodel related code I've been doing the last few days, and fixing bugs, this (http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_11-25-06.zip) is the most up to date executable,
it has:
the off axis rotation code.
the 'look at' code.
it has a new detail box variant called detail sphere (just like the box but a sphere, syntax: "$detail_sphere:1,100" were the 100 is the distance from the object and 1 or -1 determines if it will draw in or out of the sphere).
"check hull" subsystem flag for turrets, they won't fire through the hull of there own ship to hit something on the other side.
and I fixed a visually annoying bug I call turret jinking, were the turret just teleports from one position to another almost instantly, now they move quite a bit smoother. or they should at least.
I also reworked some internal stuf related to getting from one set of coordanants to another that assumed they there would be no grandchildren in the model hierarchy. wich might allow turrets to work when attached to a rotating subobject.
it'd be nice if some of you people could give that a nice workout,
-
"check hull" subsystem flag for turrets, they won't fire through the hull of there own ship to hit something on the other side.
You are a god! THANK YOU SO MUCH!
-
"check hull" subsystem flag for turrets, they won't fire through the hull of there own ship to hit something on the other side.
Hurray, I waited so long for that. Now I can finally protect the flank of our ships with point defense turrets. Thanks :)
-
Check hull, eh?
I'm not sure if I'm right, but the beam turrets are pretty funky on the Cain and Lilith-class cruisers. Do those work correctly? :nervous:
I'm not bashing the build or anything, I'm just wondering if the awkward (though not from the front) beams on the Shivan cruisers work with check hull. :)
-
hense why it's a subsystem flag and not just globaly implemented.
-
Is this based off latest CVS or 3.6.9?
-
it's based off of what I got when I checked out a fresh copy of the source a few weeks ago, I haven't gotten around to messing with the branches yet, so I'm not sure which one it defaults to.
-
It defaults to HEAD, so it's not using the 3.6.9 code base.
-
That's awesome Bob, Thank you...
:yes:
-
hense why it's a subsystem flag and not just globaly implemented.
Where does the flag go, subobject properties or table entry ? Can you post an example entry?
Also, thanks muchly :)
-
table, it's just like every other subsystem flag.
$Subsystem: turret01,1,1.0
$Default PBanks: ( "Mekhu HL-7" )
$Flags: ("check hull")
beneath the weapons (the awacs thing goes before it but it's rarely used so this is more of a technicality)
-
Ok I think i've got a grasp of side mounted turrets, but could you explain how to use the look at (thats the recoil right?)
-
no, it's not recoil, it makes subobject A look at subobject B
you go to object A's properties and you type $look_at:#object B's number here#
and it needs an axis of rotation defined like a rotating subobject would have.
you can then optionally define what the axes are with the ole off axis rotation stuff.
-
Oh that.... i remember reading about that... the hydrolic pump...
I do remember seeing something about what looks like recoil.
-
there are ways to fake that, but I wouldn't bother doing that right now.
-
Maybe it wasn't you... but I remember seeing an avi of it working..
-
iirc, you can do recoil with the animation code.
-
Just had a cool yet completely pointless use for the subsystem-look-at feature. One could assemble a fully functional (in terms of moving parts) piston engine... minus real fuel of course.
-
The fuel part might be faked with shockwaves, and a stream of heavy bombs being guided in by the fuel injector.
-
try this baby out. probibly gonna put this (or turrets like theese) on the rumrunner.
it would probibly binifit from the $y_fov property if it would just work. bob, clue me in on its usage.
i decided il probibly use you hydraulic pistons feature on the vulture, they will be used to jack the wings in for landing.
[attachment deleted by admin]
-
Just had a cool yet completely pointless use for the subsystem-look-at feature. One could assemble a fully functional (in terms of moving parts) piston engine... minus real fuel of course.
Not quite pointless; imagine a gauntlet/infiltration mission where you have to fly a fighter through a hollowed out asteroid used as a spacecraft factory, dodging pistons that press down onto a conveyor belt...hit your burners or you might get squished...to get to the heart of the asteroid, hit its reactor, and destroy it.
Is it possible to make the "check hull" feature also include a "parent" ship that the turret might be placed near? I mean, say for example one chooses (for whatever reason) to make the turrets of a large installation be separate ships from the actual installation...how does one prevent those turrets from firing through the installation to reach the enemy target? Or will they not do that?
-
Just a short question:
Will there also be an updated FRED.exe? Cause it's a little bit annoying seeing FRED always mourning about the "check hull"-flag.
-
eventualy
-
"check hull" subsystem flag for turrets, they won't fire through the hull of there own ship to hit something on the other side.
Just to inquire, will it also check for docked objects? I'm looking to use this build to test out a Frankenstein'd Argo... :lol: BSilv keeps getting blocked... at certain angles, the beam will hit the target (nothing blocking the way), but at other angles of attack, the beam gets caught in between docked objects...
:sigh: I can't be bothered to type a lengthy post about it, so I'll have to experiment around with the "check hull" flag with all seven docked objects on my own... :lol: :blah:
-
not at this time
-
So... is this in CVS? I'd love to see these features appear in 3.6.10.
-
it doesnt apear to be. i think there were still some problems with the collision detection.
-
3.6.10 is going to get a few minor new features, but it's still mostly going to be a bugfix build of 3.6.9. Some "features" are actually going to be reclassified as "bugs" in this case (like some networking stuff for mods, new FS2NetD code, some OpenGL changes, etc.), but it will still be more of a "fixing-old-issues-with-newer/better-features" thing rather than a "here-is-something-totally-new" thing.
This particular feature might be one of those to be reclassified as a bugfix, but only if it works well and gets enough testing by the time that 3.6.10 is getting ready to go out. This is one of reasons why I'm basing my X builds on the 3.6.9 code base instead of CVS HEAD, it will allow proper testing of those features that might get to go into 3.6.10, even though not all of them will.
-
will the scripting upgrades make it?
-
will the scripting upgrades make it?
No. That breaks compatibility with 3.6.9 scripts (I think, anyway) and qualifies as a major change. We need 3.6.10 to be at least 98% compatible with 3.6.9, particularly anything content related. 3.6.10 needs to be able to be a drop-in replacement for mods which are based on 3.6.9, and not require any data changes to actually work with the new build. About the only compatibility breaking element going into 3.6.10 is the new FS2NetD code, and that's only because of 2-dozen-plus bugs and compatibility issues that will get fixed by the upgrade.
-
what 3.6.9 scripts? all the big ones have been upgraded for the new system. as it stands there arent many people doing scripting at the moment. all the screpters that i know are at kind of a consensus that ongoing changes to the system are acceptable, so that the system may be refined to its maximum. now is the time to change it before people get accustomed to the old way of doing things. now if 3.6.10 is going to be a month or two away i can see your point. but i do think that system consistancy shouldnt be the main reason for not adding in the upgrades. i have no problem if the main reason for not compiling it in is a bugfix cycle though.
-
3.6.10 is coming around the May timeframe, so it's not far off. The main point of it is to get in the changes which we couldn't get in for 3.6.9, but were originally slated for it. And of course, it will get additional bug fixes and performance improvements.
The scripting code in unstable is still getting changes, so until it's fully stabilized there isn't even anything to discuss. Until the API is solid and stable there is no way that it will be considered for a stable build, period. And even if it was totally solid now there isn't really enough time to get it bug tested enough before 3.6.10 comes out. The new code throws out compiler errors and has platform related code issues like crazy and there simply isn't time to fix/test it all.
We maintain two trees for a reason, stable code is for releases, unstable isn't. Some things will get added to both stable and unstable, other things won't. Anything in unstable is slated for 3.7 releases, nothing else. The stable branch will be for 3.6 releases, which will mostly be bug fix related. The stable branch is still getting new code and features, but nothing big so that we can actually keep it stable. If you rely on features and changes in the unstable branch then you have to understand that those things are not going to end up in stable, official, builds for many many months.
If you want those features then use an unstable build, and deal with all of the bugs that go with it. I'm not going to be using the unstable branch until later this year, and anything that I do work on will be my own stuff, I'm not fixing any more bugs in unstable until next year at the earliest (unless the bug is also in the stable branch). I'm only working on my own new features from now on.
If you want a stable and official build then stick with what we release from the 3.6.9 branch. It's fully supported and has the full weight of all bug fixing ability focused on it.
-
what 3.6.9 scripts? all the big ones have been upgraded for the new system.
*points at the BtRL scripting.tbl*
That's probably news to Axem and Wanderer. :p
-
Yeah, both BtRL and SoL are using scripting that is from 3.6.9. Maybe they will, or have, upgraded everything to the new API, but that's their call and we aren't going to force that on them. Those TCs will either ship with an unstable build in order to get the new scripting, or they will want a stable build with the older scripting API. We aren't going to break the API, or introduce unstable code into the stable tree, for 3.6.10 simply because those mods DO use the current scripting API and probably don't want to wait for yet another long period of time for the code to stabilize so that they can release.
-
Actually SoL has moved to the new system and the only reason we used the old system for BtRL was because we're stuck with 3.6.9 for the demo. I'm leaning to cutting out any lua scripting from the BtRL demo because of limitations in the old system that we can't get around.
-
I'm leaning that way too, to be honest as it certainly removes one major source of upgrade hassles for me if 3.7 comes out before the full BtRL release and people want to try using it to play online.