Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: JGZinv on January 08, 2007, 10:32:17 pm
-
Ok before we get into the list below, I just want to note that what we put down
is mainly a full listing of things both what we considered reasonably likely, and
others that we doubt will come to light. So we're aiming high and hoping the scatter
shot lands where we need it - in a manner of speaking.
We're doing the mod in stages/phases, so we have plenty of time available.
Lastly, in other wishlist threads most of the responses are "already done" or "play this mod."
While "play this mod" is slightly more helpful, I'd like to ask that if you know something
is in the works or available for use, just keep in mind we are somewhat new to the HLP still
and all "pointing in the right direction" is much appreciated. Names or thread links are even more
helpful. We may have some other ideas in the future, but this (including the attached documents) is the
main bulk of everything. We've picked up on some old threads here that indicate some of what we
want was being made - but have no idea if it was ever completed, so this may be a refresher as well for some.
Here's what we are looking at...
*Note selection edited per karajorma's suggestion*
Structure / Foundation:
--Afterburner in reverse.
--Throttle tied to your "reverse/forward" state.
--Replenish fly-through icons for: partial all energy, afterburner energy, weapon energy, shield energy, repair hull, refill rockets, refill missiles, refill sappers, refill mines, repair all systems (all energy / ship hull).
--Ability to land at carrier or landing pad without cutscene (fly close enough - hit enter when prompted, ship lowers/enters and docks).
--Changing ships while in game (carriers, bases, landing pads).
--Changing weapons loadouts (carriers, bases, landing pads).
--Join in progress game.
--Player to player, player to all, and player to allies text chat.
--Anything gravity related could use a FRED "area of effect bubble" - that would make placement much easier.
Server Side:
--Server side table checks - security protection.
--Independent game-warden-like system to install on the same machine serving games.
--Update from server - a la StarCraft or various others.
--Server able to separate FFA player modded games vs. "official" games with stock settings, ships.
--Graphics independence for allowing ship mods visually only (allow cosmetic changes, not ship stats) FFA modded games can do whatever, official games should only allow changed decals, paint, etc (textures).
--Ability to add player stats for the server to check while playing - such as more robust player lifetime scorecard - games/played, time played, kills, kills/minute, kill ratio, shots fired, shots landed, missiles fired, missiles landed, accuracy percentage, credits obtained, credits lost due to death.
Game Modes:
--Arena (Deathmatch).
--Co-op (imitation single player missions, side vs side, single or side or teams vs. computer).
Player Control / UI:
--Reverse shown on the HUD.
--Text chat overhaul & teamspeak integration.
--HUD GUI editor.
Weapons:
--Chargable, fire upon release of trigger [solaris torps] (toggled by release of trigger, not charge state to full).
--Linking secondary weapons.
--Linking all weapons at once.
--Linkable, multi-hardpoint secondaries.
Weapon Types:
--Improved tractor beam.
--Improved Corona device.
--Gravity Mines - for interdicting and defense.
--Gravity Mine 2nd variant - ship within certain range, mine explodes causing damage.
--Sappers for energy, speed, weapons, remote bomb.
--Tachyon gate traversable area effect bomb (send it through, clear gate "campers").
Ships / Stations / Areas:
--Battle in a warp tunnel map - when hitting a sidewall, damage is received, energy "storm" or bolts inside cause damage as well.
--Dome colony starport - perhaps on a giant ice roid (dome or shield that retracts for player to enter).
--Stand alone & combo missile turrets.
--Turret subsystems.
--Sapper burn off device for ship loadout.
--Gravity producing asteroids (rare ore, large roids, huge roids).
Gates:
--Jump via gate/model area, or specific preset area in space. Must be available in all multi player modes.
--Destroyable, or at least able to be temporarily shut down with a certain weapon.
--Support ships able to repair them.
--Animated gate parts and "sphere."
Razor may be down with a cold, so I'll try to field questions as best possible.
Stages 2 and 3 of the wishlist are attached below.
Thanks.
[attachment deleted by admin]
-
some of those are good ideas, a few of them are impractical, many already exsist (and has exsisted sence retail), or could be made useing the exsisting code, but as of yet no one has implemented it.
wait, are you planning on makeing this mod?
-
wait, are you planning on makeing this mod?
We already started back in October.
It is a Tachyon to Freespace 2 conversion... plus we plan to improve upon
some areas of Tach that were buggy, left unfinished, or could be done better.
We have a number of the ships already in Freespace 2.
More are being worked on currently.
You can find a WIP ships list and other information at www.FringeSpace.org (http://www.FringeSpace.org)
-
A large number of those things are actually possible via the scripting system or with some creative FREDding.
One thing we get the hosted projects to do when making requests to the SCP is to sort a list like that into stuff they need and stuff they want. If you sort that into a smaller list of stuff that it's absolutely essential to have for your first release there is a much bigger chance that it will get coded in or that someone will explain how you do it.
-
We'd planned on that and considered it before posting.
Figured it was best to see what was needed before going the extra step.
I'll have it edited by tomorrow sometime per your request.
-
The listing is edited. What is shown there is what we would need in order to get
basic arena games and some other materials set up and going to actually make a
mod/Tach type game - per say out of it. Stage 1.
Just so I'm not bumping my own post - the server section there I'm actually
a bit unsure as to where it should be placed. Those features are not necessarily
required for getting Stage 1 up and going - even though it would be nice.
On one hand - we realize they are not needed immediately, on the other, if we
don't mention them early on we may not get our "foot in the door" so to speak either.
We realize those in particular are some large requests, and really have no way of knowing how
the SCP organizes itself or prioritizes what to do next. So all we can do is get it mentioned sooner,
rather than later.
As can be seen here - http://www.fringespace.org/index.php?name=Sections&req=viewarticle&artid=1&page=1 (http://www.fringespace.org/index.php?name=Sections&req=viewarticle&artid=1&page=1)
The second stage moving forward would consist of getting bases and the related BaseWars up
and functional along with some interesting add-ons to what can be considered the current "stock" gameplay now.
Third stage is the major multiplayer conquest & clans mode and final add-ins to wrap things up.
The zip file attached to my original post contains both of these last stages listings in two RTF documents.
They're already formatted if for some reason someone wants to post the content later on.
~JGZ
-
at least 90% of that list you can just do now, were would you like to start?
-
Exactly. Just pick a couple you need figured out today and we'll tell you how to get started. Obviously there are too many there for me to explain how to do them all in one post :)
-
In reply to Bobboau more so than Kara - perhaps, since there is less you could tell me
what is the non-possible 10% and that would further limit my response. :)
Both -
Hmm, I suppose we need gameplay mechanics the most, soo...
--Afterburner in reverse.
--Throttle tied to your "reverse/forward" state.
--Reverse shown on the HUD.
--Chargable, fire upon release of trigger [solaris torps] (toggled by release of trigger, not charge state to full).
--Linking secondary weapons.
--Linking all weapons at once.
--Linkable, multi-hardpoint secondaries.
--Jump via gate/model area, or specific preset area in space. Must be available in all multi player modes.
That would at least get us functional. Any comments as to what to do with the server side information?
-
not sure exactly what you mean with the first three, you can fly backwards with the right table values, unfortunately this is less usefull than you probly think due to the physics of the game.
chargeing weapons is something we keep forgetting we want to implement, it'll happen soon probably.
the jump gate thing could be done via a set position sexp,
describe in more detail what you want done with the secondaries.
-
some of those are good ideas, a few of them are impractical, many already exsist (and has exsisted sence retail), or could be made useing the exsisting code, but as of yet no one has implemented it.
Thanks for the comments! Some of the "impractical", I'm fairly sure, are because we're trying to make as close an approximation to Tachyon's gameplay as possible.
wait, are you planning on making this mod?
Yessir. It's more of a conversion, though. As much as possible, we're aiming to make this a standalone game, really.
not sure exactly what you mean with the first three, you can fly backwards with the right table values, unfortunately this is less usefull than you probly think due to the physics of the game.
I've got it where I can fly in reverse. There's a few limitations inherent in the current system, though.
1. You cannot use afterburner in reverse. ie: to add to the thrust in reverse in the same way that it adds to your thrust in normal flight.
2. There's no HUD indication of your speed.
The reason we're asking, is because Tachyon's gameplay was always very highly dependent on you being able to thrust forwards OR backwards, at the same speeds, and with afterburners in either direction. That is one of the key things that elminates the "circle of doom" mentality that dominates the majority of space sims. You can thrust side to side, and forward/reverse - so you can equalize distance between you and another ship, or"keep the gap" between you and that other ship - and do it all while having the capability for some truly awesome manuevers should your opponent screw up, or should YOU screw up. It's quite scary how quickly ships move in tachyon, and how having the ability to sidestep even individual shots, or missiles, changes the face of combat.
Basically, it's just a request to allow the same functionality in reverse that you can have in forward. In as many respects as possible. This is something that I didn't discover until after I'd tabled reverse thrust in, but it's a big-time solution for us, as we're trying to duplicate functionality as close as possible.
chargeing weapons is something we keep forgetting we want to implement, it'll happen soon probably.
Awesome :D
What we're looking for, just to clarify, is the ability to not only charge, but to retain firing ability at any point of the charging process. From 0-100%, just to assign an arbitrary scale, when you release at 50% charge, it would deal 50% damage compared to the fully charged release, on that same scale.
the jump gate thing could be done via a set position sexp,
Just to clarify: In Tachyon (much like Jumpgate, from Netdevil), you "jump" to another place/area by flying through a spherical "tachyon gate", with pylons "generating" the "field" you jump through. Can you assign that function to a specific portion of a model (the sphere), while retaining the solidity of the rest of the model (the pylons)?
describe in more detail what you want done with the secondaries.
In tachyon, you have multiple "banks" of weapons, like in FS2. However, you can use two "sets" at a time, whether primary, or secondary. So, say you have 3 lasers. They're set up as 2-1. However, you might also have two "sets" of 2 missiles, or torpedoes, what have you. So, you'd "swap" to the other two "sets" - and you'd have 2-2 FS2 *secondary* weapon equivalents.
In FS2, correct me if I'm wrong, you only have single-weapon secondaries. No linking of multiple weapons within a single bank - AND, no linking together of two *secondary* banks, like you can with primary weapons. So, while we can now fire both secondary and primary weapons simultaneously, in FS2's engine (which we couldn't do in Tachyon); we CANNOT put multiple weapons into the same bank, nor can we link the two together for mass-fire.
That's one issue. the OTHER issue is, many ships carry several different weapons "packages", and do it all simultaneously - especially the "heavy" assault ships, or the bombers. I'll use the Warhammer, for instance.
It has a single, quad-linked primary (laser).
HOWEVER - it has a 2-2-1-1 secondary setup. It's usually loaded with dual high-speed/high-yield rockets (per slot) in the "2" slots, and 1 railgun apiece in each of the "1" slots. So, not only do we need the secondaries to link together, but we need the capability to swap "active" weapons in each "bank" In tachyon, you use the tilde to link weapons, 1 to switch the first "set", 2 to swap the second "set"
(http://files.fringespace.org/rk/singweap.jpg)
Like, here. One single weapon, each "bank". That's what FS2 does now, for secondaries.
(http://files.fringespace.org/rk/linkweap.jpg)
This is what Tachyon does, for secondaries as well. (yes, it says laser in this picture, but it can do it for any weapon). See the quad circles, linked with the x in the middle? That denotes that there are 2 active weapons in each bank, linked to each other.
However, I'd also like to switch between those rockets and railguns, on a per-bank basis, as well as link them all together.
In some ships, there are actually 6 different secondary weapons banks, with 2, sometimes 3 primaries. So, even if I reversed the two, you still couldn't swap weapons in the *primary* slots, either. So, basically, I guess we're also asking for the abilty for a ship to *swap* active weapons, rather than switch between "choices" on a vertical list, as the hud displays now. If it's still unclear, I'll try to FRAPS what I'm talking about.
So, to sum up:
1. Multiple secondary *weapons* under one BANK of weapons, like primaries are able to do.
2. Linking 2 secondary BANKS together (toggle)
3. Ability to SWAP active secondary weapons out for another choice, in both the #1 and #2 secondary "active" slot. Primaries do not need to swap, at least for our mod. So, in the Warhammer's case, switch between quad plasmas and dual rails with a double keypress (per-bank, so as to minimize loadout order casualties later on :D)
That's about it, for that subject. Basically, it opens up a horde of functions for secondary weapon choice and gives you a LOT of on-the-fly selection freedom.
Make sense?
-
This thread has given me a rather crazy idea. :D
Instead of reverse afterburners it might be interesting to code thrusters to be able to use afterburner fuel (or their own thruster fuel reserves).
Then what you do is add two more directions for thrusters (backwards and forwards). Link the forward thruster to the TAB key and what you have is a fully functional forward afterburner. Link the back one in similarly and you have a working afterburner with the same functionality as the old one and an easily specifiable reverse.
Why go to all this trouble? Cause by adding forward and reverse thrusters you can set up a mod where you have no forward speed and do everything with thrusters. Which makes 6 degrees of freedom mods possible too :)
-
Just to clarify: In Tachyon (much like Jumpgate, from Netdevil), you "jump" to another place/area by flying through a spherical "tachyon gate", with pylons "generating" the "field" you jump through. Can you assign that function to a specific portion of a model (the sphere), while retaining the solidity of the rest of the model (the pylons)?
Quite easily, actually, though it's done using the distance SEXP and a waypoint rather than as an actual function of the model. Put down a waypoint in the exact center of the sphere (they're invisible, won't show up), and make an every-time-argument based event to check for distance between <argument> and the waypoint being less than the radius of the sphere. Then use the set-position SEXP with the target coordinates and you've got a working jumpgate.
It'll look something like this:
* Jump_Event
- op every-time-argument
- op any-of
# <list of ships that can use the jump gate>
- op <
- # distance
# <argument>
# <waypoint>
# 100
- op set-ship-position
# <argument>
# <exit-coord-X>
# <exit-coord-Y>
# <exit-coord-Z>
With that, any ship on the argument list will be magically transported to a specific location if it gets inside a 100-radius sphere around the waypoint.
(PS. Look, I used less-than instead of greater-than this time so people not me can make sense of it :p)
-
I did notice :)
-
Kara - Really the reasoning is that we're trying to imitate Tach's flight model
or feel to the utmost extent of our ability.
Wouldn't linking both forward & reverse to the same tab key create no movement?
Canceling itself out - and even if it did not, how would you then specify which direction you
wanted? Sounds like you'd have to have a combination of 2 keys to pull it off.
The afterburners in Tach are independant from the thrusters - so you can move
under either's power, or use the burners to add speed to thrusters already producing
any level of thrust from 1 to 100 with 0 being off of course.
The slide mechanism is also tied to this, simply stating that whatever speed and direction
you are going at - you will continue to do so with no energy use once the key is pressed.
Plus you have the benefit of rotating 360 degrees around your ship's center point.
Shade - That'll work nicely. Thanks. If we wanted to imitate what Tach does, we'd simply
expand the distance argument slightly beyond the sphere - so it acts as though the pilot had
flown close enough to touch it and be transported. But having it so that you can enter the sphere per say -
may be something new worth looking into as an exchange.
-
Wouldn't linking both forward & reverse to the same tab key create no movement?
Yes you'd need a different key. I guess I was a little ambiguous (I was rather distracted at the time I wrote that - long story). :D
The idea of using the tab key was basically so that you get the same afterburner functionality even though you're now using a different system.
-
jumpgates (http://www.hard-light.net/forums/index.php/topic,44618.0.html)
one posable implementation. you can prolbly use it as a basis for however you want your system to work.
my method requires one event to link one gate to another (in one directional travel, so two events if you want to go from gate A to B, another to go to gate B to A) in the mission. the biggest drawback is due to the way events are evaluated if you are moveing too fast sometimes you'll pass through a gate without getting voiped to the other, this is largely due to the small target reagon I have set up, the bigger the gate the less of an issue this will be. also my method needed a new sExp (wich means a new build) other implementations could be made that did not require the sExp I used, also an enter/exit type jump gate were there is a defined place were you come in and go out would be doable on the currently released versions and be relitively easy.
-
That is Tachyon's same point to point system almost exactly - the way you describe it.
It even has the same gate error every once in a while, but if it's due to the same issue I don't know.
Kara - Razor was to be by to go over the burner issue again, but looks like he's still offline ATM.
We need it on one button, basically just saying "whatever direction you are going, when you hit this -
you will go faster and use burner energy/fuel."
Does anyone know information on how that HUD GUI editor was coming along....
It was mentioned to me in a reply to an earlier post topic, but we ddin't really have any hard data
on what the status was. Just that it was been worked on by someone sometime...
-
This is our "Real Ultimate Priorities" for our eventual Beta playtesting release, that seem to need code tweaking or additions. The list above is the actual "wish" list, but these are things that we really can't do this mod without. We are in pre-alpha, and likely will be until we get all of the fighter-class ships, along with all significant fighter-class weaponry ingame, and debugged to a significant degree.
Gameplay/Controls
Afterburners:
We'd like them to be tied to which direction you are thrusting - *forward, or reverse*. NOT laterally. Perhaps an entry that defines what directions afterburner can be used in.
Or, make it $Rear AB (YES, NO)
Whatever works best.
In other words, IF you are flying forward, THEN the afterburner key/button will propel you forwards faster. IF you are flying in reverse, THEN the afterburner key/button will propel you in reverse faster - tied to the current motion state, or whether the "reverse thrust" key/button is pressed
Same key, but function determined by the state of current thrust direction (whether the reverse key/button is depressed or not). Sorry if I'm too detailed, but better to be too detailed than not detailed enough.
Reverse status
Which direction you are flying shown on HUD, current speed of EITHER forward, or reverse. If in reverse, can use the same hud display for speed, but with an additional display of which direction (or a different color for the bar?) to differentiate. In other words, when your forward speed drops to "0", while in reverse, just start over from zero and list your speed in reverse. That way, you don't need new graphics - just code that allows it "swap over" when in reverse.
I *think* this works, but there's no status indicator to delineate, or differentiate, which direction you are going. Also, you have to have the throttle at 0, in order to engage reverse. (Backslash might have the solution for this, he says.)
Weapons
Primaries
When you have disparate numbers of firing points in primary bank 1 and 2, the fire wait in the smaller number bank is made the same as the larger number bank. So, if you have a 2-point bank, and a single-point bank, for instance, the single weapon fires with the same wait as the dual, despite havigng a single hardpoint, not a dual. Would like a dual-point bank to double the fire wait, and a single point to retain it's fire wait, even when linked.
Would like the ability to link only 2 primary banks, if there are more than 2 - as well as the ability for more than 2 primary banks, with the "swap" behavior listed below available.
Secondaries:
Multi-point secondaries: Implemented. Disregard earlier posts. It is part of the game already.
However: The two firing points *alternate*, and do not fire simulataneously, like primaries do.
Linked Secondaries:
Would like banks linked by twos, each with multiple firing points, with the ability to "swap" banks, by keypress, per bank, when there are more than 2 banks available.
Charging weapons:
For the Solaris Torpedo, which depends on it's "charge time" for damage amounts given.
See also: the end of this post (http://www.hard-light.net/forums/index.php/topic,44499.msg908628.html#msg908628) - addendum: Railguns, it seems, are going to become primary weapons, and seem to fit better there.
Server/Multiplayer
Join In Progress:
Allow join of multiplayer games in progress if the server has that setting enabled (for overall functionality with other mods/conversions).
Server capacity
I would LIKE a max of 64, eventually. 32 would be alright, but my goal is 64, for a dedicated server platform. Kara and I have talked about this, I believe.
(I'd like to get this in here - not because I expect it to be done by alpha release time, but just so it can be looked at quite a ways down the line, to potentially be ready by full release time. Tachyon's main selling point was always it's MASSIVE space battles. Yes, it's intensive, but I'd rather be heavy on player ships than AI ships - especially in Multiplayer. AI doesn't last long versus massed groups of human pilots. Even smart AI.)
Miscellaneous
Tachyon Gates
Addressed eaarlier in the thread, but included for reference.
Updated: 2/17/07
-
Join In Progress:Allow join of multiplayer games in progress if the server has that setting enabled (for overall functionality with other mods/conversions).
This one is already in the code. No idea if it works or not though. Some testing is in order I suspect.
-
kara: we may do some of that tonight.
Anyone: Comments on the reverse thrust hud indication idea, or afterburners in reverse?
-
kara - both JGZ and I got this error, when joining each other's in-progress games:
(http://files.fringespace.org/rk/ingame_join_error.jpg)
Game was live, ships were in-space. When in ship loadout/selection screen, it gave the "not in proper state" (or whatever) error.
-
thats different from what I remember in ingame joining O.o
-
http://scp.indiegames.us/mantis/view.php?id=1245
That's the synopsis, with debug on.
Diagnoses, doctors? :D
-
it doesn't work.
we are rather short handed in network programmers right now.
-
Problem is that your client side error is nothing to do with the code in question. It's bad data. Get that fixed and try again.
Best thing to do is to try a coop or dogfight mission. Host a game and start it without anyone joining (Both will run without a second player unlike TvT). Once you can get the mission to run on both PCs then you can begin testing in-game joining.
-
Problem is that your client side error is nothing to do with the code in question. It's bad data. Get that fixed and try again.
Best thing to do is to try a coop or dogfight mission. Host a game and start it without anyone joining (Both will run without a second player unlike TvT). Once you can get the mission to run on both PCs then you can begin testing in-game joining.
A. "(the) client side error is nothing to do with the code in question"
1. What is "that" which needs to get fixed?
2. What data is "bad", and what does the "good" look like in comparison
3. What method is used to tell the two apart?
In other words, what tells you that (a) The data is bad, and (b) What data to compare it to (there isn't a whole lot of documentation on multiplayer in general, let alone this experimental feature) and (c)
B. Hosted game works, and plays, with one player, or two. Done. That's why we're testing it. It's the stock "The Gauntlet" mission, modified to use our unique ships, and *only* for those ships.
C. Did you see the MANTIS report, with the server-side info?
I have the errorbox code from the client, and the server-side debug spew listed in that MANTIS report.
Could you be a bit more specific as to what you mean? You asked me to go ahead and test the features I wanted to use that were experimental or not-quite-implemented - so that's what we're doing :D
Bobbau:
Yeah, I figured :D
But, seriously, kara had talked to me about this in another thread, and on IRC.
he said (http://www.hard-light.net/forums/index.php/topic,43310.msg887171.html#msg887171):
I'm happy to answer any questions you have as long as you'll report any multiplayer bugs you find.
So, that's what we're doing :D Plus, he said "some testing is in order", earlier in the thread :D
-
We're short multiplayer coders so I'm slowly taking on the role until I can find someone to replace me. To that end I'm happy to at least try to help with stuff like this as it is a feature I'd like to see working in BtRL as well.
Razorkiss, the problem with your mantis report is that the error you've reported is this one
Client-side error box:
Warning: Couldn't load bitmap thruster02-01
That's not a multiplayer error. That's caused because either you haven't turned on JPG and TGA textures on that machine or you're missing the thruster textures.
So reporting this error doesn't help me much. It could be that once you fix this error in-game joining works perfectly.
What I was asking you to do is to run missions through the debug version with only one person playing the mission so that you eliminate errors like this one. Once you've got it to the point that "The Gauntlet" runs perfectly on a debug build if one player starts the game then you can try in-game joining as you'll now know that any errors you see are actually due to in-game joining and not due to bad data or a code error somewhere else in the code.
-
We're trying to make a ship fire 4 secondary weapons simultaneously.
I have 2 multi-firing point missile banks set up, naming each bank missilebank-x.
Each bank has two firing points linked to it, and they both work, in each bank - however, they fire alternately, not simultaneously, with no "cycle" flag on the weapons.
Can two secondary firing points fire simultaneously? If not, what needs to be changed to "make it so"?
Also, we're looking for the ability to link multiple banks together, in groups of two, and two only, and switch banks via keypress, should a ship have more than two secondary banks.
So, in the end result, we want to fire all firing points contained within the two selected, linked, banks, simultaneously - and switch banks to an alternate "set", if available.
-
"Priority" listing updated (http://www.hard-light.net/forums/index.php/topic,44499.msg911539.html#msg911539)