ok I'm also fiddling a litte bit with the source code.


There is a bunch of things I would love to see improved and implemented over time by me or someone else


GAME

• 
  game able to display more objects per frame
  



• 
  give helicopter/planes the ability to "see" how big buildings are and fly around or over them if they are too high
  



• 
  new multiplayer code + coop function (play against bots)
  



• 
  change additive light to multiply (shader ?!)
  



• 
  change ingame fov per ini file
  



• 
  make skydome model higher (modelling)
  



• 
  play foot stamp sound when ever a mech foot hits the ground (in the same way as the food prints are generated)
  



• 
  message box (DONE)
  

• 
  read out camera rotation, angle, height
  



• 
  abl editor with visual waypoint modification functionality
  

also

GAME

• able to create & use mech configuration files independently from singleplayer or multiplayer

The Code for the Message Window

http://blog.maginot.eu/index.php?p=till.5__mc2_code


if someone has a better idea for sharing code, tell me pls.

Starman01: don't see how this could be usefull ..


magic: thx for sharing the code!

I and Wolfman are already using a furhter developed code (not mutch) where you are also able to set the style and size with fit files


Imo the pause is very important.

If you want to display story text you should let the player decide how long the needs to read the text


I'll need to update the code on my page

Sorry Magic, I was in a hurry between work and stuff that I missed your question. Of course you may use the code in any edited form. That's why I released it in the first place!

to fix the editor resize bug look into the editorinterface.cpp and change the code to this

search for the line "case WM_SIZE:" and change the case with the following code




case WM_SIZE:
{
float w = LOWORD(lParam);
float h = HIWORD(lParam);
/* disabled by mgto */ //windowSizeChanged = true;

/* by mgto */
//MessageBox("wm_size"); // use this for debugging
if (w != g_newWidth && h != g_newHeight){

if ( (16 < (w - g_newWidth)) || (16 < (h - g_newHeight)) ){ // make bigger
windowSizeChanged = true;
}

if ( (-w + g_newWidth) > 20 || (-h + g_newHeight) > 20 ){ // make smaller
windowSizeChanged = true;
}

if (windowSizeChanged){
g_newWidth = w + 16; //scrollbar thickness
g_newHeight = h + 16; //scrollbar thickness
}
}

/* by mgto */


/* disabled by mgto */ //g_newWidth = w + 16/*scrollbar thickness*/;
/* disabled by mgto */ //g_newHeight = h + 16/*scrollbar thickness*/;

retVal = GameOSWinProc( m_hWnd,message,wParam,lParam );
if (editor && bThisIsInitialized)
{
editor->update();
}
//EditorObjectMgr::instance()->update();
}
break;
}

