Warhammer Dark Omen Forum

So I thought I might start to make a post here now and then to tell you what I'm doing right now, and to show you that stuff are happening :)

* So currently I'm prototyping for how to represent worlds (that is, battlefields, or "theatres of war" as I prefer to call them, since that allows much more interesting and poetic naming of my classes). This might seem easy, but since WARTBED must accommodate a wide range of various RTT games, it requires a heavy amount of forethought.

* I'm also evaluating audio libraries for the framework. Also a rather arduous aspect since it requires so many trade-offs and will have significant repercussions later for the more stabilised platform.

* I'm unfortunately also trying to handle an apparently autistic editor (Alastairward) that is on a one-man crusade against the RTT genre on Wikipedia. If anyone would care to comment, you can have a look at the RTT article's talk page (http://en.wikipedia.org/wiki/Talk:Real-time_tactics) (he just tried to delete SotHR and recategorise it as RTS(!)), see his lovely correspondence with other people at his own talk pages (http://en.wikipedia.org/wiki/User_talk:Alastairward) (there are four archives with people can't believing he's for real), and the wikiquette case (http://en.wikipedia.org/wiki/Wikipedia:Wikiquette_alerts#Alastairward) raised against him (he raised one against me  (http://en.wikipedia.org/wiki/Wikipedia:Wikiquette_alerts#User:Miqademus)as revenge for commenting on his).

Ok, so I've been working on the world representation format and classes. I decided to architect this using good, powerful tools, and since I have been trying out the Boost::multi_index_container storage class I decided that is perfect. For those that don't know, it is a clever storage container that resembles a database in that it contains one set of data, but many predicate-ordered views into it.

As all things Boost, since it is done using pure TMP (template meta-programming) it comes with the prise of longer compile times. I took this, because of the power I'd get. Two days later, I discovered that the complexity I needed pushed the class beyond its capacity (it can only contain 20 views, and a world has many more classes of objects than this), and at that level comilation becomes prohibitively slow, around a minute for about 500 lines of code... Guess how much work is instantiated behind the scenes... O.o Also, the support structures for the Boost solution start to get large, and adding a view requires edits to about five or six different places.

So I've basically thrown away the "clever" way an am now rolling my own world supervisor class. This has halved the code, and the class works very elegantly all by itself without being surrounded by support struts.

Good lesson, in several ways: one the one hand, I learned some very advanced Boost magic, on the other hand, I learned enough to KISS.


Also, that battle against the autistic would-be destroyer of the RTT category at Wikipedia goes on. It is very very frustrating arguing against a person with Asperger's disease and plenty of free time. Also, KDE4.4 was just released: my Linux rig is prettier than ever!

This is a relatively technical post: skip it if you don't care about technical things.

A short talk about architecture, patterns and WARTBED. In "Implementing Patterns" Kent Beck wrote "patterns is where you want to be". Well, I've seen too much pattern-happiness to know that senseless application of patterns can be as destructive to code quality as being cavalier about structuring your work. Still, WARTBED uses patterns selectively and judiciously.

Most core classes that must be created only once are implemented as Singletons, and do so by specialising the wb::Singleton class so they will all have identical interfaces and functionality. The Model-View-Controller architecture is implemented in terms of the Observer pattern. And the classes used when issuing orders can be understood in terms of the Strategy pattern. These are all obvious applications of the patterns and help make the code clear and understandable.

However, due to the nature and intent of WARTBED, a seemingly simple thing such as loading graphics (actually, loading any perceptible resource) it is a little more tricky and messy. WARTBED is intended to work by a Client/Server architecture. Still we will only have one set of data. The server does not care about 3D models or sound effects, yet must have information relevant to it. Therefore, WARTBED defines a Theatre class (from "Theatre of War"), which represents the scene/world/map/level, and the archetypal contents constituting the world (the props in the scene). These props are all abstract (which means they are only descriptions without contents). WARTBED's Theatre module also defines a PropsFactory interface, with creation methods that returns (or rather, should return) scene props of the requested type.

You might be noticing the smell of an Abstract Factory pattern now, if so you've won a cookie. Yeah, this is an abstract factory. It has two implementations: first, the client implementation, which creates actual OGRE 3D (and whatever for sounds etc) objects; it is called the OgrePropsFactory class. Then we have the ServerPropsFactory, which generates objects with only the information the pure simulation cares about. But both the client and the server works through the same Theatre object.

Architectures like this takes longer to plan out and implement than gung-ho, happy-go-lucky coding would, but whereas the latter would be incrementally more costly to expand and maintain over time, a good architecture will possible be easier and faster to build on as time goes on.

I hope that you enjoyed, or at least weren't bored out of your socks, by this little walk-through of some of the design decisions in WARTBED! See you soon! :)

So, where are we now? :)

