System TrackMapSystem

[Steel]

Executing the least amount of instructions for a map load is always better if you can mask them over the course of gameplay. I like that Executor thought of doing this, I did this in my own RPG to help decrease the load time of the map. If you have a map that is fairly large, you will have a long load time even after optimization, any reduction to that means people can be in your game and playing it faster.

Nicely done Executor.

 

[Azlier]

>Executing the least amount of instructions for a map load is always better if you can mask them over the course of gameplay.

What? I, for one, prefer a longer loading time over laggy gameplay.

>Right-click

Ah, but right-click serves another function. Both are detectable separately.

 

[Steel]

...if you can mask them over the course of gameplay.

Yes, it is always better under this condition. Always always always. If you can do something without players noticing, it is better. Preload abilities during text.

I'd personally have a map load up in 10 seconds with 10 seconds of lag after the game loads up with solid gameplay over load up in 2 minutes with 0 lag in the beginning.

 

[Azlier]

The preloading takes the same amount of time either way. You just recommend splitting it up in gameplay. I do not like that idea. Blizzard doesn't either. Melee maps preload everything at the start.

 

[Jesus4Lyf]

I'd personally have a map load up in 10 seconds with 10 seconds of lag after the game loads up with solid gameplay over load up in 2 minutes with 0 lag in the beginning.

10 seconds loading time in load screen + 10 seconds loading when game begins = max 20 seconds worth of loading.
2 minutes = 120 seconds.
Math is out 5x over in favour of the point you are trying to argue.
5x bias factor.

User's opinion ignored!

Load screen loading is definitely better, as it allows a player to be playing your game faster (if you're tracking a whole map, chances are your map depends on the trackables existing, and so the game can't start until they do - should be more efficient on load screen).

 

[Steel]

The numbers aren't skewed. If you're talking here strictly about trigger code and no object editor data then yes, I agree those numbers are not accurate.

I did a lot of analysis on map loading when I was working on my RPG. I did over 1000 load tests on 3 different machines under different stress, handling different scenarios to extrapolate the best way and fastest way to load up a map. Preloading is just about the absolute worst thing you can ever do to try and improve your map's performance. Look at my post here: http://www.thehelper.net/forums/showthread.php?p=713842#post713842 and you can try my map here: http://www.thehelper.net/forums/showthread.php?t=134226

Don't be so quick to dismiss what I said, it makes you look ignorant.

 

[Jesus4Lyf]

it allows a player to be playing your game faster (if you're tracking a whole map, chances are your map depends on the trackables existing, and so the game can't start until they do - should be more efficient on load screen).

>Don't be so quick to dismiss what I said
Return the favour?

Your tutorial there says nothing about creating trackables on map intialisation. It appears to me those links are not relevant.

10 seconds of trackable creation being moved into the load screen will not cause a load time of 10 seconds to increase to 2 minutes. If I missed your point, then you're probably off topic.

 

[Steel]

I continue to say you can mask this and still reduce the load time of your map. When do you ever need a player to use a trackable the instant a map starts? Mask what you need to do at 0.01. You always have to figure people playing your map could have an ancient computer, load times on those could be even worse and when the map is done loading you get the dreaded Waiting For Player. After everything for display is done, rendered, compiled and loaded you can push the rest of your map's features.

I'm saying what Executor did was a good feature. I gave you exaggerated numbers to a reason to prove a point: preloading isn't the best option if you can mask it their creation in game. Does anyone ever read my entire post?

My best example is this. I have an unprotected version of DoTA before and after it's complete optimization from about a 1.5 minutes of average load time to the now 2-10 seconds. I know that absolutely everything that was preplaced and done during the traditional map load was moved to execute after map start up just like I stated. This is how the game got such huge appeal ontop of it's already popular game play. What if your game can be ruined by a single person leaving and you need to rehost? Yes, let's go ahead and do that.

 

[Jesus4Lyf]

Hey, probably taking this a bit too seriously. I read your posts and respect your opinion. Excuse my joke before regarding your numbers.

