Jump to content

rainlash

Member
  • Content Count

    122
  • Joined

  • Last visited

Everything posted by rainlash

  1. Don't worry, you have all the characters through Chapter 6! You have 11 characters at that point and I wanted you to be able to choose which side should have 6 characters and which should have 5 characters. So I gave both sides 6 deployment slots so you could choose.
  2. Sorry about that. You have a slightly older version of the engine, which still had that bug. You can download the latest version of the engine and move your Saves folder over and everything should work.
  3. Yeah, or just direct message me them!
  4. That sounds weird. I don't believe this issue has been reported before. If you go to your the_lion_throne/saves/ directory there should be a file named debug.log.1. (If you didn't start playing the game again). There's a debug.log.1 through debug.log.5. It saves the 5 most recent times you played the game. You can send me those and I should be able to tell from those what is causing the game to crash.
  5. Hello all. Since I've gotten a lot of messages recently, I've decided to set up a discord server for anyone who's interested in working with the Lex Talionis Engine and/or is playing the Lion Throne or any of the other games made with the engine. If you have questions and don't want to wait for me to reply (since I only normally check this place once a day), you can throw a message on the discord server. Or you have comments or you want to share your work? That's cool too! https://discord.gg/nNBCUM7 Anyways, What does your the_lion_throne/Saves/ directory look like? That's a really weird bug; I don't blame you for not wanting to replay chapters over and over again. You need pyinstaller. pip install pyinstaller should do it for you. You might? also need the ogg vorbis audio_dlls in order for the game to play audio -- I ran into a bug once when I didn't include them in the build. You can grab them from the engine executable that I distribute normally. They are "libogg.dll", "libvorbis.dll" and "libvorbisfile.dll".
  6. Neat! I gave them a test myself and they work great! I've added them to the repo under their original names (Elfire & Luna). Hopefully it didn't take up too much of your time and was rather straightforward how the spell animations work...
  7. That's not really in the plans -- I don't have a Linux machine, although I guess it wouldn't be hard to spin up a virtual Linux box. I figure basically everyone who uses Linux in this day and age can navigate git, python, and pip, which is really all you need to run both the engine and the editor. If you're a Linux boi, you'll probably want to mess around with the bare code anyway! Plus, I'm not sure if a build of Linux on one distro would transfer correctly to other distros. No, I don't think it's possible to have the weather particle effects be above the scenic map scenes, unfortunately. You can use the `add_weather` command to ... add weather, but it only works on the main map, and backgrounds will be drawn above it. I'm not quite sure what you mean by this... There is a "Fire" weather type copied from FE6, but I don't think this is what you mean. In other news, Hibari Oozora, you might be happy to know that there's a new build of the engine with support for vertical choice menus, thanks to TheeBill, who took the initiative and coded them up for me. You can find the information on how to use them on the wiki. See here:
  8. You right. Thanks! It should be fixed now. AFAIK, it actually existed only on the git repo and not in the most recent build. I just forgot to push my changes that I made for the build to the git repo.
  9. It's definitely possible to put them into LT as is. Animations can have transform in and transform out poses, and you can access them by adding the "transform" component to an item (like let's say a Dragonstone). That should be all you need to make Manaketes work the way one would expect from the GBA games. Converting transforming animations from the repo using the animconversion utility is hit or miss -- Some of the animations seem to convert fine, but others just don't. YMMV. Right now, you can only make range based on a number or MAG/2. For instance: <item name="Physic"> <id>Physic</id> <spritetype>Staff</spritetype> <spriteid>3</spriteid> <components>spell,heal,uses,beneficial,map_hit_color,wexp,exp</components> <weapontype>Staff</weapontype> <uses>15</uses> <RNG>1-MAG/2</RNG> <value>250</value> <desc>Restores (User's Magic + 10) HP</desc> <heal>10</heal> <LVL>B</LVL> <targets>Ally</targets> <map_hit_color>96,144,232</map_hit_color> <wexp>3</wexp> <exp>22</exp> </item> It's kind of janky. I'm exploring other ways of doing this for the future. That is a little wild, but no. Not possible right now. Activated Items use the same routine as selecting a unit for rescuing, trading, etc, and not the spell routine, so you're out of luck. If you wanted to mess with the code, it would be possible to change that -- like force the activated_item to enter the spell routine instead of the select routine if the item is a spell, but for now, not possible.
  10. Nope! Adding spell animations is HARD WORK. 🙂 I didn't see these edits? until just now. Uh, no not possible to reorder choices vertically in the base engine. So you gotta make sure your choices are small. I guess try and keep to yes vs no? The check should be: if;gameStateObj.game_constants['LanselotIntroduction'] == 'Forgive Me' s;Lanselot;Yay! end The choice the player makes is saved as the value associated with the key 'LanselotIntroduction' in game constants.
  11. I'm not super well-versed in unicode..., since I just learned about it to enable the non-ASCII characters in the engine. My guess is that the bug is likely caused by your input not actually being valid unicode "utf-8". From my understanding, unicode is a multi-byte codec, which means each unicode character (or byte) is actually followed by another marking character (byte) (except the basic ASCII characters). Your error says "invalid continuation byte", which leads me to think that it is not being correctly followed by the right character. "0xed" in unicode should be í , right? There are other subcodecs, like ""latin-1" that have "0xed" also meaning í , but without the continuation byte. Maybe your file is actually in that format? Try changing the format of your text file? Otherwise, you can send me the script that the engine was reading when it crashed, and I can take a look. Yeah, there's no other turn change script. I figured any user could just move it to the start of the player phase, like you've thought of.
  12. Yes. I only grabbed the letters that were available from the Sacred Stones world map. So the letters in "Renais", "Frelia", "Grado", "Carcino", etc. Obviously, a lot of letters are never used; If you want to add the rest, feel free and thanks!
  13. These were helpful. I ended up drawing a bunch of my own custom bitmap characters to go along with these, which I'm releasing with the latest build, v0.9.3.20. Unicode should also now work both in event scripts and in-game. Although it's not super well-tested, so use it sparingly. UTF-8 should work everywhere, but there's no guarantee. Obviously only the letters I bothered to draw will work, of course -- not every UTF-8 character. Here are the one's I drew. Other fixes include two new unit tags: "IgnoreBonusStats" and "IgnoreBonusGrowths", which prevent a unit from receiving difficulty bonuses. And there should be some recent bug fixes as well. Tell me if there are any more!
  14. Yes, this is correct. Thanks for helping out, ZessDynamite! Basically, you've put two combat states on the stack, but the engine can only have one combat instance at a time. So you overwrite the first combat instance (the natural, normal one) with a new combat instance (the event one), which is fine. But then, when that one ends, the state stack wants to go back to the previous combat state, but the old combat instance has been overwritten in the meantime, and so crash. The way I implemented scripted combats in the Lion Throne was kind of janky in retrospect (I only used it for the prologue), but here goes. If you don't use the Level Editor (because the Level Editor will likely overwrite this change), you can modify the UnitLevel.txt file for the associated level directly. Here's an example of the first enemies' definitions in the Lion Throne # First enemy enemy;0;E1;Fighter;f1;eIron Axe;0,0;Pursue;Soldier;Maximum HP -5 # Second enemies enemy;0;E2;Soldier;f1;eSlim Lance;0,0;Pursue;Soldier You can see that their weapons have an "e" prepended? That means "event", and it will force all combatants in combat with them (and themselves as well) while their using that item, to Hit if at all possible. Boss fight convos are always done in the normal map instead of the battle screen. This is because conversations were added to the engine way before full combat animations, and I never bothered to go back in and modify when to do boss fight convos. I may consider adding it to the to-do list, but I don't honestly don't think it makes much of a difference... I also want this. It's on the todo list, but would be made faster if someone could get me all the bitmaps for each of the new characters (both uppercase and lowercase, and for as many font types as possible). I'm not a good GBA hacker, so I don't know where I would look for the base font bitmaps. Once I have the bitmaps, its trivial to support UTF-8 for conversations and units, items, statuses, etc.
  15. Thanks for the bug report. I've fixed it in the git repo. When I have more changes, or just in a couple of weeks, I'll go through the whole build process. Yes, it does. You can check out, for instance, the "Level0/attackScript.txt" that comes with the Lion Throne. Simply put, you can add "s;Jane;I am level {eval: self.unit.level}." to display the unit's current level. Just wrap the python command you want to evaluate in a "{eval: my_python_command}" syntax.
  16. The crash logs also appear in the Saves/ directory. The most recent one is always named "debug.log.1". You can scroll all the way to the bottom to see the error message that caused the crash.
  17. All Auras in the Lion Throne are standardized to range 3 (3 tiles in all directions) to make it easier on the player to remember. But, like ranged attacks in the Lion Throne, Auras are affected by line-of-sight. So the wall is blocking the spread of the aura. I personally used the Tiled Map Editor https://www.mapeditor.org/ , along with a little bit of GIMP, to make the maps in the Lion Throne. You can download my collection of tilesets here: https://www.dropbox.com/s/e4h3by9pcrrhtr6/TileSets.zip?dl=0 . I would choose a tileset, make the map in Tiled, export it as an image, and then do any final touch-ups with GIMP.
  18. Likely a problem with the unit id. What's happening is the preloaded level you are using has some unit_id defined that is no longer defined in the "Data/units.xml". So the engine fails to find a unit matching that id. Make sure all the unit "names" in the preload_levels.xml (they're really the unit ids) are defined in the units.xml.
  19. Not really. I incorporated the ability to make "devil axe" chance to kill oneself component, but no generic self damage component. This is on the todo list. No. I can consider adding this to the engine though. Do you have pyqt5 installed? Sometimes you also need regular Qt5 installed -- it seems to depend on how pyqt5 was installed on your system. The editor might need the "Audio/music" and "Audio/sfx" folders to exist in order to load music correctly -- That's a bit of an oversight on my part but can you try adding those in? The Git repository does not come included with audio, since the audio for the Lion Throne game is over 100 MBs. You'll need to download that separately: https://www.dropbox.com/sh/slbz2t7v1fc6uao/AACiznGLm442qcdOAGbQtnmwa?dl=0
  20. Thanks for the bug report. It's now been fixed on the main git repo. You should have also needed to import CustomObjects before your change works. I guess the "official" place would be the Gitlab issues, but I honestly don't check that as much as I check here, so this is fine. You can also PM if its something small.
  21. Assuming your skill's ID property is 'NoSwiping' STEAL_DEF = 1000 if 'NoSwiping' in [s.id for s in unit.status_effects] else SPD This also works (alternative way of writing the same thing): STEAL_DEF = 1000 if any(s.id == 'NoSwiping' for s in unit.status_effects) else SPD Assuming you gave a skill the component steal_immune (so you could have several different skills that share the steal_immune component) STEAL_DEF = 1000 if any(s.steal_immune for s in unit.status_effects) else SPD
  22. I wish I could tell you more, but I honestly don't know. On both my machines that I test compatibility with, they are able to load the compiled C modules just fine. After doing some research, my understanding is that somewhere in your stack there is a 32-bit vs 64-bit mismatch. My OS is also Windows 10 (obviously 64-bit), my Python (3.7) is 64-bit, and the compiled C code is 64 bit. If you are using the executable version, that should all be the same and you should not run into any problems. If you are not using the executable version, maybe your version of Python is 32 bit? But I honestly don't have a very good idea. Luckily its probably not a big deal. You'll run into speed issues if you have big auras or spells with line of sight, or greater than 15 movement, or the map gets too big (bigger than say 60 by 40), but otherwise everything should work fine.
  23. There's no way to have a thief only steal an item if their con is equal to or greater than the item's weight. Right now the only item discrimination that is made in the steal routine is whether you have the steal constant set to 0 or 1 (0 for GBA style, and 1 for the Lion Throne style). But you can make a unit immune to having their items stolen. There are two equations defined in Data/equations.txt. STEAL_ATK and STEAL_DEF. If STEAL_ATK is greater than an enemy unit's STEAL_DEF then you can steal from that unit. Right now they both are set to be SPD, so that like normal Fire Emblem, if SPD is higher, you can steal. Just change STEAL_DEF to: STEAL_DEF = 1000 if 'NoSwiping' in unit.tags else SPD and then give the unit you wan't to be immune to stealing the NoSwiping tag (or you know, you can name the tag whatever you want). Hopefully that helps.
  24. Hey thanks for the bug report! I think somebody else actually ran into this issue before, but your report crystallized the issue and helped me understand the problem. The problem is that whenever any event script ends and the game is in the win state ("win_game" has been called), the outroScript for that level is called. Makes sense right? Well, an outroScript itself also ends at some point, and you would end up with an infinite loop of outroScript ending and then calling outroScript. So a flag is set right before the first outroScript is called -- outroScriptDone flag. Now when the first outroScript finishes up (or any event script), the engine checks whether this is set and if so, proceeds to save screen and the next chapter. So when your interactScript ends, the engine checks whether outroScriptDone has been set, and seeing that it has and outroScript should be therefore be done, leaves the level. This is the issue you've run into. So I've got two solutions: Solution 1: This solution does not require you to update to a new version of the Engine, but is gloriously hacky! # At the beginning of the outroScript if;not gameStateObj.level_constants['outroStarted'] # Set this level constant so this section is not repeated when we repeat the outroScript set_level_constant;outroStarted add_unit;Alice;10,15;warp u;Alice;Left s;Alice;Not on my watch! r;Alice wait;50 # Make it so that we can repeat the outroScript by turning off the flag (as if we've never reached the outroScript yet) # This is tremendously hacky if;gameStateObj.statedict.update({'outroScriptDone': False}) wait;1 # We just need the Engine to parse our if statement and change the flag to False end interact_unit;Alice;Bandit1;Crit end wait;300 end_skip Yes, we're using an if statement to convince the Engine that it hasn't done the outroScript yet, making the Engine repeat the outroScript, and then making sure it skips the sections its already done. Solution 2: Wait for me to update the Engine. I plan to change the Engine so that a level won't actually end unless an outroScript itself finishes (as long as one exists for the level). This is the less fun but probably better solution. Hopefully that explains why you ran into the issue. It was kind of complicated for me to figure out on my end -- some of the code involving the outroScript is like 6 years old...
  25. This is correct. Although you shouldn't receive this error if you are using the Level Editor executable version. PIL/pillow comes included with the executable. These errors only kind of matter, although I'm wondering why you seem to get them. Basically, while the 99% of the Engine is pure Python, I found that for some very CPU intensive functions, pure Python wasn't always fast enough (think, pathfinding and line of sight calculations). So I wrote some Cython modules: compiled C code that Python calls. If, for some reason, your computer can't use the C code, that is weird. Likely, you either have a completely different version of Python or you are not using Windows. But, it doesn't really matter, because as you can tell, the Engine will fall back on the old pure python implementations, which works fine, just a little slower.
×
×
  • Create New...