Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Kazan on April 13, 2002, 10:26:41 am
-
I plan on adding
Objects that move upon script = ie
When
---fires(Turret01, -5) //five seconds before Turret01 files
------Move(Object, x, y, z); //where X,Y,Z are replaced wiht correct values
or
When
---Launces(FighterBay01, -10) //ten seconds before fighters are launched from FighterBay01
-----Move(DoorRight, -200, 0, 0):
-----Move(DoorLeft, 200, 0, 0); // that would make the two door objects open [Hey IceFire! FS2:TBP could use this :D]
Hull Lights [ie running lights like in IWar2]
That will require 2 new chunks
MVRS or "Movers"
LGHT or "Lights"
who else has suggestions
-
v00t!
-
How about support for trails? (For TAP)
And something....I forget what it was, but something for MODabilaty, especially for the Robotech MOD...
Oh, yea, not sure if this is what you mean in your last post, but how about animations that, stay (as in-fighter to gerwalk-to battloid, and back again)?
Also, more ability to be MODed, and how about a feature for a cockpit (you can turn this on or off, if you want), rather than just the bland HUD of FS2....
Cheers!
Unknown Target
-
we already have trail support - it's in the tables
-
Man, didnt we already discuss the trails?
Not. Gonna. Happen.
-
Originally posted by Kazan
we already have trail support - it's in the tables
He means engine trails, like in Homeworld. Fighters and Corvettes leave long colorful ion trails. Only way to make em work would be to make the mission in an invisible nebula, and that means no backgrounds. Too much work for a useless effect.
-
Explosion orders so the ship blows up in a certain way.
Although that could be mission specific I suppose.
EDIT: Shockwave points. It'd make sense for missile bays to give off their own shockwaves as well as the reactors.
-
Originally posted by Ten of Twelve
v00t!
isn´t that w00t. Or some new elite speak i haven´t heard of.
Anyway...uhh... animated texs???
-
Originally posted by Stunaep
isn´t that w00t.
:wtf:
-
Originally posted by Ten of Twelve
v00t!
is that 'w00t' but with a German accent?
-
Thorn: OH! understood... we'll have to think about putting that in a new chunk or the existing engines chunk [perhaps the wash zone can be the ion trail.. makes sense to me]
Warning: Post is programmer oriented
struct POFString
{
int size; //32-bit
char *str; //exactly size chars long - no null terminator
}
Chunk MVRS or "Movers"
struct MVRS
{
int nummvrs
vector scripts;
}
Chunk LGHT or "Lights"
struct POFRGBA
{
char Red, Green, Blue, Ambience'
}
struct POFRunLight
{
POFString name;
POFRGBA color;
vector location; //it's a set of floats (x,, y, z)
}
struct LGHT
{
int numlights;
POFRunLight* lights;
}
//------
It should be noted in the POF CS sources I have a naming conflict between std::vector and vector - which wasn't a problem because I was using apvector and apstring
soon im going to rename vector to vector3d, updating all the source files, POFString is called 'string' in the POF CS sources and it'll be renamed POFString
all instances of apvector will become std::vector and all instances of apstring will become std::string
-
Yea, I was talking about, well, you know, for it to be able to have a program chunk, and in FRED2000, you put in the command line in the events editor:
-When mission starts
-Enable Trails
or simply:
-Enable Trails.....
-
Better beam controls.
This running lights idea..will they just be blobs or will you be able to use texture maps as a base (I.E, a glowing Lilith?)
-
they'll be running lights
glowing textures will be part of the new texturing pipeline
-
can we get shaders
and bumpmaps
a lot of that could be added into the txtr chunk
-
mmh, only thing I'd really like, I think, are those animated parts (already discussed), but, mainly, ani as textures on ships. Now that I could have a great use of ;7
edit: for the trails, the simplest way would be to force FS2 to display them out of nebs. Ok, I don't know what I'm talking about, I'm most likely saying crap.
-
Originally posted by venom2506
mmh, only thing I'd really like, I think, are those animated parts (already discussed), but, mainly, ani as textures on ships. Now that I could have a great use of ;7
edit: for the trails, the simplest way would be to force FS2 to display them out of nebs. Ok, I don't know what I'm talking about, I'm most likely saying crap.
:p
-
specular materials. (hull metals shine)
oh and kaz, shouldn't POFRGBA:
Chunk LGHT or "Lights"
struct POFRGBA
{
char Red, Green, Blue, Ambience;
}
use unsigned chars (0-255) instead of signed ones(-128-127)?
-
Oooh, all the POF's should be able to hold people debris that trigger something in the code that makes them wiggle and explode in a special, big, red plume.
-
Originally posted by an0n
Oooh, all the POF's should be able to hold people debris that trigger something in the code that makes them wiggle and explode in a special, big, red plume.
lol :D
The pof should hold the species, not the tbl. so you can give it the thruster colour you want, regardless of the species.
:rolleyes: ok, it's absolutly not what I meant.
Let's try again:
we should be able to choose the colour of the thruster, in fact, the colour should be hnadled like any other map, so if someone wants to map its thrusters with purple and orange flames, even if he has dull tastes, he could.
-
That would be more of an explosion .ani thing wouldnt it?
-
GIF's for animated maps. No need for tedious converting.
-
Originally posted by venom2506
mmh, only thing I'd really like, I think, are those animated parts (already discussed), but, mainly, ani as textures on ships. Now that I could have a great use of ;7
mmmm organic ships.... and strange subspace portals that you can crash into ;)
-
How about detail-mapping capabilities? This system is used by a few graphics engines (Unreal and Serious Sam) to make textures look very sharp and detailed close-up by applying a bump-map only when the player is really close to the texture. Very cool effect, and it would be great to see it in a space sim. ;)
-
good call phreak
good ideas.. keep 'em coming
-
Oh, oh, I've got a good one!!!
How about 3D, volumetric explosions, rather than just the simple, 2D ones of FS2...
Also, T&L support, better nebulaes(if that's possible) and lens flares!
-
ahhh... ok.. that's it - let's worry about getting programmers FIRST
btw Unknown - that's general ENGINE stuff... not MODEL stuff
-
Oops, yea, you're right, srry:doh:
-
I just had an idea with the engine wash zone. I'll raise it later.
-
Oh, yes, I know:
ships and turrets being different pofs. basically, a capital ship pof has no turrets, just docking points for turrets. then you have multiple different turret pofs. In fred, you can attach the turret you want where you want on the ship. That may also allow the barreled turrets to be placed at an angle.
mmh, basically, allow the capships to have more than one working docking point at a time.
-
Its a radical idea -
but some kind of vertex-animation tool? Bone based or straight frame-by-frame manipulation.
I.E
Some way of making the sathanas beam pods move in close together like they did in the last FS2 cutscene?
3D volume explosions would require a fairly exclusive number of graphics cards (ones that support volume rendering, unfortunately, i dont think GEforces do. You're talking wildcats and Oxygen and FireGL cards there!)
Plus they'd slow everything up...if you're going to do that, you might as well make the explosion effect out of textured polies.
Hey Kazan, what about support for some basic procedurals and Pixel/Vertex shaders? I know thats engine stuff as well but is it on the cards?
-
Originally posted by wEvil
Its a radical idea -
but some kind of vertex-animation tool? Bone based or straight frame-by-frame manipulation.
I.E
Some way of making the sathanas beam pods move in close together like they did in the last FS2 cutscene?
that may not be that hard to do? look at modelview, it can read this kind of data for the descent oof models.
-
Originally posted by CP5670
How about detail-mapping capabilities? This system is used by a few graphics engines (Unreal and Serious Sam) to make textures look very sharp and detailed close-up by applying a bump-map only when the player is really close to the texture. Very cool effect, and it would be great to see it in a space sim. ;)
Yes, that would be good. :nod:
-
Dependign how tight your model - codeintegration is, you could use the file format to recognise trigger events that cause animations.
(on the fly pseudo)
Like
when (anyShipArrives() && anyShipArrivesParent()==this)
anim_1.start(60)
runway.flash_light(true,5,60)
i.e. when a ship arrives, do the following stuff
open doors (1) for 60 secs
flash lights on for 60 secs at 5 sec intervals
If you can set sub-objects as seprate child classes, you have a lot more potential to give them unique operations, or type - specific stuff. (better abstraction).
Of copurse, it's not really like pof format, so you'd maybe have to initialise models through a wrapper class, that defines type, stats, child subobjects and their animations, effects - taking some of that data from the relevant tbl.
If you store animations as keyframes, you could use parameters to delay, and then reverse the animation.
EDIT;
Actually, i just realised how self evident & vague most of that was. :doh:
but I'd definately suggest allowing percentage animation - i.e. rotating 50 degrees.
-
Originally posted by aldo_14
Dependign how tight your model - codeintegration is, you could use the file format to recognise trigger events that cause animations.
(on the fly pseudo)
Like
when (anyShipArrives() && anyShipArrivesParent()==this)
anim_1.start(60)
runway.flash_light(true,5,60)
i.e. when a ship arrives, do the following stuff
open doors (1) for 60 secs
flash lights on for 60 secs at 5 sec intervals
If you can set sub-objects as seprate child classes, you have a lot more potential to give them unique operations, or type - specific stuff. (better abstraction).
Of copurse, it's not really like pof format, so you'd maybe have to initialise models through a wrapper class, that defines type, stats, child subobjects and their animations, effects - taking some of that data from the relevant tbl.
If you store animations as keyframes, you could use parameters to delay, and then reverse the animation.
EDIT;
Actually, i just realised how self evident & vague most of that was. :doh:
but I'd definately suggest allowing percentage animation - i.e. rotating 50 degrees. [/B]
Im not really sure I understand, but for that kind of flexibility i dont think wrapper classes would do it without the whole thing getting waay messy.
-
Aldo that's what the Movers (MVRS) block does.. it stores those scripts
-
WOW cool Kazan..... keep it up:nod:
-
Originally posted by wEvil
Im not really sure I understand, but for that kind of flexibility i dont think wrapper classes would do it without the whole thing getting waay messy.
I've been coding a grpah since 10am this morning.... I'm at the satge where I forget what i first wrote by the time i finish the post :D
I tthink I meant that the model recognises when a certain event occurs, and performs the appropriate operation. so, what Kazan already said, then :doh:
-
The thing I like most of this is the animated textures and the move on scripting things...
-
How about some real engine flame? I mean, rather than just the simple block engine flame of the first two, how about some dynamic flame, that sputters, and ignites?
It would look infinetely better:D
Not sure if that's pof or engine stuff, though......
-
How about the equivalent of the XWing vs. tie/XWA 'sfoil' i.e. a command that activates some kind of ship transformation/animation.
Could also apply to switchable cloak generators (umm on second thoughts this might be more of an engine aspect), deployable weapons, that kind of thing.
-
ok simple really turrets on the sides of ships
and mulitple shockwave but ok different angles etc like incoming used ot have never knew how the thing would blow up
-
Originally posted by venom2506
Oh, yes, I know:
ships and turrets being different pofs. basically, a capital ship pof has no turrets, just docking points for turrets. then you have multiple different turret pofs. In fred, you can attach the turret you want where you want on the ship. That may also allow the barreled turrets to be placed at an angle.
mmh, basically, allow the capships to have more than one working docking point at a time.
Yeh, that. :):yes:
-
bump
-
Just to clarify: this is supposed to be about the Freespace Forever project, right?
-
Originally posted by Styxx
Just to clarify: this is supposed to be about the Freespace Forever project, right?
:rolleyes:
-
Two ideas:
1. Allow for sequencing of explosions so that a ship blows up in a specific way.
2. allow turrets to have a default position other than pointing straight up
-
Originally posted by CP5670
How about detail-mapping capabilities? This system is used by a few graphics engines (Unreal and Serious Sam) to make textures look very sharp and detailed close-up by applying a bump-map only when the player is really close to the texture. Very cool effect, and it would be great to see it in a space sim. ;)
More engine-oriented, but definetly - that effect was so awesome the first time I saw it, and every time thereafter... amazing.
Originally posted by wEvil
Its a radical idea -
but some kind of vertex-animation tool? Bone based or straight frame-by-frame manipulation.
I.E
Some way of making the sathanas beam pods move in close together like they did in the last FS2 cutscene?
Look to the user-made units in Total Annihilation for a guide to this kind of stuff - I'll never forget the first time I saw a Raptor (mech) walking across the map, swaying slightly from side to side. Or the model animations for the factories opening up, or those super-defense towers deploying to fire (Annihilator, Doomsday Machine). The model animation flexibility in TA was simply awesome.
Also, definetly enhance the whole docking thing. I like that swappable-turrets idea (fits in with the ship customizability idea in the main FsF thread), as well as being able to simply have multiple objects docked together at once.
-
dunno if this would be considered an engine or a model thing, but multitexturing would be a good addition.
-
endjinn .
-
true, but i dunno where else it would be used...
<2 second pause>
now that i think of it, the "skybox" is another good example.
-
Originally posted by wEvil
:rolleyes:
I'm too lazy to read through all this nonsense. So sue me. :p
-
oh yeah, multiple skins in the same pof, too.
but the turret thinguy is something I'm attached to, so I mention it again :ha:
-
ok, now im confused, are we talking about what can be done for FS2 using a new version of PCS or are we talking about a modding program based off of PCS for the FSF engine?
(Im sure this is a really stupid question but i have no clue whats going on around here anymore)
-
we are creating a new game with new POF specs, new engine.
or trying to.
-
I think we're just thinking of ideas for what the new game's model format should have in it. The stuff would have to be implemented into an engine first, though.
-
Originally posted by Styxx
I'm too lazy to read through all this nonsense. So sue me. :p
So true.
-
so dispite the name of this thread, it really has nothing to do with FS2 and is instead about FSF?
-
the "FS2= version 2117" was a reference
-
ok.. im killing this "turret dock" thingy right now - it's called overheard people. and unreasonable
-
arg, i was under the impression this was a new model editing program for FS2, nevermind
-
Originally posted by Kazan
ok.. im killing this "turret dock" thingy right now - it's called overheard people. and unreasonable
really? in what way? it's cool, and, first of all, handy. really, it's just a matter of giving ships a lots of dock points. The FS2 ships would have lots of docking points, I could do it w/o any pb. not even a need to tweak any other pof stat.
-
it would be WAAAY more hassles then worth - it would break reverse-compat, it would require a massive amount of house-keeping thereby slowing down the game... on and on
-
just for some docking points? you must be kidding.
ok, let's try this: just allow ships to have all their docking points working at the same time, that's all of what's required.
-
yes.. we can do multiple active dockpoints.. but not the turrets docking thing
-
well, give me 80 docking points, I need nothing else :nod:
-
venom... no
we're not going to allow that.. it'll slow down the game
-
Ok, Why not? is it coz you can't? it's up to the modders to judge to what extent they can use stuff. they don't have to be limited by the tool. That's the same kind of stupid reasoning that brought that 5000 polys limits for Modelview or any cob to pof converter, stupid limit which has no reason to be anymore since the computers can now handle that. If a dude puts too many stuff in a mod, it will suck. if he could have put more but wasn't allowed because of a tool limit, it's the tool that sucks. that may not please you, but it's true. Limits have to be set by the modder, not imposed by a limited tool. You can do it w/o any more work, I'm sure of that. Don't put a limit that has no meaning.
-
LISTEN TO BE BEFORE RESPONDING - i've told you this several times - the OVERHEAD required to do something like that would be an atrocity - it would slow the game to a crawl.. so ____NO____
-
ok, I guess no need to argue with you right? :rolleyes: sure, do it YOUR way then, right?
bah, no need for me to suggest anything, coz that would give you work (omg!), and that's a waste of time for me. Don't waste your time to reply either, it's useless, I won't argue anymore.
-
excuse me for getting annoyed by you pressing an issue that i've already told you that is not feasable because of performance issue
-
Kazan he has no idea what you are saying, I do understand, basically what he is saying is that if you do it this way the main problem will be is for one ship you will have 90 ship classes running at the same time, as opposed to just one, making it 90 times more processor intensive,
Now as I understand it, this is somewhat irrelevant, because you will be able to do what you want Kazan be damned, because the new engine will be able to support as many docking points as needed,
Now Kazan I have been thinking of this and from an overhead point of view, it may be better to run the turrets in a form like this, were there are "soft" turrets which would consist of a simple xyz and a vector. Then you can store the geometry of them and transformation\rotation data in one space and use it over and over again. Allowing for the standard "hard" turrets would allow this to be reverse compatible. It would also allow the custom placement of different turret types (and possibly make random rotation axes easier), we may need to make a new turrets.tbl to load a simple pof which would hold geometry\hierarchy data and the standard TGUN data which would be contanconated on to the standard turret data.
I am in favor of doing this if it isn't entierly imposable, from the point of this being usefull to make diferen't variants of ships without makeing a new ship entry in the tbl, and making it somewhat easier to set up turrets.
and reread you're last few posts and imagin someone wrote that to you for an idea you had that thought would a good idea and one wich you could not understand what they were saying
-
I was assuming that since this is an open source project (or is it? Clarification would be useful) that new options could be added later. In which case if a method of adding these dock points with less overhead is found that it can simply be added to the existing code.
Wouldn't it be sensible in any case to get an engine that supports standard POFs before getting too ambitious and designing the Uber POF that might not even be made?
-
i should have noted that i will not give 'special attention' to that capability.. but if he wants to exploit the multi-doc capabilities
-
and Mae has a point
-
Kazan, although I agree that the turrets thingy would be a huge performance hit, let me correct you on something: that feature, or any new feature, would not break backwards compatability. Keep in the engine the code to read the current POF version, and have a different bit of code that would deal with the new POF version.
Or am I missing something?
P.S. I'm not suggesting that the multi-turret docking should be done, just pointing out that I believe we could add any and all the new POF features we want w/o sacrificing backwards compatability.
-
Originally posted by Kazan
excuse me for getting annoyed by you pressing an issue that i've already told you that is not feasable because of performance issue
The 'old' FS2 engine can differentiate between turret polyobjects and hull objects, and it can manipulate their firing points, etc. According to FRED2, you can also set their AI levels.
Were it not for the dockpoint limit on FS ships, this is easily possible within the current engine - a 2 year old engine. Granted, you'd possibly have to use some SEXP-ing, but it's not beyond the realms of possiblity.
So why the performance issue? It's already done by I-War 2, using models that are probably more complex than what a modeller would come up for FSF - given limits to follow.
What exactly is the performance hit from? What causes it? How can you say it's a performance hit when you have neither coded AI, physics, weapons (etc), ship class handling, etc to even test the basic performance?
Oh, and overhead is something that exists only to dismiss stuff. you can pretty much code in anything nowadays - all you have to do is keep it tight and optimise the code accordingly. The number 1 problem of fast computers is that people forget to do this - because they don't need to.
-
Originally posted by aldo_14
The number 1 problem of fast computers is that people forget to do this - because they don't need to.
I duno about it being The Number One Problem Out There™, but I'd have to second you here - I hate bloatware!
-
Originally posted by aldo_14
What exactly is the performance hit from? What causes it? How can you say it's a performance hit when you have neither coded AI, physics, weapons (etc), ship class handling, etc to even test the basic performance?
Oh, and overhead is something that exists only to dismiss stuff. you can pretty much code in anything nowadays - all you have to do is keep it tight and optimise the code accordingly. The number 1 problem of fast computers is that people forget to do this - because they don't need to.
the performance hit is in the fact that you have to have more full AI objects, more full graphics objects, etc
aldo just because you haven't coded something yet doesn't mean you cannot make statements about it based off coding theory
and "overhead" is not something that exists only to dismiss stuff. It's actually there, and it slows down the game.
"you can pretty much code in anything nowadays" you always have been, it's getting performance that's the problem
The number 1 problem is people thinking code is infinitely optimizable, and forgetting that we're not targeting it to THEIR system
-
Originally posted by Kazan
The number 1 problem is people thinking code is infinitely optimizable, and forgetting that we're not targeting it to THEIR system
No, indeed, to the sound of it we're targetting it to YOURS.
-
mine is a 600mhz Pentium III - low end by our standards on this board - but very common by general standards, I'd be pleased to have it run on my system well
but you also have to remember there are peope that are going to think that because it's the "same game" that it's going to have the same "minimum requirements"
-
Originally posted by Kazan
the performance hit is in the fact that you have to have more full AI objects, more full graphics objects, etc
Is that true, though? You're basically replacing turret AI with a seperate AI for the turret model, the submodel with a similar polymodel, etc. beyond the fact it's docked to the ship, i don't see a major difference compared to the way that FS2's turrets seem to work. AFAIK, they have seperate AI classes and bounding boxes - they are seperate attached objects (potentially with LODs).
I don't see why it wouldn't be possible to use cut down versions of AI for turrets - they would need their own code regardless of how you implement it.
I honestly don't see how this could be considered impossible. Granted, I've not worked on AI or 3d aps, but it's already been done- and with higher AI levels and more complex bounding boxes than you'd need for pure turrets.
-
Aldo's brought up a good point... turrets need AI regardless of how they're implemented, and having them as "docked" objects rather than as subobjects of the base model won't make a difference in that respect... just instead of making them full docking points, make them dedicated turret mounts. Besides, I wouldn't mind having standardized turrets for each type of weapon... (and having a turret literally fall of the ship before it blows up would be a cool effect too... ;) )
-
I don't think it would be a good idea to use docking points to do this, it would probly be less efichent than if there was some sort of built in ability to change the turrets you have on the model. if there was a list of turret types, with geomitry, firng points, relitive normals, and animation data in ether a table or in a model file (of the turret). it just seems to me it would be better if there was one copy of the fifteen odd turret types held in memory than if there was all the repetitive turret data, not to mention from a mission design point of veiw this could only be a good thing.
as for how this would be implemented with turret points, would probly be something like
;; remember I'm not a programer, I probly ****ed this up, baddly, but I'm trying to talk you're language
;;STRT [b]S[/b]oft [b]T[/b]u[b]R[/b]re[b]T[/b]
int num_TurretPoints
for each TurretPoint, s {
vector point[x,y,z,s] ;;position of the turret
vector norm[x,y,z,s] ;;normal that defines the rotation axis and which way is up for this turret
vector forwardNorm[x,y,s] ;;normal that defines wich way is forward, the defalt direction turret will point, note this is 2d it is along the plain perpindicular to the first normal
string name[size=7pt] ;;for asigning the defalt turret type
}
now there would also be a list of turrets, I'm in favor of useing a new table,
#turrets
$name: ;;name of turret type
$pof file: ;;name of the model file
$dead pof file ;;name of model to be used when turret is destroyed
#end turret
the new animation data you mentioned would be held in the turret's pof file, as would the TGUN data with firing points and normals (most cases the normal would be 0,1,0 but some instances may be usefull to have a turret that is pointing off at an angle)
-
I can't really follow the more technical stuff here, esp. with regards to the POF data structure, cold fusion and zero-point energy (;) ), but I gather you're talking about a plug-and-pray type turret mount - the mount stores the data for direction and FOV, while the turret you put on there stores the 3d model, weapon type, etc?
-
Serves me bloody right for not reading more than the first couple posts of this thing.
-
Originally posted by Inquisitor
Serves me bloody right for not reading more than the first couple posts of this thing.
Eh? What'd ya miss? :)
-
Actually, Bobboau, that's basically what I said (although you might have started that post before mine showed up)...
And while your code earns a "close but no cigar" it does get the point across well enough... :)
-
Originally posted by Bobboau
I don't think it would be a good idea to use docking points to do this, it would probly be less efichent than if there was some sort of built in ability to change the turrets you have on the model. if there was a list of turret types, with geomitry, firng points, relitive normals, and animation data in ether a table or in a model file (of the turret). it just seems to me it would be better if there was one copy of the fifteen odd turret types held in memory than if there was all the repetitive turret data, not to mention from a mission design point of veiw this could only be a good thing.
as for how this would be implemented with turret points, would probly be something like
well, I choosed the idea of docking points (turret dedictaed ones was the original idea ) coz it sounded more simple to achieve. basically, in our good old FS2, I can do ONE turret like that already. I make a small turret pof and dock it to the ship, et voila. It was just to expand the idea in a simple yet effective way. But there's one advantage for my iway over yours ( sorry if I'm wrong, I can't really understand the technincal terms in there), it's that you can add any turret you want, even if the turret pof has been made after the ship pof. Ok wait, i'll reread your post again, not sure i really understood it at 100%...
hmm... I'll wait for your reply, I can't figure it out ( not exactly fluent in english yet ).
-
Originally posted by venom2506
well, I choosed the idea of docking points (turret dedictaed ones was the original idea ) coz it sounded more simple to achieve. basically, in our good old FS2, I can do ONE turret like that already. I make a small turret pof and dock it to the ship, et voila. It was just to expand the idea in a simple yet effective way. But there's one advantage for my iway over yours ( sorry if I'm wrong, I can't really understand the technincal terms in there), it's that you can add any turret you want, even if the turret pof has been made after the ship pof. Ok wait, i'll reread your post again, not sure i really understood it at 100%...
hmm... I'll wait for your reply, I can't figure it out ( not exactly fluent in english yet ).
Correct me if I'm wrong (there's a lot of that going on in this thread already, though. ). But isn't there a LOT more to it than simply docking a turret to a dock point? Once a turret-POF is docked with a cap-ship, then won't the turret simply sit there? What would be there to make it rotate and fire?
--TurboNed
-
In FS2, basically, I would make a thin plane with a barreled turret on it or something like that.imagine you dock an ursa to a capship, but the ursa is supersmall, and the turret huge. Voila.
-
bobboau :D that was very good psuedo-code actually
actually now that someone says something i - think we could have a turrets.tbl like the ships.tbl .. yeah, i think there should be a way to make it almost as efficient
-
others asked about materials and multylayers, i don't know if it will slow down or not performance, but i think it would be funny, maybe a solution (i'm not a programmer so maybe it is simply and idiot idea) could be to create some "default materials" that you can assign in pof editing to specific polygroups or maybe faces. for example, if you create a standard "glass material" i can assign it to my cocpits or capships' windows in the pof editor..as said, donno if it may be done or not, or if it would work better than multilayers or not
-
I’m not sure what you are able to do to shields but.
I have been making this conformed shield for the Lucifer, and believe me it is really close to the hull, BUT...
Given the fact that a Cap ship is relative large when compared to a size of a face on the shield being on a normal fighter you get these odd effects because of stretched shield polies and so.
Not even a 6000 face shield will cover the Lucifer to an extent that you get rid of those odd effects.
And this one I managed to get PCS to convert. After that I use import shield on the original Lucifer.
1 way to solve the problem would be to increase the Polygon count, but I already tried increasing it to 9000,16000 and 23000 & Currently PCS crashes “the window goes white with no error msg`s being shown” on those high polygon counts.
I don’t know if this is has something to do with the memory allocated by PCS not being able to cope with such a high shield polygon count or if it can be fixed to work at all so that those odd stretching effects can be eliminated. Note the game is not being dragged down on my system with a shield of 6003 polygons. 800 mhz Tbird, GF2.
Secondly. This one I think is an engine limitation of Freespace 2.
When a "stream" "laser" enters an assumed bounding box of the shield and has not yet hit the shield, then the shield lights up where the projectile will hit. And then lights up again when projectile hits.
I don’t know if there is any bounding box information in the POF file shield chunk that can be edited so that these "2 flashes pr hit" can be removed.
It would however be superb if you could tweak PCS to work with a shield polygon count of 10000 - 16000.
Note I tried poftocob with high limits. “Ran out of MEMO capacity”. And it never used more than
2 MB`s of ram as I can active monitor this.
-
the way PCS functions the max number of shield polys is 2 to the 32nd power minus 1 (2^32-1) it just takes a lot of time to execute because it's finding the associations
-
Ideas for a new POF format:
Support for translucent & transparent textures. (Imagine a space station with a big interior hanger bay and some "windows" through the hull. Or a station with a hydroponic garden.) And undoubtably more uses I've not thought of.
Support for a mirror texture maybe? "The beam cannon that turns corners. You see, it hits this giant mirror over here, bounces off and hits that mirror over there..." ;)
Fake turrets. Ability to have fixed direction turrets that don't need seperate submodels, a cross between gun points, turrets, and subsystems for ships where you want to have more turrets then would work well on the engine. They wouldn't increase poly count, as they'd be built onto the model, and wouldn't need a very advanced AI. (And probably no destroyed texture either.)
Better control on exactly how a subobject is able to move (so turrets won't fire through ships.)
Maybe bay subsystems/subobjects for use with escape pods that will be launched when hull == 0 or when told by a script?
Expandability: A POF section that could contain data which would be ignored unless run under a game engine that understands that data. For future expandability.
A version string so if upgrades are made later the engine can tell what features a particular POF file supports and how it expects things to work. :)
Multi-axis rotation support for submodels, including but not limited to turrets.
More a table thing then a POF thing I think, but:
Special class flag "any" or "any_weapon" to allow a ship to equip any kind of weapon regardless of it's class. And vice versa (if there's a turrets.tbl for the seperate POF idea) to allow a weapon/turret to be equipped on any ship.
More a FRED2000 thing, but support for multiple fighter bays per ship, and a better memory when using them so you don't have to keep re-assigning a wing to a fighter bay when you bring up that wing in a wing editor.
Thoughts on other ideas:
Docking port turrets: Sounds inefficient, see below.
Seperate ship/turret POFs with tables: cool, same customizability as docking port turrets and less work for ship builders who don't want to make custom turrets/weapons. :)
Models with moving/animated/script replacable subobjects: Awesome. :>
Whew. That got a lot bigger then I expected when I started. Maybe some of it will be doable and interesting enough to consider. :)
Edit: Dropped one little )
-
Originally posted by Kazan
the way PCS functions the max number of shield polys is 2 to the 32nd power minus 1 (2^32-1) it just takes a lot of time to execute because it's finding the associations
I dunno if DTP will understand, but I sure don't :sigh:
-
Originally posted by Kazan
the way PCS functions the max number of shield polys is 2 to the 32nd power minus 1 (2^32-1) it just takes a lot of time to execute because it's finding the associations
venom - 2^32-1 is, IIRC, the max value a signed (?) 32 bit register can hold. According to my calculator, this is;
4294967295
I'm not sure if the allocated memory in the COB2POF convertor can hold the required number of vertices in data, possibly the co-ordinate values would overrun the allocated stack space.
-
venom: the max size of any array on a 32bit operating system is 2^32-1` or about 4,294,00,000 [stupid kcalc won't give me exact]
-
Originally posted by Kazan
venom: the max size of any array on a 32bit operating system is 2^32-1` or about 4,294,00,000 [stupid kcalc won't give me exact]
But there could be an array of arrays of arrays of arrays to make a much larger number of "cells," right? (for future POF formats)
--TurboNed
-
Originally posted by TurboNed
But there could be an array of arrays of arrays of arrays to make a much larger number of "cells," right? (for future POF formats)
--TurboNed
The array size is based on the max register size of a 32-bit machine. whilst you can sort of synthesize larger numbers through exponentials and additional integer value, it impacts on perfromance. I think I have some C code from last year that does this, but I'll be damned if I can find it. Something to do with bit-packing a communications stream IIRC.
-
but why,
why in the name of hades would you want an aray that big
but anyway were getting a bit off topic,
so is the turret thing setteled, the new soft turrets are in?
what else do we need before the basic outline of the engine gets put together
I want Geo-mod (or something just like it with a diferent name), this is more of an engine thing and we don't realy need to add anything to the POF for it, I'll post in the other thread about this
animations,
could we get full keyframe animation in addition to the logical scripted animations that has already been mentioned, might not be necisary if the scripted animations are comprehensive enough
make sure the lights have a parent object so they can be animated with there parent as well as by them selves,
there sould be a default on or off thing for lights, also for animation
OH OH particle emitters !!!
:jaw:
oh yes that would be just SO very very sweet
look at the values you can set in red faction for it's particle emiters, be sure to include an on and off distance so we can make LODs (if you get farther away swich to a diferen't emiter with lower res textures and fewer particles), colision ditection would be usefull in a few instances
we must have particle emiters
-
Bobboau - the array _isn't_ that big.. but it _can_ _be_
it starts out with a "base value" [100 i think is what i set] then as it needs to resize it doubles it size
so it goes
100
200
400
800
1600
3200..
when it's finished it sizes to exactly the correct size
and instead of using item by item copy it copies memory blocks [ which is a high speed, low processing operation instead of a low speed, high processing operation]
-
well ok, it was just a realy big number, I was just saying it souldn't be a problem
well what about particle emiters
I want my particle emiters :nod:
I must have particle emiters :mad:
I will have particle emiters :headz:
-
i still say sequenceable explosions, but i also like the ideas for running lights and atmopheric combat...also be really nice if you could have more than one dockpoitn working at a time.
On note of the engine itself, be really cool if it could support animated backgrounds (spinning plannets)
-
well you can make a scripted death animation, this would probly be more of an engine thing than what data would be needed in the pof
-
This is all blue sky, but :
If I were you guys, I'd scrap the whole concept of POF-style files altogether. They're way old fashioned and have some pretty sharp limitations.
One sort of off-topic thing I'd suggest about this whole FSF thing - if you really want to get some kind of measurable satisfying progress - scope the sucker down. At the rate this whole operation is exploding with Grand Design you'll achieve nothing. Set a 3 month goal to have a keyboard controlled, low-poly ship running in a window using OpenGL on windows. Simple as that. I'd suggest checking out www.gamedev.net. There's a lot of guys full of hot-air on the forums over there (but hey, one could say the same thing about here too ;) ) - _but_ they have lots of useful getting-your-basic-game-up-and-running sorts of material.
I'd be more than happy to give advice (advice is the easy part when you're an armchair game designer). :)
-
I think that is a good time table for a basic rendering engine, Kaz already has a half complete openGL rendering code in his latest version of PCS. so I think as a starting point if we get something that behaves like a game with a three poly ship and none of the frills in three months, I will be impressed. but as I understand it you need to plan out all the stuff you might want in you're engine before you wright the first line of code wether or not it's defanantly gona be in it in the end (thinks of all the hidden quasi-code in the FS2 engine like when you name a ship planet, or the ssm)
of corse we would get quite a head start if we could get the FS source :D :ha:
-
If I were you guys, I'd scrap the whole concept of POF-style files altogether. They're way old fashioned and have some pretty sharp limitations.
Seems to me I heard someone say basically the same thing about the AVI format. And it's even older. :) Besides, what we're wanting to use are POF3 files, (As I'm calling them.) with loading/converting support for the older files. Assuming PCS translates at least part of a POF file into plain text, an interesting idea might be to make a version of PCS with an extra tab and a multi-line text box for putting arbitrary POF3 data in while experimenting with the format, at least until the POF3 specs are finalized. Assuming we get far enough along for making POF3 models to be an issue. :)
-
anyway, what sort of limitations, and what would you recomend we do
-
Originally posted by Bobboau
....if we get something that behaves like a game with a three poly ship and none of the frills in three months, I will be impressed.
/me tries to imagine a three-poly ship and finds it VERY difficult...seems to remember something about the minimum number of faces a closed object needs in the dimensions it occupies is one greater than the number of dimensions.
for example: a point has one point in 0D space
a line has two points in 1D space
a triangle has three lines in 2D space
a tetrahedron has four triangular faces in 3D space
a hypertetrahedron has five tetrahedral faces in 4D space (okay, I'm taking a wild guess at that one, I honestly haven't a clue)
Anyway, sorry for the derailment, but I simply had to say something that has a chance of making me appear intelligent to the ignorant masses (I hope some ignorant masses read in this forum for me to have not wasted my efforts)
--TurboNed
Edit: I agree with the spirit of what Bob's said, though...completely. I do want this project to take off, but I'll be impressed once I see real work being done.
-
you know as soon as i said that I had the same thought
-
You need at least 4 polys. That'll form a triangular-based pyramid.
-
a hypertetrahedron has five tetrahedral faces in 4D space (okay, I'm taking a wild guess at that one, I honestly haven't a clue)
That's quite true, actually. ;)
-
hey thanks for the input dave. You're very welcome to code for us if you'd like [as a non-official function of course] or tell us anything you wanted to do in the origional FS2 engine
as for 'get a function one with keyboard support in three months' - I could get an unoptimized OpenGL rendering a ship with keyboard control in not to long using OpenIL [Open Image Library] and the SDL. .. i have a half-way completely POF renderer already, and it wouldn't be difficult to remove the GLUT code and replace it with SDL code
-
Originally posted by Kazan
hey thanks for the input dave. You're very welcome to code for us if you'd like [as a non-official function of course] or tell us anything you wanted to do in the origional FS2 engine
as for 'get a function one with keyboard support in three months' - I could get an unoptimized OpenGL rendering a ship with keyboard control in not to long using OpenIL [Open Image Library] and the SDL. .. i have a half-way completely POF renderer already, and it wouldn't be difficult to remove the GLUT code and replace it with SDL code
for DaveB: I doubt you would help in any way ( you have a job after all :p ), but if thanx to some incredible odd you could, I know you don't like Kazan, so consider helping the project, not him... If you could and didn't want just because of him, that would be sad :(
-
NEVERMIND