FPLE : First Person Labyrinth Explorer

[Ace]

Works a treat, I love it! I tried testing out putting a couple of characters down only to see them floating in the air at the same resolution as normal. :D Looks like I'll have to come up with new tilesets to populate dungeons with objects, chests and doodads.

Edit: Quick screenshot of interest, adding a panorama has an interesting effect. ;D

Content Hidden

This script is awesome! Love the nostalgic feel!

wow THAT looks awesome :D with the fog it looks really cool!^^

[sallius]

This is an awesome script and here I was just wondering if I should move from VX back to XP

[PK8]

Heya, to add on to [post=14745]my other post[/url], I just came across a bug in FPLE.

I was trying a special comment in an event command besides comment (I used the Message command), typed "Stretch" in the message command and it worked, which I assume isn't supposed to.

[MGC]

It's on my TODO list. You have to wait a little, because I don't have my PC this week-end.

--> done in v1.1.

Anyway, I think I came across what may be a game-breaking bug.
So I start the demo, I set a resolution (I went with mid), I do a bit of walking around. I decided to reset the game (F12), chose a different resolution (I think I went with low or ugly), did some walking around and then the game stopped, and then the window pops up telling me "Game.exe has stopped working." Is there a way to get that fixed or what?

I didn't manage to reproduce it... If you ever have a mega-detailed scenario (demo + exact location + movements when the bug appears), I'm interested.
It must be a problem in the C code, and that's really a pain to debug.

Would it be possible to have the priority of a tile determine the height and/or Y-axis of a ground, wall or ceiling tile?

* Or perhaps, as suggested by MyOwnFriend in RMVXP's chatroom (we were talking about this) to add onto my initial idea: The terrain tags can be the height and the priority can be the Y-Axis?

Currently the engine can't draw ground and ceiling tiles at different heights (the view is somehow fixed to simplify the algorithm). The idea is rather good though. I'll keep that in mind for a future version.

Some sort of method where developers can check if a ceiling is over the player or not? Perhaps something like this: "ceiling_exists?(x, y)"
Edit: I could see this being used brilliantly, to pull off a few "lighting" tricks with the panoramas.

You can already check that with a classic : $game_map.data[x, y, 2] >= 400.
But I can add a command if it is too complex to use.

I also notice how players can't jump in FPLE. I tried getting the player to jump and I ended up not being able to move. So I was wondering if it was possible to get jumping working for players. I guess I wouldn't mind if there wasn't an option for jumping height. :P (I know MGC said "No jump" in the first post)

That's the same problematic as for the first point : as the height of the view is fixed in this version, jumping is unfortunately not possible.

Special comments for events:

* "Flat": Flat would flatten the event graphic to the ground, just like the original mode7 (not NM7).

-> not easy, but possible.

* Y-Axis/Height in NM7: A feature to set the graphic's Y-Axis to any value. I'm aware of there being a V-Align comment

--> a little easier and also possible.

Oh yeah, events can move in your system.

Thanks for the good news !

May I use this code for an open source project?

Yes, you can. As long as you don't claim that the core of this script is yours, you can use and modify it freely.

This is an awesome script and here I was just wondering if I should move from VX back to XP

Do you plan to make a dongeon crawler ? Otherwise it shouldn't be wise to spend 60$ just for a script...

I was trying a special comment in an event command besides comment (I used the Message command), typed "Stretch" in the message command and it worked, which I assume isn't supposed to.

I've got the problem too. I'll see what I can do to fix that.

[Victor Sant]

@MGC
There was an small issue with touch trigger events and random battle calling.
Since FPLE hadles Game_Player moving? in an different way, it didn't become false after each step, like it do on defautl script.
So the encounter count down and event checks are made only when you stop.
if you keep walking unstoped they would never be checked.

i changed this part of the FLPE_Game_Player update:

Code:

unless moving?
      # If player was moving last time
      if last_moving || $game_temp.last_moving
        $game_temp.last_moving = false
        # Event determinant is via touch of same position event
        result = check_event_trigger_here([1,2])
        # If event which started does not exist
        if result == false
          # Disregard if debug mode is ON and ctrl key was pressed
          unless $DEBUG and Input.press?(Input::CTRL)
            # Encounter countdown
            if @encounter_count > 0
              @encounter_count -= 1
            end
          end
        end
      end