magic or anyone else who knows:
how to play a sound from one of the mclib cpps ? (i guess it's mclib folder.. the folder where mech3d.cpp is in)

normally everything works from the code folder using the gamesound.cpp (which is also in the code folder but working as a subclass of soundsys)

but I'm not able to create an instance to the soundsys class (which is referenced in mclib) nor reference gemsound.h into the mclib stuff


I don't understand the c++ organisation well enough to get this going

Sorry,
I did not look at sounds.

magic

Check 'ABLMC2.CCP' under 'CODE' directory.

It defines the commands that can be used in script files.
Among these commands are several that refer to playing sounds.
The set up, and header files at the beginning of this file should give you some idea of how to access them from other source code locations, and code examples of how to call 'MCLIB' functions.
Ref: PlayBetty or PlayDigitalMusic

Hope this helps.

hi!

1. I can play sounds form files in the 'code' directory
2. There is no code I can find under mclib that is actually using a sound system. the bink code has something in it but I'm quite sure the bink code is not compiled any more

I can not use the normal way to play sounds 'cause I'm not able to use soundsys (can't get an Instance of the class to work) nor am I able to reference the gemesoundsystem which is under 'code' and not included in the mclib sub-vproject. If I inlclude it I get the error that aFont can't be initialized but I'm not able to fix that

Correct me if I'm wrong (wouldn't be the first time).
I'm new to C++ and don't know what's available through the compiler, and what has to be coded.

MCLib is part of the game Library? Primarily setting up access to existing C++ background functions like the sound system, so they can be called later. If that is the case, you wouldn't be able to access SoundSys, because it technically doesn't exist until it is compiled. Library functions have that tendency.

Where as Code accesses (includes) MCLib, and uses the defined functions. Therefore, you now have access to SoundSys.

The coding setup was most likely never intended to play any sounds from within MCLib, just make sound available.

Is there anyway you can accomplish what you are trying to do in the Code section?
Which brings up the question, what exactly are you trying to do?
I understand you're trying to play a sound file, but for what purpose?

A bit more information might help others point you in the right direction.

Which all brings me around to one last question...

Bink Code? You found Bink Code? Where is it? What filename?

Okay, that was actually 4 questions, but I'm interested in restoring Video capability to the game. It's not a high priority item with anyone else, but I think the game has lost alot of potential without it.

This is what I think (and try to convince people of since some time) video back would be a real value for MC2. It needs a good C++ coder for that; my understanding of object oriented coding is too limited.
Bink is not the way to go because it is a thrid party code that you have to pay for. I believe this is why Microsoft took it out of the source code before they relesad it.

check out wolfman's missions and wolfman's forum at
http://s2.invisionfree.com/wolfman_x_forum/index.php

yes, that it's part of a library could be true. Instancing a Class only after compiling could make sense but I'm not sure it's really true here

anyway.. the bink stuff (which is nothing more as a little bit code not doing the real video stuff) is called something like ...bink.cpp or ..bnk.cpp also within the mclib folder

I want to play a sound every time a mech foot touches the ground

the necessary information is within the mech3d.cpp but as it is part of mclib I need to get a soundsystem there. I see no easy way to transfer the mech-foot-touch-ground information into the 'code' section


and wolfman: you would also need someone who knows a bit about implementing a video codec not only handling c++ code.
But as people are normally not able to create some quality videos I wouldn't call this a really big value to the community .. multiplayer would be better imo

Couldn't find find .CPP you referenced, but no matter, it will take me a while figure out the codec thing and how everything connects together.

Just 'one' quick question, and it requires no response.

Have you considered the full audio ramifications of 16 Mechs (32 feet) all slapping happy across your video screen, and into your ear drums?

And that's just player Mechs add in the enemy and ....v

the filename is : mclib/mc2bink.cpp

and the class I would love to call is 'SoundSystem' and there is already an instance of it called 'sndSystem' but it's used by /gui/ or /viewer/

as said mc2bink.cpp is using the soundSystem instance of the GgameSoundSystem class I guess. but mc2bink is not used anymore.. but it makes me wonder if it IS possible to get the sounds active from the mclib folder


and yes I'm aware how a bad foot step sound implementation would sound like .. and I also know there are some old files in the source showing that they where planing to implement these sounds but decided against it.. bc of lac of time or other reasons
but I'm sure I'm able to create a good foot step sound implementation if I'm somehow able to get these sounds working

No such file, I got one called MC2Movie in the Code. You may have one of the first downloads of the source, before all the Bink stuff was cleaned out. I got mine just a couple of months ago.

Anyway, back to your problem...
Mech3d looks like it's setting up the animation frames. It may not be the best place for your Mod.

We can look at this logically.

Problem: You need to add sound based on a specific action/animation situation. Walk or Run.

So, other questions to figure out...
What calls Mech3d?
What other process has a sound associated with an animation action?
Is there another direction to work from?

Possible solution:
Find a similar process, and see how that works.
Look at the process for Jump. It uses special animation, and has a specific sound associated with it. (Which only works after the first jump.} It also has several functions for it in Mech3d, but no calls to play an SFX in those functions.

Where is the sound process executed? SFX sound = JUMPJETS = 76

There has to be something that says process a jump action, and play this SFX with it. Check the GUI process for the Jump Action.

That's your way in. Start with the mouse click for jump. Follow it to when and where it plays a sound. Apply the same or similar coding to walk and run. Walk should be easy, since all mechs walk at the same speed. Run will be more difficult since each mech chassis has its own speed.
You might actually find most of the code already there commented out, or a reference to what was planned.

Also check on how SFX Sound Channels are set up. There are a set number of channels and a priority system, so if there are too many things to be played at the same time, high priority gets played and low gets trashed. Set your priority appropriately.

Hope this helps.

check out wolfman's missions and wolfman's forum at
http://s2.invisionfree.com/wolfman_x_forum/index.php

@rollin :

regarding that :


"give helicopter/planes the ability to "see" how big buildings are and fly around or over them if they are too high"



Have you made any progress in that ? After taking a look into some fit files, I found that most if not all object have the same settings in the (Bound) part. X, Y and Z is all set to 20. Have you tried changing those values ?

Either MS didn't get it working, or was simply to lazy to edit different bounding boxes per model

that was a good idea!

unfortunately the bounds are only creating a 2d rectangle. Not sure for what that was or is used. Changing the values doesn't seem to do anything 0.o

Hm, maybe it's disabled in the code ? That would explain why they didn't bother to change the values. Karl found this in the code, maybe it's related and you can add the z-axis :

// convert to block and vertex

              long tileCol;

              long tileRow;

 

              land->worldToTile( data->vector, tileRow, tileCol );

 

              int blockI = tileCol/20;

              int blockJ = tileRow/20;

              

              data->blockNumber = blockJ * land->blocksMapSide + blockI;

              tileCol -= blockI * 20;

              tileRow -= blockJ * 20;

              

              data->vertexNumber = tileRow * 20 + tileRow;

              countObject(data);

              

              data++;

       }

 

