As a followup to some previous discussions regarding precaching actors in mutators to avoid the initial bit oflag in the event the actor class in question is not already on the map, I thought I would post my latest method for this.

Here is a shortened bit of code right out of the currently unreleased Dropper v2.0 update. (This week I think. Still testing a bit.)

For this example there are only 2 global config variables from the ini file being used by the precache function.

Hi, LoathSome I'm thinking at... Player supposed to render these... TickSpy did not figure too much troubles at server but looks like player at spawning stuff for first time is "forgetting" rotation a bit, and there are moments when this has less funny results...I think I'll try something for client - a separate precacher. Probably will lock view in first second but I guess it will help later... I cannot say that I might be able to do it well but I think it worth a try...So to speak I head to Mesh dynamically changed in client sent by server for some "box" used as a precache base. I believe that mesh is trouble maker at these laggy things not actor itself. If I check some UT stuff, precaching refers mainly to mesh which has to be rendered and it needs info "how to" at first appearance.Gotta find some time for testing these, and I'm already thinking at "state precaching"... , and for sure I need to solve player later entered too...

Until this moment I could figure at first Monster Encounter in a Level with No Monsters, whatever lag... Well... like I said if player doesn't know what mesh or what freak will spawn it has to load content processing it a bit and bugging your aiming and/or rotation. Given the request for "let me know" from player (server precached somehow files and... it doesn't render) I think I can insert (oops inserted) something from stock (from original packages) but assigning meshes from SwarmSpawn.INI directly from server to client without declaring any new replication and using default Actor Replication, as follows:Class SS.uc

