Any news about Strings, is he still around?

No, he hasn't been seen in months, Zeleni. I sent him an email but he hasn't replied to that either. I've left a message next to his combat system saying it is no longer under development now.

What a pity, he was a nice fellow... damn it when my hard drive went off i'v lost all his vulcan and malon ships!! Matress is it possible that you have a copy of those files/ships?

I've got his model viewer which has his Malon ships but they are in .xnb format.

Regards Wolfe

The modelviewer is available on sharepoint. I sent a message to Kenneth this morning asking whether we might be able to incorporate it as an official program with ALL the models in it, but Kenneth hasn't read it yet.

Wolfe, would you be able to adapt it/make a similar program? A model viewer would be useful in the tech screen, and would be a nice program to whet peoples appetites for the combat system even more...

As far as I know there is no reverse engineering regarding XNB. Once put in XNB stays in XNB. Strings ships are lost for now.

Damn, I just got a PM from Kenneth over on the AFC forums. He's still afflicted by the forum glitch here so can't log into his account.

I've told him what's going on here and given him links to the updates for Supremacy and Wolfe's combat system. I've also updated his password to see if he can log in with that, but i'm not hopeful of it working.

Kenneth has asked me to urge people to upload whatever models that they have to the models folder on Sharepoint because of losses like this. If you have any models, PLEASE upload them as soon as you can. Kenneth IS still working behind the scenes on getting all of the models up to scratch and correctly labelled, so uploading the files will make his job a lot easier and will help ensure future accidental losses are minimised.

...

I just checked Zeleni, and you're right. the .xnb filetype hasn't been hacked yet - and .xnb users seem almost fanatical about that "feature". Idiots.

Please be conservative with your uploads to SharePoint, as we have limited space. Please use good compression (ZIP "normal" is fine), and try to exclude any extraneous files that aren't actually used by your models (e.g. old materials that you've replaced).

why not upload then to the host? no shortage of bandwidth there

Bandwidth isn't a problem on the SharePoint site. We have a couple gigs of space, but files add up quickly these days. Just asking people to try to be efficient with their uploads.

