Boblen

А для НВидиа уменьшенныые дистрибутивы есть на www.nvworld.ru , в том числе и для чипсетов.

Спасибо. Взял сегодня мать Epox на NForce 4 (одноканальная память, PCI-E), проц Атлон 64 3000+, видео Palit Daytona GeForce 6600 128 Mb, монстр-кулер от Гигабайт... вроде старый БП должен потянуть... только вот собрать времени нет...

Forsage - www.hardwarelab.ru

Подборка основных багов в скриптах. реклама на форуме запрещена, читай правилаwww.uesp.net/wiki/index.php?title=T...ipting_Pitfalls

Почитал тесты - лидирует 6600ГТ почти везде... с отсутствием антиальяса смирюсь, разрешения больше, чем 1024*768 ставить не на чем - думаю возьму или 6600ГТ или 6600, на что хватит... Кстати, а 300 Вт БП хватит на Атлон64 3000+, 6600ГТ, 2 винта и 2 резака??? ЗЫ: В 2 конторах сказали, что на таможне держат груз камней и матерей под 939 слот, того, чего мне нужно пока нету, балин...

Пользуюсь Форсажем - нормальные дрова, а вот с Омегой были проблемы в плане разрешения экрана... ну и размер, если он для вас имеет значение, у неофициальных (русских) меньше, т.к. нафиг выкинуты остальные языки, кроме россиянского и английского и контрольная панель сведена в одну установку с осн.дровами... А есть ли нечно подобное с НВидиа?.. Ибо на нее буду переходить...

Тогда вместо наставника месяца получишь презренного с пожизненным бананом. :)

WhoCanMerge нужна для перевода esp в esm.

I thought it would helpful to make this information public knowledge. The ToggleMenus function can be useful to to force the game engine out of Menu Mode, but some scripters (myself included) have had real issues with using it. Remember that a second ToggleMenus call is always necessary. Without this, menus do not "have permission" to display at all. Attempting to force menus to open by script, while the general Menus state is toggled "off", will often cause freezing/CTD. As others have found, however, using a double ToggleMenus call has the nasty side effect of completely disabling the HUD. Once disabled, the HUD will not reappear until it is reinitialized. There are only two events, that I know of, that will force the game engine to reinitialize the HUD without the player's intervention. There may be others, but these are the ones I have tested and which I know work:- Cell Load Any new cell load (interior or exterior) forces the game engine to reinitialize the game interface completely, including the HUD. e.g. Begin nigedo_hidemove If ( OnActivate ) ToggleMenus Player->COE 0 0 ToggleMenus Endif End This means that it is entirely safe to use ToggleMenus to hide the cell load progress bar in the case of scripts that teleport the player by means of multiple cell loads. Delaying the second ToggleMenus call until the same frame that the player arrives in their destination cell will hide the transportation and still reinitialize the HUD. ForceGreeting This is the other, and more useful, means of reinitializing the HUD. 1. If you use ToggleMenus to immediately exit dialogue, you should add follow on code to initiate a ForceGreeting from the same NPC and then call ToggleMenus twice, to restart the HUD and safely leave Menu Mode respectively. e.g. Call this script from a StartScript in the required dialogue Results field:- Begin nigedo_exit_dialogue Short step If ( step == 0 ) ToggleMenus ToggleMenus Set step to 1 Elseif ( step == 1 ) ForceGreeting ToggleMenus Set step to 2 Elseif ( step == 2 ) ToggleMenus MenuTest StopScript nigedo_exit_dialogue Endif End Notes: * The functions must be called in separate frames in this order to work successfully. * Calling ForceGreeting in the same frame as the first of the second set of ToggleMenus calls (step 1), allows the HUD to remain active despite menus state being toggled "off". I believe this is because the ForceGreeting is already in the process of reinitializing the HUD as the ToggleMenus call processes. The ToggleMenus call catches the dialogue window, but not the HUD. * The MenuTest call (step 2) eliminates an inventory view Menu Mode state that appears to underlie dialogue Menu Mode states. 2. If you want to use this method to safely exit Menu Mode states other than dialogue, you will need to create a custom NPC that you can use to initiate a ForceGreeting call, as required. To do this: * Create a new race with default attributes - call it "race_invisible" * Create a new NPC using the race "race_invisible" and call him "npc_HUD_reset" * Create a new dialogue entry towards the start of the "Greetings 0" section. Filter it by ID = "npc_HUD_reset" and enter the text "." (this isn't strictly necessary, but it's cleaner) Then add this script to "npc_HUD_reset":- Begin nigedo_reset_HUD Short step If ( GetDisabled ) SetDelete 1 Return Endif If ( step == 0 ) ForceGreeting ToggleMenus Set step to 1 Elseif ( step == 1 ) ToggleMenus MenuTest Disable Set step to 0 Endif End Now, whenever you create a script that uses ToggleMenus calls to exit Menu Mode, add a follow on section that places an instance of "npc_HUD_reset" at the player. e.g. This example exits the inventory share Menu Mode state, when activating a container:- Begin nigedo_container_shutDown Short step If ( step == 0 ) If ( OnActivate ) Activate Set step to 1 Endif Elseif ( step == 1 ) MenuTest ToggleMenus ToggleMenus Set step to 2 Elseif ( step == 2 ) If ( MenuMode ) Return Endif PlaceAtPC npc_HUD_reset 1 0 0 Set step to 0 Endif End Note that, in this case, a MenuTest call is necessary at step 1, in order to exit an underlying inventory view Menu Mode state. This is not always necessary and MenuTest can cause problems if called unnecessarily. Experiment with your specific needs and determine whether you may need additional MenuTest calls to assist the process. smile.gif Оригинал здесь

