massiv-devel Mailing List for Massively multiplayer game middleware

Cau,
nacommitoval jsem configy pro spusteni 2 serveru a jednoho klienta.
Bezi to, to je dobra zprava, ale po chvili, kdyz mezi sebou ty servery
nekomunukuji se chteji od sebe odpojit a hodi to assert -
Assertion failed: Server node is trying to kill another server node. Not implemented., file c:\projekt\massiv\massiv\src
\core\object\node_manager.cpp, line 1276

Jsi si jistej, je to ok? Podle me node_manager vubece nemusi zajimat
close connexe na jiny server, pouze lost. Ta zavrena conexe mezi
servery je pro vyssi vrstvy neviditelna tzn, ze muzes klidne posilat
zpravy na ten server atd. Driv tam ten assert nebyl a bylo to lepsi.
Ja bych ho odendal.
Octa

From: "Marek Vondrak"



> >> Pote, co mi to uspesne smaze ten soubor, tak to padne v tom for cyklu
> >> na radku 394 v archive_manager.cpp
> >> ArchivationId archivation_id = it->first;
> >
> >Zeby std::map::erase() invalidovalo vsechny iteratory?
> 
> Nechce se mi tomu verit. Neco se musi posrat predtim.


Tak je to jasne, problem je v tech reverse iteratorech.
Reverse iterator totiz je definovan jako jemu odpovidajici
iterator - 1, tzn. v podstate pouze wrapper nad normalnim
iteratorem.
Tzn.
rend() == reverse_iterator( begin() ) == ( begin() - 1 );

Z toho plyne, ze pokud se smaze prvni prvek containeru,
rend() "zmeni" hodnotu.
Tzn. nasledujici assert selze:
reverse_iterator rit = c.rend();
c.erase( c.begin() );
assert( rit == c.rend() ).

Coz je presne to, co se deje pri mazani archivu.


Petr

Btw pro normalni iteratory (ukazujici do list, map apod.)
todle neplati, uz se to
v konferenci parkrat objevilo, ale pro uplnost:
nasledujici assert neselze:

iterator it = c.end();
c.erase( c.end() - 1 );
assert( it == c.end() );

PT> Jedna se o pracovni srazy clenu teamu nekolik
PT> po sobe jdoucich dni v naplni zhruba 4 hodiny
PT> denne venovane kolektivni prace na massivu.

PT> Ocekavani:
PT> - Urychleni vzajemne komunikace (doba pingu):
PT> Problemy se v aktualnim stavu resi
PT> v idelanim pripade zhruba 5 dnu (1. den formulace
PT> problemu/todo mailem, 2. a 3. den prijeti odpovedi,
PT> 4. a 5. den dohadovani jak to teda nakonec ma byt),
PT> coz nemluvime o vlastnim programovani.
PT> Pri pracovnich schuzich by se melo reseni zredukovat
PT> na 20 minut (kdyz se budou dohadovat vsichni dohromady).
PT> - Synchronizace praci za behu - moznost zadavat
PT> todo a usmernovat prace clenu okamzite (tyka se
PT> hlavne octy a hafa, u kterych je problem vycleneni
PT> nejake vetsino celku prace).
PT> - Flexibilni delegace ukolu.
PT> - Testovani vice serveru, zkouska spravy systemu
PT>   naostro (zive).

PT> Pokud by projekt pokracoval ve stejnem stavu jako doted,
PT> neni zadna zaruka stihnuti dalsi obhajoby.

PT> Pracovni srazy by se konaly ve skolnich labech
PT> (nebo pokud mate nekdo moznost sehnat mistnost
PT> s 5 kompy (vi nekdo kdy prifrci marekus?)).
PT> Rozchozeni massivu v labu berte jako
PT> vyzvu svych schopnosti pracovat v limitovanem
PT> prostredu.

Kolik mame dohromady notebooku? Pry ma moznost markoid ( stoupik to
kdysi psal ), marekus ma
jeden, ja taky. Mam i mobilni pripojeni na net.

PT> Veskere dalsi podrobnosti se projednaji na schuzi.