I'm one of the people with an ancient computer. That's why I said load screen is preferable - won't disconnect when a swarm of trackables are made when the map begins.

You may need trackables immediately useable in a map where the map is based on trackables, otherwise you wait in the load screen or you wait when the map has loaded.

>I'm saying what Executor did was a good feature.
Sure. Options for mappers are good. Nonetheless, I'm not sure there's a practical justification for its use...

PS.
DotA does a lot of things like preloading abilities, we're talking trackables in this thread...

 

[Steel]

I'm one of the people with an ancient computer. That's why I said load screen is preferable - won't disconnect when a swarm of trackables are made when the map begins.

Yea this is a problem with the WC3 engine and further proves it is garbage. If you take too long to load the others will be in game and you can get dropped.

I know what you're saying. I understand it. I know why you're saying it. You're talking about trackables here, I mearly commented on preloading vs doing it at 0.01 elapsed...I know things are different here in WC3 than what I do programming for so my roots from that are probably ingrained deeply into what I'm saying. The point I guess I'm trying to get across is, why would you have anything loaded up when the map is loading that has the possibility of not being used? I hate when I see a TD map do this for their 50 levels. Why have it load up level 50 if the players never get through 10?

That's all I've been trying to convey. Not trying to sound like an asshole.

 

[Executor]

Thank you for your support, Steel!

I understand why Jesus4Lyf prefers the TrackMap's to load in the loadingscreen.
He assumes that the game starts immediately, but think of it:
Which types of Map's will use a TrackMapSystem?

for ex.:
Ingame Editor
Uther's Party

I most cases both have whether a setting phase or a video sequence after loadingscreen is done. So there is enough time to generate these.
And Uther's Party for ex. will maybe load the TrackMap even later, because other mini games could be before this one.

Well, reasonable or not it always depends on the game type and the starting phase of the map, here is no reason to argue

Well, let's stick to the topic and compare my bugcreating TrackMapSystem to Azlier assimilable solution, I unfortunately like more than mine.

 

[Azlier]

Don't feel bad. Yours can do one thing mine most certainly cannot: track the position of the mouse when not clicking.

 

[Sevion]

Don't feel bad. Yours can do one thing mine most certainly cannot: track the position of the mouse when not clicking.

Even though that'd be easily remedied? XD

 

[Azlier]

Not at all. Mine doesn't use trackables.

 

[Sevion]

Oh? Not anymore? I thought it did. Each Trackable2 was 12 trackables?

 

[Executor]

Azlier doesn't mean his trackable2 sys, instead he refers to this post:

If I were to base a map on this track map thingy, wouldn't it be laggier and inaccurate compared to this solution?

It detects the X/Y of left clicks and can detect right clicks with ease.

(Btw. as far as I 'researched' trackable2 it's still only one trackable per struct.)

 

[Azlier]

Trackable2? No. No no no no no no no. No. No? No!

We weren't talking about Trackable2, we were talking about this product of mine!

Yes, Trackable2 does detect tracking. Why shouldn't it?

EDIT: Bawww.

>(Btw. as far as I 'researched' trackable2 it's still only one trackable per struct.)
Nonsense. 0 trackables per struct. Magic? Yes!

 

[Sevion]

Lol, ok, sorry about the confusion.

 

[Executor]

>(Btw. as far as I 'researched' trackable2 it's still only one trackable per struct.)
Nonsense. 0 trackables per struct. Magic? Yes!

Sry got it wrong there are indeed 12 trackables per struct. I don't know what exactly of your code should be 'magic' but you still create with your normal "create" method 12 trackables per struct instance if you want it to see or not. Just because you don't store them in variables, aren't they 'puffed' away.

But I was right in one point:
The "createforplayer" function only generates one trackable per struct instance.

I just don't understand what you want to tell me with your 'Magic' pribble-prabble.

 

[Azlier]

I don't have to store no trackables in the struct. That isn't magical?