Просто я помню обзор, в которм говорилось, что х700 по производительности повыше 9800, а стоит также, как и 6600. На 6800 меня не хватит... видимо придется брать 6600 обычную и гнать... Пошел сегодня за матерью на СокетА - нету, говорят... и на складе в Москве уже не найти ни маму, ни проц под нее... Вот засада... придется на 64-бита все же переходить, минимум 11000 рупий...

Ясно... такой вопрос, что лучше GeForce6600 или Radeon x700?

Согласный

Видяху я буду брать после выхода Обливы, меня пока интересует чипсет под СокетА.

Часто компилер VC++ так ругается на недостаточный размер файла подкачки... хотя, может, и патч пригодиться.

ХЕЗ, этот движок Морра - такой непредсказуемый...

Ага, вот именно такой я и решил делать, т.к. на полноценный денег нет... На барахолке есть матери на СокетА под ДДР-память (а то моя 133 уже явно не комильфо). Я так понимаю, что лучше брать на НФорс2-чипе, чем на ВИА и СИС? Хотя я сначала одну планку брать буду на 512 Мб (а потом, если деньги будут) еще одну докуплю... Жду советов... И еще, видел видяху GeForce6800 за 5000 (в коробке MSI, вроде нормально, но цена смущает, новая 6600ГТ - тоже около 5000 стоит). Вообще в прайсе одной конторы видел РадеонХ700 на АГП за те же бабки, может к ней присмотреться?....

