Hard Light Productions Forums
Hosted Projects - Standalone => The Babylon Project => Topic started by: Skullar on November 05, 2007, 08:26:20 am
-
I noticed that the hyperspace vortexes that used to be fine in previous releases seem to be WAY too big now....
They all appear many times bigger as they should.
-
I noticed during the development of my recent campaign, that a 1000m 2d jumpeffect works well inside the jumpgate but when I replaced them with a 3d, it looked like the jumpgate jumped and I had to scale it down to 650m.
Maybe it has something to do with that ?
Moderator edit: Interested in this thread? Then also read this thread: http://www.hard-light.net/forums/index.php/topic,50861.0.html
-
similar effect. I don't know if this is a fresh bug or if it has been done on purpose.
When using custom Jumppoints it's no problem, but when ships jump in and out of their own, their jumppoints are WAY too exaggerated. Anyone else noticed ?
-
The change happened when we moved to the new 3D warp effect model. Which is generally an improvement. It's just the size thing. The person you need to bug about it is Asprin. The effect comes from his Minbari Project team. I will give you his ICQ# when I get chance.
-
Ian, I am sure I have seen the 3d-model ingame with correct scaling. Just like the one who did the BABYLON_FLAIL video you all know...
-
Why don't you investigate? If you can provide fixed files I'll ensure they are in 3.4a.
-
I would, but I am afraid I have no idea where to start. Not my area of expertise.
-
No. Me neither.
-
:mad2: Supersized jumppoint vortex and missing glowmap support make Skullar go crazy :mad2:
It's convenient to complain when you are not the one supposed to clean up the mess, but someone has to say something !!! :hopping:
-
Say what you like. Just don't expect me to fix it.
-
If you get Asprin's ICQ #, and no one else here wants to, I can contact him.
-
Say what you like. Just don't expect me to fix it.
I sense the tone of someone who's troubleshot enough TBP issues for one lifetime.
-
That's not it. It's just I don't have the time. If you guys provide an improved warpin model, one from an earlier version of the mod or a rescaled version of the new one by Asprin, then I will ensure it goes in the download. But that's the best I can offer. It's put up or shut up time people. If something's bugging you you're going to have to do some work to fix it yourselves now.
-
The effect comes from his Minbari Project team.
Well, the size of hyperspace vortex has been corrected up to actual (as Ian asked me day ago), however we're still working on warp out physics. The vortex also will has minimum size for all ships smaller then a jumpgate, vortex for other ships will depend on its x/y/z size.
-
...I hope this size is actual: http://fsdnl.jino-net.ru/warpin.avi
-
WOW !!!!! Is this TBP ingame ?
Cooooooooooooool , and the ships are also "fast" when coming out of hyperspace.
Thats just GREAT man !!!!
How can I thank you ?
-
Is this TBP ingame ?
Yes. But remember - work is still in progress. Warp in is ok, but warp out is not.
-
More important than your custom built gam engine Asprin, please can you provide a resized version of your 3d warp pof which results in a smaller vortex. As you can see, people think the current one is rather big. This is a pressing matter. While your custom game engine is something for later.
-
The vortexes I have ingame are MANY TIMES the size of the one you see in his beautiful vid.
So, I wondered if I just have a strange bug.
-
your 3d warp pof
Ian, it is not pof model. It is cpp changes.
-
So you're suggesting 3.6.9 retail made warp vortices bigger?
-
warp vortices bigger
Yes.
-
The vortexes I have ingame are MANY TIMES the size of the one you see in his beautiful vid.
So, I wondered if I just have a strange bug.
Well let's see. Take a screenshot of a ship warping in at a distance in front of the player. Tell me everything I need to know to recreate the exact same warpin scenario. THe ship used, distance, screen res... and I will take a screenshot. Then we can compare.
-
warp vortices bigger
Yes.
So would scaling your warpin model pof smaller counter this change and return the vortices to a more accurate size?
-
will try to, but making a screenshot is something I haven't succeeded in ever since I installed from msi
I will try to deliberately make this \screenshot folder and try again. I just don't get it.
-
will try to, but making a screenshot is something I haven't succeeded in ever since I installed from msi
I will try to deliberately make this \screenshot folder and try again. I just don't get it.
If you can't do the test then maybe someone else reading this can.
-
return the vortices to a more accurate size?
Vortex size depends on ship size, not on vortex pof model. If ship smaller then jump gate->vortex will has minimal size (such as in video); if bigger then jump gate->vortex will be created based on ship size.
-
Yes but the vortex itself is a pof, with a scale.
-
Yes but the vortex itself is a pof, with a scale
Anyway, Ian, our warp in/out POF MODEL (not current pof) will be make physical effects like in IFH, not visual.
-
your 3d warp pof
Ian, it is not pof model. It is cpp changes.
Post up a diff and I'll do some testing.
-
Yes but the vortex itself is a pof, with a scale
Anyway, Ian, our warp in/out POF MODEL (not current pof) will be make physical effects like in IFH, not visual.
That's good for you, but I'm investigating an apparent problem with TBP which uses standard game engine builds.
-
That's good for you, but I'm investigating an apparent problem with TBP which uses standard game engine builds.
Nothing keep us from making builds for TBP.
-
It would be a very bad idea to start down that path. Believe me. I have experience with the BtRL build and I'm going to be happy once we get everyone back to using 3.6.10 Official.
-
TBP will not be moving to non-standard builds.
-
Nothing keep us from making builds for TBP.
Looks like i have stated the idea incorrectly. Well, i do not mean the non-standard full-builds, i mean our CODE MODIFICATIONS that possibly could be use in standard builds...when "-tbp" flag is active.
-
The -tbp flag is on it's way out though. It's pretty stupid to have something that can screw up missions in a launcher flag where any idiot can get at it.
And that's before we get to the point of how it's rather unfair to have code which other projects could use locked up in a single all or nothing flag.
-
Anyway, is this possible:
i mean our CODE MODIFICATIONS that possibly could be use in standard builds
-
Hmm... possible solution: ?
Put it so that the TBP features are all mission flags / SEXPs... I imagine this is what you are doing when you say you are phasing out the -tbp flag. But couldn't you include a master -tbp or -wcs or -btrl flag IN THE MISSION CONFIG that enables all TBP or WCS or BtRL flags, instead of having them off by default? Or do I not know what I'm talking about? (Not sure I do.)
-
Just took a look at the 3d warp scaling, and it is indeed off by a little (should be "radius / 25" rather than "radius / 20"). That isn't a "change" though, merely how it's always been.
I double checked in normal FS2 that the 2D and 3D effects are scaled the same now for the same ship, so I'll add this change to CVS for inclusion into 3.6.10.
-
Put it so that the TBP features are all mission flags / SEXPs... I imagine this is what you are doing when you say you are phasing out the -tbp flag. But couldn't you include a master -tbp or -wcs or -btrl flag IN THE MISSION CONFIG that enables all TBP or WCS or BtRL flags, instead of having them off by default? Or do I not know what I'm talking about? (Not sure I do.)
There will never be a BtRL flag (not while I draw breath at least.) :p BtRL started up much later than WCS or TBP and the idea of having a flag that turned on specific features for that mod had already fallen out of favour. From what I understand WCS are already in the process of unbundling stuff from their flag and turning it into table entries.
So that just leaves TBP. And the question here is whether to make all the tables need fixing for 3.6.10/3.7 (where ever we unbundle) or just to add a master switch to ai_profiles.tbl.
-
Sorry Kara but I don't want to modify TBP further after TBP 3.4. So any change to SCP that requires changes to TBP (such as doing something with the Enable features for The Babylon Project flag) is effectively a decision by the SCP team to drop support for TBP.
-
I thought 3.4b was final? :confused: So anything to modify TBP after that would have to be made by someone who was willing to take up the continuation of modifying TBP, right? (eg, putting normal maps in TBP if they aren't already there.) Or did I miss something here?
-
I think you've missed something. I'm pretty sure that's what I just said. :lol:
-
Well, that's not unusual, and I've got a head cold. :ick: So processing right now is a little flaky.
-
While I am here.
Anyone interested in this thread please also read this thread:
http://www.hard-light.net/forums/index.php/topic,50861.0.html
-
Sorry Kara but I don't want to modify TBP further after TBP 3.4. So any change to SCP that requires changes to TBP (such as doing something with the Enable features for The Babylon Project flag) is effectively a decision by the SCP team to drop support for TBP.
To be honest I'd prefer to get rid of the flag completely but if this the last ever release we can simply unbundle the options while leaving the option to turn them on via the flag. Then we'd simply remove the -tbp flag from being one of the ones that is selectable in the launcher. It would become one of the ones you selected by typing it into custom flags (Like no_emissive_light or -ambient_factor).
That should pretty much remove the problem of people accidentally selecting it while also allowing other mods to use the special TBP features without needing them all.
-
As I understood it FS2 and it's various mods have installers which set the correct flags. So there is no real need to fiddle with them. In addition anyone who turns on a flag entitled Features for The Babylon Project in the launcher, is an idiot. I would imagine there are a small number of those playing FS2 since it seems to attract a more intelligent audience. There are on the other hand a large number of TBP players out there (albeit quiet ones). I believe it would be a shame to inconvenience the large number of TBP players (compared to the small number of idots) with having to fiddle around setting command line parameters if they want to upgrade to a new version of SCP. Don't get me wrong I appreciate the principle behind getting rid of the flag entirely, and agree with it, but in this case I think the cons outweigh the pros.
That said, it's your engine so do as you will. The game engine builds you gave us do a fabulous job too. So if you guys drop support for TBP in the future (which strikes me as quite likely in some form or other) then it's not the end of the world. Thanks mate.
-
Umm... *probes around for a solution agreeable to both parties* How about making it available as a FRED mission flag? Then just add the flag to all the missions (sounds easy enough, I'll do it if no one else will... then you can unbundle the options, but have the FRED flag be a master switch. Or how about a launcher6.ini entry? That way, all future engines will see the option in \The Babylon Project\launcher6.ini , as long as the correct launcher6.ini is included with the final TBP. If there is a common solution to be found, now is the time (before the "final (no really final)" edition is out. XD Whaddya guys think?
-
It never wouldn't have been a launcher6.ini switch jr2. :p
As I understood it FS2 and it's various mods have installers which set the correct flags. So there is no real need to fiddle with them. In addition anyone who turns on a flag entitled Features for The Babylon Project in the launcher, is an idiot. I would imagine there are a small number of those playing FS2 since it seems to attract a more intelligent audience. There are on the other hand a large number of TBP players out there (albeit quiet ones). I believe it would be a shame to inconvenience the large number of TBP players (compared to the small number of idots) with having to fiddle around setting command line parameters if they want to upgrade to a new version of SCP.
The way FSO currently works the only time you need to actually set the flag is if you've deleted the launcher6.ini file. That's true even if you upgrade the build. So hiding the flag shouldn't have any real effect on your users.
Furthermore when someone does delete their launcher6.ini I usually say something like "Cut and paste this line into launcher->Features->Custom Flags. -spec -glow -env -jpgtga -mipmap -nomotiondebris -missile_lighting -targetinfo -ship_choice_3d -3dwarp -tbp -snd_preload -no_set_gamma -window -ambient_factor 65 and it will rebuild your ini file for you"
That wouldn't change.
That said it does balance out to making things a tiny bit more difficult for normal users who run into an uncommon problem vs a tiny bit easier for idiots. So given that it's probably not worth the effort of hiding the flag. I'll still be unbundling the features to table entries though so that people who want to use them on other mods can as well.
If at a later stage someone else wants to take up development of TBP I'll remove the flag then. :)
-
How about making it available as a FRED mission flag? Then just add the flag to all the missions
:eek2:
-
Yes, I did notice that. :) It would actually be more work than simply adding it to the tables :D
-
sounds easy enough, I'll do it if no one else will... then you can unbundle the options, but have the FRED flag be a master switch.
It can't be that hard... XD
I once had to work on a Mac, converting uncompressed .TIFF images to HQ compressed .TIFF A whole CD full of clipart. Took me 1-2 hours, but I did it. And no, I didn't have some version of IrfanView on the compy... It was all File-Open-Save As. ;)
-
It's not hard. It's just not smart. An AI profiles table switch would have the same effect in about 20 seconds of editing.