Idag har jag lite smått börjat med save/load-säkringen av mina skript och lärt mig ett smartare sätt att göra det på. Jag hade egentligen tänkt vänta med det till senare, men det visade sig att jag var tvungen att göra det för mina maskskript - till att börja med; resten tar jag senare. Jag hade problem med att viktiga inställningar plötsligt och oväntat nollställdes och det tog ett tag innan jag insåg vad det berodde på och vad som behövde göras för att lösa problemet, men nu är det löst. Även det mysko problemet från tidigare kan ha försvunnit, men jag har det fortfarande under uppsikt.

Maskskripten har förresten namn som BurrickPeeBall, BurrickPeeReceiver och BurrickPeeVictim. Meddelanden (som skickas mellan skripten) och inställningar heter saker som till exempel ReleasePee och BurrickPeeVictimSanctuary. Den som kan gissa vad allt detta går ut på vinner (ett fotografi av) en av mig för ändamålet tillverkad hatt.

Det som återstår av maskarna är att ge varje mask en egen fristad och kolla vad som behöver göras med fejkvattenskriptet.

Idag har jag fixat en hel radda med småsaker, några större saker, givit maskarna en fristad, reducerat antalet celler (genom att ersätta diverse hyllplan och en förhörsmöbel med objekt och optimera terrängen på olika sätt). Jag har även upptäckt att några områden inte påverkas av de flödesklossar som de omges av och jag vet fortfarande inte vad det beror på (det gör till exempel att eldpilar som skjuts ner i berörda vattenvolymer studsar på bottnen och sedan åker upp och krockar med himlen istället för att släckas och försvinna när de kommer ner i vattnet). Det har troligen något att göra med cellindelningen och kanske även, om jag har tur, det faktum att jag har ett varningsmeddelande angående detta, så jag ska börja med att göra mig av med det (vilket inte skadar i vilket fall som helst).

Det som återstår av masktjoflänget är fejkvattenskriptsanpassningen.

Alla mina fina dodekaedrar påverkar säkert också och gör terrängen mer/för komplicerad för DromEd att hantera.

1649 celler till godo

Nu har jag lagt grunden till fejkvattenskriptsmaskanpassningen och testat litegrann, så imorgon torde jag kunna skriva klart den. Imorgon ska jag även fortsätta med de trasiga flödesklossarna.

1670 celler till godo

Det sista på maskskripten drog som vanligt ut på tiden. Jag var tvungen att införa en ny typ av fejkvattenvarelse, eftersom mina maskar saknar det som Thief-motorn anser vara ett huvud, så jag var tvungen att tala om att de är regelrätta varelser trots att de saknar huvuden. Jag passade även på att snygga till koden och ta bort en hel del redundans och inledde arbetet med att save/load-säkra maskskripten, vilket inte är helt klart. En lite mysko grej är att (vissa) skript aktiveras i DromEds redigeringsläge (det vill säga innan simuleringen ens startat (det är lite som att ett program skulle börja köra bara för att jag öppnar och tittar på textfilen som innehåller koden eller kanske (åtminstone delvis) som att en lampa tänds innan jag sätter i sladden i eluttaget)), så jag får en extra kopia av saker som det bara ska finnas en av (eftersom viss kod körs två gånger (en gång i redigeringsläget och en gång i spelläget)). Jag måste undersöka detta närmare och eventuellt får jag kompensera. Detta händer för övrigt även i det riktiga spelläget (det vill säga när man inte kör via DromEd).

Save/load-säkringen av fejkvattenskripten är klar, koden är ytterligare tillsnyggad och alla hittills kända problem är lösta. Den stora maskapparaten skulle också kunna sägas vara klar, men jag vill testa lite mer först innan jag uttalar mig.

Jag funderar på att skapa ytterligare ett lager av abstraktion eller åtminstone hålla mig striktare till dem som jag redan har. I nuvarande form gör jag vissa saker i ett lager där de egentligen inte hör hemma och det skulle vara elegantare/underhållsvänligare att flytta ut dem till lagret ovan. Det vore dessutom enkelt att göra, men anledningen till att det ser ut som det gör är att jag har ett timer-event som regelbundet utlöser och utför saker, så jag ville få just den koden så snabb som "möjligt". Frågan man emellertid kan ställa sig är hur pass mycket snabbare det faktiskt blev och att betänka är även "elegans kontra tidsåtgång kontra minnesanvändning".

Jag skulle också kunna betrakta spelarobjektet som ett objekt bland andra objekt istället för som det speciella objekt det är. Bland annat har jag gjort det så att jag kan komma åt spelarobjektets och dess huvuds respektive kropps ID-nummer direkt och sedan lagra dem, vilket snabbar upp koden litegrann jämfört med att hämta behövda ID-nummer varje gång de behövs som jag gör (och är tvungen att göra) för övriga objekt, men det bryter den distinkta uppdelningen i lager som gäller i övrigt. Frågan är som sagt också hur mycket snabbare koden faktiskt blir av detta tricksande och om den eventuella tidsvinsten är värd den extra förfulningen.

För övrigt binder != starkare än &...



Det är tydligen ett känt fenomen. Det känns lite kontraintuitivt, men å andra sidan kan det vara användbart vid testning. Hursomhelst kan jag lösa det genom att negera effekten i redigeringsläget och sedan spara.

Nu är det gjort: Jag valde det eleganta före det tveksamt snabbare och skrev om koden. Det gav ingen märkbar förändring i snabbhet och blev helt klart snyggare. Imorgon ska jag snygga till det sista och testa lite mer innan jag går vidare till nästa grej.

Det vill verkligen till att man gillar att lösa problem när man håller på med DromEd:
Nu har jag stött på en liten patrull i form av ett enstaka specialfall som gör att mitt fejkvatten inte fungerar fullt ut, så jag måste nog implementera ett par hängslen, men exakt hur dessa hängslen ska se ut vet jag inte än. Problemet är att när vissa objekt av samma sort plockas upp av spelaren kombineras de i inventariet till ett enda objekt och när spelaren sedan lämnar ifrån sig ett av dem, så skapas det på nytt utan att rummet i vilket det skapas underrättas om detta, vilket mitt fejkvattenskript delvis bygger på, så fejkvattnet vet inte om att objektet finns. Jag måste alltså komma på ett sätt att tala om för fejkvattnet att objektet faktiskt finns där, vilket inte låter sig göras helt enkelt.

Ett sätt att lösa problemet kan vara att lyssna efter nyskapade objekt (det räcker med att kolla enbart de objekt av samma sort som ett objekt i spelarens inventarie, men det kan tänkas innebära onödigt mycket merarbete), vilket bara behöver göras så länge spelaren befinner sig i fejkvattnet, och kollar sedan om det nyskapade objektet befinner sig inom en given volym. Detta skulle kräva åminstone ett nytt skript plus en mekanism per (alla!) fysiska objekt som talar om för det nya skriptet att objektet skapats. Detta är nog fullt görligt, men det är lite surt att det behövs så mycket för en sådan liten grej.

Edit:
Eventuellt kan jag lägga in den nya funktionaliteten i ett redan existerande skript, vilket skulle förenkla det hela lite.

Idag har jag formgivit och börjat tillverka ett par hängslen.

Nu är hängslena på plats och fungerar, men det återstår fortfarande några detaljer, lite optimering och testning innan det är helt klart, så vi får se vad som händer imorgon.