23 replies to this topic

[Mikhail Troncon]

Никто не подскажет - язык LSL дорабатывается? У него есть домашняя страница? Можно ли почитать официальные изменения и "новинки LSL" где-то в одном месте?

[SOb Zemlja]

Mikhail Troncon, on 4.9.2009, 14:40, said:

Никто не подскажет - язык LSL дорабатывается? У него есть домашняя страница? Можно ли почитать официальные изменения и "новинки LSL" где-то в одном месте?

Дорабатывается. Но сводной страницы с «новинками», насколько мне известно, нет. Только Release Notes к свежим версиям клиента.

[Johnathan]

А доработки однако ему не помешали бы.

[Web]

Johnathan, on 25.03.11 - 14:08, said:

А доработки однако ему не помешали бы.

Толковые доработки - да, не помешали бы. Но в большинстве предлагаемых нет смысла...
Например, все хотят ООП в ЛСЛ.. На кой?..
Все хотят доступ к шейпу и одежде.. Конечно, это было б круто с точки зрения гламурных кис, но совершенно, опять же, не нужно.

Мой вопрос такой: а чего бы вы хотели в лсл? Вот краткий список моих, так сказать, мечт:

1) Чтобы сделали для перманентные url для http_response.. Долой вебсерверы!
2) Хочу эвент on_derez.. Можно было бы, например, запретить вызов из этого эвента ряда функций, чтоб исключить грифинг.. В пределах разумного - как это было бы классно...
3) Хочу, чтоб убрали брутальную задержку при линковке. Дико бесит + смысла уже не имеет.

[Axon Dezno]

О, прикольные предложения веб.

Парочка своих:

1. Хотет функцию integer llSetSculptPrimAnim(integer linkNUM, list sulptTYPES, list sculpts, list sizes, list pos, list rot, integer fps, integer animtype, integer start, integer end, integer on-pass-off);
на выход, если функция лежит в timer-событии должна выводить текущий проигрываемый кадр анимации, шобы когда надо её можно было выключать в integer on-pass-off, а когда надо просто взять кадр, то взять его и оставить функцию работать дальше константой PASS.
Ну или для вывода кадра какую-нить integer llGetSculptAnimFrameNum(integer linkNUM);
Ато я уже опух её всевозможные аналоги пилить.

2. Хотет шобы линдены наконец выпилили некоторые логико-математические ошибки из LSL, ато множественное вложение if-ов и некоторые виды сравнений периодически при верной логике вообще никак не реагируют на внешние раздражители.

Вот, кстати, клинический пример:

integer add; integer prew=-1; integer cur;
default
{
	state_entry(){llSetTimerEvent(1.0);}
	timer()
	{
	prew=cur; cur+=add;
	if((prew<cur && cur<5)||(prew<cur && cur>=0)) {add=1;}
	if((prew<cur && cur>=5)||(prew>cur && cur>0)){add=-1;}
	llSetText("prew="+(string)prew+" cur="+(string)cur,<0.0,1.0,0.0>,1.0);
	}
}

Зато вот так почему-то работает, блджад. Х________х

integer cur = 0; integer rising = 1;

default
{
	state_entry(){llSetTimerEvent(1.0);}
	timer()
	{
		if(rising)		{cur+=1;}
		else			{cur-=1;}
		if(cur==5||cur==0)	{rising=!rising;}
		llOwnerSay("cur="+(string)cur);
		//Как это хоть фунциклирует-то? О_о
	}
}

[Web]

UPD: хочу еще switch-case и foreach для листов

[Web]

Хочу еще, чтоб llGiveMoney возвращала, хватило ли денег (произведена ли оплата)

[alina]

если нельзя библиотеки то хотябы только инклуды уж

Quote

все хотят ООП

не просто ООП а чтобы обьекты вели себя как обьекты ООП.

[Axon Dezno]

Я пупею с аудитории...
Для внедрения ООП линденам прийдётся перепиливать весь ЛСЛ. Плюс много старых скриптов после введения ООП станут не рабочими. Да и накой оно надо?
Текущая версия лсл-а итак достаточно навороченная и изучить её не так-то просто, к тому же не факт, что после первого же готового клиента не появятся умельцы-хацкеры, которые наделают много всяких пакостей. Да и сопсна, зачем в разгар кризиса LL-ам идти на такие эксперементы? Ведь подобное радикальное изменение внутриигрового языка не самым лучшим образом скажется на психике местной аудитории, которая рискует при таком раскладе просто разбежаться. Напимер все скрипты фуриков шо 3 года назад, шо сейчас меняются только тогда, когда кто-нить сделает что-то что лучше всего остального на порядок, тот же переход с аватаров с текстурной анимацией глаз на авы со скульптовой произошёл тока после того, как Uchi слепил своего халявного кошака. И то у 80% фуриков рот анимируется как и раньше обычным поворотом нижней челюсти туда-сюда, а хады до сих пор имеют ограниченный набор смены цветов вместо полной палитры.

