Object Count Limitations

So spawning pieces in not at start causes them not to use dynamic lighting? @TheClubhouse

 

That's correct. If an object doesn't spawn at the start of a match, that object doesn't register as being there as far as the lighting is concerned. Therefore, it won't cast any shadow.

 

So do you just have to set spawn at start to false and set a spawn time or is there more to it?

 

Nope, that'll pretty much do it.

 

Does anyone know if delay-spawning a bunch of objects would make the map more likely to load? My theory is if you set the spawn time for half of the structure objects to 8 seconds with place at start set to false, then the map would essentially load in 2 different batches/stages, and therefore wouldn't be so overwhelmed with so many things to do at the very beginning. All the delayed objects would still be there before players spawn in.

 

I already tested this a little while ago. Unfortunately this doesn't make any difference. The actual cause for maps not working with larger parties is due to the number of objects spawned onto the map at any given moment. So if you delay spawn the objects into stages, what will happen is that the map will initially load for all players, but as soon as all your objects have finished spawning in, everyone gets kicked out.

So yeah, to summarise; the object count limitation is actually an object spawn count limitation - that's what's breaking parties.

 

i disagree, once the map is loaded on your end it shouldn't need to constantly send update packets of each individual piece unless they've moved or despawned so packet size and bandwidth shouldn't be an issue. though on this subject scripting updates might have been the cause for the bandwidth spike we were seeing before.

what i think is happening is ram overflow issue, in a simple try catch statement when trying to create a new object would handle an allocation error and end the game instead of crashing the to the dashboard if it wasn't handled. also considering, at least from my experience, maps with a lot of complex objects on them crash with a lower object vs maps with simpler objects and a higher objects count just managing to be stable leans itself more towards this.

we don't have access to any debug tools so we can't say for sure though.

 

Posted on Waypoint, though no one there really seems to care:

The H2A forge right now is difficult to work with. Framerate performance can drop markedly with only a third to a half of the budget utilized, depending on the pieces used. This makes forging larger scale maps that actually load up in larger lobbies almost impossible. The most framerate-intensive pieces are also some of the most commonly used, such as the bridge pieces, coliseum walls, landing pads, and the large braces.

Could we please have the following improvements (most desirable listed first):

1. Four different options for blocks, bridges, and inclines: default, simple concrete, gray metallic, and black metallic, selectable under "object options" so that the object list isn't three miles long.

.....(a) The simple versions remove all of the extraneous polygons for generating the pipes, etc. (especially important for bridge pieces).

.....(b) The simple versions remove some of the piece geometry polygons (simplifying the large braces would be an enormous help).

.....(c) They would also remove the lip on the backside of the bridges so they could be used for smooth walls/flooring.

.....(d) The simple concrete ones could still have the black metallic trimwork as long as extra polygons aren't involved in creating that.

.....(e) The metallic ones could simply use the pattern on the back of the decorative walkway cover on one side, and the smooth brushed metallic finish on the bottom of the platform large and platform XL on the other side.This will give us the ability to create large, smooth surfaces with minimally visible seams, yet still utilize the added visual complexity of the current, default pieces when necessary aesthetically. This doesn't need to be done with all the pieces - simply sticking to the blocks, bridges, inclines, and a couple of very common decorative pieces and platforms (large brace, landing pad, small Y-cross) would be fine.

2. Add some additional building blocks: 1x10, 2x10, and 5x10 in flat, short, normal, and tall variants. Using the larger 10x10s for creating map borders that are a few units tall (leaving the rest of the piece buried below the floor) contributes to framerate issues, as the engine wants to render the entire piece if any portion of the piece is visible.

3. Make the color stripes visible only in Forge when "neutral" is selected. That lets forgers see where the strips would be . . . but doesn't make them show up while playing if the forger doesn't want the piece colored.

4. Improve the performance meter so it actually registers a portion in red when frame drops will occur. Right now it seems like you have to get down to 20 FPS or less before any red registers.

5. Fix geometry holes in the pieces that causes seemingly hidden objects to drastically affect framerate. An example is the failure of the polygons on the tip of the pyramid to actually connect, letting you see through the tip at the correct angles.


Secondly, if a real fileshare could be resurrected, all forgers would rejoice. The forging community took a big hit with H4's inability to retain popularity, and the current fileshare situation is like standing on our necks while we're down. Please please please get a real fileshare up and running.

Thanks!

 

PC Gamer and Programmer here.

Can confirm that it probably isn't a "packet" problem.


The truth is, multiplayer requires little data to run. That's why someone moving from DSL (.5 MB per second) to Cable (2 MB per second) won't end up with a ping that's 4 times better. Surprisingly, DSL is actually better when it comes to ping, but not by much.

In other words, it's the quality of the connection that affects gaming, not the quantity of bits it can carry every second.


Even if every piece was dynamic, moving, and sending out data, the amount of data used would probably be insignificant.

All it's doing is sending out information to the consoles telling them ("There is Object A at XYZ").

In the cases of a PC, assuming that the player has a reliable connection (something that most people have), it would be a problem with object and lighting rendering that would crash weaker machines (or anything else requiring raw performance), not a lack of bits.

In this case, raw horsepower isn't the issue. If the host can render the map, everyone else should be able to as well. All Xbox Ones have the same specs (identical CPUs, GPUs, and RAM), and the individual differences between chips are too small to have any significant impact.


As "A Haunted Army" states, it could be a problem with memory (RAM). Personally, I think that what's causing the crashes may be a bug or oversight involving the hosting system. It might even be both, a problem with un-optimized memory management involving the hosting system.


I'd say that the best way to test this would to get a 16-man LAN party and run on a Forge Canvas with 500-600 objects and see how many people crash.