PT> Mozne reakce na tento mail:
PT> 1/ Souhlas - Za zkousku nic nedame, lze pouze ziskat.
PT> 2/ Nesouhlas - Dany clovek musi prijit s lepsim
PT>    navrhem, jak kriticky stav projektu vyresit.
PT> 3/ Nemuzu - Neprijatelne. Osobni cile (fulltime prace,
PT>    cestovani, ...) si odsunte o nekolik mesicu, pokud
PT>    budou prekazet).
PT> 4/ Zadna - Neprijatelne. I kdyz projekt trva nejaky
PT>    ten rok, neni zadny duvod aby nemohly nastat
PT>    personalni zmeny.

1/
Souhlasim. K urychleni by doslo. Jen bych byl pro nejakou rozumnou dobu na ty schuzky.
Nejsem proti treba uz od 6.00 rano nebo vecer 17.00+. Vikendy taky
nejsou problem.
Taky by urcite slo rict, ze nejaky vikend bude pracovni, klidne delsi schuze a prace.
Ubytovani mam do 8.9.2003, ale uz si hledam podnajem, takze to neni
problem.

K cemu se ale musim priznat, tak to je to, ze za 3 tydny bych mel asi
na mesic odjet do zahranici ( na vikendy bych mohl byt zase doma, ale
bude to narocne ) a neudelam uz s tim vubec nic, leda, ze by me
prejelo auto.

PT> Dale bych vsechny (krome stepana) poprosil, aby mi
PT> poslali telefonni kontakty na ne (jako osobni mail,
PT> nedoporucuju posilat primo do konfery).

Poslu.

PT> Petr

Pocitam s tim.

Haf

----- Original Message ----- 
From: "Petr Tovarys" <pto...@ss...>
To: "MASSIV-DEVEL" <mas...@li...>
Sent: Saturday, August 30, 2003 9:26 AM
Subject: [Massiv-devel] schuze 5.9.


> Caues,
> 
> Schuze se kona v patek 5.9. 2003 na MS
> v 9:00 (v pripade potreby odpoledne).
> Ucast povinna vsech.
> Co nejdrive potvrdte maila.
> 
> 
> Petr
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Massiv-devel mailing list
> Mas...@li...
> https://lists.sourceforge.net/lists/listinfo/massiv-devel
> 

PT> Caues,

PT> Schuze se kona v patek 5.9. 2003 na MS
PT> v 9:00 (v pripade potreby odpoledne).
PT> Ucast povinna vsech.
PT> Co nejdrive potvrdte maila.


PT> Petr

OK, pocitam s tim.
Octa

Caues,

Vzhledem k opetovne neobhajobe projektu a vsech
negativnich dusledku z toho vyplyvajicich jsem
nucen zorganizovat pracovni srazy vsech clenu
teamu s jedinym cilem - dokonceni projektu
v co nejkratsim case (neni ekvivalentni dokonceni
presne na termin obhajob).

Jedna se o pracovni srazy clenu teamu nekolik
po sobe jdoucich dni v naplni zhruba 4 hodiny
denne venovane kolektivni prace na massivu.

Ocekavani:
- Urychleni vzajemne komunikace (doba pingu):
Problemy se v aktualnim stavu resi
v idelanim pripade zhruba 5 dnu (1. den formulace
problemu/todo mailem, 2. a 3. den prijeti odpovedi,
4. a 5. den dohadovani jak to teda nakonec ma byt),
coz nemluvime o vlastnim programovani.
Pri pracovnich schuzich by se melo reseni zredukovat
na 20 minut (kdyz se budou dohadovat vsichni dohromady).
- Synchronizace praci za behu - moznost zadavat
todo a usmernovat prace clenu okamzite (tyka se
hlavne octy a hafa, u kterych je problem vycleneni
nejake vetsino celku prace).
- Flexibilni delegace ukolu.
- Testovani vice serveru, zkouska spravy systemu
  naostro (zive).

Pokud by projekt pokracoval ve stejnem stavu jako doted,
neni zadna zaruka stihnuti dalsi obhajoby.

Pracovni srazy by se konaly ve skolnich labech
(nebo pokud mate nekdo moznost sehnat mistnost
s 5 kompy (vi nekdo kdy prifrci marekus?)).
Rozchozeni massivu v labu berte jako
vyzvu svych schopnosti pracovat v limitovanem
prostredu.

Veskere dalsi podrobnosti se projednaji na schuzi.

