Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - schmoggi

1
Oh man, how could i overlook this!? Thank you very much :).
2
Hello,

sorry for this nightmarish necropost. I'm looking for this fine treasure called "Gemini Editor". Never knew somethin like this exist. Links are all dead in this thread. I've only managed to find the version 2.0 source code .zip on some site i don't remember anymore. Has anyone the binary files / compiled project?

Thank you very much!
3
Helloo,

thank you very much for your effort LittleDrago! I love 16px Tile Movement, specially for Games with Zelda Style Battle Systems (ABS). It doesn't feel blocky  like with the original 32px Movement and personally, i don't see the need for pixel Movement, not to mention that the need for collision maps is often present when using it. I've got one Question:

Is there a possibility, this Script can be made compatible with Heretics Modular Passable Script? I already made some Request one Year ago but sadly, didn't get an answer :/. Here is the Link
http://forum.chaos-project.com/index.php/topic,15436.0.html
Forget the mentioned Script in there, your Script is looking much better.

EDIT:
Woah .. i just thought "well, why not just test it anyway?". Guess what, i did not get any Errors *o*. It works pretty well actually, at least what i tested so far, i can't believe it. You are god.
Finally, it seems i can have 16px Movement and all the Advantages of Heretics Collection afterall!
Only the Moving Plattforms Script is buggy, but that was predictable. An easy Workaround would be, disable pixel Movement when entering/leaving a Plattform. Of course 16px Movement on a Plattform would be Cherry on the Cake!


greetz
4
Bump...

I'm still on this and would be happy for any help. You can find the Script mentioned in the Opening Post i'm using under these Lines. I translated the few german Comments there were for you so you can understand it  better.

Spoiler: ShowHide
# Genocide_Movement 1.1 - 8 pixel precise movement for RPG Maker XP
#
# Author: derula
#
# This script is taken from the German RPGXP project "Genocide" and adjusted
# for standalone usage. Permission is granted by the author to freely use and
# edit it as long as the game "Genocide" and the code's original author remain
# credited in the code. Other means of crediting are voluntary, but appreciated.

module Genocide_Movement
# Configuration:
# Default 1/4 of a Tile an Event is moving
# Standard: 4 (32px), Minimum: 1(8px), Maximum: 4(32px)
EVENT_DISTANCE = 4
# Default 1/4 of a Tile the Player is moving
# Standard: 4 (32px), Minimum: 1(8px), Maximum: 4(32px)
PLAYER_DISTANCE = 2
# Turn Diagonalmove on or off
# Standard: true, Deactivate: false
PLAYER_8_DIR = true
# Key for Strafe:
# Standard: Input::SHIFT, Deactivate: nil
STRAFE_KEY = Input::SHIFT
# Cost for Diagonalmove
# Standard: Math.sqrt(2), Deactivate: nil
DIAGONAL_COST = Math.sqrt(2)

class ::Numeric
# Map Position Coordinates calculate from Flowpoint Coordinates
def to_field
if (i = to_i) == self
i
else
(self-0.125).round
end
end
end

