Goob I appreciate that someone tried to reply to my requests at all, but I'm honestly sitting
here with a facepalm. I went to the extra effort/time to record videos because trying to explain
what I had to show is difficult in words in the first place.
Even if I did explain it, everyone else would still have some part of it they wouldn't quite grasp,
which we'd spend several more posts trying to clear up. Other than the first two all the videos
are around or under 2 minutes. Reading a regular post takes longer than that.
Firepoint linking... again trying to explain it is a heck of a lot harder than showing it off.
The primary/secondary systems is based on a common pool of weapons. So essentially the "secondary" and "primary" labels
our only useful for two things. 1. As a label on the HUD. 2. As a different fire key assignment.
Theory / idea:
Now
if I could take all my weapons, list them all as primary, still have
missiles, rockets, etc, function as they conceivably would.
That
might work as a hack to draw everything from a single "pool."
Would still have to find out how to setup a HUD gauge (fake secondary)
that
would be displaying weapons from the primary group, but not the
same weapon as the real primary labeled gauge. Provided that much was
do-able... it might work. But since I don't know... all I can do is
throw it out there and see if there's other ideas, maybe instead fixing
it to work "normally" via code rather than a hack around.
The
other part of that is various stages of firepoint linking. Some or
possibly all of which FotG I believe has based on some of the videos
floating around. But there several things I don't know, starting with
where FotG got it from and how it was configured.
That's the reason the video is 7 mins long, because it explains and goes through both of the above.
HUD
Energy - *rubs temples* I just tried wring a paragraph, deleted
it, and I'm lost. Tach's is mostly the same basic elements/system as
FS2.
The functionality and gauge behavior in terms of how each ETS
element relates to the other ETS element is a little bit different.
Radar
Orb - would you ask Diaspora to change DRADIS to ORECK? I'd
rather look into every other option before making a decision like that.
We're a total conversion, the idea isn't to leave FS2 parts in plain view.
Charging
- I hear this a lot... but I've yet to see anyone explain "why" this is
such a difficult problem. No that's not noob-to-HLP talking, I've
seriously not seen a explanation of what is keeping it from
working. I'm going to take a guess here, and think that it's based
on something to do with weapons, ammo, and energy - how FS2 treats them
as objects. One issue being how do you spawn a weapon with less giving
damage properties, when everything is based on hard numbers in tables.
Spoiler:
To
my woefully code uneducated brain, it would seem the answer, if this is
the case, would be to handle it in scripting outside of the normal
restrictions.
You'd need an outside "container" of sorts for the weapon damage value, so that it could be a variable number.
You'd
need one script that would read from your weapons energy amount, and
tell the weapon to stop filling should you have no more energy to give
it. This also directly tells the container how much value/dmg it can do.
The
dmg value could be determined by calculating how long whatever key it
is is held down to charge, the duration of the key press, times some
numerical increment. Basically a scale. A early version of this could be
filling by increments. Such as every key press removes 25% from weapons
energy, and gives the same value to the weapons container.
Now,
when the fire key is pressed, the values for the container are locked,
no more charging can be performed as the weapon has been released.
There's
need to be some check though setup for the next time the user wants to
fire another shot, so the script goes back to charging after it looks to
see if there's any energy left in the weapons reserves to charge with.
As
for the weapon, for your table, set the dmg and all that to 0. Most of
the features of a weapon, description, etc, should still be applicable.
You'd probably need a flag though for "charging" so that it would know
to accept/use/look for the scripting elements.
As for the
released weapon we have, let the FSO system handle the projectile like
elements. You just need to watch for it to have "hit" - which then the
rest of the scripted events happen. It would need to know which ship or
object was hit. Then the script would translate the value left in the
"container" to damage, and apply that to the shield/hull/whatever of the
object receiving the attack. When the weapon disappears either by
hitting an object or exploding by reaching it's lifetime, the values in
the container are also erased, for that instance of the fired weapon. |
Missile
flight - A hornet flies in swirls or curls like a spring all together. I
want to edit that so I can make it fly in a different formation. One
missile out front with a trailing triangle-esque 3 point pattern of
missiles trailing the first. It's designed like a penetrator.
First hit weakens the shield, then the main salvo smashes the target.
Gliding comment - I "didn't" intend for everyone to look at all of them at once. Most people specialize in a couple areas.
Missiles - No, because I'm not entirely sure it's a bug. Trying to show/discuss it to figure out what it is...
Surely
the Tachyon engine is not the FSO engine. Tachyon was a nearly
unmoddable, labor of love by a group of devs that was unfinished. It was
abandoned by it's publisher. It has no where near the support that FS2
ever saw. Which is why we are here.
A major portion of the L1
requests above are HUD related, of which, in all fairness is still
somewhat a recent addition to what we have to use.
However if I don't say something about what we need, it'll also never become available.
If
you notice, I never said anywhere that we needed these this week, next
month, or 6 months from now. If I was "hoping" - I'd "like" to see us
get
the main things together for alpha release by mid December this year.
Besides the coding, texturing, and FREDing issues, we're not doing
entirely too bad for a change. Least compared to the last 6 years we've
been trudging away at this with a small skeleton crew.
Which is
why I posted this now, on the tail end of 3.6.14 being finalized, so
maybe... if there's anyone interested, some of these things can start
being thought about for integration in the future.
Topic: FringeSpace Requests (Read 97 times)
Quick Reply