Server Tracked Objects

Well, STOs themselves aren’t complicated. Standard stuff really. I’ve got a little class hierachy: base, transport and implementation. The abstraction means that Rick/Martini get to stay a step or two away from the evil that is teulKit, but I don’t have to write a new set of callback routines for each and every STO. It probably costs a little efficiency, but I’ve bought plenty of that :) And I’ve added plentiful hooks for monitoring these things.

First up will likely be smoke and mobile spawns. What’s that face for? Smoke is a good test of some fundamentals, lets us make smoke work somewhat better, and I hope eventually lets us add smoke to tanks. We want to increase the number of mobile spawns significantly, so we want to let you despawn your deployed MSP truck and have it replaced with an MSP object.

And once both those are working, they have natural follow-ons. As I’ve been writing the transport classes it’s been cool seeing how close the code is to what we need for a whole bunch of stuff.

The tricky part is integration to an existing, complex system. I was going to do this on the cell hosts. Seemingly the “right” place for it tho is probably on the map/mission host, but players transfer to/from that when they despawn/spawn, and I’ve not had sufficient opportunity to sit down and break that disconnection.

And ultimately I want to replace our current world “grid” system, edit: an overhaul for which the area chat system was actually a basis for. The current system is frighteningly over-complicated by the fact its design screams “write me in object-oriented C++”, but instead it was written in “no, we shall not use classes, even if you threaten to scare us! C”. It has complex, unexplained, lines of code like this:

  FAST_POSITION fast;
  fast.x=((raw.X - FAST_OFFSET_X*100 + 87732) / 100)
          >>WIDTH_ADJUSTMENT_LEVEL;
  fast.y=(THEATRE_MAX_X*1600);
  if (fast.x > fast.y)
    .. some error about out of bounds ..
  fast.y=((raw.Y - FAST_OFFSET_Y*100 + THEATRE_MAX_Y)/100)
          >>WIDTH_ADJUSTMENT_LEVEL;
  fast.x=(THEATRE_MIN_Y*1600);
  if (fast.y > fast.x)
    .. some error about out of bounds ..

Hum. Ok.

“WIDTH_ADJUSTMENT_LEVEL” is 4, so “>> 4” is a very fast integral “divide by 16”, some of the rest begins to make sense. That * 1600 is probably supposed to be divide by 1600.

After a while going through defines, looking at numbers, typing stuff into calc, I came to the conclusion this code doesn’t work. And lo. It’s called the same thing as the real function, its defined in three different files, but through the magic of compilation, it actually turns out that it uses a different function entirely:

  // Convert from cm to 16m units
  x = raw.X / RAW_TO_GRID_RATIO ;
  y = raw.Y / RAW_TO_FAST_RATIO ;

  x -= GRID_X_OFFSET ;  // Zero-based from left edge of map
  y -= GRID_Y_OFFSET ;  // Zero-based from top edge of map

  // x and y are unsigned so if they go negative they become very large
  if ( fast.x > GRID_WIDTH || fast.y > GRID_HEIGHT )
    .. error ..

The sharp eyed will notice something about the syntax of the second bit of code ;)

Where’d the shifting stuff go? Well, “>> 4” is a fast divide by 16. But since we’re dividing by 100 to get from cm to m anyway, we might as well go ahead and divide by 1600 which is what “(X / 100) >> 4” amounts to.

Well, for now I’m going to overcome the obstacle of surgery-on-the-old grid system by bypassing it entirely.

No, there isn’t going to be an separate, dedicated ordnance server, but there will be a server that handles ordnance.

Tossers ;)

17 Comments

W00T!!!1 An ordnance server!!!

:)

Actually I’m still waiting for that ordinance server – that’d be much more fun. :)

BTW I’m (OMG!) extremely worried (nay, concerned!) about this whole MSP STO thing. What will it look like? Will it be killable? Will there be some way of stopping it from lasting forever? Will it be movable?? I really don’t think these areas of MAJOR concern have been given enough attention.[1]

Re STO’d smoke, I actually think that’s pretty cool. And didn’t some tanks have smoke shells or summat, that they could fire as an alternative to their regular HE or AP? I’m no WWII expert, but I think I’ve seen some discussion of this on the forums (ie it’s probably completely apocryphal).

[1] I may have forgotten to add the appropriate [sarcasm][/sarcasm] tags around this paragraph.

BOUNCING GRENADES!

Persistant Smoke is a basic feature of real WWII tactics… it includes, tank shells, tank defensive smoke launchers, and also infantry mortar with smoke rounds…

Both, the british 2inch and the 50mm german light mortars had smoke rounds, you can read it in the Osprey book about WWII mortars.

Smoke worked to isolate a sector of the front, to be able to perform attack and defense actions… smoke is even more important than StatHE for our low density of infantry players compared to real life, because persistent Smoke also deny to tanks the line of sight over an extended area… Just use your imagination.

The Naval Destroyers had also defensive smoke barrages…

