Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: blowfish on June 06, 2008, 06:18:28 pm
-
Yes, another feature request :rolleyes:. CBAnims seem rather cumbersome as it is, so I was thinking that it would be cool if you could just specify a ship or weapon (a weapon with a model) to use as a CBAnim. It would basically be the same as the tech room or the loadout screen, where you have the model rotating. I would try to do this myself, but I know next to nothing about graphics and something tells me that there is more to it than draw_model_rotating() ... :shaking:
So is this possible?
-
Actually, there might not be. draw_model_rotating is a function I made to replace the techroom ship and weapon selection ANIs with rotating models. If you could check for a POF extension, then have it load the model rather than the ANI, and then check if the model variable was set and the ANI variable wasn't, you should be able to toss the function in and it'll work how you'd expect. You should probably call model_unload for each stage the model is used in (Basically every time you call model_load) once you're done with the command screen. There's probably an existing function to do that for ANIs.
The only unusual thing about the function is the rotation_buffer. That's a pointer to a float that you should define as a static variable in the function that calls draw_model_rotating. That lets the function save the position of the ship for each frame for that instance of rotation (otherwise it would just sit there, because the function has no other way of telling where it's being called from).
-
So basically this is what I would need?:
When the stage is initialized:
-load the model
-page in the textures
For every frame of the stage:
-call draw_model_rotating (what to the four integer coords represent?)
When the stage is done:
-unload the model
----
And there is no additional graphics setup that has to be done beforehand?
-
Noop, it's all contained in the function (see g3_start_frame/g3_end_frame). The four integer coords represent the upper left corner of the model 'window', and the lower right corner of the model 'window'.
-
Looks like this may actually be doable...
-
Is this a mod requirement, or one of those things you just thought of but never plan to use?
-
I'm not entirely sure ... I do have my own mod in the works (who doesn't :P), but I'm not sure if I would use this feature or not. So basically it is not a mod requirement. Why do you ask?
BTW - I am working on coding this.
-
For some of us less code inclined, what benefit will it server or to phrase it better...
what are some examples of the effect this could have?
-
Basically, for the command brief, instead of the animation, you could specify a ship or weapon model, and it would rotate, like in the techroom. Saves you the trouble of creating an ANI yourself (a good amount of work).
-
I would probably use it in one of my mods. Would also be useful for INFA, cause we only have static anis right now.
-
Would also reduce the workload / or increase the "polished" feel of any new mods that decided to make use of this feature. Right?
-
I think SWC would use it too, as GalEmp just made us some very pretty high-detailed meshes for our secondaries, we could use them there as well.
-
Also we wouldn't need to keep making new .anis when high-poly models come out.
-
If you can supply a background image/ani for the model to rotate on top of it could look pretty good in fact.
-
I would certainly make use of it, too. :)
-
I can see as how it would make the job of the other modders much easier too. No more need to either tediously make CBanims or reuse old ones.
-
I never knew primary weapons had models :rolleyes: .We would have to create a model for primary weapons ?
for secondary weapon it already exist (see use 3dmodel/ship selection in your launcher)
but this feature would be nice for command briefing though (but not for primary weapons).
-
I'm assuming he's aware primaries don't have models, and probably intended this more for secondaries or for anyone wanting to make a model for a primary, in fact you'd probably be defining the model manually and wouldn't even need it to be tied to the weapon directly, it could just be a separate model altogether. So no need to roll your eyes :P
Also, that's what a CBAnim is. Did you read the post? He specifically mentions it would be like the loadout screens.
-
sorry I didn't mean to say this feature already exist, I just wanted to show that we could use the feature used by the loadout screen. I don't think it's very hard to call the source code used by loadout screen for command briefing.
maybe something separated from the game who would create a ani file and then use iy in your vp file. (I'm interessted I'll check the source code for this)
-
sorry I didn't mean to say this feature already exist, I just wanted to show that we could use the feature used by the loadout screen. I don't think it's very hard to call the source code used by loadout screen for command briefing.
maybe something separated from the game who would create a ani file and then use iy in your vp file. (I'm interessted I'll check the source code for this)
Porting the code over actually isn't that hard to do. WMC made a function that gets the model to rotate (the draw_model_rotating thing we were talking about earlier) which handles all of the graphics stuff (the hard part).
Since there seems to be demand for this, I'll try to get it working this week.
-
This is one of those dragons den moments. One of those things i wished i'd thought of. Any chance of using the briefing icons system too?
-
I don't think it's very hard to call the source code used by loadout screen for command briefing.
Really? This is excellent news. I'm so glad someone took the time to examine the code and evaluate the difficulty level for us. Do you think you could send us a feature patch while you're at it?
-
I got it to stop screwing up the interface, thanks to gr_reset_clip (you forgot to tell me about this WMC :shaking:), but now it just doesn't do anything. I've just been testing with fighter01.pof, but it displays nothing out of the ordinary...
-
I don't think it's very hard to call the source code used by loadout screen for command briefing.
Really? This is excellent news. I'm so glad someone took the time to examine the code and evaluate the difficulty level for us. Do you think you could send us a feature patch while you're at it?
Well he did say he'd check the source code so he might not actually be doing the talking out his hat that most people do when they say something is easy. I wouldn't bet money on it though.
-
Here's a quick working patch; I recommend you apply dmr_fix.diff to your codebase. This puts gr_reset_clip into draw_rotating_model, where it should be, and fixes a minor problem where the function assumed it was rendering a missile if you didn't specify a closeup pos. It'll change three files but you'll have to revise your missioncmdbrief.cpp to take into account the gr_reset_clip change (ie just get rid of the one you added).
The other patch is for a quick working test I made.
[attachment deleted by admin]
-
I never learned how to incorporate a diff into your local source :nervous: how do you do it?
-
TortoiseSVN includes a patch application utility. If you have it installed, you right-click on the file, go to the TortoiseSVN menu, and then go to 'apply patch' and select your missionui directory.
-
What if I am not using windows and 'svn patch' is not available?
-
Then I don't know. :p Or at least I can't give you any definite solutions. There is a patch utility under Linux, that might be available under Mac OS X, that might be able to use the diff files.
If nothing else, you can always crack open the diff files and do the changes manually; there's not more than ~20-30 lines changed. "+" indicates a line that was added, "-" indicates a line that was removed. Neither +/- indicates that the line was not changed, and can be used to locate where the change was made. The line numbers above each 'chunk' indicate where that change occurred, although since you are changing the relative position of things in the file, the line number may not be accurate, and I generally avoid using it when patching manually. (It might come in handy for duplicate code sections, though)
-
I know how to read a diff file!
-
Thanks for the code, WMC. This works now. I should be able to do the rest pretty easily ;)
-
:D
-
What? I'm SCP now? Anyway:
Command, those coordinates you gave us are bogus. Its x, y, width, height, not corner, other corner ;) Spent a lot of tim trying to figure that out...
-
You have access to the internal forum, by recommendation. :) Check it out.
-
Well, after wrestling with Console, making many stupid mistakes, and discovering that I had the wrong coordinates, I finally got this finished. I've tested it a bunch, but whoever commits it should probably look it over and you might want to test it a little yourself. Also, someone will have to add this to FRED, as I can't. So basically how it works is in the mission, after the ani filename, it looks for "+Ship Class:", "+Weapon Class:", or "+Model Name:" (only one of the three). Defining a ship or weapon sets some special behavior. For ships, it uses the table-defined closeup position and zoom values. For weapons, it uses the tech model if available, if not it uses the regular POF file (unless the weapon is a primary - flak behaves weirdly), assumed to be a missile so that the center is set up correctly. I removed the 1.7 multiplier from the closeup zoom, because I thought it looked better that way in a longer rectangle. I guess that's pretty much it. So here's the diff.
And BTW, we should really be able to attach diff files.
EDIT: Darn! Forgot to add code to deal with when a ship class doesn't exist. Appears to be a fatal error.
EDIT2: Fixed and reuploaded. Forgot to mention that using a ship causes a slight, but noticeable pause when initializing a briefing stage.
EDIT3: And forgot to thank WMCoolmon for showing me how to get this to work in the first place! How could I forget that?
[attachment deleted by admin]
-
Actually I think it's better to use an archive than a plain text file attachment anyway. I just prefer having those types of things archived, even if it's not compressed.