Well everything is finished and uploaded and yay and woo. Downloads aren't online yet and will stay down until such time as an external mirror comes up so that we don't just run our server into the ground as has been done before.

Spent frigging ages tonight with Kizza trying to get his awesome windmill working in his map - turns out rotating movers is something that unreal just really hates. So instead, the windmill is static for this release. Boo, hiss, meh.

Looks as though I accidentally deleted a couple of these posts with a database backup, im pretty sure all they were was me saying 'fixed some bugs here now i will list them'. Nothing you really couldn't miss.

I've spent the last week on and off going over the last few things that needed to be done to get the core of the mod in a finished and working state.
Today Michael and I got together and combined our efforts, and touched up some of the more 'topional extra' things and stuck those in.

I've fixed all of the important bugs. That's right, all of them. Replication on spawn effects, rope slipping in 2D games, awful memory leaks that made the game progressively slow down and roll/crouch combo bugs are all a thing of the past.

The both of us then added in all the flair such as loading screens, gametype screenshots etc. The mod is done.

Oh, the other cool thing I added was an alternate skin system for the ropes which allows new designs to be added in very easily. At the moment we have standard brown rope, steel cable and vine variants. These are extremely easy to use from the point of view of the map editor.

Got a suggestion from a fan today re. teleport effects which I have now implemented.

Basically, I've changed the effect so that on 2D maps, teleporting and spawning are both accompanied by a bright pink beam that shoots up from your player's head into the sky. This makes it much easier to locate your player, especially on fixed camera 2D maps where the view is zoomed out a long way.

This beam only shows up for the player who teleported, so it cannot be used as a position giveaway by other players.

Michael and I got together again today to finish up the last of the bugs. All the weapons are 100% working now, although the weasel's AI still needs some tuning.

I also added in a credits page to the main menu. It's empty at the moment, but I'll get around to it.

Today was a big day for the mod in terms of publicity. I finished adding in some more animations, sounds and most importantly character models to the mod.

Now that all the characters we plan to create are implemented, it is time for us to pass the baton on to the community. The character creation tutorial has officially been started, being publicised at the following locations:

BeyondUnreal Forums
Atari Community
Planet Unreal
Beyond Unreal

Now I guess we can just sit back and wait for some awesome models to roll our way.

Spent the last few hours testing some multiplayer action and fixing up all the bugs it bought forward. Here's a list:

- Changed 'crouch' in menus to 'roll/crouch'
- Players colliding while rolling now bounce properly
- Air instability only happens with other players, or when hitting a wall with sufficient power and at the right angle
- View never gets stuck when rolling now
- Made pickups slower and easier to get
- Network clients can now pickup weapons after losing all their ammo on an old one
- HUD bug with icon not disappearing when weapon does fixed
- Rope velocity not replicating resulting in sliding for clients fixed
- Kills are now awarded when players push someone, they fall, then roll, then fall and die (FIDS)

Spent some time today playing with our first map and trying to make it more playable and less, well, crap.

It's moved on from a test map to something that I think we can be proud of and hopefully release along with the mod.

Also added in the full animation set for the shield. Bam.

Today's race for work manages to see me now almost finished with my work on the project. The only things remaining to do are maps, which Chris will be principally handling, and the code for the puck, weasel and bots which Michael will be doing. So I'm almost done.

I spent a long time adding in solid new features like pickup pictures to the game options screen and pickups to the level query string. So now players will be able to see what pickups are active before joining a match. Neat, eh?

I then spent an equally long time polishing the smaller details of the mod. I put in about half the sounds Liam has sent me, added in some more animations from Kieran.
Then there were other details like fixing the overexposed colouring on characters, fixing the shading on the net pickup, changing the falling and drowning death messages to read 'FIDS!' and stuff like that.

The other important thing I did was changed the mine to how we initially envisioned it. Now it doesn't go off straight away, instead it beeps loudly and uncloaks. The player is pretty much screwed after this, but it's funny to see. If they stand off the mine, it will explode and kill them then.

Today we worked from around 10 in the morning and I'm about ready to stop now.

For the first hours of the day we did a major go-over and bugfix on all our leftover network bugs. I personally fixed up the net animation and firing problems, weasel graphics and shield blocking of projectiles.

A long-dormant bug where players would be able to keep bouncing into each other has been significantly reduced and should now happen only very, very rarely. I also fixed up the lighting on characters so that their textures have more definition now.

Rolling is now fully implemented along with animations. I've also added 'stable' and 'unstable' midair animations so that players have a good visual cue for determining what will happen when they land (stable = land squarely, unstable = roll).

However, the major part of the night for me was implementing our HUD, which I am now quite pleased with. We've tried to keep it as clean as possible, and so it consists only of an indicator to show the currently active weapon. This is all 3D and spinny because I know it looks much cooler that way.

I've posted a shot of the HUD and a character in the midst of rolling, here.

Getting into the final stint of work on our first beta.

Tonight's effort was rolling. I believe I'm about finished with it now, pretty much all the subtleties of it are working perfectly which is just great. Animations aren't done yet but I can tell it's going to look awesome.

The player's avatar doesnt rotate when rolling, which makes things much like in MDuel1. I've also stopped it rotating when crouched for the same reason. Purely aesthetic but nice to look at.

One of the interesting problems that came up with rolling was the ability to get stuck really easily. Since you can't move when crouched and normally can't roll from a crouching position, it was easy to roll under low-hanging objects and get stuck. So of course now players can roll more than once if theyre unable to get up. This could make some interesting maps, as rolling is a slight bit faster than running.

I also added in another nice visual cue to show instability in the air. When you first jump you will look in control, but as soon as another object is bumped into the player starts looking a little spastic. This is a nice cue for knowing what is going to happen to you when you land, as an unstable player will roll upon landing.

The other problem rolling brought in was with the placeable weapons like mine and puck. Since these auto-crouch when fired, they would force the player to roll which wasn't what I was really after. This is fixed now.

Also fixed up some bugs in the 2D player classes and modified the jumping back to normal 'straight up and down' style because testers were finding it difficult.

With the semester drawing to a close, it's getting around to the time where we're going to have to start work on the mod again.

Allow me to be the first to break this long period of delay with some new models for the other heads of the original Marshmallow Duel characters:



We're also planning on starting our MDuel character creation competition very soon. I'm currently patching up the development tutorial and getting hold of all the resources I need to compile a dev kit. When it's ready, full details will be announced on the main page.

Over the last 48 or so hours I've spent my time getting the more difficult animations, like rope climbing and the net 'curled into a ball' animation, ingame.

Weapon animations for the gun, magnet firing loop, grenade throw, boomerang throw and catch, grapple throw and catch, and the placing animations for all placed weapons are working fine and attached to their respective weapons with no problems.

I also fixed some earlier problems with the blank weapon wrecking up some animations and the placeable weapons not forcing you to crouch (an oversight only really).

The rope animations are particularly cool as they are played depending on the speed of climbing. So climbing up very fast produces a faster animation that slow climbing and makes it generally look much nicer.

The net animation was particularly difficult to do as clients werent fond of playing the animation at all. I ended up replicating a variable for it and telling the clients explicitly whether they should be playing it or not.

I just finished the first version of my awesome system to allow weapons to control third person pawn animations.

By default, UT doesnt allow this sort of behaviour, so adding it in makes things much more fantastic in terms of the whole 3rd person experience.