Mozne reakce na tento mail:
1/ Souhlas - Za zkousku nic nedame, lze pouze ziskat.
2/ Nesouhlas - Dany clovek musi prijit s lepsim
   navrhem, jak kriticky stav projektu vyresit.
3/ Nemuzu - Neprijatelne. Osobni cile (fulltime prace,
   cestovani, ...) si odsunte o nekolik mesicu, pokud
   budou prekazet).
4/ Zadna - Neprijatelne. I kdyz projekt trva nejaky
   ten rok, neni zadny duvod aby nemohly nastat
   personalni zmeny.


Dale bych vsechny (krome stepana) poprosil, aby mi
poslali telefonni kontakty na ne (jako osobni mail,
nedoporucuju posilat primo do konfery).


Petr

Caues,

Schuze se kona v patek 5.9. 2003 na MS
v 9:00 (v pripade potreby odpoledne).
Ucast povinna vsech.
Co nejdrive potvrdte maila.


Petr

>> Pote, co mi to uspesne smaze ten soubor, tak to padne v tom for cyklu
>> na radku 394 v archive_manager.cpp
>> ArchivationId archivation_id =3D it->first;
>
>Zeby std::map::erase() invalidovalo vsechny iteratory?

Nechce se mi tomu verit. Neco se musi posrat predtim.

-- Markoid
=00

From: "Ondrej Pecta"


> Pote, co mi to uspesne smaze ten soubor, tak to padne v tom for cyklu
> na radku 394 v archive_manager.cpp
> ArchivationId archivation_id = it->first;


Zeby std::map::erase() invalidovalo vsechny iteratory?
Safra safra.
Ale je divne, ze pak nepada core test, tam jsou na to testiky.
Mozna je problem v tom, ze se tam pouzivaji
reverzni iteratory, takze mozna erase() invaliduje
reverzni iteratory ??

Dela se tam totiz todle:

map                   m;
map::reverse_iterator it;

for( it = m.rbegin(); it != m_rend(); )
{
ArchivationId aid = it->first;
it++;
m.erase( aid );
}


Btw pokud potrebujete disablovat to mazani archivu,
tak pouzijte settings
[ Settings/ArchiveDatabase ]
keep_archives_count : integer = -1


Petr

Hello Ondrej,

Friday, August 29, 2003, 8:03:46 PM, you wrote:


OP>> Size : 16 archive_database info: Removing obsolete archives...
OP>> !archive_database info: Removing 'archives/regular/massiv_0000000004.archive' archive file.
OP>> !file_system error: *** Exception on Fri Aug 29 16:38:33 2003

OP>> archives/regular/massiv_0000000004.archive is not a file.
OP>> Call-stack history:
OP>> <root>
OP>> Unhandled non-massiv exception.

OP>> zkusim to debugnout, cim to je, myslim, ze mi Haf rikal, ze mu ten
OP>> server taky furt pada. Ze by jen MSVC7 only?
OP>> Octa
OP> Pote, co mi to uspesne smaze ten soubor, tak to padne v tom for cyklu
OP> na radku 394 v archive_manager.cpp
OP> ArchivationId archivation_id = it->first;

ale kecam v archive_database.cpp
sorry
Octa

OP> Size : 16 archive_database info: Removing obsolete archives...
OP> !archive_database info: Removing 'archives/regular/massiv_0000000004.archive' archive file.
OP> !file_system error: *** Exception on Fri Aug 29 16:38:33 2003

OP> archives/regular/massiv_0000000004.archive is not a file.
OP> Call-stack history:
OP> <root>
OP> Unhandled non-massiv exception.

OP> zkusim to debugnout, cim to je, myslim, ze mi Haf rikal, ze mu ten
OP> server taky furt pada. Ze by jen MSVC7 only?
OP> Octa
Pote, co mi to uspesne smaze ten soubor, tak to padne v tom for cyklu
na radku 394 v archive_manager.cpp
ArchivationId archivation_id = it->first;
Octa

PT> To nevim, me to vsechno funguje (msvc6), tzn. archivy se mi mazou
PT> (na ty se pristupuje pres native fs), a nepada mi to.

PT> Petr

Size : 16 archive_database info: Removing obsolete archives...
!archive_database info: Removing 'archives/regular/massiv_0000000004.archive' archive file.
!file_system error: *** Exception on Fri Aug 29 16:38:33 2003