// convert to block and vertex

              long tileCol;

              long tileRow;

 

              land->worldToTile( data->vector, tileRow, tileCol );

 

              int blockI = tileCol/20;

              int blockJ = tileRow/20;

              

              data->blockNumber = blockJ * land->blocksMapSide + blockI;

              tileCol -= blockI * 20;

              tileRow -= blockJ * 20;

              

              data->vertexNumber = tileRow * 20 + tileRow;

              countObject(data);

              

              data++;

       }

 

check out wolfman's missions and wolfman's forum at
http://s2.invisionfree.com/wolfman_x_forum/index.php

Anyone had a look at increasing the number of objects that can be displayed on screen? I have and have found some code that to an untrained eye looks promising but I cant seem to get the MC2 source code to compile.

TG_Shape::tglHeap = new UserHeap;
		TG_Shape::tglHeap->init(tglHeapSize,"TinyGeom");
		
		//Start up the TGL RAM pools.
		colorPool 		= new TG_VertexPool;
		colorPool->init(30000);
		
		vertexPool 		= new TG_GOSVertexPool;
		vertexPool->init(30000);
		
		facePool 		= new TG_DWORDPool;
		facePool->init(40000);
		
		shadowPool 		= new TG_ShadowPool;
		shadowPool->init(30000);
		
		trianglePool 	= new TG_TrianglePool;
		trianglePool->init(20000);

Has anyone else come across this piece of code?

To me (an untrained eye) it would seem increasing the value will increase the RAM allocation and also increase the number of instances of these geometric features that the game can handle? I know MASSIVE assumption!

Again I am very new to C++ so most of the time I dont know what I am looking at but I am keen to learn and help with the current multiple projects to revamp the MC2 engine.

By the way if anyone one wants a program written that says "Hello World" in a cmd window, I can do that no problems!  

   
  
   

depends.. In which file did you find it?

Looks interesting indeed!

File is mission.cpp

Mission::initTGLForMission()

Rollin I made a hybrid of your message box:

void ControlGui::setMessageText( int mode, const char* getString, int timeToDisplay)

