Author Topic: Brace Yourselves  (Read 2752 times)

0 Members and 1 Guest are viewing this topic.

Okay, here is the crap. I am hiding in my invincible bunker so any horrible things you would want to do to me for this automatically fail.

Is there any current way, through scripting, workarounds, etc. To get any of the following into the game.

A: Secondaries that shoot more than one type of projectile. Like one point would shoot one rocket while the other would shoot another type when you click secondary fire.

B: Barrage fire. Where pressing the secondary button results in several seconds of firing rather than having to hold it down.

C: Animation. Seriously I know there are techincally incredibly limited and rubby animation commands that let you rotate a subobject, but I want to know if it is AT ALL possible to add in even an animated model. Like you go left, change character animation to animation_6 or something. Even just armoured core level of animation would be acceptable.

D: Notices when another player fires a specific weapon. Like when they fire it a comms message triggers. I'm actually fairly sure this could be done with SEXPS.

Now. Let the beatings commence.
"I only miss what I don't hit."
Show me something that beats 87 BF reds and I'll show you Hateful Lies!!!

 

Offline Aardwolf

  • 211
  • Posts: 16,384
    • Minecraft
Why did you post this in two boards?

 
Becasue scripting gets like NO traffic and nobody in modding knows how to script.

I have an absolutely WONDERFUL idea for a mod I really want to do, but there's a few key issues with freespaces engine that I need to know if they can be remedied. I already know two of those are fine and I'm thinking maybe A can be solved with hidden turrets that are locked untill the player triggers the SEXP or something. Still not sure about the animation though.
"I only miss what I don't hit."
Show me something that beats 87 BF reds and I'll show you Hateful Lies!!!

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
A: Secondaries that shoot more than one type of projectile. Like one point would shoot one rocket while the other would shoot another type when you click secondary fire.

You could check for keypresses and mouse presses with scripting and create a weapon with the appropriate speed, position, orientation, and target (though you might have to manually set up gunpoint data for each ship). This wouldn't work for the AI (it has no intelligence for this sort of thing and doesn't work via the keyboard/mouse input code), and it wouldn't work if the player remapped the keyboard or mouse or used a joystick.

B: Barrage fire. Where pressing the secondary button results in several seconds of firing rather than having to hold it down.

I've seen this done, in Blaise Russel's FS1-era FS2Open campaigns, if I remember right. I think it's done by $Swarm.

C: Animation. Seriously I know there are techincally incredibly limited and rubby animation commands that let you rotate a subobject, but I want to know if it is AT ALL possible to add in even an animated model. Like you go left, change character animation to animation_6 or something. Even just armoured core level of animation would be acceptable.

You can rotate subobjects, but that's about it. Anything else requires writing your own animation system using multiple models (which for this purpose would be analogous with 'ships'. You'd need a ship class for each arm, leg, etc. or do something bizarre like having the complete model, destroying all the subobjects but the limb you were going to use, and then using multiple ships of that type with different positions to create the full model. So you'd have a 'mecha' model, then you'd kill every subobject but the head subobject, move that vertically. Then you'd make another 'mecha' ship, kill everything but the right leg subobject, and move that down and to the right, etc. All that would be part of your render function, which would handle changing each ship's orientation/position to animate each ship. You'd also have to account for the ships hitting each other - that would be bad.)

D: Notices when another player fires a specific weapon. Like when they fire it a comms message triggers. I'm actually fairly sure this could be done with SEXPS.

You could use scripting to go through all the weapon objects and compare the parent to the current player. If the weapon is newer than the last check, you set a SEXP variable. Then you set up a SEXP conditional to check if that variable has been set via scripting, unset it, and send the message.

You might be right about it being doable with pure SEXPs, but that's how you could do it with scripting. I don't know about pure SEXPs.

EDIT: Conceptual corrections, the engine should handle drawing ships for the mecha thing, you should just have to move them in order to get the animation effect you want. Note that some kind of fluid half-life 2 animation thing is going to require a lot more work and probably can't be done without lowlevel engine modifications, new vertex shaders, etc.
-C

 
What if there were only ever two players on screen at a time?

And for the first one, maybe turrets that only activate when you fire a secondary?
"I only miss what I don't hit."
Show me something that beats 87 BF reds and I'll show you Hateful Lies!!!

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
I'm not sure whether you're referencing C or D, but I don't see D as being player-dependent - you could set something up for AI just as easily as a player.

C would run into problems if you tried to use it with AI because the AI obviously isn't set up to handle multiple animations or mecha sprites. But if it could somehow work with ordinary commands and you could get it working with multiplayer, the method I described wouldn't have any problems with multiplayer. Though I should note that it would probably be horribly inefficient, at worst - at best it wouldn't be much slower than drawing the entire mecha ship at once. The ambiguity lies in how much overhead using the multiple ships would add.

You could also put together some kind of mecha model with invisible, collideable args, legs, etc and then do all the rendering with the scripting renderModel. This would prevent the overhead of having several ships per mecha. Again, there's some ambiguity how well this would function with several mecha at once, but your worst case would be that you'd have the same slowdown as drawing X parts as you would as drawing X ships, and the best case scenario is that it doesn't take very long to skip over the non-showing parts and so it doesn't take any longer than rendering them all at once.

The chief difficulty might lie in doing all the animations with few enough calculations that it didn't slow things down. This is all theoretical at this point - nobody's tried to do it before - so I can't guarantee what problems you would or wouldn't run into.
-C