• Новые темы в этом разделе публикуются автоматически при добавлении файла в менеджер ресурсов.
    Ручное создание новых тем невозможно.
Иконка ресурса

Мануал Максимальный размер Html - дубль 2

  • Автор темы Автор темы FuzzY
  • Дата начала Дата начала

FuzzY

Выдающийся
Местный
Сообщения
65
Розыгрыши
0
Репутация
168
Реакции
84
Баллы
1 383
Chipercu добавил(а) новый ресурс:

Максимальный размер Html - дубль 2 - Максимальный размер Html

Здраствуйте уважаемые форумчане! Вот уже год почти прошел с того момента когда я расспрашивал вас можно ли увеличить размер хтмл и в ответ мне сказали что нет ну или костыли понапихать, ну я подумал ну на-х тогда) Но вот недели 2 назад увидел на форуме...

Узнать больше об этом ресурсе...
 

А что по кешированию? Или каждый раз, когда юзер открывает alt+b - эта вся логика происходит? Если так, то вы можете столкнутся с ооочень большими проблемами производительности. Для теста - воспроизведите 100 таких сценариев одновременно (чтобы они повторялись) в коротком промежутке (как будто у вас 100 клиентов зажали alt+b и у них открывается и закрывается комунити борда по кд), а если 500? А если 1000? Сколько памяти потребуется на всё это?
 
А что по кешированию? Или каждый раз, когда юзер открывает alt+b - эта вся логика происходит? Если так, то вы можете столкнутся с ооочень большими проблемами производительности. Для теста - воспроизведите 100 таких сценариев одновременно (чтобы они повторялись) в коротком промежутке (как будто у вас 100 клиентов зажали alt+b и у них открывается и закрывается комунити борда по кд), а если 500? А если 1000? Сколько памяти потребуется на всё это?
Для сервака это херня. Для клиента это проблемы клиента.

PS: Идея годная) Возьму к себе. Я бы еще добавил основных текстур в словарь, а также добавил бы в html маркер о том, сжат ли он или нет, внутри тега <html
 
А что по кешированию? Или каждый раз, когда юзер открывает alt+b - эта вся логика происходит? Если так, то вы можете столкнутся с ооочень большими проблемами производительности. Для теста - воспроизведите 100 таких сценариев одновременно (чтобы они повторялись) в коротком промежутке (как будто у вас 100 клиентов зажали alt+b и у них открывается и закрывается комунити борда по кд), а если 500? А если 1000? Сколько памяти потребуется на всё это?
оптимизация уже остаётся за тем кто решить это использовать) я допустим у себя поставил компрессию в момент кэширования всех хтмл файлов, по этому это одноразовая операция на старте сервака, в клиенте не увидел какой то особой нагрузки ( при декомпресии 30к символов в 80к занимает где то 20мс и то не очень честный замер поскольку для измерения я просто перед обработкой и после отправляю пакет на сервер)
 
Для сервака это херня. Для клиента это проблемы клиента.

PS: Идея годная) Возьму к себе. Я бы еще добавил основных текстур в словарь, а также добавил бы в html маркер о том, сжат ли он или нет, внутри тега <html
была идея сделать такое с тектстурами) 1732978986857.webp
файлик уже готов со всем текстурами) но менять прям все текстуры уже совсем тяжело клиенту, но если штук 10 основных то вполне норм
 
оптимизация уже остаётся за тем кто решить это использовать) я допустим у себя поставил компрессию в момент кэширования всех хтмл файлов, по этому это одноразовая операция на старте сервака, в клиенте не увидел какой то особой нагрузки ( при декомпресии 30к символов в 80к занимает где то 20мс и то не очень честный замер поскольку для измерения я просто перед обработкой и после отправляю пакет на сервер)
Ну клиент это да, это уже другая история, я про серверную часть, все таки логика выглядит очень ресурсозатратной.
 
Ну клиент это да, это уже другая история, я про серверную часть, все таки логика выглядит очень ресурсозатратной.
На сколько я знаю компресия html и так у всех есть перед отправкой хотя бы в виде удаления лишних пробелов и переносов строк которые тоже довольно много занимают, и пока что ни кто не говорит что и за этого сервак греется) но как я и написал выше, ни кто не мешает компресию делать на моменте кэширования

Я бы еще добавил основных текстур в словарь, а также добавил бы в html маркер о том, сжат ли он или нет, внутри тега <html
Вот это годный совет) только я для себя решил все параметры запихивать в тег <params>(что бы было читабельнее) там как раз и инфу о сжатии отправлю
 
Не знаю насколько быстро выполняется UnrealScript, но я бы прикрутил какое-нибудь простенькое сжатие типа LZW c предварительным прогоном через трансформер Burrows–Wheeler. На крайний случай вынести в native.
 
На сколько я знаю компресия html и так у всех есть перед отправкой хотя бы в виде удаления лишних пробелов и переносов строк которые тоже довольно много занимают, и пока что ни кто не говорит что и за этого сервак греется) но как я и написал выше, ни кто не мешает компресию делать на моменте кэширования


Вот это годный совет) только я для себя решил все параметры запихивать в тег <params>(что бы было читабельнее) там как раз и инфу о сжатии отправлю
кто вам мешает править диалог при загрузке в память его? каждый раз его менять не нужно ибо он статичен.
 
'NPCDialogWnd который вместил в себя 5 страниц альт б баффера'
че это за бафер который растянут на 5 страниц аль б?
 
'NPCDialogWnd который вместил в себя 5 страниц альт б баффера'
че это за бафер который растянут на 5 страниц аль б?
ты видимо не понял сути) стандартным способом ты сможешь отправить в NPCDialogWnd максимум 8180 символов, больше либо у тебя отобразятся только первые 8к либо клиент кританёт, а тут я отправил в это окно 82к , то есть слипил 5 страниц бафера в 1 и отправил в клиент
 
Вопрос, зачем? Такие заморочки под ХФ клиент игры, который и так перегрузили кастомом, который только и ждет очередного крита из-за нехватки оперативы и дополнительной нагрузки.
Сделайте самый простой и понятный для игроков КБ.
 
Вопрос, зачем? Такие заморочки под ХФ клиент игры, который и так перегрузили кастомом, который только и ждет очередного крита из-за нехватки оперативы и дополнительной нагрузки.
Сделайте самый простой и понятный для игроков КБ.
Хотя бы за тем что в л2 верстка гомно, иногда что бы что то нормально выровнять приходится оборачивать img в таблицу потому что valign можно указать только top и то хз работает ли он, и потом оказывается что вместо того что бы отобразить все на 1 странице как у людей, приходится делать пагинацию потому что уперся в лимит пакета
 
Хотя бы за тем что в л2 верстка гомно, иногда что бы что то нормально выровнять приходится оборачивать img в таблицу потому что valign можно указать только top и то хз работает ли он, и потом оказывается что вместо того что бы отобразить все на 1 странице как у людей, приходится делать пагинацию потому что уперся в лимит пакета
Все там делается отлично, только зачастую недоадмины пытаются туда влепить и рыбу, и лумку и жену с самоваром, заполненным самогоном.
Ну а как еще КБ делать без работы с текстурой?
 
Все там делается отлично, только зачастую недоадмины пытаются туда влепить и рыбу, и лумку и жену с самоваром, заполненным самогоном.
Ну а как еще КБ делать без работы с текстурой?
Не стоит защищать этого умирающего мамонта при этом обзывая всех недокемто, может ты и гуру в вёрстке в л2, но это не отменяет тот факт что html в нём недоделанная шляпа
 

Похожие темы

Назад
Сверху