Recent Posts

Pages: 1 2 [3] 4 5 ... 10
dim3 Versions / Re: dim3 v24 Release
« Last post by ggadwa on February 01, 2018, 04:08:48 PM »

There you go!  That's definitely the last version of it.

[>] Brian
dim3 Versions / Re: dim3 v24 Release
« Last post by Galavant Garde on February 01, 2018, 09:43:28 AM »
Wicked, thanks Brian!   ;D
dim3 Versions / Re: dim3 v24 Release
« Last post by ggadwa on February 01, 2018, 08:01:56 AM »
I never threw it up on github, so I can't be sure what that is.  Tonight when I get home I'll zip it up and put it somewhere were you can grab an archive.

[>] Brian
dim3 Versions / Re: dim3 v24 Release
« Last post by Galavant Garde on February 01, 2018, 07:39:36 AM »
Oh hey again, where can I get the v24 source? I went to github for the first time in years to download it, but the version on there was last committed in 2009.
Idle Chatter / Re: One Of Them
« Last post by Galavant Garde on January 13, 2018, 04:05:25 PM »
Little update video:

The biggest thing to look out for is actually something you can't see.  It's the unnoticeable checkpoint saving and loading with no save screen or input from the player!  Less is more, plus I'm not a fan of the dim3 save screen, and it crashes a lot too.

I've rewritten the bots' vision and movement routines from scratch plugging a bunch of logic gaps and dead ends that caused odd behaviour in the past.  This has made them a lot better at filling a small space without getting stuck on each other (see up the top of the stairs in the video)

I also rewrote the math for bot aim when standing on different levels, and when the player height decreases.

The checkpoint thing is all manually scripted - was a big learning curve for me, but let's just say I'm dreaming in 'for' loops now.  The biggest issue I found with it was packing the Y angle of objects in the save data...took ages to work out that it was often freaking out because the Y angle had too many decimal places.  The way it works is, while still playing you can reload from a checkpoint smoothly, but if you quit and come back to the game later, it'll be at the start of that level. It's a tradeoff I know, but I'm pretty happy with it.

& before you say it, I know the action icon in the middle of the screen is terrible - it's on the list. Also I won't upload any more playable demos since nobody seems to try them out - will just do videos instead I think.
Scripting / Re: Scripting checkpoints
« Last post by Galavant Garde on January 05, 2018, 11:45:51 AM »
Meanwhile I've written a routine into my game script that constructs a 9-digit simple save ID with each number representing a different parameter.  I used a much more basic version of this with 2 digits when I made Ronja all those years ago.  Anyway I can use this to manually reconfigure the level after loading it so it works a little more like a full game save state.  At the moment it allows me to know which map, which music, which checkpoint to move the player to, what the player's health was, whether the player is carrying a rock, the player's model animation settings (he runs differently depending on what's going on), and whether bots are alerted to the player's presence or not.

It's a bit much to try incorporate stuff like enemy locations / health / if they're dead / what they were in the middle of, but I'm sure I'll come up with ways to squeeze more data in there  :D

