Thread Rating:
  • 4 Vote(s) - 4.5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 What's up, RMers?
so is it like an auto connect? even if i download the demo and put it in an experiment game, i still won't figure it out.

got up this morning and drew this snowman. i'm going to add an area before my snow village, and this guy will be there as a mini boss to test your new party member. then he'll show up as the elite-normal enemy in his dungeon.

[Image: snowgoon_zps1fb747dc.png]
Reply }
"please enter an interger between 0 and 200"

Who thought it was a good idea to limit states in this way!? The percentages are so non-linear! 50% is half, and 200% is double. it should be 1-1000. Or SOMETHING.

I'm going to have to write my own editors, it seems.
Reply }
Well, there's a fix for elements that do the same thing which we editors could change. (>Click circa 2005<)

I wonder if you could do likewise for states?
Up is down, left is right and sideways is straight ahead. - Cord "Circle of Iron", 1978 (written by Bruce Lee and James Coburn... really...)
[Image: QrnbKlx.jpg]
[Image: sGz1ErF.png] [Image: liM4ikn.png] [Image: fdzKgZA.png] [Image: sj0H81z.png]
[Image: QL7oRau.png] [Image: uSqjY09.png] [Image: GAA3qE9.png] [Image: 2Hmnx1G.png] [Image: BwtNdKw.png%5B]
Above are clickable links

Reply }
Unfortunately, no. This is an editor limitation and not a script one. If you force a state to have more than a 200% buff, it works. I'll just use txt2rgss and edit it manually.
Reply }
Alas.... I may not be done with Lycan.

There are three things I still need to work on in my ABS. But of the features that will be in the next demo, I have:

An Adjustable AntiLag
A normal antilag prevents the sprites from updating or having the graphics rendered within the spriteset if the event's source is not within the 20X15 playable/visible area. Unfortunately, this could make fairly tall sprites 'POP' into view if they weren't originally within the screen, or cause a strange graphics drag/undispose glitch if a tall sprite's source leaves the area.

This new feature allows the designer to add padding to the top, sides and bottom edges of the screen. They are individually set, so padding on the top may be set to two tiles while padding on the edges are set to 3. By default, I set the bottom padding to a 6 tile area for extremely tall tiles/events, like trees.

Jumping height check
I already set it up so you can make certain tiles impassible when jumping. This allowed me to create ledges you cannot jump off which would look totally stupid. But there was another check it lacked.

I added a feature that checked if you were jumping over (or through) tiles that had a priority rating of 2 or more. Sure, a tree stump doesn't have a priority of 2, so you can jump over that. But tiles above the trunk base are typically set to 2 or higher. So I set up a system that (ignoring autotiles) checked to make sure it wouldn't pass through tiles with too high a priority. I mean... who jumps over trees???

These are two features that are coming. There are others I have planned.
Up is down, left is right and sideways is straight ahead. - Cord "Circle of Iron", 1978 (written by Bruce Lee and James Coburn... really...)
[Image: QrnbKlx.jpg]
[Image: sGz1ErF.png] [Image: liM4ikn.png] [Image: fdzKgZA.png] [Image: sj0H81z.png]
[Image: QL7oRau.png] [Image: uSqjY09.png] [Image: GAA3qE9.png] [Image: 2Hmnx1G.png] [Image: BwtNdKw.png%5B]
Above are clickable links

Reply }
i needed a lighthouse. so i made one

[Image: th_lighthouse-light_zpsb5319123.png]
Reply }
There is an awful, awful crash bug in my battle simulation script (used by my AI to determine actions). I am pretty sure it is caused by an sim-battler trying to choose a target when all the sim-targets are dead; normally this ends the game but not when it is a simulated battle. The awful thing is that this bug only happened once in the whole time I was testing it, so I cannot track it down.

Other than the crash bug, it's working fine! In one amusing battle, my two heal-spammers abandoned the party lead and started attacking the enemy. They had correctly deduced that the enemy would be able to kill the party lead this turn even if they were to heal him, and so did not waste the MP.
Reply }
im pretty sure there was a script here somewhere that lets you view what's actually happening in game to do bug fixes. can't remember the name of it though.
Reply }
If there is, you'd have to keep records of every value in action or change. Tracking something down like this is hell. Confused It drives me nuts.

But it makes me wonder why 'battle end' doesn't occur when all enemies, simulated or otherwise, are dead. Is something different about simulation enemies that don't register as being dead like regular ones?
Up is down, left is right and sideways is straight ahead. - Cord "Circle of Iron", 1978 (written by Bruce Lee and James Coburn... really...)
[Image: QrnbKlx.jpg]
[Image: sGz1ErF.png] [Image: liM4ikn.png] [Image: fdzKgZA.png] [Image: sj0H81z.png]
[Image: QL7oRau.png] [Image: uSqjY09.png] [Image: GAA3qE9.png] [Image: 2Hmnx1G.png] [Image: BwtNdKw.png%5B]
Above are clickable links

Reply }
The simulation occurs at the beginning of a turn, and is used to give battlers prediction. We need this so that all the healers do not try and heal the same damage. Before I wrote the simulator, battlers were determining their action when it was their turn, which works but not if the move has an action speed different than default.

The problem occurs on a decisive turn; because the simulation happens BEFORE the actual turn, all simulated battlers can be dead before the real ones are.
Reply }




Users browsing this thread: