Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Wanderer on April 13, 2008, 04:52:18 pm
-
So i finally got around it and placed tried fooling around the FS source with Visual C++ 2008 Express Edition...
And - big thanks to karajorma who got me started - something i made...
Now first it is supposed to make an option for making bomber turrets smarter.. ie. to make turrets mounted on fighters and bombers to target freely like normal turrets instead of keeping the one ship has targeted as the turrets target. Flying 'Slaying the Ravana' with Medusa and testing the new flag both on and off and keeping close eye on the turret and what the turret is targeting at should probably explain what i mean. With the new flag off (as default on bombers is on) on the turrets actual protect the bombers and while on retail setting the turrets are as useless as usual.
Also it - assuming i got it right - moves small ship, big ship and huge ship flags from ship info to ship type info and makes then along the bomber turret thing as an option for the objecttypes.tbl.
link to zipped patch file (http://koti.mbnet.fi/vekkup/test_patch.7z)
As for the names of the flags... if you have better ideas please change them... i just wrote something descriptive there
-
Nice! Looks good. I've always wanted this feature, but shied away from coding it thinking it'd be a lot harder. WCSaga in particular will like this, but obviously anyone with fighter turrets would too. I think the original campaigns should have been this way.
The objecttypes.tbl thing sounds great... don't have a use for this myself, but more potential for TC type projects is always nice. :yes: Unfortunately I think your thread title has made non coders ignore this...
Oh, and welcome to the dark side. We shall watch your career with great interest.</Palpatine voice>:D
Heh, yeah naming the flags gets me too... for example, what would you suggest naming a flag that makes beams no longer whack in a baseball bat manner but instead like a hose? ;)
-
Heh, yeah naming the flags gets me too... for example, what would you suggest naming a flag that makes beams no longer whack in a baseball bat manner but instead like a hose? ;)
"soft whack" perhaps.
-
Thwack?
Limp Hit?
Soft Smack?
Smush?
Thump or Thud?
Whap or Fwap?
Bang or Bam?
Ram?
-
I was unclear -- it's more to do with the direction than the amount. So more 'baseball bat vs pool cue'. Let's just say, negative numbers results in a working tractor beam ;7
Rofl, didn't mean to derail things that quickly. This is quite a big patch. Seems to work so far. I'd like the more senior SCP guys to take a look. If possible could you make the turret flag feature as a separate patch? That one would be more likely to be able to commit right away.
-
Well.. sure... That should be it.. That is it is still in the big patch file as well
EDIT... and the tbm to disable the retail method of getting targets for bomber and fighter turrets..
sst-obt.tbm
#Ship types
$Name: Fighter
+nocreate
$Use Small Ship Turrets: NO
$Name: Bomber
+nocreate
$Use Small Ship Turrets: NO
#End
[attachment deleted by ninja]
-
Also it - assuming i got it right - moves small ship, big ship and huge ship flags from ship info to ship type info and makes then along the bomber turret thing as an option for the objecttypes.tbl.
Woah, woah, woah.
The entire point of objecttypes.tbl was to get rid of those flags. They cause a lot of hardcoded behavior that needs to be broken down into individual options so that mods can specify it individually, and so that it's clear what's actually happening. I broke a lot of those size-dependent options off of the flags and moved them into objecttypes.tbl. From a design perspective, I'm not sure if it's a step forwards or a step backwards. In the short term, it gives the modders a little more choice as they can select from three super-shiptypes.
In the long term, it risks halting development of objecttypes.tbl and permanently retarding its growth, possibly stopping it entirely. Frankly, it scares me. By making those flags accessible to modders rather than simply an internal code thing, you would force every single version of the SCP to continue to support those flags. That means that every single toggle that's in there now for those flags would have to stay there. If somebody ever gets around to making those options explicit in objecttypes.tbl, every single option, every single value, would have to have code implemented to handle precedence for the flag.
For example, what happens if somebody explicitly specifies a value in one modular table, and then a modular table after that specifies a "big ship" flag? Do you override the explicitly specified variable in the first modular table with the implicit specification in the second modular table? That's the easiest method from a coding POV, but it's a confusing result for the modder.
Any time you make something from the codebase explicit in a table or other modder-accessible thing, you force every single version of the SCP to be consistent with the effects of that. You can't just port variables to a table without any thought to how it's going to effect things if somebody else wants to do something more than you, or improve on the work you've done, unless you just don't care or don't want to allow for that possibility. It's a very daunting task, but it's generally a lot better to provide a lot of specific options rather than very vague ones. If you have an option like "Max Visible Fog Distance", you know what the modder wants and you can play around with ways to do that. You can add whatever gimmicks you need to account for new materials and so on, because you know that the modder wants the ship to be visible at that distance. If the modder just says that the ship is a "big ship", there's no inherent implication of how far away the ship should be visible in fog. You also don't know if the modder is using the flag because they think the ship is a big ship, or because one of the options is so important that they're using the flag inaccurately to get one specific effect.
There's also the matter of move stuff from ship_info to ship_type_info. That should, generally speaking, never ever be done. In this particular case, it doesn't really affect anything since the options were dependent on ship types anyway. However, in general, all this does is reduce modders' choice in what ships should do. In many cases, options that were originally ship type dependent should be moved to ships.tbl because somebody might want to make them different for ships of the same class. Remember that ships of the same class may not necessarily be of the same species, so the technology behind them may be totally different. I've heard the objection that it creates more work for table modders, but IMHO that's not true in the long run. When you factor in managing precedence not just between modular tables, but also between different types of tables, it's a lot better to proactively avoid the precedence hell. It's also a lot easier to code the feature once than to have to recode it later on, when somebody wants the option on a per-shipclass basis, and also take into account that you've already coded it once before.
Speaking less formally, I have little patience for people who are willing to risk all of that rather than have to paste one line in a table 15-16 times. :rolleyes: I wish any coding were that easy.
And, like I said, it goes against the original intent of ship types, which was to get rid of all those designations which make sense for the Freespace universe, using the original game's ships, and make it into something that mods could use to start from scratch to define their own ship types with their own characteristics.
Notes on the Implementation
Three different boolean options are used to identify a ship as big, small, or huge. When you're working with a set of a type of designation, it's generally better to just make that a single variable. There's no reason to have three booleans, it wastes memory. Also, a ship can't be small and huge at the same time, at least not with the conventional english definition of those terms. :p
Several places you use:
Ship_types[Ship_info[Ships[objp->instance].ship_info_index].class_type].ship_boolsFor me this is a red flag, because there are three indices going on. I think I did this before, but it wasn't really a great idea then. It would be more appropriate to make a function like this:
ship_type_info *ship_get_type(object *objp)
{
Assert(objp != NULL);
Assert(objp->type == OBJ_SHIP);
Assert(objp->instance > -1);
Assert(Ships[objp->instance].ship_info_index > -1);
Assert(Ship_info[Ships[objp->instance].ship_info_index].class_type > -1);
return &Ship_types[Ship_types[Ship_info[Ships[objp->instance].ship_info_index].class_type];
}
which cleans up the code everywhere that the indexing is made, and lets you check all of those assumptions automatically in a debug build.
I would also change "Use small ship turrets" into a "Turrets prioritize ship target" option, or something shorter along those lines.
Also, at certain points you changed a "enemy_sip_flags" to ship type bools. For that kind of thing, the variable name should be changed, as it's no longer ship info flags. Somebody else might get confused by that bit of code and think that ship_info flags were being referenced, put in some checks for SIF_ flags, and get unpredictable behavior.
Sorry that got pretty long.
-
Yeah.. true..
Woah, woah, woah.
The entire point of objecttypes.tbl was to get rid of those flags. They cause a lot of hardcoded behavior that needs to be broken down into individual options so that mods can specify it individually, and so that it's clear what's actually happening. I broke a lot of those size-dependent options off of the flags and moved them into objecttypes.tbl. From a design perspective, I'm not sure if it's a step forwards or a step backwards. In the short term, it gives the modders a little more choice as they can select from three super-shiptypes.
In the long term, it risks halting development of objecttypes.tbl and permanently retarding its growth, possibly stopping it entirely. Frankly, it scares me. By making those flags accessible to modders rather than simply an internal code thing, you would force every single version of the SCP to continue to support those flags. That means that every single toggle that's in there now for those flags would have to stay there. If somebody ever gets around to making those options explicit in objecttypes.tbl, every single option, every single value, would have to have code implemented to handle precedence for the flag.
For example, what happens if somebody explicitly specifies a value in one modular table, and then a modular table after that specifies a "big ship" flag? Do you override the explicitly specified variable in the first modular table with the implicit specification in the second modular table? That's the easiest method from a coding POV, but it's a confusing result for the modder.
Any time you make something from the codebase explicit in a table or other modder-accessible thing, you force every single version of the SCP to be consistent with the effects of that. You can't just port variables to a table without any thought to how it's going to effect things if somebody else wants to do something more than you, or improve on the work you've done, unless you just don't care or don't want to allow for that possibility. It's a very daunting task, but it's generally a lot better to provide a lot of specific options rather than very vague ones. If you have an option like "Max Visible Fog Distance", you know what the modder wants and you can play around with ways to do that. You can add whatever gimmicks you need to account for new materials and so on, because you know that the modder wants the ship to be visible at that distance. If the modder just says that the ship is a "big ship", there's no inherent implication of how far away the ship should be visible in fog. You also don't know if the modder is using the flag because they think the ship is a big ship, or because one of the options is so important that they're using the flag inaccurately to get one specific effect.
There's also the matter of move stuff from ship_info to ship_type_info. That should, generally speaking, never ever be done. In this particular case, it doesn't really affect anything since the options were dependent on ship types anyway. However, in general, all this does is reduce modders' choice in what ships should do. In many cases, options that were originally ship type dependent should be moved to ships.tbl because somebody might want to make them different for ships of the same class. Remember that ships of the same class may not necessarily be of the same species, so the technology behind them may be totally different. I've heard the objection that it creates more work for table modders, but IMHO that's not true in the long run. When you factor in managing precedence not just between modular tables, but also between different types of tables, it's a lot better to proactively avoid the precedence hell. It's also a lot easier to code the feature once than to have to recode it later on, when somebody wants the option on a per-shipclass basis, and also take into account that you've already coded it once before.
Speaking less formally, I have little patience for people who are willing to risk all of that rather than have to paste one line in a table 15-16 times. I wish any coding were that easy.
Though as it is ATM the hard coded options under small, big and large ships are completely inaccessible for new objecttypes.tbl types... which is why i thought that giving at least a global access to the said options would be preferable top having no access at all. Besides i sorta assumed that majority of the options that could be broken away from the 'super shiptypes' would more or less still remain as things controlled by objecttypes.tbl so the references to the ship_bools (or to ship_type_info in general) would already be there making it supposedly easier to add the new flags/options.
Of course if objecttypes.tbl is in such shape that its usage its not encouraged then i understand that. And i dont mean as in bad shape but as 'under construction' shape.
As for why i chose to move those to objecttypes instead of ship types... well... I was more thinking like adding new objecttype along the lines 'Alien Capship' than making those ship table options.. Mainly because the super shiptypes themselves are directly derived from the ship types. But sure now that you mention it there is good amount of logic behind the idea of putting them as separate ship flags as well.
And, like I said, it goes against the original intent of ship types, which was to get rid of all those designations which make sense for the Freespace universe, using the original game's ships, and make it into something that mods could use to start from scratch to define their own ship types with their own characteristics.
As it was briefly discussed earlier the currrent functionality of objecttypes - unless multiple ship types are defined for the said ship class - is severely limited by the hard coded SIF_<ship_type> and SIF_<ship_size> flags.
Notes on the Implementation
Three different boolean options are used to identify a ship as big, small, or huge. When you're working with a set of a type of designation, it's generally better to just make that a single variable. There's no reason to have three booleans, it wastes memory. Also, a ship can't be small and huge at the same time, at least not with the conventional english definition of those terms. :p
Well... true though i couldn't see any limitation in code for that and thought it was left like that for some reason....
Several places you use:
Ship_types[Ship_info[Ships[objp->instance].ship_info_index].class_type].ship_boolsFor me this is a red flag, because there are three indices going on. I think I did this before, but it wasn't really a great idea then. It would be more appropriate to make a function like this:
ship_type_info *ship_get_type(object *objp)
{
Assert(objp != NULL);
Assert(objp->type == OBJ_SHIP);
Assert(objp->instance > -1);
Assert(Ships[objp->instance].ship_info_index > -1);
Assert(Ship_info[Ships[objp->instance].ship_info_index].class_type > -1);
return &Ship_types[Ship_types[Ship_info[Ships[objp->instance].ship_info_index].class_type];
}
which cleans up the code everywhere that the indexing is made, and lets you check all of those assumptions automatically in a debug build.
I thought of writing similarish function (though with less asserts...) but after i took a look how things were handled in the code there seemed to rather interesting amount of variety in methods getting to the ship flags so i dropped the idea of making such function.
I would also change "Use small ship turrets" into a "Turrets prioritize ship target" option, or something shorter along those lines.
I haven't got rights to write to SVN so i'll leave the actual naming of that option to some one who can - should there be such a person who wants to add that option - and who is actually native English speaker...
Also, at certain points you changed a "enemy_sip_flags" to ship type bools. For that kind of thing, the variable name should be changed, as it's no longer ship info flags. Somebody else might get confused by that bit of code and think that ship_info flags were being referenced, put in some checks for SIF_ flags, and get unpredictable behavior.
Fair enough...
EDIT... That said i still hope that atleast the small ship turret thing - which ever it would named as - would get committed to the code as AFAIK (and by looking at the code) that way the turrets function in bombers in FS2 was not the way they were intended to function.
-
Some other things i fooled around with...
Iffs... Some little questions first... Assuming it was in one way or another possible should there be possibility to set alternate IFF colors within the set IFF entity (entity in this case refers to the things like 'Friendly' etc). I wrote something that actually accomplishes that but problem is that it was a) very poorly constructed, b) relied once again on ship types, c) alternate iff colors might be something fredders might want to set on their own (and my version certainly wasnt such). So i take any alternate iff colors thing should preferably have options in fred and ships table instead of iff_defs and objecttypes?
Then a couple of things that were - well seemingly - somewhat within my grasp. Not sure how much use these would in general have.. but i guess some people might prefer other than hard coded colors for asteroid of message HUD frames, or to the radar blips marking cargo, warping ships, bombs etc. Besides some one had reversed the older 'is bright' boolean at some point so that missile etc. were actually drawn brighter if they were further away even though with ships it worked like advertised so this patch (iff_patch_1and2) should fix that bug as well. And it also gives option to use similar dimmed color scaling system with those blips as the one used with ships.
As for names of the flags.. dunno..
EDIT: Hmm.. Seems like there is lack of interest in this kinds of things... Oh well.. i'll post a single diff yet and trouble people no more with code stuff then...
The alt_iff_patch enables alternate iff colours for the ships within a set IFF entity. As of now it is set via ships.tbl with additional possibility of setting individual settings via SEXPS (latter is untested as AFAIK express editions do not have MFC). But given the amount of trouble i had with figuring out why support ships had wrong color i suppose it works too... It doesnt work with all possible things - like escort list color is still the main IFF color - as that would probably just have complicated things too much. So it should make Wing Commanderish alternate IFF color capships possible. Hopefully got the sexps sorted out too
[attachment deleted by ninja]
-
Some other things i fooled around with...
Iffs... Some little questions first... Assuming it was in one way or another possible should there be possibility to set alternate IFF colors within the set IFF entity (entity in this case refers to the things like 'Friendly' etc). I wrote something that actually accomplishes that but problem is that it was a) very poorly constructed, b) relied once again on ship types, c) alternate iff colors might be something fredders might want to set on their own (and my version certainly wasnt such). So i take any alternate iff colors thing should preferably have options in fred and ships table instead of iff_defs and objecttypes?
Dunno. Since the underlying assumption is that the targeting computers add the IFF colors, I'm inclined to say that IFF colors should actually be a separate thing altogether. For example,
#IFF Colors
$Species: Terran
;;When flying a Terran ship, you see the following colors:
;;Green for friendly ships
$Color: 0 255 0
$Team Status: Friendly
$Type: Ship
;;Red for hostile ships
$Color: 255 0 0
$Team Status: Hostile
$Object Type: Ship
;;Orange for bombs
$Color: 255 64 0
$Team Status: Hostile
$Object Type: Weapon
$Flags: "bomb"
$Species: Vasudan
;;When flying a Vasudan ship, you see the following colors:
;;Yellow for friendly ships
$Color: 255 255 0
$Team Status: Friendly
$Object Type: Ship
;;etc etc
$Ship Class: GVA Setekh
;;When flying a GVA Setekh, you see the following colors:
;;Blue for friendly Terran ships
$Color: 0 0 255
$Team Status: Friendly
$Species: Terran
$Object Type: Ship
;;Yellow for friendly Vasudan ships
$Color: 255 255 0
$Team Status: Friendly
$Species: Vasudan
$Object Type: Ship
;;Pink for hostile stealth ships
$Color: 255 0 255
$Team Status: Hostile
$Object Type: Ship
$Flags: "stealth"
#End
Something like that would give modders a lot of flexibility without a lot of extra gymnastics. Syntax is based on conditional scripting.
Then a couple of things that were - well seemingly - somewhat within my grasp. Not sure how much use these would in general have.. but i guess some people might prefer other than hard coded colors for asteroid of message HUD frames, or to the radar blips marking cargo, warping ships, bombs etc. Besides some one had reversed the older 'is bright' boolean at some point so that missile etc. were actually drawn brighter if they were further away even though with ships it worked like advertised so this patch (iff_patch_1and2) should fix that bug as well. And it also gives option to use similar dimmed color scaling system with those blips as the one used with ships.
As for names of the flags.. dunno..
See above & that does sound like a bug that you fixed.
EDIT: Hmm.. Seems like there is lack of interest in this kinds of things... Oh well.. i'll post a single diff yet and trouble people no more with code stuff then...
The alt_iff_patch enables alternate iff colours for the ships within a set IFF entity. As of now it is set via ships.tbl with additional possibility of setting individual settings via SEXPS (latter is untested as AFAIK express editions do not have MFC). But given the amount of trouble i had with figuring out why support ships had wrong color i suppose it works too... It doesnt work with all possible things - like escort list color is still the main IFF color - as that would probably just have complicated things too much. So it should make Wing Commanderish alternate IFF color capships possible. Hopefully got the sexps sorted out too
I suppose I'm not a big fan of IFF colors in ships.tbl since, again, they're supposed to be generated by a ship's targeting computer; it also makes sense for them to change based on ship status, and especially allegiance. However, I think it sounds like what you've implemented follows the basic pattern of how IFF has been done already.
Lack of posting doesn't always equate to lack of interest, either.
-
Though as it is ATM the hard coded options under small, big and large ships are completely inaccessible for new objecttypes.tbl types... which is why i thought that giving at least a global access to the said options would be preferable top having no access at all. Besides i sorta assumed that majority of the options that could be broken away from the 'super shiptypes' would more or less still remain as things controlled by objecttypes.tbl so the references to the ship_bools (or to ship_type_info in general) would already be there making it supposedly easier to add the new flags/options.
Of course if objecttypes.tbl is in such shape that its usage its not encouraged then i understand that. And i dont mean as in bad shape but as 'under construction' shape.
As for why i chose to move those to objecttypes instead of ship types... well... I was more thinking like adding new objecttype along the lines 'Alien Capship' than making those ship table options.. Mainly because the super shiptypes themselves are directly derived from the ship types. But sure now that you mention it there is good amount of logic behind the idea of putting them as separate ship flags as well.
Hmm. Indirectly you raise a good point, you do have to keep the SIF_* shiptype defines around as-is, especially if somebody makes a gunship class or something that isn't specified in the defaults. It's something that deserves some thought on how to fix it - maybe establish some kind of multiple shiptype system with precedence - but ideally, I guess, objecttypes.tbl should be finished.
objecttypes.tbl is in the 'under construction' shape, but it's not actively being worked on by anyone AFAIK.
As it was briefly discussed earlier the currrent functionality of objecttypes - unless multiple ship types are defined for the said ship class - is severely limited by the hard coded SIF_<ship_type> and SIF_<ship_size> flags.
Yup. Multiple ship types is pretty much an unfortunate hack to allow objecttypes to be used in conjunction with the old system.
Well... true though i couldn't see any limitation in code for that and thought it was left like that for some reason....
I guess it's because :V: never had trouble with people defining something as both a corvette and the ship at the same time. I think I remember a discussion sometime about code to limit things to a ship type, but regardless, I think the general assumption up til now is that a ship only has one type. Since big/small/huge were all supertypes of specific types, you could never have more than one supertype as long as you had only one type.
I thought of writing similarish function (though with less asserts...) but after i took a look how things were handled in the code there seemed to rather interesting amount of variety in methods getting to the ship flags so i dropped the idea of making such function.
Maybe, it's still rather alarming to me when I look at it since an array indexing error throws one of those "memory access violation" or "Send error report to Microsoft" things that doesn't help debugging at all.
EDIT... That said i still hope that atleast the small ship turret thing - which ever it would named as - would get committed to the code as AFAIK (and by looking at the code) that way the turrets function in bombers in FS2 was not the way they were intended to function.
-
I suppose I'm not a big fan of IFF colors in ships.tbl since, again, they're supposed to be generated by a ship's targeting computer; it also makes sense for them to change based on ship status, and especially allegiance. However, I think it sounds like what you've implemented follows the basic pattern of how IFF has been done already.
Well.. i did implement it via multidimensional array of integers so yeah. That is there is the observer vs observed check to get to the color - so if IFF changes so will the color (and the alternate color). As for why to ships.tbl.. to give possibility of setting IFF color per ship class basis if needed and - with the untested sexp thing - to enable ship specific IFF color which can be changed during the missions if needed. Besides it now gives a objp to the section where the color is actually handled so more complex methods should now be rather simple to implement.
EDIT: Karajorma pointed out that it might be smarter to use IFF instead of string as fred input argument/identifier... So.. making yet another patch...
[attachment deleted by ninja]
-
Tbl? What about SEXPs and ship options since it's set to "NO" by default?
-
Um? Care to ellaborate?
-
Well they should be easier to handle from Editors---> Mission Specs and/or via SEXPs.
-
Well.. In some case alternate color (or colour :P ) might be preferable to have been set as default for certain ships so that you wouldnt have to go through all the sexps for every ship for every mission to get the colors on... And actually i did write a sexp for it as well.
However as i still lack the necessary MFC libs i couldn't compile fred builds and so couldn't really make it into the editor or even test that the sexp would actually work like it should...
-
What about both thing? Table entry and SEXPs/settings to trigger/deactivate?
-
Well.. i think this might answer some questions...
7z archive (http://koti.mbnet.fi/vekkup/FS2/iff_and_blip.7z) with the build and example table files with references. And the iff color thing is also made to sexp but as it would need notepaddling to make it work i left the instructions out so that it wouldnt even be attempted. Basically (from the attachments posted on this page) alt_iff_patch_2 and iff_patch_1and2 on top of fresh SVN build.
EDIT: teaser of the next thing... Ingame screenie without any post editing.
(http://i30.tinypic.com/30iylh4.jpg)
-
I see custom blips on the radar.
...y'know what would be awesome? Bringing back the solid-fill FS1 briefing icons and using those for the blips. :D
-
DRADIS contact!
very nice, now all we need is a combo with that, working render-to-texture + cockpits, and the DRADIS Whoosh
-
Updated the 7zip archive a couple posts above. Now there should be a single mission with ships changing their iff color, the example table files, both fs_d and fred_d (thanks to Karajorma) and the actual combined (and slightly updated) patch. But please do note that this stuff is not in SVN.
As for the (d)radar.. i'll try making something up that could be tested.
-
Wow that would be awesome for Dradis!
-
Dradis, true, but almost every universe has its unique sensor technology, and this will help them achieve that uniqueness.
-
For those who might want to test some sort of option for the radar image... Now then... I haven't enabled any size limitations in the linked set and also my attempt to get scaling to work didnt work out as i hoped it would despite the help i got. So if you try it out and do not just want to fool around do not make the images any larger than 32x32 or they will clutter the radar screen. There are couple of small dds images i made from screenshots of the nBSG series which give some idea how it could look like.
The bad thing is that i sort of run out of ideas on what to do with targeted blip and decided simple to draw it twice which is generally a bad choice so that method will most likely keep changing a bit more still.
radar_image.7z (http://koti.mbnet.fi/vekkup/FS2/radar_image.7z)
EDIT: And if you try this or the iff thing out please comment...
-
Ah, lovely. I'll have to whip up something for this.
Just for reference- these are single-frame images, not ANIs. Are they paletted; if not, how are they colored by IFF? Do they use the alpha-channel or just intensity blending?
-
Single frame - at least for now. The images i used were standard greyscaled DDS images with transparent background (ie DXT5) - mainly due the reason as i needed larger transparent versions of those images elsewhere... So iff status of the target decides the color and the current target as well as weapon range decide the actual alpha value of the blip.
-
Do they scale appropriately with the resolution at least, like the radar itself, or at lower resolutions will the icons appear much larger?
-
DRADIS contact!
very nice, now all we need is a combo with that, working render-to-texture + cockpits, and the DRADIS Whoosh
they already work if you want to script em :D
-
So far I'm getting this error when I don't use DDS:
Assert: !(flags & BMP_AABITMAP)
File: bmpman.cpp
Line: 2265
Call stack:
(etc.)
And this error randomly during missions, using retail data files.
Assert: wingp->ship_index[j] != -1
File: aigoals.cpp
Line: 836
Call stack:
(etc.)
-
K, I haven't tried these out yet as the debug build is still giving me errors, but here they are. There's also a TBM with them assigned appropriately. (If your mod corrects the SSG Rahu to the SG Rahu, remember to edit the tbm accordingly.)
I've tried to pad the margins of a few things to have the cargo icon sit in the freighter icon's docking bay, and have the support ship stick to the bottom of the fighter and bomber icons. This sort of depends upon them both being in the same location, so it may not work from up close, but any dockees more than a few klicks away should.
Wanderer, if you can get these to function properly, and your patch doesn't break anything, you can commit your changes and we'll include this in the next MVP release.
FS1-style Radar Icons (http://pjfoliver.googlepages.com/radaricons.zip)
(http://pjfoliver.googlepages.com/radaricons.gif)
-
Well... i cant commit anything to SVN.. i can just write something - usually with assistance of more experienced coders - and hope it would be accepted to SVN in one form or another...
Also my main rig (with the code patch, working compiler etc. etc.) is out of action for undefined period of time. I'll test those once i get the computer back up and running though.
-
Just to clarify, they go in the Interface folder, correct? And do I need to have 3D Radar enabled?
-
THIS
IS
AWESOME
(http://pjfoliver.googlepages.com/radarwithicons.gif)
Download the link from my previous post, put the DDS files in Interface and the TBM in Tables, then run the included build.
This is one of the greatest tactical advantages Freespace Open has ever given us! It's increased my battlefield awareness a hundredfold!
This MUST go into the next MVP release. It HAS to!
My only gripe, Wanderer, is that it doesn't work with the 3D orb radar. Personally I prefer the 2D radar, but it has to work with both.
-
Holy frak that looks nice! Yoink!
I suspect the files should be in hud instead of interface, but it seems to work so...
I'm working on settings in hud_gauges.tbl to allow the radar to use a bigger area, so that'll be nice too :)
Edit: Admittedly I don't really understand how this area of the code works... but where do you page in the used bitmaps? Or does that matter?
-
Well i decided to start doing it originally for 2D radar only though i believe it could be made to work with 3d as well.
As for paging in bitmaps.. I do that while it is parsing the file... and then pass only the index forward from it. This might be wasteful assuming if there are several instances that particular option is parsed (multiple tbm passes) so it might need some cleanup option or then the bitmap(s) ought to be loaded only after the whole parsing thing is over. Though assuming these images are 32 x 32 or smaller the whole shebang for all allowed ships 130 is about on the same level as memory needed for single frame of the glow animation on a shivan ship.
if (optional_string("$Radar Image 2D:"))
{
stuff_string(name_tmp, F_NAME, NAME_LENGTH);
sip->radar_image_2d_idx = bm_load(name_tmp);
}
And as for the dds files... i placed mine into effects directory but it shouldnt really matter as long as it goes to any of the directories that cfile allows for dds files.
I'm still tackling the scaling issue as i got the scaling image larger working thanks to the help from taylor but scaling them smaller remains something i have not yet figured out. That i can scale them smaller but at the same time i scale the 'canvas' (or what ever you call the are area drawn on screen) smaller and this causes the scaled down images first (as they approach the lower edge of the screen) be only partially drawn (as if part of the image was over the edge of the screen) or disappear totally (ie. like image drawn totally of the screen).
-
Aha, missed that line. There it is. Yeah that makes sense about the size. I'm sure you could use DXT1a without mipmaps, if you wanted to be really stingy.
I'm liking this feature a lot and plan to help commit it for you soon. I think a slightly better place for the entry in the ship table would be right under $Shield_icon , what do you guys think? The 3D radar would be nice, but it probably needs the scaling support because of how the dots get bigger when they're 'closer' to your 'eyes'. Not sure how good that'll look when we're dealing with this size.
Very nice art Galemp. I particularly like how you got the cargo to line up with the freighters. :yes: And wow you're right this makes a HUGE difference in battlefield awareness... especially with a bigger radar area :D (WIP) I almost think the special 'big' ships icons should be even bigger (Colossus, Lucifer, Sathanis, Hades, etc)
-
I agree, now that I've figured out the 32x32 size is a guideline rather than a fixed limit. I'd like to make the fighters/bombers/support ship smaller and the supercaps bigger, basing them on total pixel area instead of just the longest dimension. I'll be working on that today.
-
Really the scaling code needs to be what controls that, not the pixel size of the icon. I'm still wondering what happens with it when the screen res changes. I'll probably try it out tonight.
-
I'd rather have control over the absolute scale of the icon on-screen (scaling these guys up or down would be nasty) and have Z-drawing order and alpha-blending denote location, orientation and target.
-
This is brilliant. I would love to see this go into the MediaVPs.
-
I've made some slight adjustments to the icons. linky (http://pjfoliver.googlepages.com/radaricons2.zip) I fixed it!
The big ships are bigger, the small ships are smaller, and they all have a slight transparency in the fill so you can see what's behind them a bit better.
Wanderer, this only works with DDS files formatted as you specified. Anything else--even TGAs--causes a crash on load. 'Twould be nice if they had a little more support for other formats, maybe even EFFs.
-
Well.. i think i have sorted out the scaling thing by bumping the bottom and right clipping borders. It gives a scaling option so that you define the max of the images larger dimension and game then scales the image as needed.
As for controlling it via alpha blending.. that is difficult given certain blips have alpha 255 by default while iff blips have alpha of 240 or 176 depending if they are close up (or targeted in standard mode) or further away.
I also got the 3d radar images to work.. in a way.. problem is that i have yet to figure how to make the game use the 2D drawing color for the 3d objects (like the blip images) of the radar... which is not really made much simpler by the fact the game uses 'cheatish' method for drawing the spheres. Any ideas would be welcome...
As for the image file type problem... i'll take a look - though i wont promise anything..
-
Hm. Perhaps for the 3D radar (since it is 3D) you could render the lowest LOD of the ship being represented? There's code for the target view that will let you render it in wireframe using the IFF color.
If the artists have done their job properly it should only be an extra 20 polies for each ship in the mission, without texture mapping having to be rendered, and it would translate orientation as well as position. Again, your problem is with scaling, but perhaps you can scale them to a uniform value based on the model's radius then multiplying it by 0.5 or 1.5 for extra-small and extra-large ships.
This is all conjecture, though. I don't know if it's possible or even how it will look.
-
That wireframe was marvelous idea.. got to take a look at it immediately.
Hmm... it seems to use solid color filled lines.. so it wasnt that useful...
-
What would you want it to use?
-
It would be nice if I could play with this build, but I'm getting bull**** errors such as:
Warning: EFF: No frame images were found. EFF, SbeamAglow.eff, is invalid.
File: bmpman.cpp
Line: 1799
Call stack:
------------------------------------------------------------------
fs2_open_3_6_9d_radar.exe 00b2d025()
fs2_open_3_6_9d_radar.exe 008d9e2d()
fs2_open_3_6_9d_radar.exe 008e2660()
fs2_open_3_6_9d_radar.exe 0072dd92()
fs2_open_3_6_9d_radar.exe 0071994f()
fs2_open_3_6_9d_radar.exe 00719a81()
fs2_open_3_6_9d_radar.exe 00719c36()
fs2_open_3_6_9d_radar.exe 0072707e()
fs2_open_3_6_9d_radar.exe 0091764e()
fs2_open_3_6_9d_radar.exe 00725b92()
fs2_open_3_6_9d_radar.exe 00917cac()
fs2_open_3_6_9d_radar.exe 0072929c()
fs2_open_3_6_9d_radar.exe 0072952e()
fs2_open_3_6_9d_radar.exe 00c54e66()
fs2_open_3_6_9d_radar.exe 00c54cef()
------------------------------------------------------------------
...and endless errors about the GVF Serapis having a null moment of inertia and BFRed having more than 5 beam sections. :mad:
-
Those errors have absolutely nothing to do with the build or with the features that are shown here. Those are well known issues in the 3.6.10 beta mediavps. All builds (debug builds) should either report those errors / warnings (either as popups or just to the log file) or then you will encounter some odd behavior.
What would you want it to use?
Well i would like it to use the same bitmap image as the 2D radar does.. And it does that. Problem is that i haven't yet figured out how i should approach issue short of building whole new set of functions for it but then again i have still lot of things to try before that. And the issue was that the image is drawn as grey bitmap..
-
I was about to ask why Galemp posted a debug build. :wtf:
-
What else? Using release build only sweeps the problems under the carper (so to speak). The beamglow is still missing and the firing of BFred could still CTD the game not to mention the other problems.
Besides - unless some else used the patches and compiled a release build - the only build available is the debug build i compiled.
-
Removed until I can figure out where the DDS corruption is coming from.
What corruption is this?
Guessing here, but I wonder if the DXT compression plays havoc with such small art. You might experiment with u555 or u888. u1555 or u8888 if you need alpha. All are lossless.
Hey Cobra, does checking "Disable parse errors" on the Troubleshoot tab help?
-
I actually did try that. I still kept getting errors.
-
Yeah.. too small compressed DDS files will suffer from corruption, IIRC limit is 16x16 though i could be a tad wrong about that.
As for how you can fix the errors.. Use older mediavp set. There is a reason why the current release is tagged as beta
-
Oh shush, I know. :P
-
Here is something that is probably buggy but might just work out nicely... There is a slight clipping issue with upper edge of the 3d radar though which should be something that can most likely be fixed... radar_mk2.7z (http://koti.mbnet.fi/vekkup/FS2/radar_mk2.7z). It has scaling for images enabled - more or less.
-
Nice. I work more than usual today so I can't try it out, but the skimming of the code I did made sense.
I wonder... this might be a big project, but is there any chance you could apply somewhat the same technique (only the opposite :p) involving the grayscale images, to add an option for HUD ANIs to allow NON-grayscale? Does that make sense? Currently as you probably know, hud gauges are made in 16 color grayscale (a very particular palette too), and the game applies its own shading and coloring. The ability to turn some of that off for certain gauges and display a full-color ANI (or EFF set someday :nervous:) would be incredibly useful. WCSaga in particular would like it. If you're interested in trying this, I'll gladly help if I can.
-
The good news is, my new icons work wonderfully. The bad news is, I'm still getting the wing assert crash during missions, specifically Their Finest Hour. I'd focus on fixing that.
-
Hmm.. Yeah i get it too... Happens when 'Scorpio' wing loses all but the last ship (which is usually Scorpio 1)... I'll try to take a look at that.
EDIT: Well.. It ain't any of my doings - that is i get the same problem with unmodified SVN build. And it certainly is triggered when there is only a single member or the Scorpio flight remaining though this does not need to be Scorpio 1.
-
Hmm... the bombers and fighters icons are garbled for me... but that could be because they're smaller than 16. Padded it to 16 and it works, easily fixed.
Odd crash. Something to do with ai_maybe_add_form_goal. Somehow the remaining ship is not part of a wing or something. Wish I was better at understanding the debugger...
-
It may have something to do with the fact that the waves of the Scorpio wing arrive at that time as well. So there are then essentially 5 Scorpio ships belonging to wing of four ships...
EDIT... Do you mean the fighter and bomber icon images were garbled when they were set via the table option to have size of 16 (or smaller) or when the actual images were smaller than 16x16?
-
Odd crash. Something to do with ai_maybe_add_form_goal. Somehow the remaining ship is not part of a wing or something. Wish I was better at understanding the debugger...
The problem arises because Scorpio wing has a Threshold value (i.e not all of the ships have to be destroyed before the next wave appears). I can already reproduce the problem in a test mission and thanks to Wanderer I know where the bug was introduced. All I need to do now is figure out how to fix it. :)
-
Wouldn't it be easier to just set it so the second wave doesn't arrive until the first wave is destroyed?
-
In the same way that it would be easier to set the game to only have 1 class of ship that couldn't move or fire, yes.
Solving bugs in features by removing the feature is nothing short of idiotic.
-
I don't see how that would be removing a feature. :wtf:
-
'Wing Threshold' is a feature. It's mainly to stop you as a player from equipping Akhetons, then disabling one fighter out of every wing so they don't respawn.
-
Huh. I don't know that. Useful little failsafe, isn't it?
-
EDIT... Do you mean the fighter and bomber icon images were garbled when they were set via the table option to have size of 16 (or smaller) or when the actual images were smaller than 16x16?
When the actual images were smaller than 16 (they're 8x8). Do they work for anyone else? Haven't goofed around with the table options yet.
-
Any compressed DDS textures (in freespace mainly DXT1 and DXT5) needs to be minimum of 16 x 16. Any smaller and then the image needs to be in uncompressed format (like u888 or u8888). But yeah i have encountered those problems before.. IIRC 4x4 pitch black compressed DDS texture which appeared... well... not so black :D...
But that shouldn't be an issue with the scaling options (assuming they work like they should). Of course the scaling has its problems as it makes already thin lines even thinner (when making images smaller) unless the image used takes this into account - though this effect may by preferable as well.
-
'Wing Threshold' is a feature. It's mainly to stop you as a player from equipping Akhetons, then disabling one fighter out of every wing so they don't respawn.
It also helps keep the pace up; no waiting for warpins.
-
'Wing Threshold' is a feature. It's mainly to stop you as a player from equipping Akhetons, then disabling one fighter out of every wing so they don't respawn.
That would only delay the warpin actually. After about a minute of being disabled or disarmed enemy fighters in wings self-destruct in order to prevent someone screwing up the mission by doing exactly that. :)
-
I now know why some characters went down despite the fact that they were guardianed...someone disabled them...
Good to know :)
-
Backslash.. What did you mean by the hud thing? Using colors in hud elements? or something? make them table options?
-
I'm already making them table options... what I was getting at was different. Right now, a HUD ANI has to be a particular 256 color palette (actually only 16 colors, grayscale, with the rest being empty). The game then shades that to whatever color is specified in the options menu (or the custom table option I'm working on). What I'd like would be something like, "if the game detects the file is more than 256 colors, it displays it as is and does NOT try to shade it a custom color." Does that make sense?
Upon looking through some archives I notice taylor said he might do it. But then he says that about everything cool :D and he did say that a while ago. I suppose if you did decide to take this on, you might want to PM him for input -- perhaps he has some WIP code or notes you could have. I don't know what all is involved... it might dovetail nicely with the stuff you already worked on and be quite straightforward, or it could be a big complicated project. I don't mean to push you into something too big.
-
Just wondering... If you are already making them table options wouldn't it be possible to enable boolean (or strings) to set the game to draw the bitmaps in the way like you want them to?
-
@backslash: Is it really a good idea when you can use hud_gauges.tbl for images already?
-
@WMCoolmon, yes, that's where I'm putting it. :)
@Wanderer... the options I'm making is basically the same thing as what the HUD options menu sets... "I want the afterburner green, reticle red, shield blue, target box yellow" etc. This is still just the shaded gauges though. Yeah adding a setting is easy... I just don't know how to make the game actually DRAW the bitmaps that way ;)
So basically, you start on one end (how to actually display the thing), I'll start on the other (settings in the table) and we'll meet in the middle? :D
-
AFAIK the issue is basically that almost every HUD render functions sooner or later calls gr_aabitmap or gr_aabitmap_ex (actually almost the same thing as the non-_ex function calls the _ex function in turn) functions and therefore also opengl_aabitmap_ex_internal. And as that function has mandatory requirement that the bitmap in question has to be set in TCACHE_TYPE_AABITMAP type you cant really do anything else than just draw with current color. So what needs to be done (imho) is to place alternate gr function calls to the places where the gr_aabitmaps are called.
Perhaps using gr_bitmap_ex instead of aabitmaps though that sets the type to interface... hmm...
Besides at worst it seems to only need a new opengl draw function and as bitmap_ex is currently unused (i couldnt see references to it) i think that could be used... I'll probably try it later - possibly today.
-
gr_set_bitmap(idx, lua_Opacity_type, GR_BITBLT_MODE_NORMAL, lua_Opacity);
bitmap_rect_list brl = bitmap_rect_list(x1, y1, w, h, uv_x1, uv_y1, uv_x2, uv_y2);
gr_bitmap_list(&brl, 1, false);
from scripting drawImage function. Much more flexible than _ex.
-
Yeah... That one should do the trick..
-
:bump:
To break the silence...
Salvo mode
Uses a single weapon entry. All firing points within a turret aim more or less independently (to improve accuracy) but fire simultaneously. Should ignore all the weapons expect for the 'primary one'. Known issues: Swarm weapons may not work properly.
Fixed firingpoints
Sets the weapon to a fixed firing position. Position is set according to the weapons 'position' when it is parsed. That is 1st primary weapon should fire from the 1st bank and 2nd from the 2nd bank and secondaries get their 'positions' assigned after the primaries so 1st secondary weapon in a turret with 2 primaries would go to 3rd bank and so on. Requires the use multiple guns option. Effectively maximum number of weapons (apart from the 3 + 4 limit) set to the turret is equal to the maximum number of firingpoints of the turret. Known issues: Multiple swarm weapons may not work properly - single swarm weapon is ok.
Comments are always welcome....
EDIT: ...as are ideas on how to fix a swarm weapons with turrets that have multiple weapons. That is from time to time the turret fires only portion of the swarm weapons loaded into it and tossing the rest away with Overlapping turret swarm firing intervals note.
EDIT2: heh.. err.. missed one thing... added the a flag for subsystems that if set should force the subsystem not to fire unless the turret points at the target. So if the barrels wont point where they were supposed to point the turret shouldnt start firing... so the 'wip_turret_10.7z' should contain the diff for 'fire on target' turret flag.
[attachment deleted by admin]
-
Blech. I wish turrets would behave like fighters stapled to the ship's hull.
-
Like?
-
Turrets have been known to behave oddly at times. I have seen cases where the the firepoints don't rotate with the barrel, and sometimes they don't fire along their normals. Its too sporadic to replicate consistently though.
-
Firepoints not rotating with the barrel sound more or less a model file issue. And multipart turrets shoot only along their normals if the turret rotation has caught up with the actual firing direction - thing for which i made the 'fire on target' flag (then it only fires if it actually points at the target).
-
Made new revision after i decided to make an attempt to get the multiple swarms per turret to work. Also added '+No Swarming Movement:' boolean option for weapons to cut down the useless math for non-homing swarm missiles (or shots) as well as giving ability to make non swarming 'burst fire' missile turrets and has the smart spawn option included.
-
:yes:
-
Here is the diff and the build (of the 'turret' branch - so the radar and iff stuffs are not in this). I included the 'smart spawn' and i also added phreak's "inherit parent target" flag for good measure.
So things which are included:
Turret flags
"fixed firingpoints"
- explained earlier - except now should work with beams and swarms as well
"salvo mode"
- explained earlier - except now should work with beams and swarms as well
"fire on target"
- prevents turret from firing unless it as actually (almost) pointing at its target
Weapon flags
"smart spawn"
- prevents game from firing all the turret fired spawn type weapons in straight line like all retail turret fired spawn type weapons are fired
- allows turret fired spawn type weapons to act like normal weapons. ie. allowing them to home on target etc.
"inherit parent target"
- phreaks earlier addition.. forces spawned warheads to inherit the parent warheads target
Weapon options
"+No Swarming Movement:" boolean... right after 'swarmwait' entry
- if set to 'false' removes the random swarming movement from swarm type missiles (makes them more like burst type missiles) by skipping most of the math of swarm weapons
test build (http://koti.mbnet.fi/vekkup/FS2/Arkisto/fs2_open_3_6_9d_turrettest.7z)
[attachment deleted by admin]
-
So.. any comments? Criticism? Anything?
Another set of additions due request from VA
$AliveSnd:
Sound subsystem keeps while its alive...
The sound index value from sounds.tbl, integer
$DeadSnd:
Sound subsystem keeps when its not alive (surprisingly...)
The sound index value from sounds.tbl, integer
$RotationSnd:
Sound subsystem keeps when its rotating (almost the same as alive)
The sound index value from sounds.tbl, integer
$Turret RotationSnd:
Sound turret keeps when its moving.. ie. tracking the target
Scaled according the rotation speed vs max rotation speed
The sound index value from sounds.tbl, integer
$Turret RotationSnd Volume Multiplier:
Multiplier so that single sound can be used for several different sizes of turrets
Defaults to 1... float
Link to testbuild... (http://koti.mbnet.fi/vekkup/FS2/Arkisto/fs2_open_3_6_9d_turretsnd.7z)
Link to diff... (http://koti.mbnet.fi/vekkup/FS2/Arkisto/wip_turret_13.7z)
-
I hope all this stuff will come in handy with the ISD, and it's octet-turbolaser batteries.
-
Awesomeness. I'll test as soon as I can. :D
Chief: Yeah that kind of turret is what I was thinking this would be really really helpful for - making big turrets really feel big.
-
Just wanted to say; this is really really cool. :D
I applied a sound from BF2 to this to use as the turret rotation sound, and used it in conjunction with a triton with slowed down turrets. Even though the turrets are far less effective than they would normally be, they *feel* much scarier and like the huge gun turrets they would be in real life.
If this stuff can be integrated into 3.6.10, I'd love to make use of it in the MVPs. An Orion bringing its big guns to bear would be a very impressive sight indeed. :)
-
Yeah, that would be awesome. The effect of sound cannot be overestimated. It's the sound that makes beams so scary, not the appearence - When you hear that warmup, you just know something bad is headed your way. And I bet it would be the same with a rotation sound for the big multipart turrets... you're trying to evade and don't have much time to look towards the turret, but you can hear it following you everywhere you go and expect imminent death :nervous:
-
Salvo beams? Sweeeeeet
-
So.. any comments? Criticism? Anything?
In general I find it takes a little while for people to realise the nice toy they've just been given. :D
-
Sounds promising. Maybe this could even be applied to the retail campaign without too much trouble?
-
I'm wondering, is it possible to get a uh, alternate salvo mode where . . .well you can fire beams out of a turret but they don't fire simultaneously? (like normal swarm turrets). Or is that already implemented?
Regardless I'll try out the Salvo mode sometime though I'm on a bit of modelling buzz right now and I want to keep at it while I'm still interested. If it lasts long enough when I test it out it might be on something even cooler :D
-
That type of option was available earlier.. Problem was that you rarely got 'independent' weapons instead the beams tended to jump from one firingpoint to another and even then use the same firing point for all the beams in the turret - but the build i posted should have this fixed. But you can make the turret to fire multiple beams 'non-simultaneously'... Arm the turret preferably with as many beams (max 3) as it has firingpoints. Add 'use multiple guns' turret flag for it - and possibly also 'fixed firingpoints' flag. And that should do it.