I’m also excited about the MS posibilities that this feature opens… and in a long term… the naval gameplay of Cruisers, Battleships, and Aircraft-Carriers… you can track them, and only display a naval mission when two enemy fleets become close enought to be in visual range, to allow to the players to join and man those big vesels… avoiding the long sailing times for north atlantic battles.

STO has a great potential for gameplay. :-)

Here’s my solution for tanks firing smoke :) When a tank fires a “smoke” round, it actually fires an infantry unit holding a smoke cannister in his upraised hand. When the infantry hits the ground, the smoke round detonates and the infantry unit is killed. Players could crew with the tank to become these smoke rounds, and they’d get rank points for every suicidal smoke death (we’d call it “ranking up the hard way”). A “burp gun” sound for the firing would be a nice touch.

So what happened to Gophur’s notion from a couple of years ago that a good first test for server-tracked objects would be persistent bicycles scattered about the towns?

Hard to do without having the requisite infantry animations already developed, I suppose.

BTW…I recall when Killer said that smoke wouldn’t be tackled until an ability existed to model breezes, so that there’d be a basis for smoke drifting and dissipating.

So does that mean that breezes will be along as well, and we’re getting closer to ground-level weather and particularly morning fog over the Channel, coastal areas and in the Meuse valley?

Hmmm. One more question:

Is STO functionality one of the precursors for implementation of naval-game polycrewing, say for ten players?

A discussion of what it may take to make the fundamental shift to polycrewed naval gameplay would be very interesting.

OMG, those poor semi-colons… they look so lost and lonely if I only I would be able to delete that expanse I would. LOL gah, the perfectionist in me says that that space is blasphemy, but each to their own I guess.

Pretty much all BEF tanks came with duel smoke launchers (you can see them on all the destroyed tanks at Arras) and the BEF HE tanks came with 6 times as many smoke rounds as HE. Early war axis tanks had “smoke candles” that don’t sound nearly as useful. French tanks I think when I saw the thread had no smoke shells.

Later war tanks for everyone had them as standard, at least thats what Steel Panthers tought me.

Persistant smoke without morters makes tanks yet more powerful (they can fire smoke quite a distance, and inf can’t), and the light morters (2″, 30-50mm) probably are more useful as smoke launchers anyway.

It also makes the 88 more powerful again because it’s smoke it undoubtly going to be better than smoke shells from a 2 pounder or 25mm.

Re:limiting the power of MSP: mabye limit them to “you must be X meters away from the nearest friendly non-mobile mobile spawn”. Only problem is the player can get told when hes too close, but unlike depots, can’t see where the other NMMSP actually IS. A Objective OiC could, but that’s only 1 person, who isn’t driving the truck either.

Soltion: everyone can see ALL friendly MSP’s going to THAT objective, and whats more, see the radis of deployment and where you can and cannont deploy, on the map. This also means friendly tanks/AA/ATG/Air on other missons can still see where the MSPs are and support them a lot better than they do now (how many attacks do youy see where massed armour attacks where the friendly MSP ISN’T!).

Expect DEFENSIVE MSPs to become a lot more popular too. This is a good thing.

And 232s/Panhards/Vickies should cost more, because they just become a lot more useful then evere.

IIRC there were dedicated CS versions of the BEF tanks that had almost solely Smoke loadouts.
The main gun was a 3,7″ howitzer on those tanks.
/Soraz

A lot of tanks had little mortar-like launchers for smoke canisters on the turrets, and we don’t currently have any of those visually modelled on the tanks ;)

W00T!!!!

Tank model updates!!! Time for dirty tanks!!!!!

See, now WWIIOL is getting fun, bceause now the GOOD stuff is coming. Not to be a jerk but I would say, finally you have a base game here and now you’re looking to modernise.

Rael

lol, I didn’t know you meant the visual model :) I figured it was something like a ‘vehicles don’t have loadout’ problem.

RE: smoke on the battlefield: Long burning, large smoke effected, tank hulks. Colour, persistance, recon (how many dead tanks do you see attacked this town?), wow factor, coolness, cover, fly boys have harder time to doing ground attacks, and reviewers will love it.

persistant destroyed vehicles would be excellent immersion

SMOKE is a valuable tactical asset and should be a priority. And yes the MATILDAII CS with 3inch howy did have a high smoke/HE loadout.
Smoke discharges are standard on almost all AFVs even today. The matilda had 4? on each side of the turret.

Good news about the terrain and graffix engine too, the MAJOR thing holding back TACTICS in this game has been the lack of effective tactical terrain. any RL soldier knows the importance of terrain and in this game there quite literrally isnt any so far.

re: MSP despawning and respawning as inf, cool! I can see the link here with bailing out tank crews and pilots!?!

AH, uhm, no offense taken Rael. I think “Wow, we could almost release this now” has been an oft sung anthem at CRS towers… :)

Trackbacks and Pingbacks

[…] I could have sat down with a cool head and implemented the design(s) I’ve experimented with (remember, the chat grid system was a prototype for such a concept). But it’s categorically not […]

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: