779 réponses à ce sujet

[Ottemis]

No offence meant to you Shot_Down_USA, but mostly installation issues have to do with wonky updating of the toolset or not properly vanilla-ing between treecans.

The toolset is still hard to work with and if you don't know exactly how it operates, which the average user obviously wouldn't and because of that you're both unnecessarily updating AND potentially not updating properly, all kinds of issues can surface that potentially have nothing to do with the specific revision you updated to.

 

Unles you can determine without a shadow of a doubt that it is a revision issue rather than an install issue, that's the first assumption because it's simply so easy to mess things up due to user 'error'. In this case even more likely when the module you're having issues with was not included in the update notes and likely saw zero changes.

[Drengin]

True.. however seen as i have been using explorer for a very long time and have never had an issue with this before the last update i am not sure what it is.

True it could be me and that's why i am vanillaing the game and throwing out the tree scan. Repaired files with new tree scan on 645 should sort out any issues, i hope.

That said i am sure you are right and that somewhere i screwed up a file.. maybe. 

 

Otte' would you suggest a repair or total re-install? total vanilla install it is to be 100% sure of no moddified files

[Ottemis]

I'd class myself as a veteran and even I have issues sometimes, most often eliminated by a fresh install, if this issue persists through a complete vanilla setup be sure to report it but again, in therms of mod compatibility and need to update, mods will not lose compatibility and the need to update only exists when tools you use are impacted. That's why the update notes exist, so people know if they are affected by changes. We haven't been for a while, since K's rewriting Texplorer and Modmaker and won't be making updates until he releases the overhaul.

[Ottemis]

True.. however seen as i have been using explorer for a very long time and have never had an issue with this before the last update i am not sure what it is.

True it could be me and that's why i am vanillaing the game and throwing out the tree scan. Repaired files with new tree scan on 645 should sort out any issues, i hope.

That said i am sure you are right and that somewhere i screwed up a file.. maybe. 

 

Otte' would you suggest a repair or total re-install?

I usually throw out all basegame files with a modified date newer than 4/25/2012 and copy in a vanilla DLC backup. Then download the deleted modified basegame files via Origin update or repair. I've noticed that repairing or updating without first deleting modified files sometimes causes issues. Obviously copying in vanilla backups instead works just as well.

 

I'd also advise to keep both a copy of your unmodified vanilla DLC folders and then make a second backup after treescan so you have them in vanilla unpacked state as well. That way to return to a vanilla state after treescan you can as you no longer have an issue with the packed state of the DLC.

[Drengin]

Ok thanks for the clarification on explorer.
Downloading a new base and dlc as we speak. Will then copy them for a backup and do so again as you suggest after fresh tree scan.

 

One more question... i have a heavily moddified Coalesced.bin. Could that be causing an issue with .mods?

[Ottemis]

No, pathing isn't taken from the coalesced so it should not impact modmaker or texplorer/tpf tools functionality.

Another thing, your tree does not need to be updated between revisions unless the treescan / texplorer were affected by an update. K will ALWAYS make it really clear in update news when you need to rescan but as it stands you can just keep re-using your old tree, or in your case the one you're making right now until that happens.

Backing up the tree + the vanilla backup of DLC in unpacked state post treescan means you have a lot easier time returning to a clean unmodded state if you run into any issues. I personanly never back up my basegame because I have retardedly fast internet and it takes longer for me to copy a backup in than it does to redownload, but that's completely personal / depends on your setup.

[Drengin]

Thank you

[Drengin]

I have to backup as for some reason i only get 2.21mb/sec from origin even though i am on a 20mb line, so a total d/l takes 45+ mins on the base game alone

[Ottemis]

Ahh yeh that's messed up, I get good speeds (average 6mb/s on a 120mbit line) on basegame but if I redownload the DLC from scratch that takes me about 45-60 minutes, speed seems throttled more with multiple downloads at the same time. I also own all DLC so that tends to ramp up heh.

[Drengin]

Ahh yeh that's messed up, I get good speeds (average 6mb/s on a 120mbit line) on basegame but if I redownload the DLC from scratch that takes me about 45-60 minutes, speed seems throttled more with multiple downloads at the same time. I also own all DLC so that tends to ramp up heh.

Yup, same here. Even purchased the stupid Genesis 2 lol.

I found it quicker to just d/l one dlc at a time or the whole thing slows to a crawl.

 

Getorex i will get back to you about the mod as soon as i have the game ready to install mods

[Getorex]