Each weapon is free to replace as many or few of the default animations for the characters as needed. So for example, the shield may need to include new runcycles, crouching cycles etc to look nice. The animation system Ive done today allows this extremely easily by simply changing default properties on each weapon.

Ive put a new build online with Kieran's animations included and set to work with the respective weapons that they are meant for. The gun in particular looks extremely awesome.

The other major thing I did today was modify the rope code somewhat to give greater freedom with them. From now on, players will not touch ropes at all unless they tap their jump or crouch button whilst near them. This is particularly relevant in 2D where players getting knocked at ropes would catch them automatically before. Now some skill is required to not end up FIDs.

Other fixes today:
- Smash platforms now default to 60sec hidden instead of 20.
- Fixed array out of bounds in pickup spawner when game is played with no pickups active.

Fixed cameras are now completely working for the 2D gametype, and look just awesome. The process of adding them to maps if desired is extremely easy and intuitive for the mapper.

Basically, all they need to do is position their viewport camera in the right place for where they want to view the map from ingame. Then it is a simple matter of placing a fixedCamera2D actor in the same place and rotation, and the code handles the rest.

One of the best features of this system is that the camera can be placed in any position or rotation, meaning that the mapper can choose to view their map from cool perspective views as well as straight on 2D.

I also had a big spree of fixing all the little bugs we had left over with different weapons. Here they are:

- puck doesnt bounce out of screen in 2D
- grapple dies if it hits a volume
- magnet fixed for client/server
- net works properly
- added acceleration dampner to pickupBases
- fixed projectile rotation for mine, hook, puck and net
- projectile meshes for boomerang and hook added
- parachut visibility problems fixed
- magnet fx now disappear if the pickup being pulled times out and dies
- Dunce Cap made, and fixed character head - position slightly to fit

In the ingame images section you can see some nice pictures of the new magnet weapon, which I am starting to think is the coolest addition we have made to mduel.

The functionality of the magnet was mostly done by Michael, but to summarise, it basically draws in a pickup you are pointing it at or steals one from another player. The trick is that it also draws in all the pickups around the player very slowly, so you have to be careful not to draw in something nasty.

The magnet FX and weapon attachment were both completed by myself and I am very happy with the way they are both looking. I also spent a lot of time creating effects for the pickups to play when being pulled by the magnet which look really cool, especially since they are scaled by the magnet's influence over them.

Pickup bases have been modified to decelerate when over their maximum speed - this prevents the magnet from filling the level with pickups whizzing to fast to catch.

I fixed up various bugs with the map entities, basically the pickup spawners no longer have issues with rotation and also face in the proper direction.

If you are pushed by someone and then touch a rope, they will no longer get the credit for killing you if you fall from said rope into the marshmallows without touching the ground first.

Oh! I also did some work on the net and managed to get it working pretty well. It holds players in place until they are pushed and works perfectly if they are on the ground. If hit in the air, there are still some client/server issues to work out - the player will keep moving serverside but freeze on the clients, which is of course not very good.

This was a bit of an afterthought so I'm just going to make another post.

I just this minute made a long-overdue update to the website that allows team members to add comments to the images they post which will show up to outside visitors when they view each image.

Hopefully now we can have a bit more explanation on each shot that really gives the full impact.

Ok so my contribution over the last 48 hours was mainly the new character model with a classic style.
I was working again in a very polygonal and geometric style, using Chris' early concept sketches. The final model is ingame now, although the textures are not yet completed. The shot shown here is using a rough texture to give the basic idea.



This model will of course be colour configurable later on.

I also redid the UV maps for the weasel since Chris was having a lot of trouble with the old ones. There was all sorts of horrible overlapping seams etc present, I think I must have been in a hurry when I did it the first time around.

As for weapon stuff, the shield is all coded and works pretty well. There's still odd bugs where projectiles clip through occaisonally, but I hope to have that fixed soon. I'm pretty proud of my netcode for the shield as it works as a separate entity from the player, but has no movement jitter on clients as normally happens with that sort of thing.

I delved into getting all the finished pickup models ingame and wrote some nifty attachment code to handle unique things like the parachute's attachment to the players chest (instead of hands as is the norm). The grenade, mine, puck, net, shield and parachute are all now graphically final and feature the correct models. The gun also has an attachment now but still needs a firing animation.

So that's basically what I've got done on the weekend. There are still quite a few outstanding bugs with those weapons which I hope to squash pretty soon. After that I can get optional fixed cameras working for the 2D game mode and focus on more low-level stuff like getting pickups to appear in the level info string so that anyone joining a game can see what's included.

So it seems that the nasty big memory leak bug we were having was due to my stupid respawn effect.

It used to rip shaders off your body and place them in materialSequences to gradually eliminate seemingly random chunks of texture - an effect that looked a bit like a pixel wipe. But it wasn't very good.

So basically I got rid of that whole bunch of uselessness and instead made a much cooler deres effect. This one uses some very nice vector maths and coordinate translation to detach all staticMesh body parts from your body in the exact same place as they were before being detached. It then spawns some cool red particles all over the body parts and disappears them. I'll probably end up changing the effect again at some point, but the main feature this style has is that it doesn't hog memory and wreck up the game.

For maybe the first time since we started this project, I'm sitting around feeling like there's nothing much for me to be doing. All the big bugs have been squashed and all the weapons I was responsible for are implemented and working perfectly reasonably.

I might get into an attempt at randomly generating levels later on but it seems like too much of a big thing to work on at the moment. I suppose I could start making character models, but I hate modelling a lot these days.

Screenshots have been piling up a bit over the last few days, so here's some pretty pics of the hook and respawn effects in action..



Oh, I also went ahead and imported all my models into the game, ready for the textures they will be getting tomorrow. I animated the weasel nicely but the lightwave->unreal exporter I'm using didn't like it so he just wiggles in a silly way at the moment. Looks hilarious. Might even keep it in.

I had another day of implementing weapons and getting all their FX as close to completion as I can without having access to finished staticMesh objects.

The boomerang was patched up a bit and now works in 2D gamemodes, allowing you to throw it up and down as well as out in front of you.

The grappling hook is finished as well and looks really good. It has a wavy rope that arcs out behind it until it hits something, after which the rope becomes taught and you are dragged towards it.

The 'chut is also finished and working fine. It doesn't look like anything yet though since the parachute itself isnt textured ingame yet.

I also went over the code for the destroyable platforms and changed it a bit to facilitate platforms interaction with projectile weaponry. Weapons such as the mine and grappling hook are much more realistic now as they actually land on the platforms, and fall down from them if they are destroyed.

Michael and I had a big coding session today, working at getting a more stable codebase for the pickups down and then making lots more of them.

The boot is now ingame and works really well - it gives a speed increase when equipped and makes huge jumps when fired.
The 1000V also features a speed increase, much less noticeable than the boot however. This is simply to make it harder to evade, as there are really no edges to make things difficult in a 3D environment.

Pickups have been modified to die out at random intervals, a very important element as when playing with skulls, TNT or anything else undesireable, the map just ends up filling with them if they don't die out after a bit. There is a game option to scale the average lifetime of pickups as well.

The boomerang is ingame and I am extremely happy with the way it is working right now. You have a certain degree of control over it when in the air, so you can steer it towards your opponent. It then returns to you if it has hit a wall or player.

