|
|
| Author |
Thread Statistics | Show CCP posts - 5 post(s) |
NegatedVoid
Dreddit
Test Alliance Please Ignore
0
   |
Posted - 2012.04.24 21:44:00 -
[1] - Quote
I've made a Wine bug report as I start looking into this.
http://bugs.winehq.org/show_bug.cgi?id=30515
Please post any relevant details, but don't just chatter / 'me too' / spam, etc. |
NegatedVoid
Dreddit
Test Alliance Please Ignore
0
|
Posted - 2012.04.24 21:50:00 -
[2] - Quote
kakmonstret wrote:One guy in the Linux ingame channel reports that it dosen't crasch with folowing:
Suri Abrams > Two GTX 570s in SLI with 295.4 drivers and the most recent wine you can get on Arch.
Not sure what if anything what it means seems alot of you got the same driver version.
See if you can have him run wine --version?
Also, ask him if he has overrides in winecfg for msvcr80, msvcr90, and/or msvcr100 and what they're set to. |
NegatedVoid
Dreddit
Test Alliance Please Ignore
0
|
Posted - 2012.04.24 23:58:00 -
[3] - Quote
Maquis196 wrote:
Also, there's nothing wrong with dozens of people confirming bug with winehq as well, or at least until somewhere there actually confirms the bug, enough activity on the bug report by a lot of people might see movement. The problem does appear to be UI related and I think there was work there for Inferno.
We know it's not a windows issue, so either wine or eve is broken, hopefully it's a quick fix, I live up north and avoiding T3s is hard!
Cheers,
Maq
Please don't spam the winehq people. Work on Wine is done on a volunteer basis - a bunch of people complaining just will irritate someone, not motivate them to be helpful. I'm a Wine developer (on unrelated parts).
But do post any additional logs, different systems/architectures/versions of whatever. That is useful information! |
NegatedVoid
Dreddit
Test Alliance Please Ignore
0
|
Posted - 2012.04.25 01:01:00 -
[4] - Quote
Okay, here it is, hilarious workaround time. This renders t3s invisible. And probably does evil stuff to your game.
Also, totally send me isk.
You'll need to locate your eve cache folder and adjust this from my settings.
Open a console, and input this:
while true; do rm -r ~/.wine/drive_c/users/murph/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/ships/*; done
This will start a continual loop that is deleting the generated ships cache (only t3s are generated, i think).
Now, in a second console, go start eve your usual way. |
NegatedVoid
Dreddit
Test Alliance Please Ignore
0
|
Posted - 2012.04.25 01:16:00 -
[5] - Quote
If you do that, be warned that flying a t3 is really weird. The camera can't do a "look at" on your own ship. So you can look at other stuff, but then can't reset the camera. Not the end of the world though., |
NegatedVoid
Dreddit
Test Alliance Please Ignore
0
|
Posted - 2012.04.25 04:08:00 -
[6] - Quote
Make sure you've got the right directory for your cache. Some distros put it in other places or something.
"find ~ | grep /cache/ships" should point you in the right direction, might be slow tho. |
NegatedVoid
Dreddit
Test Alliance Please Ignore
0
|
Posted - 2012.04.25 04:31:00 -
[7] - Quote
You could try doing winetricks glsl-disable and running without glsl. |
NegatedVoid
Dreddit
Test Alliance Please Ignore
0
|
Posted - 2012.04.25 16:59:00 -
[8] - Quote
Fam Trinly wrote:
Can somebody, who understand why EVE crashes with modern ships models, tell me more details about reason why python 2.7 cannot do file operations under wine as good as under native win32 ?
Sure. When you open a file, you get a "file descriptor" that is like a pointer to it. When you're done, you're supposed to close it.
The python developers have "os.open" and "os.close" for this - they pass through to the underlying operating system's open and close calls.
If you attempt to close an invalid file descriptor (like .. one that's not open already), the C runtime (msvcrt in this case) will throw an error. However, the Python developers want to have a python exception instead so they do error checking themselves. In order to see if the the file descriptor is "open" already, they have to poke around the internal memory of MSVCRT.
Wine reimplements the Windows API's, such as MSVCRT. So when the python code goes poking inside the memory of the runtime, it's actually poking inside of the memory of the Wine version.
Unfortunately, there is a host of these runtimes (MSVCR80, MSVCR90, MSVCR100, etcetc) that have mostly similar methods with some difference (for example, the structure that holds the needed information is different on each). In Wine, they're all mostly implemented once, not for each version.
So in order to use the expected memory layout, I think that Wine would have to create separate implementations for each of these runtimes, which is a lot of work and leads to a lot of code duplication which is bad.
I'm still working on figuring out the details of how Wine is handling this, but my initial attempts at simple fixes have been unsuccessful. If you're *reallly qualified* please contact me to help, but if you're just casually qualified it might not do much good.
|
NegatedVoid
Dreddit
Test Alliance Please Ignore
6
|
Posted - 2012.04.25 23:55:00 -
[9] - Quote
Hah, thanks for the update to my terrible script.
I think that checking kernel32 for the "wine_get_unix_file_name()" function is better than using registry. But yeah it's a hack.
Better than a wine-detecting hack would be a command line argument or a settings file. Then there's no trickery - just set an option somewhere.
I've got a serious research deadline on the 3rd, but I'm willing to try my hand at reimplementing the msvcrt stuff after that. So maybe we could get a hack in for a while until I (or someone!) can get things working in Wine? |
|
|
| |
|