[Trivial Psychic]

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.

[CaptJosh]

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...

[Nuke]

what about the replacement interface and the new hud system, any work expected on those?

[starfox]

Yeah, Im also very interested for the Interface replacement. Is it going to be something like a current Shiplab, or something else ?

[taylor]

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.  Just blame Goober, always works for me.  

I've got so much new stuff going on that it would make you all sick.

[Trivial Psychic]

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.

[Nuke]

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.

[WMCoolmon]

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 on Python integration as well to give a lot of flexibility (without sacrificing much simplicity) to modders.

So general idea for a gauge entry:

Code: [Select]

$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.

[Nuke]

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.

[mikhael]

Originally posted by WMCoolmon

...
For both of these I'd probably be relying 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?

[Axem]

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.

[WMCoolmon]

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?

[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?

[WMCoolmon]

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 See the HUD/Python thread.

[Goober5000]

*Throws flak at WMC*

I hate Python.

[StratComm]

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.

[IPAndrews]

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.

[IPAndrews]

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.

[Flipside]

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

[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.