The devs of explorer should really adopt the standard open source model (unless they do it this way and I'm simply unaware).  There is a dev branch and a stable branch.  The stable branch gets even numbered version numbers while dev branches get odd.  There is always a latest stable release available that virtually EVERYONE uses unless they are a dev or just someone who wants to help with bug fixing.  People using it go the to stable branch every time.  Thus, functional modders and users may ALL be downloading stable branch 644.0.  Bug fixes might get an even decimal (644.2) and is NOT delivered via svn.  There certainly can be a "check for updates" tool in it so that if there is a new stable release (646 for instance) it finds it and asks if you want to update.  The devs may be on 645.1, 645.7, etc.  ONLY release a stable branch when it is validly considered stable.  Doing it this way means that end users are NOT having to worry about updating weekly or all that often.  Only stabilized versions of the dev ever get released for general use.  

[Ottemis]

In theory they use a similar system between the SVN and the SF, but seeing most users don't even report issues in revisions rather than sitting on them or reporting them outside the official forums, they often don't know about issues in SVN revisions until after the SF was updated. If it had a more active testing base, it could most definitely more effectively be done, but as things stands that's simply not how things work.

There are so many factors that affect any given function that you can never truly claim anything to be a stable release. Also these are students doing this in free time while they are working on their thesis projects at university, it's logical they don't have the time nor patience to wait for users that CAN properly test to report on issues between revisions. They'd rather keep development going.

 

I don't know if you know what the average 'bug report' looks like but most often it boils down to 'hey. It doesn't work'.

 

You know it's similar to mod creation, we are unable to gauge how things respond for others as some issues are system specific, without testers we might not catch issues before release and very often this workflow can't be avoided as we simply can't force people to test our mods out for us in a reliable fashion.

[Drengin]

Always have been, and always will be, more than happy to test mods. That's half the reason why i am going vanilla right now so i am sure it works without any other persons mods involved.

[Drengin]

Sorry for the delay...
 
Game in vanilla status with only your EDI mod installed.

Base install with no tweaks appears to be the best version.
As to the 'glowing' i was fniding before, my best guess is that Otte's EDI mod changes something that your mod does not overright. If it were me i would add all of the spec/diff/norm files for EDI head/scalp/EDIa-g etc so anyone installing this over Otte's mod will get the desired look.

 
Results: -
 
(screenshots taken with lighting set to -2 and Smarteck's Next-Gen Cinematic Filter.)
 
Original files installed with no additional spec tweak
Installed files : -

• EDI Head and Body Mod Full DLC-163-5
• EDI Head and Body Mod Main Game-163-5

Image



Black-Alpha test
Installed files: -

• EDI Head and Body Mod Full DLC-163-5
• EDI Head and Body Mod Main Game-163-5
• EDIa-Spec-Black-Alpha-test.mod

Image


NoAplha test
Installed files: -

• EDI Head and Body Mod Full DLC-163-5
• EDI Head and Body Mod Main Game-163-5
• EDIa-Diff-NoAlpha-Test-52414.mod

Image


NOTE:-
No light blooming/spec glow seen so far in game.

[Drengin]

Getorex - Let me know if you want more testing done as i will do that before installing all my mods/graphics.

[Getorex]

Thanks Shot_down, the first image in the series is what I got on my system originally. In the lighting I can see there's still an issue, just like with Otte's face texture in your earlier shot between the face and scalp. Not horrific but I will try and fix it up a bit later.

The main mod did not include the spec? Or are you saying there's an issue of perhaps incomplete replacement when going from Otte's textures to mine?

[Drengin]

I believe that there may be a problem going from Otte's to yours. Maybe because Otte uses files that your mod does not replace. For safety i would bundle up your modified files with the ones you did not alter too, such as the spec. For complete peace of mind maybe even add in the rest of EDI's 'head' files and body files (yup all of them) that are in a vanilla state too. For a .mod install it is still one click for the user.

 

I will try installing Otte's into the vanilla game and then installing yours over it and see if that was what caused the weird lighting issue i had previously.

[Ottemis]

For ref, my EDIa mod replaces EDIa body: mesh diff spec norm, face: diff spec, scalp: diff spec norm, eyes: diff spec, visor (HMF_HGRa_EDI_Emis)

[Drengin]

For ref, my EDIa mod replaces EDIa body: mesh diff spec norm, face: diff spec, scalp: diff spec norm, eyes: diff spec, visor (HMF_HGRa_EDI_Emis)

Thanks that should save me the install
As long as Getorex replaces all of those with his changed files and any not moddified with vanilla state files all should be good.

[Almostfaceman]

This is for Getorex (it's his thread after all) but also for any of the other artists/mesh modders currently active and having fun. I'm a big fan all your work, including CDAMJC, who pretty much made Mass Effect 1 (almost) free of the uglies. 

 

Is there any interest, plans, efforts going into Mass Effect 2? There are a sizable amount of textures already out there for the game, some problematic. Not nearly as much texture work has been done for ME2 as there has been for ME3, and now even ME1. 

 

You are all doing this in your free time and for fun, so I don't want to come across as entitled. It would be cool, though, to see ME2 brought up to speed and its uglies destroyed. 

 

Getorex, do you have any interest/plans to mesh ME2 to be consistent with your ME3 work?

 

I always do complete run throughs of all three games, ME2 is starting to stick out like a sore thumb.

 

I'm a fan of all you guys/gals, hope I'm not coming across as a Conrad Verner.   

[Getorex]

I wish I could do meshes in ME2 (and somewhat less, ME1 - I think it's fairly flawless in that regard). I'd mainly unify the meshes across them. But each game is different in core design and there's no way to mesh mod them, and no apparent intent to make it possible.

[Ottemis]

We are wanting for volunteers to port functionality, yes.
As to ME2, I would love to get around to porting all my textures if I wasn't so busy with ME3 stuff / requests / helping others.

[Almostfaceman]

I wish I could do meshes in ME2 (and somewhat less, ME1 - I think it's fairly flawless in that regard). I'd mainly unify the meshes across them. But each game is different in core design and there's no way to mesh mod them, and no apparent intent to make it possible.

 

Huh, that's too bad since I'd particularly like to see your mesh work on Tali in ME2. Being able to see her face makes her a bit more romance-able for my tastes. Plus, you know, consistency with ME3. There's a Jean-Luc texture mod that makes her face more visible, but it's not the same. 

[Almostfaceman]

We are wanting for volunteers to port functionality, yes.
As to ME2, I would love to get around to porting all my textures if I wasn't so busy with ME3 stuff / requests / helping others.

 

Yes, indeed you are a power-house within the modding community, very engaged, talented and helpful. If you get time I'd love to see what you do with ME2. 

[Almostfaceman]

I'm having an issue with the helmet texture for Liara, here's a screenie. Perhaps a tpf would correct this?