East Front Mod - Presentation

(xro) #1

The mod is gonna be situated on 1940-1945, with russians.

Some of the features will be:
* Player data will be stored on a master server (saves your rank, xp, skins etc for ever)
* Drivable tanks with a new class that is specialized in driving.
* New maps.
* Lots of skins to costumize your character. (around 60 skins per team)
* A bit more realistic than ET, but not too much so it wont become boring…
* New weapons. (the russian ones and some new weapons for the axis)
And much more…

But enought it is still too early to talk about this

Our team has 8 members and we are looking for:

5 Mappers
3 Coders
2 Sound artist
2 Moddelers
1 Skinner

If you wanna join us, visit our provisory forum.
We will have an website with screenshots and updated news soon!

(carnage) #2

well its not realy the first time weve had news of a mod like this and not realy much originality

im also curious to some of your features. do u think that adding 60 skins per team will realy make the game much more enjoyable to make it worth the work to make 120 skin images and definitions

also how you plant to implement this when you could be on a 20 v 20 match with potentialy 40 differnt skins and hold them all in memory and send them all though the cash without hitting any performance limitations. i dont know if you looked at the current skin images but they are pretty big

(kamikazee) #3

This mod is as doomed as FalckonET in the aspect of memory footprint.
As Carnage pointed out, (thanks, saves me talking) that every image file counts when it’s loaded into memory.
If you are aiming for 120 new skins, most if not all will be loaded and most newbie’s will be scared of when they get the “could not allocate memory, see com_hunkMegs” error.

If you’re serious about this, I wish your mod the best of luck. :slight_smile:

(Jaquboss) #4

hint : search for members on non-ET related sites, especialy Q1-3 ones
you might be suprissed that a lot of ppl don’t know about ET or didn’t try it at all

(El Stupido) #5

As Carnage pointed out, (thanks, saves me talking) that every image file counts when it’s loaded into memory.
If you are aiming for 120 new skins, most if not all will be loaded and most newbie’s will be scared of when they get the “could not allocate memory, see com_hunkMegs” error.

com_hunkmegs can be altered pretty easy if your going to code your own client anyways. (hint: fs_basedir cough commandline coughcough)

(kamikazee) #6

You can’t com_hunkMegs them from within your mod, as the engine is already running at that moment.
The only way to do it is by pressing your newbie users to start W:ET with a parameter, or by setting their com_hunkMegs to a higher value in etmain as well.

Or do you happen to know another way? (except for a script or launch executable)

(El Stupido) #7 
void forcehunk(void){
	char		server[MAX_CVAR_VALUE_STRING];
	char		hunk[MAX_CVAR_VALUE_STRING];
	char		base[MAX_CVAR_VALUE_STRING];
	char		game[MAX_CVAR_VALUE_STRING];
	char		*p;
	
	trap_Cvar_VariableStringBuffer("com_hunkMegs",hunk,sizeof(hunk));
	if(atoi(hunk)<128){
		trap_Cvar_VariableStringBuffer("cl_currentServerIP",server,sizeof(server));
		trap_Cvar_VariableStringBuffer("fs_basePath",base,sizeof(base));
		trap_Cvar_VariableStringBuffer("fs_game",game,sizeof(game));
		
#ifdef WIN32
		p=va("%s/et.exe",base);
#else
		p=va("%s/et",base);
#endif

		execl(p,p,"+set","fs_game",game,"+set","com_hunkmegs","128","+connect",server,NULL);

		trap_SendConsoleCommand("quit
");
	}
}

This goes to CG_Init below CG_ParseWolfinfo. It works fine besides on linux it seems to screw up sound on some installs . I think this is related to the new process starting before the old one terminates but i didnt have time to look into it yet.

(xro) #8

lol, we aren’t going to use all skins at the same time, having a snow camo skin on a spring map is just useless, on the menu you’ll be able to choose your snow camo skin, spring camo skin, etc…

(Ragnar_40k) #9

Take a look at this (never finished) mod for RtCW: http://www.planetwolfenstein.com/russianfront/
Afaik they already made some new models etc.

#10

I was kinda waiting for that mod :frowning:

I don’t think this is gonna become anything, really, but good job if it will :drink: I could join the team as a mapper if I had more experience, but unfortunately I don’t yet have enough of it.

(Jaquboss) #11

nice work el stupido

(jaybird) #12

The reason is because ET never shuts down. When you use those exec calls, the image in memory is overwritten with what you are execing. Therefore, your quit call is never executed, and ET never gracefully shuts down. I don’t know the specifics of the sound system in linux or ET, but I’m sure that’s the source of the issue.

It doesn’t seem like a very safe method to accomplish what you are trying to do.

(kamikazee) #13

Agreed that it’s not the safest thing to do. In fact, the correct way to start a program is to fork() the parent process and then to exec the new ET instance in the child process. Problem is: it might be a pain to do this on Windows/Mac platforms.

W:ET mostly uses /dev/dsp which supports no mixing, so only one program can use it at a time. And because W:ET is not really shut down in a proper way (as jaybird pointed out), the file is never closed untill the second W:ET is closed as well.

Anyway, thanks for the code snippet and now back on topic…

(Mr.Mxyzptlk) #14

Even if the et-engine tolerated such stuff, I wonder how OpenGL, Sound and other
subsystems in Linux, Windows, and OSX take to re-exec behavior?

(SCDS_reyalP) #15

You could ship your mod package with an installer and lanucher, and use the launcher to put whatever you need on the command line. Wild west for RTCW did this, if i remember right.

(El Stupido) #16

Agreed that it’s not the safest thing to do. In fact, the correct way to start a program is to fork() the parent process and then to exec the new ET instance in the child process. Problem is: it might be a pain to do this on Windows/Mac platforms.

Thanks very much… you saved me a lot of hairloss i think :slight_smile:

I dont know about mac but at least on windows i dont think the fork is necesary as it seems to start a second process anyways. I think it works like this because it relies on windows API? Not sure… corrections welcome :wink:

Edit: Err well no corrections please ill try myself and this has gone far to much offtopic… sorry for that :frowning:

(SaMFoX) #17

doesn’t matter we like the thing to get some help… :clap: :clap: