[Dragon]

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.

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.

[Nuke]

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.



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.

[Spoon]

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?

[JGZinv]

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

[Legate Damar]

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?

[Nuke]

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. 

[Dragon]

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.