to this:

Code:

if not moving? or ($game_system.fple and moving? and @steps != $game_party.steps)
      # If player was moving last time
      if last_moving
        @steps = $game_party.steps
        $game_temp.last_moving = false
        # Event determinant is via touch of same position event
        result = check_event_trigger_here([1,2])
        # If event which started does not exist
        if result == false or ($game_system.fple and result == false and
           passable?(@x, @y, @direction))
          # Disregard if debug mode is ON and ctrl key was pressed
          unless $DEBUG and Input.press?(Input::CTRL)
            # Encounter countdown
            if @encounter_count > 0
              @encounter_count -= 1
            end
          end
        end
      end

that way the scripts checks also the step count, to verify if an step was done.

I get no errors with that so you could make some tests with this change.
Also, random battle doesn't start if diferectly facing an blocked tile.

Also for people whou would like to use the dungeon background as battle back ground, this small code can do this ;D

Code:

#==============================================================================
# ** Scene_Battle
#==============================================================================
class Scene_Battle
  #--------------------------------------------------------------------------
  if !@already_aliased
    alias main_fple_scene_map main
    @already_aliased = true
  end
  #--------------------------------------------------------------------------
  def main
    if $game_system.fple
      @spriteset_map = FPLE_Spriteset_Map.new
    else
      @spriteset_map = Spriteset_Map.new
    end
    main_fple_scene_map
    @spriteset_map.dispose
  end
end

#==============================================================================
# ** Scene_Map
#==============================================================================
class Scene_Map
  #--------------------------------------------------------------------------
  if !@already_aliased
    alias call_battle_fple_scene_map call_battle
    @already_aliased = true
  end
  #--------------------------------------------------------------------------
  def call_battle
    if $game_system.fple
      @spriteset.update
      Graphics.update
    end
    call_battle_fple_scene_map
  end
end

Just paste it bellow FPLE scripts.

[MGC]

-> Atoa
Thanks for corrections !
The random encounter rate seems better now.
I'll add them in a new version this evening.

[Boot]

I get no errors with that so you could make some tests with this change.
Also, random battle doesn't start if diferectly facing an blocked tile.

I tested your script and that isn't entirely true. I set the battle step counter to 1 and it is possible to enter battle while directly facing a wall, also tested with a couple of other low numbers and still managed to do this. Maybe it's to do with how I'm setting up my maps?

Despite this, it's nice to have the random battle rate fixed, I noticed the error this morning and was about to ask about it, glad I checked this thread first. :P

[MGC]

I uploaded a v.1.2 with Atoa's changes.

I tested your script and that isn't entirely true. I set the battle step counter to 1 and it is possible to enter battle while directly facing a wall, also tested with a couple of other low numbers and still managed to do this. Maybe it's to do with how I'm setting up my maps?

That's because even if the encounter count doesn't drop when facing a wall, there's nothing to prevent a battle from being called if the encounter count is already at 0.
I added an addon that forces the player to turn automatically if he's facing a wall when a battle is launched. I found that cool.

[lyla2284]

This is, without a doubt, one of the best RMXP scripts I have ever seen. I'm currently implementing it into my game, and everything worked perfectly, except for one thing. It seems to conflict with Blizzard's catterpillar script. Is there any way to disable the script on maps that don't use FPLE? Hopefully, that would get the caterpillar system working again, seeing as this script changes the Game_Character.

Help would be appreciated. I'm a complete and utter n00b when it comes to scripting, but I can configure them. ^^

[Xaiko]

This script is amazing! I see great potential for a new generation of RM horror games ^^

Edit: I'd like to combine this script with VVulfman's Mousie script but pathfinding doesn't work correctly. Clickling on the screen makes the player move directly to the corresponding top-down-view X Y coordinates on the map... instead of just taking a step foreward or activating the event in front of the player.

@DerVVulfman: Could you edit your Mouse System to be an "AddOn" für FPLE? I guess it would be enough, if left clicking would have the same effect as pressing forward - or pressing C, if there was an event in front of the player. This would be great ! ^^