archives/regular/massiv_0000000004.archive is not a file.
Call-stack history:
<root>
Unhandled non-massiv exception.

zkusim to debugnout, cim to je, myslim, ze mi Haf rikal, ze mu ten
server taky furt pada. Ze by jen MSVC7 only?
Octa

PT> K editboxu:
PT> Ten button_click_on_enter si mel udelas spis
PT> zadefinovanim noveho message receiveru pro
PT> edit box, tzn. ze by edit box generoval zpravy,
PT> ze nekdo zmackl enter.

Done, je to tak mnohem lepsi, da se handlovat cokoliv.

PT> K tem prev a next widgetum, nalinkovanym
PT> k edit boxu - ted do toho nevrtej, ja to budu
PT> predelavat jako obecnou vlastnost widgetu.

Ted uz by to pripadne taky slo pres EditBoxMessageReceiver - hlidat si
to v login_dialog.

PT> Petr

Hello Stepan,

Friday, August 29, 2003, 12:32:17 PM, you wrote:

SV> On Thursday 28 of August 2003 20:55, Ondrej Pecta wrote:

>> Koukal jsem na webu na ty interlocked metody a nikde nepisou nic o tom,
>> ze by to melo nejaky hacek. Klidne bych je pouzil, horsi je to ale s
>> unixem, ten tam nic nema? Nasel jsem hinty jen jak to udelat pomoci asm v
>> cpp... Je tu nejaky Linuxar, kdo s tim ma zkusenost?

SV> Neni. Kdyztak to opras pomoci jednoho globalniho mutexu jako je to tedka (ale 
SV> primo unixoidniho mutextu nekde uvnitr interne v implementaci tech 
SV> atomickejch metod - ne pres ten nas interface, ktery potrebuje globals).

SV> -- Stoupik

No uz jsem tam neco commitnul, tak si to opras, je to na to
pripraveny, i kdyz to co jsem nasel, tak "pry" ma fungovat.
Octa

>Prechod na RPC k=20
>replikam by znamenal asi dost velke zmeny v libu.

Nevim jak se maji pouzivat, ale snad je to normalni RPC? Tudiz misto =
primeho praseni do ClientXxx, se pouzije RPC na ClientXxx - samozrejme =
jen v tech pripadEch, kdy chceme, aby se klient dozvedel o zmene ihned; =
napr. Pri presunu itemu v inventorari. Replica client by navic mohl po =
dokonceni RPC zavolat ten update callback, tudiz v clientu by se =
nemenilo nic.

A na predikce neni vubec=20
>nic trivialniho (pokud teda nemyslis extrapolici, ktera zase vypada =
dost=20
>podivne).=20

Samozrejme jenom extrapolaci. Viz specifikace, tam je receno "predikce =
(extrapolace)".

-- Markoid
=00o delat.
>
>-- Stoupik
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Massiv-devel mailing list
>Mas...@li...
>https://lists.sourceforge.net/lists/listinfo/massiv-devel
>
>
=00

>> 3) zarucuje replicaclient, ze
>> replika neni zrusena, kdyz na ni ukazuje strong stack pointer?
>
>Ne a ani by IMO nemel, protoze by pak nemohl zarucovat poradnou =
konzistenci=20
>replikacnich skupin.

Podle me strongptr ma zarucit, ze kdyz se mi ho podari dereferencovat =
jednou, pak i opakovane.
Pokud navic updaty pobezi jen na urovni 0 (je to tak?), pak je toto =
zaruceno.

-- Markoid
=00

On Saturday 23 of August 2003 22:37, Petr Tovarys wrote:
> Caues,
>
> Stepane, ty replikacni masky mas porad blbe,
> takze aktualni verse na cvs nefunguje (replikuje
> se cela migracni skupina playera)
>
> Ty vsude pises, ze kazda repflags_yes musi
> obsahovat MIGRATE bit, cili 0b0001.
>
> Jenomze client_repflags_yes si nastavil na 5 = 0b1001,
> coz znamena ze
>
> # Property will be serialized iff:
> # ( property_repflags & ( repflags_yes | repflags_no ) ) == repflags_yes
> # ie. all repflags_yes bits are set and no repflags_no bits are set.
>
> bude vzdycky true -> bude se replikovat vsechno, protoze
> property_repflags vzdy obsahuje 0b0001, a repflags_yes
> taky vzdycky obsahuji 0b0001.