I have re-implemented full Dark Omen level loading (with placeholder graphics for particle effects). So Dark Omen maps are loadable and more importantly, manipulable! Basically, the map viewer is now also a potential level editor, though no interface or suchlike for editing has been added.

Unlike the old map viewer, this new one is implemented fully in terms of WARTBED classes, so there is no code waste. The parsers and loaders written will be directly usable both for a direct remake project as well as for the pure WARTBED project (the Bright Portents module).

Have had a few busy days with my job, so coding has been put on a very slow burner during this time. I hope to release something within the next few days, though ;)

can we discuss come points there? good thing to know new map editor will be realised!

are u using open source systems? maybe you should open source your own? or at least use some other guys technologies?

im not familiar with that but think it could help a lot.
there could be a possibilty we're arent alone there with Dark Omen mods :-)

my 2cents

Sure, feel free to ask and discuss. I'm a bit surprised no-one else has yet :)

So, to answer your questions: Yes, I am using other people's stuff. The 3D scene graph and rendering is done through OGRE 3D (open source). Audio will (probably) be done using Audiere or OpenAL/cAudio (both open source). Etc. WARTBED will be open sourced when I get to the point where it is meaningful to release the 0.1 "Clausewitz" version. The Dark Omen map viewer (and eventually editor) will be released earlier, but will link to a pre-compiled WARTBED library rather than the source files. All headers will be available.

If you haven't done so already, check our the WARTBED pages on the wiki (http://wiki.dark-omen.org/do/WARTBED)! The design document (http://wiki.dark-omen.org/do/Wartbed:Design) in particular will probably answer a lot of your questions. Also, you can add any well through-through suggestions to the WARTBED brainstorming page (http://wiki.dark-omen.org/do/Wartbed:Brainstorming).

Following all the various aspects of WARTBED on the wiki, is really great for learning how an RTT game engine fits together. Amazing progress, keep up the good work!

:)

So I have spent the last week ripping out CEGUI v 0.5.2, which was provided by default with OGRE 3D 1.6, and replacing it with the current trunk version 0.7.1. This move was relatively smooth sailing, meaning it only took two days :rolleyes: Which is exactly the very reason I hold to the policy of keeping external dependencies to a minimum. Otherwise I'd have to take punches like this on a regular bases rather than they being exceptions from normal development.

One of the main reasons I needed the new CEGUI version was that the 0.5 series didn't have a Tree widget, which I really really want in the Dark Omen map editor I am working on. So I upgraded and got the control I wanted. Or rather, I got a horrible hack of a control that is more suffering than mere pain. Crazy Eddie himself hates it and wants to replace it (some other guy had mashed a bloody ListBox widget with a mallet until it resembled a Tree control!), and it basically supports none of the functionality I or anyone else need for a proper editor interface. So I spent an additional five days or so trying to coax it into doing what I need. And today I have decided to let it just be decorative and get on with real coding until CEGUI is furbished with a real, usable Tree widget.

So that... slightly annoying distraction... has delayed the editor somewhat. It is coming, though: stay put and stay sharp.

so its going well?

It is going well. Because the architecture is now laid down so that all code that is written, even for the Dark Omen editor, also contributes to the goals of the project. That is, though the editor is a Dark Omen-specific tool, it is directly applicable to a Dark Omen remake as well as the Bright Portents WARTBED module.

That said, it is not going tremendously fast, since I'm doing this myself. I expect this to change when I release the source. Speaking of which, I am going to release the editor source along with the editor itself for you to do what you want with :)

 ;D thanks for spelling it out for me, this sounds very promissing, keep up the good work

As some of you know, the first alpha of the new map editor has been released. It is really a pre-alpha since many features aren't in place yet, but it features full loading of all Dark Omen maps, including animations and particle effects. No sounds or BG music etc are loaded yet, but all things that are part of a map are represented in (what will be) the level editor.

