Fans use Machine Learning to HD Remaster Final Fantasy VII

bugs_ said:
or conversely you can opt for a zip-less/vol-less configuration and have everything in the folder and no zip/vol file
Click to expand...

ya tru

the only reason i said .zip was iirc 1.40 throws console errs when certain .zips are missing

i tended to extract a zip, work in the folder and then re-zip when finished
 
A new mjhires.acs.cs file has been posted.

I've been able to get the upscaled DOX textures to be displayed properly.

What led to this is that I noticed I was running a local 1.40 server whenever I was running a 1.40 hrfix client. What the hell?

Sure enough at the beginning of mjhires.acs.cs we have this:

createServer("Broadside", false);

If you remove this then mjhires doesn't work. Sudden understanding results. mj (or altimor) is using what the local server instance knows about and not what the client knows about.

https://youtu.be/wRnSnfiUI54?t=17

so the latest mjhires.acs.cs now has this:

newObject("DOX_textures",SimVolume, "DOX_textures.zip");
newObject("savanaDML",SimVolume, "savanaDML.zip");
newObject("titanDML",SimVolume, "titanDML.zip");
createServer("Broadside", false);

so that the server instance knows about these volumes. the more we add here the more tricky our memory usage will become.

*** I do think the creation of the local server instance needs to be disclosed to those running this (and the earlier versions of it). ***

perhaps we can put a "deleteServer();" in there somewhere? maybe mj could let us know about that.
 
Last edited:
so, this is all my vague recollection... so instead of prefacing every statement with 'iirc' im just gonna ramble

so it may or may not be exactly how things happened... but, IIRC:


we had an issue with hrfixfix where on first map load, no scaling would take place at all

then you'd disconnect and re-try and it would work on 2nd/3rd etc

emjay said he never had that problem with his 1.40 so he couldn't re-create the issue to troubleshoot

i think it was plasmatic or crow who figured out that if u did the createserver thing during startup, it worked on first load

so we added this and i think echo that its a fix 4 hrfixfix (more like a workaround but whatever)


if u throw the deleteserver in the script does it still work on first load?

thx 4 ur work on this bugsy_

i wonder if emjay still has the source for this and could make an hrfixfixfixfix
 
Last edited:
Nice to know some of that history.

If we do a deleteServer(); a bit later (say 1 minute into the first map) it seems ok with no ill effects. we can play with how soon it happens.

the not working the first time reminds me of a problem we have with 2048x2048 lushDML. it takes so long to load it that we get dropped by the server.

so i put in a preload script to preload all the terrains before we try to join a server.

this may be a similar issue - that the first time through some things haven't been loaded yet so it doesn't work. creating a server instance loads some volumes that may not have been loaded or initialized yet.

maybe we just need a longer list of volumes to preload instead of making a server instance.
 
Last edited:
In a 32 bit binary (which 1.40 is) you are hard limited to 2GB of data - you can't address more than that simultaneously.

in an upscaled 1.11 configuration we reach that 2GB limit because 1.11 will load all the terrains and keep them in memory.

1.40 will delete and recreate the terrain used each map - this makes more memory available (at the cost of a performance hit at the start of each map) but we still have a ceiling at 2GB.

This is one of the reasons why the world has gone to 64 bit for OS and large applications.

If you try to go to 1024x1024 textures with 1.40 you will hit the 2GB barrier and 1.40 will crash.
 
bugs_ said:
Nice to know some of that history.

If we do a deleteServer(); a bit later (say 1 minute into the first map) it seems ok with no ill effects. we can play with how soon it happens.

the not working the first time reminds me of a problem we have with 2048x2048 lushDML. it takes so long to load it that we get dropped by the server.

so i put in a preload script to preload all the terrains before we try to join a server.

this may be a similar issue - that the first time through some things haven't been loaded yet so it doesn't work. creating a server instance loads some volumes that may not have been loaded or initialized yet.

maybe we just need a longer list of volumes to preload instead of making a server instance.

btw with goldeneye/perfect-dark textures we have almost 5000 mjhires image entries and lots of volumes so i haven't hit a limit there yet (other than the 1.40 2GB data limit because 32 bit).
Click to expand...

Nash said:
Bumped for Groove
Click to expand...

ty 2 Nash 4 the thread bump

