[jg18]

I've gotten FSO (3.6.14 RC7) to work in Wine on OS X 10.6, but for some reason, FRED gets stuck (stops loading) and I have to kill the process (shut down X, to be precise). In case it helps, this is Wine 1.4.1 (latest stable build), installed using MacPorts.

Here are the registry values, according to Wine's regedit:





The 1440x878 value for resolution is 1440x900 minus 22 pixels for OS X's top menu bar.

Logs for FSO and FRED attached, along with a debug_filter.cfg file that I don't remember making but that I added +OpenGL to, which didn't seem to do anything. For the FSO log, I started the first training mission and then exited it. For both FSO and FRED, I ran them using

Code: [Select]

wine <program_name>
from within the /Applications/FreeSpace2 folder, which is where I store my FS2 data on OS X.

Thanks for any help anyone can provide.

[attachment removed and sold on the black market]

[The E]

Not exactly sure what kind of help you're looking for here. Fred is a Windows-only application. We do not and can not optimize it for running it in something that is almost but not quite  Windows.

[jg18]

I'm not asking for any changes to be made to FRED. I'm just puzzled because

• FRED is known to work (for some value of "work") in Wine
• FSO does work in my current Wine setup, so it's strange that FRED doesn't

so I'm wondering if maybe there's some setting in my Wine setup that isn't correctly set, something of that nature, that's preventing it from working, maybe a folder/file that FRED expects to be there that isn't.

[niffiwan]

well - just one example of differences between FSO & FRED is the fact that MSVC Express can compile FSO, but can't compile FRED.  I haven't had much success with FRED under Wine on Linux using the latest 1.5 beta versions.  Last time I tried, most things seemed to work, but saving missions didn't making it a big exercise in frustration     I didn't try changing much within the winecfg app, maybe some different OS values in there may help?  Alternatively, there's people on the wine forums that know the system much better than we do, e.g. when I wrote up a walkthrough for WCS:DD some guy on the wine appDB group figured out how to get the launcher working in no time - I guess it's just experience they have with knowing what sort of wine additions / tweaks / tricks are needed to get various programs running. 

[jg18]

Oh, well, in that case, it looks like

• FRED is known to work (for some value of "work") in Wine

isn't actually true.

I guess I could try this Wineskin wrapper; supposedly, that works. If not, then asking around on the Wine forums is probably my best bet, as you said.

Thanks.

EDIT: Mind you, I can always just boot into Windows and use FRED there. It's just that having to reboot and set aside whatever I was working on in OS X is annoying.

[HAZARDLEADER]

I've had a similar problem with Cross over (which runs on wine) it just gives me a bunch of error messages and then closes out.   

[jr2]

Would running a Dependency Walker analysis of FRED running on Windows be helpful?  Perhaps FRED depends on some library in Windows that isn't included by default in Wine, but could be added?

[chief1983]

We may not officially support FRED in Wine, but since FRED is only Windows, and there are quite a few *nix users in the broader community, the recommendation has been to run FRED in Wine in the past.  And that has worked fairly well for many users, so if something changed, we can hopefully investigate a bit at least.  We might even have a few devs who could take a shot at running the Wine version just to see.

[mjn.mixael]

Or reinvigorate wxFRED development...

[chief1983]

That'd be great, but it's the long-term solution, and FRED in Wine has worked before, for anyone willing to put in the effort to get Wine running.

[HAZARDLEADER]

It would still be cool, to run Fredopen so that us Mac people could be supported, if someone could get it to work on wine that would be fine. Although it would be way cooler to open fred with out wine. I have to vote for wxfred. 

[jr2]

Right, but meantime, while wxFred is still being coded, back on the Apple farm, there is Fredding to be done...

[HAZARDLEADER]

Right, but meantime, while wxFred is still being coded, back on the Apple farm, there is Fredding to be done...

Yeah, hope it gets done soon. Running fred2 on crossover is...well you can imagine what hell it puts me through... 

[FreeSpaceFreak]

Isn't there a sorta roadmap for FSO cross-platform development? I recall someone mentioning that, it went wx-multiplayer-setup-thingy -> wxLauncher -> wxFred. That's in order of increasing complexiity, which makes a lot of sense to me. So when wxLauncher has reached 1.0 and become the official FSO launcher, we might hear some more on wxFred again

[karajorma]

You might be thinking of the plan to port the standalone server to wxWidgets so that we could run standalones on Mac and Unix.

I believe some of the work for that was done but it was never submitted to trunk (it may have never even been posted in fact).

[jg18]

Would the standalone server be another potentially good project for a new coder? I don't know anything about it, including how difficult or complex it is. If the work that was done is around and usable, that'd help. Admittedly, this is drifting away from the OP a good bit...

[chief1983]

Someone has already written a conversion of the standalone to wx.  Nothing has ever happened with it because no team member ever did the rest of the work of reviewing and integrating it into trunk.  I still have the source though I think.

[FreeSpaceFreak]

You might be thinking of the plan to port the standalone server to wxWidgets so that we could run standalones on Mac and Unix.

I believe some of the work for that was done but it was never submitted to trunk (it may have never even been posted in fact).

Aye, that was it. And it was certainly posted, I even found the thread just now.

[chief1983]

All the diffs of the code have been purged, but I managed to find one on my laptop, not sure which one, and uploaded it here.  The indicated revision is 5799, which was only committed on Jan 8 2010, so this is probably the most recent version of the patch Spicious uploaded.  Maybe he would like to take another look at this though.

Edit:  I did manage to merge that cleanly into current Antipodes 8 with a couple small tweaks to the diff, you can find the patch here.  Don't know if I can compile it though.

Edit2:  I found an older version of the patch on another computer, which seems to have the files that were missing from the 5799 diff.  Not sure if they're up to date enough to work with the newer patch, but I'll see what I can do.