As all WARTBED-based applications, the level editor has a fully customisable input scheme - there's no aspect of the input system that can't be set and configured in the application configuration file. You can of course also set the app to use the input scheme of your preference: FPS controls, RTS controls, DO-style vector acceleration controls, etc etc, you name it.

The released version suffered from some setbacks. First CEGUI--the GUI solution--had to be upgraded so as to get access to a tree widget. Then this widget turned out buggy and almost unusable. Since release a slightly bug-fixed version has been provided by CrazyEddie, though, and the map editor now finally has a reasonably workable tree representation of the scene element hierarchy. Updates are released frequently from now on, and the source code will follow.

With the source code anyone can use this as the bases for a DO-related tool or even a remake project! More info to be had in the IRC channel.

Fantastic! I will look forward to replacing the All Maps pictures with your Map Viewer ones, as yours will be much better.

http://forum.dark-omen.org/maps/all-maps-t155.0.html (http://forum.dark-omen.org/maps/all-maps-t155.0.html)

Also since work has begun on creating our first Custom Mod Maps, previewing them will be alot easier.

Thanks bro,

:)

Mini-update, just for the kicks of it.

I have always been slightly concerned about the performance of the WARTBED/OGRE code. In the old renderer we saw frame rates of only about 15--30, and even though I knew that was due to the debug mode being extremely slow due to all sanity checks it was still disconcerting.

The new framework is set up so both debug and release builds are made, and the release builds happily steams on at a steady 60Hz, which is the vertical refresh rate of my screen. So today I finally rewrote the initialisation code to allow setting the vsync as well as reading the graphics constraints from a config file, and was pleasantly surprised with a healthy 800 fps in fullscreen 1024x768@32bpp mode :)

And now you have to program a benchmark, that does some nice Camera movements through the map ;).

I'll look forward to testing this latest version out, sounds wicked!

:)

wow Mikademus you really put much heart into it ;] keep up the great work

Short note: because of shortcomings with the camera system that became obviously unacceptable when the map editor was tested by others here I am rebuilding it. Relatively speaking, it is much smaller surgery than most others I've performed on the codebase lately, but I'm rather keen on this system working really well, and it revolves around some pretty specific OGRE wizardry so I'm taking my time with this one.

[Edit: rebuilding the camera system, that is]

The new Map viewer is really nice to use and has proved very usefull, when im previewing some of my early custom mod maps.

Thnx again!

:)

Short update so you know what's up.

Still working on fixing the camera. What was wrong with the previous system was that I was trying to avoid additional mathematics and low-level operations by using what is called a two-node camera system. In this I had one scene node containing the camera, and one node representing the focus of the camera (the "look-at point"), where the camera auto-tracked the focus. The reason for this system was to allow both FPS camera and orbit camera controls with the same camera class, and by using two nodes these modes are basically only a difference of changing which node you rotate. This was a simple and elegant system requiring minimal code on my part. However, due to the funky nature of OGRE's auto-tracking always defaulting to the [0,1,0] up vector for generating its world matrix, the camera had the two interesting flaws of (1) inverting the Y movement depending on whether looking to the positive or negative Z, and (2) interpolating the look vector toward [0,0,1] when Y was updated. Great fun...

So basically I had to switch to a more classic model where I calculate camera rotations. This is trivial for FPS control, and easy for orbit control, as long as you know the intersection point of the camera's look vector and the geometry (or easier put, "where you look at"). Unfortunately, OGRE, as the only render engine ever made, does not support raycasting to the polygon level. There has been some debate on the form about this which boils down to that everyone and their mothers thinks it should be there, but two vocal moderators have invested some kind of difficult to understand pride in their votes to the contrary, and have held up the feature for some two years.

Well, in all truth, there is support for this, but only against what is known as "static geometry", which is a special kind of pre-analysed geometry created by OGRE by feeding meshes to it. For some very strange reason, though, the Meshes made from Dark Omen maps causes this static geometry cooker to crash. The forum provides no help, as generally is the case with any interesting or difficult problem. So I have had to roll my own polygon-collision routine. This works, but also has revealed that something IS strange with the Dark Omen geometry, since only about half of the polygons of any given map will react to intersection tests. So I've tried to get help about what could be wrong with geometry, and gotten no response. See a pattern?