class ::Game_Character
#--------------------------------------------------------------------------
# * Calculate new position
#     x : x-coordinate
#     y : y-coordinate
#     d : direction (0,1,2,3,4,6,7,8,9)
#         * 0 = no change
#     s : steps (1..4)
#--------------------------------------------------------------------------
def get_new_coordinates(x, y, d, s = EVENT_DISTANCE)
# Get move distance
s *= 0.25
# Get new coordinates
if d != 0
dx = (d % 3 == 0 ? 1 : d % 3 == 1 ? -1 : 0)
dy = (d <= 3 ? 1 : d >= 7 ? -1 : 0)
new_x, new_y = x + dx * s, y + dy * s
else
dx = dy = 0
new_x, new_y = x, y
end
[new_x, new_y, dx, dy]
end
#--------------------------------------------------------------------------
# * Determine if Passable
#     x : x-coordinate
#     y : y-coordinate
#     d : direction (0,1,2,3,4,6,7,8,9)
#         * 0 = Determines if all directions are impassable (for jumping)
#     s : steps (1..4)
#     n : new coordinates as calculated by get_new_coordinates
#         if not specified, they are calculated here
#--------------------------------------------------------------------------
def passable?(x, y, d, s = EVENT_DISTANCE, n = get_new_coordinates(x, y, d, s))
# Get new coordinates
new_x, new_y, dx, dy = *n
# If coordinates are outside of map: impassable
return false unless $game_map.valid?(new_x, new_y)
# If through is ON: passable
return true if @through
# Get move distance
s *= 0.25
# Calculate Standfield
fx, fy = x.to_field, y.to_field
# Check, if moving to new field
cx = ((x - fx).abs < s and 0 < dx*(new_x - x))
cy = ((y - fy).abs < s and 0 < dy*(new_y - y))
if cx and cy
return false unless $game_map.passable?(fx, fy, d) and $game_map.passable?(fx + dx, fy + dy, 10 - d)
elsif cx
# Normal Check
return false unless $game_map.passable?(fx, fy, 5 + dx) and $game_map.passable?(fx + dx, fy, 5 - dx)
# If Player is between 2 Tiles...
if y != fy
cy = fy + (y <=> fy)
# ... Check neighbor Tile...
return false unless $game_map.passable?(fx, cy, 5 + dx) and $game_map.passable?(fx + dx, cy, 5 - dx)
# ... Make sure, fy ist the Tile above, cy the Tile below...
fy, cy = cy, fy if cy < fy
y = (y - fy) % 1
# ... check above Tile to the south...
return false if y <= 0.5 and not ($game_map.passable?(fx + dx, cy, 2) and $game_map.passable?(fx + dx, fy, 8))
# ... and check below Tile to the north
return false if y >= 0.5 and not ($game_map.passable?(fx + dx, fy, 8) and $game_map.passable?(fx + dx, cy, 2))
end
elsif cy
# Normal Check
return false unless $game_map.passable?(fx, fy, 5 - 3 * dy) and $game_map.passable?(fx, fy + dy, 5 + 3 * dy)
# If Player is between 2 Tiles...
if x != fx
cx = fx + (x <=> fx)
# ... Check neighbor Tile...
return false unless $game_map.passable?(cx, fy, 5 - 3 * dy) and $game_map.passable?(cx, fy + dy, 5 + 3 * dy)
# ... Make sure, fx ist the Tile left, cx the Tile right...
fx, cx = cx, fx if cx < fx
x = (x - fx) % 1
# ... check right Tile to the left...
return false if x <= 0.5 and not ($game_map.passable?(cx, fy + dy, 4) and $game_map.passable?(fx, fy + dy, 6))
# ... and check left Tile to the right...
return false if x >= 0.5 and not ($game_map.passable?(fy, fy + dy, 6) and $game_map.passable?(cx, fy + dy, 4))
end
end
# Loop all events
for event in $game_map.events.values
next if event == self or event.through
# If through is OFF and (self is player => partner graphic as character)
# and event coordinates are consistent with move destination
if #not event.through and event.character_name != "" and
(self != $game_player or event.character_name != "") and
(event.x - new_x).abs < 1 and (event.y - new_y).abs < 1
# impassable
return false
end
end
# If self is not player, player through is OFF coordinates are consistent
# with move destination and your own graphic is the character
if self != $game_player and not $game_player.through and
@character_name != "" and ($game_player.x - new_x).abs < 1 and
($game_player.y - new_y).abs < 1
# impassable
return false
end
# passable
return true
end
#--------------------------------------------------------------------------
# * Move
#     dir          : direction (0,1,2,3,4,6,7,8,9)
#     steps        : number of steps to move (4 = 1 field)
#     turn_enabled : a flag permits direction change on that spot
#--------------------------------------------------------------------------
def move(dir, steps = EVENT_DISTANCE, turn_enabled = true)
return if dir == 0
turned = false
# Turn to specified direction
if turn_enabled
turn(dir)
turned = true
end
# Calculate new coordinates
new_coords = get_new_coordinates(@x, @y, dir, steps)
# If passable and route free
if passable?(@x, @y, dir, steps, new_coords)
# Turn to specified direction
turn(dir) unless turned
# Update coordinates
@x, @y = new_coords
# Increase steps
increase_steps
# Slide if moving diagonally
elsif dir % 2 == 1 and
((m = dir % 6) == 1 and passable?(@x, @y, 4, steps, n = get_new_coordinates(@x, @y, 4, steps)) or
(m == 3 and passable?(@x, @y, 6, steps, n = get_new_coordinates(@x, @y, 6, steps))) or
(dir < 5 and passable?(@x, @y, 2, steps, n = get_new_coordinates(@x, @y, 2, steps))) or
(dir > 5 and passable?(@x, @y, 8, steps, n = get_new_coordinates(@x, @y, 8, steps))))
# Update coordinates
@x, @y = n#ew_coords
# Increase steps
increase_steps
# If impassable
else
# Determine if touch event is triggered
check_event_trigger_touch(new_coords[0], new_coords[1])
end
end
#--------------------------------------------------------------------------
# * Move Down
#     turn_enabled : a flag permits direction change on that spot
#     steps        : number of steps to move (4 = 1 field)
#--------------------------------------------------------------------------
def move_down(turn_enabled = true, steps = EVENT_DISTANCE)
move(2, steps, turn_enabled)
end
#--------------------------------------------------------------------------
# * Move Left
#     turn_enabled : a flag permits direction change on that spot
#     steps        : number of steps to move (4 = 1 field)
#--------------------------------------------------------------------------
def move_left(turn_enabled = true, steps = EVENT_DISTANCE)
move(4, steps, turn_enabled)
end
#--------------------------------------------------------------------------
# * Move Right
#     turn_enabled : a flag permits direction change on that spot
#     steps        : number of steps to move (4 = 1 field)
#--------------------------------------------------------------------------
def move_right(turn_enabled = true, steps = EVENT_DISTANCE)
move(6, steps, turn_enabled)
end
#--------------------------------------------------------------------------
# * Move up
#     turn_enabled : a flag permits direction change on that spot
#     steps        : number of steps to move (4 = 1 field)
#--------------------------------------------------------------------------
def move_up(turn_enabled = true, steps = EVENT_DISTANCE)
move(8, steps, turn_enabled)
end
#--------------------------------------------------------------------------
# * Move Lower Left
#     steps        : number of steps to move (4 = 1 field)
#--------------------------------------------------------------------------
def move_lower_left(steps = EVENT_DISTANCE)
move(1, steps)
end
#--------------------------------------------------------------------------
# * Move Lower Right
#     steps        : number of steps to move (4 = 1 field)
#--------------------------------------------------------------------------
def move_lower_right(steps = EVENT_DISTANCE)
move(3, steps)
end
#--------------------------------------------------------------------------
# * Move Upper Left
#     steps        : number of steps to move (4 = 1 field)
#--------------------------------------------------------------------------
def move_upper_left(steps = EVENT_DISTANCE)
move(7, steps)
end
#--------------------------------------------------------------------------
# * Move Upper Right
#     steps        : number of steps to move (4 = 1 field)
#--------------------------------------------------------------------------
def move_upper_right(steps = EVENT_DISTANCE)
move(9, steps)
end
#--------------------------------------------------------------------------
# * Turn
#     d     : direction (1,2,3,4,6,7,8,9)
#--------------------------------------------------------------------------
def turn(d)
# If no direction fix
unless @direction_fix
if d % 2 == 1
# If diagonal direction specified, replace it with good straight
# direction if the character is facing an opposite direction
if ((m = d % 6) == 1 and @direction == 6) or
(m == 3 and @direction == 4) or
(d < 5 and @direction == 8) or
(d > 5 and @direction == 2)
@direction = 10 - @direction
end
else
@direction = d
end
@stop_count = 0
end
end
#--------------------------------------------------------------------------
# * Update frame (move)
#--------------------------------------------------------------------------
def update_move
# Convert map coordinates from map move speed into move distance
distance = 2 ** @move_speed
# Apply cost for diagonal movement
if DIAGONAL_COST and @x * 128 != @real_x and @y * 128 != @real_y
distance = (distance / DIAGONAL_COST).round
end
# If logical coordinates are further down than real coordinates
if @y * 128 > @real_y
# Move down
@real_y = [@real_y + distance, @y * 128].min
end
# If logical coordinates are more to the left than real coordinates
if @x * 128 < @real_x
# Move left
@real_x = [@real_x - distance, @x * 128].max
end
# If logical coordinates are more to the right than real coordinates
if @x * 128 > @real_x
# Move right
@real_x = [@real_x + distance, @x * 128].min
end
# If logical coordinates are further up than real coordinates
if @y * 128 < @real_y
# Move up
@real_y = [@real_y - distance, @y * 128].max
end
# If move animation is ON
if @walk_anime
# Increase animation count by 1.5
@anime_count += 1.5
# If move animation is OFF, and stop animation is ON
elsif @step_anime
# Increase animation count by 1
@anime_count += 1
end
end
end