The warp dynamically builds a list of all possible bot navigation points in the level and uses those as spawn targets, so it can never spawn you in stupid places unless the mapmaker things it would be funny to do so.

The mine is also looking pretty great. This was mostly Michael's work but I had a little to do with it at the end. You even crouch when placing it.
Having the mine done is fantastic, as it lays the foundation for how all the other projectile based pickups will work, such as grenade, puck and even weasel.

Today was a good day. I got rope climbing working very well. There is even now animation helping code so that the player always faces the rope whilst climbing on it. Nifty!

Getting the ropes to work properly turned out to be a huge piece of work. It turned out after all the torment and anguish that the problem was in-engine. Apparently if you change the collision size of an object, its drawScale reverts to default (?!). So a quick replication fix from server to client was needed to rectify that inadequacy.

I did up some models for all the 'classic' ingame objects, such as platforms, pickup spawners and all that jazz. Chris added some quick textures which look quite wonderful already.

Erm, what else? Fixed up the TNT so that it always destroys what it hits (there was a problem before with really large platforms - their registration points were outside the TNT blast radius and they would not die if hit near the edge). Fixed up the invisibility a bit so that the server and client can never get out of sync with it.

Here's a nice picture of the platforms and rope object all together. It's starting to look like Marshmallow Duel now.

I spent so many damned hours today trying to fix the simplest bug. For some reason, when you start a new 2D game with no pickups AFTER starting one without, it simply ignores your decision and spawns the last pickup set. Very strange.

Anyway I couldnt find any reason for it at all, so in the end I just did an ugly hack and made a flag to set against that sort of thing. It makes me feel dirty, but it works.

Also made weapons destroy themselves and replace with the blank mduel weapon dummy when out of ammo - this prevents things like the gun's view restriction staying in place after you have exhausted it.

There's also a major memork leak somewhere in the mod that I've been unsuccessfully trying to track down. It seems to afflict the 2D gametypes much more severely. Something isn't being properly destroyed when you die - every time your character respawns it costs you around 5 or 10 fps. I'm hoping to track this down and have it fixed before I put a new mod build online.

So, it took about 10 or 15 hours to make rope cimbing work like it's supposed to in 2D games.

The major problem was making objects think they're colliding when in fact they aren't. If you think about sidescrolling games, you have ladders that sort of sit in the background. You can walk straight through them if you feel like it, or you can stop and climb them. So I needed my mduel climbing ropes to let players pass through them most of the time, but climb up at certain times.

I spent hours upon hours after I had the initial collision working (not something a 3D engine is good at doing) tweaking the feel of the connection and difficulty of the climb to try and get something nice working.

As it stands now, I'm pretty happy. If you're walking along the ground, you can walk straight through a rope as if it isn't there. If you want to climb one, you press and hold your jump key to glide up it gracefully (there's no animation yet, of course). Jumping into a rope comes with a certain degree of 'stickiness' to make it easier to catch them. They're fairly thin, after all. If you jump into a rope and let go of all your keys, youll stick to it perfectly and can then use jump/duck to move up/down it. If you need to jump but aren't interested in the rope, just keep holding forwards and youll kick right through it. You can also use them to get extra boosts of height if you hold jump AND forward whilst moving through them. Overall, very awesome little inventions.

They're easy to use for mapmakers too. You can just drop them in like any other actor, scaling them both horizontally (but why would you) and vertically as needed. They need to be of roughly equal width and length to work effectively, but any height is fine. You can even use custom staticMeshes as ladders, but you need to enter the width and height of the mesh manually or they won't work very well.

I spent another few hours going back over the 2D player class to implement all the stuff I'd done for the 3D games with regards to ladders. 2D feels very nice now, you can slide up and down the ladders between platforms without much trouble at all. There were also a few visual bugs in the crosshair and related stuff hanging around the 2D arena, which I managed to fix up.

I did probably too much work today. Spent this morning playing with collision and trying to make an object that you can walk through, but also climb up. I've gotten pretty close, but I suspect the engine won't allow this sort of thing so I might have to stop trying and be happy with ropes that you just touch to climb up.

I also finally got around to fixing up the telefragging problem we were having much earlier on. Since player/player collision is turned off for some things to allow players to, say, trip through each other, turning it back on again could sometimes end up with people inside each other and one person getting randomly killed. This is now fixed, instead players just get bounced like normal. Oh, I also added a tiny bit of air control, because I think the game probably needs it.

I then moved on to weapons because I was sick of all that. I fixed up a lot of base class code that is needed to make things work like being unable to fire unless standing (or in the air for some other weapons).

The weapons that I've finished are the 1000V, invisibility, gun, TNT and skull. Invisibility was probably the hardest to coordinate between client and server, but it works fine now. I made pretty FX for the 1000V pickup, and also went ahead and made some other cool rez and derez effects for the floating pickups themselves. The TNT has a cool explosion when it blows up ground too. I think thats all. Oh wait, the gun is awesome because you can't aim up or down. That required far too much effort. But well worth it.

Here's a picture of some FX. And a new build of the mod with all this stuff in it is now online.

Michael and I went over a lot of stuff today, and I believe now that I have finished fixing all the small problems with the game up to this point.

We also started creating code for the weapons - the skull and TNT now work entirely properly and more weapons are coming soon.

Here's a list of everything I can remember fixing, because it would once again be too much effort to talk indepth about each thing:

Keybinds are cleaned up and don't show useless buttons anymore.

Players in 2D games have been fixed so that they have a mesh now.

Bots now have a mesh, which is inherited from the server player's current character configuration.

Pickup bases are properly removed.

Added game option to choose whether platforms respawn or not.

Added pickup sets to quickly choose none, shareware, registered or all.

Added pickup multiplier so that the number of pickups generated can be customised.

I also played with gamespeed and gravity a bit to try and get rid of the 'floaty' feel of the jumping in UT. Nothing seemed to particularly work though and it all felt a bit wierd. Perhaps we will end up just leaving it alone.

This morning I quickly fixed up a couple more things.

I made a huge improvement in the netcode for the pickups. They use only about half the bandwith they were using before now. Basically I've made it so they never try to tell each other about their rotation properties, since its irrelevant to the gameplay and just looks cool.

Also added some stuff to the platforms so that they can now be told to never respawn. It might be an idea to add in a game option to force all platforms to never respawn, actually. Just an idea.

Today has been really good to me in the form of getting those niggling little things working that have been plaguing me for months.

So here's a list:

- Pickups no longer bounce off platforms, they clip straight through like in mduel.
- Pickups bounce off level killzones (ie marshmallow) instead of dying.
- Players all appear perfectly to all other players without delay.
- Platforms now destroy and appear properly for all clients. This includes starting off invisible if a player joins midgame when they are dead.
- Platforms now explode in a cool way instead of from a point, so that elongated platform meshes will explode nicely.
- Added platform appear and disappear sounds.

Its certainly a big update, so a new build is now online for team members to use.

Dont mind the title, it's a running joke that nobody gets.

Today I got some good work in on the destructible platforms code. I've created platform objects that map makers can assign any mesh and scale to and simply place in their maps in the same way as staticMeshes. The amount of time for each platform to wait until respawning is also configurable by the mapmaker. They even get lit properly!

So far it all looks great - I've added in some awesome particle effects that are only temporary but still work pretty well. Here's a timelapse picture of the whole process (respawn time was very low for testing because waiting is tedious).

