| UTC/GMT | Sunday, October 11, 2009 at 1:00:00 PM | UTC |
| London (U.K. - England) | Sunday, October 11, 2009 at 2:00:00 PM | UTC+1 hour BST |
| New York (U.S.A. - New York) | Sunday, October 11, 2009 at 9:00:00 AM | UTC-4 hours EDT |
| San Francisco (U.S.A. - California) | Sunday, October 11, 2009 at 6:00:00 AM | UTC-7 hours PDT |
| Perth (Australia - Western Australia) | Sunday, October 11, 2009 at 9:00:00 PM | UTC+8 hours WST |
For those of us based in Europe, I have to say that my gut response to the times stated was a WTF!!??, given that it appears to specifically exclude the whole of Europe.You get the usual Australian experience this way!
I am certain that was not the intention, but that's what it felt like.
Should we defer setting a time until karajorma gets his October schedule?
Should we defer setting a time until karajorma gets his October schedule?Makes sense.
how do i attend? I mean since I got an invitation vie email and all.
I know it's off topic but hows the job going karajorma?
[22:01] <karajorma> Soooo. We having a meeting? :p
[22:02] <Goober5000> so, we do :)
[22:02] <Goober5000> I just edited my last post in the meeting thread
[22:03] <karajorma> Okay
[22:03] <Goober5000> unfortunately, portej isn't here
[22:03] <karajorma> Yeah, I've noticed that
[22:05] -->| Pyro4d ([email protected]) has joined #scp
[22:05] <karajorma> So now what?
[22:05] =-= Pyro4d is now known as Pyro3d
[22:05] <Goober5000> well
[22:05] <Goober5000> we can throw some stuff out there, for now
[22:05] <Goober5000> for instance, Qt vs. wxWidgets
[22:06] <Goober5000> I confess I haven't worked with Qt at all
[22:06] <karajorma> I've installed both, thrown up my hands at trying to get them to work in MSVC and gone back to MFC. Does that count? :p
[22:07] <IssMneur> not that it matters much, but I have never been able to get QT to work for me, but wxWidgets has worked quite well and easily
[22:08] <Goober5000> hehe
[22:09] <Goober5000> I have found wxWidgets easy as well
[22:09] <Goober5000> the documentation online has been quite thorough and helpful, unlike other GUI toolkits
[22:09] * Goober5000 glares at MFC
[22:09] <Goober5000> and it took me very little time to set up the bare-bones shell of wxFRED
[22:09] <The_E> And another comment from the sidelines: How easy is it to integrate wxWidgets into VS, and whyt do I need to do it?
[22:09] <Goober5000> the implementation (meaning coding up all the dialogs, etc.) is of course what's going to consume the majority of effort :D
[22:10] <IssMneur> ya, spit and polish :)
[22:10] <The_E> More like meat and bones
[22:10] <Goober5000> it's a lot more than spit and polish; it's the whole guts of the application! :p
[22:10] <Goober5000> yeah, what E said
[22:10] <Goober5000> anyway, about VS integration, I don't thnik it's strictly necessary
[22:11] <Goober5000> what people desire is an IDE, so they can build their application in a WYSIWYG environment, without having to do a bunch of configuration file editing
[22:11] <The_E> Yep
[22:11] <Goober5000> whether that IDE is MSVC or something else is a secondary point, AFAICT
[22:11] <karajorma> It helps if you have it though
[22:12] <Goober5000> however, we DO have an IDE for wxWidgets -- and that is DialogBlocks
[22:12] <Goober5000> I haven't gotten around to digging deeply into it, but I've fooled around with it some, and it seems like it'll suit our purposes
[22:12] <Goober5000> in fact Taylor went ahead and did a lot of dialog construction in it before the wxFRED effort died down
[22:13] <Goober5000> and the reviews online seem very favorable
[22:13] <The_E> And seeing as Dialogblocks is not free, I dislike it already
[22:13] <Goober5000> well here's the thing
[22:13] <Goober5000> I told karajorma that if people are willing to work on wxFRED, I might be persuaded to get DialogBlocks licenses for everyone
[22:14] <Goober5000> so for purposes of comparison, let's assume that DialogBlocks costs $0
[22:15] <The_E> If it is/can be made that way, then there's no reason to choose QT. Right now, the only thing that recommends QT over wx for me is the freeness of QT IDEs
[22:16] <IssMneur> I have not found it terribly necessary with wxWidgets to have a gui to layout the dialogs, as long as you know what the layout you want before hand, the sizers make it quite straight forward. (this applies to QT as well apparently as it supports the same concept)
[22:18] <The_E> Oh, but guis are much nicer with a gui to design them.
[22:18] <Zacam> I'd contribute to a wxFRED pool to obtain DialogBlocks. In fact, I think we should have a code resource pool to be able to get people licensing for compiler apps like MSVC as well.
[22:18] <Goober5000> that sounds like an awesome idea
[22:19] <Goober5000> although MSVC licenses are a lot more expensive
[22:19] <Zacam> And if managed decently enough, it can also be used to assist when coders have hardware that has gone bad, like a HDD, processor or RAM. Or at the least, to cover shipping in the event that someone has a spare they will donate.
[22:19] <karajorma> The problem with that is when we'd give someone new a license
[22:20] <karajorma> We wouldn't want people turning up and not able to contribute cause they didn't have dialogblocks
[22:20] <karajorma> but we wouldn't want people turning up, getting a copy and then buggering off either
[22:20] <Goober5000> very true
[22:21] <Zacam> New people would have to have a need outside of the express edition reason for aqcuiring the license and have a proven track record in spite of that limitation, though it would be predominately for assisting existing members in an upgrade path from older versions.
[22:21] =-= cerberus_AFK is now known as cerberus
[22:21] <karajorma> And we do tend to have a very high "I want to join the project" followed by buggering off 10 minutes later factor
[22:21] <Goober5000> heh
[22:21] <Zacam> As for DialogBlocks, that would be handled differently I suppose.
[22:21] <Goober5000> keep in mind, there's a lot more to wxfred than gui design
[22:21] <karajorma> Yeah
[22:22] <Zacam> Indeed.
[22:22] <Goober5000> as a matter of fact, I wouldn't be surprised if it only took a couple of days' work to recreate all the dialogs
[22:22] <karajorma> And this is actually an important thing
[22:22] <IssMneur> yep, which I why I don't think it is that nessicary
[22:22] <Goober5000> and then all that would be needed is filling in the guts
[22:22] <Zacam> And a GUI designer isn't, as IssMneur pointed out, strictly neressary for people to fiddle and supply those with the IDE to compile.
[22:22] <Goober5000> exactly
[22:23] <karajorma> One of the slowest things about adding new features is coming up with the way to represent the GUI data and then translating it into the data the game understands
[22:23] <karajorma> It's one reason I like having a universal undo
[22:23] <karajorma> The only problem is that requires a complete rewrite
[22:25] <karajorma> Whenever I've decided to sit down and finally write the cutscene editor dialog it's always been that which made me get up 5 minutes later again. :p
[22:25] <cerberus> a comment if I may about the what karajorma said. you might want to consider organising with newcomers. and a proper wiki would greatly help getting the hang of thing in a quick pace
[22:26] <Goober5000> well here's the other thing, even though we would have DialogBlocks, it's not actually required for adding new dialog elements
[22:26] <Goober5000> as someone mentioned, you can use sizers, which are similar to Java swing elements
[22:26] <Goober5000> GridLayout, BorderLayout, etc.
[22:26] <Zacam> Expansions ideas: For the event editor, an ability to comment the various entries (optional) so that in multi-user projects, members can be aware of why someone set something up the way that they did. As well, per object, when selecting a ship be able to see the listing ofevents/messages/ orders/etc that are related to or involve it.
[22:27] <karajorma> Comments for Events have been something I've wanted to add for ages
[22:27] <Goober5000> me too
[22:27] <karajorma> to be honest, it's not that hard
[22:27] <karajorma> We'd just have to add a comment section to the editor
[22:28] <karajorma> and to the mission file
[22:28] <karajorma> and copy from one to the other
[22:28] <Zacam> And in a selection list, that allows you to filter ships only referenced by specified events.
[22:28] <Zacam> (those ideas brought to you courtesy of BluePlanet members)
[22:29] <Goober5000> there are two things I would want to see in any overhaul of fred (whether a rewrite or a redesign)
[22:29] <Goober5000> 1) a proper Undo system
[22:29] <Zacam> I'm still working on (at some point) getting Fred to output Debug to it's own independant log file as well as use it's own filter.cfg file.
[22:29] <Goober5000> 2) a proper comment system
[22:29] <karajorma> To be honest I'm kinda surprised that Goober and myself haven't broken down and added comments already
[22:29] <karajorma> :D
[22:30] <Goober5000> speak for yourself, I *tried* to add comments, and you know how that worked out :p
[22:30] <Zacam> Too many other things keep adding up and getting in the way. :-)
[22:30] <karajorma> I'm not talking about comments the retarded way they are in the mission file now
[22:30] <karajorma> I mean simply adding a $Comment: section to events
[22:31] <karajorma> Each event would write out an additional line if there was a comment
[22:31] <karajorma> Comments would be visible in FRED
[22:31] <Goober5000> mmm, ok
[22:32] <Goober5000> and here I was trying to make a system that would work everywhere, not just for events :p
[22:32] <Goober5000> but you're right, that would be a quick-and-dirty solution that would actually work
[22:32] <karajorma> Events Editor is what really, really needs it
[22:32] <FUBAR-BDHR> just make sure the comments don't count toward the size limit of the event
[22:32] <Zacam> Again. "$Comment:" seems just fine.
[22:33] <Zacam> What FUBAR said. That would suck.
[22:33] <karajorma> The size limit is on the formula
[22:33] <Zacam> Sweet.
[22:33] <karajorma> and only on that IIRC
[22:33] <karajorma> BTW, we should make the formula editor generic
[22:33] <karajorma> So we can plug it in where ever we want
[22:34] <karajorma> Again, I'm thinking of the cutscene editor again
[22:34] <karajorma> I have to write out a whole GUI for making the SEXPs that control it
[22:35] <karajorma> when really I should be able to simply say start an instance of SEXP-Formula or something
[22:36] <Zacam> And is it me, or does FRED not really do event's listings properl? The biggest issue I hav always had with FRED is never being able to find the items to use for an event the way I know an event can be built. So, I do it in notepad instead.
[22:36] <karajorma> What do you mean Zacam?
[22:38] <Zacam> I mean that when you start out making events, the initial availble selection (non-greyed out values) force a step through process that doesn't seem very well laid out or intuitive if you already know (or want to recreate in FRED) an event as you know it will work.
[22:39] <Goober5000> do you mean you begin making events before you have any ships available?
[22:39] <karajorma> You mean SEXPs being grayed out that should be available?
[22:39] <Zacam> Ex: When testing if "allow-warp" and "never-warp" actually work, I just said screw it and did it in notepad.
[22:39] <karajorma> Cause that was a bug I fixed a little while ago
[22:40] <Zacam> The only ship there that was necessary was Alpha 1.
[22:40] <karajorma> The game was checking if there was a ship in the mission and forgetting that PLAYER_START counts as a ship
[22:40] <Zacam> When did that get fixed?
[22:40] <karajorma> 3.6.11 should fix that issue
[22:40] <Zacam> I was using 3.6.11
[22:40] <karajorma> Hmmmm
[22:41] <Zacam> FSU Mantis 235 examples the test data that I used.
[22:41] <karajorma> This is sounding more like a bug than a major design issue
[22:41] <Zacam> I did try to create the mission in FRED first, but when it came to the events, it wasn't possible.
[22:41] <karajorma> I'll look at it a little later if you want
[22:42] <Zacam> k. In short, the whole events system is fairly cumbersome to build with, hence I guess the biggest complaint and part of the system folks want to see over hauled.
[22:43] <QuantumDelta> Please, it's the biggest thing that keeps me away from fredding :P SEXP/Events = not that intuitive
[22:43] <karajorma> I've never found using mouse selections to choose sexps annoying
[22:43] <karajorma> but an autocomplete when typing would be nice
[22:43] <Zacam> You are also FAR more intuitively tied in and experienced with FRED, kara. On many levels.
[22:44] <FUBAR-BDHR> I don't mind it either but I would like some kind of alternative like the ability to pop up a text version and edit that is loaded into the event editor and saved on close
[22:44] <karajorma> That is true. I suppose when I started we didn't have quite as many SEXPs
[22:44] <Goober5000> quite
[22:44] <FUBAR-BDHR> Be great for things like when-argument lists
[22:44] <Goober5000> we've doubled the number, at least
[22:44] <karajorma> It's a lot more intimidating for a newbie now
[22:45] <karajorma> I like the idea of a text editor too
[22:45] <karajorma> but we'd need to completely change the way Events are handled now
[22:45] <karajorma> cause at the moment they only update when you close the dialog
[22:45] <karajorma> Which is very useful if you cock up
[22:46] <Zacam> Mmmm. Have a input box and a check button to check the freeforms syntax and then a save/commit button which will also check syntax prior to saving it in the mission file.
[22:46] <FUBAR-BDHR> but very bad if you forget to exit and do a couple of big events and then crash
[22:46] <karajorma> but would prevent you quickly swapping between text editor and gui version
[22:46] -->| The_E1 ([email protected]) has joined #scp
[22:46] <karajorma> Agreed
[22:47] <karajorma> Another reason an undo is needed
[22:47] |<-- The_E has left irc.esper.net (Ping timeout: 180 seconds)
[22:47] =-= The_E1 is now known as The_E
[22:48] -->| portej05 ([email protected]) has joined #scp
[22:48] <Goober5000> indeed
[22:48] <Goober5000> o there you are
[22:48] <portej05> Just seen the message on the forums
[22:49] <karajorma> We've just been kicking ideas around for the most part
[22:49] <portej05> What type of ideas?
[22:49] =-= Mode #scp +o portej05 by ChanServ
[22:50] <karajorma> How to improve the events editor for instance by having a text edit mode
[22:50] <karajorma> adding auto-complete to both GUI and text edit modes
[22:50] <QuantumDelta> I have an idea for making it more intuitive but I'm having a really hard time formulating it into words
[22:51] <QuantumDelta> or at least easier to learn
[22:51] <karajorma> To be honest, I think we should concentrate on the GUI mode first, the changes might make text editing unnecessary
[22:51] <QuantumDelta> sort of advanced tooltipping, letting people see what prior conditions on the sexp is required to get to the one you need later?
[22:51] <portej05> I'd like to put documentation and management forward as two items to consider
[22:51] <QuantumDelta> some of them ARE obvious
[22:51] <portej05> kara: I really think we should separate the GUI and implementation thoroughly
[22:52] <portej05> Doing GUI first doesn't encourage that
[22:52] <Zacam> QD: To some extent, it will tell you, but only AFTER you have made a selection. A pre-selection list box that gives you that would be nicer.
[22:52] * QuantumDelta goes back to being quiet anyways :P
[22:52] <karajorma> I'm referring to having a text editor built into the events editor
[22:53] <portej05> QD: I think I follow
[22:53] <portej05> kara: ah, I see
[22:53] <karajorma> I think we should simply build a GUI that doesn't require one
[22:53] <karajorma> :)
[22:53] <portej05> yeah, but there's always going to be someone who wants to do something we hadn't planned on
[22:53] <karajorma> Yeah
[22:53] <Goober5000> I think we should not focus too much on future expansion ideas :)
[22:53] <karajorma> So we build with adding one in mind
[22:54] <Goober5000> yes
[22:54] <portej05> Goober: It focusses people on the idea of modularity and extensibility
[22:54] <karajorma> but concentrate on the GUI side first
[22:54] <karajorma> One thing I do think we desperately need
[22:54] <karajorma> for argument SEXPs we need to be able to autogenerate lists
[22:55] <portej05> What type of lists do you mean?
[22:55] <karajorma> i.e ships, weapons, turrets etc
[22:55] <portej05> ah, I see
[22:55] <portej05> Well, that's where having meta data about the sexp system will be important
[22:55] <karajorma> I know FUBAR will agree that FREDders spend too long cutting and pasting Beta into the argument list and then adding 1, 2, 3 & 4 afterwards by hand
[22:56] <Goober5000> oof, this is very true
[22:56] <karajorma> I don't think meta-data is the issue
[22:56] <Goober5000> I switch to notepad when copying sexps
[22:56] <FUBAR-BDHR> Yea try it with 99 waves of 6 ships and 6 wings
[22:56] <karajorma> so much as a need to be able to pick a list of predetermined options
[22:56] <karajorma> The argument SEXPs really show this problem
[22:56] <portej05> This doesn't sound like something that can be done through the current engine functions
[22:57] <karajorma> but it's been present since FRED started
[22:57] <karajorma> It can be done now, it's just probably not worth it
[22:57] <karajorma> but it's something we need to design a new system for
[22:58] <karajorma> Being able to multi-select from drop-down lists would help
[22:58] <karajorma> If I'm making an is-destroyed SEXP list
[22:58] <karajorma> I shouldn't have to type or select Alpha 1 through 4 manually
[22:58] <portej05> OK, I getcha
[22:58] <karajorma> I should simply be able to multiselect all 4 from the list
[22:59] <karajorma> and have all 4 appear
[22:59] <portej05> That seems like something a good tooltip/autocomplete system should be able to help with
[23:00] <karajorma> It could help, but this is something seperate
[23:00] <FUBAR-BDHR> or an expansion of the <any whatever> system for things like <every fighter>
[23:00] <portej05> Not as separate as you think :P
[23:01] <karajorma> Autocomplete fills in the current sexp node. This needs to say "I'll need 4 more nodes for this"
[23:01] <portej05> If you've got a sexp, which requires an argument, and you know the argument type, just look up the list of things it could possibly be
[23:01] <karajorma> Nope
[23:01] <karajorma> This needs to do more than that
[23:01] <karajorma> because for arguments there is no argument type
[23:01] <karajorma> the type is String
[23:01] <portej05> Example Sexp?
[23:02] <portej05> is-destroyed?
[23:02] <karajorma> when-argument
[23:02] <karajorma> is-destroyed was an easy example
[23:02] <karajorma> when-argument is the harder one
[23:02] <portej05> OPF_FLEXIBLE_ARGUMENT.
[23:02] <karajorma> You need to be able to let the FREDder say "Generate a list of ship"
[23:02] <portej05> Bugger.
[23:03] <karajorma> or "Turrets on ship x"
[23:03] <portej05> yep, I getcha
[23:03] <karajorma> If you can do that it makes FREDding much easier
[23:03] <karajorma> but it's not an easy thing to do
[23:03] <Goober5000> I think this is a tangent :p
[23:04] <karajorma> :)
[23:04] <karajorma> True
[23:04] <FUBAR-BDHR> http://fubar5.fubar.org/tbp/multi/data/missions/Vidmaster_MG03.fs2
[23:04] <karajorma> but it's something very much worth having
[23:04] <FUBAR-BDHR> you want to see a when-argument list nightmare
[23:04] <Goober5000> very true, but it doesn't need to be done to have a redone fred
[23:04] <karajorma> True
[23:05] <karajorma> What do we need then?
[23:05] <portej05> What sort of documentation/design documents are we aiming to produce for this thing?
[23:05] <Goober5000> well here's what I think we should nail down
[23:05] <Goober5000> 1) what toolkit to use (most likely wxWidgets)
[23:05] <Zacam> Monetary Pool if/when necessary to provide the DialogBlocks licenses. Which would only be strictly necessary for those who need a GUI to do the GUI creation, which is not technically necessary to supply the dialogue data, just the apperance. (This was another thing previously covered, to bring portej up to speed)
[23:05] <Goober5000> 2) ground-level design considerations (an undo system, a proper comment system, etc.)
[23:06] <portej05> 1) <- must come after design.
[23:06] <Zacam> How? HOW you design is goin to be based on what TOOLS you are using to do said design.
[23:06] <Goober5000> 3) a general strategy for how to proceed
[23:06] <portej05> Zacam: Pick the tools that best fit the design.
[23:07] <Zacam> Which you won't know, because your tools will inflruence your design ability.
[23:08] <karajorma> Given that the argument is QT vs wxWidgets I think we should be able to make any design in either
[23:08] <Zacam> End results can be accopmlished regardlees of the tools, the only mitigating factor is how much those tools will either help or hinder that process.
[23:08] <portej05> We also need to discuss distribution, updating, etc - these are easier to do at the start
[23:09] <karajorma> Well that's where the new launcher comes in
[23:09] <Zacam> launcher/installer/updater.
[23:09] <portej05> ok
[23:09] <portej05> So we need to have a think about that pretty soon then
[23:10] <karajorma> Agreed
[23:11] <Goober5000> what, do people want to rewrite the launcher from scratch?
[23:11] <Goober5000> because I'm still working on the rewrite of the current launcher
[23:11] <portej05> It's too risky given how much the current launcher is supposed to support
[23:11] <Goober5000> also, I don't want to combine the functions of the launcher and installer
[23:12] <karajorma> We want a cross-platform launcher/installer/updater
[23:12] <portej05> Goober: Why not?
[23:12] <Goober5000> separation of concerns
[23:12] <karajorma> I agree, why not
[23:12] <Goober5000> it's more organized to have one tool for launching and one for installing/updating
[23:12] <karajorma> The launcher and installer would be better if combined I tend to feel
[23:12] <portej05> But that goes against the whole idea of keeping the distribution simple.
[23:12] <FUBAR-BDHR> It's better to know if there are updates for what you are trying to run before you run it
[23:12] <portej05> Now you need them to download two separate tools?
[23:13] <karajorma> Exactly FUBAR
[23:13] <Goober5000> the launcher is downloaded as part of the installer
[23:13] <FUBAR-BDHR> This is very true for multi player where running with old versions can spread them like a virus
[23:13] <Goober5000> you know, in the installer section where you choose the FSO builds
[23:13] <karajorma> you've basically hit the major problem with our current set up
[23:13] <The_E> Let me just add my voice to the combined approach choir
[23:13] <karajorma> We spend massive amounts of support time on people running old versions of things
[23:14] <portej05> That's the other thing, where do we draw the line there?
[23:14] <karajorma> combine launcher and updater and you've instantly warned people of problems
[23:14] <portej05> I can understand the attraction of running previous builds (especailly after the last few weeks)
[23:14] <FUBAR-BDHR> We still have people crashing every standalone server because they are using pre 3.6.10 RC2 builds
[23:14] <karajorma> "You are not running the latest version of Mod X, you may experience issues due to this"
[23:15] <karajorma> Not mention upgrading/informing people of official releases
[23:16] <karajorma> In addition, done correctly you could have the installer recommend other TCs
[23:17] <karajorma> Which would be great once Diaspora, Starfox and the other big ones are out
[23:19] <Zacam> Just got this (sorry to break conversation here) Project : error PRJ0002 : Error result 31 returned from 'C:\Program Files\MicrosoftSDKs\Windows\v6. 0A\bin\mt.exe'.
[23:19] <karajorma> I still think we need a combined solution
[23:19] <portej05> Zacam: Welcome to my very late night last night
[23:19] <Zacam> Compiling Freespace2 with the latest trunk.
[23:19] <portej05> You've just hit a manifest problem.
[23:19] <portej05> Try rebuilding.
[23:19] <Zacam> ....
[23:20] <portej05> That application writes the manifests which go into the application specifying the CRT to use.
[23:20] <karajorma> OK, back on topic
[23:20] <Zacam> This was a build type not previously built.
[23:20] <karajorma> Launcher
[23:20] <karajorma> Anyone against a combined solution still?
[23:21] <Goober5000> lemme ask this
[23:21] <Goober5000> if we did combine the launcher and the installer/updater, how would we organize it?
[23:21] <Goober5000> the launcher already has a lot of tabs
[23:21] <portej05> Get rid of the tabs somehow?
[23:21] <Zacam> ....
[23:21] <Zacam> Hah. Yer funny.
[23:21] <Goober5000> and I like the wizard-style installation interface, where you click next->next->next with your choices
[23:21] <Zacam> Integrate the functions of the existing tabs.
[23:22] <karajorma> That's still doable
[23:22] <FUBAR-BDHR> Isn't there already an updated button on the launcher?
[23:22] <Zacam> Primary Welcome tab can be used to check the Exec and Launcher/Installer versions.
[23:22] <karajorma> The current launcher has so many tabs cause of the small size
[23:22] <Zacam> Mod tab can use to check currently selected mod or an aption to check all.
[23:22] <karajorma> Yep
[23:23] <karajorma> Plus you can have the application make a quick update check when you try to run a mod
[23:23] <karajorma> (which you can turn off of course. We are an open source project after all!)
[23:24] <Zacam> And that can be in the Features tab.
[23:24] <Zacam> Right above "Easy Setup"
[23:24] <Goober5000> I'm skeptical
[23:24] <Goober5000> I'd like to see a napkin sketch
[23:24] <karajorma> Features ought to be expanded to be able to deal with all those hidden features like -spec_tube etc
[23:24] <Zacam> "Auto Check for Updates on: EXE: [ ] Mod: [ ]"
[23:24] <portej05> Well, I liked that .NET layout someone came up with recently
[23:25] <The_E> Yeah, that .net Launcher looke dpretty good
[23:25] <karajorma> Got a link Portej?
[23:25] <The_E> http://www.hard-light.net/forums/index.php?topic=65239.0
[23:27] <karajorma> Yeah, I like that. Could use some improvements but it seems pretty well done
[23:27] <Goober5000> yeah, that design looks good
[23:27] <Goober5000> we can't use .net itself though
[23:27] <portej05> True
[23:28] <portej05> Actually, why not?
[23:28] <karajorma> I know, we'd just use wxWidgets/Qt.
[23:28] <karajorma> Dependancies
[23:28] <karajorma> I'm not introducing another one
[23:28] <The_E> portej05: Are the windows forms functions implemented in Mono?
[23:28] <karajorma> You weren't around when OpenAL was first used by the SCP
[23:28] <karajorma> No one who was wants to go through that again
[23:29] <portej05> So we're basing 99% of our design decisions (regarding libraries, etc) on an experience that wasn't managed well?
[23:29] <karajorma> It was managed perfectly well
[23:29] <portej05> Clearly not.
[23:29] <karajorma> You keep making a fundamental mistake
[23:29] <karajorma> you keep assuming people aren't idiots
[23:29] <karajorma> :p
[23:29] <IssMneur> The_E: http://www.mono-project.com/WinForms, it seems not offically or completely
[23:30] <karajorma> For BtRL we included OpenAL in the download renamed to RunMeFirst.exe
[23:30] <karajorma> and people still didn't run it
[23:31] <IssMneur> sounds about right, we have the same problem with people and new printers (we remind them before they leave the store even)
[23:31] <karajorma> If you're insisting on making people download the .Net framework before using the installer you've basically got a support nightmare on your hands
[23:31] <portej05> Where was the test code in the engine for it?
[23:31] <portej05> Why wasn't the DLL attempted to be loaded dynamically first?
[23:32] <Goober5000> portej05: have you seen the number of support requests we STILL get for the "webcursor not found" dialog box?
[23:32] <karajorma> Seriously, stop assuming our users are smart. They really aren't
[23:32] <karajorma> SoL are dealing with Nintendo fanbois
[23:33] <Goober5000> the engine tests for the web cursor bitmap, displays a dialog box if it's not found, and tells the user how to fix the problem
[23:33] <portej05> That doesn't mean that we should do not-smart things with the engine.
[23:33] <The_E> Yep. The smart ones are rare
[23:33] <karajorma> you really expect them to be able to handle an error message if they don't have .Net?
[23:33] <portej05> I've just spent most of last night debugging a statically linked application.
[23:33] <portej05> Turns out that the linking was the issue, so I'm a little grumpy on this topic at the moment.
[23:33] <karajorma> Using .Net when we have other alternatives isn't smart
[23:33] <karajorma> wxWidgets is smart
[23:34] <portej05> So is Qt
[23:34] <karajorma> That's why I favour it
[23:34] <karajorma> Qt still requires a framework
[23:34] <karajorma> which means we'd have to include it with the installer
[23:34] <portej05> wxWidgets requires bending over backwards and a financial commitment from HLP
[23:34] <karajorma> and support it when it becomes older
[23:35] <portej05> You not heard of the merge-module concept under windows?
[23:35] <portej05> Open up c:\windows\winsxs and have a look inside.
[23:35] <Goober5000> a financial commitment is doable
[23:35] <karajorma> No I haven't. Nor do I much care.
[23:35] <Goober5000> bending over backwards takes effort, but saves frustration in the long run
[23:35] <portej05> Well, you shuld
[23:35] <portej05> It's a majormajor component of distribution issues with modern software under windows.
[23:35] <Goober5000> and don't forget Murphy's Law (the original version)
[23:35] <Goober5000> "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it."
[23:36] <karajorma> Yep
[23:36] <portej05> Guys, I gotta finish this lab, I'll have to be back later.
[23:36] |<-- portej05 has left irc.esper.net (Quit: http://www.mibbit.com ajax IRC Client)
[23:36] <Goober5000> I guess he retreated :p
[23:36] <karajorma> I'm simply not interested in spending large amounts of time supporting a issue we never should have had to deal with in the first place
[23:36] <Goober5000> me neither
[23:37] <karajorma> wxWidgets avoids pretty much all of those issues and we've already said we can solve the financial issues
[23:37] <FUBAR-BDHR> I'll 3rd that
[23:37] <FUBAR-BDHR> Although I'm sure it would run up E's post count
[23:37] <karajorma> :D
[23:37] <The_E> ...
[23:37] <karajorma> He's be ahead of me by the end of the year
[23:37] <The_E> Joy
[23:39] <karajorma> So any objection to a combined launcher still?
[23:39] <IssMneur> well, just to be contrary, MergeModules seems to be an installer format for windows so that all dependencies can be included into one installer, but I admit it still doesn't look as simple as just distributing a single binary
[23:39] <karajorma> And what happens on Linux?
[23:39] <IssMneur> no, I think a combinded launcher would be a good thing
[23:39] <karajorma> Or MacOS X?
[23:39] <IssMneur> I know, thats why I still think a single exe is the better route
[23:40] <karajorma> That's kinda the issue I had with Portej suggesting it
[23:40] <karajorma> Although I didn't get time to explain it
[23:40] <IssMneur> MergeModules is not a cross platform solution to the problem
[23:41] <Goober5000> I'm okay with the combined launcher if 1) it can be done intelligently, and not turn into a behemoth of features; 2) someone else manages it :p
[23:41] <karajorma> Yep, and quite frankly I'd prefer a solution that brough us more Linux and Mac coders
[23:42] <karajorma> We've had a few say they aren't interested because we are too Windows centric
[23:42] <IssMneur> well, kkmic and I have some ideas for how to do that, Goober
[23:42] <karajorma> I tend to think we should get FRED designed but actually get the launcher working before we even start work on FRED
[23:43] <karajorma> A good launcher benefits everyone immediately
[23:43] <karajorma> and it frees up about as much dev time as FRED would since we should have less support issues to deal with
[23:44] <Goober5000> that was my original plan a few months ago
[23:45] <Goober5000> do the standalone in wxWidgets, then do the launcher in wxWidgets, then finally wxFRED
[23:45] <karajorma> ep
[23:45] <karajorma> yep
[23:45] <Goober5000> and it provides incrementally more experience
[23:45] <karajorma> if we integrate the installer it would solve a bunch of problems.
[23:45] <karajorma> One question about the launcher
[23:46] <karajorma> Do we want to keep it tied it to the game folder?
[23:46] <karajorma> It strikes me as a better idea in some ways to have the launcher able to install whereever and simply save the config files in the game folder
[23:47] <karajorma> that way 1 launcher services all the TCs
[23:47] <IssMneur> I think it should because that it makes it much easier to have parallel installs of freespace
[23:47] <The_E> I would like having a Launcher that works for anything based on FSO, BUT: that would make it necessary for every TC to provide an autoupdate config
[23:47] <IssMneur> though that is a good point kara
[23:47] <Goober5000> well waitaminnit
[23:48] <Goober5000> Tolwyn had some suggestions awhile ago about the launcher
[23:48] <karajorma> Every TC would need to have an autoupdate whether the launcher is in the same folder or not
[23:48] <Goober5000> most notably, if a TC came with the launcher it would be nice to provide its own banner image
[23:48] <The_E> There is also the issue that an approach like that may not work on Vista
[23:48] <karajorma> Yep. I'd definitely want that
[23:48] <karajorma> Oh?
[23:49] <Goober5000> and different mods may have different settings, so keeping one launcher per TC folder would keep them distinct
[23:49] <karajorma> Vista doesn't like code from one location executing programs from another?
[23:49] <The_E> Consider: On Vista, any program is prohibited from accessing any folder in C:\Program Files\ that is not its own
[23:49] <FUBAR-BDHR> Yea we are already haveing some issues with TBP and Vista not letting FS2 create directories because it is installed in program files
[23:50] <IssMneur> also, you have to be an admin to write to the program files folder , even your own folder
[23:50] <karajorma> One launcher Goober, but the config (i.e which excutable it uses etc) is kept in the config file in the game's own folder
[23:50] <karajorma> That way you can have Diaspora insist on having 3.6.11 or higher while FS2 still runs on 3.6.10
[23:50] <Goober5000> even so, TCs are going to want to create their own self-contained installations
[23:51] <Goober5000> supposing the user installed FS2 before he installed Diaspora -- is he now supposed to load up the launcher in the FS2 folder whenever he runs diaspora?
[23:51] <FUBAR-BDHR> Well even FS2 is a self contained installation
[23:51] <karajorma> Ah
[23:51] <Goober5000> and supposing a user installs TBP, WCS, and Diaspora, but not FS2 -- where does he install the launcher then?
[23:51] <karajorma> That's my point
[23:52] <Zacam> Can a MOD flag value be set to ignore Retail VPs on load for TC's to reside their data in mod folders so that multiple TC folders with launchers and exes are not necessary?
[23:52] <karajorma> A combined launcher/installer becomes the installer for all the TCs
[23:52] <karajorma> i.e if you install WCS
[23:52] <IssMneur> ya, you install the launcher/installer then it manages all of the TCs and mods like how Steam works
[23:52] <karajorma> Yep
[23:53] <FUBAR-BDHR> what we would need is some kind of central database that is kept up to date with where to download from
[23:53] <karajorma> Yep, all that database needs is links to the files the other TCs use for their updates
[23:53] <IssMneur> don't we have that already on the main hard-light page?
[23:53] <FUBAR-BDHR> it's not like we are going to have one download source for everything
[23:53] <karajorma> which is how the current installer works anyway
[23:54] <karajorma> All the installer needs to know is where the mods live
[23:55] <FUBAR-BDHR> but it will also need crcs or something to compare against to see if you have the latest version
[23:55] <karajorma> The installer would install itself to an FSO folder and then install WCS, TBP, Diaspora etc to other folders
[23:55] <IssMneur> one thing with the launcher/installer is the launcher/installer should be able to handle someone manually installing a mod
[23:55] <karajorma> I can't see that being much more of an issue with my suggestion
[23:56] <IssMneur> ya, it shouldn't but it should still be something that is considered in the design
[23:56] <karajorma> The nice thing about this suggestion is that every TC becomes an advert for all the others
[23:57] <karajorma> And for FS2 itself
[23:58] <Goober5000> k
[23:58] <karajorma> I agree with the idea of having the launcher brand itself with the splashscreen of the currently selected TC/Mod though
[23:58] <Goober5000> well, it sounds like you have an idea of how this is going to work, so maybe you should take it and run with it :)
[23:59] <karajorma> I'll write up a forum post with a mockup of how it might look. Feel free to change my design though
[23:59] <karajorma> I'm just gonna make a quick mock up
[00:00] <Goober5000> k
[00:02] <karajorma> We done on the launcher for now?
[00:02] <Goober5000> think so
[00:02] <Goober5000> are we done on fred too?
[00:02] <karajorma> I think the big requirements were undo/comments
[00:03] <FUBAR-BDHR> you mentioned the standalone interface first?
[00:03] <karajorma> Spicious should have ported it already
[00:03] <FUBAR-BDHR> Yea I think I had a beta up awhile back.
[00:03] <karajorma> We should get that code and set up wxWidgets so we can all start using that as the default
[00:05] <karajorma> Having the standalone already ported to wxWidgets was one of the main reasons I thought the choice had already been made. :)
[00:05] <FUBAR-BDHR> I'd actually like to see that expanded a bit too at some point. Nothing major just a few things to make it easier to manage.[23:36] <Goober5000> I guess he retreated :p
[23:41] <karajorma> Yep, and quite frankly I'd prefer a solution that brough us more Linux and Mac coders
[23:42] <karajorma> We've had a few say they aren't interested because we are too Windows centric
[22:22] <Goober5000> as a matter of fact, I wouldn't be surprised if it only took a couple of days' work to recreate all the dialogs
[22:09] <Goober5000> the documentation online has been quite thorough and helpful, unlike other GUI toolkitsawww, comeon, it's not that bad :P
[22:09] * Goober5000 glares at MFC
I've tried FREDding some ideas once or twice, but the learning curve is far too steep to make it an easy 'sit down and see what happens' interest.
Precisely. In fact, when I started to use FRED, I found it so intuitive that I just started making missions. And that was on FRED1, where I didn't have the benefit of the FRED2 tutorial. :DIt's one of the better mission editors originally written around those times, but compared to many of the editors I use at work, FRED is awful.
FRED is actually now *incredibly* obtuse to a new user:There's very little that's 'obvious' to someone who's never used the editor before.
- How do you choose a Mod?
- Which Mod am I using?
- When does what I'm doing get stored?
- How do I move the camera?
Anyway - the 'Must Have' features aren't possible on the current FRED architecture, so the discussion now turns to a new architecture, and in my opinion, a new UI.
I would definitely agree with a combined Launcher/Installer-Updater, as that immediately minimises support.
However, I would suggest that it *doesn't* expect to deal with all TCs, but instead the same executable should be 'skinnable' to meet the needs of each TC.
- So a TC distributes the same Launcher app, but with a different skin and config file suited to their particular needs.
While I agree that all of those are nice, I don't think they're significantly going to change the learning curve to be honest. If you want to learn to FRED you're going to need to learn to use SEXPs in order to get anywhere. And doing the walkthrough is about the only way you can teach that.Of course you're going to need to learn SEXPs, but when you first open the software it's not at all obvious where to look to find the 'how to make it work'.
Sure we can make it easier to play but I consider FRED to be closer to an IDE than a word processor and no one would sit down in front of MSVC and expect to learn C++ by simply playing with the settings.
What we could do is simply have FRED pop up a dialog the first time it runs which gives a "Welcome to FRED newbie. Want to do the walkthrough cause you really should?" message.'Tis a thought, to be true.
To be honest I'd rather have it as an item under the Help menu - "Help" >"Tutorial"There is a "FRED Help" option under the Help menu that opens the FRED help pages, including the tutorial, in a separate browser window. It might be nice to have a specific link to the tutorial, though.
After someone's played for a bit, they'll usually look under Help. And if they don't, well...
I agree with making the links in FRED's help menu more obvious. I still think a popup on first execution linking to it is a good idea though.