class ::Game_Event
#--------------------------------------------------------------------------
# * Touch Event Starting Determinant
#--------------------------------------------------------------------------
def check_event_trigger_touch(x, y)
# If event is running
if $game_system.map_interpreter.running?
return
end
# If starting determinant other than jumping is front event and
# trigger is [touch from event] and consistent with player coordinates
if @trigger == 2 and not over_trigger? and not jumping? and
($game_player.x - @x).abs <= 0.5 and ($game_player.y - @y).abs <= 0.5
start
end
end
#--------------------------------------------------------------------------
# * Automatic Event Starting Determinant
#--------------------------------------------------------------------------
def check_event_trigger_auto
# If starting determinant other than jumping is same position event and
# trigger is [touch from event] and consistent with player coordinates
if @trigger == 2 and over_trigger? and not jumping? and
($game_player.x - @x).abs <= 0.5 and ($game_player.y - @y).abs <= 0.5
start
# If trigger is [auto run]
elsif @trigger == 3
start
end
end
end

# Shots/Hits and 8Dir- and Pixelmovement
class ::Game_Player
def move(dir, steps = PLAYER_DISTANCE, turn_enabled = true)
super
end
#--------------------------------------------------------------------------
# * Frame Update
#--------------------------------------------------------------------------
def update
# Remember whether or not moving in local variables
last_moving = moving?
# Fix Direction
if STRAFE_KEY
if Input.press?(STRAFE_KEY)
if @pre_fix == nil
@pre_fix = @direction_fix
@direction_fix = true
end
elsif @pre_fix != nil
@direction_fix = @pre_fix
@pre_fix = nil
end
end
# If moving, event running, move route forcing, and message window
# display are all not occurring
if not (moving? or $game_system.map_interpreter.running? or
@move_route_forcing or $game_temp.message_window_showing)
# Move player in the direction the directional button is being pressed
move(PLAYER_8_DIR ? Input.dir8 : Input.dir4)
end
# Remember coordinates in local variables
last_real_x = @real_x
last_real_y = @real_y
super
# If character moves down and is positioned lower than the center
# of the screen
if @real_y > last_real_y and @real_y - $game_map.display_y > CENTER_Y
# Scroll map down
$game_map.scroll_down(@real_y - last_real_y)
end
# If character moves left and is positioned more let on-screen than
# center
if @real_x < last_real_x and @real_x - $game_map.display_x < CENTER_X
# Scroll map left
$game_map.scroll_left(last_real_x - @real_x)
end
# If character moves right and is positioned more right on-screen than
# center
if @real_x > last_real_x and @real_x - $game_map.display_x > CENTER_X
# Scroll map right
$game_map.scroll_right(@real_x - last_real_x)
end
# If character moves up and is positioned higher than the center
# of the screen
if @real_y < last_real_y and @real_y - $game_map.display_y < CENTER_Y
# Scroll map up
$game_map.scroll_up(last_real_y - @real_y)
end
# If not moving
unless moving?
# If player was moving last time
if last_moving
# 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
# If C button was pressed
if Input.trigger?(Input::C)
# Same position and front event determinant
check_event_trigger_here([0])
check_event_trigger_there([0,1,2])
end
end
end
#--------------------------------------------------------------------------
# * Passable Determinants
#     x : x-coordinate
#     y : y-coordinate
#     d : direction (0,2,4,6,8)
#         * 0 = Determines if all directions are impassable (for jumping)
#     s : steps (1..4)
#--------------------------------------------------------------------------
def passable?(x, y, d, s = 4, n = get_new_coordinates(x, y, d, s))
# If coordinates are outside of map: impassable
return false unless $game_map.valid?(n[0], n[1])
# If debug mode is ON and ctrl key was pressed: passable
return true if $DEBUG and Input.press?(Input::CTRL)
super
end
#--------------------------------------------------------------------------
# * Same Position Starting Determinant
#--------------------------------------------------------------------------
def check_event_trigger_here(triggers)
# If no event is running
unless $game_system.map_interpreter.running?
# All event loops
for event in $game_map.events.values
# If triggers are consistent, starting determinant is same position event
# (other than jumping) and event coordinates are consistent
if event.over_trigger? and triggers.include?(event.trigger) and
(not event.jumping?) and (event.x - @x).abs <= 0.5 and (event.y - @y).abs <= 0.5
event.start
return true
end
end
end
return false
end
#--------------------------------------------------------------------------
# * Front Envent Starting Determinant
#--------------------------------------------------------------------------
def check_event_trigger_there(triggers)
# If no event is running
unless $game_system.map_interpreter.running?
# Calculate front event coordinates
new_x = @x + (@direction == 6 ? 1 : @direction == 4 ? -1 : 0)
new_y = @y + (@direction == 2 ? 1 : @direction == 8 ? -1 : 0)
# All event loops
for event in $game_map.events.values
# If triggers are consistent, starting determinant is front event
# (other than jumping) and event coordinates are consistent
if not event.over_trigger? and triggers.include?(event.trigger) and
not event.jumping? and (event.x - new_x).abs <= 0.5 and (event.y - new_y).abs <= 0.5
event.start
return true
end
end
# If front tile is a counter
if $game_map.counter?(new_x, new_y)
# Calculate 1 tile inside coordinates
new_x += (@direction == 6 ? 1 : @direction == 4 ? -1 : 0)
new_y += (@direction == 2 ? 1 : @direction == 8 ? -1 : 0)
# All event loops
for event in $game_map.events.values
# If triggers are consistent, starting determinant is front event
# (other than jumping) and event coordinates are consistent
if not event.over_trigger? and triggers.include?(event.trigger) and
not event.jumping? and (event.x - new_x).abs <= 0.5 and (event.y - new_y).abs <= 0.5
event.start
return true
end
end
end
end
return false
end
#--------------------------------------------------------------------------
# * Touch Event Starting Determinant
#--------------------------------------------------------------------------
def check_event_trigger_touch(x, y)
# If no event is running
unless $game_system.map_interpreter.running?
# All event loops
for event in $game_map.events.values
# If triggers are consistent, starting determinant is front event
# (other than jumping) and event coordinates are consistent
if not event.over_trigger? and not event.jumping? and
[1,2].include?(event.trigger) and (event.x - x).abs <= 0.5 and (event.y - y).abs <= 0.5
event.start
return true
end
end
end
return false
end
end