Replication for this is a slight bit difficult, since the visibility of objects is never passed across by the engine unless you tell it to. At the moment, the server is fine but the clients still see the platforms even when they're supposed to be invisible. Nothing I can't fix up when I next get the time to though.

The character system now works and replicates stuff between clients all very nicely.
The only thing it doesnt do 100% is working for listenservers - characters inherit the server's style for the first spawn, but then after dying everything is fine, so it isn't that much of a problem.

Anyway, this means that the character design system is going ahead, and we can start encouraging others to start making their own stuff. Oh, and we can do it too.

I've moved all the code for handling player limb selection into the mod's PlayerReplicationInfo now, so that it is constantly visible to the server and all clients throughout a match.

I've also reworked the method of storing said data so that it uses static arrays and variables instead of dynamic arrays, which we all now know don't replicate properly, if at all.

Point to all this being -it's all ready to test online and that another day or so of work with 2 computers to test with should yield successful results; and people can get started on making custom characters.

Michael and I had a bit of a go-over of all the code today and got a lot of small bugs sorted out.

Replication of the player's colour works fine for clients only, now. If youre playing on a listenserver theres still problems for some reason.

A few things need to be reworked to get everything working online.. replicated player selection variables need to be moved from pawn over to playerReplicationInfo for one (you CANT have global stuff in pawn, because it gets destroyed when you die and everything goes back to defaults).

Also need to completely rewrite the player selection arrays. Since dynamic arrays (the cool way im using now) arent replicated properly, its going to have to be done with boring old static array stuff to replicate alright.

I've spent the last couple of days fixing up small bugs in the character creation system and writing a HUGE tutorial (about 20 pages I think) on character creation for MD:MR.

The plan is to get some animation students to check over it and make sure its informative enough, then release it out to the general UT public so that anyone who's interested can start making cool stuff for the mod when it's released.

When it all gets vitoed we'll have it online for interested modellers to do stuff with (no animation is required, yey!).

Here's a fun function:
 

static function Array<Material> FindStaticMeshSkins(StaticMesh aMesh)

{

    local int iPointer, i, iCutOff;

    local string sParseString, sTextureClass, MaterialsPropText;

    local array<Material> SkinArray;

    //local class<object> sClassPlaceholder;


    MaterialsPropText = aMesh.GetPropertyText("Materials");


    // This is the max number of iterations currently allowed for this loop. (to avoid an unlikely infinite recursion)

    iCutOff = 128;


    i = 0;


    for (iPointer = InStr(MaterialsPropText, ",Material="); iPointer != -1 && i < iCutOff; iPointer = InStr(MaterialsPropText, ",Material="))

    {

        sParseString = Mid(MaterialsPropText, iPointer + 10);

        iPointer = InStr(sParseString, "'");

        sTextureClass = Left(sParseString, iPointer);


        //sClassPlaceholder = class<object>(DynamicLoadObject(sTextureClass, class'Class'));

        //SetPropertyText("sClassPlaceholder", sTextureClass);


        sParseString = Mid(MaterialsPropText, iPointer + 1);

        iPointer = InStr(sParseString, "'");

        sParseString = Mid(sParseString, iPointer + 1);

        iPointer = InStr(sParseString, "'");


        // Cut off the parsed section of MaterialsPropText so that it will go onto the next section during the next iteration. (otherwise infinite recursion)

        MaterialsPropText = Mid(sParseString, iPointer + 1);

        sParseString = Left(sParseString, iPointer);


        SkinArray[i] = Material(DynamicLoadObject(sParseString, Class'Material'));


        i++;

    }


    Return SkinArray;

}

 
What it DOES is to work out what materials are being used on a StaticMesh. The engine doesn't support doing that by default. The code is based on work by shambler, and because of it I've now got a working player custom colours system happening.



Today I also started working on making all your limbs fall apart in random directions when you die, because I thought it would be a cool use of karma physics. So far everything is ok, except that the damn things won't collide with anything. Having them fall straight through the ground isn't that spectacular, so I might work more on it later or just get rid of the effect. It's not that essential.

Yesterday I got the geometry of a proper character model from Michael Lane.

So, I've converted the model into static objects for use in Marshmallow Duel:MR. He looks pretty awesome ingame, the style seems to fit alright even if he isn't quite an MDuel character. Anyway I've had a test with him and here's some screenshots of different parts of him working with the other test objects. Its all only temporary.. the robot might make it into the final game, he might not. We'll see.

Ok well the main thing of news for today is the character designer, I've redone it much cooler and made a proper interface for it so that it isn't horrendously dodgy and difficult to use.

Here's a pic. This is probably going to be the final design for it, or something similar anyway.

Also today I added in some stuff thanks to player input from body check. The game now comes with a choice between a high and low detail crosshair, in case the high detail one slows down your computer too much. I fiddled with the high detail one as well to make it less angry for framerate. An 8fps decrease due to crosshair seemed a bit ridiculous.
I also added a camera offset option, so that players can position their camera to the left and right of their player. This is completely configurable and good news for the people who were pissed off about not being able to see things directly in front of them.

Ok so I've got things moving along pretty well now, players can select body parts independently of each other to combine into their own horrendous character creations.

Some problems are sure to come up with replicating the data to clients and all that stuff, but for now I'm happy to have this much done so I'm just going to temporarily ignore it. I'm going to be talking to some 3D artists on the weekend, and hopefully they will be interested enough in what I have done so far to start making some custom dueler pieces.

The GUI to set all this up is really dodgy at the moment, but here's a screenshot anyway since it shows the level of customisation I am talking about:



Here is the result of this character selection ingame. I apologise deeply for the horrendous modelling and texturing, but at this stage I am more about getting function down rather than form. Let the 3D artists worry about that.



I should also mention that the character colouring system I was hoping on will have to be a no-go for the moment. Obtaining a reference to the textures used on a staticMesh is next to impossible.

I've made some good progress on the character design menu. Basically, at this stage it is fully capable of reading and writing all the data necessary for players to select custom body parts for their characters.

Of very awesome and important news is the fact that I am using the game's INT system to load in character set data dynamically. This means that third party modellers can create their own body sets and import them straight into the game - nothing has to be hardcoded into the mod itself.

Basically, I see this process as going like follows:
1. Modeler makes their own player torso and custom animations if they want. This is then set up with a defined skeleton with specific bone names.
2. Modeler makes custom limb objects. These are simple staticMeshes, and can be a full limb set or some subset of that, so for example releasing a body set that only adds a new head is quite fine.
3. Modeler fills out a simple class file of the following template:
 

class whatever extends duelerInfo;


defaultProperties

{

    attachmentActors(0) =StaticMesh''

    attachmentActors(1) =StaticMesh''

    attachmentActors(2) =StaticMesh''

    attachmentActors(3) =StaticMesh''

    attachmentActors(4) =StaticMesh''

    attachmentActors(5) =StaticMesh''

    attachmentActors(6) =StaticMesh''

    attachmentActors(7) =StaticMesh''

    attachmentActors(8) =StaticMesh''

    attachmentActors(9) =StaticMesh''

    attachmentActors(10)=StaticMesh''

    attachmentActors(11)=StaticMesh''

    attachmentActors(12)=StaticMesh''

    attachmentActors(13)=StaticMesh''

    attachmentActors(14)=StaticMesh''


    SetName="Cubic Lad"

}

 
Where attachmentActors defines all the staticMesh objects that will be applied to each limb (there is a certain system to this); and SetName is simply the name of this body set to be displayed in menus.

