Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: WMCoolmon on September 08, 2008, 05:51:45 am
-
Changes:
Warp Changes
- Added OF_LIMBO flag (Bumbumbum...)
- Added field to ai-warp-out to toggle departure
- Added ai-warp-in
- Added is-in-limbo SEXP
- Many, many other changes and incremental improvements to support uninteractable OF_LIMBO objects
- Fixed ships disappearing at the wrong time with warp
- Fixed/Completed sounds for BTRL and Homeworld warp effects
- Fixed Homeworld effect 'jumping' at transition between opening or closing sequences
- Fixed Homeworld and BTRL warp dimensions when docked (Known issue: BTRL FTL effect may get rendered under docked objects)
Scripting Changes
- Added On Frame Simulation hook
- Added gr.CurrentCamera
- Added boolean to ship:warpOut to toggle departure
- Added ORDER_ARRIVE for ship:giveOrder()
- Fixed ship.Textures indexing by name
- Fixed ship.Velocity to calculate speed/fspeed when set
- Fixed lua vector/orientation indexing with uppercase characters
- Changed createVector and createOrientation to newVector and newOrientation
- Changed camera 'Self' and 'SelfSubsystem' to 'Host' and 'HostSubsystem'
Other
- Got rid of unnecessary Assert(banks_fired)
- Tested HUD damage gauge with custom subsys name (it worked)
- Tested camera deceleration (it worked)
Intrasystem Warping:
Set the second field on ai-warp-out to "0" and then call ai-warp-in when you're ready for the other ship to come in.
This uses the old limbo method to do this. The plus side is that all of the SEXPs work with the ships while they're in limbo, so if you want to rearm/repair or change the ship's position etc you can do so. The down side is that all of the SEXPs work with the ships while they're in limbo, so you have to keep track of ships yourself. has-arrived-delay and has-departed-delay will not work - those still work with the mission arrival and departure cues.
Multiplayer, as far as I know, doesn't support this arrangement right now. I could add extra data to the packets but that would break compatibility.
In general, everything will behave like the ship that warped out has departed for good. This means if you have a ship on course to dock with a ship that warps out, you'll have to reissue the dock order once it jumps back in. One exception is the escort menu - it'll retain memory of the ships that have jumped out and keep those on the list. You can still send messages from ships in limbo and they won't show the targeting brackets. Ships will also not show up on the F4 screen when they limbo in/out - see "Jargon" below.
There's also some interesting things you could do with this as future coding features, like flagging certain wings to just warp out when ordered to depart and appear on the reinforcements list when warped out. With some SEXP or scripting, you could then slowly repair the ships over time until the player ordered them back in.
Jargon
"Arrived" and "Departed" remain specific to the act of entering and exiting the mission. A ship which warps in or out does not arrive or depart, and won't appear that way to any of the SEXPs. This is by necessity - it would obviously make them worthless if they behaved as they do now and got set for good once a ship had warped in/out once, and confusing if they got reset every time.
SEXPs
SEXPs will act like the ship is still in the mission and still at the spot where it warped out (until you move it with SEXPs or scripting, or it warps back in). I need to go through the list, but I'm up in the air on this. I can see instances where it might be useful to know where a ship in-limbo is, but I can also see where it would cause mass confusion.
Extendability:
If somebody wants to implement something else that uses limbo, you just need to call:
//Enter limbo
obj_set_flags(objp, objp->flags | OF_LIMBO);
//Exit limbo
obj_set_flags(objp, objp->flags & (~OF_LIMBO));
Know bug:
Colossus doesn't warp in at the right spot on "Endgame". This doesn't actually have anything to do with the limbo code, it's almost certainly an issue with the default warp effect changes I made.
I was going to hold off release until I'd fixed this bug and looked into making ships appear in the F4 screen, but I want to have the maximum amount of time for people to test intrasystem warping and let me know if I've missed any changes I need to make. I expect SEXPs will be one thing, but again, I haven't had time to look over them.
TODO:
- Test/bugfix
- Look into F4 screen w/ regard to limbo
- Look over SEXPs w/ regard to limbo
- Group HUD wingman status code in hud wingman status section
- Finish implementing lights in scripting
- Add $On Object Create/$On Primary Fired/$On Secondary Fired hooks
- Look over scripting functions
- Rest and relax
Build:
http://fs2source.warpcore.org/exes/latest/C09062008.zip
-
Like it :)
-
Hooray!!!
Now if only Nuke would get back to working on the mod...
-
I found a problem with this build. I was playing the last mission of the NTV demo and had a mission where the remaining Vasudan bombers would warp out after a vasudan cruiser was destroyed. The objective for protecting the destroyer relied on a destroyed or departed sexp. The mission did not see the bombers as departed and the event did not go to a true status. The game still showed the bombers as being present. I replayed the mission using the C09032008 build and it worked normally.
-
The warpin jump sounds for the BSG effect don't seem to be playing:
$Warpin type: BTRL
$Warpin Start Sound: 69
$Warpin time: 0.3667
$Warpin animation: ftl
$Warpout type: BTRL
$Warpout Start Sound: 70
$Warpout time: 0.3667
$Warpout animation: ftl
-
It's not actually a code problem. The effect sound has a pause for longer than the effect animation lasts, so the effect happens before the sound gets to anything meaningful.
I'm going to revise the BTRL warp code. Right now it'll autoscale the distance values given in sounds.tbl based on the ship's size (table values are assumed to be for a 100m long ship), but that's going to be too confusing. After some further thought I'm going to switch it back, so you'll have to make explicit sounds.tbl values for the effect if you want different distance values based on ship sizes. The same goes for the Homeworld effect, unless either of the two mods has a preference.
I found a problem with this build. I was playing the last mission of the NTV demo and had a mission where the remaining Vasudan bombers would warp out after a vasudan cruiser was destroyed. The objective for protecting the destroyer relied on a destroyed or departed sexp. The mission did not see the bombers as departed and the event did not go to a true status. The game still showed the bombers as being present. I replayed the mission using the C09032008 build and it worked normally.
I think I found it. The problem was that the departure code uses the AI to warp out, but circumvents the normal AI goal system. So the AI code checked the permanent-departure value for whatever the last goal was before the ship warped out - which wasn't set to anything definite because ai_goal doesn't have a constructor and no other goal does anything with the permanent warp switch.
I'm pretty sure I coded in a fix but I haven't gotten around to testing it yet.
-
Check and see that this build (http://fs2source.warpcore.org/exes/latest/C09122008.zip) doesn't fix it.
- Removed sound range factor modification for BTRL and Homeworld warp effects
- Fixed departure bug with limbo code
Also, I'm going to set the BTRL FTL effect so that the 'start' sound happens from beginning to end of the effect, like now, but the end sound happens when the shockwave appears and continues until the sound is done. Unless there's objections.
-
I know it's only been a day, but, are there no responses because people haven't tested the build, or are there no responses because people are testing the new build and haven't run into problems? :p
If it's the latter, I'd like to know. My goal is to have this committed by the end of the week.
-
I've been testing it, and unfortunately the sounds still don't seem to play on the BtrL jump effect. The table entry is exactly as posted in this thread still, I just have the warpin sound part put in.
-
What if there were no responses because all the testers' computers got melted into slag?
-
I've been testing it, and unfortunately the sounds still don't seem to play on the BtrL jump effect. The table entry is exactly as posted in this thread still, I just have the warpin sound part put in.
Like I said before, it's not a code problem so nothing I do in newer builds will fix it. You need to cut out the dead silence in the beginning of the FTL sound effect for it to work properly.
What if there were no responses because all the testers' computers got melted into slag?
That sounds like a modern-day version of Schrodinger's cat. :D
EDIT: Yes, this was intentionally moved. PM me if you need the details.
-
Oh my God, is the limbo what I think it is? Ships and spacecraft can depart, keep their status and then return when needed?
-
Yes. The Nemesis nanojump now no longer requires a crude hack.
-
Using a letter FreeSpace doesn't reckognize in the name of a second ship isn't a crude hack...
It looks fantastic...any chance of getting this feature in 3.6.10?
-
If it involves resetting all the *%$&! beam turrets that you &#%!@ disabled before it made the jump, then yes, its execution is crude.
-
That helps with balance. In campaigns like Transcend and Sync some ships' status is always reset for balance issues.
-
I've been testing it, and unfortunately the sounds still don't seem to play on the BtrL jump effect. The table entry is exactly as posted in this thread still, I just have the warpin sound part put in.
Like I said before, it's not a code problem so nothing I do in newer builds will fix it. You need to cut out the dead silence in the beginning of the FTL sound effect for it to work properly.
Ah, nevermind. I didn't realize that it had an auto-cutoff when playing. I expected the sound to be delayed after the flash, but to still play.
As a side question- when will this and wanderer's turret code be added to the trunk?
-
The earliest any new feature can be added to the trunk will be after 3.6.10 is out.
-
Testing update:
Even with a shorter sound effect, the warpin and warpout sounds for the BtRL warp are not playing.
The sound files play when recalled through a play-sound SEXP, but not with warpin or warpout. Sound doesn't play even when the player ship jumps out.
-
The earliest any new feature can be added to the trunk will be after 3.6.10 is out.
Really? Why not adding the Limbo effect(only the Limbo effect...)for now? :nervous:
-
Congratulations, you're now banned for a day. :rolleyes: Stop asking us to make exceptions to the rules just for you. It's annoying, and it makes you look like childish.
Incidentally, for reasons of project stability, the limbo code may not be added to the trunk at all. I hesitate to definitively say "no", but at the very least Taylor and I would need to be convinced otherwise.
-
Before you close this thread may I know why you keep saying stuff like "make exceptions to the rules just for you"? For me? Giving me money or helping me out with the Uni would indeedly be a "personal" help but...what about this? I simply said that I don't want such a nice feature WMCoolmon came up with to be implemented in regular builds with a delay of several months. If I remember well you made the request to create the Limbo code - correct me if I'm wrong - and you should therefore be as happy as me to see regular builds using it. :nod: :)
Incidentally, for reasons of project stability, the limbo code may not be added to the trunk at all. I hesitate to definitively say "no", but at the very least Taylor and I would need to be convinced otherwise.
Oh well, how would I know this? ;)
-
Before you close this thread may I know why you keep saying stuff like "make exceptions to the rules just for you"? For me? Giving me money or helping me out with the Uni would indeedly be a "personal" help but...what about this? I simply said that I don't want such a nice feature WMCoolmon came up with to be implemented in regular builds with a delay of several months. If I remember well you made the request to create the Limbo code - correct me if I'm wrong - and you should therefore be as happy as me to see regular builds using it. :nod: :)
First of all, I didn't make the request for WMC to add the limbo code.
Second of all, if I had wanted to close the thread I would have closed it yesterday.
What I'm referring to when I say "stop asking us to make exceptions to the rules" is exactly that. Don't whine at us to add a feature in the middle of the code freeze. Don't whine when we establish a board rule. Don't whine when we close a thread. It's extremely annoying, and it makes us less inclined to help you in the future.
Incidentally, it's not just you; a few other people have exhibited this behavior too. So the one-day ban is basically a slap on the wrist saying, "Bad. Stop it."