LiliArch

(And the correct term was "instance" and not "preference"... I blame my game client which was acting up, so I wasn't able to check the terminology.)

 

I'd say that the difference between PvE and RP-PvE servers is that there's RP guilds on RP-PvE servers.

They are both same. You can pick if you want to play PvE or PvP without changing the server. There's a tutorial entry about it once you get your character started.

They apparently replaced PvP and PvE servers with PvP and PvE preference and now you can play both on a same server by picking another preference. Dunno why the don't tell which are RP servers anymore, though. You can see the list there, but I don't know how up-to-date it is.

I'm on Red Eclipse, and Progenitor. Planning to try some other server too, though. There seems to be no rule against playing on multiple servers.

 

It's totally F2P-playable, as long as you don't hit a game-breaking issue that requires the help of customer service. I finished my Smuggler and Jedi Knight as F2P just fine. Sith Warrior and Imperial Agent are a bit picky, if your computer happens to be one of those unlucky ones that hit an issue where holoterminal conversation doesn't progress (I recently got a response from customer service that listed 1 mission for Sith Warrior and 4 missions for Imperial Agent where that happens). Totally computer-dependant, apparently, though, so you may get lucky. Or just avoid playing those two classes. If you spend no money for it, you can get only two characters at a time, anyway.

LiliArch, have you tried both versions? - and if you have - In your opinion, is there much difference between the Blender 2.69 and 2.7 version?

Well, I've run both versions, but I don't exactly know how to use them, so. By the time I found out I need to use a wheel mouse instead of touchpad to be able to do anything reasonable, I had already sort of hurt my mouse-arm and as such, I was unable to try to learn how to use the program. They have a different picture in the splash screen, that's all I know. I'm still only trying to learn how to do 3D.

 

It seems like every version of blender is different

That's usually the point in releasing a new version, isn't it? If it would be exactly the same, they wouldn't raise the version number...

...sorry, I feel snarky. Bad day.

Well I don’t think they see themselves as the saviors of FileFront, but they are doing what they can do to help. The reason I could see them in a panic to save the files is because there may be things going on behind the scenes we don’t know about. Are those files archived on the FileFront servers? if so, the new owners could be demanding they be dumped to make room for things they want to use them for, and FileFront staff that is left making the transition over to the new owners, went to the first people they could think of to facilitate it. Every link I have followed to a so called archive is redirected to the Escapist, so they (that magazine) seem to be doing a hostile takeover of what is left. I can see some of their execs giving the kill order to clean those servers out if that is the case. Seems typical. Of the other sites that host the same files, they are either not as well known, or not as well organized as nexus usually is. The difference between the Kotor site on nexus and how it is now is alarming. It is all in disarray, when it used to be nice and neat, although somewhat sparse. And remember this is not the only game they are doing this with. There are tons of other games that don’t have any equivalent host sites they have to get the files for or they will be gone, so they are painting with a broad brush here with all of the files.

 

Why would contacting the mod creator be the last step in this situation? Because there is a time limit, and contacting people who are MIA is time consuming and takes a lot of manpower to achieve. I think we all know from attempting to contact people that have dropped off the modding map, how frustrating that can be sometimes. So they are thinking practical, not necessarily nice to do or moral obligation. They had to make a quick decision, and I don’t think any of us in the same shoes would be approaching it differently unless we had the foresight to think a year or two ahead. But such is the realm of business. They have not been given much time to work with. Large corps usually don’t like to stretch deadlines like us modders do. They are very black and white and aggressive. They want those servers now and they are going to get what they paid for. They could care less about some old mod files. The fact they are even allowing any time at all for someone to rescue files is kind of gracious.

I'm sorry, I can't quite follow your logic there. First, if old links suddenly lead to another site, it's because the domain is taken over, not the servers - the physical servers themselves may be the same ones, but they can as well be on the other side of the planet. Second, I can't see any reason for the web host provider to not simply carefreely delete the files once the webspace ownership has been terminated; someone booking to the same space (and there's no reason why it would be exactly the same sector of the hard drive that the previous client used, not that it would matter after wiping the previous client from the system) should not matter there at all, no more than you're allowed to live in an apartment you don't rent anymore, no matter if there's new person moving in or not. If they do feel the need of archiving old files, it's done on completely different servers, and don't matter to any person that's their client, except the one who the files belong to. And in the case that FileFront staff actually owns the physical servers themselves, I doubt they would be selling them to another company. There's not much to be gained from that. Owning a server (if you own the machine itself) does not cost any more than owning any other computer, when you cut it off from web.

 

Unless you have some inside information about web host provider's way of doing business? That's just the picture I've got as a client...

Ah okay, I see what you're saying now. Well I have XP and that's about all I can use as a operating system for right now - been trying to save up and get a better computer with Win 7 or build one that I can put Win 7 on.

Well I don't know about Blender 2.8, but 2.7 runs fine on XP (after installing that C++ runtime or whatever it was, if it's not installed already). I'd suppose the new neverblender should work with it.

I mean, it wouldn't look realistic if they let you walk through a corpse that was taller than you are (not to mention how odd the camera would look...).

*cough* Telos Tank droid remains *cough*

 

sEcOnDbOuToFiNsAnItY said (and that is also my recollection but I can verify it) that the corpses do not need to be destroyed to move past them.

Of course you don't need to destroy them to move past them, but you can't walk where they are. Now, that doesn't pose a problem if there's space enough to move around them, but I once managed to block myself in a corner with that Rancor corpse, and had to destroy it to be able to move at all, as it was blocking my only way out of there. Also, that dragon corpse doesn't exactly help you in the Tatooine ambush.

If you don't destroy it, it blocks your path... isn't that a payoff?

For a bit of a look into history, Tk has been working on Linux since 1992, before it even worked on Windows (which came after the Windows 95 release). And yes, it does still work.

To be fair, that was the source of my concern about it not working anymore. It is old, and old systems tend to get replaced by newer ones at some point. Plus, I just found out that certain Win32 libraries don't work properly on my 32-bit Windows, or on my 64-bit Windows.

 

The only reason I would do it that way is to potentially avoid breaking if Windows ever starts reporting itself as MSWin64 (while still providing Win32, the perl library) or something crazy 

Makes sense to me. (Though you can tell if the program is called with arguments even without Autoglob - so it can decide if GUI needs to be fired or not - the functionality is obviously limited.)

 

yep, it is easy with your instructions. i remember learning about commenting out previously at some point but never really had to use it for anything til now. thanks for making it easy.

All part of the service. What point is in knowledge if it's not shared?

 

Okay, okay, I move to do something else.

I believe there may be support for TK windowing in linux kernel (GTK maybe?) but it for sure has to be in the correct case consistently, and that is usually the issue (besides the dotnet fiasco in many exes), not necessarily the fact that Tk is present, but that there was a case discrepency. Linux is case sensitive, while windows is case agnostic, so a script can reference something in all caps and even if the dll or the exe is in all lower case it will still work in windows, but not in linux. linux all the references have to match 100% or something will not work.

 

I also like that you suggested commenting out certain things, but i will have to look into it further to figure it all out.

 

If the code had to be retooled in the exe itself, then i dont have the things i need to do that any more (i used to)

 

just commenting out in the perl script is easy as pie.

You can throw the exe out of the window if you like. You don't need it. Just edit the .pl file and execute it.

 

It's not a difficult edit in any sense... just follow the instructions I posted. That should work after those. (I actually tried it on my Win-system after removing the Win32-dependencies and it run like a charm. Well, I would have probably missed the autoglob if I would have used it from command-line, but I wasn't.) I hope they were clear enough? I'm so stuck with that old phpBB mod-installation instruction form that I can hardly give code-edit instructions without it... ahem. If you look closely, most of the edits are simply adding # mark in front of a line; that's what makes it a comment (everything on that line after the # mark is a comment). There's also fixed the "TK" to be "Tk" (you need Tk::Tree if you want to use the tree view) and Win32-file open dialog changed to Tk's one, that should be cross-platform compatible.

 

As far as the case-sensitivity goes, Perl is actually case-sensitive even on Windows systems. If the "TK" would have been a normal variable, it would never work. Only thing I can imagine why it actually does work on Win-systems is that it is essentially a file path, but it's definitely not valid Perl, no matter how you look at it.

 

I just realized that there's an even easier fix, which is to just move the 'use Tk...' and 'use Win32...' lines into the actual usegui = yes block.  Sorry ... code. That would make it still useable as usual on Windows while also supporting command-line usage on other perl-enabled platforms.

Actually, no. For Tk, sure, there's no reason for "use Tk" -stuff to be there if you're using it from command-line, so it would definitely make sense to include that under the part that is defined if you use gui (and in that case you can run it from command-line without having Tk installed). But Win32... not. The only Win32-one that is actually required to be used on Win-systems is Win32::Autoglob, and only point to use it is when you are using it from command-line. For the file-opener dialog you can simply switch to use Tk's in-built open file dialog, as I did in those instructions of mine. Better than dump the "use Win32::Autoglob;" into a location where it's not used would be to make an if-clause where the script checks OS and use the library only if it is run on Windows. That way the same script can be used in all platforms, with of without Tk installed (if it is called correctly from command-line) and Autoglob would be used where it matters.

 

I guess what would be cool is if it could use GTK instead of TK. But im not sure how that would pan out.

If what would use GTK? MDLOps? It could, but it would require some rewriting. Probably not a big deal... after learning how GTK works first, of course.

Now, now. I've used Red Hat... somewhat twelve years ago. I wouldn't assume to know what Win 10 supports based on knowledge of Win 2000, you know? Nor would I assume Win 10 would be backwards compatible with everything that's done for previous versions of the OS. It's definitely possible OS writers change their minds about what the OS does and does not support, as well as it's possible different builds support different things (they wouldn't be different builds if they wouldn't have differences, now would they?) so I see no reason why there couldn't be a Linux version that doesn't support Tk's windowing system.

 

That being said, I won't assume anything for sure unless I can test it.

Because I wanted to use mdlops on the command line the first thing I did was pull out the Tcl/Tk stuff, and of course the Win32 dependency.

...you do realize that MDLOps has in-built commandline usage, right? There's no need to strip GUI from it to do that. Of course, you may need to strip Tk from it to be able to run it on Mac, but that's another story completely (and in that case, you could rewrite the GUI with another library).

 

Anyway, there's my instructions. Sorry about me not posting them earlier, but deadlines don't wait, and if I need to choose between payed work and a hobby, well...

Assuming Linux can use Tk, this should do the trick (I can't test, so I can't say for sure, but there's all Windows dependencies I can see removed):

 

FIND

use TK::Tree;

REPLACE WITH

use Tk::Tree;

FIND

use Win32::FileOp; # for file browser added by tk102, thanks tk102!
use Win32::Autoglob; # stupid windows shells don't do globbing!

REPLACE WITH

#use Win32::FileOp; # for file browser added by tk102, thanks tk102!
#use Win32::Autoglob; # stupid windows shells don't do globbing!

 

FIND

    my %parms=(
                    title => "Open Model File", handle=>0,
                   filters => { 'Model Files' => '*.mdl', 'All Files' => '*.*'},
                   options =>OFN_FILEMUSTEXIST |  OFN_PATHMUSTEXIST);
    my $dialog_name = OpenDialog \%parms;
    unless (-e $dialog_name) { return; }

REPLACE WITH

    #my %parms=(
    #                title => "Open Model File", handle=>0,
    #               filters => { 'Model Files' => '*.mdl', 'All Files' => '*.*'},
    #               options =>OFN_FILEMUSTEXIST |  OFN_PATHMUSTEXIST);
    #my $dialog_name = OpenDialog \%parms;
    #unless (-e $dialog_name) { return; }
    my $dialog_name = $object{'main'}->getOpenFile(
        -title => "Open Model File",
        -filetypes => [
            ['Model Files','.mdl'],
            ['All Files','.*'],
        ],
    );

That's all! Save and close and run the file. You can also remove the lines where we added the # in front of them, but I hate removing lines when I tweak code like that, so I just commented them out...

 

im sure the tk reference was not a typo, since it can be run without it in linux, but he specifically made it dependent because he was focusing on windows use. he just didnt see it as necessary to edit the script to allow for linux use. i dont think it was ever really intended to be a linux script. if it was he would have realized the case sensitivity of linux and made a folder with the isolated script as an alternate without the same dependencies as windows.

And I believe it is a typo, because "TK" appears only once, while "Tk" appears four times, and all of them refer to the same thing. Or, it could be written by another person.

 

A word of warning - be careful when you install things. Don't install Tk::Tree separately, unless you're 200% sure it's not installed with main Tk. I did that and it screwed the whole Tk library, so I had to install the whole thing again.

well i decided to just forget the idea. heres the thing. if you break into the perl script, it still calls for win32api depemdemcy, and so you have to run it in wine anyway... but it calls for things in windows in such a way that it will brick wall in linux, there is a clue in the script itself which suggests that nobody has ever used this script in linux

Nah, you just need to change the win32api to a library that runs in Unix. (I thought I mentioned that already?) It's pretty trivial, really. I can do it for you, if you tell me which version of MDLOps you're using. Does Tk work on Linux?

 

Edit.

If you or the guy who helped you don't believe it is trivial, consider this: The only Windows-dependant things are file-opening dialog (which consists of five lines of code) and a library that is relevant only on Windows (and thus the dependancy can simply be removed from the code). It is not complicated at all. It may be developed on Windows, and there may be a typo about TK instead of Tk (given that it appears only once, I'm quite sure it is a typo, and was unnoticed only because it was never tested on Unix). It doesn't mean it would need more than a minimum effort to be useable on Linux. I'd give instructions here right away (as far as I can see, all you need is two edits) but I'm a bit busy right now.

It is not the mask, it works fine. The problem is the robe. If you don't believe me, try wearing the mask without the robe and robe without the mask. The issue is that character turns head when they take focus on something on their sides, and the hood of the robe doesn't follow the movement, so whatever is on the face (or the face itself) goes straight through the side of the hood. I'm 99% sure I know what to do with it, but it's a major job, and I'm most definitely not going to touch it as long as my tendons haven't healed. One poorly trained model is not worth permanent tissue damage.

 

As far as your issue at starting Orion goes, did you retry starting it? I don't think FS changed anything there, and I most definitely didn't, and I can't recall ever having that issue myself. Not in there, at least. It sounds very much like the issue I've been having around both K1 and TSL (mods, at least, can't recall if it happens with Vanilla or not) where game obviously feels tired or rebellious and decides to not run some random script. Retrying usually fixes the problem. It's annoying, but I have no idea what's causing it, so it's pretty hard to fix (after all, can't fix a problem if you don't know what the actual problem is).

As far as I recall, MDLOps is actually released under GPL.

 

wow, im glad someone agrees with me about dotnet. it is atrociaous. now if i get perl running and the modlops installed, im pretty sure i can compile it so that there is a link on the desktop that will run commandline for me instead of typing it all the time. console commands are very powerful tools in linux but if i dont have to use them i would rather not,

Well, I'm pretty sure being powerful is what the commandline is for in the first place. Can't believe it would be there just for the fun of it (unless Linux was developed by people who prefer DOS over Windows, hmm). In any event, you don't need to compile anything. If Perl runs on Linux at least half the same way it does on Windows, all you need to do is to double-click (or whatever is the Linux equivalent for Windows double-click) the mdlops.pl and it should run (when you get it running correctly, first). But as long as you're troubleshooting, commandilne is your best friend. After all, if you get a crash, you can't fix it unless you know why it is crashing, right?

I must admit, I'm with the Linux coders in this. .NET is terrible (no offence, C# programmers on board). Luckily, MDLOps doesn't require it. KTool does, though, and even as I'm not exactly capable of troubleshooting that one, one thing to consider: it uses an ancient version of .NET, so maybe it is possible that new versions of Wine don't support it anymore? Perhaps you could try older version for that one? (If I recall correctly, the version of .NET that KTool uses is 2.0.)
 
But lucky for you, that's the beauty with Perl (no offence to those on board that hate it). It is natively cross-platform compatible.
 
As you're using Linux, I assume you are familiar with command-line, so bear with me. If something is unclear, please ask for an explanation. I don't use Linux, so I can't really test, but in theory, it should work; I can help you to troubleshoot if needed. In the MDLOps folder you downloaded, you should have a file named "mdlops.pl"; that's the one you need. (Make sure there's a "mdlopsm.pm" in that folder, too, though.)
 
So, here we go. You have Perl installation up and running, and the path variable added? Go to command-line, navigate to the folder where you have your mdlops.pl, and run command "perl mdlops.pl" (or alternatively, don't navigate to the folder, but instead use "perl [path_to_folder]/mdlops.pl", but that requires a whole lot more typing, if you're doing that multiple times in a row, and in any event, it increases the risk of mistyping, which is awful when you get your huge list of parameters typed and then there's a misplaces character that screws the whole thing because it directs to a floder that doesn't exist). If you are lacking libraries, you should get error message that tells which libraries are missing. Install them and try again. After you have everything installed, you should be good to go.
 
If there's some required libraries you can't install, list them here (or PM me, but I would assume that other Linux users - if there are any - might be interested in that, too), and we'll look for alternatives.
 
Out of curiosity, what's that Blender plugin you're using?

That widescreen is more trouble than it's worth. After these fixes, do the cutscenes appear correctly with 4:3 resolutions anymore?

You need to set the Fullscreen = 0 in both Display Options and Graphics Options for it to work. The AllowWindowedMode=1 is not necessary for TSL (it is for K1, though - trust me, I've went through a wide set of options to get the games work on Intel card) but it does make the launch much more flawless, so I'd really recommend to use that, too.

 

The only way to disable the movies for me seems to be to rename the Movies folder to something else (I usually use "ORGMovies" if it's not modded) and create a new empty folder with name "Movies" - For some reason, the DisableMovies settings never work for me. You may want to try that. Of course, it's not an ideal solution, as you don't see the movies there at all. That shouldn't be necessary if you get it run in windowed mode, though. And if it is, the issue is something else.

Disable movies / switch to windowed mode?

Yeah, mdlops.exe doesn't require Perl being installed. On the other hand, if you do have Perl installed, you don't need the exe, and thus, you should be able to run it on Linux without faking the program to think it is running on Windows. There's some Windows-specific libraries, but switching them to Unix ones should be pretty straightforward.

 

First, clones should have terrible life-expectancy (and by that I don't mean the battles and such). They have a maximum age of 30-40. And those are the clones that aren't "programmed" to age faster so that an army can be created faster. Those guys should only live 15-20 years before they just kick it. This would add to the Jedi's moral objection to why a clone army can't be risked.

You lost me there. Clones are accurate genetical copies of the original, so why would they have a shorter life expectancy than the original? Well, other than those faster-aging ones, of course. I would agree with the maximum age of 30-40 for them, but for the non-programmed ones... why and how?

It is not tied to the Frame Buffer Effects option, at least not solely. I'd rather say it is a graphics card issue. I've had the holographic look for... well, holograms, even with Frame Buffer Effects turned off.

I'm not sure if editing the dialog.tlk in pure text format can ever be considered very noob-friendly. There's graphical editors for that.

That's also not possible since you can't give scripts via feats in K1... :/

You mean "give feats via scripts", right?