I think I can confirm that lags were reduced at minimum (player needs a bit of time for new content (files) but not as it was before... New comers will have precached all content as long as it is now in Level until game will end.

I have some observations. If Level has other dependent files they are not causing so many troubles because Level will be prepared for player. If server uses packages but which are not part of Level (as our monsters) new content needs time for load/draw etc. As long as I was bringing the MESH /I see that "ForceMeshtoExist" in more classes - well this is a another way of doing. Of course new files are not loaded yet even if are packaged (my observation in a server 2 years ago if I'm not mistaking) by example server has NWII in packages but nothing used, admin summoned a weapon and then redflag almost to drop connections - even some players were lost. Happened because nothing precached Mesh + File to load and other dependencies.This time half of job is done player load only file first time and then... he knows how to render that as long as mesh is loaded at start any exist (Book in cause). That annoying lag seems now reduced at minimum. Else probably I'll try to load classes in purpose to gain everything, file + mesh. The most of stuff from UnrealShare and UnrealI are accessed faster because they are dependent for majority of BotPack related things, so they are not that much a problem as Custom stuff...

Question. Have you done enough nearly identical tests to be sure the occasional lag you see when an actor spawns is being caused by the spawn itselfand not something else?

Is the lag from the actor spawned by the mutator about the same as it is when you summon the actor into the game as admin without any precaching?(As you just mentioned, that is the test for this. )

It just seems to me that your addition is a bit redundant. The actor in question is destroyed instantly.Precache of the mesh, and the entire actor for the client, if needed for that actor class, will happen when the pcla actor is spawned.No need to set all those extra variables at that point. This is a temporary actor. Any other attributes should be set elsewhere, eitherfor that classes defaults globally, or for a specific actor when it is spawned. In any case setting those does nothing as far as precaching the actor.The ONLY settings that need changed are the ones I do there to the class default bCollideWorld settings that allow any actor to precache on a map even ifthere is no chance of them ever actually spawning during gameplay.

Don't take that the wrong way. I am very sure I tested a few things that were doing some of the same stuff as your addition to the code there, but itdid nothing.Looked very familiar however. I like to test everything every way I can think of.

If I remember correctly there were a number of very very old mutators, that would have a function in them that was never called.It would just have code that spawned and destroyed a bunch of hardcoded UnrealI and UnrealShare monster classes, but it was never called.It was just there to force the precache of the meshes etc.... Which it mostly did, but not always, depending upon the map and the actor class etc....

Keep in mind, that wasn't stuff I wrote, but it was stuff I started learning this sort of thing from and seemed to work mostly.

I believe that old method would help eliminate spawn lag on the server itself, but probably did nothing for clients, so they would still have spawn lag the firsttime a specific actor class was spawned in the game. I think that since my current method there is actually in a function that gets called, the precache of theentire actor should happen on both client and server. Even though the temporary actor only exists for a very short time.

Look at the Precache function there in my Dropper v2.0 for what I am currently using. Same will be in the next SwarmSpawner update. (This week I hope. Minor changes... )I have been testing this a LOT on live servers with quite a bit of stuff spawning. (Yay EXU2!) Spawn lag has not been an issue as far as I can tell.

Good observations and feedback. Feel free to correct me on any of this. (I know you will. )

MrLoathsome wrote:It just seems to me that your addition is a bit redundant. The actor in question is destroyed instantly.

Nope, events are as follows:- swarmer spawns test (server-cache prototypes);- if they spawned for each of them I spawn a book copying mesh from PCLA (the temp one);- then PCLA being precached is destroyed but Book stay less visible all time for all new comer or already playing.

Little lag comes from Book and some tester + loading packages required, but mesh being there it won't cause breaks as it did before. I made a few tests exactly in the same way as in older way and... first encounter with monsters is not that delayed and the rest are just loads like are being part of Level with no delay. Of course, I reduced some of my tweaker's jobs but it did not help that much (I had A.I. iterators for DM which were not so cute). Then I had a recall about this chapter and I fired a try, it looks 70% helpful so to speak.Those client lags were happening a bit for each new round of creature spawned (which were not seen yet), now it's reduced because Package is loaded once then mesh is known because IT is NOT removed, actually people with good eyes can see them somewhere on a higher spot, they are not disturbing game at all, else I can try a bit more masking them or making a chain on axis Z. New comer breaks a bit once ( NaliWeapons even loads assets) but later they are rendered normally (depending also on Player display).I did not copy any code from nowhere this is my idea to get meshes in Level for client notification using a stock thing, probably another fancy way is by using Spawn Notification with some tweaking, but I went for a more simple solution. And of course my monsters uses minimum 2 packages: Original with code and the rest of stock for meshes, then more data is loaded at first encounter not only stock type.

Another note, even for default games, very little lags might occur when a new player which has joined is using another class than player from Level and playing current match, at least I could figure this all time in servers, happens because me, the player, I have to load files used by New Comer and to know how does he/she looks like. This happens with swarmspawn but, it is now closer to what I was looking for. The crappy warping also happens when server uses 8 player types packaged and all of them are entering one by one - that moment is not the best but... hey - game just starts...

As for server, I'm using a small trick for loading stuff a bit faster than usual. Before firing UCC I'm listing all files from server (dir command), so UT will learn their location speeding up seeking. Also Server Folder is the only one "indexed" by OS, so scanning files there takes less time than in first load which I used 1 Year ago, cache is always very fast...

Time to finish mission.Actually I did a complete outsider cacher mutator tool. It will reduce lag of first appearance even from CTFAnnouncer message or whatever stuff which is not in Level. My first attempt was functional but pretty incomplete so I went into some inspirations - a Siege class was an example of replication tweaking, but I have modified codes for this purpose. I love it right now:- Mutator spawns an actor owned by Player and is injecting names, 128 places in array - decent load.- Actor doesn't use any RemoteRole by default;- Actors having 2 instances server and client will go in 2 different states:a) Server guardian - player left > delete;b) Client - When starts Precaching Server initializes RemoteRole sending names;c) Client will dynamic load classes creating those tiny annoying breaks ONLY ONCE at starting match for all and one by one at small intervals of time to not affect connection and to do job as smoother as possible, big packages takes visible time but they can be pre-cached too;d) Whatever spawns later in game, if is mentioned in precache INI configuration won't lag any longer, not even a bit;e) looks like it does the same thing with Custom Messages and all actors which are about to spawn visible in Client, so I'm guessing that even custom player types entering in game won't affect frame-rate from client as long as they exist already loaded in advance.After doing a couple of tests I'll share the mutator and source-code. Right now Everything which I'm using in all SwarmSpawners will get loaded in a few seconds and all later game action does run like the stuff is embedded in Level by mapper .

And I think I completed cache mission. Client will load packages depending on INI configured and will have them ready when server demand a custom spawn so the bit of lag happens only once at beginning and will help later to prevent frames drop during play.

Mutator for helping player in pre-loading custom server stuff - configurable by admin.

(78.46 KiB) Downloaded 55 times

EDIT:I was setting up my old rig Athlon1800 having slow hard drives and old structure - heh, this method looks really useful for such hardware. All bad lags occurs at start and later it flows smoother...

Last edited by sektor2111 on Mon Oct 10, 2016 6:45 pm, edited 1 time in total.

Took a look at the code, and I see what you are doing there, (and it is nice and makes sense), but I am still not sure still if it is really needed or not....

Been testing last month or 2 on my servers with both the Dropper 2.0 and an unreleased version of Swarmspawner that are both using the pre-cachecode that is in Dropper 2.0. Not noticing any major lag issues when things spawn as it is, but that doesn't mean much. I could just be used to it.

I do very much like the way you wrote that. It will work with anything, and you can select the classes you wish to precache individually. Very nice.

Will have to run some tests with and without that to see if I can even tell a difference. May have to make a test version of Swarmspawner that has no internal precacheto compare with. Might have to write up a spawn timer log mutator utility or something for the testing....

Again, I do like the way you did that. Even if it turns out to be not needed for Dropper 2.0 and Swarmspawner, it will work to precache actors for anything else.

Been distracted by RL and health issues the last month or so, but hope to mess with this stuff more here shortly.

This stuff is aiming client, I even did some tests with a machine having OLD IDE drives - Looks like it do helps a lot. Just take in account one occurrence which I was witnessing some time ago. Server NaliWeapon II Only in packages Not mutator. At a moment admin summoned a NaliWeapon. Now imagine RedFlag at loading new stuff because it was not in Level (stupid MH-Face map). Then reconnect, at least 3 guys were lost. Using such a tool will enforce some stuff preloaded BY CLIENT because SwarmSpawn does unexpected spawning for client which is like a sneak attack - client being forced to load from cache files right in that moment. THis toy in old machine does those lags when game starts, all later sudden creatures dropped won't lag anymore their first appearance - I simply boost their first appearance at start so, good bye Lags later during hunting. Btw, SwarmSpawn used is located only in server - NO packages but monsters are part of packages - in exchange client won't drop them in Level because... they are not in Level's dependencies so client loads them on demand. Lag which I'm talking about is similar with opening Mapvote window (not map lists) which seems to have the same problem - stuff sudden called unrelated to Level, so I think I'll list that class for being part of Level in order to speed up the load when it needs.The cons:Newer machines (player on purpose) with SSD drives probably doesn't need this thing - but a couple of time ago a player complained about lags in those DM Matches and testing server from another Network I was figuring the problem. Now I think is done Monsters are spawning like those from MH maps with no issues as long as classes are forced to go in Level. First time I was interested to do this in SpawnNotify but... I wanted another try - it looks operational.

I had the same problem in MH when I was using a Monster Replacer tool, new stuff appearing in front of player was always causing breaks at first encounter. I was using a fake monster spawning a true monsteer when players were aproaching... Purpose was to speed up PawnList using only a few nearby creatures and those ordered with some mission. The rest have been eliminated and bringing copies in their locations - this way was laggy for clients...