if mode = 0 (default) timeToDisplay is required in seconds.
mode > 0 it displays your mesage box with pause game and press enter to continue, timeToDisplay not required.

Magic, I've updated my message window code here

http://blog.maginot.eu/index.php?p=till.5__mc2_code


The biggest change is the implementation of the buttonLayout(...).fit Files to set the messagebox size and colors for every resolution in a proper way


It should be easy to implement the changes into your version of the code.

Note: only controlGui.h and .cpp have changed and you need to add the new block to each buttonLayout(...).fit file

oh and something else


could you implement the following bug fix?!



it's only a very tiny visual bug of the mech torso rotation. I'm quite sure nobody else notice it but me it drives crazy




mech.cpp


old line
if ((torsoRelFacing < -fireArc) || (torsoRelFacing > fireArc) )

new line
if ( (torsoRelFacing < -fireArc) || (torsoRelFacing > fireArc) || ( (torsoRotation <= fireArc) && (torsoRotation >= -fireArc) ) )

it's simple for others to change the look without working with the source code. You are the code right now.. but you also have to think about those who want to mod your mod (mission builders like me for example)

THAT is great

I have nothing to say in this case. It's wolfmans thing and not mine.

I'm just helping here and there with code stuff

What you or wolfman do with the code, if you use the same or not, is something both of you have to communicate.

I don't have time to do or look into anything atm anyway.

Your right Rollin I guess the file is important so...
This code can be found in both mission.cpp under the mechcmd2 project and also in editor.cpp under the editormfc project

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!



Karl you are close to beeing the hero of the day..