I tried Combat Demo IV today (don't know how I missed it before) and it's look great and runs smoothly on my GeForce4 MX440 ( lol )

I just want to know how can I see fps? And can I run it with other ships?

You can only see FPS in windowed version which this is not sadly, also i have enabled Vsinc in this one for realtively smooth play so you won't get FPS higher then your monitor refresh rate anyway .

You can add any of the ships i have listed as files in the ship data folder, they are xml files.

Just open up the GameState.xml file and change the values you want for the number of ships aswell as the type of ship.

i.e

// Declare how many friendly ships are in combat
<Friendly_Ships>
<value>3</value>
<name>Dom_Attack_Ship_IV.xml</name>
<name>Dom_Attack_Ship_IV.xml</name>
<name>Dom_Attack_Ship_IV.xml</name>
<name>Miranda_Destroyer.xml</name>
<name>Fed_Cruiser.xml</name>
<end></end>
</Friendly_Ships>

This will load 3 ships, (NOT! 5 as value statement indicates 3), and these 3 ships will be Dom_Attack_Ship_IV variety.

the varying xml files to load up are all in the ship data folder.

You can also add your 'OWN' ships but that is a little more complex.

Regards Wolfe

TNX! It's working! I destroyed a Borg Cube

Combat simulation crashes for me as soon as i start, it says something like this: " can' t create direct3d 9 driver".

I thought it was something with direct x so i reinstalled direct x and manualy inserted d3d9.drv in system folder but it didn' t work.

Odd, It runs on DirectX 9 though you can use OpenGL if i wanted to though it looks like and runs like crap.

I assume you run similar games which need directX ?

Regards Wolfe

All other games and first version of your comat demo run perfecty. Any clue?

Could you post the full error?

Bar natural coding changes, all there is differant is that it is set to full screen mode and also Vsync is enabled where before they weren't.

Here are the files to replace those in the Debug folder only, just pop them in.

http://cdr.wolfe.googlepages.com/Debug.rar

The only changes are i reset it to windowed mode and set vsync off, i very much doubt this is what is causing it but give it a go.

Regards Wolfe

I have replaced debug folder content now app crashes again but from another reason... i will take screen cap to show you how it looks.

Screen cap:

The last one shouldn't really happen often, just done to some poor coding on my part i believe.

Have you tried to load it up more then once?

If so and it keeps giving you that error please tell me.

Regards Wolfe

No change, it keeps crashing...

Thats just odd, it seems C# just doesn't like it when i try and get a string name. Something to do with 'Strings' getting corrupted, bleh i don't know, maybe MStrobel knows why.

Anyway i'll look into it. Have to wait for now I'am afraid Zeleni.

Regards Wolfe


Quoted from elsewhere:

"You've used unmanaged code - raw win32 API. Unfortunately, the memory protection you consistently get in .NET Framework, where all parameters are passed ByVal is not a protection you get using unmanaged pinvoked platform code for win32. Everything is passed ByRef... and that is a thing not always easily done since you have to send pointers"

I may have done something similar who knows .

Wolfe, the demo just crashed on me:



I also noticed the Klingons were a little...white. Is it meant to be that way?

Some of the ship textures can't handle lighting it seems so don't look very good.

Hmmm must have missed that error on my runnings, can't look into it now but will do when i get back, for now i guess just avoid using 'Avoid'

Regards Wolfe

I'd recommend avoiding Irrlicht.NET, since it's a wrapper around an unmanaged library, and it's not very consistently maintained. Did you look at the JAD Engine, wolfe? It's pure managed C# code on top of Managed DirectX.

I did have a look but as much as this is a learning experience for me, i won't be changing horses midstream. Not until i'am confident that there is the support and knowledge to do so.

That is not to say i won't code it using the Jad engine. But it will have to likely wait until i have a more or less feature complete Irrlicht engine.

Regards Wolfe

Unfortunately, switching frameworks in the middle of development is pretty common in the software development world--better get used to it .

since it's just a wrapper, do you think wolfe, that libs and dlls or anything can be used directly within bote?

I don't quite know what you mean Malv, all i do know is DLL stands for (Direct Linked Library) beyond that i have no idea what a DLL or Lib is or does .

Regards Wolfe

Mal has observed that Irrlicht.NET is simply a managed wrapper around the native C/C++ Irrlicht library. I believe he's wondering how straightforward it would be to translate your C# code back into the equivalent C++ code, link it against the native Irrlicht library, and integrate it with BotE.

I suspect the easiest approach would be to host the .NET CLR within BotE, run cdrwolfe's combat system from within the hosted CLR, and change the way the display device is handled such that you can just take the Direct3D handle used by Irrlicht and host that directly in one of your hWnds (as opposed to having it render to a separate Windows.Forms window).

@wolfe: In answer to your question, .DLL and .LIB files are the output generated by the compiler when building a library that will be used by another application. DirectX is an example of such a library--it's not an application on its own; it exists as a library of objects and functions intended for use by other programs. There are two ways of utilizing such a library. The first is to perform static linking at compile-time. This means that when you compile your application, the compiler automatically analyzes what code you're using from the library, and effectively rolls it up as a part of your application. This has a slight speed benefit, as you do not have to perform the linking at runtime. However, as a downside, you're stuck with the version of the library that you linked against when you compiled your app. Statically linked libraries are .LIB files. Alternatively, you can link dynamically to the library at runtime (to a .DLL file). In this case, the compiler simply validates your usage of the library against the provided header files (.h files). The library code is not loaded and hooked up to yours until you actually run the application. It does this every time you run, which is beneficial in cases where you may want to deploy updated versions of the library without having to ship a freshly compiled version of your own application. Just overwrite the existing .DLL, and (provided there are no breaking changes to the APIs that you are using), your application will automagically link against the new library version at runtime.