Ne:
0b0001 & ( 0b1001 | 0b0000 ) = 0b0001 != 0b1001, takze se to replikovat nema. 
Replikuje se pouze kdyz _VSECHNY_ repflags_yes bity jsou v property_repflags 
nastaveny, jinak ne. Pokud ano, je tam nekde neco blbe, ale todle ne. Btw. 
pokud by se replikovala cela migracni skupina vcetne server-only objektu, 
replica client by IMO mel zahodit cely replikacni paket, takze by se nic 
nezreplikovalo.

> Pokud prvni bit node_repflags je 1, znamena to,
> ze pri replikaci na tento node se replikuje CELA
> migracni skupina.
> Pokud prvni bit node_repflags je 0, selze assert
> Property::should_serialize(), ktery rika
>
> assert( flags_on( desc.repflags_yes, REPFLAGS_MIGRATE ) ||
>             ( !desc.repflags_yes && !desc.repflags_no ) );
>
> Podle me to ma byt takhle:
> Property repflags_yes ma vzdy obsahovat 0b0001.
> Pri migraci se node_repflags_yes maji ignorovat.
> node_repflags_yes se maji pouzivat jen pri replikaci
> a tudiz prvni bit by mel byt 0, aby se nereplikovala
> cela migracni skupina.

Ne, viz. vyste.
Precti si poradne komentare v massiv.replication.conf.

-- Stoupik

On Tuesday 26 of August 2003 19:07, Martin Havlista wrote:
> > No urcite ne radky "false", "1", ale misto toho vhodna slova. Viz
> > serializace objektu. Tam taky proste neni radka, kde se z cista jasna
> > objevi treba "1". Je tam treba "serialize" / "noserialize". Melo by to
> > byt hierarchicke (dle me staci vhodny popis uzlu a nemusi byt zvlast
> > sekce [dataobject]). Misto bloku "{", "}" jako u objektu neco jako
> > "@node", "@endnode".  Tohle jsou ale akorat moje navrhy, myslim, ze
> > Stepan se k tomu jiz vyjadril dost detailne.
>
> Prave ze se k tomu ani moc nevyjadril. Tak at se vyjadri i on,
> udelam z toho mix, a pak to predelam.

Myslim, ze jsem se k formatu vyjadroval nekolikrat, ale uz tak davno, ze to 
nejsem schopen najit. Tak si neco tedka za minutku vymyslim, ale mozna by te 
mohl pouzitelnejsi format napadnout sam od sebe:

1. Stromy psat hierarchicky, tj. ne vzdy cela cesta jako treba
   /image_default/image_login_picture
(coz je jeste pekna kratka cesticka).

2. Parametry psat tak, aby slo poznat, co to je zac.

Takze napriklad:
(je to PRIKLAD, tj. nektere hodnoty jsou jinak nez maji byt, jenom aby 
demonstrovaly jak by to mohlo vypadata)

node image_default
  type necessary_client
  type necessary_server
  file "image/default.png"

  node image_login_picture
    obsolete
    type client
    file "image/login.png"
  endnode

endnode

Nebo cokoliv podobneho, proste radkove, citelne, hierarchicke. Poradi radek 
neni pevne urceno, co je to zac se pozna z prvniho slova.

Vysvetleni jak je to mysleno:
- type XXX muze byt specifikovano vicekrat, naoruje se (pokud teda spravne 
chapu jak to v DM funguje, pokud je to jinak, at je to tak - porad presne 
nechapu vyznamy download type CLIENT a SERVER). Prijemnejsi by bylo mit to na 
jedne radce, ale o neco slozitejsi naparsovat (i kdyz nic tezkeho).
- file XXX je snad jasne.
- node zacina novy uzel - potomka uzlu, ve kterem je to napsano (takze spis 
cely podstrom). Nainicializuje node do rozumneho defaultniho stavu, takze 
absence radek "type" a "obsolete" je ok. Absence radky "file" se da testovat 
pri "endnode" a pak se hodi error.
- endnode konci definici uzlu.
- obsolete je myslim vyznam toho true/false flagu. Nema smysl tam psat to 
true.