So basically, the camera system is actually working, but there are some outstanding issues which makes it not usable atm, and that are rather technical and OGRE-specific that has to be solved. This is complicated and to top it off real life has made some very tolling demands on me last week, and I haven't been able to put much work into solving these issues.

So there you have it. Quick update so you know things are moving along, and why this takes longer than I originally hoped it would.

Interesting problems and solutions, enjoyable to read and learn but sounds frustrating when facing Ogres' lack of support.

So glad I never learned to code

Good that I never programmed something that uses a 3D Engine :D. But maybe some of these problems are only Ogre related...

It's always interesting to read your stories about the wtf-moments in the Ogre Engine.

My favourite one for now is the story about the joke called "Tree Widget" in CEGUI.

what i understood its an OGRE. you're making OGRES to be playable in the game, right? :D

seriously though, not udnerstanding much of the problems you facing with. hope you can deal with it w/o much delay!

Heh, since OGRE 3D comes with a skinned and skeleton-animated ogre (the hallmark mascot) I will probably put it into a beta version :P

Don't worry if my explanations aren't understandable, I'm just telling what's up atm to say to you all that you're important and I want you to have some insight into progress/delays/whatever. The technical details are there as a bonus for those of that background or inclination :)

Double-posting, but this is MY THREAD and MY SUB-FORUM, so I can do that! Moahahahaaa....

Anyway, here are some screenshots to illustrate the problem. Basically, some polygons can be intersected with a raycast, while some cannot. All geometry should be correct, if nothing else simply because OGRE can render it! So I am quite confused...

Anyway, the green lines are successful intersections. But as you can see, the camera will not work on most of the map. This is something of a problem :(


Full render (view images for full size):
(http://img72.imageshack.us/img72/7459/mapnormal.jpg)

Wireframe:
(http://img227.imageshack.us/img227/2497/mapwireframe.jpg)


New thread at the OGRE forum (http://www.ogre3d.org/forums/viewtopic.php?f=2&t=57158)

A picture paints a thousand words, thnx

but what a horrible problem, since - as you say it renders the whole scene, so why can't it raycast the whole scene.

Hm the wireframe reminds me of the official map editor.

I wonder in the thread who Keemossi is ;).

Now B2T:
This looks like a booooooorrrring debugging job.

It's strange that there isn't any logic because even in the ray casting part are just some parts of the map not casting.
But the pond does work completly...

Does the working terrain has some special properties that are slightly different in all other parts?
How is the result on nearly flat maps like Spare9?

I am starting to think is is related to materials, of all things! Or perhaps vertex batches, since they're organised by texture in the BASE.M3D file. It is strange, though, since the water is one model, but the pond and river tributary probably have different batched. Anyway, both B1_04 and SPARE9 really show that there is some kind of correlation between materials and ray intersections:

(http://img441.imageshack.us/img441/6291/map4normal.jpg)
(http://img10.imageshack.us/img10/9646/map30normal.jpg)

A possible good test would be if i sent u my Empty Spare9 Mod map that I'm working on, where I have overwritten all textures to be grass but left their names intact. So the original Circle01 texture is still called Circle01 but its texture is now the same as NFLGRS01.

(http://img532.imageshack.us/img532/5688/bestspare.jpg) (http://img532.imageshack.us/i/bestspare.jpg/)

Or I can send you my own 10x10 Flat extra Terrain Block to test

(http://img35.imageshack.us/img35/6163/best2j.jpg) (http://img35.imageshack.us/i/best2j.jpg/)

:)

The empty map would be a good test, please mail me it! Tnx mate! :)

Still no answers in the ogre board to an interesting question, sounds familiar to me :)

Any luck with those Tutorial Map Textures I sent you, Mikademus?

:)

Yeah, big thanks! I have just now (30 minutes ago) isolated the problem! When you load geometry you create a "Mesh" object. Any Mesh is always attached to an Entity, and consists of sub-meshes, one for each material used. What isn't explained is that every SubMesh is in turn associated with an automatically created SubEntity. When asking for the Mesh of an Entity that consists of many sub-objects, the first SubEntity is implicitly returned but in a way that appears to be the top object. And the ray-checking code only checks the Entity. So it will only intersect with the first material! I hope this sounds fucked up, because it is totally bizarre that no-one has documented this or replied in my help request threads!  >:( Friggin' absurd I should have to spend weeks figuring this out by myself!

I am now looking into how to get around this. I wish the OGRE community would be more helpful... :(

One week since my last post. I am still working on the same bloody problem. I am so fed up with the OGRE community, they are the bloody worst I've ever come across! The only questions you'll get an answer to are total n00b ones, like "what are manual objects", to which some wannabie can safely reply "it is in the docs". Any more difficult question will never be answered. I just want to WAAAAAGH!-rush them!

So I have to solve this manually in other ways, which means mathematics. And I'm not terrible good at it, so it is slow going.

you are my heroe mika, you are..

and our Saviour,

Our hearts go out to you- and we share your pain/frustration.

:)

Wow. Three weeks it took! Now the problem is solved. A friendly guy from another forum I hang out at helped me, and I managed to solve it. The OGRE code was buggy, and no-one at the OGRE community helped me whatsoever, so I am little pissed with them right now. I actually got one answer, basically saying "it was a difficult problem, so nobody want to help".

Anyway, now that that is taken care of I can get back on track. Expect more regular updates again. Also, expect me in the channel again, since I have intentionally stayed away so as not to get sidetracked or vent my frustration on you guys!

haha you are such a gentleman

Glad to hear you're back on track and look forward to seeing you in the Channel and more developments to WARTBED

:)

Thanks mate :) I want to push by this traverse, then things will get rolling again.

any update? :-)

I'm working together with some guys on what will hopefully be a commercial project atm. However, all code I write with the intention of using it in WARTBED so when things happen, a lot will come at once.

I was pretty burned out a while ago when working at WB since first of all I worked at a maniacal pace, and secondly when I ran into a problem with OGRE nobody helped me or believed me when I identified a bug in OGRE, which I then had to solve for myself. It took a month to do so, and wass all kinds of frustrating hell. And when I finally solved it nobody thanked me. So yeah, that sapped so much motivation. I'm still bitter about it...

Nonetheless, I appreciate you asking because that increases the likelihood of a release sooner rather than later ;)

:) i will always wait for you, always, yours.

Thanks Brapus, I honesty admire and appreciate all you guys' patience! Currently I'm down with a cold and no voice and am thinking quite a bit about what tools could be made to help Olly's current efforts!

Hope you get over the cold soon and any new tools would be greatly appreciated, although I really don't mind using our existing individual Apps, as they are producing some really cool results. Top of my wishlist would be a Base.M3D to Base.M3X converter to improve stability as I'm simply just renaming my Base Terrain models from .m3d to .m3x and finding some crashes on other players' machines.

Height maps seem to extend into infinity, that works to our advantage as not being restricted to simple flat map extensions but now I can follow the contours into extended territory. My next step is dropping all this new Furniture that myself and my hired artists have been producing, (Church, Castles, Houses) and to use Rob's BTB to XML Tool, that will allow me to create my own Data Blocks for creating a Radius around new 3d models to block movement and missiles passing through them. In my Beta test i simply grab and enlarge an existing Tree's Radius and set it around a new House. Combined with your excellent Text Map Editor, i also set ex_walk and other Boundaries. Its really all coming together now and when the new Mod Map is completed it will provide a perfect place to start adding our own AI Scripts, thanks to all the latest OpCodes that have been discovered!

Back to WARTBED and tell us of the other project, if it not too Top Secret.

:)
 

Oh, it is not secret at all :) It is an attempt to write a tactical wargame for casual gamers. Though the engine is actually really tactically rich the goal is to mask this and create an extremely easy-to-use interface so we can sell it perhaps even to soccer mums. And as I mentioned before, I try to make everything in such a way that all code written have direct relevance for WARTBED. F.i. I've just written a complex sprite module for multi-direction animations, which can be plugged almost directly into it.

About M3D to M3X: I think they must have used a tool to manage the conversion of those, because the divided version is really structured in how it is disassembled. Let's look at it together later!

    Since you are very slow, maybe you could team up with somebody talented who makes online games. I know that they are usually garbage, but games such as gemcraft  and Sonny were done by talented enough people. Maybe you could help make them their own games, in exchange for help.
    Also if you are thinking that you can't make money on Dark Omen, make you could read the "www.lostgarden.com/2009/07/flash-love-letter-2009-part-1.html (http://www.lostgarden.com/2009/07/flash-love-letter-2009-part-1.html)" article. It's talking about making money on online games.
    In any case, please report us on your progress. I'm new to this forum.

