Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: WMCoolmon on September 20, 2005, 03:29:20 am
-
Well? Get to it! :p
-
Import Background button in FRED :D
And a flip Icon button for the briefing window.
-
Change Asteroid-Field t'sphere instead o' current cube. I guess X,Y,Z coordinates are still possible then (a little older request by me, but I thought I give it another try :) )
(edit) I forgot, Arrrgh Matey :D
-
support for different resoultions and aspect ratios
specifically 1280x800 widescreen
-
export current background to a .pof in FRED?
-
Originally posted by Ransom Arceihn
How doable would a set o' SEXPs that do these things be?
- Add/remove background bitmaps an' suns
- Switch th'mission t'a nebula mission (or aft t'a normal one)
- In a nebula mission, change th'Lightnin' Storm setting
- Change th'selected Poofs
...also, would it be possible t'make th'Ambient Light settin' functional (or otherwise make it possible t'define ambient lightin' on a per mission basis)? [/B]
Arr.
-
Originally posted by Ransom Arceihn
Switch the mission to a nebula mission (or after to a normal one)
I don't see that one in the near future. There would be no way to transition smoothly from neb to non neb, not to mention in non neb missions the textures don't get paged in, among many other things.
-
I think you told me to bump this thread after the code freeze. ;)
http://www.hard-light.net/forums/index.php/topic,34385.0.html
-
Originally posted by Sticks
There would be nay way t'transition smoothly from neb t'non neb.
That's not a problem for me. But if thar be other technical reasons why it can't be done that's fine.
Although if that one can't be done then it kind o' cancels out th'rest for me (at least for what I want to use it for in the near future), I guess I'll have t'find a way around it.
-
is it possible to have different colors of light from different sides, like, say theres a blue nebula on one side, and a green nebula on the other side, is it already possible to have blue light coming from one side and green from the other?
i'll bet this is already possible and i'm just making myself look dumb
-
Originally posted by Black Wolf
And a flip Icon button for the briefing window.
Ack! A sekret feature has been requested before it has been released! :(
-
Originally posted by Ransom Arceihn
That's not a problem for me. But if thar be other technical reasons why it can't be done that's fine.
Although if that one can't be done then it kind o' cancels out th'rest for me (at least for what I want to use it for in the near future), I guess I'll have t'find a way around it.
Well i think thats the only tough one really. Were you planning on having it appear and disappear or have it fade in from nothing?
-
Ack! A sekret feature has been requested before it has been released! :(
This will allow you to horizontally flip the icons so they face the right direction? You know, I was going to ask for that myself about a year ago but forgot about it. :p
-
A bloody dynamic LOD system! :D
-
Originally posted by Turambar
is it possible to have different colors of light from different sides, like, say theres a blue nebula on one side, and a green nebula on the other side, is it already possible to have blue light coming from one side and green from the other?
i'll bet this is already possible and i'm just making myself look dumb
create invisble suns in the stars table and add $NoGlare: to the end so they don't whiteout the screen when you look into them.
-
Originally posted by Sticks
I don't see that one in the near future. There would be no way to transition smoothly from neb to non neb, not to mention in non neb missions the textures don't get paged in, among many other things.
Transitioning is easy (use the fade-in/fade-out SEXPs) and paging in could be done based on something else other than the mission flag.
-
wxFred :nod:
*wants to be able to ditch windows ASAP*
-
Originally posted by CP5670
This will allow you to horizontally flip the icons so they face the right direction? You know, I was going to ask for that myself about a year ago but forgot about it. :p
I already did ask for it a year ago :p (almost dead on actually)
http://www.hard-light.net/forums/index.php/topic,19985.msg393499.html#msg393499
[EDIT]I know I didn't personally request this, but I remember someone did - nebulae lightning (possibly with the option to have sounds on/off) without actually having a full neb - would be brilliant for missions set in unstable subspace nodes.
-
TBP could use a method of simulating the focusing effects for the Vorlon ships and the Victory. I had 2 ideas on how to simulate the effect, but I much prefer the 2nd idea. I explained my ideas in THIS (http://www.hard-light.net/forums/index.php/topic,34951.0.html) thread. It uses a system of secondary beamglows and beams focusing towards the main beamglow, with a bit of a delay between the two, so the secondaries warmup before the main one does.
Broader support for Multi-species, with additional options.
Broader support for mulit-docking.
Customizable icons table classes, rather than the different classes being hard-coded by type and location in the list.
Customizable (rather than hard-coded) warp sequences, like warpout speeds, which are determined by class flag ATM. Ability to disable the visual warping effects, without losing the accel/deceleration effects when you use the current option to not show the effects.
change-turret-weapon
That's all for the moment.
-
Originally posted by PhReAk
Well i think thats the only tough one really. Were you planning on having it appear and disappear or have it fade in from nothing?
From a technical point of view, just switching without transition.
Originally posted by WMCoolmon
Transitioning is easy (use the fade-in/fade-out SEXPs)
That's what I figured.
-
Originally posted by Trivial Psychic
Broader support for Multi-species, with additional options.
All the species-specific stuff is now in species_defs.tbl; nothing is defined in the code anymore. What were you thinking of?Broader support for multi-docking.
Broader than what we have now? :wtf:
-
I'd really like to have the ability to use Nebula Lightning effects in Subspace missions. :(
-
Originally posted by Goober5000
Originally posted by Trivial Psychic
Broader support for mulit-docking.
Broader than what we have now? :wtf: [/B]
A Fred build that supports it would be nice if one doesn't already exist, but more importantly something should probably be done about the fact that when 2 or more powered ships are docked to another one, the whole mess wiggles around like there's no tomorrow. Or do I need to take that to Mantis?
-
Originally posted by StratComm
A Fred build that supports it would be nice if one doesn't already exist
In the works.but more importantly something should probably be done about the fact that when 2 or more powered ships are docked to another one, the whole mess wiggles around like there's no tomorrow. Or do I need to take that to Mantis?
That's really rather impossible to fix, and you run into this in retail too. Just use sexps to ensure that only one ship is powered at a time.
-
Originally posted by Trivial Psychic
TBP could use a method of simulating the focusing effects for the Vorlon ships and the Victory. I had 2 ideas on how to simulate the effect, but I much prefer the 2nd idea. I explained my ideas in THIS (http://www.hard-light.net/forums/index.php/topic,34951.0.html) thread. It uses a system of secondary beamglows and beams focusing towards the main beamglow, with a bit of a delay between the two, so the secondaries warmup before the main one does.
It strikes me that this sort of effect would be of particuar importance for a certain vessel in the Star Wars mod, as well. :)
-
Originally posted by Goober5000
That's really rather impossible to fix, and you run into this in retail too. Just use sexps to ensure that only one ship is powered at a time.
Which is strange, because if I dock a bunch of ships in-mission to one "carrier" there's no jitter. It's only when they start out that way that things go crazy.
-
Originally posted by StratComm
Which is strange, because if I dock a bunch of ships in-mission to one "carrier" there's no jitter. It's only when they start out that way that things go crazy.
Oh, well initially docked ships aren't quite set up yet. Maybe you're experiencing that bug instead.
-
Ah, ok. That would explain it then :)
-
Originally posted by Goober5000
All the species-specific stuff is now in species_defs.tbl; nothing is defined in the code anymore.
There's still things like default iff. I recall during the early days if multi-species introduction, Kazan was trying to setup a matrix to allow a system of relative iff, to designate how each species should handle each other by default: species C is hostile to species E and friendly to species B, and species E is considered unknown to species B... that sort of thing. Also, color designation, from how they should be colored in the FRED drop-down ship selection, and if there should be any special species colors on the hud (and escort list, etc.) Also, the abilty to designate a different warp effect to a different species.
Of course, in the short term I'll settle for getting it stable. :D
-
That really should be handled based on IFF changes rather than species_def changes though. All the species_def should do is set the default default iff.
I presume that's what you mean but it's a little hard to tell.
-
Do we have multiteam support yet? Like A and B can be hostile to both each other and C, etc. So the player could have 2 enemies that are hostile to each other.
-
Teams work like this AFAIK.
Friendly.
Hostile (hates everyone except unknown)
Neutral (Hates Friendly - ignores hostile even when attacked by them)
Unknown (Won't attack or be attacked by anyone unless specifically ordered).
In addition to that you have all teams at war where everyone tries to kill everyone else.
The situation Aldo describes could be done using all teams at war but if you want something more specific than that you've got to do a lot of complex SEXPing using the AI-Chase-Any-Except SEXP.
-
[q]
Neutral (Hates Friendly - ignores hostile even when attacked by them)[/q]
Was it not that Neutral ignores friendly? I'm sure we used that for a mission in CoW (the one with the cargo convoy).
-
Neutral was used for the HoL in FS1--they hate Friendlys (attack GTA and PVN) and ignore Hostiles (Shivans)
-
Originally posted by Trivial Psychic
There's still things like default iff.... Also, color designation.... Also, the abilty to designate a different warp effect to a different species.
Ah, I forgot about FRED. Yes, those will be added.
As far as the IFF matrix goes, that as karajorma says is in the IFF department. I've been planning an iff_defs.tbl for some time and now that the code freeze is done I'll start working on it.Originally posted by Galemp
Neutral was used for the HoL in FS1--they hate Friendlys (attack GTA and PVN) and ignore Hostiles (Shivans)
Indeed; they should have called it something more descriptive than Neutral.
As far as IFFs are concerned, I think only the following need to be specified. Does this sound correct?
Team X:
--Attacks Y
--Attacks Y Only When Ordered [by add-ai-goal or comms]
I'd have to look in the code to double-check, but if that's the case we can specify iff_defs.tbl like so:
$IFF Name: Friendly
+Attacks: ( "Hostile", "Neutral" )
+Attacks Only When Ordered: ( "Unknown" )
$IFF Name: Hostile
+Attacks: ( "Friendly", "Neutral" )
+Attacks Only When Ordered: ( "Unknown" )
$IFF Name: Neutral
+Attacks: ( "Friendly" )
+Attacks Only When Ordered: ( "Unknown" )
$IFF Name: Unknown
-
One suggestion. Add the colour for the team to the IFF_Defs. It will would be really useful for missions with traitors in them to have them appear as the same colour as friendlies when they first attack rather than having to switch them to red as soon as they begin the attack run.
That way you can specify ships that seem to have friendly IFFs right up until command figures out that they are attacking cause they've gone rogue.
It also gives you a way to allow the player to kill traitors as soon as he figures out who they are without having to make it open season on everyone by using the no traitor flag.
-
Right, good idea. :)
So
$IFF Name: whatever
$HUD Color: ( r, g, b )
+Attacks: ( "iff" )
+Attacks Only When Ordered: ( "iff" )
+Cargo Known By Default: [YES | NO]
It just occurred to me that I might be able to allow either "color" or "colour". ;) Same for $FRED Color in species_defs.
-
Other suggestions:
Either Gunship AI, or poor-man's-gunship-ai... ie, the use of "target big" and "target big no bomb" flags, so that heavier anti-cap weapons will target the bomber or fighter craft using it.
The ability to select specific ship fighterbays for arrival or departure.
change-skybox-pof sexp
That's all for now.
[Edit]
I forgot about bank-specific cycling and varied cycling. Basically, as we have it righ now and flag is used to enable cycling between primary fire-points, but it will enable it universally throughout the model. Furthermore, all firepoints will cycle in series. For example, if you have a bank with 4 firepoints, it will fire 1, 2, 3, 4 and then repeat. I'd like the ability to fire 1 and 3 at the same time, then 2 and 4, and repeat. I'd like to see the ability to select how many firepoints in a bank will fire at once, a numeric sequence to indicate which ones should fire together, and of course, a way to indicate which banks you want to cycle, and which banks you may not, or may wish to cycle in a different pattern.
[/Edit]
-
Why not add it to species_defs.tbl?
-
Originally posted by Trivial Psychic
change-skybox-pof sexp
Ummmmm. That one's already in FRED. Have a look at the Change>>Special SEXPs
-
Oh. OK. Here's another... allow the render distance between nebula poofs be changeable in FRED. We currently have an option for what the sensor radius is, but not render radius.
-
Lets see....
Well this (http://www.hard-light.net/forums/index.php/topic,34751.0.html) thread has something I would like to see... Did we decide anything regarding the hulks by the way? The discussion just stalled in mid air, so to speak...
Support for multiple medal cases would be nice. Mentioned in this (http://www.hard-light.net/forums/index.php/topic,34851.0.html) thread...
The manouvering thurster stuff we talked about in here (http://www.hard-light.net/forums/index.php/topic,34831.0.html)...
Improving the asteroids, like sliders for setting the amount of different asteroids in a field.. See this (http://www.hard-light.net/forums/index.php/topic,34536.0.html) thread.
Hmm... I think thats all for now...
-
just a thought: would it be possible to be able to assign cut scenes to be played (before or/and after the mission) in FRED rather than in the campaign editor (which is very limited anyway as far as I am informed.)
-
Here's something I just thought of, taht would greatly allow fredder's to increase the dramatic effect of there missions: subspace 'escape' velocity control.
Remember the lucifer in the FS1 cutscene? The major impression of scale in that picture was the slow speed at which it exited subspace. to duplicate that sense of scale by controlling the exit velocity of any ship in a mission (and having it to that ship only) would greatly add to dramatic effect for certain scenes - not to mention would be incredibly usefull in the creation of cutscenes. having the option to create a subspace 'wave' that causes the camera or any ship near the special 'warp' as the ship exits would add to this even further.
Just food for thought.
Oh, that, and stencil shadows!!!
-
Originally posted by Tolwyn
just a thought: would it be possible to be able to assign cut scenes to be played (before or/and after the mission) in FRED rather than in the campaign editor (which is very limited anyway as far as I am informed.)
The campaign editor is FRED. And it lets you do everything you can possibly do with the campaign file.
-
Originally posted by Goober5000
The campaign editor is FRED. And it lets you do everything you can possibly do with the campaign file.
Does that mean that there is now no limitation for the number/naming of the cut scenes?
And what about stand alone missions? I doubt you can run 'em through the campaign editor :)
-
Originally posted by Tolwyn
Does that mean that there is now no limitation for the number/naming of the cut scenes?
There never was. :confused:And what about stand alone missions? I doubt you can run 'em through the campaign editor :)
Just make a campaign with a single mission.
-
Originally posted by Goober5000
There never was. :confused:
I remember reading something in the project discussion forum... :confused:
-
Tracking primaries! <-- Priority 1.
-
Originally posted by Carl
Tracking primaries!
No.
-
Variable duration player-fighterbeams.
Basically, by setting the firewait and/or beam duration to -1 will result in the beam firing only as long as either A ), there is weapons power to sustain it, or B ), the player has the fire button pressed. That way, if you only want a short burst, just tap the trigger, but if you want a sustained beam, hold it down until either your target is destroyed or the weapons energy is depleated. This would be very useful for the Whitestar in TBP.
Remove the need for player-craft to have secondary firepoints, either on the models or in the tables.
Allow variables to be used in (command) briefings (persistant variables obviously) and debriefings.
-
change-turret-weapon
As in, swap out the weapon on a turret for another? Or switch the preferred weapon to another?
-
So, uhm... what about this star stuff I suggested a while ago?
http://www.hard-light.net/forums/index.php/topic,34385.0.html
The game would gain a lot by having a feelable speed.
-
Yeah, I actually thought about asking about that.
I was going to reread it tomorrow, after sleep, because I didn't get what you were talking about (although I seem to remember I did the first time I read the thread. :p)
-
Originally posted by WMCoolmon
As in, swap out the weapon on a turret for another? Or switch the preferred weapon to another?
As in, the ability to change the weapon mounted on a turret via SEXP, in mission.
-
[Random thought]
I don't know if it's already possible or not, or even if it requires coding, but...
I'd like the addition of a limited warp drive. A secondary booster if you will. It takes energy from a different energy hold than the booster, doenst last for more than a second or two(in that time you go a few kms), and has a very slow recharge.
Might make some battles interesting and might aid in the Star Trek conversion. I think it would be cool to see ships warp away when in trouble, or fail to.
I know I can do this by just changing the booster speeds in the .tbls but I'd rather not compromise those variables. All of this of course would need tweaking to make it work, but I'm in class right now and can't really doing other things ...much.
[/random thought]
-
One thing i would love to have at some point is the ability to save and load different default loadouts for ships that automatically assigns all the turrets and/or hardpoints their weapons, so you don't have to constantly go through and change each and every turret again and again.
For instance, you could have a Fenris, and its saved loadouts could be its FS1 weapons and its FS2 weapons, and you can switch between then by just selecting it from a drop down menu.
This would require a bit of GUI modification in C++, but i think it would really benefit mission designers, especially when you have one ship with several possible configurations.
-
Auxiliary engines!
what's this all about?
Basicly like a normal engine subsystem oinly it's dormant - no engine glows, no nothing.
You can activate it with a SEXP later in mission.
Would be cool when a ship get's it's engines blown it activates it's auxiliary ones and starts moving (slowly)
That said the speed entry should have two numbers - 15(5) like normal speed and auxiliary engines speed.
On another note how about actually doing some engine calculations??? By that I mena reducing a ships speed as engines get blown. How to do that? simple - by engine wash entry - it gives a good overview of hte power of the engine.
So engines wash + engines wash + ... = total wash
When engine03 get's destroyed you calculate how much % thrust it was giving (using engine03 wash and total wash) and reduce the top speed by that much.
Needles to say that if all engines are operational and you turn on auxilliary ones the ships goes faster (15 + 5)
-
Trashman, go blow out engine subsystems on a moving capship and see if it keeps clicking along at top speed. Asking for features is one thing, asking for features that have been there since FS1 is quite another.
-
Hm...how come I haven't noticed that....:hmmm:
My dab then..
Well, auxiliary subsystems was not there at least...
-
damage heirarchy
make it so that you can set up links between subsystems. so that you can have parts of a ship that may be shot off an would take out any other subsystems linked to it. for example if you have a wing subsystem with a number of turrets on it and you destryo the wing, it should take the turrets with it. id imagine adding "+subsystem dependancy: subsystemname" tags to each subsystem that requires another for its operation. if a system is destroyed, anything with a dependancy tag for that system is also destroyed. i imagine quite abit of versitility with this.
-
Originally posted by TrashMan
Well, auxiliary subsystems was not there at least...
Its not there, but it has been requested before. If implimented, it would be made part of Tertiary Systems (go to THIS LINK (http://dynamic.gamespy.com/~freespace/fsdoc/index.php?pagename=Weapons%20changes) and scroll to the bottom of the page), which are PhReAk's domain. Unfortunately, Tertiaries have been put on the back burner and turned down to simmer for the time being. Don't expect any broad-scale implimentation of this any time soon.
-
Originally posted by Goober5000
No.
No aspect or heat seeking primaries? Bah! :p
-
Could we lock the positions of every ship when in FRED's breifing mode? It's really annoying when I want to move an icon and then move a ship instead. Even more so when a jump node likes to take up 5 times the space and not let me select anything else.
-
Originally posted by Axem
Could we lock the positions of every ship when in FRED's breifing mode? It's really annoying when I want to move an icon and then move a ship instead. Even more so when a jump node likes to take up 5 times the space and not let me select anything else.
The man makes a good point. A very good point.
[EDIT] - Actually, a checkbox allowing you to lock and unlock the ships in the briefing would be best. It's sometimes useful to be able to move them around, in a carefully controlled manner.
-
Seconded on the locking ships in the briefing.
Here's a new feature idea:
Rotation settings for skyboxes. Allowing the FREDer to rotate the skybox .pof like a ship model.
-
One other feature:
Enable glow map (map name) SEXP.
Turning on or off all of the maps is great, but there are cases where turning off say one glowmap is needed. A good example is say when the Golgotha's meson reactor is powered down, having only that glowmap off adds to the effect.
Another example would be when the Charon comes online. The installation portions are working, and so should have glowmaps but the Knossos segments should light up with each stage of activation.
-
Originally posted by Trivial Psychic
Its not there, but it has been requested before. If implimented, it would be made part of Tertiary Systems (go to THIS LINK (http://dynamic.gamespy.com/~freespace/fsdoc/index.php?pagename=Weapons%20changes) and scroll to the bottom of the page), which are PhReAk's domain. Unfortunately, Tertiaries have been put on the back burner and turned down to simmer for the time being. Don't expect any broad-scale implimentation of this any time soon.
why are they handeled as tertiaties? After all it's just anotehr subsystem..
-
silly me how could i forget:
gatling turrets :D
-
You asked for it:
Here's what I want in ANY space sim. Make of it what you will.
[list=1]
- Mission Interrupting Events (Red Alerts that pop up during a mission)
- Multi-area missions using Wing Commander style waypoints.
- Player use of freestanding jump nodes for transiting between systems during a mission
- I-war2 style virtual HUD (a)
- I-war2 style sortable contact list (requires a single contact list comprised of all targettable objects)
- Smooth views (ie: freelook/mouselook)
- Simulation system (b)
- Manual launch/landing sequences. Sim style or Wing Commander/Starlancer style, should be toggled by a difficulty setting. Three settings: [none|arcade|sim]
- Dynamic Asteroid Fields (generated by freestanding particle system and LOD system) (c)
- Modular object system (Iwar2 style)
- Scripting system with SEXPs implemented as prewritten functions in the scripting language
- Modular plugin system (major game system components as loadable modules)
- Gravitational attractors (NOT a proper gravitational system, which would be too complex)
- Iwar2's dynamic universe system (e)
- Iwar2's model animation system (f)
- Resource/Mod files packaged as ZIP (g)
- Remove distinction between primary, secondary (and the proposed tertiaries) (h)
Longer explanations:
(a) Virtual Hud: Iwar2 has a virtual HUD system. In game, the HUD is projected on the pilot's visor. What this means is that HUD elements are painted last, atop everything else, including the cockpit. When implemented with a freelook, this can be a very good thing.
(b) Sim Mode: a setting wherein collisions are modelled accurately, the player is required to monitor damage and energy levels in real time, and things like heat are taken into consideration. Jane's Advanced Tactical Fighters is a Sim. Crimson Skies is a shooter. In space combat games, Iwar2 is close to a sim, but not quite. Freespace is more of an arcade shooter.
(c) Dynamic asteroid/debris/etc field: fields are placed in the playing area as a volume object; a sphere for example. The game engine knows that sphere object represents a field of some sort and looks up its [INI|Table|Registry|Mission] entry where it reads a field type (asteroid, debris, nebula, etc), a field density, and a model/poof file pool. (Note: this is Iwar2's nebula/debris system)
(d) Modular model system: more than just one model for a turret used by many ships, its also a matter of the ships themselves. When a ship is listed as having three EXTERNAL heavy weapons hard points, placing weapons on those hard points should result in an outside view of the ship reflecting these changes. Internal hardpoints do not show. This is not very important for the player's ship, but it is important for all the other ships in the game, since an experienced pilot will learn to tell what sorts of equipment a ship is packing by looking at its profile.
(e) Iwar2's Dynamic Universe System: Not useful for a skirmish oriented game like Freespace. However, for a game that has a freeflight mode, its critical. In a dynamic universe, systems and installations have traderoutes, patrols, intrasystem business, radio chatter and the like. Iwar2 models this by creating a horizon based universe with the player at the center. There are three nested spheres to this horizon system:
--Anything within the outermost radius is simulated somwhere in the engine. Movement is calculated, etc.
--Anything with then the next smaller sphere shows up on the longest range sensors, and may be affected by the player. Players with sufficiently strong sensors etc, can target objects in this radius, and will see them in the contacts list and radar. Not everything in this radius is going to be rendered. It depends on size.
--Anything in the nearest radius is visible (IE rendered full time) and can trigger sound events.
(f)That's a whole long explanation by itself. Short version: every event that can be triggered by the pilot (CPU or human) can trigger an animation channel. Pitch, roll, yaw, accelerate on X, Y or Z axes, fire primaries, fire secondaries, etc are all candidates. In the [INI|Registry|Table], a list of animation channels have special instructions for motion on the object. In Iwar2, the most obvious example of this is Tug. When the player accellerates either Z+ or Z-, the four engine pods rotate forward or back. I've built ship models where if the player rolls, the engines rotate away from the roll and emit thruster cones.
(g) Modding and testing of mods in games like Iwar2 is made easier by handling the resources as a directory tree stored in a zip (or out of a zip, Flux--the Iwar2 engine--will read both, with unzipped data taking precedence over zipped). Users can just open the zipped resources directly and work with them with any standard compression tool (like, oh, XPs compressed folders, *nix's zip packages, Mac's stuffit, et al). It isn't as if plucking resources out of a zip file is precisely slow, and it does allow for alot of flexibility. Is there something useful to the VP system I am unaware of?
(h) Implement three triggers, and let the player assign weapons to each. The "cycle primary" and "cycle secondary" buttons will select through the various weapons assigned to those groups. Countermeasures are a kind of weapon under this system.
-
Originally posted by mikhael
... :eek2: ...
:eek2:
-
yes i would like rendering capabilities with million-puly models and 10240^2 64 bit textures. oh and i want ai that is smart enought to take over the world if it ever managed to get out of the constraints of the game engine. :D
-
Originally posted by Sticks
:eek2:
What?
Every single item in that list has been implemented before in at least one major game, most of them have been in several.
-
Originally posted by mikhael
Every single item in that list has been implemented before in at least one major game, most of them have been in several.
Major games that have been specifily built, using lots of money, to support those features...
-
What would be really cool is some sort of non CTD error for ships without a docking point calling in a support ship. Presently, any fighter without a support ship docking point which calls for support crashes the game, including AI ones. A better solution would be for the game to check for the presence of a dockpoint before allowing the support ship to jump in once its been requested. If the dockpoint isn;t there, you get a little "This class of ship can not be resupplied" error.
Consider, for example, stuff like Aldo's space suit. Allowing the support ship to dock to it would be as bad as the CTD...
-
Originally posted by Black Wolf
What would be really cool is some sort of non CTD error for ships without a docking point calling in a support ship. Presently, any fighter without a support ship docking point which calls for support crashes the game, including AI ones. A better solution would be for the game to check for the presence of a dockpoint before allowing the support ship to jump in once its been requested. If the dockpoint isn;t there, you get a little "This class of ship can not be resupplied" error.
Consider, for example, stuff like Aldo's space suit. Allowing the support ship to dock to it would be as bad as the CTD...
That's more of a bug report than a feature request. Mantis it. :)
-
Righto then.
[EDIT]Oh, well, if the last ones a bug maybe this is too (though I suspect it's on the bug/feature border). Is there a specific reason why ignore-ship AI behaviour is greyed out for capships? All it would need to do would be to prevent turrets firing on the ignored ship, but for some reason [V] decided it wasn't important enough... I'm kind of curious as to why, and whether it might be feasible to get it turned on?
-
Originally posted by Prophet
Major games that have been specifily built, using lots of money, to support those features...
And?
-
I've got a feature request. How about support for alternate keyboard layouts? I use a Dvorak layout keyboard and it's annoying that I can't type using the layout I use. I'd like be able to just use my existing layout without having to remember which keys in Dvorak layout match up to which standard layout keys.
-
if i ever get the gatling turret feature, how would it be implemented, through the vwep system or something else? im revising some of my capships and am curious as to how to procede with designing their turrets so that they will be compatable with the feature should it be implemented.
-
In regards to the gattling turret feature, aren't the flak turrets already gatling style, at least in rate of fire?
Beyond that, I'm guessing that this feature request might be related to The Babylon Project, based on what I remember of B5's armaments and defense grid?
-
no, flak turrets dont have cool spinning barrels that tell whoever they are pointedat that they are about to die. the rate of fire of the flak guns in this game cant even match a browning .50 cal, let alone a gau-8, wich has a fire rate of about 70 rounds a sec. i mainly want the rotating barrels when the turret fires, they looked cool in descent3 and freespace should have them to. and this feature request is for nukemod, wich is accidently turned into a major campaign, im sure there are many other mods out there that would use them.. :D
-
Dude, do you have ANY idea how many polies it would take for that? You'd end up killing the framerates for any mission in which a capship had those. It's why all the turrets in FS2 have so little detail. During development, they had some high poly turrets and it didn't work well at all.
-
During development they didnt have HTL.
-
During development they considered people who don't have supercomputers.
-
Regardless of that, I'm just not sure that it's terribly practical.
That's some fancy animation you're asking for combined with very high polygon counts in an object that not only has to spin its own barrels, but also has to move in alt/azimuth fashion on its base. This is asking a lot from the game and from players' machines, even from the top end ones.
-
4-barelled gatling, using intersections (rather than a single solid welded set of faces) would take, I dunno, about 50-100 faces?
(4 barrels, diamond shapes, is about 4*4*2 = 32. Assuming we have a pentagonal or hexagonal base... well, I can't be arsed working the exact value, but 100 would be a reasonable budget. Using submodel loding for high detail at close range, with sensiby high smoothing angles, and you'd be able to easily do it)
NOTE/EDIT; that's assuming each barrel is individually modelled, of course, rather than the usual method of just texturing an xx-sided cylinder (which would be the most sensible way for turrets IMO).
-
Yes, but four barrels wont work for a gatling. Even a minigun has six.
(http://mgs.gry-online.pl/mg/real/minigun.jpg)
And the bigger the gatling, the more barrels you need to maintain rate of fire, because a larger size means it's harder to rotate them as fast.
-
Still not a significant problem. Especially with sub-object Loding. And I'd note with that many barrels, you can quite easily have a textured cylinder fill in for it with virtually no visual difference at any sensible viewing range.
Physics of a gatling gun don't matter, of course, because it's a game. Set in space. 3 centuries in the future.
(I have actually looked into this, y'know.........)
-
Oh no!
Noobs complaining about performance degradation - what has the world come to? (exasperated sigh)
Check out the specifics the SCP boys already managed, or take a look at Omniscaper's Death Star model.
The engine is really capable and a lot of LODing methods were introduced that make even very high poly models efficient to render.
-
Reasonable distance, now there's a fascinating but ultimately meaningless concept.
"Why?" you ask.
Well, I know I can't be the only one who skims the surface of enemy warships blasting turrets at point blank so that I can't be shot down while I'm destroying them.
-
Originally posted by Flaser
Oh no!
Noobs complaining about performance degradation - what has the world come to? (exasperated sigh)
Oh no! Jackasses who don't know the difference between a n00b and an experienced beta tester voicing legitimate concerns based on his experience.
The problem is not in the standard but in the specific type of model.
Even if he's willing to do a textured cylinder for the purposes of keeping the polies down and making the animation easier, sooner or later, someone's going to decide to go nuts and do a full detail gatling because they can't stand what they consider the half-assed job done by the original modder, never bothering to consider that maybe there was a reason he didn't go with a full detail turret model that didn't include laziness. Then that person is going to b***h about how their game goes really slowly when there's a capship around that has gatling turrets. What's more, said person will never willingly admit that he has the custom model in there because of course, it couldn't be anything he did...
-
But, the modder could just use the cylinder as the lower poly model as a default turret, and then use subobject LODing so the higher poly one appears once your within like 10m of it. Far away it'll use less polies, but once you get right next to it, you'll be able to see the whole high poly thing.
-
Now that's reasonable. Unfortunately, you also get n00b modders who don't understand the concept of distance dictating detail levels. Still, it eases concerns that someone would feel the need to create a full detail model and never bother to crank down the detail at distance.
-
Originally posted by CaptJosh
Reasonable distance, now there's a fascinating but ultimately meaningless concept.
"Why?" you ask.
Well, I know I can't be the only one who skims the surface of enemy warships blasting turrets at point blank so that I can't be shot down while I'm destroying them.
Submodel loding.
Also, skimming implies speed, which implies a reduced ability to view the full detail of a highly detailed model; this goes back to using cylinders rather than individual (discrete) modelled barrel tubes.
Originally posted by CaptJosh
Oh no! Jackasses who don't know the difference between a n00b and an experienced beta tester voicing legitimate concerns based on his experience.
The problem is not in the standard but in the specific type of model.
Even if he's willing to do a textured cylinder for the purposes of keeping the polies down and making the animation easier, sooner or later, someone's going to decide to go nuts and do a full detail gatling because they can't stand what they consider the half-assed job done by the original modder, never bothering to consider that maybe there was a reason he didn't go with a full detail turret model that didn't include laziness. Then that person is going to b***h about how their game goes really slowly when there's a capship around that has gatling turrets. What's more, said person will never willingly admit that he has the custom model in there because of course, it couldn't be anything he did...
And we can't restrict features because of what might be done with them. Some daft bastard might want to make a series of 20,000 poly, unlodded destroyers; that doesn't stop HTL and increased limits being a good thing. If you take away responsibility for addressing these types of issue from the artist, you have to take away a lot of their freedom. I'm not some daft bastard who assumes he can make anything he wants and blames problems upon the game; I'd rather not have my options constricted by those who are.
Not to mention - we can choose what mods to use. In your little example, that mod would simply never be used (or indeed adopted for the HTL packs if it was a stock remake).
-
freespace already supports gatlings through the vwep system, they already work in my mod, i just want to make it possible to put them on turrets. they dont slow up the machine much at all. i can make a good looking gatling gun model with less than a hundred polys but make em 2-3 times more detailed for cool factor.
i was also curious about lod-ing on vwep models, i know they have a detail distance but i was wondering if lod model for them were posible, it would alow for a smoother transition.
-
My opinion is that a balance needs to be struck between feature availability and the capability of an artist outstripping her wisdom in using that capability. Reach exceeding grasp is all well and good, however, without direction, you end up with problems. Perhaps this isn't a very popular view.
I suppose another approach would be to have a sort of modeler's bible, a document having basic guidelines for making models for FS2 Open, including things like a request for courtesy to those with less capable computers by including level of detail mapping or whatever it's actually called(You can tell I'm not a modeler). A statement to the effect of "While this may take more work, the results are more than worth it, and you'll avoid being nagged to go back and do it later," would be a good include it the end of that section of such a document.
-
AFAIK no-one forces anyone to use mods, so I don't think feature availability should ever be compromised.
It's not the job of the coder to tell a modeller what not to do any more than it's the job of a modeller to tell a coder what not to do. This is not some application being designed for the lowest common denominator, after all; there's an inherent basic understanding that can be reasonably expected from people making any kind of content.
-
Still wouldn't hurt to have some sort of docs so as to let the old hands pass their wisdom on to the new guys. That way they can learn from the mistakes of others. After all, you can never live long enough to make every mistake on your own. :D
-
No more.
Going to split out the idiots replying to the idiots.
Be civil or don't post.
-
200 polies isn't going to be as much of a problem as multiple textures.
-
I was being civil. I merely used a paraphrase of an old expression. "Learn from the mistakes of others. You'll never live long enough to make them all yourself." It's an old adage, tried and true. I only got snarky at the gentleman (and I use the term loosely) who called me a n00b.
I merely make the suggestion that a guide to FS2 Open modeling would be good for the community as a whole. People would have a list of what already has been tried and won't work. A list of things to try, etc...
It's rather like the EV Nova Bible for learning Nova Control Bits and other things for making mods for that game.
-
When I meant, n00b I meant it as someone new to the SCP engine.
It is a open source, open development engine and is usually way underrated IMHO.
There are some really unorthodox menthods in it, and in some aspects it is way ahead its time.
The feature I meant for you to check out was Bobbau's detail box redering.
I makes it possible to have really high poly subobjects.
Unlike general loding it will only show up if the said subobject is within a set radius.
By putting boxes into boxes (something I frequently call recursive detail boxing) you can make it so, that the more and more detail shows up seamlessly as you come close; but only a couple of high poly models will be rendered at any given time.
(So the viola next to your cockpit on other side of the brige's window, the captain; but not the CD-collection of the XO whose stuff is on the other side of the room 20 meters away).
-
Next time, try to put things more constructively, please. The term n00b is going to be inflamatory to any experienced gamer/beta tester/webboarder. And it most deffinitely is going to be offensive to someone who can compile and install applications from source on Linux. :D
-
Originally posted by CaptJosh
I merely make the suggestion that a guide to FS2 Open modeling would be good for the community as a whole. People would have a list of what already has been tried and won't work. A list of things to try, etc...
Problem is who is going to write it? I'd rather see the coders who wrote the feature coding than writing complex documentation (Although they need to do some documentation of course) and pretty much the same thing is true with modellers who use these features.
I do something a little similar with FRED and it's a lot of hard work to keep it up to date. Modelling is worse because at least with FRED you can playtest to see if something works in minutes. It takes a hell of a lot longer to test a modelling feature.
-
i hope noone called me a noob, ive been modding sence freespace 1. i use 3 basic guidlines.
guidline for performance:
if it runs better than doom 3, its cool.
guidline for balence:
if you make a uber death weapon or super ship from hell, give the enemy one too.
guidline for dealing with critics:
flip the bird and tell em to stuff it somplace stinky
:D
-
if you want to get some idea what the detail box setup can do look at these two vids
http://www.penguinbomb.com/omniscaper/WIPS/DSv2.wmv
http://www.penguinbomb.com/omniscaper/WIPS/trench.wmv
-
Damn, man! That is SLICK! I take it you're working on a Star Wars total conversion mod?
-
Omniscaper actually recorded those vids, although the star wars mod is looking for staff (http://www.hard-light.net/forums/index.php/topic,35418.0.html)
-
Hmmmm.... Definable fog (without poofs) in levels, with the right backgrounds, this could work brilliantly, also handy for....more terrestrial reasons.
Mines and minelaying AI
Not sure if this has been done already, but the ability to make the main object invulnerable, whilst keeping the subobjects as vulnerable, you can already assign individual hitpoints to them if needed iirc.
I'm sure I'll think of more ;)
-
I think I've seen that done before. So far as I know, no matter how hard you try, when you first encounter it, while you can disable it and destroy every subsystem on it, you cannot kill the SD Ravannah when first you encounter her in the FS2 Campaign. I've gotten her hull down to 1% and still she doesn't blow up no matter how much longer I stay there and blast away with missiles and guns.
-
Originally posted by CaptJosh
I think I've seen that done before. So far as I know, no matter how hard you try, when you first encounter it, while you can disable it and destroy every subsystem on it, you cannot kill the SD Ravannah when first you encounter her in the FS2 Campaign. I've gotten her hull down to 1% and still she doesn't blow up no matter how much longer I stay there and blast away with missiles and guns.
That's different. The Ravanna has the "Big Ship" flag, which means only heavy weapons like bombs and beams, can ultimately destroy a ship, though fighter weapons can weaken them down to 1%.
-
Well that explains that, I guess. My mistake.
-
Originally posted by Black Wolf
though fighter weapons can weaken them down to 1%.
:wtf:
I dear to say that I'm pretty sure it's 10%...
-
If it is, there's a problem, then. Because I've gotten the Ravanna down to 1%.
-
It's down to about 10% at normal damage levels, then down to 1% at reduced levels AFAIK. And it's the "corvette" flag that makes it act like that.
-
Originally posted by Prophet
:wtf:
I dear to say that I'm pretty sure it's 10%...
I think it used to be, but SCP changed it so that at 10% the damage would be greatly reduced to make it seem more realistic.
-
Originally posted by WMCoolmon
I think it used to be, but SCP changed it so that at 10% the damage would be greatly reduced to make it seem more realistic.
And later it was changed back. :)
-
Well, all I know is that once it hit 10%, and this is on the release 3.6.7, mind you, it took forever before I got it down to 1%, and then it wouldn't go down any more.
-
two thigs:
- a disable Command messages only option in FRED
- a SEXP that allows you to activate/deactivate player orders. Why?
Let's say I want to make a mission where tehy player is part of a wing he doesn't command (thus all player orders are disabled9. Let's say I want the leader to get killed and you take over. In order to do that I would need some SEXP trick that sets all player orders of a ship/wing to enabled or disabled.
-
New Request:
Would it be possible to upgrade the Loop selection function so that you can have multiple specifically named paths for the player to choose.
One example could be:
Which side will you serve?:
- GTVA
- NTF[/i]
BTW: For the record, i think i managed to take down a Hathesput once in a fighter. I was in an Erinyes, with Alpha and two other wings all in Erinyes, and we all had my standard loadout for the class (Kayser, Maxim and two banks of Tornados). I remember it took a long time (20-30 minutes) but she died eventually.
-
What's a Hathesput? I know from Lucifer, Lilith, Cain, Demon, Ravanna, and Sathanas, but...
EDIT: BTW, what thoughts on my idea to include support for alternate keyboard layouts, such as Dvorak?
-
The Psamtik's a Hatshepsut destroyer. You see her in the first mission when it nukes the Belisarius.
And as another FRED request, could it be possible to drag around backgrounds to place them? Keying in numbers for many nebulas gets tiring.
-
Thanks for the translation from the bad spelling. I guess I never bothered to learn the classes of friendly units other than those that also showed up as enemies in the NTF. I knew all Vasudan units were friendlies, so... *shrug* Still, if the spelling had been correct, I could have looked it up.
-
BTW, not to double post or anything, but I had an idea, How a feature where, if you replay a mission from the tech room, and in the campaign that mission gave you no choice of ship or weapons, you courd try different ships and weapons if the mission was selected from the tech room.
I don't know that this is particularly feasible, it's just that I'd like to see what the mission "Bearbaiting" is like with something other than that Vasudan bomber you get assigned.
-
I think having some sort of a modding bible would be handy, but who has the time? Plus we (modellers) argue half the time over techniques and whatnot :D. To be honest, I learnt everything - the very principles- from scratch based on various titbits, so I'm not even qualified myself to write a tut, even though I've been here ages.
It'd be nice to have some form of documentation of SCP features though... or if there is one, one that's easy to actually find :)
Anyways, I second TM on the 'no command messages' box; it's a real pain losing both wingmen and command. Minelaying stuff also sounds promising :); perhaps the countermeasure code Phreaks' working on could be adapted.
Um, some of variable fog 'thickness' would be nice (i.e. not the nebula itself - although that'd also be neat - but just regular fogging effect); isn't there OGL or DirectX support for fogging that could be used? Particularly for any sort of atmospheric stuff.
To be honest, I can't think of a great deal of stuff I'd need myself. An update on the status of animation for subobjects, especially complex 'jointed' type things would be handy.
It might be nice to be able to manually set fov in FRED, too; perhaps for 'warp' like effects (ooh.... could we have fancy frame-blurring on the edges ala every racing game since Burnout - I forget the technical term - maybe for in subspace?), and also for missions with unusually sized player ships (I'm specifically thinking of that spacesuit, but also because FOV can screw up the visible cockpits if you're trying to, for example, line up a modelled HUD with the players HUD)
Oh, and has the thing with colliding problems for the visible cockpits been fixed?
What I'd really like, though, is that documentation. I keep losing track of SCP features, despite my best intentions, and it's hard to find any list of stuff. For example, I've had a nightmare trying to find the fields for glowpoints.
-
So far I've posted two ideas and I'm curious to know if anyone has some feedback on them. The ideas are support for alternate keyboard layouts and an option to let you select loadout and ship on missions played from the tech room even on missions that didn't let you in the campaign. What do you all think about those?
-
The problem is that this is an ideas thread, not really a feedback thread.
Since I'm feeling procrastinatory, I'll give a brief response: The short answer is: remap your keys. The long answer is: I don't know. As for playing with different ships and weapons, just go into FRED and remove the scramble flag.
Stuff that will probably be implemented quickly:
--No built-in command messages flag
--No built-in wingmen messages flag
--No-traitor flag specific to a particular ship
-
How are the config settings stored? Would it be possible to define a bunch of config files (i.e. for keys), autodetect the keyboard type, and then load the config file?
-
my desires for the next release
* fix the multi problem with large ships tables - i think have a solution for this in my head, just need to try it out
* more realistic star background system with stars of different sizes and different distances - higher concentrations of stars in/around nebula -- this can possibly be implemented by the art but lightspeed flat out refused to do it when someone [cannot remember who] showed an example
* BETTER ASTEROID SYSTEM and better asteroid models - including ice asterois, asteroids are ice-rock mix, rock-only, field shapes other than squares, more asteroids available - but only ones within a certain distance display, etc
-
On-topic, please. :)
-
what about customizable ship classes?
-
I wouldn't mind that myself. the classes they use in the default campaign do not even begin to follow naval convention and I'm something of a purist on that. I'll start a new topic if anyone's interested in discussing that particular subject.
As for a feature suggestion, it's not so much a suggestion as a question of feasibility and/or if it's already doable based on existing features. If one wanted to do a Star Trek type mod, is it already possible for the warp out to show up as the ship actually engaging warp drive and warping away into the distance instead of creating a "jump point"? If not, would this feature be faesible.
Side note: a Star Trek style warp out would not be dependant on jump nodes. So a ship about to warp out of the system wouldn't need to get to a specific point. It would create a totally different game dynamic. Action would need to be closer to planets stars, etc. In order for a ship to engage warp drive, it would have to be X distance from a planetary body, star, or other gravity well, where X is a function of total gravitational pull on the ship vs the size of the warpfield. Smaller ships can go to warp closer in while larger ships would have to get farther away.
Being close to planets and stars would possibly require new object classes, as they could no longer just be pictures in the background, if that's all they are now...
-
Originally posted by Goober5000
Stuff that will probably be implemented quickly:
--No built-in command messages flag
--No built-in wingmen messages flag
--No-traitor flag specific to a particular ship
YAY!!!;7 :nod: :D ;) :thepimp:
All Hail the mighty SCP wizzards!
-
- Dynamic LOD (yes, I'm saying it for the second time in this thread :p)
--Why? Saves modelers a lot of workload, and improves the game's overall look (and in some cases, performance),
- Being able to make HUD instruments larger or smaller.
--This would probably require a major HUD code overhaul, but it'd be nice if you could make some instruments small, so it gives the appearance that they're actually instruments on the 3D cockpits that we have now.
- No radar lock behind asteroids.
--Something else that would be cool, but require a major overhaul: When a ship passes behind an asteroid, it's disappears from your radar for however long it's behind the asteroid. Would be cool for multiplayer missions. :D
-
That asteroid thing is something they do in Starfleet Command Orion Pirates. Of course, the subspace based sensors in Star Trek still know the ship is there, it's just that you can't get a target lock on it. However, I rather think that the radar in the Freespace universe is just that, RAdio Detetion And Ranging. It would make sense that all you would get is an asteroid return, which gets filtered out on your scope.
-
Originally posted by Nuke
what about customizable ship classes?
Esplanation?
-
I though of an even better idea - make the command/wingman/all messgaes activated/deactiovated via SEXPs!!
so you have a disable/enable-all-messages, disable/enable-command-messgaes and disable/enable-wingman-messages
tis would enable you to make a mission where you and your wing are on a misison and when later a jamming ship popps up all comms with command are out until you destroy that ship :D
-
Originally posted by Unknown Target
- Dynamic LOD (yes, I'm saying it for the second time in this thread :p)
--Why? Saves modelers a lot of workload, and improves the game's overall look (and in some cases, performance),
I don't concur with this.
Um, can someone tell me how configurable asteroid stats are? I.e. could we swap an asteroid field, with a minefield and have nice shockwavy explosions with no subdebris?
-
This is something that has bothered me for a long time (hopefully I'm not the only one) but what about a dynamically colour changing hud, or at least targetting recticule.
I just find it really annoying that with the huge number of backgrounds and nebulas of different colour that no matter which one you pick for the hud, at some stage it'll just disappear into whatever background you happen to be pointed at for at least a few seconds in nearly every mission.
Would there be much involved in something like this?
-
I had another idea last night. How about support for the scrolling wheel most folks seem to have on their mice these days. It would be nice to be able to use it in places where you can scroll up and down through text or through ship and weapons selection when applicable. Not sure if it's feasible. Just a "would be nice" kind of thing.
-
Originally posted by Unknown Target
- Dynamic LOD (yes, I'm saying it for the second time in this thread :p)
--Why? Saves modelers a lot of workload, and improves the game's overall look (and in some cases, performance),
- Being able to make HUD instruments larger or smaller.
--This would probably require a major HUD code overhaul, but it'd be nice if you could make some instruments small, so it gives the appearance that they're actually instruments on the 3D cockpits that we have now.
- No radar lock behind asteroids.
--Something else that would be cool, but require a major overhaul: When a ship passes behind an asteroid, it's disappears from your radar for however long it's behind the asteroid. Would be cool for multiplayer missions. :D
If we're going into some sort of rudimentary radar simulation:
- Make it so that looking in a different direction won't influence the radar lock. (Every time I check six, the lock goes haywire)
- Heat seakers don't need lock-on; that's all good and dandy - however aspect seekers work on an optical method:
(So it's actually ladar/lidar instead radar)
1) So to lock on, you need a direct line-of-sight (This could be handled reusing the targeting laser code can it?)
2) Once locked on, the computer keeps track of the target (it reads its radar/lidar reading and predicts its movement) - so for a couple of seconds the lock should remain regardless orientation!
3) (1.b) The emphasis on the direct line of sight - so instead merly keeping something in the HUD we could define gimbal limits, so some ships could manage lock on a broader cone of sight.
...or have over-the-shoulder rear fire capacity a'la Firefox.
4) (2.b) Real AWACS/Command ship support: you can targets ships a lot faster if they're within the radar/lidar range of a capship.
5) (2.c) With a capship present you could relay and/or recieve targeting data from the capship. So alpha 3 tags the bandit while the rest of the squad lets loose a curtain of missiles. (Kinda how the F22 Raptors are said to hunt)
-
On your second point, Flaser, that is not entirely correct.
Some aspect seeing missiles use laser infrared (LIDAR) seeking method and some are radar homers. The AIM-54 Phoenix that my paternal grandfather helped develop comes to mind immediately.
But targeting radar and fire control radar are seperate systems. Fire control radar only looks forward. So it's perfectly possible to have a radar homer lose lock if you turn off target.
However, the aspect seeking missiles in this game stay on target even if you lose lock after firing. That indicates they all have internal guidance once launched.
Therefore, if it's not already included, I would suggest support for missiles that require the pilot to maintain lock on the target in order for the missile to continue to home. This would be quite useful for the purposes of someone creating an atmospheric flying mod for this game.
Of course, at that point, lift would have to be added to the physics so that you couldn't just cut your engines and hang there in the air. Rearming would also be out without landing, though air to air refueling would be an interesting new possibility...Hrm...Now I'm really going to have to learn how to code stuff. I suddenly have an urge to try to figure out how to make a "TOP GUN: Fire at Will" mod for this engine. :D
-
Originally posted by CaptJosh
Therefore, if it's not already included, I would suggest support for missiles that require the pilot to maintain lock on the target in order for the missile to continue to home. This would be quite useful for the purposes of someone creating an atmospheric flying mod for this game.
yes!
Some $notFaF tag for the missiles or somthing lie thqat would be awesome
-
Ooh ooh, another semi-FRED related one. A change-texture sexp.
-
Let me guess. Adaptive damage textures, right?
-
It could be, but that can sorta already be done with damage decals.
Although now that I think about it, it could already be faked by a change-ship-model, and the model is the same just different texture.
-
Originally posted by CaptJosh
I had another idea last night. How about support for the scrolling wheel most folks seem to have on their mice these days. It would be nice to be able to use it in places where you can scroll up and down through text or through ship and weapons selection when applicable. Not sure if it's feasible. Just a "would be nice" kind of thing.
That scroll wheel really should be mappable to relative throttle axis. Any other uses could be, well, mappable, but the fact that it's the perfect control surface for throttle for the mouse-players out there makes that one a no-brainer.
-
An excellent point, StratComm. It would be a very good relative throttle axis control for folks who use a mouse. Too bad it doesn't map already. Of course, when the game was written, I don't think scrolling mice were common, if even out at the time.
-
Originally posted by CaptJosh
Some aspect seeing missiles use laser infrared (LIDAR) seeking method and some are radar homers. The AIM-54 Phoenix that my paternal grandfather helped develop comes to mind immediately.
didn't know you grandfather made the mean missile :D
Allways loved the F-14 and everything it came with.
-
Originally posted by WMCoolmon
Esplanation?
id assume the ship classes are associated with a number fof flags and variables which are hard coded, such as turret capability and such, as well as what icons are used. id like to un-hardcode that info in table form. so you can add custom classes "carrier" for example. im not sure what all cxan be tweaked with this so it might be usefull, but then again it might be a useless waste of time.
a couple othir thigs id like
properly link engine glows to their respective subsystem so when the engine goes out the glows do too. mainly so that if you have a physical engine subsystem it can be shot off and make the engine glows go out.
expand the animation system. add more trigger options, and somehow make a shorthand version so it doesnt eat up so much table space.
-
Good idea. Especially since I'd like to go through and redo the ship classes so that they actually match up with naval tradition.
-
Number of turrets isn't restricted at all, you could give a fighter 100 if the HUD crash wasn't present. Ship class is primarily associated with AI AFAIK, and has some other uses such as whether or not the ship can be destroyed with standard weapons. Just about the only useful things I can think of that such custom definitions would allow would be the speed at which an object rotates in the techroom (odd criteria I know, but strangely a dependence) and the ability to add briefing icon classes. Which could sort of be fixed just by tablizing the briefing icon options themselves.
-
Originally posted by Nuke
add more trigger options, and somehow make a shorthand version so it doesnt eat up so much table space.
Bah. Get rid of the monolithic table. Give each ship its own table--entirely. Make ships self contained.
-
Originally posted by Nuke
id assume the ship classes are associated with a number fof flags and variables which are hard coded, such as turret capability and such, as well as what icons are used. id like to un-hardcode that info in table form. so you can add custom classes "carrier" for example. im not sure what all cxan be tweaked with this so it might be usefull, but then again it might be a useless waste of time.
That actually sounds like a really good idea...things like big damage and AI options could be added to a table with classes like "corvette" and such, to add a new one you just add it to the table. Overall it doesn't sound too hard, except for the ironing-out-bugs phase.
I'm not sure how well that would work with icons and the like though.
Don't hold your breath though. :nervous:
Originally posted by StratComm
Number of turrets isn't restricted at all, you could give a fighter 100 if the HUD crash wasn't present.
http://www.hard-light.net/forums/index.php/topic,35607.0.html
-
WM,
I'll put my request in for a "camera-movement" SEXP
that allows the camera to move fly around the scene in at least one direction (either x,y,z), or, if plausible, to be able to fly around on multiple axes at the same time.
camera-movement
with appropriate parameters for position, orientation, speed, and acceleration.
Cheers!
-
The equations I have now will handle total movement time, and acceleration/deceleration time. Separate for each axis is possible.
What you have there sounds easier, but I'd have to run through it before I know how plausible it is.
-
Remove the need for player-craft to have secondary firepoints, either on the models or in the tables.
This should be implemented in the next CVS build. If it isn't tell me and I'll look into it.
As in, the ability to change the weapon mounted on a turret via SEXP, in mission.
This would require loading the weapon on startup, with the changes that I've made for the mission-set-nebula SEXP I should be able to do this properly...mantis & assign it to me with the priority of feature (use the advanced bug report screen)
Rotation settings for skyboxes. Allowing the FREDer to rotate the skybox .pof like a ship model.
mantis w/ priority of feature and assign to me.
- a SEXP that allows you to activate/deactivate player orders. Why?
Let's say I want to make a mission where tehy player is part of a wing he doesn't command (thus all player orders are disabled9. Let's say I want the leader to get killed and you take over. In order to do that I would need some SEXP trick that sets all player orders of a ship/wing to enabled or disabled.
Quoted because it sounds possible but I don't know for sure. mantis + assign if you want me to take a look at it
Originally posted by aldo
Oh, and has the thing with colliding problems for the visible cockpits been fixed?
What problem was that?
Originally posted by Fractux
WM,
I'll put my request in for a "camera-movement" SEXP
that allows the camera to move fly around the scene in at least one direction (either x,y,z), or, if plausible, to be able to fly around on multiple axes at the same time.
camera-movement
with appropriate parameters for position, orientation, speed, and acceleration.
Cheers!
mantis. :nod:
-
Escape pod and recovery craft!!
Here's how I immagine it to work.
In FREd, in the ship editor you can set a escape pod model for a fighter/ship (default to none) as soo as you set it, upon destrucion that ship will spawn the appropriate escape pod - and the game will handle it like the ship wasn't destroyed - all messgaes from Alpha 2 will still be recived, but sent from Alpha 2 pod.
the pods are protected and no one will attack them unless specificly ordered to.
In addition to this, a Allow recovery craft mission flag..or a SEXP.. that will automaticly call in an support ship to dock with a ejected pod and warp out..
with this, one can make great mission with charachters that finally don't have to be made immortal or utterly incapable of anything. And the fact that their fighter can be destroyed will force the player to finally protect his wingman - no more writing mission on an account on invulnerable wingmen!
-
How about this one? Some mods would benefit from an alternate support ship type. Instead of having a ship warp in when the player calls for one, the player would fly towards a ship already in mission and once within a certain range, use the same key command as FS, but then AI will take over for the pilot and dock to the designated ship. Once docked, the rearm/repair sequence would occur.
Using BSG as an example, some dockpoints would be added within the bay pods so that the player could enter, dock, and rearm/repair, then undock and return to combat. It would almost be like a pit-stop. It would probably necessitate a launcher flag to change over from the standard FS rearming method.
While we're at it, how about the ability to have dockpoints bound to sub-objects rather than the main hull? That means that you could have objects docked to moving sub-models. The only real dilema with this is how to deal with paths. It may require that the dockpoints in question have no listed approach paths, or allow paths that allow the paths to move, staying relative to the dockpoint.
-
Could I just ask for whatever it is that the Wing Commander Saga folks want done to get done? :)
-
Originally posted by Trivial Psychic
How about this one? Some mods would benefit from an alternate support ship type. Instead of having a ship warp in when the player calls for one, the player would fly towards a ship already in mission and once within a certain range, use the same key command as FS, but then AI will take over for the pilot and dock to the designated ship. Once docked, the rearm/repair sequence would occur.
Using BSG as an example, some dockpoints would be added within the bay pods so that the player could enter, dock, and rearm/repair, then undock and return to combat. It would almost be like a pit-stop. It would probably necessitate a launcher flag to change over from the standard FS rearming method.
While we're at it, how about the ability to have dockpoints bound to sub-objects rather than the main hull? That means that you could have objects docked to moving sub-models. The only real dilema with this is how to deal with paths. It may require that the dockpoints in question have no listed approach paths, or allow paths that allow the paths to move, staying relative to the dockpoint.
nukemod could use this too. carrier landings, passive rearm and maybe an ils hud gauge for both.
-
Another change. Allow ships other than transports and cargo to have a cargo content listed in the bottom left corner of the screen, for targetted ships. Perhaps a table line like: $carries cargo: yes/no.
-
Do transports and cargo automatically carry cargo if not specified?
EG would it break compatibility if that section of code were automatically enabled for all ships instead of just transports/cargo?
-
Originally posted by Trivial Psychic
How about this one? Some mods would benefit from an alternate support ship type. Instead of having a ship warp in when the player calls for one, the player would fly towards a ship already in mission and once within a certain range, use the same key command as FS, but then AI will take over for the pilot and dock to the designated ship. Once docked, the rearm/repair sequence would occur.
Using BSG as an example, some dockpoints would be added within the bay pods so that the player could enter, dock, and rearm/repair, then undock and return to combat. It would almost be like a pit-stop. It would probably necessitate a launcher flag to change over from the standard FS rearming method.
While we're at it, how about the ability to have dockpoints bound to sub-objects rather than the main hull? That means that you could have objects docked to moving sub-models. The only real dilema with this is how to deal with paths. It may require that the dockpoints in question have no listed approach paths, or allow paths that allow the paths to move, staying relative to the dockpoint.
This can already be done with FRED, albiet, in a roundabout way.
[Alpha1 Dock]
when
|
-and
|
--<
---distance
----Alpha1
----dockingwaypoint
----200
|
--<
---is-key-pressed
----
|
---player-use-ai
|
---lock-controls (is there such a sexp?)
|
---add-goal
----alpha1
----AI-dock
-----alpha1
-----station
------dock1
------dock2
[/Alpha 1 dock]
[Alpha 1 Rearm]
when
|
--is-ship-docked-delay
---alpha1
---station
|
---refill secondaries
[/Alpha 1 Rearm]
And the undock sexp would be a simple key press that would order the Ai to undock with the station and give back control the player...that should do it I think.
-
yea but whats the fun in such a hackish implementation. and having the ai do it for you seems like taking all the fun away. i love making carrier landings and remember the space stations from elite. those were the days. i could probibly rig something up for a good carrier landing in fred and with some glopoint effects to use as a primitive ils. but it will always seem like a fakie solution to me.
my idea is you hit your standard rearm control, and if the mission has a designated passive re-arm dock, the hud will point you to it, and when withing range a gauge pops up and tells you what orentation you need to at to line up your dock with the capship's dock. then when youre in the proper angular and locational threshold you will dock automatically. fred would probibly need a carrier landing option, the name of the ship that does the passive rearm and the name of the dock that is designated as the ra-arm dock as well a place to put in the threshold options (lower thresholds means a harder dock). carrier landings would be similar, you pick your ship and dock in the departure cues and the ils guides you through the dock points on the capship during aproach and landing. i think it would really improve the versitility of the game and there are many tc's which would binifit, tbp bsg to name a couple as well as my mod.
-
Originally posted by WMCoolmon
What problem was that?
The clipping would be off, and you'd collide with objects that were far bigger than your ship, but the same (ish) size as the cockpit.
it was mentioned in the internal hosted forum. I'll try and find the link as it was easier to illustrate with examples.
EDIT; http://www.hard-light.net/forums/index.php/topic,31028.0.html
Piccies are gone; basically, 2 things were happening;
1/ the ship was colliding despite being far smaller than the actual bay
2/ the bay was clipping 'through' the ship when it shouldn't have
Um, I can send the pofs as an example if you need them. I honestly can;t remember if this was fixed or not.
-
sound more like the collision trees didnt compile correctly when you converted your model. is this thing a build specific problem?. might have something to do with the fact that your pilot is an open model. might want to try closing up some of the polies or actually modeling him as part of the seat. i havent ran into your problem, bacause i havent made a pilot model for my cockpitted ships yet.
brings me to another idea, custom pilot model. perhaps you could use the vwep code. a select4ed pilot model would be placed at the eye point (you would also need to make the pilot's middle in or in front his head).
-
Originally posted by WMCoolmon
Do transports and cargo automatically carry cargo if not specified?
EG would it break compatibility if that section of code were automatically enabled for all ships instead of just transports/cargo?
If no cargo is specified, then they'll display "no cargo". If you select cargo for something other than a transport or cargo container, it won't display it. I'd like to change this. It wouldn't break compatability if only activated by table entry. Perhaps not by the same type of table entry I specified, though perhaps by something more like just straight "+carries cargo", with no yes/no section. It would only activate on a ship with this entry, and thus not break compatability. It's just like the stealth entry in that respect.
-
Sounds like something for the custom ship classes idea, actually.
Is it time critical at all?
Edit:Originally posted by aldo_14
The clipping would be off, and you'd collide with objects that were far bigger than your ship, but the same (ish) size as the cockpit.
it was mentioned in the internal hosted forum. I'll try and find the link as it was easier to illustrate with examples.
EDIT; http://www.hard-light.net/forums/index.php/topic,31028.0.html
Piccies are gone; basically, 2 things were happening;
1/ the ship was colliding despite being far smaller than the actual bay
2/ the bay was clipping 'through' the ship when it shouldn't have
Um, I can send the pofs as an example if you need them. I honestly can;t remember if this was fixed or not.
2) This should be fixed...if not then I know how to fix it.
1) The collission code should have nothing to do with the rendering calls in there...only thing I can see is if the gr_zbuffer_clear() function somehow effects it, but it shouldn't. (Seeing as how it's a graphics and not a physics function.)
-
Originally posted by WMCoolmon
Sounds like something for the custom ship classes idea, actually.
Is it time critical at all?
Not extremely. I just know that there are a few TBP transport ships that work better with fighter/bomber AI, but still should be able to carry cargo.
-
Say..that escape pod thing..can it currently be simulated in any way with some exotic FREDing?
-
give fred the ability to save and load complex event scripts.
-
Originally posted by WMCoolmon
Sounds like something for the custom ship classes idea, actually.
Is it time critical at all?
Edit:
2) This should be fixed...if not then I know how to fix it.
1) The collission code should have nothing to do with the rendering calls in there...only thing I can see is if the gr_zbuffer_clear() function somehow effects it, but it shouldn't. (Seeing as how it's a graphics and not a physics function.)
I'm not sure. It seems to only happen with that one particular model, and I'm having nagging doubts about its stability now. Um..... I'll need to run some proper tests, I may have jumped the gun a bit.
As an aside; it'd be nice to be able to set objects to be only displayed on (i.e. if part of) the players ship. For example, having a cockpit with really detailed greebling in the cockpit, only visible in the cockpit. Can that already be done by subobject LODing? (I'm thinking stuff like switches, high detail pilot models, etc)
It'd also be handy to turn off some objects in the same context; I'm thinking specifically to do with the pilot model here.
-
The ability to trigger Bob's rotational animation code through FRED
-
I think you could do that with subobject LODing. Mostly it depends on whether the code uses the eyepoint as the determining factor or the player ship position. It should use the eyepoint though, as if not it wouldn't work for viewing other ships externally.
-
That sounds like what happened when I tried to give a capital ship the show ship flag. It was displayed as though the model being rendered as the visible ship (from the current eye position) was about 10x as big as it should have been, with things rendering on top of it as though they were much smaller and much closer than they really were.
-
I don't see why it should've done that. If the ship has a show ship flag, it should be rendered last ie after the zbuffer has been cleared so it should be impossible for other objects to be in front of it...unless I misunderstood how the zbuffer works?
-
I just had a feature idea for the launcher. How about altering it so that it can load mods that are in directories with spaces in the directory name?
-
I'm going to pretend I didn't see you request as a feature something that's currently listed as a bug. RandomTiger (the guy who wrote the launcher) is aware of it, but 1) he's not here right now and 2) it's not AT ALL trivial since the directory name is getting parsed from the command line (which is space-delimited).
Originally posted by WMCoolmon
I don't see why it should've done that. If the ship has a show ship flag, it should be rendered last ie after the zbuffer has been cleared so it should be impossible for other objects to be in front of it...unless I misunderstood how the zbuffer works?
That's what I thought, but I can still easily reproduce it. I might need to point out that it isn't the player ship that's doing this, but a capship that I'm viewing from.
-
If you're trying to run a mod for TBP, the best soltion is to enter the -mod XXXXX line as a custom command line. Note, your modname still wouldn't be able to have spaces in itself.
-
I'm not trying to run a mod of a mod. I have been running TBP on today's build of the SCP, though. Installed it as c:\Games\Freespace2\TBP. I just wish I knew where all the sound files were for the "Severed Dreams" mission. It's rather disconcerting to have to try to remeber the audio from a B5 ep I haven't seen in years. The only part I actually remember is the way it ended.
DELENN: This is Ambasador Delenn of the Minbari. Babylon 5 is under our protection. Withdraw...or be destroyed.
EA OFFICER: Negative. We have authority here. Do not force us to engage your ship.
DELENN: Why not? Only one human captain has ever survived battle with a Minbari fleet. He is behind me. You are in front of me. If you value your lives, be somewhere else!
One of my favorite echanges in the whole thing.
As for that bug in the launcher, I should have looked at Mantis, but it's quite late where I am, and I'm *YAWN* quite tired, and it didn't occur to me. Perhaps I should just call it a night...
-
what about the replacement interface and the new hud system, any work expected on those?
-
Yeah, Im also very interested for the Interface replacement. Is it going to be something like a current Shiplab, or something else ?
-
New interface code is in the works (LUI & FLUID) but is still a ways off from being really useful. It's been in the planning stages since the end of last year but I only started coding on it about 2 months ago. It's not like WMCGUI which is used in the lab and instead greatly expands on the current interface, using a type of table (.lui), doesn't use masks and allows a high degree of custimization. It's designed specifically for the FS2 style interface. The main reason I started working on this is because of the new SCP options screen in-game. It's such a pain in the ass to work with, let alone add new options to, that something new was needed for the interface.
LUI_core is still in the works though what I basically want is complete in my head. Just need to get the rest of it in code now and work out some basic issues. Some bugs and issues in the current UI code is going to be fixed but most of the controls are going to be exactly the same. It will be able to use the new font code (utilizing TTF) in a useful way, doesn't require separate mask files (as I stated earlier), can have a solid color or even repeating images for a background, nearly any shape/size button and be better suited to handle different resolutions as well as widescreen displays.
FLUID is a WYSIWYG designer for the interface. It will offer familiar tools (think like a simple webpage creator mixed with a very specific IDE) for creating an interface screen and making it usable in the game. You will design an interface, plug in all of the graphics and fonts that you want to use and it will "build" the interface for you by generating the .lui file and copying everything needed for it into a data/ structure which all you have to do then it pack it into a VP. FLUID is still a ways off but .lui files are just text so they can be created/edited by hand until it's done.
Oops! All of that was still something of a secret. :drevil: Just blame Goober, always works for me. ;)
I've got so much new stuff going on that it would make you all sick.
-
Would it be possible to improve the effectiveness of this thread a bit? What I mean is, edit the original post and add 3 lists. The first would list those requests that can and will be granted, in relative short order, perhaps within a month or three. The second would list what requests the team has deemed worthy requests, that will be granted, and that either are in progress but will take at least 6 months, or require some additional changes first, and won't be gotten to for 6 months or so (like shadows, which need Bob's materials system to be implimented first). The last list would be those requests which, due to either the time required, the lack of expected use, coding nighmares, or just the fact that it can't be implimented in FSO, won't be implimented.
This, of course, would require someone who is on the up-and-up with the activities of the team, and who has the time to go through and sort out each request into the 3 categories. There is some leeway or course, for example if someone made a request, for one specific addition, but someone in the know would be able to see that its just one tiny aspect of another, much larger and potentially more valuable addition, then the more encompassing addition would be listed, with perhaps the insitgating request, added in in brackets by its description.
-
it sounds like a good idea but id rather have people working on their code, mod, whatever than writing up a fancy thread that most people arent gonna work with and will fade into oblivion as a bad idea. i myself im gonna avoid playing with new features so that i may prepare a second nukemod beta for release that is fully compatable with the current offitial build. that is u8nless something i really want (gatling gun turrets) gets implemented. :D
-
Originally posted by Nuke
what about the replacement interface and the new hud system, any work expected on those?
Well i feel a little obligated to defend the lab, it's not near as good as it could be. It does actually have a pretty fully functional skinning table, it's just that it's never worked properly in OGL or D3D (Different bugs in each) so it's never really been popularized. I'm not sure if those bugs are still present, I have table files and art that could be plugged in to readily test.
I was thinking about doing some fun stuff like making it a total interface replacement and loading it from the start and relying on the mod(s) to provide the interface.
For the new HUD I was thinking along similar lines. The old :V: system is so hardcoded it isn't even funny.
For both of these I'd probably be relying alot on Python integration as well to give a lot of flexibility (without sacrificing much simplicity) to modders.
So general idea for a gauge entry:
$Name: Blah
$Show in: ("cockpit" "target cockpit")
$XCoord: 100 ;; Draw 100 pixels to the right of the left edge of the screen
$YCoord: 240 ;; Draw 200 pixels down from the top edge of the screen
$Draw: {
# What you want to draw goes here. Like to draw a
# 100 pixel-square X:
# Top left to lower right
gr.line(0, 0, 100, 100)
# Top right to lower left
gr.line(100, 0, 0, 100)
# Draw the current target model too?
g3d.draw_ship_model(self.target(), 0, 0, 10, 10)
# Write the name in the upper left
gr.text(self.target().get_name(), 0, 0)
# Note that 'self' would refer to the ship you're
# currently viewing from, rather than just the player ship.
}
Gauges would be separated into different 'screens' (I use the term because that's the class name for the new GUI, Gui_screen), each screen would correlate to a different ship type or something.
Assuming all this got implemented, it'd be really really flexible; you could do pretty much anything you wanted with the HUD, the only limit would be how advanced of Python knowledge you had.
-
your example seems to be within my understanding. im pretty sure that most would accept using python. just make it a standard for programming-essential features. perhaps the materials system would binifit as well.
in my mind its theese two things that need to be implemented the most to make the engine a stand-alone mod platform. id like to see it so that you could download a build and a modbase.vp, wich contains a minimal amount of data to make the engine run, although without actual game ccontent. so that anyone, even without freespace, could develop a free game.
-
Originally posted by WMCoolmon
...
For both of these I'd probably be relying alot on Python integration as well to give a lot of flexibility (without sacrificing much simplicity) to modders.
...
Assuming all this got implemented, it'd be really really flexible; you could do pretty much anything you wanted with the HUD, the only limit would be how advanced of Python knowledge you had.
So, um, when did someone start deciding it was a good idea to implement a proper scripting language, or am I misunderstanding?
-
Two quick ideas:
Proximity fused secondaries, missiles that explode when they get within a certain radius of their target.
The ability to add particle trails to ship debris. On large ships it probably wouldn't look as good, but for it might look better on fighters.
-
Originally posted by mikhael
So, um, when did someone start deciding it was a good idea to implement a proper scripting language, or am I misunderstanding?
I don't think you're misunderstanding...what's your point?
-
Only that its usually my biggest most important wishlist item and I didn't ever see anyone actually considering implementing it. Where can I read more details about the proposed implementation?
-
Originally posted by mikhael
Only that its usually my biggest most important wishlist item and I didn't ever see anyone actually considering implementing it. Where can I read more details about the proposed implementation?
Hrm, I was expecting flak :nervous: See the HUD/Python thread.
-
*Throws flak at WMC*
I hate Python.
-
Feature request:
A new filename extension for FSO-only missions, which takes precedence over a mission of the same name with a .fs2 extension.
Uses:
Campaigns which wish to retain retail compatability out of the box but that also want to use FSO-only graphical enhancement SEXPs (glowmap/glowpoint activation/deactivation, texture replacement, etc). Said campaigns could create the mission for retail, save as .fs2, then add the extra features and save in the new extension. The game would load the extra features version if it understood it, but retail would go on with the .fs2 version. .fs2 would not automatically mean retail mission format though, since there have been several years of that extension mapping to SCP-enhanced missions.
Potential downsides:
It sets a fairly arbitrary bar on what version of FSO you can use to play the "enhanced" campaign. Not in any way ideal. However, I think it'd ultimately be worthwhile, as I've seen a couple of requests for changes to the current system that could be resolved completely with this (backwards-compatability preserving) change.
-
Please can I have:
1) Floating point numbers.
2) String -> number conversion SEXP.
3) Number -> string conversion SEXP.
4) String concatenation SEXP.
5) Font support in the cutscene subtitle SEXP.
6) 0-1 range subtitle positions (to allow screen resolution independence) for subtitle sexp.
7) Create/remove asteroid field SEXPs.
8) SEXP to allow me to change the bitmap based background nebulae in-mission. Maybe using an add/remove mechanism or just a single sexp that takes a list of neb names, positions, and rotations and completely replaces the current setup with the new one.
9) A nearest-enemy-ship SEXP to return it's name.
10) A capship equivilent of the fighter chase-any (possibly attack-any) to tell capships to just approach/fire/circle the nearest enemy capship.
-
Oh some other things to allow me to make my dynamic campaign BHX to work better.
11) change-ship-class works on a ship that either hasn't warped in yet or is in the process or warping in.
-
2 Quick questions, I've not FS2 installed atm, but before I start making a load of placeholders and useless models....
1 : Has the thing with Shininess being set to 100% if theres no shine map been reversed? A lot of the stuff I'm working on doesn't need shine-maps, and I'd rather not make loads of little black squares unless I have to ;)
2 : Was there any advance on rotating barrels on turrets or is that a definite nono for the forseeable future?
Thanks :)
-
In response to 1), judging from what I'm seeing with the Pegasus, that'd be a definitive yes. Whether the default is no shine or use the texture as a shinemap I'm not sure, though I suspect it's defaulting to off now.
-
Originally posted by StratComm
In response to 1), judging from what I'm seeing with the Pegasus, that'd be a definitive yes. Whether the default is no shine or use the texture as a shinemap I'm not sure, though I suspect it's defaulting to off now.
The default is no shine now. Previously it would use the normal bitmap as a shine map if there wasn't a true shine map but besides being wrong it was breaking bmpman load accounting so I removed that "feature". I figured that if you actually wanted a shine map then you would have made one.
-
Originally posted by Flipside
2 : Was there any advance on rotating barrels on turrets or is that a definite nono for the forseeable future?
Thanks :)
see im not the only one who wants gatling turrets (http://www.game-warden.com/nukemod-cos/Images/turrrent.gif)
-
Feature request- Support for different aspect ratios (or at least make them selectable).
e.g. like the Source engine does now- select an aspect ratio (4:3, 16:9 or 16:10) and the game automatically adjusts the FOV and allows the widescreen resolutions to be selected.
Specifically at the moment it is impossible to run at 1200x800 which is my laptop's native res.