so it's been a while but i was finally testing this and finding with the deleteserver in the script it's not resizing most of the time

trying 2 think of a way 2 schedule this deleteserver for later (cuz if you try 2 schedule it that early the scheduler isn't running)

can we maybe attach a function to joining a server and schedule it for shortly after? if i take out the deleteserver it works pretty reliably

@bugs_ thoughts? i was playing around with your updated files and it looks fantastic, thanks for all your work on this
 
Groove said:
@bugs_ thoughts? i was playing around with your updated files and it looks fantastic, thanks for all your work on this
Click to expand...

The script could save the current values of $Server::HostPublicGame and $Server::port then set them to false and a random number (say 10000+ random*9999). Then the created server instance wouldn't broadcast its presence to the master servers and the chances that an outside intruder would guess the port to connect to would be lowered (unless it were automated).

This would reduce the security annoyance/disclosure problems of the created server instance. Upon tribes exit the original values should be restored.

Wondering out loud could it be possible that there are two memory subsystems inside 1.40?

A tribes-in-a-browser memory subsystem that is used by the 1.40 in client mode and the standard 1.11 system that is used when isServer() is true? If this is the case i wonder if it might be possible to simply switch memory subsystems rather than absorb the additional overhead of creating a server instance.

We would have to be careful here because the 1.40 behavior of deleting the terrain textures at the end of the map help the 32 bit 1.40 "stay alive" longer than a 1.11 tribes using the 512x512 textures. 1.11 will keep all the terrains used in memory whereas 1.40 will keep only the current map's terrain in memory (createserver() may stop this behavior?)

If we could keep better tabs on available free memory we could delete the least recently used terrains when we got tight on memory. that might be a good compromise between the two memory systems.
 
ok so yeah this works although its kinda nuts

Code: 
%saveplaymode = $pref::PlayGameMode;
%savemission = $pref::LastMission;
%saveServerPort = $Server::Port;
%saveServerPub = $Server::HostPublicGame;
$Server::Port = round(getRandom()*100000, 0);
$Server::HostPublicGame = false;
echoc(4,"++++ starting $hrfixserver on port " ~ $Server::Port);
createServer("Broadside", false);
$pref::PlayGameMode = %saveplaymode;
$pref::LastMission = %savemission;
$Server::Port = %saveServerPort;
$Server::HostPublicGame = %saveServerPub;
$hrfixserver = true;

function Groove::KillHrfixServer() after JoinGame
{
	if($hrfixserver)
		echoc(4,"++++ $hrfixserver is true - scheduling deleteserver " );
		Schedule::Add("deleteServer();",30);	
                $hrfixserver = false;		
}

or this version with comments and using switch instead of if cuz i hate if:

Code: 
echoc(3,"fix4hrfixfix" );
//save your current server settings
%saveplaymode = $pref::PlayGameMode;
%savemission = $pref::LastMission;
%saveServerPort = $Server::Port;
%saveServerPub = $Server::HostPublicGame;
//create random 5 digit server port for hrfixserver, set not public, start server
$Server::Port = round(getRandom()*100000, 0);
$Server::HostPublicGame = false;
echoc(4,"++++ starting $hrfixserver on port " ~ $Server::Port);
createServer("Broadside", false);
//restore server settings
$pref::PlayGameMode = %saveplaymode;
$pref::LastMission = %savemission;
$Server::Port = %saveServerPort;
$Server::HostPublicGame = %saveServerPub;
// setting stupid variable so we know this server is started
$hrfixserver = true;

function Groove::KillHrfixServer() after JoinGame
{
	switch($hrfixserver){
		case "false":
			echoc(4,"++++ $hrfixserver is false - doing nothing" );
			break;
		case "true":
			echoc(4,"++++ $hrfixserver is true - scheduling deleteserver " );
			Schedule::Add("deleteServer();",30);
			$hrfixserver = false;
			break;
		default:
			echoc(4,"+++++ $hrfixserver unexpected value? doing nothing" );
			break;	
	}
}

so this way: the server is not public + on a random 5 digit port and stops running 30 seconds after you join any server

think that might be the best we can do unless we ever figure out why it doesn't load w/o all these shenanigans
 
Last edited:
You must log in or register to reply here.
Back
Top