class ::Game_Map
alias :old_passable? :passable?
#--------------------------------------------------------------------------
# * Determine if Passable
#     x          : x-coordinate
#     y          : y-coordinate
#     d          : direction (0,...,10)
#                  *  0,10 = determine if all directions are impassable
#     self_event : Self (If event is determined passable)
#--------------------------------------------------------------------------
def passable?(x, y, d, self_event = nil)
# Handle diagonal passability
if d % 2 == 1
# Calculate temporary movement direction indicators
dx, dy = d % 3 == 1 ? -1 : 1, 6 <=> d
# Get new position
new_x, new_y = x + dx, y + dy
# Get movement directions
dx, dy = 5 + dx, 5 + 3 * dy
# Calculate passability
passable?(x, y, dx, self_event) and passable?(x, new_y, dx, self_event) and
passable?(x, y, dy, self_event) and passable?(new_x, y, dy, self_event)
else
old_passable?(x, y, d, self_event)
end
end
end
end


Thanks a Lot

greetz
5
This looks absolutely amazing. I can't think of any additional Features at the moment, but i guess by releasing a first Demo people will see how it works and functions... and maybe have some Ideas for new things. I can't wait to try it out :).

greetz
6
Hey,

you can swap Tiles on your Map with the following call script:

$game_map.data[x, y, layer] = ID


x = map_x position
y = map_y position
layer = Map Layer, it starts with 0 for Layer 1
ID = Tile ID from your Tileset, starting with 384 for the first Tile below Autitiles in the left upper Corner

Though, i don't know if the changes on the Map are saved in the save File. I can't test it yet because i'm not at home. If not, maybe some friendly Scripter could edit it so the changes are saved.

greetz
7
Hey there,

As you know, we are all restricted to the 32px Tile Movement. The Problem ist, that Movement can look very blocky und feel a bit "unnatural", specially when you developing with a Zelda like Action Battle System in Mind. Though, there are plenty Scripts out there which allows Pixel Movement. Pixel Movement is fine by it self, but personally i don't like it in RPG Maker Games and in many cases you have to use a "Collision Map". Furthermore, i think it is an unnecessary Step. A "half-step" Movement like 16px instead of 32px is already fine in my oppinion and it could be made more precise when reduced to 8px. Anyway .. you run into Problems when you're a Fan of Heretics Scripts.

I guess many People around here know the famous Heretic's Collection  of Art and 100% Compatible Scripts, specially the  Heart of it, Modular Passable Script. If you don't know it, well then get to know it .. it is awesome!

Modular Passable - > http://forum.chaos-project.com/index.php/topic,14986.msg191610.html#msg191610
Collection - > http://forum.chaos-project.com/index.php/topic,13682.0.html

It allows many advanced things like Collision Optimizer, NPC on Event Tiles and the new added Moving Platforms. Things, that should have been in the original Release of XP Maker. If you ask me, i don't want to abandon that Scripts anymore, they offer so much. Sadly, like already said, if you're a Fan of Custom Movement, you have a Problem. In the Modular Passable Script it is stated:

Quote# -----  Compatability  -----
#
# This script will NOT be compatible with any other script that replaces
# either Game_Map Passable or Game_Character Passable.  If a script replaces
# Game_Event Refresh, that can be fixed by putting the entire Game_Event class
# below the conflicting script, but leave Game_Map and Game_Character classes
# in this script above other user created scripts, except the SDK.
#
# If the nature of other scripts is extremely different, expect problems.  So
# other scripts like Pixel Movement Scripts most likely will be too foreign
# for this script to offer any compatability.  Bananas and Screwdrivers.
#
# This is intended for making the Default Movements more Modular only.


I'm here to ask a capable Scripter (or more than one) if someone could take a glance on it and develop a fine Script, based on Modular Passable, which:

- gives you the Possibilty to alter the standard 32px Movement to 16px/8px/4px.
For my personal Taste, 16px would be already enough but i can imagine there are many out there with the desire for finer Movement. Also this would provide more customization