4. Modeler compiles this class to their own *.U package to be distributed along with their animation and staticMesh package. They then create an *.INT file with the following format:
 

[Public]

Object=(Name=myPack.myClass,Class=Class,MetaClass=mduelGame.duelerInfo)

 
This is filled in with the path to the file created in step 3.

Now the game will automatically detect their custom player models and add them into the menus as flawlessly as with the core player models.

Pretty cool, eh?

Today I spent a long, long time making sure that absolutely everything I've done so far works correctly. It didnt. But it does now.

I discovered the horrors of native replication - basically, we can't use a subclass of 'pickup' for our moving pickups, since the pickups has native replication that ignores all its movement data. Obviously, epic thought pickups would never need to move. Not to worry, my new pickup class does the job just fine.

Also added in some things I've been meaning to do for ages.. You now spawn with a blank weapon which does nothing - not only does this stop bots generating runtime warnings, it also makes them much more aggressive since they think they have a melee weapon in their hand. Finally, they are using some sort of extremely limited 'push bad guys off the edge' logic. You can also only hold a single weapon at a time now - as soon as you pick up a new pickup, whatever is in your hand will evaporate. yey. Oh and jump height is increased slightly, since Michael was dubious it was high enough.

New version online in dev files now.

Ok, its done.
Havent tested client/server things yet but that stuff should hopefully be pretty fine.

Anyway the game options menu has all the options in it that are needed, at least I imagine at the moment. They all take effect immediately and seem to work fine. Ive moved most of the options from the 'player' screen over to the 'game' screen, to make room for all the menu stuff we will need to let people build their characters limb by limb.

Motion blur is optional, camera smoothing is scalable, character transparency is toggleable. The crosshair is finished and its colour and size can be customised. It also toggles off and on. It looks pretty cool, especially when you move it fast - you get a nice blurred line from it as it smudges across the screen.

Im pretty happy with the colour slider for the crosshair. It takes only a single slider to do things - using hue instead of separate sliders for red, green and blue. Here's the fun code to convert from a single hue value to RGB values for rendering fun:
 

function color hsl2rgb(float hue)

{

 local float red, green, blue, saturation, light;

 local float tmpred, tmpgreen, tmpblue;

 local float tmp1, tmp2;

 local color retv;


 hue /= 256.0;

 saturation = 1.0;

 light = 0.5;


  tmp2 = (light + saturation) - (light * saturation);


  tmp1 = 2 * light - tmp2;

  tmpred = hue + 1.0 / 3.0;


  if(tmpred > 1)

   tmpred -= 1;


  tmpgreen = hue;

  tmpblue = hue - 1.0 / 3.0;


  if(tmpblue < 0)

   tmpblue += 1;


  /* red */

  if(tmpred < 1.0 / 6.0)

   red = tmp1 + (tmp2 - tmp1) * 6.0 * tmpred;

  else if(tmpred < 0.5)

   red = tmp2;

  else if(tmpred < 2.0 / 3.0)

   red = tmp1 + (tmp2 - tmp1) * ((2.0 / 3.0) - tmpred) * 6.0;

  else

   red = tmp1;


  /* green */

  if(tmpgreen < 1.0 / 6.0)

   green = tmp1 + (tmp2 - tmp1) * 6.0 * tmpgreen;

  else if(tmpgreen < 0.5)

   green = tmp2;

  else if(tmpgreen < 2.0 / 3.0)

   green = tmp1 + (tmp2 - tmp1) * ((2.0 / 3.0) - tmpgreen) * 6.0;

  else

   green = tmp1;


  /* blue */

  if(tmpblue < 1.0 / 6.0)

   blue = tmp1 + (tmp2 - tmp1) * 6.0 * tmpblue;

  else if(tmpblue < 0.5)

   blue = tmp2;

  else if(tmpblue < 2.0 / 3.0)

   blue = tmp1 + (tmp2 - tmp1) * ((2.0 / 3.0) - tmpblue) * 6.0;

  else

   blue = tmp1;


 retv.R = red * 255;

 retv.G = green * 255;

 retv.B = blue * 255;


 //log("COLOR IS: " $ retv.R $ " " $ retv.G $ " " $ retv.B);


 return retv;

}

 

I've started putting in the backend of the GUI. There's a simple and efficient interface now for users to set their client side options.

So far, the following things are configurable and perfectly functional:
- Motion Blur
- Amount of camera smoothing
- Transparency for characters when chase camera is close to them

I also fixed up some bugs with motion blur and camera smoothing not working correctly in some rare cases.

I've had some help from a Marshmallow Duel fan on our forums, who let me know the actual font used in Mduel.

I've since taken the bitmap font and painstakingly converted it into a vector-based truetype font so that we can use it for whatever publicity stuff, and can use it in place of the standard UT2004 fonts.

The font can be downloaded from the mduel classic site as before. Here's a link to a preview image that shows all the characters.

I spent many hours today sorting out all the GUI code I needed to do. I also finalised some menu graphics and made the main menu look much more polished.

This is what the main menu looks like at the moment:

Note that pretty much all of it is animated in some way, which adds a bit of interest and makes things look cool. It still needs something extra, I have an idea what this will be, but I can't do anything with it until we get more texturing done.

You'll notice the nice mduel styled font used there - this is a custom font I spent some time creating. It's usable in all parts of the interface. Yey. I tried to make it as close to the original font used in Marshmallow Duel as possible. Here's a quick screen grab of the charset.

You can download this font from the mduel classic website, incidentally, under the 'Fan Stuff' section.

The last (very awesome and important) thing of note is that I have successfully coded the GUI routines to handle our pickup management system. I've used the same screen as the mutators screen, since its much the same
idea.
Now that I know how to do this, adding in our own customisation options (already coded in, but no interface for them yet) will be quick and easy.

Anyway, this screen has successfully been tested, and the pickup range selected is most definitely used in the game. Very cool.

Oh yeah..
Bugs to fix later:
- GUIController isnt loaded on my brothers PC and the game crashes. No idea why this is but I sure hope it isnt widespread.
- Motion blur will stay active when you die, until you get a new weapon. Wierd.

I've started working on the functionality and basic layout of the GUI, since parts of it are required to build an interface to set up our custom game settings pages, plus it would be cool to get it working since its a big visual part of the mod.

I spent the last few hours working on getting a custom font ingame. Finally success, with a few hacks along the way to make the engine comply with me. So, I present to you.. DOS font inside UT2004!:



Since it was a bit of an effort, and since everybody else seems to be doing it by initialising for each GUIcomponent (which is a lot of extra effort and pain, believe me), here's the code to load in the custom font groups over the top of the defaults.

 

//force load our new awesome DOS fonts

function Initialize()

{

    Super.Initialize();

    updateMduelFonts();

}


//delete the default UT fonts and replace them with DOS console fonts

function updateMduelFonts()

{

    FontStack.Remove(0,11);        //delete all the old font entries

    RegisterFont(class'mduelGUI.fon_mduelMenu');

    //keep going to add more of your new custom fonts. If you give them the same name as the ones they are overriding, there should be no problem.

}


