Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Riptide on August 19, 2012, 01:05:39 pm
-
Hey guys, I had a bit of a technical question in regards to customizing Freespace and I figured this forum would be the best to post in.
I was wondering if it is possible to allow a player to select armor and engines in addition to being able to select weapons.
I thought of a way to 'fake' it by making multiple ship tables like myrmidonA, myrmidonB, that would have different values associated with them; however, I was wondering if there's any way to incorporate this into the GUI in the game. For instance, if you equip a certain type of armor, it reduces damage from beams but makes you slightly more vulnerable to flak (just an example). I know I'd have to make a custom weapon and damage type table, but I figured I'd ask if this would be possible.
-
Yup. Mods like WoD and Ashen Wings (among others, did Antagonist too ?) made heavy use of the armor.tbl table that does just that, enabling different types of weapons to do different damage on different hulls. I direct you to this (http://www.hard-light.net/wiki/index.php/Armor.tbl) wiki page for more info, or just take a look at what's been done in released mods. Basically, you put a specific damage type on your weapons (through weapons.tbl) and a specific hull type on your ship (through ships.tbl or via SEXPs in-mission), and list what does what damage on what in armor.tbl.
-
For the selection, you might not need to use duplicate ships if you use the equipment/tertiary weapon slot.
-
Hmm, this equipment slot is exactly what I was looking for. Can you elaborate a bit on it? Sorry, big time noob when it comes to this. Is it something that is usable in the stock FS2 open GUI?
-
FYI, The armor.tbl wiki page (http://www.hard-light.net/wiki/index.php/Armor.tbl) has been updated to the latest version, as well as updated the format for ease of use.
Also, this is the first time I've heard of the equipment/tertiary weapon slot?
-
id kinda also like to be able to equip turrets. and i bet all this is possible with a little scripting to tweak the loadout screen. big problem is the lack of a ui, i could cobble something together i suppose, but they were planning on some kind of scriptable ui system and i shelfed any plans i had pending that feature.
-
FYI, The armor.tbl wiki page (http://www.hard-light.net/wiki/index.php/Armor.tbl) has been updated to the latest version, as well as updated the format for ease of use.
Also, this is the first time I've heard of the equipment/tertiary weapon slot?
I think Spoon showed something like that in one of his WoD2 preview vidoes. There he put some special, externally docked equipment into free weapon slots:
http://www.hard-light.net/forums/index.php?topic=74794.msg1527311#msg1527311
If I remember correctly there is also a video of an externally docked "after-burner booster", that is put into a missile slot flying around somewhere, but I can't seem to find it (I'm also not sure if it was also from WoD or somewhere else).
-
DE had a thing like that
-
Hmm, this equipment slot is exactly what I was looking for. Can you elaborate a bit on it? Sorry, big time noob when it comes to this. Is it something that is usable in the stock FS2 open GUI?
Basically, what we call "equipment slot" is a workaround where we use primary or secondary slots to put dummy "equipment" weapons just as any other weapon in the loadout screen, which can then be detected by sexps or scripts in order to trigger the effect of the equipment.
Since you can restrict which weapons is allowed in which slot on a per-ship, per-slot and per-weapon basis from ships.tbl, you can make "equipment"-only slots for this purpose.
-
ive used that technique in the past. crude but effective.
-
The only problem with them is that equipment slots count towards either missile or gun bank limit. TBH, I wouldn't be against bumping those limits, but I'm afraid that it'd be quite an undertaking.
-
It was my understanding that simply bumping these limits would break multi.
-
That's why I said it'd be quite an undertaking. In FSO, bumping a limit is rarely simple. You need to ensure things like multi, interface and pilot code all work without any problems with the new limit. The new pilot code might take care of the latter, Swifty's HUD can handle a part of interface problems (there's still loadout and FRED interface to edit), but multi might be very hard to fix. Diaspora is looking into improving multiplayer though, so maybe something will change in that regard.
-
I don't quite see what's wrong with just making a dedicated equipment slot... the equipment itself doesn't have to do anything in the game, that could be done with something like a script that's common to each and every mission in the mod/campaign.
-
*watches thread with keen interest*
-
I don't quite see what's wrong with just making a dedicated equipment slot... the equipment itself doesn't have to do anything in the game, that could be done with something like a script that's common to each and every mission in the mod/campaign.
Making this work in multi could be even more difficult than bumping the bank limit. You're adding a new feature, as opposed to expanding an old one. This feature would also need new interface, HUD, pilot code (for carrying equipment through Red Alert missions), etc.
-
I don't quite see what's wrong with just making a dedicated equipment slot... the equipment itself doesn't have to do anything in the game, that could be done with something like a script that's common to each and every mission in the mod/campaign.
Making this work in multi could be even more difficult than bumping the bank limit. You're adding a new feature, as opposed to expanding an old one. This feature would also need new interface, HUD, pilot code (for carrying equipment through Red Alert missions), etc.
Antipodes 8 has got the pilot code covered. Dedicated code for a HUD interface is unneeded for the most part, as you can use custom gauges + scripting to achieve any effects you need to display, although for some things such as mid-mission equipment changes will need some tweaks to the HUD and scripting code.
A new Interface page will definitely needed, and should be configurable. There's been some work on modularizing the menu/interface system already, so hopefully we'll see some news of that soon.
Multiplayer is a topic in of itself, I don't know if what they have currently verifies all files used client side match the files server side... which is a common (?) way of determining if somebody's trying to cheat, or if they're having a derp moment and forgot to take mod-stuff out of the folders while playing multi :P).
Unfortunately, checksums alone cannot tell which modifications are merely cosmetic (which may be allowable) or alter the performance of in-game assets (which should be illegal), unless it's known specific files/tables affect only cosmetic stuff.
-
Here, it's more of a matter of sending a new "item" over the net. Also, I don't think including too much scripting in the equipment system is such a good idea. It's not exactly the easiest nor the best optimized way of doing things. Things like HUD display for equipment should be implemented in engine.
-
If anything, the main problem will be the goddamn ship selection interface.
IIRC that was the reason a bunch of WoD requests got shot down and they(I'd say we since I'm on the team but I really had nothing to do with this xD) had to resort to using scripting/sexp-based systems...
SCP is...rather reluctant to work on the ship selection interface, short of a complete rewrite, which will be done "later" or something.
-
Here, it's more of a matter of sending a new "item" over the net.
I don't see that big of a deal, during initialization of the game and/or when a player joins while the game is in-progress, the player's computer would send "I has dees items: blah1, blah2, blah3." If the multiplayer code is that bad where it has the player continously report what items it has, then yes, that would be a big deal. :P
Also, I don't think including too much scripting in the equipment system is such a good idea. It's not exactly the easiest nor the best optimized way of doing things.
Well the only other way I see making equipment work predicatbly and still be general enough to supply most/all posisble capabilities is to create an equipment.tbl or a ship_cards.tbl and go from there.
Things like HUD display for equipment should be implemented in engine.
...What? what's wrong with the hud.tbl system?
rather reluctant to work on the ship selection interface, short of a complete rewrite, which will be done "later" or something.
Honestly, there WAS some work done by two people on the interface. Valathil mostly, He was doing some work on a new menu interface system that provided LUA hooks for some things, but I think that was several months ago.
-
Also, I don't think including too much scripting in the equipment system is such a good idea. It's not exactly the easiest nor the best optimized way of doing things.
Well the only other way I see making equipment work predicatbly and still be general enough to supply most/all posisble capabilities is to create an equipment.tbl or a ship_cards.tbl and go from there.
Things like HUD display for equipment should be implemented in engine.
...What? what's wrong with the hud.tbl system?
In general, it should be possible to make equipment using SEXPs and tables. Yes, an equipment.tbl would be a good idea, it'd simplify a lot. It's syntax could be simple:
$Name:
$Uses: (0 for passive equipment, activated upon mission start)
$Regeneration: (how fast the uses regenerate, in case you wanted an energy meter)
$Event: (SEXP to execute on activation)
or
$Script: (Script to execute on activation)
or
$Special: (built-in presets. Typing a name of armor type from Armor.tbl would make it apply that armor, and there could be other presets like "cloak").
Scripting is good for advanced features, but things like HUD are better done via tables. There should be an optional HUD gauge, not using custom gauges system, but rather a dedicated "equipment gauge". It'd show installed equipment and number of uses.
Here, it's more of a matter of sending a new "item" over the net.
I don't see that big of a deal, during initialization of the game and/or when a player joins while the game is in-progress, the player's computer would send "I has dees items: blah1, blah2, blah3." If the multiplayer code is that bad where it has the player continously report what items it has, then yes, that would be a big deal. :P
Well, let's start with saying that FSO MP code is badly written. :) Somebody mentioned running into packet size limits when discussing bumping weapon bank limit. I don't know details, I don't have a lot interest in multi.
-
If anything, the main problem will be the goddamn ship selection interface.
IIRC that was the reason a bunch of WoD requests got shot down and they(I'd say we since I'm on the team but I really had nothing to do with this xD) had to resort to using scripting/sexp-based systems...
SCP is...rather reluctant to work on the ship selection interface, short of a complete rewrite, which will be done "later" or something.
i think valathil or whoever was working on a configurable gui of sorts. probibly a ways out but i figure this is the thing you need. theres always nukui but its very incomplete and you need to be a scripter to use it.
Things like HUD display for equipment should be implemented in engine.
would be nice if the hud table led you define scriptable gauges, managed by the hud system. from script side you would just get a little sandbox for drawing the gauge frames (init and uninit sections would be useful for loading/freeing graphics), and pass the appropriate parameters from the hud_gauges.tbl to scripting. i still maintain that scriptable gauges can look way better and be far more tweakable than anything hard coded. case in point this scripted weapons gauge could easily be tweaked to add tertiary weapons or equipment gauges.
(http://i213.photobucket.com/albums/cc103/Emperor_of_Nihil/screen0046.jpg)
yea the 2d artwork could be better but meh, you dont get analog gauges in the stock weapon gauge, you get a couple of ugly boxy procedurally drawn ammo gauges next to it which is the whole reason i did this (to be fair you can probibly define new graphics for those nowadays). would be nice if i could make use it in a hud.tbl gauge slot, where i could inherit things like screen offset, size, and color info so it can be worked in by editing hud_gauges.tbl. even if its just something like a dummy gauge slot, that is ignored by the internal system.
face it if you are going to define custom behavior for the equipment, your going to need to program that behavior, be it sexp or lua. so its a good idea to provide the framework so you can do that without a bunch of dirty hacks. nothing against an engine defined equipment/gauge, but that kinda takes the custom aspect out of it, as you would be limited by only internally defined equimpent.
-
If I remember correctly there is also a video of an externally docked "after-burner booster", that is put into a missile slot flying around somewhere, but I can't seem to find it (I'm also not sure if it was also from WoD or somewhere else).
http://youtu.be/1spSv2GP7oI?hd=1
this?
-
I have to wonder where E is... as I made him the tertiary weapons/equipment art for the weapons selection menu and he was
on his way to making that all work. I still have the PSD's around here somewhere...
ie http://www.hard-light.net/forums/index.php?topic=71501.msg1414314#msg1414314
http://www.hard-light.net/forums/index.php?topic=75815.0
-
In general, it should be possible to make equipment using SEXPs and tables. Yes, an equipment.tbl would be a good idea, it'd simplify a lot. It's syntax could be simple:
$Name:
$Uses: (0 for passive equipment, activated upon mission start)
What if you want an ability with unlimited uses?
-
adding conditions for equipment usage should be up to the modder. like if i stick a laser designator on there so long as you still have laser guided munitions you can use it. perhaps also allow me to use energy or ammo. an elementary task for any fredding wizard/scripter. table entry may allow you to define things like sound effects capacities, consumables, usage rules, but really all you would be able to do to define what the equipment does is select it from a list of pre-defined functions that the coders felt like implementing at the time (things like cloaking device, and boosters, to name a couple). something like an $on equipment used: hook or an equipment-activate sexp, and controls to use equipment are all you need to actually define your own equipment. and it can go either way or both for that matter.
-
In general, it should be possible to make equipment using SEXPs and tables. Yes, an equipment.tbl would be a good idea, it'd simplify a lot. It's syntax could be simple:
$Name:
$Uses: (0 for passive equipment, activated upon mission start)
What if you want an ability with unlimited uses?
Then you give it one use and regeneration of, say 100. If you also want a recharge delay, you can set regen to a fractional value (setting it to 1 would create a 1 second recharge). Any rechargeable ability would have unlimited uses.
Now that I thought of it, a $Delay: field would be useful for defining recharge delay for limited use equipment.