Резюме: Линденов местные обитатели за такие нововведения съедят живьём, поскольку ООП может навредить продавцам и внутриигровой экономике, а за этим могут по цепочке пострадать владельцы земель (если стало нечего покупать, то зачем земля?), всяческие школы скриптинга, коих тут итак полторы штуки (потому, что новичкам придётся переучиваться, а также потому, что как только кто-то сделает что-то толковое, то забугорники имеют довольно скверную привычку не явно гадить владельцам таких школ, в основном гадят те, кто что-то уже продаёт).

Врятли ООП сделают - экономических проблем с ним многовато будет.

[Koshachii]

Axon Dezno, on 22.04.11 - 14:47, said:

...
а хады до сих пор имеют ограниченный набор смены цветов вместо полной палитры.
...

У лисы TWI FOX в HUD полная палитра для смены цвета.

И, это... хочу Python вместо LSL.

[SOb Zemlja]

Koshachii, on 22.04.11 - 15:07, said:

…
И, это... хочу Python вместо LSL.

Ну Python, это доспустим слишком. А вот привести LSL к ECMAScript (к JavaScript даже) думаю идея хорошая.
Сохранится событийность (а это важно!), "типа" ООП появится, средства редактирования и отладки имеются в ассортименте.
Варианты с работой на сервере, компиляцией, горячей заменой кода и расширениями уже имеются и опробованы (node.js).

[highstaker]

Quote

И, это... хочу Python вместо LSL.

Не имел дело с Пайтоном, трудно сравнить. Но так как ЛСЛ схож с С++ чем-то, мне было проще его осваивать.

А я банально хачу LLName2Key, а то сайты которые достают ключи по никнеймам то появляются то исчезают.
llGetProfilePicture тоже был бы неплох, но пока и старые методы работают (один раз я их заметил в глюкавом состоянии после обновления интерфейса профильных страниц. Хотелось всех убить)

[alina]

помоему ЛСЛ непринужденно принял бы в себя механизм сопрограмм, исторически он мало исползуем конечно но в данном случае он возможно был бы эффективен. и мог бы представлять недорогую в реализации замену ООП

[SOb Zemlja]

alina, on 16.02.12 - 04:34, said:

помоему ЛСЛ непринужденно принял бы в себя механизм сопрограмм…

Учитывая специфику применения LSL я бы предположил, что чем меньше в нём будет синхронных компонентов, тем лучше.

Максимально асинхронный вариант, который удавалось мне реализовать — работа по шине с использованием протокола — реализуется легко и оказывается весьма гибким. Часть системы описана в этой теме.

Кстати, да, если принимать синтаксис других языков (целиком) то мы лишаемся подобной замечательной техники.

[Web]

LSL дорабатывается постоянно. Исправляются баги и всё такое.

Сама парадигма существенно не меняется. Повторюсь : LSL нужен не для смены цвета, не для анимации скульптов, не для аспектного программирования и не для ООП. LSL нужен для того, чтобы ездили машины, открывались двери и горел огонь. Остальное - скорее побочное. LSL такой, какой он есть. И желать, чтобы он был похож на привычные вам языки просто глупо.

Кстати, встречал в сл кучу скриптеров, которые орут "хочу ООП", но не могут об'ьяснить, зачем оно им надо. Большинство из них вообще имеет очень смутное представление об ООП. Зато все знают, что это круто.

Quote

Хочу еще, чтоб llGiveMoney возвращала, хватило ли денег (произведена ли оплата)

Кстати, линдены услышали мои молитвы

Конечно, многое хотелось бы. Но когда 10 человек хотят, а еще 20 тысячам оно не надо - выбор разработчиков очевиден.

[alina]

касательно меня то ООП я хочу не в традиционном виде обьекты-в-памяти а в специфическом для сл - обьекты-в-сл. так чтобы обьект хранил в себе некую порцию данных и процедур их обработки и так чтобы програмирование состояло в комбинировании этих обьектов

так что это не совсем ООП в традиционном понимании с одной стороны и совершенно естественный подход для сл с другой. но принципиально не реализуемый на тек момент так как движок не потяет такого количества мелких скриптованных обьектов (не говоря уж о том что они банально клиент даже нагрузят)

сопрограммы в этом контексте всплыли как механизм могущий конкурировать с ООП в определенном смысле и они возможно реализуются менее ресурсоемко. хотя с другой стороны они малоизучены как теорией так и практикой

отдельно в сл отсутствуют развитые (с гарантированнойй доставкой и не ресурсоемкие) средства коммуникации между обьектами. что дополнительно лишает базы эту саму идею по-обьектой инкапсуляции

ксати наск я понимаю асинхронность сама по себе предпологает хорошую коммуникацию. если мы лишили процессы возможности заранее знать что происходит с соседом то нужно компенсировать потерю эффективности дав ему возможность спрашивать об этом. асинхронность в слабосвязанной среде - это весьма "перспективно" ))