//this registers the custom fonts in this GUI controller, since it is usually done natively, write my own.

function bool RegisterFont(class<GUIFont> FontClass)

{

    local GUIFont NewFont;


    if (FontClass != None)

    {

        NewFont = new FontClass;


        if (NewFont == None)

            Return false;


        // Check that we haven't already loaded it

        if (GetMenuFont(NewFont.KeyName) != None)

            Return false;


        FontStack[FontStack.Length] = NewFont;

        NewFont.Controller = self;

        return true;

    }

    return false;

}

 

Did a bit of setting up today for the rest of the week's work. Basically I added a dynamic list on our coremost gametype that tells the game which pickups to spawn.

Users can configure which pickups to include much like the mutator config menu in UT2004. This hasn't been done yet but its a simple case of GUI coding to do so.

The other thing I am excited about having working is servers reporting which weapons are active. At the moment I have all the active weapon data being passed out to the server string, so it should be simple to display this info much as mutator info is displayed for UT.

Our moving pickups now work as subclasses of Pickup, which makes things like getting bots to recognise them and getting weapons to spawn from them a ton easier. Of course these things were sort of working before, but this way we are using the code that we know for certain works, anyway.

The pickup spawning objects are also different, they now work under the 'InventorySpot' class, which means they will have embedded navigational data in them for bots to work off.

That's all for now.

I spent a few boobless hours today trying to get the bots to follow the floating marshmallow pickups. It was pretty difficult to get anything to happen without confusing myself entirely, so I just gave up after a bit. Michael can have fun with this later.

I did, however, work out how to spawn custom bots using a mutator only, which will be great for testing later.

EDIT:
I tried again today, with some fancy code I was proud of that makes the bots recognise the pickups as inventoryPoints. This seemed to help a little, since they now follow pickups occaisonally (very occaisonaly), but they mostly just give up the hunt after a second or two. I should probably give up on this stuff.

I was fiddling around with emitters, and I came up with this, quite by accident:



I think it looks very marshmallow, maybe a bit more interesting than plain purple globs. We will make some sort of decision later, anyway.

Today Michael and I got together and combined the work we have been doing over the last week or so.

There were quite a few bugs that needed to be ironed out when we put everything together but everything is pretty much fine now. We tested our pickup code by creating rocket launcher pickups that fly around the map as you would expect. The number of pickups to spawn for each generator is even configurable for mappers. Naturally, we stuffed around with that a bit:



As you can see, I also made a quick emitter to stick on the weapons, which I actually think looks quite nice in retrospect.

I fixed up a couple of things with our 2D gametype, and luckily all the work we have done so far ports straight over to 2D without any fuss. Here's a shot of pickups and motion blur in the 2D game.



After getting everything working, I put a new internal build online for the rest of the team. Some package dependency problems were also addressed (if only the UT2004 makefiles would work bi-directionally).

The basic movement code for mduel characters is now finished. Rolling still needs to be implemented, but until we get some custom animations going I will probably leave it. Most of my errors were not my fault (ModifyVelocity does WIERD stuff), so im happy.

The new third person view system with smooth camer also works really nicely.

To celebrate, I've released 'Body Check', a small (~9KB) mutator that implements most of the movement functionality. Players can push each other around, just like in Marshmallow Duel. Scoring is done correctly for when players push each other off the map (yay! that was tricky!). Different movement combinations also have different effects on the outcome. Here's a screenshot:



I have also included motion blur for when the weapons fire, just as something extra and cool that I thought might be nice. Here's a shot of that:

Today I managed to get players to bounce off each other without error. The key was to flag them as needing a kick and then waiting until the end of calculations for that tick to execute it.

If you dont do that, each player will execute slightly out of sync and interpret the other's position and state incorrectly, leading to problems. But that's fixed now. Luckily the ModifyVelocity() function in pawn is called very last (after velocity and acceleration have been updated, but before location has). So I used that.

So the bouncing happens without error, however the amount of bouncing does not. You can bet money on the fact that players will end up being thrown all over the map with about twice as much momentum as they should. Still working on the cause of this, hopefully I will work it out soon.

But not too soon, because I'm going to get drunk now.

Ive spent the better part of today getting mduel style player pushing going. All the code for doing that is working well, and I've also got players to bounce off walls without any troubles.

However, the really horrendous logic nightmare is the part where I have to decide HOW to move each player, based on their current state (standing, in the air, rolling, crouching and running) and their rotation.

I almost had things working once but now it appears that my problems lie in lag and client side functions, as they frequently prove to do.

It seems that momentum is being applied to one player before the other when they collide, which does not exactly work well since they calculate what the other player is doing differently each time.

I'll try some more tomorrow.

Started the player movement code today. So far I have implemented:

- cooler jumping (you push off on an angle if you jump from an angled surface now)
- removed double jumping and dodging
- misc movement speed tweaks
- cannot move while crouching
- no air control
- players don't drop their weapon when killed (this does not work for bots yet as they arent being replaced by the new pawn class - this will be fixed when we add our own bot classes in)
- Game is always played in 3rd person

I have also coded in a nice smooth 3rd person camera that moves to the side when you strafe and other nice effects that stop your body getting in the way. Here's the code for it (because its easy to cut and paste into your own 3rd person mod, and i dont care if you do):
 

Event PlayerCalcView(out actor ViewActor, out vector CameraLocation, out rotator CameraRotation)

{

    local vector vCameraNormal;

  local vector vHeadLoc; // The place the camera will come across when the pawn is up against a wall

  local vector vHitLoc, vHitNormal;

  local Actor aHitActor;

  local int averageOver, i;


    //force players to use 3rd person view

    bBehindView = true;


    //super.PlayerCalcView(ViewActor, CameraLocation, CameraRotation);


    //only do special camera if we have a view target

  if (Pawn != none)

  {

      // Start out at the Pawn's location and a bit above the center of the model

      vHeadLoc = Pawn.Location;

      vHeadLoc.Z += nCameraHeight;

      vHeadLoc = vHeadLoc - fHeadChaseDistance * vector(Rotation);


      // Get a normal to the camera rotation and move it back nChaseDistance units

      vCameraNormal = nChaseDistance * vector(Rotation);


      CameraLocation = vHeadLoc - vCameraNormal;

      CameraRotation = Rotation;


      aHitActor = Trace(vHitLoc, vHitNormal, CameraLocation, vHeadLoc, true);


      // Move the camera slightly away from the wall so you don't clip through it

      if (aHitActor != none)

          CameraLocation = vHitLoc + vHitNormal*10;


      // filter camera position

        CameraHistory[NextHistorySlot] = CameraLocation;

        NextHistorySlot++;

        if(bHistoryWarmup)

            averageOver = NextHistorySlot;

        else

            averageOver = FilterFrames;

        CameraLocation = vect(0, 0, 0);

        for(i=0; i<averageOver; i++)

            CameraLocation += CameraHistory[i];

        CameraLocation /= float(averageOver);

        if(NextHistorySlot == FilterFrames)

        {

            NextHistorySlot = 0;

            bHistoryWarmup=false;

        }

    }

    else Super.PlayerCalcView(ViewActor, CameraLocation, CameraRotation);


  return;

}

 
That's all for now. In the next few days I would like to add a cool crosshair (I was thinking something like that nice blur effect from Alice), some code to implement rolling and other frills.

From there on, it's adding the 'bouncing' elements that are so critical to the game.