- relies on the standard Collision & Passability Detection
no nasty "Collision Maps"

If it helps, i've already got a fine Movement Scripts through which you can customize the Movement down to 16px/8px and so on. Since i plan to use Heretics Scripts, i can't use it anymore. If it helps, i can post it here so we do not need to make a fresh start and "only" need to make it compatible.

greetz
8
Hey there,

i was playing around the last day(s) in the maker and thought about some nice Idea which could be very useful. Since Heretic asked that day about new Ideas i thought, why not just post it here and see if there is some interestit to script it.

Event Size

So, as we know, Events are always 32 x 32 pixels and so they only take up one single tile on the map with collision etc. However, this also includes events with bigger graphics assigned to them. Logically, the big Dragon from the RTP for example should not be able to pass a 1 Tile space, but sadly it can. How about changing that?
The Possibility to give Events a proper Event Size (maybe through Comments) would be great. With that, Events with bigger Graphics could not pass anymore, for them, impassable areas or not be crossed by Player/Events where it should not be possible (think of the carriage). Furthermore,  the new size could be taken into account for triggering other Actions like Player touch/Event touch.

greetz
9
Oh my, didn't see that coming! That looks very nice, Heretic.
I have used the Light Script called Fabien 3.0 in the past and i was fine with it. But this looks very promising.
Probably i'll stick with it when it is released, i like to have most as possible from one Hand :). I've got one Question though:

Is the Day & Night System linked with the functionality of the Light System or is it free to decide using only the Light System or both?

I ask because while i was looking out there in the Past for some Light Scripts, i've always found some with inbuild Day & Night System which bothered me, to be honest.
Many People, like myself, like to use their own (Evented) Day & Night System or have already build one and do not like to drop it.
And that is the reason i like the Fabien 3.0 one so much because it can be used without some inbuild Day & Night.

Thanks for the Answer.

greetz
10
I checked the new Collection with the new Demo(s) and it is wonderful. Specially the Advanced Camera Control System is a very nice addition, no to mention the Moving Platforms (i love it). You put some nice explanation in there and i find it very outstanding, that your collection Project outmatches a lot of Game Projects out there when it comes to detail love although it is "just" a Project demonstrating your beautiful Script Collection. Thank you!

greetz
11
I've got one Question regarding alternatve Movement Scripts:

In your Modular Passable Script it is stated

Quote# -----  Compatability  -----
#
# This script will NOT be compatible with any other script that replaces
# either Game_Map Passable or Game_Character Passable.  If a script replaces
# Game_Event Refresh, that can be fixed by putting the entire Game_Event class
# below the conflicting script, but leave Game_Map and Game_Character classes
# in this script above other user created scripts, except the SDK.
#
# If the nature of other scripts is extremely different, expect problems.  So
# other scripts like Pixel Movement Scripts most likely will be too foreign
# for this script to offer any compatability.  Bananas and Screwdrivers.
#
# This is intended for making the Default Movements more Modular only.


Does this mean, Scripts which alters the Movement of Player/Events have no chance at all or can be made compatible when adapting the Movement Script to the Modular Script?
To be clear, i do not like Pixel Movement in Maker Games. But the standard Movement (32x) can be sometimes too "big", if you know what i mean. Especially, when working with an Action Battle System (Zelda like) like i do, small steps when attacking etc. can look unfortunate. So, i thought a long time ago about it and did a Request for a more precise Movement Script, so Player/Events Movement is reduced to 16 instead 32 pixels. Fortunately, someone called delura was so nice to create such a script and with it you can customize the Movement from 32 down to 16, 8 and 4 pixels.
This means, i have this Script lying around and originally planned to use it. Did a Test with the Modular_Passable Scripts and, of course, it did not go so well. Well, it works but things like diagonal Stairs (lite and delxue) are not recognized anymore and who knows what else. Anyway, in short, Is it worth starting a Request to ask someone with enough time for making it compatible with the Modular_Passable Script or is it an already doomed plan and I'll have to stay with standard Movement?

greetz
12
Eat this, EB! This feels so naturally, something like this should have been in the maker from the start... like much more stuff.
I love what i see, Heretic. You did not only fix the endless loop Animation, but also the strange feeling of "slow movement" is completeley gone. Gorgeous!

greetz
13
Nice to hear, i can't wait for it :).

I would love if you post another, advanced Demo to see the Progress when you have time :).

greetz
14
Quote from: Heretic86 on March 27, 2016, 06:35:17 pm
Thanks!

Okay, movement works like this, as you may already know:

distance = 2 ** @move_speed

I had to change that to this:

x_dist = y_dist = 2 ** @move_speed
# Set X and Y distance to 0 if direction is not relevant
case @platform_move_direction
when 4, 6 # Left and Right
  y_dist = 0
when 2, 8 # Up and Down
  x_dist = 0
end

When the Platforms move, they use the original method, which works fine.  Speed comes out to a real value of 9 with a speed of 3 and 16 with a speed of 4.  I understand that feeling of "slow movement" because of  the screen scrolling.  Adjustments made cause the screen to scroll at a real speed of 7 since 16 - 9 = 7.  If the platform moved the same speed, it wouldnt be just slow, it would be no scrolling at all!  Im not sure what I can do about that since the screen always centers the player.


I think, i get it now. I played a little more with it and did not think about the movement speed of the Platforms at first, so i changed their Speed from 2 to 3 and then to 4 (same Speed as Player). With every increase that "slow movement" fades away, of course. But the correct movement (x/y position) while going in the opposite Direction is messed up then (with every increase).