GetStat, ModStat and SetStat: A concerned modder’s guide. Throughout the term “base stat” means the value of the stat when yellow – i.e. unmodified by any in game bonus / penalty apart from fortification abilities. GetStat: Always returns the current stat – including any bonus / penalty. No nasty side effects as far as I’m aware, so GetStating should always be safe. There is (sadly) no GetBaseStat function. MWSE has these I think, but they don't include e.g. racial fortification abilities in the base (I think), and usually you'd want them included. Note that all stats are stored as floats, even though they should nearly always be integers. Usually this makes no difference. Most of the problems of ModStat and SetStat explained below are only really important for the player (and companions I guess). These functions won’t do anything worse than screwing up the stats they operate on, so for normal NPCs, there’s not much point worrying about all this. I’ve only tested the following on the player, but I presume the same is true for NPCs. As with pretty much anything in Morrowind modding, if you have a choice to use scripting or something else, then use something else. For ModStat / SetStat, the “something else” will usually be fortify/drain stat spell effects or curses. For most purposes, standard effects will work as well as ModStat and SetStat, and will be much less buggy. ModStat: Usually increases (or decreases) the stat concerned by the amount given (local variables are accepted). Both the current stat and the base stat are affected. Usually preserves the amount of fortification or damage on the stat. E.g. for a player with strength 50(base) + 10(fortification) = 60(current) Player->ModStrength 10 will give 60(b.) + 10(f.) = 70(c.), just as you’d expect. Limitations: ModStat can never decrease a stat below zero. It also cannot increase a base stat to a value over 100. Trying to Modstat below zero or above 100 can cause trouble in the following ways: Strength = 30(b.) + 0(f.) = 30(c.) ModStrength, -50 gives Strength = 0(b.) + 0(f.) = 0(c.) ModStrength 50 [hoping to undo the first modstrength] Strength = 50(b.) + 0(f.) = 50(c.) – and the player has a permanent bonus. You can try to avoid this by instead checking that you don’t reduce the stat by more than the current value, but that won’t always work. For example: Strength = 40(b.) + 10(f.) = 50(c.) ModStrength -50 Strength = 0(b.) + 0(f.) = 0(c.) ModStrength 50 Strength = 50(b.) + 0(f.) = 50(c.) – and the player’s base strength is increased. If he then removes the fortification, his strength will show up as damaged. Restoring and replacing the forification will leave him with: Strength = 50(b.) + 10(f.) = 60(c.) It’s never safe to ModStat down by more than the player’s base stat. Given that there’s no failsafe method to determine the player’s base stat, this is annoying [the only ways I know to determine the player’s base stat are the method which I use in GCD – complicated, and doesn’t work correctly when the player’s stat is damaged -, using MWSE, which I think doesn’t include permanent abilities in the base (for most purposes you’d want permanent abilities to count towards the base). Even systematically removing every conceivable bonus / penalty – which is a drag anyway – won’t always work with other scripted mods]. Going over 100 has similar problems. The following is fine: Strength = 70(b.) + 20(f.) = 90(c.) ModStrength, 20 gives Strength = 90(b.) + 20(f.) = 110(c.) ModStrength -20 gives Strength = 70(b.) + 20(f.) = 90(c.) – all fine. However, this also happens for some reason: Strength = 70(b.) + 20(f.) = 90(c.) ModStrength, 50 gives Strength = 100(b.) + 40(f.) = 140(c.) – already screwed up. ModStrength -50 gives Strength = 50(b.) + 40(f.) = 90(c.) – further screwed up. This problem arises because if a stat is fortified or damaged, and the base is not 100, ModStat always increases the current stat by the value you give it, even if the base stops at 100. If the base is 100, ModStating won't have any effect. If the stat is equal to its base value, ModStat will behave normally. So this is fine (so long as you don’t ModStat -50 afterwards): Strength = 70(b.) + 0(f.) = 70(c.) ModStrength, 50 gives Strength = 100(b.) + 0(f.) = 100(c.) And this is fine: Strength = 100(b.) + 20(f.) = 120(c.) ModStrength, 50 gives Strength = 100(b.) + 20(f.) = 120(c.) But this isn’t: Strength = 99(b.) + 20(f.) = 119(c.) ModStrength, 50 gives Strength = 100(b.) + 69(f.) = 169(c.) – oh dear. Of course as a modder you won’t know in general what the Base + Fortification is before you use the ModStat function, so you have no way to compensate for errors even once you know what can go wrong. Joy! Ok, so as long as you never try to ModStat the current stat over 100, everything should be fine, right? Sadly not: Strength = 95(b.) - 10(damage) = 85(c.) ModStrength, 15 gives Strength = 100(b.) + 0(f.) = 100(c.) – OK so far ModStrength, -15 gives Strength = 85(b.) + 0(f.) = 85(c.) – Permanent strength damage. So under what circumstances will ModStating up or down give reliably predictable results? Only when you know the base value of the stat. Can you reliably work out the base value of the stat? No – only in some situations is it possible (the process is explained below, and implemented in my Gals_Sk_Acrobatics script in GCD). Even then it’s not easy. (it’s worth checking script extenders for updates though) SetStat: Sets both the base and the current value to the value you give it (also accepts local variables). This will pretty much always cause problems if the player’s current stat is not equal to their base stat. If their stat is fortified, and you SetStat it, it’ll turn yellow at the value you give it. Removing the fortification, then restoring will give the player a permanent bonus. If their stat is damaged, SetStating it will again turn it yellow, but this time at a lower value than you (probably) intended. They will instantly have their base knocked down to the value you set. Using SetStat is therefore never even slightly safe unless you know the player’s base stat, and compensate accordingly. While you can’t guarantee that ModStat won’t cause trouble, you can almost guarantee that SetStat will. Using SetStat is therefore almost always a bad decision – if you’re ever not sure whether it’s a bad decision, then it is. Then are these functions useless!? Not always. You can use them on NPCs without worrying too much. Using them on companions could occasionally not have the effect you want, but it’s unlikely the player would notice. Using ModStat on the player can be safe, so long as you’re careful – e.g. to increase strength by (up to) 10 points temporarily, you could: Give the player a very strong restore strength curse for a frame or two. (you can then be sure his strength isn’t damaged) ModStrength by MIN{ 10, 100-current } … ModStrength down by the same amount when you want the effect to finish. You can never be sure that giving a temporary penalty won’t cause trouble, but if you only reduce the stat by at most 30, then it’ll usually be fine since most players start with all stats that high. Restoring the stat after you’ve reduced it like this could cause trouble if the player has since gained base stat points, and his stat started close to 100. Some "cunning" tricks with SetStat / ModStat: WARNING – using the following tricks might cause even more trouble than using the functions normally. Use with care. Conflicts are likely. Finding the base of a stat: You can find the base of a stat using the (mis)behaviour of ModStat, as follows: (1)Make sure that the player’s stat isn’t damaged [You have been tracking increases in the natural values of the stat since the beginning of the game, haven’t you? If you haven’t, then you have no way of knowing if it’s damaged – you could check the base value on installation of your mod, so long as you ask the player to install when stats aren’t damaged / fortified]. (2)If it is damaged, give up. (you might want to check script extenders) (3)If it isn’t: (4)Store the current value of the stat. (5)Mod the stat up to 100 if it isn’t already 100 or more. (6)ModStat, 1 as many times as you can while the stat still increases. (7)The fortified part of the stat is the value it reached minus 100. (8)The base part of the stat is the current value minus the fortified part. (9)Return the stat to its current value (DON’T use SetStat, use ModStat). Armed with the base value, you can now use ModStat and SetStat wisely and safely, so long as you’re very careful. Damaging a stat: To set a stat to e.g. 50 damaged from 70, you can do the following: Player->SetStat, -20 [base and current are now both -20] Player->ModStat, 0 [Necessary: sets the base to 0] Player->ModStat, 70 [base = 70, current = 50 (red)] This level of precision is not possible in general using e.g. damage stat curse effects, but it’s not usually necessary either. The above can also be done within one frame, whereas a curse effect might take a second to kick in. Again, the speed can be useful, but is usually unnecessary. Fortifying a stat: To set a stat to e.g. 120 fortified from 90, you can do the following: Player->SetStat 130 [base and current are now both 130] Player->ModStat, 0 [Necessary: sets the base to 100] Player->ModStat, -10 [base = 90, current = 120 (white)] Right, I hope that made some sense. Now you know pretty much everything about the Get/Set/ModStat functions. Just remember not to use them wink.gif. Оригинал здесь Автор Galsiah