Nasleduje config, ktery udela uplne totez, jenom je to trochu jinak napsane 
(neprehlednejc; melo by to jit precist tim samym parserem se stejnym 
vysledkem):

node image_default
type necessary_client
node image_login_picture
file "image/login.png"
type client
obsolete
endnode
type necessary_server
file "image/default.png"
endnode

Dale by stalo za uvahu:
1. Moznost specifikovat ten samy node vicekrat, testovat uplnost az na uplnem 
konci souboru. Hazet warningy kdyz je specifikovano "file" nebo podobna 
polozka vicekrat.
2. Includovani jinych souboru.

Pr. poziti:

=== .description_main

node image_default
   type necessary_client
   file "image/default.png"
endnode

include ".description_textures"
include ".description_client_images"

=== .description_client_images

node image_default
  node image_background
    type client # presne nechapu
    file "image/background.jpg"
  endnode

  # atd.

endnode

=== .description_textures

node image_default
  node white
    # Zadny type neni imo potreba, textury by se pri startu tahat nemely.
    # Ze se tedka nahodou vsechny data objecty pouzivaji hned je vedlejsi.
    file "texture/white.png"
  endnode

  # atd.

endnode
    
=== end

O co mi jde:
- Hlavni soubor zminuje pouze bezpodminecne nutne data objecty.
- Pak includuje soubory podle ruznych kategorii, aby v tom nebyl naprosty 
maglajz.
- Pokud tyto soubory rozsiruji existujici node (podnody), pak to delaji jak je 
uvedeno. Samozrejme by taky slo includovat napr. .description_textures primo 
z definice node image_default, ale takhle se mi to osobne libi vic.

A nebo si vymysli neco uplne jineho a treba hezciho, osobni aktivite se meze 
nekladou, i kdyz uz ji asi malokdo ocekava.

-- Stoupik

On Thursday 28 of August 2003 17:54, Marek Vondrak wrote:

> Ahoj,
> nebylo by lepsi misto assertu v techto souborech bud pouzit vyjimky nebo
> panic()? Myslim, ze tam, kde to muze spadnout v dusledku nespravneho
> pouziti ze strany uzivatele (napriklad SRPC z klienta, spatne parametry do
> Object::cancel_replication, apod.), by se mela vypsat popisujici hlaska.

Myslim, ze spousta podivnych veci se v rpc.cpp pisedo logu (aspon je tam toho 
teda dost, mozna by se melo neco pridat). Co konkretne mas na mysli (staci 
cislo radky).

A "uzivatelem" myslis asi toho, kdo pise lib, ne toho, kdo klika po krajince. 
Pak by tam bylo podobnych veci asi o dost vic nez jenom ty dva zdrojaky. STL 
ti taky pada, kdyz ho pouzivas spatne. Je to takovy problem?

> Dalsi vec, je jestli by podobne v generovanych
> tridach nemelo byt misto "Can not create instance of abstract class." neco
> zajimavejsiho. Navic tahle hlaska je v exaci asi 50x.

A co by tam melo byt, nejaka vtipna prupovidka? (asi teda myslis jmeno te 
tridy, jestli ti spravne ctu myslenky...)

-- Stoupik

On Tuesday 26 of August 2003 17:51, Marek Vondrak wrote:

> - Lamp je podobne jako Entity nebo Sector rozdeleno na 2 casti -
>   server only cast (Lamp v lib/server) a shared cast (ClientLamp v
> lib/shared); ClientLamp drzi jen ty atributy, ktere se maji replikovat na
> klienta (tj. stav pro Light), Lamp drzi pointer na ClientLamp a
> implementuje Logic a Entity interface

Ne ze by na klientu byla nejaka rozumna sprava zdroju svetel apod. Svetla v 
TerrainManager jsou jenom hack a hned tak to vylepseno nebude. Problem je, ze 
zapinat v OpenGL vic nez tak 4 svetla najednou bych radsi nedelal (minimalni 
maximum ktere driver musi umet je 8), asi to kdyztak bude per-terrain (vybere 
se X nejblizsich zdroju). Zatim ale nic...

-- Stoupik

On Friday 29 of August 2003 11:00, Marek Vondrak wrote:

> Myslim, ze stavajici nastaveni replikaci je hodne prestrelene. Nyni se
> vsEchno replikuje 5x za sekundu, coz v pripade 10 objektu, ktere se
> pohybuji, a replikacnich skupin okolnich sektoru podobne velkych znamena
> load asi 9 x 10 x 10 x 5 = 4K dat. To me prijde dost, protoze tezko jeden
> objekt nacpes do 10 bytu a to si pis, ze objekty budou dirty. Resenim je
> pouzit RPC k replikam (pro to ho taky Stepan udelal). Napriklad veskere
> presuny v inventorari takto. Pak se klient dozvi o zmene hned a presto je
> mozne provadet updaty replik treba jen jednou za sekundu nebo pro efekt a
> demonstraci jeste min casto. Pohyb entit se da predikovat velice trivialne
> a navic je ve specifikaci.

Zatim je to takhle rozhodne OK a nic bych na tom nemenil. Prechod na RPC k 
replikam by znamenal asi dost velke zmeny v libu. A na predikce neni vubec 
nic trivialniho (pokud teda nemyslis extrapolici, ktera zase vypada dost 
podivne). Zatim proste tu frekvenci snizit nemuzem, protoze by to 
nefungovalo. Lze o tom uvazovat az to celkove bude neco rozumneho delat.

-- Stoupik

On Tuesday 26 of August 2003 14:08, Marek Vondrak wrote:

> 3) zarucuje replicaclient, ze
> replika neni zrusena, kdyz na ni ukazuje strong stack pointer?

Ne a ani by IMO nemel, protoze by pak nemohl zarucovat poradnou konzistenci 
replikacnich skupin. Replikace zatim zajistuje, ze mas-li repliku, pak i 
celou jeji replikacni skupinu, a to v jednotnem stavu (az teda na ten problem 
s migraci, ktera ted nici repliku hned). Nerika nic o tom, kdy se replika 
objevi a kdy zmizi, a menit by se to nemelo. Strong pointery na repliky jsou 
vec dost nesmyslna, stejne jak smazat se ti muze pod rukama uplne divne 
zmenit - pokud z nejakeho podivneho duvodu chces data z repliky uchovat, 
pouzij replica manager a nekam si je frkni.

Rozhodne se todle chovani nezmeni dokud neuvidim dost dobry duvod, proc by se 
tak stat melo.

-- Stoupik

On Tuesday 26 of August 2003 18:55, Marek Vondrak wrote:

>   Jake tam chceme mit dvere? Jako opravdove dvere, ktere jsou bud pruchozi
> nebo ne, nebo jako jen jako teleport do jineho layeru?

Co nejprimitivnejsi, takze spis teleport. Pruchozi/nepruchozi dvere uprostred 
prazdneho terenu by asi vypadaly trochu priblbe a pochybuju, ze by se nam 
podarilo postavit neco zajimaveho v terenu.

> - Nejaka logika u
> Monster? Stavovy automat a podobne blbiny?

Ne. Udelat "spravne" AI je hodne tezky a tady to nikdo neumi, takze se to 
delat nebude.

-- Stoupik

On Thursday 28 of August 2003 20:55, Ondrej Pecta wrote:

> Koukal jsem na webu na ty interlocked metody a nikde nepisou nic o tom,
> ze by to melo nejaky hacek. Klidne bych je pouzil, horsi je to ale s
> unixem, ten tam nic nema? Nasel jsem hinty jen jak to udelat pomoci asm v
> cpp... Je tu nejaky Linuxar, kdo s tim ma zkusenost?

Neni. Kdyztak to opras pomoci jednoho globalniho mutexu jako je to tedka (ale 
primo unixoidniho mutextu nekde uvnitr interne v implementaci tech 
atomickejch metod - ne pres ten nas interface, ktery potrebuje globals).

-- Stoupik

MV> Pokud by byl problem pouzit ty atomicke operace na unixu, pak klidne pouzivej dal ty zamky - zamek, ale bude muset byt v nejakem, korektne inicializovanem, globalnim objektu, tj. Ne v
MV> mtreferencelock.

MV> -- Markoid

Neco jsem uz i pro linux nasel, holt musime pockat, esli to nekdo
zkompiluje :o) Podle testu, by to melo byt jen o trosku pomalejsi nez
single thread.
Octa