Magic and Wolfman (when you're back)


open mission.cpp (not mission2 or anything else yet)
and double all Pool Values

(stuff is around line 3075)

It does work here but I've already changed some values in the mid level renderer (MLR) so please do only this and nothing else and test it with a very crowded map (big forest or something like that)

I'm not saying we have it.. but we are certainly very very close!

Great find Karl!

Whoohoo! Hero of the day is what I was aiming for!

Wicked I am glad that something I found was actually useful. Not sure if you can tell from the code but are the values quoted in my post byte values? just curious really.

Also remember these values are also present in editor.cpp, would be keen to know what effect these values have on the mission editor, I would investigate myself but I first have to figure out how to get MC2 compiling.

That's great news guys, I'm keeping my fingers pressed that it works

Similar to the code I posted there is also this additional code in editor.cpp

Its lives in the code block directly under the previously posted code block in editor.cpp only

//------------------------------------------------
// Fire up the MC Texture Manager.
mcTextureManager = new MC_TextureManager;
mcTextureManager->start();

//Startup the vertex array pool
mcTextureManager->startVertices(2000000);

check out wolfman's missions and wolfman's forum at
http://s2.invisionfree.com/wolfman_x_forum/index.php

I have a good testing object for you guys. This is a mission wip from myself with a very big city. The retail editor and the game had already problems displaying it, and that even if the trees and props are still missing.

Mission is based on MC2X

I have now overlayed the city with a dense forest, that should generate enough polys (after all, the trees alone don't have that much polys, so that might be the reason why you haven't noticed any big changes yet)

Download here :

http://wcsaga.hard-light.net/team/Starman/downloads/data2.rar

There are some settings with the mid level renderer that might have an influence on what karl posted


the first place can be found in mlr.hpp around line 117

something like Max_Number_Vertices_Per_Frame = ... and so on

this is "just" a place that initializes basic values that can be changed on function call anyway but as this function seems to be not always called with all arguments this is not that unimportant.

so for the first test it would be interesting what happens if you double the values here (make sure they can be divided by 2 like 1024, 2048 ...)

the 2nd place is in mechcmd2.cpp
seach for "MidLevelRenderer::InitializeClasses(

2nd test would be to change values here but not in mlr.hpp

3rd test would be to change values in both files



here is my current state where I see now a lot more objects on screen

in mlr.hpp i use still some old values for testing which are way higher the the defaults:
vertices : 16384
primitives : 16384
the others values are the default ones

now in mechcmd2 i use also some old test values but this time lower ones!
(512, 512, 0,0,true)


that's all I can tell for the moment

Since you are all looking at the code at the moment, has anyone come across this site? it outlines some code corrections to fix little bugs in the game, this may be old news but thought I would mention it

http://klucher.com/blog/mechcommander-2-fix-guide/

check out wolfman's missions and wolfman's forum at
http://s2.invisionfree.com/wolfman_x_forum/index.php

is it possible to read the settings for the pool stuff out of the settings or options cfg? OK, of course it's possible but how much effort?

Would be cool as soon as we know for sure what's necessary to increase the models per screen.

Wolfman says he's not sure if doubling the values alone did something significant

ok, so far we are not sure what the MLR is doing (bc I also didn't saw any real change)

but changing the values in mission.cpp does increase the amount of objects one can see (I tested it and magic tested it)

Magic, when are you releasing your latest build?

And I hope we can get this into MC2X too

released.

check out wolfman's missions and wolfman's forum at
http://s2.invisionfree.com/wolfman_x_forum/index.php

I also hope we can close the technical gap between wolfmans and magics mod. For me it would be great to port my maps easily from one mod to another and just deal with the balance changes based on the different gameplay

I know wolfman has it's way of thinking about mc2 as magic has too. But getting conform on a basic technical level would help both!

That's also my motivation why I release all my changes and modifications to everyone!

Seconded

After you declared to finish your MC2 activities some years ago I used whatever slots anywhere have been available and extended the content of inventory by adding objects from other authors. I believe it is not compatible at all.

And I believe that I overcame the limitations in object2.pak. It can handle now around 3000 objects compared to issue it had before at a little over 1000.

check out wolfman's missions and wolfman's forum at
http://s2.invisionfree.com/wolfman_x_forum/index.php

While you guys dig through the code, have you encountered the existing limits for objects and warrior brains for missions ?

In Chapter 2 of my campaign I decided to use the 120x120 map size two times, and for big maps with lots of battles you ran quickly into the warrior limit, i think it's currently 120 (counting all mechs and vehicles)

Also at some point the editor refuses to add any more trees (and objects I guess), he says it runs out of resources (while not getting slow or something). Certainly nothing that needs to be done quickly, but it should get a place on the "needs" list, when you plan to insert bigger maps too.

Found alittle bit of code regarding texture size for models, under aseconv -> Source files -> ase2tgl.cpp

Line 51

"long ObjectTextureSize = 128;"

When/if someone gets anytime would you mind changing this value to say 512 or 1024 and run a model though please (if it is as easy as that)

1024 is too much imo, I would say max 512. After all, think about the size of the units ingame, most of the time you are zoomed out a bit. Until there is no decent Lod system, I would say 512 is enough
But with a good lod system, nice camera angles you could zoom in into 3rd person view, then 1024 will become interesting

Only thing that needs uge textures are landscape textures.

I say 512 is too much.

Of course it's never bad to loosen restrictions but I doubt there are many people around capable of filling all these pixel with a good texture.

Also this would lead to
redoing all default textures to get an consistent look
doubling or tribbling all objects polycounts to really make the texel density worth the effort

I say, 256 would be nice and still difficult to fill


A Texture size of 512 or 1024 would mean to use normalmapping and creating a mechcommander 3

for everything else, less is more then enough!

- my opinion

Fair enough, I really dont care what it is changed too, I was more interested in finding the benefit limit, at what point do more pixels = no more useful detail. It sounds like the more experienced heads here already have a handle on that which is fine by me.

That would be best, since it's also important to easy mod all the other stuff

Rollin,

have you seen this?

struct Limits {
static unsigned
Max_Number_Vertices_Per_Frame,
Max_Number_Primitives_Per_Frame,
Max_Number_ScreenQuads_Per_Frame,
Max_Size_Of_LightMap_MemoryStream;

enum {
Max_Number_Vertices_Per_Mesh = 1024,
Max_Number_Vertices_Per_Polygon = 32,
Max_Number_Of_Texture_Bits = 14,
Max_Number_Textures = 1 << Max_Number_Of_Texture_Bits,
Max_Number_Of_NGon_Vertices = 9,
Max_Number_Of_Multitextures = 8,
Max_Number_Of_Lights_Per_Primitive = 16,
Max_Number_Of_FogStates = 4
};
};

in mlr.hpp.

You are much more versed in modeling then I.

yes I've seen them


but I don't see any use to increase them atm. Interesting only of someone wants to try to create a new graphics quality level

Hi guys

Could someone with code experience please look at objmgr.cpp particularly the section about "Gameobjectmanager::Load" approx line 3028

I am watching the video links that I posted the other day in the sticky thread and they guy on the video is going on about there being building, vehicle, mech, terrain, etc object limits set in this code and that if these limits were exceeded MC2 would just not draw them

Here is the solo mission quicksave fix

I'll collect all changes now on one page where I can use colors to make more clear what's new

http://blog.maginot.eu/null.php?p=till.5__mc2_code

Hi Magic,

do you also notice an increase in crashes with the more-objects-higher-viewdistance? Working with mc2x r16 atm and not sure what is causing the crashes.

You have told that you have fixed some issues with the memory and poly/objects heaps.. Did this fixed the issues for you? And do you have no more crashes connected with that?

Would be nice to get some insight in what you have found out on that issue!

cheers
rollin

Well, no time for testing. Please install MCO and see.
I had no reports of such crushes lately.

I reduced object rendering (buildings, not mechs and vehicles) if the distance from camera is greater then value. I also reduced shadow rendering.

We have one map (120x120 with lots of objects) made by starman that had constant crushes, not any more.

There are also indications of some other things that can cause crushes, terrain passable or impassable calculations or path calculations.

There is also a possibility that new objects can cause unexplained crushes. For example My new Kodiak had 10 weapon nodes, there was an error in ase file that was translated OK to tgl and agl and caused some severe crushes. The error was an empty line in ase between weapon node 8 and 9. That empty line caused unexplained memory related errors.

Memory changes were connected to after mission crushes for maps above 120.

Hi, thanks for the valuable info!

I want to make some tests but I have a simple problem now. If I want to load my map with the mco editor but the editor crashes. Funny is: even if I want to load some of the maps that come with mco it crashes (e_1_x for example)

It would be great if missing objects are replaced by a dummy object. That way I just have to go over all dummy objects and change them back to the object they should be.

Strange is that the editor has the functionality to do so as long as the object is not visible (== hidden behind the fog)

would be great to have this dummy-object-function

The editor will crush if you have set model id for model to be displayed in objectives

l modelID = ... must be new objnum for mechs,
vehicles and new buildings, or the editor crush on show object in objectives.

I changed those Ids in my mission.fit files and all of them can be opened now.

Missing objects will work for buildings, but not for movers, if you have mover objects from X, their object numbers will find a file from different object in MCO and that will create an error. For example you have a mech from X with object num 55. It will load file 55 from MCo object2 and that file can be from another mech (it will not crush in that case), or from vehicle (crush) or from building (crush).

So you have to remove all mover objects from x and (I think) the editor will handle the buildings.

Or open your mission.fit file and change all object numbers and names for mechs and vehicles to MCO numbers. You can find all those numbers in buildings.csv and for all mechs, vehicles and new buildings in missions/moveobj.fit.

EDIT: Can you do the writing of that dummy-object function? I will try but I am very short on time...

yes got it working. thanks for the tip!!


btw a suggestion: can you "fade out" the shadows? like make the transparency dependent on the view distance and disable them when they reach the max range

about the dummy object hting. I'll have to setup a source code and visual studio first. my other rig where I did all the code work is not here where I live now. Will try to get this running.

thx again for your help!!