Вышла новая версия Illuminated Windows под все версии Морра + под Балмора Экспаншн и Банковский мод. Оф.форум: реклама на форуме запрещена, читай правилаwww.elderscrolls.com/forums/index.p...howtopic=158241 Берем отсюда: реклама на форуме запрещена, читай правилаwww.fullrest.ru/downloads/plugins/g...indows_v1_2.zip 902,6 Кб - я еще не смотрел, нужно ли в нем что-то переводить... ИМХО, если и нужно, то немного...

А чтобы злобный читер не вылетел оттуда телепортацией, переписываем мой стартовый скрипт так: begin BES_Full_Unequip_Start ;Заметьте, что ## в первом блоке должны быть меньше, чем во втором ;А во втором блоке меньше тех, когда квест выполнен и игрока можно отпустить. ; Пока не достигли опред.прогресса - не работаем if ( GetJournalIndex, "Journal" < ## ) return endif ;Достигли нужной точки квеста - запускаем глоб.скрипт ;Который будет контролировать снятие/надевание предметов. if ( GetJournalIndex, "Journal" < ## ) if ( ScriptRunning, "BES_Full_Unequip_Glob" == 0 ) StartScript, "BES_Full_Unequip_Glob" endif if ( ScriptRunning, "BES_StopTeleport_Glob" == 0 ) StartScript, "BES_StopTeleport_Glob" endif return endif end И пишем следующий глоб скрипт: begin BES_StopTeleport_Glob float timer float posX float posY float PosZ short doOnce if ( GetJournalIndex, "Journal" == ## ); выпустить игрока StopScript, BES_StopTeleport_Glob return endif if ( doOnce == 0 ); запоминаем координаты игрока set posX to ( player -> GetPos, x ) set posY to ( player -> GetPos, y ) set posZ to ( player -> GetPos, z ) set doOnce to 1 endif if ( timer <= 5 ); проверка идет раз в 5 сек. set timer to ( timer + GetSecondsPassed ) return endif if ( GetPCCell, "Your_Cell_ID" == 1 ); Если в ячейке - set doOnce to 0; запомним вновь его координаты set timer to 0 else; а если нет Player -> PositionCell, PosX, Posy, PosZ, 5400, "Your_Cell_ID"; геть назад MessageBox, "Куды собрался, гаденыш" set timer to 0 endif end Кстати, я советую на игрока надеть не только штаны, но и рубашку и мантию. Короче полный комплект одежды, а также кольца и амулеты... иначе он сможет использовать магию колец, мантий и прочего... Тогда придется чуть расширить 1 глоб.скрипт, но ничего сложного, расширяем первую часть, где надеваем не только шлем и штаны, но ивсе остальное... а также делаем такое же дополнение к части после проверки GetArmorType, также, как и для штанов со шлемом...