EDIT - I rounded this bit out.  So yes I've made a simple save ID that clumps together basic data so loading a map after quitting the engine can put the player back where he was and with the same vitals / equipment, but all that remains of the bots' previous state is their collective awareness of the player...they sadly get sent back to their starting spots (because simple save IDs can't pack enough data into them to include the x/y/z/angY details of all the bots.  What I HAVE therefore been able to do is, while you're still playing i.e. you die and respawn but you don't quit and reopen the engine, the game remembers where to put all the bots and restores them fairly faithfully to their states as of the time you hit the checkpoint.

It involves using For loops in the game script that call bots sequentially to gather important vitals/stats, and stores them in arrays inside the game script. I'm then able to run more For loops to manually return all those values to every bot when the player calls the game telling it to restore the bots' old state.  Effectively, it's an auto-save that returns things essentially back to the way they were after the player hit the checkpoint but before the player died.

And it's fast!  No visible lag whatsoever - it just seamlessly puts things back the way they were.  Here's a messy look at how it works:

Code: [Select]
// SAVE ROUTINE - in player script

// Simple save ID will effectively form an array-like string - use JS string methods to read it. The positions will mean the following:

// 0 - Map              // 0 is Yard, 1 is Road, 2 is Sewers
// 1 - Music            // 0 is Prison, 1 is Prison_beat
// 2 - Checkpoint ID    // used to allow searching for the checkpoint, which allows pinpointing its map position so the player may be placed there
// 3-5 - Health         // occupies 3 places as the player default health is 200
// 6 - Holding rock or not  // 0 - false, 1 - true
// 7 - Player move animation    // 0 - Trudge, 1 - Limp, 2 - Run, 3 - Sprint
// 8 - Global bot awareness // 0 - Low, 1 - Medium, 2 - High

// When respawning without quitting, individual bot data can be restored. If loading a simple save, only the above parameters will be applied meaning
// only general data can be used to set bots up. This means their location and movement data won't restore, and they will all have the same awareness

function constructSaveString(game,x,y,z) // note the checkpoint includes its x/y/z position when calling the game script
    pos0=data.get('map name');  // this is set when the map loads
    pos0=pos0.toString();   // convert to a string - this will mean all other values added at end will be strings also
    pos1=data.get('current music');  // this is set when the music starts
    pos2=data.get('checkpoint');  // this is set when the checkpoint object spawns into the map

    playerhealth=playerhealth.toString();   // convert to string otherwise the JS slice method cannot be used

    if (playerhealth>99) {  // 3 digits
    else if (playerhealth>9) {  // 2 digits
    else {  // 1 digit

    if (data.get('holding rock')==null) pos6=0; // data container won't exist if a rock was never picked up
    else pos6=data.get('holding rock');

    pos7=data.get('move animation');  // set whenever player walk animation changes
    pos8=data.get('alert level');  // set globally by the last bot to change its alert level, default is 0


    data.add('respawn x',x);
    data.add('respawn y',y);
    data.add('respawn z',z);
    data.add('respawn angle',respawnAngle.y.toFixed(0));    // Y angle with no decimals rounded up

    for (i=0; i<botRoll.length; i++) {  // runs bot data capture for each ID stored on the roll array

    iface.console.write('auto-save complete - '+simpleSaveString);

All those calls to the bots look like this:

Code: [Select]
// This is in each bot script
function captureX(obj)

function captureY(obj)

function captureZ(obj)

function captureYang(obj)
return(obj.angle.y.toFixed(0)); // Y angle rounded up with no decimals

function captureAwareness(obj)

function capturePath(obj)

function captureMovement(obj)

function captureHealth(obj)

From that, when the player dies it calls:

Code: [Select]
// this is in the player script - attached to the Die event
function die(obj)

sound.playGlobalPlayer("Game Over",1);




function playerFallOver(obj)
    headTurn=new Angle(90,90,0);

function checkForSaveData(obj)

if (data.get('health')==null) obj.event.chain(10,'resetCamera');
else obj.event.chain(10,'resumeFromCheckpoint');

function resumeFromCheckpoint(obj)

function raiseTheCurtain(obj)
posX=data.get('respawn x');
posY=data.get('respawn y');
posZ=data.get('respawn z');
spot=new Point(posX,posY,posZ);
ang=data.get('respawn angle');,ang);'health'));


if (<50) walkSlower(obj);
    else if (<100) walkNormal(obj);
    else if (<150) runSlower(obj);
    else runNormal(obj);


musicID=data.get('current music');
switch (musicID) {
case 0:

case 1:

if (checkpoint1) checkpoint1=false;

You'll see in that second bit, the player calls the game after dying:

Code: [Select]
// this is in the game script
function playerHasDied(game)
    for (i=0; i<botRoll.length; i++) game.event.callObjectById(botRoll[i],'stopAllActivity',null);

That cycles through every bot telling them to stop what they're doing.  After they're all done, the player calls the game asking it to do this:

Code: [Select]
// this is also in the game script
function restoreBotState(game)
    for (i=0; i<botRoll.length; i++) {
        if (botHealth[i]<1) iface.console.write('skipping restore of bot '+botRoll[i]+' because he is dead');
        else game.event.callObjectById(botRoll[i],'restoreState',botX[i],botY[i],botZ[i],botYangle[i],botAlert[i],botPath[i],botMove[i]);
    iface.console.write('all bots restored');

Which checks the health the bot was saved with.  If it has no health, it won't bother restoring its old state because it's dead so hasn't changed state.  If it WASN'T dead at the time of hitting the checkpoint, it reconstructs all of the saved data and packages it up into a call to each bot script sequentially:

Code: [Select]
// this is in each bot script
function restoreState(obj,x,y,z,angY,prevAwareness,prevPathID,prevMoving)

spot=new Point(x,y,z);,angY);

switch (prevAwareness) {
case 0:

case 1:

case 2:
pathID=prevPathID; // revert to previous path iD
if (flashlight) useFlashlight(obj,false);
if (prevMoving) resumeInterruptedPath(obj); // if moving, resume previous path
else if (pathID==null) spawnOntoMap(obj);
else whereToNext(obj); // if not moving, decide on a new path based on previous awareness

Moral of the story?  There's always a way, even for coding noobs like me
Scripting / Re: Scripting checkpoints
« Last post by Galavant Garde on January 05, 2018, 09:34:11 AM »
Simple saves work great; it's the entire game state saves that I'm getting stuck with.  So is the map.action.restartMapFromSave(); a command intended for simple saves then?  I assumed it must be for the full game state saves.  If it is for simple saves, would it for example reload the map while simultaneously returning the simple save ID or something like that?
Scripting / Re: Scripting checkpoints
« Last post by ggadwa on January 05, 2018, 09:04:23 AM »
That simple save was implemented for Scruffy and I doubt it was ever tested in any other place and it is probably buggy and not you.  I suspect (I'll have to relook over the code) that it's really works in a very "restart the entire level" type of thing, and not a save the current state.  It's probably not something very useful for more complex games.

[>] Brian
Scripting / Scripting checkpoints
« Last post by Galavant Garde on January 05, 2018, 08:30:37 AM »
Oh hi me again, so I've implemented Dim3 checkpoints for the first time (I always just used to use my own manually scripted checkpoints for simple save stuff) so that I can get my game to auto-save.  It seemed to work OK at the beginning, but now I'm getting problems with it.  I noticed when you load a game from a checkpoint, the checkpoint is still there after loading, triggering another save event in the same spot.  So you end up with near-identical saves in the same spot for each time you load it.  Also this saving-right-after-loading-because-the-checkpoint-is-still-there thing often causes the engine to crash.  Is there a way to add a script to the checkpoint that prevents it from re-triggering after loading the save file?  Or something in the engine/editor that removes triggered checkpoints from save files?

Alternatively, is there a command I can run that triggers the auto-save event?  That way I could get the game to save without bringing up the Save Game interface WHILE simultaneously avoiding the above checkpoint issue altogether?

Also the map.action.restartMapFromSave(); API isn't working for me - it just restarts the map even though there is definitely a save file.  Other times it comes up saying something about it can't find the spot '-Player'

Hopefully it's just something I'm doing wrong.  Sorry for all the questions - I know I'm the only one really posting anything these days but I'm really fond of Dim3 and want to keep using it
dim3 Versions / Re: dim3 v24 Release
« Last post by Galavant Garde on January 04, 2018, 04:34:46 AM »
Not sure if it's worth mentioning, but I think I found a v24 camera bug.  When restoring a save file, it restores the camera state from when you hit 'load' rather than when you hit 'save'

I came across it because when my player dies, the camera pans away at an odd angle.  So at full health with normal camera settings, I hit 'save', then I run out into the open then get shot.  When I die, the camera pans to the odd angle, and the 'load' menu appears.  Except when you hit the 'load' button to resume from when you had full health and a normal camera angle, it restores everything else normally but that weird camera angle stays.

Easy enough to make a workaround - I just reset the camera angle right before the 'die' event triggers the 'load' menu to open.  I'm really happy otherwise with how well the game state saving works - I remember older versions (years ago) that did all sorts of weird and unstable stuff.
Pages: 1 2 [3] 4 5 ... 10