Author Topic: New Joint Venture Multi Player Map  (Read 15916 times)

Offline dave_erald

  • Sr. Member
  • ****
  • Posts: 262
Re: New Joint Venture Multi Player Map
« Reply #25 on: January 04, 2016, 06:29:28 PM »
I thought I had seen in another post somewhere about disabling all warnings for a map, or it may have been a hack of outpost 2 itself rendering every map without warnings? I'm not sure now.
-David R.V.

-GMT400 fan
-OPU Influencer

Offline Arklon

  • Administrator
  • Hero Member
  • *****
  • Posts: 1267
Re: New Joint Venture Multi Player Map
« Reply #26 on: January 04, 2016, 07:08:04 PM »
I thought I had seen in another post somewhere about disabling all warnings for a map, or it may have been a hack of outpost 2 itself rendering every map without warnings? I'm not sure now.
I made a hack to disable all disaster warnings a while back for CCF2, but not on a per-instance basis.

I should maybe look into making disaster warnings only trigger if they're in close proximity to your units, like how the incoming EMP missile warning works.
« Last Edit: January 04, 2016, 07:10:39 PM by Arklon »

Offline dave_erald

  • Sr. Member
  • ****
  • Posts: 262
Re: New Joint Venture Multi Player Map
« Reply #27 on: January 04, 2016, 08:45:53 PM »
That could be where I read it. Wow, I swear i only just found and downloaded the package on ccf2 and was going to send you a PM later this week on what its about and its usage. I had seen someone's post on 'Battle of the blight' and thought that code really needs more use, which of course led me too your download.

I was going to ask your permission to use it if I could (pending my ability to even sort of comprehend it, I looked it over, its out of my reach right now)

Thanks for the help.


Side note, the fast call trigger for firing a meteor gets passed around in the SDK a bit, I'm guessing one call couldn't be manipulated to fire multiple meteors?(noob question, feel free to give me a noob appropriate response)
-David R.V.

-GMT400 fan
-OPU Influencer

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: New Joint Venture Multi Player Map
« Reply #28 on: January 06, 2016, 08:09:55 AM »
Quote
Doing that still spams you with warnings (disaster occurring), just not cautions (disaster watch, 10 marks prior) or alerts (disaster imminent, 5 marks prior).
Good point Arklon. Perhaps some more thinking is required.

Quote
Side note, the TethysGame::SetLavaSpeed is sorta useless ain't it? (Yes it is, that 300 in TethysGame::SetEruption is the lava speed, 50 is slow, 500 is, well, lava probably shouldn't move that fast...)
I think so, yes. That's why I omitted it.

Quote
NEXT=>  A lot of this could be used for a controlled meteor shower right? All of the meteor impact points would go in:
That "MeteorShowerA/B/C" looks an awful lot like an array. ;)

As for the meteor shower offsets, it's similar to how it's done with the volcano. From what I remember, SouthFlowAni sets two tiles to animate. You specify one coordinate, and the other coordinate is offset from there. The meteor shower cloud could have relative coordinates from a center point. You specify a center point to the function, and the function will spawn meteors about that center point. The offsets could be controlled by using set layouts, passed in an array, or they can be randomly generated. The layout idea is neat, but beware the player will quickly recognize those layouts if you don't have a lot of them. That might not be desirable. It does allow for control over the damage pattern though, and can prevent two or three meteors from overlapping, and possibly causing too much localized damage.

Code: [Select]
void CreateMeteorShower(POINT &center, int numMeteors, POINT offsetList[])
{
  for (int i = 0; i < numMeteors; ++i) {
    POINT pt = center + offsetList[i];
    int meteorSize = 2;  // Better not to hardcode this
    TethysGame::SetMeteor(pt.x + 31, pt.y - 1, meteorSize);
  }
}

A modification to the above, is rather than pass "POINT offsetList", is to define a new data structure that contains both the offset, and the size of the meteor. That way it's not always hardcoded to 2. Such a struct might look like this:
Code: [Select]
struct MeteorInfo {
  POINT pt;
  int size;
};

You can then use array[index].pt, and array[index].size to control the offset and size of the meteor.

A further extension might include varying time delays, so the meteors don't all crash down at exactly the same time. I think that would actually be rather important to give the meteor shower some flavour. I'll leave you to think about it first. It will likely involve using scriptGlobal to control placement over multiple game ticks.


You can do away with the layout array by just using random numbers to generate the offsets. A parameter might be the size of the area around the center where meteors can hit. You can also play around with random number distributions to get meteors more likely near the center, and only rarely near the edges, and shape the area so it's more circular, or oval, or linear, rather than a box. There are also ways of controlling layout to prevent crowding, but you'd likely need to generate and store coordinates in an array and then spawn the meteors after all of them have been assigned a place. If you're also doing time delays, then the array will need to be stored between ticks, again using scriptGlobal.

Offline lordpalandus

  • Banned
  • Hero Member
  • *****
  • Posts: 825
Re: New Joint Venture Multi Player Map
« Reply #29 on: January 08, 2016, 09:02:00 PM »
Is it possible to create a new disaster entirely? That way you'd only get a single warning.

Something like an event that produces meteor strikes all within a single area, and as its a single event, only a single warning would be posted.

In theory.
Currently working on Cataclysm of Chaos, Remade.
Link to OPU page = http://forum.outpost2.net/index.php/topic,6073.0.html

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: New Joint Venture Multi Player Map
« Reply #30 on: January 09, 2016, 10:49:26 AM »
That might be one way of doing it. Difficult though, as disasters are units. I don't think you'd want to do this as a new unit, as adding units to the game is quite difficult. In particular, it's not too clear how new units would be saved or loaded from saved game files. It would be a convenient way of working with it though.

I suppose a meteor shower library could be designed and wrapped up into a nice API. With a bit of mem hacking you could remove the extra disaster warnings. You'd probably want to set a static limit on size, as in a max number of meteors in one shower, but I suppose that could become a template parameter. The object controlling the disaster would probably need to be stored in the ScriptGlobal struct, since it's probably going to need processing over multiple game ticks, and so would need to be saved and restored from saved game files. That makes it a little less nice to deal with, but not too terrible.