Нетестировавшийся вариант: 1. Скрипт этот нужно повесить на любой активатор (спрячте его под полом) в нужной комнате. begin BES_Full_Unequip_Start ;Заметьте, что ## в первом блоке должны быть меньше, чем во втором ;А во втором блоке меньше тех, когда квест выполнен и игрока можно отпустить. ; Пока не достигли опред.прогресса - не работаем if ( GetJournalIndex, "Journal" < ## ) return endif ;Достигли нужной точки квеста - запускаем глоб.скрипт ;Который будет контролировать снятие/надевание предметов. if ( GetJournalIndex, "Journal" < ## ) if ( ScriptRunning, "BES_Full_Unequip_Glob" == 0 ) StartScript, "BES_Full_Unequip_Glob" endif return endif end 2. А это глоб. скрипт, который запускается из предыдущего, как только квест достигает нужной точки. Он надевает игроку нужный шлем и штаны, снимает все остальные предметы, а затем следит за тем, чтобы все так и оставалось... пока квест не достигает кульминации... тогда скрипт самоостанавливается... begin BES_Full_Unequip_Glob short statum ; Когда квест выполнен - останавливаем глоб скрипт if ( GetJournalIndex, "Journal" == ## ) StopScript, "BES_Full_Unequip_Glob" return endif if ( statum == 0 );Проверяем на шлем if ( Player -> GetItemCount, "Your_Helm_ID" < 1 ); если нет - дадим Player -> AddItem, "Your_Helm_ID" 1 endif if ( Player -> HasItemEquipped, "Your_Helm_ID" == 0 ); не надет - наденем Player -> Equip, "Your_Helm_ID" endif set statum to 1; и идем дальше endif if ( statum == 1 ); Проверяем штаны if ( Player -> GetItemCount, "Your_Pants_ID" < 1 ); если нет - дадим Player -> AddItem, "Your_Pants_ID" 1 endif if ( Player -> HasItemEquipped, "Your_Pants_ID" == 0 ); не надет - наденем Player -> Equip, "Your_Pants_ID" endif set statum to 2; и идем дальше endif ; Основная проверка на все типы брони, кроме шлема ; И если они небездоспешные, идем в нужную секцию ; Откуда добавляем нужный "фантомный" предмет, ; Тут же надеваем его на игрока ; И тут же снимаем, потом снова возвращаемся к проверке if ( statum == 2 ) if ( Player->GetArmorType, 1 != -1 ) set statum to 10 elseif ( Player->GetArmorType, 2 != -1 ) set statum to 11 elseif ( Player->GetArmorType, 3 != -1 ) set statum to 12 elseif ( Player->GetArmorType, 4 != -1 ) set statum to 13 elseif ( Player->GetArmorType, 5 != -1 ) set statum to 14 elseif ( Player->GetArmorType, 6 != -1 ) set statum to 15 endif if ( Player->GetArmorType, 7 != -1 ) set statum to 16 elseif ( Player->GetArmorType, 8 != -1 ) set statum to 17 elseif ( Player->GetArmorType, 9 != -1 ) set statum to 18 elseif ( Player->GetArmorType, 10 != -1 ) set statum to 19 endif if ( Player -> HasItemEquipped, "Your_Helm_ID" == 0 ) set statum to 0 elseif ( Player -> HasItemEquipped, "Your_Pants_ID" == 0 ) set statum to 1 endif endif ;Блок снимания/надевания нужных деталей брони. if ( statum == 10 ) Player -> Additem, "Your_dummy_Cuirass" 1 Player -> Equip, "Your_dummy_Cuirass" Player -> RemoveItem, "Your_dummy_Cuirass" 1 set statum to 2 elseif ( statum == 11 ) Player -> Additem, "Your_dummy_LPauldron" 1 Player -> Equip, "Your_dummy_LPauldron" Player -> RemoveItem, "Your_dummy_LPauldron" 1 set statum to 2 elseif ( statum == 12 ) Player -> Additem, "Your_dummy_RPauldron" 1 Player -> Equip, "Your_dummy_RPauldron" Player -> RemoveItem, "Your_dummy_RPauldron" 1 set statum to 2 elseif ( statum == 13 ) Player -> Additem, "Your_dummy_Greaves" 1 Player -> Equip, "Your_dummy_Greaves" Player -> RemoveItem, "Your_dummy_Greaves" 1 set statum to 2 elseif ( statum == 14 ) Player -> Additem, "Your_dummy_Boots" 1 Player -> Equip, "Your_dummy_Boots" Player -> RemoveItem, "Your_dummy_Boots" 1 set statum to 2 elseif ( statum == 15 ) Player -> Additem, "Your_dummy_LGauntlet" 1 Player -> Equip, "Your_dummy_LGauntlet" Player -> RemoveItem, "Your_dummy_LGauntlet" 1 set statum to 2 endif if ( statum == 16 ) Player -> Additem, "Your_dummy_RGauntlet" 1 Player -> Equip, "Your_dummy_RGauntlet" Player -> RemoveItem, "Your_dummy_RGauntlet" 1 set statum to 2 elseif ( statum == 17 ) Player -> Additem, "Your_dummy_Shield" 1 Player -> Equip, "Your_dummy_Shield" Player -> RemoveItem, "Your_dummy_Shield" 1 set statum to 2 elseif ( statum == 18 ) Player -> Additem, "Your_dummy_LBracer" 1 Player -> Equip, "Your_dummy_LBracer" Player -> RemoveItem, "Your_dummy_LBracer" 1 set statum to 2 elseif ( statum == 19 ) Player -> Additem, "Your_dummy_RBracer" 1 Player -> Equip, "Your_dummy_RBracer" Player -> RemoveItem, "Your_dummy_RBracer" 1 set statum to 2 endif end Скрипт на дверь пишется аналогично 1 скрипту, если кто другой не кинет, напишу его завтра.

Напишу...

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

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

А на 2 дисках написано "с нормальным переводом". :) На ДВД главгерой в балахоне.

Сейчас на оф.форуме появилась тема, где народ делится различными скриптами. Знающие английский (да и не знающие тоже) - вперед туда, за нужными вам скриптами. реклама на форуме запрещена, читай правилаwww.elderscrolls.com/forums/index.p...howtopic=156664