question about companion mod and wesps and a black screen startup

[Warduke]

So I was wondering if anyone has had any issues if they installed the companion mod then installed the latest version of wesps after?  I see the companion mod incorporates an earlier version of wesps patch so I figured it probably would not hurt it.  Anyone know any details on this or have ideas?

Also I noticed lately the game gives a black screen at startup, mind you I have not played in years and have a new PC and widescreen LCD now.  The game runs fine but I just have a black screen until i get the start / load screen.

[Acleacius]

I'm 90% sure you need to install the UP patch first, then your mod, if your updating UP you have to reinstall your mod after you update with the UP.

You best bet would be to ask in the UP thread or the Comp mod thread, which ever is more active.

[Wesp5]

I'm 90% sure you need to install the UP patch first, then your mod, if your updating UP you have to reinstall your mod after you update with the UP.

Yeah, that's the way to go, and you would probably loose some of the newer fixes of the UP.

[Malkav]

Wesp is right, the order of installing would be  first the UP, and then the mod. And while I'm not sure if the Comp mod chhanges a lot of the maps, it surely changes the probably most important file for new fixes: vamputil.py. So a lot of the new fixes from the UP will get lost.

[burgermeister01]

Yea, by principle, CompMod edits ALL of the maps 


  ... goes the UP fixes.

[Malkav]

... goes the UP fixes.

You're a bit blunt, aren't you?
Well, it's sad but true for most of the existing mods. They change the maps and the python files, so they basically are not compatible unless you want to merge them manually, and know what you are doing.

[Acleacius]

Someone was working on a way to install each major mod to a separate directory and have them read the files from the main directory that way nothing gets overwritten.

I hope it's still actively being worked on.   

[Warduke]

Hello all, well I tried installing the newest UP first and following with the compmod, unfortunately they did not seem to agree with each other.  I did a standard overwrite with compmods files and for some odd reason it still did not want to work properly.  Ahh well.. such is life.. win some and loose some.  If anyone has had better luck than me let us know.

[burgermeister01]

@Malkav: What can I say? I'm not one to forgo on a poop joke, when the opportunity presents itself 


@Acleacius:   I hate being Dennis Downer, but even the separate directories thing didn't really fix the conflicting files problem. It just basically opened up the possibility for mods to install to directories, which a user could pick upon launching the game. That way, you could have multiple mods installed simultaneously, but you still would only be able to play one at a time.

[Acleacius]

Ahh my bad, thanks for the info burgermeister01.

[burgermeister01]

Yea, if they had had time to do things better, they should have made it so that mods could be installed on top of each other, via the directories method, BUT also specify a files manifest with each mod, that would load the mod files into the various game components. So, for example, if the file that specifies all the quests was broken into multiple files, one for each quest, or if even you were allowed to append new lists of quests via a mod, everyone could add their own quests to the game, without overwriting each other. But they didn't *sigh*

[Acleacius]

burgermeister01 what would it take to do something like that, sounds like a wicked idea? Would a Frontend loader manage this, in the sense if each mod had it's own install folder structure? Possibly a Python merge tool, which actually edited the main game vampire.py to create a vampire.py inside the mod folder structure, which the mod would use?

I am not pretending any of this would be easy, I certainly couldn't do it but if we actually knew what we needed or thought we needed, we might could recruit some help.   

[burgermeister01]

Gosh, I wish this was all within the realm of possibility. Unfortunately, the way that the data files are loaded into the game is controlled by the compiled C++ code, so changing something like that is pretty well near impossible; you would need the original source code to make it happen, or be some kind of idiot-savant with assembly.

That's why -- in the bigger picture -- the revival team is really on the right track. If they make their source code public, if they don't implement some feature on release, anybody with some coding skillz can come in and make it happen in the future.

Of course, what I'd really love is for some ex Troika employee to bow out of the shadows and offer up the source, but fat chance of that ever happening...