Jump to content

  •  
- - - - -

Notice to Mapmakers - ref .def's & performance


  • Please log in to reply
8 replies to this topic

#1 Learner

Learner

    God

  • Administrators
  • 2121 posts

Posted 04 September 2015 - 06:04 AM

A change is currently being tested to improve the handling of some types of map areas. The potential was there that lots of areas that take effect by entering or standing in the area could possibly slow down the server If the map was really busy (like during invasions).

While there are still limits on how many areas there can be, this does mean there is less concern for bogging the server down with lots of specials unless you cover more then half the map with specials! This will allow for more complex & smarter maps .... keep that in mind while designing and making the .def's.

#2 winter

winter

    Member

  • Full Member
  • PipPip
  • 305 posts
  • LocationUSA

Posted 04 September 2015 - 06:48 AM

That sounds great L!  Is there a correlation to server load and the relative density of these spots or just the aggregate across the entire map?  Ie, if we're going to have a lot of them, is it better for the server if we spread them out, or should that not matter?

#3 Learner

Learner

    God

  • Administrators
  • 2121 posts

Posted 04 September 2015 - 06:56 AM

It's the aggregate across the entire map that could have caused the slowdown in special cases with lots of areas or tports combined with lots of mobs or players. The code being tested uses some extra server memory to quickly check if a coordinate could be in an area of a specific type, if not no further checking is needed.

Also, the order the areas are in can be a minor factor ... the list is scanned and it stops on the first active area. That means areas more likely to be used should be listed first, and when two of the same type overlap, the one listed first will hide an overlap with areas after it.

#4 winter

winter

    Member

  • Full Member
  • PipPip
  • 305 posts
  • LocationUSA

Posted 04 September 2015 - 07:55 AM

I should probably know this, but I don't have a clear handle on it...  for general placement of objects with respect to client lag - is it the number/complexity of objects in a viewable area that tends to cause lag or those across the whole map?

When making maps, there seems to be a constant struggle (in my mind) between making the map LOOK really nice, cool, and seamless versus flooding it with too many polys and therefore making it laggy.

Is it just my natural tendency to be an efficiency hawk?  How concerned about lag should we be, when making maps, in regards to how many 3d or 2d objects (and their complexity) we use?  My machines aren't high-end, but are zippy enough, so I'm not satisfied with relying on my personal experience in game to answer this.

#5 Learner

Learner

    God

  • Administrators
  • 2121 posts

Posted 04 September 2015 - 08:50 AM

2D objects aren't complex ... but almost always have transparency. For 3D objects, their complexity & transparency of the texture(s) are factors. Certain 3D objects like trees, tall grass, corn, etc are guaranteed to use transparency, others it varies. Transparency in an object doubles the amount of work needed by the GPU, doubled again by reflections, and doubled again with shadows enabled.

Of course there are also Client settings that affect the look and the effect of slowdown, including many settings related to the camera as well as the actual view the player has at the moment. One feature that might have been removed from the client (or disabled) as being able to adjust 2D size vs distance of a texture to just not bother even trying to draw 2D objects. Some people didn't like how some ground textures suddenly appeared as they were walking. Would have to check if that's still there or not (was in earlier versions before AnimationProgram & CameraViewDistance was added)

One of the earlier versions of DTF looked really nice but lagged some machines, and it was mostly because of a lot of skeletons & bones added to the map to make it look better. General rule of thumb, test new maps with the slowest PC you can find with multiple views & locations. Thats how it was identified that all the bones were adding to the lag.

#6 EatsAllLife

EatsAllLife

    Member

  • Full Member
  • PipPip
  • 381 posts

Posted 04 September 2015 - 09:51 PM

Yeah, so test new maps with my computer... XD Anyways, the changes with .def will slowly be learned, along with the nactual .def coding... but nice info with map making - all tips/comments can be useful in many ways!

#7 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 07 September 2015 - 12:09 PM

Ok, so I am irrevocably old and dumb. However, I can't go to my grave without knowing wtf .def coding is ???

Just point me to a previous post, or whatever. I just need to get my head around how a .def interacts with an .elm

#8 Learner

Learner

    God

  • Administrators
  • 2121 posts

Posted 07 September 2015 - 01:09 PM

There is a .def for for every map that is on the server only. It defines special areas (like IP healing or WSC sewer) with special properties, names ares, what happens when you use an object (like a flag to tport to another map), etc. It adds function to the graphic design in a .elm. The MapAreas I'm referring to here are related to many of those common ones except clicking on an object to be tported.

#9 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 07 September 2015 - 05:43 PM

Thanks L




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users