Quote from: Heretic86 on March 27, 2016, 06:35:17 pm
While getting on and off platforms, and changing between two different groups, the whole Platform Group will stop moving until "boarding" and "unboarding" is complete.  Im not sure if this is a good way to do this.  I didnt want the platform to move away from a characters position until they were fully on that platform.  It just broke the illusion.  So far, I sort of set it up so while boarding, a platform wont move at all, it wont even update its Wait counter!  What I wanna do, not fully working, is allow two platform groups to be evented so they end up next to each other, then characters can transfer between them without either platform taking off prematurely.

Current way they are set up is so you cant get on or off a Platform unless they have been given a Wait command!  You can (sort of) walk between Tile Groups tho.


It would be very hard, even imposibble, anyway to set up the possibility for Platforms to move avay while Characters/Player are moving on the Platform with the Restriction of Tile Movement like we have it now. Like you said, it brakes the illusion but also brakes the right Positions from the Characters. Guess, that kind of Thing needs pixelmovement. So being able to only move on Platforms while they are on hold and Platforms only moving again when Characters/Player is finished with the "move on Platform" process is fine.

I do not know if you thought about it, but i also noticed, making some changes in the Platform Events after you set them up (Speed, Route) could be a bit annoying, especially when you have more and bigger Plaform Groups on your Map. An Idea to avoid that and make it more comfortable would be, to control and set up whole Platform Groups with only one Command/Event. In this case, you would ony need to change the Sprite (if needed) when changing something.
An Alternative could be, but i don't know if thats possible and even fit into the Platform Script, to have only one Event with the whole Platform Sprite
(obviously a character then) and somehow tell the system that this Character is logically bigger than just one 32x32 Event and have custom passabilites in that Range of x/y Values the Sprites is being displayed.

greetz
15
Looking fine so far, Heretic!

I get sometimes an endless loop of Aluxes moving Animation on the Platform when trying to move in the opposite direction the Platform is going. But i can not reproduce it, seems pretty random. Otherwise it is usable, respect for this short amount of Time. Looking forward for the "getting on Platforms while they are moving". While testing i think i realized why the other Platform Script has an inbuild pixel Movement.
When heading in the opposite Direction the Platform is moving, you get this "strange" and "slow" feeling of Movement. I don't know if you will fix that or it is there because we have a 32x Tile Movement. Furthermore i don't know how "getting on Platforms while they are moving" can be achieved with our Tile Movement. I think there would be a Problem with synchronization the Position of the Player, based on the Tile Movement, when e.g. jumping on a moving Platform. It would result in an offset of x/y and the Player would not be anymore in the Grid itself.

greetz
16
Quote from: Heretic86 on March 24, 2016, 09:27:02 pmSo yes, you can have Stairs and Moving Platforms, or just Stairs or just Moving Platforms, but for them to work together, they need Modular Passable.  Modular Passable by itself doesnt do anything.  Putting the script in your game and you wont notice any other changes.  Modular Passable is a framework that allows other scripts to alter behaviors with compatability.


That is totally fine with me. I'm planning to use some Scripts from your Collection Art anyway and i felled in love especially with the Modular Passable and the Possibility it provides like the "restricted Tile Passage" and "event through event but no tileset" part. Makes Life much easier :). With independently i actually just ment to not combine it with other Scripts or Functions which alters your Movement Behavior, i you like or not. Thats all. If you like, i could provide you the other Moving Platforms Script i talked about so you can have a Glance at it.

Quote from: Heretic86 on March 24, 2016, 09:27:02 pm
But I did do a bit more thinking about what you were saying.  What I came up with seemed to work okay.  It can be achieved with both Event Tiles by swapping Event Pages, and can be achieved by getting direct access to the tiles themselves.  Events is way easier, but limited in scope, but swapping tiles creates an Illusion.  If you duplicate a set of graphics in your tilesets, you can give them different passages and priorities, even though they look exactly the same to the Player.  So what Im thinking is you have a map with at least two "Levels", a top and a bottom.  While on the bottom, a player can walk under or behind some of the terrain, but on the top layer, those passages are totally different and allow walking around on all parts of the top layer.


Exactly, that is what i talked about in the first Point back then. Add the Drawing Part and you have a real Elevation System. But like i said, i dropped that Thing back then after i realized there is no chance realize the Drawing Part with the standard Tilemap Class. And without the Drawing Part there is no Point to talk about the other stuff because the Illusion of different Z Levels is broken. The Thing is, i can easily build a Eleveation System through swapping Event Pages or through swapping the Tiles on the Map directly with the Help of some Script Commands right now, even without the Additions of the Collection Art. The Problem is and was back then, this would only apply to either the Events or the Player but not both at the same Time! Look here:

The Characters are on different Z Levels, so they can not interact with each other and are drawn behind or above the Tiles, depending on their actual Z level, at the same Time. Sadly, not possible (right now), at least the drawing Part, so i dropped it and changed my Plans. Situations like this one are not possible anymore because Cliff Tiles like the one on the Pic have no higher Priority and are only passable from one side (pretty standard). The "Logic" for the Z Levels are still there though and that is the Reason for the "give Tile ID's multiple Values" Script or just call it "Z Terrain Tags". It could be easily done with the standard Terrain Tag System but then you have no Terrain Tags anymore for other Things and "unlimited Terrain Tags" Scripts don't help because Tiles can still only hold one Value per Time. In short, there is need of more than just one Terrain Tag System which all work independently and don't override eatch other Values.

Quote from: Heretic86 on March 24, 2016, 09:27:02 pm
Im not sure I understand "Negative" trigger, but you seem to be familiar enough with scripts and programming in general that I think this explanation will be worth while.  Triggers for each event can be changed with simple Move Routes!  Even though you set the Trigger with the Editor where it says "Action, Player Touch, Event Touch, Autorun and Parallel", its a simple numeric value and that value can be changed as easily as Through can be turned on and off with Move Routes also.  It just requires a script call: @trigger = 0 thru 4.  The default of 0 thru 4 represent each of the default behaviors, where 0 = Action Button, 1 = Player Touch, etc.  The default code says anything higher than 2 is an autorun or parallel and is always updated in its list of event actions, but you can go negative also!  For example @trigger = -1 makes an event Untriggerable!


