Hi all,

I'm new to wine, and I've done a lot of reading and searching for a solution to my problem. But nothing seems to work.

The game runs fine, only on startup the movies in front of the main menu don't work. And in game characters are teared up.

Example:


I've tried installing the dll files for directx and patched the game but it doesn't seem to work. I'm running it from steam and on osx 10.6.8.

I'm using wineskin and haven't downloaded anything besides that.

I'd appreciate any help,

Novante

Wineskin has its own support forum. http://wineskin.doh123.com/tiki-view_fo ... ?forumId=1

Very constructive awnser, thanks.

Although its not a Wineskin issue, they won't support you here at all. I know you posted this over on the Wineskin forum as well, but there is little I can do over there for game specific problems. If you reproduce the problem using normal Wine and XQuartz, then they'll help here. Being the Wineskin uses stock Wine its actually possible to run it command line right from Wineskin and its normal Wine usage, but you have to change around your path and stuff... I don't know why that wouldn't be supported though. I'm thinking of putting together a HOWTO on the FAQ on how to run the Wine build command line under XQuartz for testing and maybe that will be accepted here since its stock unmodified Wine already anyways.

On Sun, Mar 4, 2012 at 5:18 PM, doh123 <wineforum-user@winehq.org> wrote:

That would be a great idea. If it is just stock Wine 'under the hood'
then there should be no heartburn accepting bug reports related to
non-functioning of Wine.

However, we still would like the reports to be filtered before users
come here for assistance.

And there is a script for building Wine (I use it) produced by Ryan.
It does NOT modify Wine's code and just pulls in all of the
dependencies. Much faster than using MacPorts or Fink. I have setup
a build environment for code testing and release testing (separate but
equal stuff) and have to get back to using it during the RC runs.

James

The issue is not just Wine itself; I believe you when you say you use unmodified Wine. But wrappers such as yours also install winetricks and other tweaks that are relevant to troubleshooting a problem. It is not our responsibility to keep track of what every wrapper script out there is doing, and the people who use these things are often unaware of what they've installed. One thing you could do that the PlayOnLinux people promised long ago, but failed to deliver, is a a log that will summarize every tweak that was applied by your wrapper that users could copy and paste here.

The second thing you need to fix for users to get support here is to properly install gecko in every wrapper. A wineprefix without gecko is broken.

The wineprefix is made stock and nothing is installed unless the user went into Winetricks and installed it themselves. Nothing is automatic. I'd only accept bug reports if its someone who actually made the wrapper, not just downloaded someone else's because they might not even be using stock Wine builds. Normal Wineskin engines are stock, sure, but anyone can compile their own Wine code as well to make an engine. Wineskin is not designed to automatically get games working for you, you still do all the work yourself, there are no installation scripts or anything like that... or just download a working wrapper someone else has already made.

Gecko is easy for the user to install if they need, but installing it in every wrapper no matter what is a HUGE and utter waste of space. When a wrapper is already like 150mb, asking the user to put another 30ish mb on top of that for Gecko when 75% of the things people run never even use it is crazy. That might work for the idea of normal Wine usage where you just have Wine on the system and use it for everything, but not with how Wineskin works. Every app you run contains its own wineprefix, its own X11, its own Wine build, and all the dependencies it needs. If you have 6 or 7 ports all with Gecko installed and none of them actually using it, wasting hundreds of mb is a bit silly.

My option (I'll probably build it in to launch Terminal ready for you instead of just following a HOWTO) will not even use the wineprefix in the wrapper, it would just default to the normal ~/.wine. It would be nothing more than letting the people open Terminal with a pre-compiled Wine build ready to go and nothing more. There can be a note about making sure Gecko is installed... This would only be so people don't have to try to compile anything themselves just to test if its a Wine or Wineskin problem.

That sounds good, but you need more than just a note about gecko. It needs to be installed to ~/.wine by default.

Don't worry I haven't forgotten this
In fact everything is ready in POL / POM 4 to log everything that happen in a prefix (wine commands runed, file downloaded, contents of .reg applied)
I just need to add a few code line to enable it. I just thought you were no longer interested by this.

Consequently, this feature will be available for 4.0.16. Don't hesitate to ask for something you want in the log.

Ok, it's done. I don't know if I should post a new topic for that, but here is an example of the result. It works for all POL's recent script. User needs to have at least 4.0.16 to have access to these logfiles.

http://pastebin.com/mAUVF2BF

Will the log clearly identify cases where a patched version of Wine has been used? Because patched Wine will not be supported here.

I notice the log you posted happens to indicate gecko was not installed. What I said to doh123 applies to your users, too: a wineprefix without gecko is broken. Don't send anyone here without it.

I can only speak for myself, but I am willing to take a look at these logs, and if what I see assures me that the Wine used is unpatched and no unnecessary dlls or other tweaks applied, help the user troubleshoot the problem using the same steps I would take with any other user. But you need to make it clear to your users that those "same steps" often involve a plain, unscripted reinstall to a clean wineprefix using the latest development release.

Patched wine version is also planned

You'll see on the log file "PlayOnLinux is using a patched wine version.\nPlease DO NOT use this log on winehq website!"

I can change the message if you want to. For gecko problems, I could add a message like this.

Also, it's not written in the log, but you should know that we ALWAYS disable winemenebuilder.exe.so with

export WINEDLLOVERRIDES="winemenubuilder.exe=d"

Is it a problem for you ? If really it is, I could re-enable it for PlayOnLinux and find another way to control shortcuts menu

Rephrase the second sentence to "Do not file bugs, AppDB test reports, or ask for help on the WineHQ website for any applications or games that are run using this version." For gecko, I'd really prefer it just be installed by default, but if not, make the message similarly strong.

Not a problem; in fact, I have winemenubuilder permanently disabled in my .bashrc. But I hope you let your users know this, so they don't ask us questions about why no menu items are being created.

- Done for the rephrase
- For gecko, is there a simple way to tell wine to look for gecko packages in other places than /usr/share/wine ? If not, I will make our building server add gecko packages in each wine build

- For winemenubuilder, the user sees a message in logfile. From 4.0.16, he/she will also see a link where he can find information to re-enable it.

When Wine is run from the build directory it looks for it in ../gecko (relative to the build directory). Other than that, I don't know. Adding a package is probably best.

This would be very nice really... my Wine build is normally in a totally different location, and it still looks in the ${prefix}/share/wine location, but it would be nice to be able to have that elsewhere... but it will go off whatever your install location is that you specified as the prefix during configure.

Sorry to spam this topic, but 4.0.16 is out with everything (Gecko, logfile, warnings, ...)

Should I post something to give details about this?

Yes, go ahead and post an announcement about the new features.

Done. But the topic has been closed without any reason nor explanation. The topic seems even not to have been read. I think that all our effort are vain. I give up.
(Oh, and by the way, by doing this, I've found a bug in wine which makes it very slow when its piped with other processes.)

I opened it long enough to add a comment of my own, but I have locked it again to avoid pointless arguments. My offer still stands.

On Mon, Mar 19, 2012 at 7:31 AM, qparis <wineforum-user@winehq.org> wrote:

The topic was closed to prevent the possibility of a continuous
arguement and pointless discussion. Unfortunately, it is not possible
just to open a topic to certain people and block it to everyone else.


Please file bug reports for these...

Also, the project does value inputs on improvements from your efforts
to make programs function. Just is some of the 'hacky patches' need
clean up and that can and does take time. The overall process should
make the Wine project much better and easier to support both old and
new programs.

James