Mirage Source
http://web.miragesource.net/forums/

Why are we using/wasting so many loops?
http://web.miragesource.net/forums/viewtopic.php?f=201&t=1154
Page 1 of 29

Author:  Obsidian [ Sat Jan 13, 2007 8:37 pm ]
Post subject:  Why are we using/wasting so many loops?

I was just thinking about it... and everytime something of necessity happens... that affects, everyone that's playing... we use a

for i = 1 to max_players (or highindex, if you used the tutorial for it)

and then the next step... is to do, if IsPlaying(i)


WHY!?!........ shouldn't we just simplify the entire process and save loops by doing for i = 1 to totalonlineplayers? TotalOnlinePlayers stores the current number ACTUALLY PLAYING. So instead of looping 50 + times, when chances are it only needs to do it 13 times or so... why don't we just use TotalOnlinePlayers?

Author:  Joost [ Sat Jan 13, 2007 8:54 pm ]
Post subject: 

Fine..

In Joingame
(Note, you can just do + 1 too, but I think that's just a bit too buggy, plus, a recount every now and then isn't going to hurt anyone
Code:
    For i = 1 To MAX_PLAYERS
        If IsPlaying(i) Then
        PlayersOnline = PlayersOnline + 1
    End If
    Next i

somewhere:
Code:
Public PlayersOnline As Byte


In leavegame
Code:
    PlayersOnline = PlayersOnline - 1


And replace most instances of MAX_PLAYERS with PlayersOnline.


Not tested.

Author:  Obsidian [ Sat Jan 13, 2007 8:57 pm ]
Post subject: 

PlayersOnline?

why add a totally new variable? TotalOnlinePlayers is already stored in every version of MS that has been released. Instead of doing a for i = 1 to max_players, just do a for i = 1 to TotalOnlinePlayers saves a TON of loops.

I'll release a tutorial on it in a bit. Nice little optimization for MSE2 as well. :D

Author:  Joost [ Sat Jan 13, 2007 9:02 pm ]
Post subject: 

It is? Lol, never noticed.

Author:  Obsidian [ Sat Jan 13, 2007 9:05 pm ]
Post subject: 

I actually just had a question pertaining to this though... Say There are 4 players logged in


1 2 3 4

Player 3 logs out.... So is the Index # for player 4, now 3? Because if it isn't... and you do a for i = 1 to totalonline players (3), then would it miss #4. I think i'm overthinking now... and i'm confusing myself.

Author:  grimsk8ter11 [ Sat Jan 13, 2007 10:46 pm ]
Post subject: 

TotalOnlinePlayers in no way matches up with the indexes.

Author:  Obsidian [ Sat Jan 13, 2007 11:12 pm ]
Post subject: 

Scrap this topic. I realized how way off it was... and why it wouldn't make sense to use.

Author:  Obsidian [ Sat Jan 13, 2007 11:24 pm ]
Post subject: 

Actually... would it be possible/practical to append the user's index # as people left and what not, so totalonlineplayers could be an accurate counter, and align itself with the player's indexes?

Author:  Matt [ Sat Jan 13, 2007 11:37 pm ]
Post subject: 

Are you sure it's in each version of MS? I couldn't find it. O_o

Author:  William [ Sat Jan 13, 2007 11:38 pm ]
Post subject: 

totalonlineplayers is the same as high_index.

Author:  Gilgamesch [ Sat Jan 13, 2007 11:50 pm ]
Post subject: 

William wrote:
totalonlineplayers is the same as high_index.



so then there is no reason for adding high_index o.O

Author:  Obsidian [ Sun Jan 14, 2007 12:09 am ]
Post subject: 

totalonlineplayers isn't the same... totalonlineplayers just holds a count... highindex stores players index without a wasted loop. It would be ideal to use highindex for now though.

Author:  William [ Sun Jan 14, 2007 12:31 am ]
Post subject: 

Obsidian wrote:
totalonlineplayers isn't the same... totalonlineplayers just holds a count... highindex stores players index without a wasted loop. It would be ideal to use highindex for now though.

Still High_index isn't correct. It can easily get misscounted and give inaccurate values. Grim explain some to me, high_index can be wrong.

Author:  grimsk8ter11 [ Sun Jan 14, 2007 2:25 am ]
Post subject: 

TotalOnlinePlayers to be used to manage was, to an extent, a genius idea. The problem with TotalOnlinePlayers is the opposite of the problem with High_Index, it always fluctuates back downwards, leaving anyone with an index over it, left in the cold. High_Index works only because it keeps the number of players that were EVER logged in during that run of the server, so it includes the highest index if they don't log out but the people below them do. This can basically just get as out of hand as MaxPlayers can if it gets high enough, but then again, if it gets that high, its most likely that it will continually be used.

Changing the players index is very possible, possible also very confusing to do if you don't have it all figured out in your head, but you would also have to interrupt loops and fun stuff like that that constantly run so it could update as to what the true index it is on really is.

Overall MaxPlayers, or any loop through a large number is a bad thing to have, and there are better ways of doing it, but seeing as the whole system of Mirage is based on index, it would be a pain in the ass to fix.

Author:  Obsidian [ Sun Jan 14, 2007 3:10 am ]
Post subject: 

bummer... i thought maybe i had something worth an attempt thought up.

Author:  Spodi [ Sun Jan 14, 2007 6:04 am ]
Post subject: 

Why not just store the highest index of the array, and resize the array appropriately when needed? Every new character/npc/object/etc, you loop through the array checking for an unused slot, and if there is none, just redim preserve the array + 1 in size and update the last index value. Only time you'd ever loop through unused indexes is if entries not at the end of the array was removed, and nothing was added to fill in the gaps inside the array.

Shouldn't really even be too big of a problem, though, for the most part. Users you only have to update every X ticks to change their statuses (spells running out, hp/mp raising). The rest is event-based from the packets. For NPCs, you can loop through them, see if the map they are on has anyone on it first, then do the AI, which unless the AI is complex, should be quick and easy. For objects, you only have to update every minute or so to remove them if they have been on the ground too long and thats it - you don't even have to check that every loop.

Author:  grimsk8ter11 [ Sun Jan 14, 2007 1:46 pm ]
Post subject: 

Resizing the array is fine, and I mentioned that, but, like I stated, you'd have to interrupt some of the looping that already goes on, like packet handling, or just update the array there, but there is alot to watch out for. I know in C++ I use socket based instead of index based, so the socket is actually part of the player and the only reason there is a player array is so i can kick/ban players.

Author:  Spodi [ Sun Jan 14, 2007 3:02 pm ]
Post subject: 

Quote:
Resizing the array is fine, and I mentioned that,


Oops, sorry about that. I was skim-reading. :oops:

Quote:
you'd have to interrupt some of the looping that already goes on, like packet handling,


I wouldn't see many places where you'd have to watch out too much. I recently just noticed I went all this time having vbGORE with a constant array size for the users, and got a few errors on the opening/closing of new characters after changing it. So yeah, it is pretty easy to mess up, but often easy to fix if you know how your code works (which I'm sure anyone who has spent a few months in Mirage does). I guess that wouldn't really help much for the looping, though, since you can still sort them into a large array just as easily - it just allows you to use as little ram as needed, while allowing for as large of arrays as needed.

What would be nice, is to keep an array pointing to which NPCs to update. This would allow you to completely ignore NPCs with no users on the map (as long as you handle accordingly when a user changes maps, logs in, and logs off). Though not sure if it'd be worth the cost of updating/maintaining that array in the long run, though, since you can often skip through a NPC not using any AI very quickly (just a matter of one or two "If X (>, <, =) Y" calls).

Sorry, I'm just rambling now. :wink:

Author:  Bakekitsune [ Thu Feb 15, 2007 10:26 pm ]
Post subject: 

the only way to do it well i would think would be making variable for player(1 to max_players) dynamic and then have a formula for working out wat the max of that variable is.

So public player() 'becomes dynamic variable
Find a formula for what player() is at its most.


because player() only goes through online players not every single account.

e.g 3 players = player(3)'s stats will be set, but once you go past it, it goes through players with just "0" for every state, but if you have 250meg of RAM its not even a problem the biggest waste is the amount of large size variables that are declared in the source and packet lag.

Author:  Obsidian [ Thu Feb 15, 2007 11:43 pm ]
Post subject: 

I made another post somewhere about how i ended up doing it... i just did a
Code:
For i = 1 to max_players
    whatever whatever (this is what calculated the TotalOnlinePlayers)
    OnlinePlayer(TotalOnlinePlayers).Index = i
next i


Then everywhere else i just ended up doing for i = 1 to totalonlineplayers... then i just pulled their index back out from that...

Author:  Bakekitsune [ Fri Feb 16, 2007 9:18 am ]
Post subject: 

i actually havent tested this but "array.length" is used to find the length of an array, i assume that is the highest index.

//declare
public player()

for i = 1 to player().length
//Procedure goes here
next i

if that doesnt work then
When the server send the "loginok" packet, increase player().length +1 and send a packet. (decrease by 1 when a player logs out and send packet)

Another way could be

for i = 1 to max_players
if player(index).name = "" then
exit for
else
//procedure goes here
next i

Author:  wanai [ Wed Dec 01, 2021 1:18 pm ]
Post subject:  Re: Why are we using/wasting so many loops?

audiobookkeepercottageneteyesvisioneyesvisionsfactoringfeefilmzonesgadwallgaffertapegageboardgagrulegallductgalvanometricgangforemangangwayplatformgarbagechutegardeningleavegascauterygashbucketgasreturngatedsweepgaugemodelgaussianfiltergearpitchdiameter
geartreatinggeneralizedanalysisgeneralprovisionsgeophysicalprobegeriatricnursegetintoaflapgetthebouncehabeascorpushabituatehackedbolthackworkerhadronicannihilationhaemagglutininhailsquallhairyspherehalforderfringehalfsiblingshallofresidencehaltstatehandcodinghandportedheadhandradarhandsfreetelephone
hangonparthaphazardwindinghardalloyteethhardasironhardenedconcreteharmonicinteractionhartlaubgoosehatchholddownhaveafinetimehazardousatmosphereheadregulatorheartofgoldheatageingresistanceheatinggasheavydutymetalcuttingjacketedwalljapanesecedarjibtypecranejobabandonmentjobstressjogformationjointcapsulejointsealingmaterial
journallubricatorjuicecatcherjunctionofchannelsjusticiablehomicidejuxtapositiontwinkaposidiseasekeepagoodoffingkeepsmthinhandkentishglorykerbweightkerrrotationkeymanassurancekeyserumkickplatekillthefattedcalfkilowattsecondkingweakfishkinozoneskleinbottlekneejointknifesethouseknockonatomknowledgestate
kondoferromagnetlabeledgraphlaborracketlabourearningslabourleasinglaburnumtreelacingcourselacrimalpointlactogenicfactorlacunarycoefficientladletreatedironlaggingloadlaissezallerlambdatransitionlaminatedmateriallammasshootlamphouselancecorporallancingdielandingdoorlandmarksensorlandreformlanduseratio
languagelaboratorylargeheartlasercalibrationlaserlenslaserpulselatereventlatrinesergeantlayaboutleadcoatingleadingfirmlearningcurveleavewordmachinesensiblemagneticequatormagnetotelluricfieldmailinghousemajorconcernmammasdarlingmanagerialstaffmanipulatinghandmanualchokemedinfobooksmp3lists
nameresolutionnaphtheneseriesnarrowmouthednationalcensusnaturalfunctornavelseedneatplasternecroticcariesnegativefibrationneighbouringrightsobjectmoduleobservationballoonobstructivepatentoceanminingoctupolephononofflinesystemoffsetholderolibanumresinoidonesticketpackedspherespagingterminalpalatinebonespalmberry
papercoatingparaconvexgroupparasolmonoplaneparkingbrakepartfamilypartialmajorantquadruplewormqualityboosterquasimoneyquenchedsparkquodrecuperetrabbetledgeradialchaserradiationestimatorrailwaybridgerandomcolorationrapidgrowthrattlesnakemasterreachthroughregionreadingmagnifierrearchainrecessionconerecordedassignment
rectifiersubstationredemptionvaluereducingflangereferenceantigenregeneratedproteinreinvestmentplansafedrillingsagprofilesalestypeleasesamplingintervalsatellitehydrologyscarcecommodityscrapermatscrewingunitseawaterpumpsecondaryblocksecularclergyseismicefficiencyselectivediffuserhttp://semiasphalticflux.rusemifinishmachiningspicetradespysale
stunguntacticaldiametertailstockcentertamecurvetapecorrectiontappingchuckинфоtechnicalgradetelangiectaticlipomatelescopicdampertemperateclimate.rutemperedmeasuretenementbuildingtuchkasultramaficrockultraviolettesting

Author:  wanai [ Mon Jan 31, 2022 5:04 am ]
Post subject:  Re: Why are we using/wasting so many loops?

curi

Author:  wanai [ Mon Jan 31, 2022 5:05 am ]
Post subject:  Re: Why are we using/wasting so many loops?

201.1

Author:  wanai [ Mon Jan 31, 2022 5:06 am ]
Post subject:  Re: Why are we using/wasting so many loops?

PERF

Page 1 of 29 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/