Oh yes, there's a new version of the internal mod build online as well because there were some badly named folders that the compiler really didn't like. I've removed our test maps from the archive this time since theyre pretty large, and you can put them back by just copying 2D and DM maps from UT and renaming them.

Been working all day on finishing up all the 3D work for the pickups. All 18 of them are in a final kind of stage now as far as 3D work goes (yes I said 19 before but I was confused).

The most complicated was of course the weasel, since it requires animation and rigging as well as your basic modelling required for all the others. I thought it might be nice to put a render or two of it online since I'm fairly happy with it.

So, all the pickup meshes are done and UV mapped, just waiting for textures. You can see all of them here as a quick render. Some you can't really tell what they are yet, but the addition of textures will help with that later on.

The cool evolution style image of the weasel's progress is here.

I just went over the website quickly and got rid of the 'discussion' section - it serves no real purpose other than to confuse things now that we have a forum up and running.

I also rebuilt the mod framework, added in some templates for new packages and quickly fleshed out the basics for some new classes we really need.

I'm just about to reorganise the dev team area of the forum as well, but for everyone else this is irrelevant news.

Also discovered a bug in our dev file upload script that can't really be fixed. Apparently PHP is running in safe mode and won't allow uploads that exceed some timeout - had to upload the latest dev build (about 1MB) manually.

I've spent the last couple of days doing 3D models for the pickups, based on the concept sketches Chris has uploaded.

So far I've finished all 14 Chris has sketched so far, hopefully once he gets the other 5 drawn I can go through and do those.

I'll have some renders of them (untextured) up when this happens.

Version 4 is out. This one will be the final one if nobody has any problems with it. Dedicated servers run fine for me now, so hopefully that will propagate to everyone else.

I also converted the aforementioned incompatible maps from the old UT2003 mod, smashU2k3, across to be compatible with SoldatUT.

There was nothing much to it at all, simply deleting a few items from the levels which referenced the old packages from said mod.

Now there are no less than 13 new maps for SoldatUT. A couple have issues with my camera (as compared to the one from smashU2k3), but the rest play just perfectly.

I know I said i wasn't going to work on this anymore, but the annoying bug that crashes servers still wasn't fixed.

I talked to some people who run servers and it turns out the bug only happened on dedicated servers (i usually test with a listenserver).

So, I set up a dedicated and spent the last hour or so patching up the nasty bug that crashes the game.

Everything seems to be working perfectly fine now, so I'm just doing some quick tests on fans servers to make sure of the stability before I release a (this time) final version.

With this done, it means that all the bugs are ironed out of the 2D code we need for MD:MR.

Who would have thought that a couple of

if (NetMode != NM_DedicatedServer)

conditionals could make so much difference.

I'm now going to try and convert some other incompatible 2D maps from an old UT2003 mod over to SoldatUT at a player's request.

Today I fixed up much of the bugs in the vehicle and turret code for SoldatUT, and I am confident that it is at the stage where it can be released publicly.

This will be the last release of SoldatUT before MD:MR is released. It is getting to the stage now where all the elements that will be included in the final 2D gametype for MD:MR are working properly, and the only additions that can be made are specifically for UT.

I have no wish to divert from the development of our primary mod, so I am leaving SoldatUT as is. If anyone out there wants to develop and fix it further they are more than welcome to the source code.

The new version is on the files page, and I also added a couple of screenshots to show off the vehicle action.

I'm sending off emails and forum posts about the release as I write this, spreading the word and making people aware of our existence.

The latest update in the sidescrolling nightmare that is my life: Vehicles are working fine in 2D, and replicating between servers and clients properly.

I always hated replication, and the last day has been nothing particularly new. Moved quite a few functions from my input class over into the playerController class so that they can be sent across the network, and stuff like that. Here's an example of the code needed to get the clients to tell the server where they are aiming:
 

function doVehiclePawn(rotator controllerRotation)

{

    local float temp;

    local int i;


    if (ONSAttackCraft(Pawn) != none)

    {

        temp = controllerRotation.Pitch;

        controllerRotation.Pitch = controllerRotation.Yaw;

        controllerRotation.Yaw = temp;

        controllerRotation.Pitch -= Pawn.Rotation.Yaw;

        controllerRotation.Yaw *= -1;

    }

    else

        controllerRotation.Yaw -= Pawn.Rotation.Yaw;


    for(i=0;i<ONSVehicle(Pawn).Weapons.Length;i++)

        ONSVehicle(Pawn).Weapons[i].CurrentAim = controllerRotation;

}

 
Reasonably basic stuff but its the horrible vector maths required in order to get all those values that really gives me a headache. The code for passenger weapons requires all sorts of nasty juggling of skeletal parameters and stuff like that.

Vehicle weapons now work properly, meaning that they point in the right direction (across, instead of into, the screen). Also the vehicle movement is feeling quite natural in terms of reversing direction.

The code I have done so far has been with the intent of keeping things modular so that you don't need to change much from the UT2004 base vehicles to get them to work in 2D. A simple subclass with a couple of overloaded functions is all that is needed. Consequently, there are some things that are a bit of a hack, like variables that switch between two different values in the same tick. This is fine offline, but in multiplayer, opponents vehicle weapons have a tendency to flicker.

They still work fine though, so who am I to judge. When we get around to creating our own mduel vehicles, we will be doing most of them from the ground up - so we can do the code right at the lower levels instead of hacking vehicle stuff to keep modularity.

So, 2 things left to do for the next release of SoldatUT - fix up the crosshair and stop it crashing the game, and either fix up the invasion HUD or get rid of it.

I'm also waiting on some new maps before I release.

I have spent the last two agonising days trying to get vehicles to work in a 2D gametype. I figure we will probably want to do this later on at some stage, so why not perfect it early?

Anyway, I have mostly finished getting them working in a 2D Onslaught gametype for the next version of SoldatUT (luckily, some community members made me some 2D Onslaught maps!)

Basically, after all the hiccups fiddling with Karma physics parameters to stop the vehicles rotation on 2 axes, making new map volumes to push them away from the edges of the map, doing horrible hacky things with resetting their physics modes, etc etc etc, I have finally got it all working through the relatively easy method of adding Karma impulses to the vehicles when they move off course.

Damn, I wish vehicles were as easy to move as players are.

Here's the code that does it all (AbsoluteY is set on spawn as the object's initial Y position)


simulated function KApplyForce(out vector Force, out vector Torque)
{
Super.KApplyForce(Force, Torque);

if (AbsoluteY != Location.Y) //deviations
{
Force += vect(0,1,0.2) * 100 * VehicleMass * (AbsoluteY - Location.Y);
//scale by distance from ideal point and vehicle mass
}
}


Since this involves extending the vehicle classes that are already there, I have made it expandable by putting an INI file in the game system directory to set which 2D vehicle class replaces the corresponding 3D class. This file is a simple array list which holds all the necessary data:


[SoldatUTv3.Mut2D]
ONSVehicleClasses=(sFactoryClass="Onslaught.ONSAttackCraftFactory",sNewClass=class'SoldatUTv3.Veh_2DRaptor')
ONSVehicleClasses=(sFactoryClass="Onslaught.ONSHoverCraftFactory",sNewClass=class'SoldatUTv3.Veh_2DManta')
ONSVehicleClasses=(sFactoryClass="Onslaught.ONSTankFactory",sNewClass=class'SoldatUTv3.Veh_2DGoliath')