Hi and welcome to the forum!

I agree that lately I have been very slow, and I apologise for that. I would happily team up with people that could help move the project along at a faster pace! It seems that to get people to join you you first need to hit a critical mass, and then things start to roll. See Spring and Glest for instance - it took them years before they achieved their momentum. I am afraid that I'd have to join other's projects rather than have them help with me, and that would simply siphon away even more time from Dark Omen-related stuff.

That development went on at a rapid pace previously was because I was actually unemployed and spend most of my time on developing the project. The last year I have however been employed full-time and have not had much spare time and I've had to portion the little I did had between family and projects.

That said, nothing is dead or still - every line of code I make is made with WARTBED in mind--no exaggeration!--and if things follow my plan things will start moving ahead.

I deeply appreciate your honest opinions and sincere suggestions! :)

It will all naturally evolve and come together, as prophesied in the Ancient Stone Tablets.

I believe and Worship WARTBED!

:)

lets give time to the time :)

Ok, so to reboot some discussion here, this is what you will see in the next release:

* Full map loading of all DO maps with all visual effects and animations
* Terrain-colliding camera with RTS/Orbit/DO/FPS modes
* All DO sprites and animations renderable

These are done and only need to be plugged in together. The aspect I had most problems with before the hiatus (due to work, being alienated by the horrible support from the OGRE community, and being burned out) was the camera: it is a very tricky and technical aspect, and you can often see even full-price AAA titles with really dysfunctional or outright awful cameras.

Now what I want to know is what is on you guys' wishlists? What do YOU most want to see in the coming version of the engine? :) I'd really like to know!

Sounds Great, I will investigate over the weekend and let you know.

Thanks

:)

Thanks for letting us know.
I don't know if it was ever discussed, but I always wanted to be able to use buildings and castles in Dark Omen.
It would also greatly help, if we were able to save our deployment before starting the battle. It would great reduce the time needed, and reduce the frustration after a failure significantly.

Added as http://wiki.dark-omen.org/do/Wartbed:Power_goals#Engine_bonus_capabilities (http://"[url=http://wiki.dark-omen.org/do/Wartbed:Power_goals#Engine_bonus_capabilities)"]bonus power goals[/url]


Good suggestion! Please feel free to add it to the http://wiki.dark-omen.org/do/Wartbed:Brainstorming (http://"[url=http://wiki.dark-omen.org/do/Wartbed:Brainstorming)"]brainstorming page[/url]!

Time for some good news!

Lately I have taken time off my commercial projects and pulled some strings to invest in bringing WARTBED forward. This has paid off.

The two stumbling blocks that have kept WARTBED from moving on have been (a) that OGRE's own geometry intersection code didn't work and I had to fix it myself which took a long time and much frustration, and (2) that a versatile camera that intrinsically is capable of RTS, FPS and orbit/Dark Omen styles was very complicated to implement under Ogre.

Both these problems have now been solved. The camera took a guy with a doctorate in maths to fix but hey, now it works very sweetly indeed!

Therefore, expect a new map viewer any day, and work on the map editor will go on.

Further, on a personal note, I now have academic credits in Old English (AD 400--1130). O.o

Fantastic News! It sounds like the most complicated problem i've ever known, to take that kinda Brain Power to solve.

Congrats on Qualifications as well.

I can't wait to test the new Map Viewer!

:)

so any demonstration to show? like darkmancer's movie or something

Oh you sceptical people :)

You will not get a movie, you will get the executable itself.

Although making demo movies sounds like an interesting idea, I could perhaps make those and present on my youtube channel to show new features... Thanks for the idea! :)

Works Brilliantly! I love the new Camera Restrictions, so it can't rotate freely above and below ground and the camera also checks for collision with the ground.

(http://img823.imageshack.us/img823/6558/mapviewer2.jpg) (http://img823.imageshack.us/i/mapviewer2.jpg/)

(http://img842.imageshack.us/img842/6876/mapviewer3.png) (http://img842.imageshack.us/i/mapviewer3.png/)

(http://img412.imageshack.us/img412/48/mapviewer4.png) (http://img412.imageshack.us/i/mapviewer4.png/)

Nice Advanced Smoke Particles, can't wait to explore further!

Thanks

:)

Great :) Can't wait for more

uh well... can wait for more!

jesus crist man! mika you are the coolest person i ever known, even more cooler than olly :O :O :O: O but dont worry olly, you are 2nd place haha (L) goood workkkk demus

Oh, I only realised TODAY that there were replies in this thread! O.o Thanks guys for the positive comments! The current version would be available for download and testing if I could bludgeon Olly into uploading it to the dark-omen FTP :)