Edited by alina, 28.02.12 - 12:02.

[Axon Dezno]

ЛОЛ, алина тебе с такими хранящими в себе информацию объектами не в СЛ, тебе в майнкрафт.

[Koshachii]

Пример. Почему ООП это может быть хорошо.

Предположим, есть заказчик-дизайнер, хочет скрипт для своих машинок.
Делаю класс(ы), реализующий интерфейс, например, Авто, компилю в отдельный файлик. Наруже открыты только методы и свойства интерфейса, вся остальная внутренняя начинка скрыта модификаторами.
Отдаю клиенту файлик nomodify - он кидает мой файлик в свой объект, создает свой скриптик, в нем создает объекты моих классов из полученного от мяф файлика, вызывает простые методы интерфейса (поехать, повернуть, затормозить, ...), не парясь сложностями внутренней реализации.
Потом вдруг захотелось клиенту не просто авто, а грузовик. Не вопрос! Наследуюсь от первого класса, перегружаю методы, компилю в отельный файлик, отдаю клиенту - happy end!
Он вызывает те же методы, но они уже работают для грузовика! Клиент может даже оставить свой старый скриптик для первого авто.
И он не видит мой код внутренней реализации, т.е. отдав ему свой скрипт, мяф не теряю полностью эту тему.

Ня? Касательно SL не ня, это моя фантазия.

По моему личному опыту, когда кода много-много, да еще с разным функционалом, классы с их ООП-ништяками реально удобная штука. Как вспоминаю, когда-то на C кодил - необъятные простыни кода... брррр. А ведь по текущем меркам размеры кода смешные были.

И, касательно, самого LSL. Пока ты молодой ака студент у тяф полно времени на изучение еще одного очередного языка или фреймворка. Когда постарше, то очень много надо зубрить по работе, семья, быт. Если бы вместо LSL был тот же знакомый многим ECMAScript или даже кастрированный вариант Java (вспомним Android), то програмистов в SL было бы значительно больше. Желание повозиться с чем-то новым всегда присутствует, но вкладываться своим временем, когда есть более серьезные альтернативы, мало кто может себе позволить.

[alina]

обьекты в скриптах противоречат наличию обьектов в сл. два вида обьектов в одном простраснтве. по меньшей мере это терминологическая путанница.

а вообще то перенос ООП в сл без изменений наивность и ошибка. намажте вкусную селедку вкусным малиновым джемом - это по вашему будет шедевр кулинариии? сл мир ресурсодифицитный а ООП это технология которая позволяет выполнить два плюс два используя 20 мегабайт кода на 2 гигагерцовом процессоре.

плодить цепочки экземпляров какихто классов - возможно это парадигма программного пространства в котором легко оперировать ссылками на общую память. возможно лучше было бы подсмотреть решения в тех областях где ООП пыьтались срастить с распределением вычислителдьной мощности по сети, желательно глобальной. не понмю как там назывались технологии

помоему ООП в сл не должно быть похоже на ООП в языках как оно сложилось в прошлом десятилетии. но должно быть привязано к обьектной структуре самого мира. и иметь способность результирующего обьекта полностью потерять связь с родительским не теряя унаследованых свойств

кстати количество програмистов в сл абсолютно не связано со сложностью языка. АБСОЛЮТНО. и это пожалуй основное отрытие которое позволил сделат LSL

касательно простынь кода - нужны ЛЮБЫХ хотябы средства повторного использования кода. даже простой инклуд уже сильно украсил бы жизнь. а реализованный во внешних редактора он неудобен. даже инклуд позволил бы не использовтаь простынь кода. почему его не сделали сложно понять

дальше за инклудом идут библиотеки внешних функций. а только потом уже ООП. естественно что без средств структурировать работу над кодом имеем ограничение на высоту потолка сложности кода. в итоге только простые прогарммы для того чтобы огонь горел а выключатели включали свет. и никакой совместой работы группы програмистов

Edited by alina, 01.03.12 - 00:31.

[alina]

я знаю какой язык должен быть в сл так чтобы большое количество скриптовыанных обьектов минимально нагружало сим - это должен быть не процедурный а табличный язык. то есть никаких аглогитмов - строки таблиц срабатывающих по событиям обьединенные в сеть. такой язык не потребует заведения своей маленькой иртуальной машинки для каждого скрипта. добавление обьекта в сим будет посто приплюсовывать некий набор обработчиков событий в виде строк таблицы и все. никаких стеков, сегментов, кодов. все обрабатывается общим интрпретатором событий

такой сим сможет легко доавлять и удалять по тыще скриптов на каджом фрейме к миллиону имеющихся

более того. лсл позхоже так и задумывася судя по его событийной структуре. но чтото не сложилось и его быстро перелелали в обычный алгоритмический