Thank you Sir, i didn't even know that is possible. You can learn every Day :).

But, i guess "negative" Trigger was not clear enough. I mean Events and Player with a different Value in their local Variable can not interact (triggering) and do not block each other when moving, but this only applies to Characters with different Values. So, for example two NPC's with the same Value interact with each other as they would normally do.

greetz
17
Hi Heretic86,

Quote from: Heretic86 on March 22, 2016, 06:17:13 pm

Update News:

Im scripting again!  I have a few ideas for some new scripts.  They may or may not work, but seems like they are coming along so far.  Im working on a PLATFORMS script that will allow Characters to do things like walk on a floating island to cross impassable areas.

Would anyone be interested in a Moving Platforms script, or any other requests?


Oh, and there i thought this Day could not get any better  8). A "Moving Platforms" Script would be a Dream! I waited and searched so long for this. But there is nothing alike for our beloved XP :/ ... eh, well not 100% true. I saw a Script, worked fine, but it was bound to a pixel moving Script with inbuild Jump System. At first, such Systems does make sense in combination with moving Platforms but some (like me) like to give Players only the Possibility to jump (to other Platforms) at specific Points/Positions. Furthermore the "Moving Platforms" Script should be independently so People can decide on their own if they stay with the standard 32x32 Tile Movement or go with 16x16/8x8/... and so on.
So in short ... yes there is a lot interest, at least from my Side! A "Moving Platforms" Script in a "basic" form, means totally independently would be great. If you could customize it in the way, telling via some configuration Lines in the Scripts self what a Movement System you use so it can adapt to it would be awesome!

By the Way ... if you already asking for other requests:

I don't know if you remember, i started a Request some Time ago about Z Layers etc.

http://forum.chaos-project.com/index.php/topic,15059.msg191893.html#msg191893

Though it is outdated (did an Update in other Places), i had to realize that it was a doomed Dream, at least with the standard Tilemap Class and much Effort would be needed and so on. So i made up my Mind a while ago and canceled completely the realistically drawing Part of the Sprites. I changed my plans and decided to go only with the "Z Terran Tag" Thing. I don't want to bother you with the long (old) Thread so i sum up my Idea(s):

1. A Script for a local Variable for Events and Player which can store a Value (in my Case it would be the Z Level). It seems there is already a Script out there (here) which can do that though. So, maybe that wouldn't be needed anymore:

http://forum.chaos-project.com/index.php/topic,5357.0.html

2. A Script which gives the Possibility to give specific Tile ID's in your Tileset more than just one Value, independently . So, for Example, one Tile in your Tileset could have the Value "1" and "2". Pretty much like Terrain Tags. Difference here is, a Tile ID can have different Values at the same Time. This should not override or replace the standard Terrain Tag System but instead advance it.
There are Scripts out there which handles "unlimited" Terrain Tags. As much as i understand them, the Values are stored in an Array with a specific Name. But there is still only one Value for one Tile ID. So to make this happen, in theory, i guess there could be more some sort of multiple Arrays with differents Names. Through this a Tile ID could have different Values, stored in different Arrays and you could refer to one or multiple Arrays in Conditions with the help of the individual Names.

Furthermore, i would have two little additions which relate to both Requets and make it complete:

A "negative" collision and trigger check for specific Events (e.g. Commment or Character in Event Name) and Player when they have different Values stored in the local Variable. So, no blocking or triggering between them when the Values are different. Maybe customization for enabling/disabling only collision or trigger check but thats just optional.
Furthermore when that specific Events and our Player are moving towards Tile ID's with a different Value (customization which Array should be checked) than their own, stored in the local Variable, their local Variable Value should change to the Value from the Tile ID's they are moving toward.

greetz 
18
Of course, neither did i demand that you code that thing ;). I also think, your Modular Passable is a great Base to start. Real Elevation in a RPG Maker Game which affects the Player and other Events at the same Time is one of my Dreams. It would open so much possibilites and give more depth in Gameplay Techniques and Concepts, i hope i can see that Day happenings sometime. Maybe with the new RPG Maker coming or with the Help of some smart Scripters with enough Time and Motivation to code that stuff. After all, we are in the Script Request Section :). I guess, i will also look on other Boards for some Help, maybe i'm lucky. And if not, i guess i'll just have to stick to the Player only Solution or work somethingt out that comes near to what i imagine with the possibilties your Modular Passable Scripts offer.

greetz
19
Hello everyone!

Great to see some of best Scripters participating on this Discussion :).

Quote from: Heretic86 on June 06, 2015, 04:25:58 am
For your mapping images, you'd end up using different pages, each page using the same graphic, but a different Z-Index.  Then you can change pages when the player is on one "Level" and a different page when they are on a different "Level".  This allows the player to both move behind the terrain, and on top of the terrain on the same map.  I built a map a long time ago that does exactly what youre talking about by using Events for the Map Tiles the player can both move behind and on top of on the same map.  The map is available in my "collection".  Link is in my signature.


Yes, and here we would get our first Problem(s). The Events on the lower Z level are also effected from the Event Page switch! Lets take my first Image from above where we have Aluxes and the blue NPC Knight next to him. Lets assume the upper cliff Tiles are Events with the specific Tile Sprite. On Page one we have the Tile Graphic with the Passage Settings from the second Line with the Cliff Tiles from the Tileset Picure. This one:



That makes sure, our Player can walk under those Tiles and is displayed under it. Now, Aluxes changes his Z Level to 2 when going up the Stairs. By that, he activates the Event Page switch for that Cliff Tiles. Now the second Page is active and the Tile Graphic on Page 2 looks the same, but is the other one from the Tileset (duplicated) with different Passage settings. In this Case, the first Line of the Cliff Tiles from the Tileset Picture (Priority 0 etc.). This one:



So that, again, makes sure that our Player Aluxes can now walk over those Cliff Tiles and is displayed above them. That is completely fine but we now have a Problem here i already mentioned in my first Post. It only considers Aluxes, the Player! What about our NPC next to him? As long as Aluxes stays on the Ground, it would be fine (considering there is no other NPC on the Cliffs above). But as soon as Aluxes changes his Z Level higher, the Events with Tile Graphic switch Pages and have different Passage Settings. The NPC now can not longer walk under those Cliff Tiles. Your NPC's on Event Tiles are, sadly, no great help anymore in situations like this. You could make the NPC's walk under it with the help of the\event_through commands and so on but that would also make it possible, that NPC's can magically walk on a higher z Level, in this case where the Player stands.

Thats actually what my point is all about. I could easily make it possible for the Player(!) without any fancy Script to walk over Cliff Tiles and under Cliff Tiles on the same Map by using duplicated Tiles in the Tileset with different Passage and Priority Settings and Events. But, like said, only for the Player (and of course for Events too with the Help of Heretics NPCs on Event Tiles Script). But this Solution does not consider other NPC's on different(!) Z Levels because it checks only Passage Settings, Priorites etc. on Tiles that are active in the actual Moment.
And, we have a dozen of Events, specially in bigger Maps, for showing Cliff Tiles. Would be better, it could be done jstu through Mapping. So in short, we need the Possibility to allow NPC's and the Player to take different Passage Settings, Priorities etc. in consideration when actually checking that stuff, based on their Z Level Variable. In pseudo Coding it would look like:

Situation:
Player/Event is moving one tile left and there is a upper Cliff Tile

Now depending on the solution (Z Terrain Tag or Height Map) the Condition would look like:

Z Terrain Tag:
- Check if Tile has a Z Terrain Tag
 - Yes
    - Check if Player/Event Z Level is same as Cliff Tile Z Terrain Tag
       - Yes
          take Passage Setting and Priority from the Cliff Tile id xx in consideration
       - No
          take Passage Setting and Priority from the Cliff Tile id yy in consideration
 - No
   Do nothing

or

Height Map
- Check which Color the Tile Position has on the Height Map
 - Blue
   take Passage Setting and Priority from the Cliff Tile id xx in consideration
 - Red
   take Passage Setting and Priority from the Cliff Tile id yy in consideration
 - No Color
   Do nothing

Furthermore, the Tiles with Z Terrain Tags or Tiles (in a specific Mapping Layer) on a Position the Height Maps Color is indicating have to be drawn in different Sprite_z Values so Events and the Player are drawn correctly (below or above, based on their Z level) because they are changing their Sprite_z Value too when changing their Z level Variable.

Quote from: Heretic86 on June 06, 2015, 04:25:58 am
Adding new Priorities in the Editor tho isnt possible, which is why I had to resort to doing things like using specific Comments to achieve similar functionality.  


Yeah .. like KK20 also said, the "more Priorites" Idea is a bad and not needed Iead, i realized that too. Changing the sprite_z Value is the right thing here.

greetz
20
Hey,

sry for double post but i had some Brainstorming.

First, the increase of sprite_z value like KK20 mentioned should also apply to the specific Tiles/Sprites drawn from the Tileset which are involved in the Z Level System (in this case a specific Z Terrain Tag). If not, Players/Events on higher z level would be drawn over Sprites/Tiles which are logically on a even higher Z Level and so above them.

Second, i've came up with a different way to make it possible to check, if the player and/or a event is on a specific Z Level and check the right Passage Settings. The Result would be the same, which one would be the easier and faster one (performance wise) is the right question. So, how does the other way look like? I guess you all know the Pixel Movement Scripts out there. Some have a fine thing called collision map/picture. So as i know it, you have a Picture for a specific Map on which there are colors that tell the System which Tiles or pixels are passable or not. Let's use this approach for our Idea.

Simply, Height Map(s)! You can have Pictures (saved in the pictures Folder) per Map where 1 Picture would stand for one Z Level for that specific Map. In that Case, you could have as many Z Levels (1 Z Level = 1 Picture) for one Map as you want, in theory. If a Map, the Player is on has Z levels activated, the system would check which Z Level the Player has (and the other Events of course) and then look at the specific Z Level Picture for passage Detection. Because every Z Level Picture has a different Color and one Z Level stands for one Color (customizeable) the system knows, which Tile Passage Setting in the Tileset it should check. Here is a sample i quickly made so you can understand it better:

Spoiler: ShowHide


Okay, explanation:

In this Case you would have two empty Pictures (ignore the actual Game Screenshot below) with one showing the red color and the blue on the other in the Picture Folder. Those are our Height Maps/Pictures. The Colors are our equivalent to the Z Terrain Tag Idea. Below you have the Tileset which was used. As you can see, there are two of the same Sprites, in this Case the upper Cliff Sprites, for a Level Switch. That is needed so the System knows which passage setting it needs to check.

On the Screen, our Aluxes ist the Player. So he is on Level 2. The NPC next to him is clearly on Level 1 (Ground). So what is happening here? First, the Upper Cliff Sprites from the Tileset which are set to the Color blue are drawn with different (lower) sprite_z values that the ones with the color red (higher). Events with a increased sprite_z value when changing their Z Level are drawn properly now, like Aluxes in this case and the NPC next to him. Next, the System is checking which Z level the Characters are and can then, because of the help of our colored height Maps/Pictures, properly check the right passage settings for the specific Tiles. For the Player (Aluxes) the Passage Settings from the very first upper cliff Tiles in the Tileset are considered because he has a Z Level of 2 and the Color blue is configured to check for Level 1 and 2. The NPC next to Aluxes is on Z Level 1 (below the Player) so for him the Tile Passage Settings from the second 3 upper Cliff Tiles are considered.

greetz