To tie in with the topic of this thread, I am currently testing different solutions for the network layer. At this time I am coding a simple lobby in Boost AISO atm to evaluate it as a good package for wartbed.

I've sent you an Email for your FTP login access.

Keep up the good work!

:)

Download link for the curious:

Dark Omen Map Viewer 0.7.5 (http://www.dark-omen.org/Dark_Omen_Map_Viewer_0.7.5.rar)

Note that there is no fancy installer here, so you will have to edit the "cfg/dark omen map viewer.config" file manually to set your Dark Omen game path.

The map viewer crashes here after startup :/.

Logfile:
Log started at Sat Feb 19 14:39:31 2011
-----------------------------------------------------------------------------
14:39:33 [debug  ]> Valid battle 0: D:/Spiele/Dark Omen/GameData/1pbat/SPARE9/
END OF FILE

The lnk files have the working dir set to the resource directory.
Plugin[_d].cfg ist set to the bin[_d] directory
And in Dark Omen Map Viewer.config the root path is set to D:/Spiele/Dark Omen

Oh yeah, sorry. You need to edit the shortcut files in the install folder.

My shortcut files has the "start in" property set to "E:\Development\[ WARTBED ]\resources", and you need your to reflect your own path, for instance "c:\chthulu\Dark Omen Map Viewer\resources", if that is where you installed it.

Yes, thats what I meant with:

But in the meanwhile I found the error reason: I remembered a problem that was happening in your Cli Editor "SPAARTAn": It doesnt find map dirs that have the ntfs compression enabled.
And the same happens with your map editor: It only reports the maps where the folder (and its content) is uncompressed. No idea what api you use to transverse directories but in my opinion this is a bug. Please try to fix this, I use ntfs compression to save a lot of space because of the gigantic bitmaps and hundreds of do mods ;).

Thanks for the info Ghabry! I use pure STL streams for file access with maximal cross-platform compatibility, which should work with any file system. That said, NTFS is MS-specific and its specifications has never been published, and Visual Studio's STL is MS-implemented so one would think that MS's STL would be able to handle MS's tweaks to its own NTFS.

The point is that while I will look into it this might actually be a bug in the MS libraries and as such outside of something I can do anything about. I trust that you can turn off compression on the Dark Omen folders meanwhile?

Wow Mika nice project as i see from screens (maybe i will look today at it, you know program cause little time now). It's possible to see source of it or some tips on PM about progrmaming? :P

I'm willing to give you all the tips you want on programming :) Feel free to PM me, or make a thread here if you want to let other people also share in on the discussion. We can discuss the map viewer code there.

Much of the code is actually already available since it uses the PrjParser and BtbParser classes (named after the two most important files for a battle: the .PRJ (PRoJect) and .BTB (BaTtle Boundaries) files). These classes are f.i. used in the CLIEditor (Command LIne) and Ghabry's WH32Edit.

;) good to see you are active , yet .

Salutes Mika

Good day.
I'm a fan of DO too.
So how is going with remake?

Hi! I'm a fellow DO fan.

I wanted to know if you're still working on the project; in case I may be able to lend a hand. I have some knowledge of programming, although not much spare time :/

later,
Stefano

Hi,

I'm a DO fan too, and I'm sad that there was more news about wartbed.
Is there any release of source code on a platform github guy? svn? a lost ftp?

cordially

Only Mikademus could release all his source (C++ in Ogre 3d) but perhaps Crash can help as he has been using part of it, the Map Viewer ->

http://forum.dark-omen.org/tools/map-viewer-questions-t1195.0.html (http://forum.dark-omen.org/tools/map-viewer-questions-t1195.0.html)

http://www.mediafire.com/download/50b6lblc86hzjur/Dark+Omen+Map+Viewer+0.7.5.zip (http://www.mediafire.com/download/50b6lblc86hzjur/Dark+Omen+Map+Viewer+0.7.5.zip)

(Extract into C:\Program Files\Dark Omen folder and run in Windows XP Sp2 compatibility mode for Win 8.1

:)