Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Mav on November 11, 2009, 07:16:33 pm
-
Well, I'd like to include drones as weapons for a mod or two...
(actually, I already started this shortly after my v1.1 Ravana-mission, i.e. quite a while ago, as part of 1.2 - not that it was the most critical part, just a nice extra :) )
My idea for it is to make a multi-spawning missile, that re-spawns both itself and a few shots in straight line. (thanks to the SCP-staff for making multi-spawn working :yes:, and adding vector settings to spawning)
Problem would of course be that those drones would be indestructible, even when flagged as bombs.
So - could there be a health-value be added to missiles, and if such a missile should be destroyed, spawning would not take place (or, maybe, be governed by a separate destroyed-spawn-flag) ?
Also, I heard that spawning primaries wouldn't currently work - it would be great if this, too, could be solved; but it shouldn't be critical - I could just create "primary" secondaries of some sort, as the ammo counter won't be a problem...
-
Nuke has already shown that drones of various sorts can be done.
Scripting. Learn it.
Edit: and then join the RTS mod team, we need scripters/coders. But only if you're good.
-
Hitpoints for missiles already exist. Retail was 50 points. 3.6.11 has support for whatever value you want.
-
Oh, as for this:
I could just create "primary" secondaries of some sort, as the ammo counter won't be a problem...
I tried (using scripting) to make a primary weapon which was immediately replaced with a missile upon firing, so it could home properly. Problem was, I had fired ~1000 primary shots and got ~1000 secondary hits. Meaning my primary accuracy was zero and my secondary accuracy was > 100%.
-
Greater than 100% ? Damn, that's talent. :P
-
Greater than 100% ? Damn, that's talent. :P
Not really - you get that with every ship that has sufficient turrets. Maybe even with Piranhas, but I'm not sure about this one.
Hitpoints for missiles already exist. Retail was 50 points. 3.6.11 has support for whatever value you want.
Good to know, thanks :) .
But I'd still need something like "$Flags: (... , destroyedSpawn (nothing), ...)"
@Aardwolf:
Well, the drone's a missile anyway - I'll just make it fire missiles that LOOK like primaries, even if I need to create a .pof for that...
[edit: Also... RTS mod? I'll have to try that first...
But still, I usually have enough to do for my own mods anyway, sorry :-/ .
I might take interest in that RTS-mod, but don't count on it...
And about scripting: Sure, I'll try. Downloaded those wiki-sites to read them later...
But still it would be better if it was directly supported by the code.
Of course - I guess there are certainly things with higher priority to the coders, so well...]
-
Secondaries can use laser-type rendering, just like primaries.
I did that and it worked well, though I'm unsure about shooting down secondary that doesn't have a model.
-
http://www.youtube.com/watch?v=6uFrJlSyXO4
skip ahead to about 1:15
-
http://www.youtube.com/watch?v=6uFrJlSyXO4
skip ahead to about 1:15
Thanks. Is this (the working cockpit) doable with current nightlies, or a preview of something to come?
BTW. , I'll propably HAVE to user fake-primaries.
I recently tried real primaries... they DO spawn, but with random type and without $SpawnAngle working... :-/
-
it works fairly well. most of the new script functions i wrote were committed so no custom builds are really required. of course im not gonna release it till its done. i still have several input bugs to fix. the cockpit demo also sprouts a lot of cool input options. such as several mouse control options, throttle axis reverse thrust zone, mouse control of lateral/vertical thrusters and so on. drones can work with either an rtt window or fullscreen. and you can now control them with your ship controls kinda like descent 2. also theres a bunch of trackir stuff ive added. the problem is abstracting all these input meathods and then providing an interface so the user can change settings without editing a text file. i think its something the game engine should handle. scripting has a whole lot of low level access to things it really should deal with at a higher level. the game provides an interface for binding keys and axes and i kinda wish i could use that from scripting, instead of having to write 4 different systems to recreate that functionality. such as a file parser/saver, a ui for changing the settings and so on, things the game already has but which has no scripting access.
-
Well, thanks... but for the most part, I'm interested in your working monitors, as I'd like to implement such on my ships, too. :)
So- what'd I have to do for that?
-
that still hasnt been set in stone. right now i have a bunch of invisible textures in my model, floating over the textured screens in my ship. if rtt doesnt fail then those invisible textures are replaced with rtted textures. of course this is temporary. also it tends to cripple framerates right now and theres some z sorting issues when dealing with the rtt cameras. i also at some point want to add working hud screens and i have an idea how to make it work, but im lazy. modability isnt hard though, my script parses a custom table file for most of the ship settings, contains info about player controllable turrets, camera positions, scripted animations and such.
id like to get all this stuff working with the new cockpit model feature, but i have no scripting access to those that i know about. so this only works with show ship cockpits. meaning that if you make the cockpit model to high res youl slow down the game because they get rendered for every ship in the mission. you could probibly get around this with per subobject detail distances (if they ever get implemented) or maybe detail boxes. performance is the main issue with the script at this point.
-
Woah...so you managed to get both reverse-thrust throttle and controllable drones working? Maybe my far-fetched ideas about a full-fledged Descent mod weren't so crazy after all. :)
-
its possible the only real problem is levels would be kinda bland without moar light sources. though you could probibly render lighting to texture in max and use them as glow maps for some makeshift light mapping. that would however require every polygon to have unique uv space. its an idea that suffers the same fate as my concept of a bridge simulator, the lack of graphics to test it with (and the lack of desire to make them).
-
I was thinking that it might be best to concentrate solely on the multiplayer side of things for a start, at least in terms of getting the movements and weapons balance right. Just stick a few Pyros out in space with some random invulnerable ship obstacles and let them have at it. As far as levels go, the structure of something like good ol' Skybox would be easy enough to reproduce, and that thing used pretty generic rock textures to begin with. :p
-
there was a doom 3 descent mod which was fairly awesome, but work on it seems to have stopped.
http://www.chmodoplusr.com/IntoCerberon/
making it multiplayer would probibly work the best, since theres currently no scriptable access to ai. technically speaking we dont have any real way to override physics either. most of my physics mods (which i keep in a whole other folder), rely on a series of dirty hacks to work. there is no override and no physics hook. but as far as ai is concerned we have almost zero access to it from scripting.
for graphics, its one of those things that would work better if we had more than one uv mapping channel. then you could bake your light maps independant of the diffuse texture(s). this would allow for more texture re-usage in the level and better overall quality for less performance cost.
room based game engines use portholes to separate areas which need not be rendered. say youre in one room and the next room, separated by a door is not rendered until the trigger to open the door is fired. when the door closes the rendering of the adjacent room is shut off. another trick is to include cornered hallways so its impossible to see 2 rooms at the same time. theres usually a couple invisible triggers on each entrance to that angled corridore so that when you pass the first you turn on rendering for the next room and you pass the second turn off rendering to theprevious room. that this is why fps games get away with such high detail.
in freespace we dont have portholes but we do have detail boxes and loding. so if we make each room a ship. we set the first lod distance to only render the entire room if youre within that rooms radius, if you exit the room then the detail either cuts off fast, to an lod with one dummy invisible polygon. if the room is visible from the next then we can lod it down more slowly. the idea is to make it so you can only see a few rooms (ships) at a time.
we may need a few source tweaks though, for example, we need a way to make an object derivative, such as a ship, static. it never moves and never changes its position or orientation. everything tagged as static is transformed to world space once at mission load (instead of every frame which makes it faster). this would be useful for lots of things, terrain, planet models, ect. aligning rooms in fred would be hard enough without them moving about at runtime. some fred tweaks may come in handy to make rooms snap together at certain points or to make the orientation match (especially if rooms are placed at odd angles). might need a few new types of animation trigger that goes off if a player comes near it/touches it/activates it/destroys it, whatever. i dont see that being really hard to do, might even be fairly easy to script. and finally better control of dynamic lighting, such as light emitting textures or glowpoints. most hardware supports around 8 hardware lights. so if each room only has 8 dynamic light sources to deal with then it should work fine. room lights should be able to be activated by lod or distance. so that only lights in the current room are rendered as well as lights from weapons or player ships.
do that and a descent mod for freespace is possible. but i think it would be a lot of work to do right. frankly the idea of a descent mod is daunting. while i realy wouldnt want to do any level design or modeling in general id be happy to provide such a mod team with at least some script support (i have some mercury missile effects already working in game and have managed to get guided missiles to work as well as other descent like weapons) and perhaps il finish my pyro ix model for it.
-
room based game engines use portholes to separate areas which need not be rendered. say youre in one room and the next room, separated by a door is not rendered until the trigger to open the door is fired. when the door closes the rendering of the adjacent room is shut off. another trick is to include cornered hallways so its impossible to see 2 rooms at the same time. theres usually a couple invisible triggers on each entrance to that angled corridore so that when you pass the first you turn on rendering for the next room and you pass the second turn off rendering to theprevious room. that this is why fps games get away with such high detail.
I think you've misunderstood the concept of a Portal-based rendering engine and confused a variety of different techniques for culling...
Room-based engines (eg the original Descent, all first-person shooters) use a variety of different techniques to determine if entire sections of the model are currently visible.
- Common techniques include 'level triggers' where entire map sections are loaded from disk as a player enters a certain area (the 'loading' screens in Half Life), and other quick visibility culls commonly using BSP trees.
'Portal' engines are extremely rare in fact - these have 'segments' joined by 'portals'. If the transparent portal polygons aren't visible, then nothing in the segment is visible.
(A friend of mine built a 'true portal' engine space fighter game for his MSc, where the portals didn't have to join in 3-space. Space combat in a tesseract was a little bit confusing!)
FreeSpace2 does very little culling, as it makes the basic assumption that all objects are visible at all times.
Detail boxing and LODs are done as straight model-replacement on a simple distance-to-centroid basis.
Only backfacing polygons and (possibly) polygons hidden by the front of the model are not drawn. (I'm not sure about the latter.)
(And it still gets confused about what should be visible sometimes)
-
room based game engines use portholes to separate areas which need not be rendered. say youre in one room and the next room, separated by a door is not rendered until the trigger to open the door is fired. when the door closes the rendering of the adjacent room is shut off. another trick is to include cornered hallways so its impossible to see 2 rooms at the same time. theres usually a couple invisible triggers on each entrance to that angled corridore so that when you pass the first you turn on rendering for the next room and you pass the second turn off rendering to theprevious room. that this is why fps games get away with such high detail.
I think you've misunderstood the concept of a Portal-based rendering engine and confused a variety of different techniques for culling...
Room-based engines (eg the original Descent, all first-person shooters) use a variety of different techniques to determine if entire sections of the model are currently visible.
- Common techniques include 'level triggers' where entire map sections are loaded from disk as a player enters a certain area (the 'loading' screens in Half Life), and other quick visibility culls commonly using BSP trees.
'Portal' engines are extremely rare in fact - these have 'segments' joined by 'portals'. If the transparent portal polygons aren't visible, then nothing in the segment is visible.
(A friend of mine built a 'true portal' engine space fighter game for his MSc, where the portals didn't have to join in 3-space. Space combat in a tesseract was a little bit confusing!)
FreeSpace2 does very little culling, as it makes the basic assumption that all objects are visible at all times.
Detail boxing and LODs are done as straight model-replacement on a simple distance-to-centroid basis.
Only backfacing polygons and (possibly) polygons hidden by the front of the model are not drawn. (I'm not sure about the latter.)
(And it still gets confused about what should be visible sometimes)
mod definable master visibility range would be useful especially on mods which use or emulate vast battle areas, WCS comes immediately to mind
-
do that and a descent mod for freespace is possible. but i think it would be a lot of work to do right. frankly the idea of a descent mod is daunting. while i realy wouldnt want to do any level design or modeling in general id be happy to provide such a mod team with at least some script support (i have some mercury missile effects already working in game and have managed to get guided missiles to work as well as other descent like weapons) and perhaps il finish my pyro ix model for it.
I know a Descent mod would be a big undertaking, but if it were pulled off right, I think it could be something really special, and it could potentially stir up some big interest in the Descent community too. A few people are still working on the D1 and D2 source code, but not all that many people still play those games to begin with, and D3's mod development has all but stagnated thanks to its source code never having been released. As you noted, the Into Cerberon mod had a lot of promise (though I haven't played it myself), but it didn't really go much of anywhere in the long run. If someone were to bring the Descent experience to an actively-developed engine like FSO, it could allow for all sorts of fun along the line.
As far as actually developing a mod goes, I'm not a modder by any stretch of the imagination, but I did take the ported D3 models and do some fooling around with table files until I have something at least approximating the Pyro-GL's correct stats. (The values in the D3 tables don't all correspond to real-world values, so it was kind of an inexact science.) I made a thread a while back asking about some of the specific requirements for a full-fledged mod, and how possible they'd be in the engine as it stands, but I think a lot of the responses were largely inconclusive. If you or anyone else ever did get some sort of effort going, I'd love to help out as best I could, even if it were only in the form of screwing around with tables and attempting to port weapons graphics.
Um...sorry for completely derailing this, Mav. :p I can take this conversation elsewhere if it continues.
-
room based game engines use portholes to separate areas which need not be rendered. say youre in one room and the next room, separated by a door is not rendered until the trigger to open the door is fired. when the door closes the rendering of the adjacent room is shut off. another trick is to include cornered hallways so its impossible to see 2 rooms at the same time. theres usually a couple invisible triggers on each entrance to that angled corridore so that when you pass the first you turn on rendering for the next room and you pass the second turn off rendering to theprevious room. that this is why fps games get away with such high detail.
I think you've misunderstood the concept of a Portal-based rendering engine and confused a variety of different techniques for culling...
Room-based engines (eg the original Descent, all first-person shooters) use a variety of different techniques to determine if entire sections of the model are currently visible.
- Common techniques include 'level triggers' where entire map sections are loaded from disk as a player enters a certain area (the 'loading' screens in Half Life), and other quick visibility culls commonly using BSP trees.
'Portal' engines are extremely rare in fact - these have 'segments' joined by 'portals'. If the transparent portal polygons aren't visible, then nothing in the segment is visible.
(A friend of mine built a 'true portal' engine space fighter game for his MSc, where the portals didn't have to join in 3-space. Space combat in a tesseract was a little bit confusing!)
FreeSpace2 does very little culling, as it makes the basic assumption that all objects are visible at all times.
Detail boxing and LODs are done as straight model-replacement on a simple distance-to-centroid basis.
Only backfacing polygons and (possibly) polygons hidden by the front of the model are not drawn. (I'm not sure about the latter.)
(And it still gets confused about what should be visible sometimes)
well my understanding of portholes (not to be confused with porals) mostly comes from working on several quake 1 and 2 maps. these used area porthole triggers to enable rendering on and off at certain rooms. i got the techniques down but quickly realized i suck at architecture. as a result i have a ****load of unfinished quake maps omn my hard drives. freespace 2 while i think its loding system is kinda cumbersome, still i think theres enough to do a room based engine that culls properly. backface cull is done pretty much in all game engines because its stupid not to. it can easily double your rendering performance.
do that and a descent mod for freespace is possible. but i think it would be a lot of work to do right. frankly the idea of a descent mod is daunting. while i realy wouldnt want to do any level design or modeling in general id be happy to provide such a mod team with at least some script support (i have some mercury missile effects already working in game and have managed to get guided missiles to work as well as other descent like weapons) and perhaps il finish my pyro ix model for it.
I know a Descent mod would be a big undertaking, but if it were pulled off right, I think it could be something really special, and it could potentially stir up some big interest in the Descent community too. A few people are still working on the D1 and D2 source code, but not all that many people still play those games to begin with, and D3's mod development has all but stagnated thanks to its source code never having been released. As you noted, the Into Cerberon mod had a lot of promise (though I haven't played it myself), but it didn't really go much of anywhere in the long run. If someone were to bring the Descent experience to an actively-developed engine like FSO, it could allow for all sorts of fun along the line.
As far as actually developing a mod goes, I'm not a modder by any stretch of the imagination, but I did take the ported D3 models and do some fooling around with table files until I have something at least approximating the Pyro-GL's correct stats. (The values in the D3 tables don't all correspond to real-world values, so it was kind of an inexact science.) I made a thread a while back asking about some of the specific requirements for a full-fledged mod, and how possible they'd be in the engine as it stands, but I think a lot of the responses were largely inconclusive. If you or anyone else ever did get some sort of effort going, I'd love to help out as best I could, even if it were only in the form of screwing around with tables and attempting to port weapons graphics.
Um...sorry for completely derailing this, Mav. :p I can take this conversation elsewhere if it continues.
actually idtech4 is the perfect engine for a descent mod. it has the right kind of lighting and is mainly room based. also it will end up being open source as soon as john carmack rolls out his next game engine (assuming he doesnt take up rocket science full time :D ). into cerberon was totally awesome in terms of that classic descent 2 gritty, dirty, dark feel. its actually somewhat playable in multiplayer, but thats about all it can do.
-
that still hasnt been set in stone. right now i have a bunch of invisible textures in my model, floating over the textured screens in my ship. if rtt doesnt fail then those invisible textures are replaced with rtted textures. of course this is temporary. also it tends to cripple framerates right now and theres some z sorting issues when dealing with the rtt cameras. i also at some point want to add working hud screens and i have an idea how to make it work, but im lazy. modability isnt hard though, my script parses a custom table file for most of the ship settings, contains info about player controllable turrets, camera positions, scripted animations and such.
Well, all I want is a way to assign hud anis to as texture of a polygon with "show ship" activated, just like the thruster ani which is also controlled by ingame variables (speed, afterburner) is assigned by placing a thruster01.pcx there... Is something like that already doable or at lest in the works?
id like to get all this stuff working with the new cockpit model feature, but i have no scripting access to those that i know about. so this only works with show ship cockpits.
What exactly is this "new cockpit model feature" ? :confused:
meaning that if you make the cockpit model to high res youl slow down the game because they get rendered for every ship in the mission. you could probibly get around this with per subobject detail distances (if they ever get implemented) or maybe detail boxes. performance is the main issue with the script at this point.
The approach I detailed above would easily take care of this via LODs - or at least I think it should... shouldn't it??
Admittedly, I haven't yet gotten into Lua scripting... so I'm pretty lost on the things you talk about it... :nervous: (What, for example, does "rtt" reference to?? :confused: )
-
"rtt" stands for "render to texture". It's a technology where you can paste the view from a camera placed somewhere in your 3d space, and use the output as a texture on some model that the player actually gets to see. Examples for this would be the big screens Dr Breen is appearing on in HL2s opening. An obvious application for this in FS2 would be HUD elements projected onto 3d cockpit models.
-
render to texture simply makes it possible to render to a texture instead of just the frame buffer. this texture then may be used in game. you can simulate mirrors and cameras and the like. you can also output 2d graphics to texture to make gauges. it works much better than just using an ani. there might be some degree of script control over animation playback, which works fine for any 1 dimensional gauge like a throttle indicator.
-
Hmm... kk, thanks for explaining.
So, as I understood it, this "rtt" is still being WIP then... hm.
Me hopes it'll make it into 3.6.11 , then :) .
-
You could do it right now, but it has serious performance penalties. Needs an engine rewrite, most likely.
-
it can be made to work but its nearly cutting the framerate in half in all my tests.
-
Can't it be kept from being drawn for all fighters by LODing ??
-
"rtt" stands for "render to texture". It's a technology where you can paste the view from a camera placed somewhere in your 3d space, and use the output as a texture on some model that the player actually gets to see. Examples for this would be the big screens Dr Breen is appearing on in HL2s opening. An obvious application for this in FS2 would be HUD elements projected onto 3d cockpit models.
Except it can also mean "real time tactics", which led to some confusion when Nuke was talking about it, leading me to think he was already working on something like the FS2 RTS Mod. Then I was like "well, there should be an RTS Mod!" so we made one. And it was good.
-
Can't it be kept from being drawn for all fighters by LODing ??
You don't understand. It is horribly inefficient, even if it is only drawn for the player.
And as it is drawn via scripting, it's relatively easy to not do it for every ship in the mission; that is not the point.
-
my system only creates textures for the player. however there is a lot of inefficiency because of the number of render targets im using. all the 2d effects need to be drawn to one texture, cameras need to be rendered to their own textures then drawn as a 2d image to the main texture, since theres no way to mirror the scene properly. now you should be able to mirror the camera matrix to flip the scene the right way, but freespace seems to be built around 3x3 matrices which really gets annoying for this kinda thing. final version i might just go to using a single video screen only, and all the cockpit done with one texture, then i can alternate the render targets every frame so only one texture gets updated. still its so slow that its gonna need to be an optional feature for people with high end system.
-
Did you ever post a example of your RTT script?
I would be happy with something simple as rendering the target computer view onto a texture, which would then be mapped into a cockpit POF.
-
Hey, "Drones..."-related question: is it possible to have weapons with hitpoints that are not targetable (or which are not targetable with B, i.e. you would have to use the reticle targeting control) ?
-
i kinda have that already, i have a multi-target type weapon that works with a tight beam radar. right now the radar range is adjustable so you can cover a narrow beam at long range or a wide beam at close range, however with some tweaks i can make the beam tighter so you would have to keep the target sighted to hit it.