SPINGEE:

100+ vidím reálně. Už při testech 75 to už bylo prej na super úrovni. Navíc proti A3 budou mít výhodu, že se klientům posílaj mnohem menší datový balíčky. Imho tohle je aplikovantelný i na auta/letadla. Pokud na to maj vyhrazenýho člověka, tak věřím že do 1.0 bude desync uspojivě vyřešenej.

Fyzika nikdy nebude počítaná na serveru, prostě ty rag-doll věci uvidí každý jinak. Max možná házení předmětů a samebou server bude počítač zásahy a let kulek. Bude se synchronizovat počasí a tma.

Co bude problém/challange je optimalizace AI na serveru - jak zedi, tak zvířata. Imho AI jako takovou vytvořej super, ale chlapíci ze slovenska co to maj na starosti, imho řešej jak tu AI dělat na serveru, kterej bude dělat i spoustu jiných věcí a nebude to takový dělo jako máš doma. Tj. nemusí se jim povést ten problém vyřešit - což by znamenalo větší nároky na server HW, větší ceny a nasraný SÁčkaře. Když se jim nepodaří utáhnou AI na serveru na těch 6k-10k zedech (teď trochu plácám, nejsem si jistej jakej mají goal) - jsou v pyči. Protože pak by se museli vrátit k spawnování zedů a to je mechanika kterou jsem u modu nenáviděl. Tady prostě doufám a záruky nemám, páč si myslím, že tohle řešej poprvé a žádné řešení co by mohli koupit neexistuje. Na tomhle levelu problémů je obecně BI sama. Všichni ostatní si šetřej práci přes waves a spawnování. No a čím více hráčů, tím více ta AI bude muset makat. Jako fakt nevím, tady držím palce.

Víc FPS - pragmaticky, když to zvládli pro A3, zvládnou to i pro SA. Co já vím, většina práce bylo to oddělení volání renderingu z engine a vytovření nějakýho standardního API. Tohle je navíc důležitý i pro gondole a jiný porty, aby ten rendering byl oddělenej. Podle info co mám tam narvou nějakou pre verzi A3 renderingu a tu budou optimalizovat s ohledem na objekty v Ch+. Tj. narozdíl od A3 se zaměří na objekty v interiérech, páč z toho co si pamatuju naposled z A3, tak jich na Altisu moc není. Imho s 1.0 bude Ch+ běžet na A3 i SA stejně, později bych vsázel že SA bude zvládat Ch+ ještě lépe. Protože tu pipeline prostě optimalizujou na počty a typy objektů najdou v Ch+.. Poslední věc, nakonec s optimalizacema příjdou i engineers z NVIDIA/ATI a různě to ohekujou pro potřeby SA. Ale tohle příjde až po 1.0. Co se týče FPS mám velkou důvěru. A co se týče HNIZDO: -- odpověď je jednoduchá, furt to jede na ToH bez jakékoliv optimalizace od začátku EA, tj. zvýšili počet objektů, čímž víc zapřáhli CPU a tím snížili FPS. Tkaže ano je to pomalejší, ale novej rendering je zdá se na spadnutí (ano to říkám o SA od roku 2012:-) - imho do konce roku a imho se tím SA splní milestone pro vstup do beta.

Co taky důležitý říct, novej rendering taky pomůže v tom, že se hra seká, když jede pomalu server. Teď je to já vím všechno nějak spojený, takže ta hra je laggy, už třeba díky blbýmu serveru. Je to dobře patrný u A3 se špatnejma skriptama. Ale to je i ve spojitosti s netcode.

Btw.. s grafikou za 5,5k a procesorem za 1,5k,- mám města v 15-20 FPS s max antialiasingem a 2056x1080:-) Ale hraje prostě po vesnicích, tam to mám krásně plynulé - jen bych potřeboval SSD kvůli texturám. Furt hraju na vyřazenejch serverových 7,5k discích z práce, který nejsou dle SMART úplně cajk:-)

DUBAS_: novej r******r nebyl potřeba k Chernarusi+, proč k Namalsku? Kvůli kreslení do sněhu?

Namalsk by měl představovat modelovou mapu k otestování nástrojů, který jim Sumrak pomáhá připravit.

Tohle napsal Biran v březnu letošního roku: "On an exciting note, as we look forward to what will be required to support Steam Workshop modding for DayZ teams have begun analysis work on both requirements for new content to be created, and legacy DayZ Mod content to be supported. On the legacy side – we’ve worked closely with Sumrak, the author of the Namalsk map for Arma 2 / DayZ Mod and have completed a basic analysis and test multiplayer session on Namalsk in DayZ. The road to supporting a proper ecosystem on Steam Workshop will take time – but our goal is to have a strong set of tools, documentation, and examples by the time DayZ hits 1.0 and leaves Early Access. We’ll be reaching out to more DayZ Mod content creators over the coming months to gather feedback, and discuss exactly what modding DayZ will look like."

Status Report - 3 Mar 15 | DayZ | Official website
https://dayz.com/blog/status-report-3-mar-15

RUDOLF: no to je gol, to ma adam radost sam mi rikal ze na namalsku bude pracovat az odladej samotny dayz sa a vychytaj mouchy

to ze pridavaj dalsi hadry atp ok ale roubovat na tohle dalsi mod to uz je moc

leda ze ma adam volnou ruku a pise si vlastni veci s novym renderrrerrem a jede si solo linku vedle sa

btw.. na Namalsku jako testovacím modu SA se stále pracuje.. např. Some mods are already being worked on (Namalsk, including the ability to extract water from snow).

Zkoušeli jsme Epoch, démoni a Ai protivníci super, stavění základen a bankomaty taky paráda. Breaking point mě zase vrátil do ARMA II DayZ Mod...

já bych chtěl příští SA v Africe!

Making Wearables From E-Waste
https://www.youtube.com/watch?v=jv--ezAQOrY

ZOMBO: ještě žhavý z rendereru..

koukám že ten ddos furt trvá..

a evženovo info k posunutí exp releasu, vlastně dobrý info - když něco shazuje klienta, tak to bude nějaká core věc v engine - me gusta:-)

Current blockers for internal build include :
Memory crash (client crashes about hour of running)
Couple client crashes with no solid repro
Invisible crew for cars (due to refactor of certain optimizations)
Swap item duplication (due to same reasons)
Issues with binarization of data for map because of changes made to support increase number of objects on the map 2million - 8million.
And more of course.
However its development so we are working on it.
EDIT : The thing about sharing everyday progress is, that some things might not be true in few hours, while others persist. You want to try different approaches to find the best possible. Now were aiming for a more stable experimental releases and much more polish done on them.

a jak mergovali kód, který nemohli hned otestovat v QA:-)

The build didn't get pushed solely for the HDD PSU failure of the core Jenkins server. It was cascade of events that happened over couple days. We lost time because we couldn't test stuff properly. And before all the things got in place (binarization issues, svn issues, hardware issues, data structure). We lost 5 days fixing all of it. Even though devs haven't stopped. The fixes could not get tested accordingly so the bugs that appeared after we got the build for the QA engineers they were behind on schedule.