The best thing is, you can even use this to dynamically set which vehicles to have in your maps. Woo.

Here's a screenshot of a working 2D hellbender:

I have spent the last few days exchanging emails with the creators of Marshmallow Duel, who will henceforth be referred to as Nigel and Llewelyn Bruce for the fun of it.

They are very excited about our project and building our website's community, and have offered us some fantastic content.

Nigel has provided us with another game by him (Thieves), and also the source code to Marshmallow Duel! We will be using this at a later date to extend and improve upon the original hit game!

They will both also be doing an interview with us in the future - be ready fans! All you ever wanted to know about MDuel is coming!

Earlier today I reorganised the forum with more thought to generating discussion - not just about MD:MR, but about the original MDuel as well.
The new structure invites more community members to get involved and invite their friends, so that we can make the MDuel community stronger every day.
I also tied together the MD:MR and MDuel1 websites with much the same ideas in mind - the MDuel1 site has undergone a major overhaul to make it more readable and efficient, and both sites link to each other at the top of the page, so nobody will miss it.
I also changed some forum code to add links to both sites at the top - just in case anybody breezing through misses it.

Why, you ask? I have been furiously exchanging emails with Duncan Gill (the creator of Marshmallow Duel) lately, and he is very excited about MD:MR and building an Mduel community. The tying together of MD:MR and MDuel1 should provide a much stronger community, and the reorganisation of the forums leaves lots of room for discussion and community support.

Just a brief update.. I did a proper logo for the mod. A larger version of this image in PNG format can be found here.

I also added some new sections to the forum for team members so that we can keep a log of all the legal correspondence we get, and also keep track of emails and other community feedback.

Ive implemented unrealscript syntax hilighting in our journals section, so that we can post code segments easily, retaining colouring and formatting. You can have a look at my post before this one to see the effect.

This is for journals only, since we will probably never need to do so in the news section, and putting it on the discussion section opens up too many security holes.

I've included a utility page for team members where you can paste your code and have it automatically formatted for easy inclusion in your journal posts.

I also uploaded a new build of the mod so far to the dev files section, along with full source as usual. Team members please feel free to look over this and get comfortable with what I have done so far. This build includes some extra batch files to perform other useful tasks, such as client/server testing.

The last few days have been spent collating bug reports and concerns from community members and fixing up various issues with the test 2D gametype.

Of main concern were stuttering bugs with online play - which turned out to actually be due to a lack of errors. The inventory class I had adopted from k0lpa's 2D tournament was making heavy use of the 'Instigator' property, which was not actually set for this class. I had changed them all to Owner, since this was set. However it seems that this code is not supposed to come across for clients (Instigator worked locally in this instance, for reasons i wont get into), so the old way, that spits out error after error into the UT2004 log file, was the way to go.

I fixed up a random death error by removing all clipping between players - this makes sense anyway since there is less room to get around each other in 2D. Tightened up the camera lag so that it isn't a bad thing on slower computers. I also added some more useful features - made the lightning gun zoom a bit more useful by making it not only increase the view range, but also zoom the view out more. To do this, I made modifications to the playerCalcView function which is automatically called by the local player controller object:

 

function PlayerCalcView(out actor ViewActor, out vector CameraLocation, out rotator CameraRotation )

{

    local rotator controllerRotation;

    local vector tempCamLocation;

    local int i, averageOver;

    // camera , control a pawn **********************************************************


    CameraRotation = rotator(vect(0,-1,0));


    controllerRotation = Owner.Rotation;


    tempCamLocation.X = ViewActor.Location.X;

    tempCamLocation.Z = ViewActor.Location.Z;

    tempCamLocation.X += CursorLocation.X/2;

    tempCamLocation.Z += CursorLocation.Z/2;

    tempCamLocation.Z += 200;                                    //stop low floor on terrain maps etc


    //scale Z pos (zoom) of camera based on FOVangle for zooming weapons

    tempCamLocation.Y = (Owner.CameraDesiredLocation*0.85) + ViewActor.Location.Y +

                                            ((Owner.DefaultFOV / Owner.DesiredFOV) * Owner.CameraDesiredLocation * 0.15);


    if (Pawn(ViewActor) != none)

    {

        tempCamLocation += Pawn(ViewActor).EyePosition();

        PawnLocation = ViewActor.Location + Pawn(ViewActor).EyePosition();

    }

    else {

        tempCamLocation.Z += 175;    //good value for a guess?

        PawnLocation = ViewActor.Location;

        PawnLocation.Z += 175;

    }


    tempCamLocation += Owner.GetZoomOffset();

    Owner.FovAngle = Owner.DefaultFOV;


    //average camera pos over the last FilterFrames frames to provide smoother view

    CameraHistory[NextHistorySlot] = tempCamLocation;

    NextHistorySlot++;

    if(bHistoryWarmup)

        averageOver = NextHistorySlot;

    else

        averageOver = FilterFrames;

    tempCamLocation = vect(0, 0, 0);

    for(i=0; i<averageOver; i++)

        tempCamLocation += CameraHistory[i];

    tempCamLocation /= float(averageOver);

    if(NextHistorySlot == FilterFrames)

    {

        NextHistorySlot = 0;

        bHistoryWarmup=false;

    }

    CameraLocation = tempCamLocation;

}

 

I also overrode the raw player input so that the buttons which usually control forward/backward movement could be used for jumping and ducking, since they are now defunct. A listing on the unrealWiki for the different keyboard input names was most helpful. This revision makes things easier for players as they do not have to reconfigure their keys for a more natural setup when playing UT in 2D. Essentially, I am just overriding the raw inputs:

 

// movements ****************************************************************

Owner.aBaseX = 0;


//reset these so that jump/duck can be pressed again

if (Owner.aBaseY == 0)

{

    bJustJumped = false;

    bJustDucked = false;

    Owner.bDuck = 0;            //needs to be reset manually

}


//intercept forward/backward for jump/duck

if( Owner.aBaseY > 0 && !bJustJumped)

{

    Owner.bPressedJump = true;

    Owner.aUp = 6000;                    //this sets us up for jumping detection later

    bJustJumped = true;

}

if( Owner.aBaseY < 0 && !bJustDucked)

{

    Owner.bDuck = 1;

  bJustDucked = true;

}


Owner.aBaseY = GetTurned() * 6000 * -Owner.aStrafe;


// Jumping *******************************************************************

if (Owner.aUp > 0 && Owner.bPressedJump)

{

    if (xPawn(Owner.Pawn) != none)

    {

                //set Z velocity to 0 if multijumping is alright, this way we can multijump whenever

                //(not just at the peak of a jump)

        if (xPawn(Owner.Pawn).MultiJumpRemaining > 0)

        {

            Owner.Pawn.Velocity.Z = 0;

        }

    }

}

 

Incidentally, I found a very useful new way to debug output in real time. Before, I was limited to either logging output and reviewing it later, or going through the complicated process of creating a new HUD class and using it to print out variables onto the screen. Luckily, there is a much easier way.
To do this, you need access to the player's Pawn or Controller class. Then you can simply call (for Pawn or PlayerController)
ClientMessage(VARS TO RENDER);
to get a debug string output on the screen. easy!

Long story short, the new version (2.0) of soldatUT is available on the files page.