rainlash

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...

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.

Impressive work you've got so far! I took a look at what could be causing the bug and fixed the cameras map issue on my end. It's possible for the Overworld to exist irrespective of any specific level, but the camera did not expect that. The latest update to the git repo has a fix for the camera. I also have some comments on your overworld_data.txt. You may have already figured this out, but you're not using the routes correctly. You only need one route between each pair of nodes (so you need a route from 0 -> 1, but not also 1 -> 0). The direction of the routes is defined by the numpad directions (ie, 8 is up, 2 is down, 9 is to the topright). So having a route that is 8, then 2 like you showed yesterday doesn't make any sense. That route would be up then down, putting you back where you started. You also need to make sure the routes actually connect their nodes (probably -- the engine may handle this graciously). Try something like this (untested...): # Level ID ; Location Name ; Icon Index ; Position # The positions are multiplied by 8 for some reason. # Everything is done on 1 to 8 basis in overworld ===Locations 0;Milthon Grove;0;63,40 1;Redrun Village;1;66,39 # Route connections (between level id's); Route (numpad) ===Routes 0,1;6,6,6,8 # Party ID must be integer -- I don't think this is true anymore; Party name (must be character) ===Parties 0;Randall Not right now unfortunately -- but it's actually a really easy fix on my end. Items don't know whether they are being used or attacked with, but weapon aspect takes precedence over usable aspect, so your Sword was using it's weapon aspect on the unit. I added a single line that makes it so that the weapon aspect will not be used if the attacker and defender are the same unit (like when using an item). So now it will use the item aspect instead, and will behave like you expect it to. Your item setup will work as you expect it to once you get the latest update to the Engine. I have pushed the change to the git repo, so if you use that, you can grab it. I don't know when the next build of the Windows executable will be completed -- I don't want to go through the build process for just one line of code change... But rest assured the next version will have your change.

I honestly haven't taken a look at it in a while. It's on my todo list, but very far down. I do know that the last time I looked at it, you could place a party on the overworld and move them between chapters, but I think the integration with event scripts was still buggy. If you want to try it out, just set overworld=1 in constants.ini and fill out the Data/overworld_data.txt file. My DataSacredStones/ folder in the git repo has an example that I was using. The Data/overworld_script.txt file controls what happens in the overworld (although this may be buggy). It looks for "ow_trigger" calls from other scripts and then does them in order when the overworld is first displayed after every chapter. You can find all the overworld event commands in Dialogue.py (line 367+). There's no documentation on what the commands do anywhere. If you do manage to get something working on your end, let me know, because that would be pretty awesome!

Unfortunately, you can't call both `win_game` and `victory_screen` in the same script. `win_game` doesn't have any effect until the event script completes. Once the script completes, then the Engine then checks to see if `win_game` was called and does a lot of cleaning up and changing of state. So if you call `victory_screen`, `victory_screen` will look at the results from your last win -- which, in your case, is going to be the results from the last level. Basically, call `victory_screen` in the outroScript unless you have a good reason not to, since the outroScript is guaranteed to occur after `win_game` is called. I've updated the wiki to make this more clear. Yes. In the newest version of the Engine, v0.9.3.18, there is now a dedicated, unchangeable screenshot key. Since there doesn't seem to be any standard, except Window's "Alt + PrtScn" / "Win + Alt + PrtScn", I chose the grave/backquote key (`). You can find it generally at the top left of the keyboard -- the symbol under the ~ symbol. You don't need to press shift. Pressing this key will output a screenshot called "Lex_Talionis_{current_datetime}.png" to the current directory. Hopefully, you find this useful. The newest version of the Engine now has support for two additional secondary AIs. AI #10 will approach any destructible tile that does not also have HP (so something like a destroy-able village). AI #11 will approach any tile with HP. I also changed a couple of the AI presets in the ai_presets.txt file to better reflect these changes. The AI you were probably using had a secondary AI that approached both destructible and HP tiles, but could not interact with HP tiles. The "PursueVillage" preset AI now only pursues non-HP destructible tiles, like its name suggests. The "PursueTile" AI pursues HP tiles, and the new "PursueVillageTile" AI pursues both. I've also fixed this in the latest version of the Engine. The difference was actually that Absolution had set experience for staffs, which meant the game never needed to calculate the amount of healing done. All of these changes above are in the latest version of the engine, v0.9.3.18, which is currently available on the git repo. I'll build it and post it to the usual place sometime later today.

That's not a problem -- the Engine is just informing you of missing map sprites. For instance, there is no "other" team (green) Myrmidon class map sprite, so it yells at you. You can safely ignore it if you don't care because you don't plan on using an "other" team Myrmidon in your game. However, if you do plan on using an "other" team Myrmidon, then you best pay attention because when you boot up that level in Engine, it'll display the unit as a Citizen.

Since you specified that "Cleanse" is a spell, we don't have to worry about counterattacks, which makes writing the if condition in the interactScript simpler. First, we check that the defending unit (self.unit2) is named "Hilaru". Then we check that the attacking unit's (self.unit) first item (which would be the item they're using if they're using a weapon or spell) is named "Cleanse". If so, set that we have unlocked the good ending for this level. if;self.unit2 and self.unit2.name == 'Hilaru' if;self.unit.items and self.unit.items[0].name == 'Cleanse' set_level_constant;good_ending end end Later, in the outro_script, you can check to see if "good_ending" is set in the level constants: if;"good_ending" in gameStateObj.level_constants and change the ending if so. The unit that attacked with the spell is referred to as self.unit in if statements. If you want that unit to speak, you can use {unit} in dialogue commands. Although, the interactScript is called after combat, so you'll need to use the fightScript if you want it to happen before combat. This if statement should work there too. Like so: if;self.unit2 and self.unit2.name == 'Hilaru' if;self.unit.items and self.unit.items[0].name == 'Cleanse' set_level_constant;good_ending u;{unit};Left s;{unit};Take that, Hilaru! r;{unit} end end If you wanted something more complicated, I would recommend foregoing using the interactScript and rather have the spell apply a specific status on hit that lasts forever. Then you can at the end of the level, just check to see if Hilaru has that status. if;any(unit.name == 'Hilaru' and 'Cleanse_Status' in [s.id for s in unit.status_effects] for unit in gameStateObj.allunits). But this should suit your needs for now.

Thanks for the bug report! Here's an easy fix: Go to your Data/terrain.xml. Navigate to the Snag terrain and change its minimap key from <minimap>Snag</minimap> to something else that is a valid key, maybe like <minimap>Thicket</minimap>. I never used the Snag terrain in the Lion Throne and must never have caught that I put an incorrect minimap key for that terrain. I've updated the git repo terrain.xml to fix this bug also.

What do you mean by this? I'm not sure I understand. But just to check, you are still getting the empty MapSprite.png error with the latest version of the Level Editor? It should say v0.9.3.14b at the top. What image length and width does it output to the console when it loads and saves the MapSprite? I was hoping the latest Level Editor update, because it loads the image on import and then saves over it with a new format, would remove the issue you are having. For instance, when you import a new image to use as the Map Sprite, that image should be overwritten immediately. You can tell this because the filesize should change. I was hoping this new image would not have the sRGB length bug that you and Sealvester ran into.

The latest update to the git repo should fix these issues you've experienced -- I think the issue with the promotion music was that your promotion music was the same as the base or non-existent -- that should be fixed. Also, I'll have a new build of the executable with the updates sometime soon. What do you mean by "Lock a promotion to a specific item/event while keeping the auto promote option"? Do you mean that you want to be able to not allow certain units to auto promote, but by default regular units should be able to auto-promote? If so, I can add a unit or class tag that says "No auto-promote" and have the engine respect that. It's definitely possible, and not particularly difficult -- just time on my part. I envision it requires adding 2 additional states to the game, and several ancillary functions, game constants, and an event command, which will take some time to code up. I can add it to the to-do list though. Glad to hear you are enjoying the Engine! If you've managed to add paragon and leadership stars, then you might have enough experience to make the BEXP system yourself... Did you make the leadership stars actually appear on the Info Screen?

Are you running the Level Editor executable or did you just clone the Git Repo? If you just cloned the Git repo, can you pull down the latest update I made to the Level Editor and do the exact same thing again (using the fe8map1.png file you already have)? If that doesn't work, I also updated the fe8map1.png file from the wiki -- can you try that one? I do not receive this error on the computer I'm currently working on -- I don't even get the libpng warnings that you get. Which obviously makes testing to try and solve the error very difficult. I have PyQt5 5.13.1 on this machine so I don't know for sure whether it is a PyQt error. But when I get back home to my desktop later today, I should be able to check further. I remember that it does sometimes have those libpng warnings, so I'll test these changes there. Other people seem to have this problem too -- I'm trying to solve it from the code side of things so that nobody else runs into this issue, but it seems everyone else just removes the iCCP/sRGB nonsense from their png files... https://gist.github.com/bluenex/0af2f41fda9954df73a8 https://wiki.archlinux.org/index.php/Libpng_errors Sorry that I don't have anything more concrete -- Just replying back so you know I am looking into the problem. Your error messages have been a big help.

What version of the Engine are you using? Because if you are using a very old version of the Engine, I could see you running into an issue like this. Assuming you're running a new-ish version though, then the issue with "triggers" is that they are just not very well implemented right now. I would recommend not using them -- just use the "add_unit" and "move_unit" commands. I know its a more work on your end, but it's not buggy and gives you a bit more fine-tuned control over reinforcement placement. "Triggers" are kind of relic of an older method and really shouldn't be used any more. I need to hurry up and remove them, honestly... Just turn your units into reinforcements and, in your turn change script, call "add_unit;reinforcement_event_id;starting_position" and "move_unit;reinforcement_event_id;position_i_want_to_move_to". The italicized sections get replaced of course. This is what I did for every reinforcement in the Lion Throne, so I know it works well. It is explained somewhat in https://gitlab.com/rainlash/lex-talionis/-/wikis/15.-Reinforcements "Using the Reinforcement Menu without Triggers" section of the wiki. You can also take a look at how I implemented reinforcement events scripts in many of the chapters of the Lion Throne. PM me if you have any issues with this. For the custom color palettes in battle animations, I would hope that its pretty straightforward. If you still have the animation files that came with the Lion Throne, you can look at (for instance), the /Data/Animations/Knight folder to see how custom color palettes are added. For each animation: "Lance", "RangedLance", and "Unarmed", there are four image files, one for each of the color palettes I use. There's always "GenericBlue" and "GenericRed" images, which are the fallback color palette options for player characters and enemy characters if there is no custom color palette defined. But then there's the "Harold" and "Theo" images, which are how I have custom palettes for those two characters. Instead of using the normal image in engine, any Knight with the unit id of "Harold" will use the "Harold" image. Does that make sense? To make your own, just (1) open, for instance, "Knight0-Lance-GenericBlue.png" in Paint or GIMP or Photoshop, (2) swap the colors, (3) and rename it "Knight0-Lance-Winston.png" (if your character were named Winston). Now, as long as your character Winston is a Knight, is using a Lance in melee range, and has the unit id "Winston", they will use that color animation.

I could add this feature, but I would need to understand more about what you would want it to do. I assume you would want a command in the dialogue that would make it wait, but for how long? Should the length be dependent on the amount of text before it? Should pressing "A" move past the wait anyway? Should pressing "Start" move past the wait? If you have a video of an example from the GBA for me to model it on, that would be helpful. I think it's likely that Absolution just had too many characters in a row without a "{w}{br}" that two lines of text can't fit. Unfortunately, there's no easy way to detect this except running through the dialogue manually. Slight error here but I can't edit the post anymore. To get the crit section to work, you'll need to change all instances of "crit" component to "crit_hit" component. There is no "crit" component. I have a new version of the git repo uploaded. Can you try doing the same thing again, but this time if it doesn't work, can you send me a screenshot of what the editor prints to the screen. Essentially, send me the text that follows this: pygame 1.9.6 Hello from the pygame community. https://www.pygame.org/contribute.html Debug: 1 ERROR! No words.txt file found in the data directory. Version: v0.9.3.13 Also, I updated the code so that if you "Import New Map" a map that has the same size as the currently displaying map, it will not overwrite your TileData. Hopefully this is a small amount of help while we try to figure out the big problem. Recently, I opened your map image in GIMP and it told me that the image has an embedded color profile. I doubt that's the problem (since I was able to use your image just fine as is), but can you make a version of your map image without the embedded color profile and also without any alpha (transparency) and try using that instead? You should be able to do that in GIMP or in Photoshop. If you don't have either of these, maybe try saving it as a new file in Paint?

Thanks for the screenshots! I took a look and tried to recreate the events, but I don't get that weird empty MapSprite.png file that you get -- There must be something else to the problem. My expectation is that the image is somehow not defined in the editor and its saving a null image (which should break, but isn't). I've added some more error checking and moved around some of how the map sprite is saved in the latest update to the git repo. Can you pull the changes and try again? Tell me if the error continues... Yeah, this is fine. You can also PM me if you wish. So, I thought about it for a while and I think its not possible to literally change the STR, SKL, and SPD by 1.5x of a unit, only when their HP is <= 50%. There is no conditional status effects -- but I should that ability, since it seems to be wanted by more than one user -- so you can't have a conditional status effect that gives out those changes. Even if you could, there's no fractional changes to stats available. So, I would recommend a slightly different approach, to accomplish the same thing gameplay wise. <status name="Resolve"> <id>Resolve</id> <image_index>8,8</image_index> <desc>Grants effective STR, SKL, and SPD 1.5x if HP is under half.</desc> <components>mt,avoid,hit,attackspeed,crit,class_skill</components> <!-- Add STR/2 to mt, so you effectively hit for STR/2 extra damage --> <mt>self.stats['STR'].base_stat//2 if self.currenthp &lt;= self.stats['HP']/2. and item and not item.is_magic() else 0</mt> <!-- Add SKL/2 to hit, so you effectively have SKL extra accuracy (assuming Accuracy = SKL*2 normally) --> <hit>(self.stats['SKL'].base_stat//2)*2 if self.currenthp &lt;= self.stats['HP']/2. else 0</hit> <!-- Add SPD/2 to avoid, so you effectively have SPD extra avoid (assuming Avoid = SPD*2 normally) --> <avoid>(self.stats['SPD'].base_stat//2)*2 if self.currenthp &lt;= self.stats['HP']/2. else 0</avoid> <!-- Add SPD/2 to attackspeed, so you effectivly have SPD/2 extra attackspeed --> <attackspeed>self.stats['SPD'].base_stat//2 if self.currenthp &lt;= self.stats['HP']/2. else 0</attackspeed> <!-- Add SKL/2 to crit, so you effectively have SKL/4 extra crit (assuming Crit Rate = SKL/2 normally) --> <crit>(self.stats['SKL'].base_stat//4 if self.currenthp &lt;= self.stats['HP']/2. else 0</crit> </status> It's complicated, but it basically does what you want, without actually messing with the stat values themselves. There will be weird issues if you use a weapon that is not magical and also doesn't use STR for damage, but otherwise, this should do what you want.

Interesting. I didn't notice that I had two different sample rates of music included. I'm probably not going to fix it as it stands, because I'm not really updating The Lion Throne as a game anymore, and a slight speed decrease and pitch shift is not that big a deal, but its good to know. For future work, I guess 44.1 kHz is the correct sample rate to use. Thanks for mentioning it here. I don't check the engine page very often, so your issue could have languished for quite a while. I have never gotten these errors and cannot recreate it myself. I don't even know how this would occur. I don't think the editor even has the capacity to create a blank MapSprite.png. Has anyone else whose used the editor ever experienced an error like this? If you or anyone else can recreate this error in a few well-defined steps, that would really help me find it. It is the case that deleting a character that a level is using would cause the editor to crash when it tries to open that level. I've fixed the editor to now just ignore characters/units and classes that aren't defined anymore (except "Citizen" class, since that is the default class). It's updated on the Git repo and I'll have an executable update in a couple of days. I've not seen an error at all in the Engine proper. Just to check, I deleted EVERY unit in the units.xml and played the current DEBUG level and The Lion Throne prologue, and no errors occurred -- besides like the prologue making no sense because Ophie and Prim never show up.

Can you receive PMs? I sent a PM to you about your death quote info problem earlier this month. The problem is not with your death_quote_info.txt script, it's earlier in the chain -- probably your interactScript.txt for the level. Send me that one and I can take a look again. Also, tile information is readable, as long as the gameStateObj is accessible. So you can read tile information from events scripts and from the "mt", "hit", etc. item components. Here's an example for the latter: <status name="Ranger's Guile"> <id>Rangers Guile</id> <image_index>8,1</image_index> <desc>Grants +30 hit while on Plains or Forest.</desc> <components>hit,class_skill</components> <hit>30 if gameStateObj.map.tiles[self.position].name in ('Plain', 'Forest') else 0</hit> </status> Yeah, this doesn't seem to possible right now. If a class has a choice of promotions, that choice is always available no matter how you promote. Changing the LVL of a weapon to a specific character obviates the need for any specific weapon rank on that weapon type, but you still need to have at least 1 point in that weapon to wield a weapon of that type. As an example, making Wyrmsfire an "Ophie" LVL weapon would not let Ophie use the weapon while a Myrmidon (since Wyrmsfire is not a sword). As far as I know this is how Fire Emblem normally works. For instance, I believe Chrom can't wield Falchion while an Archer.

New build of the Engine is up. v0.9.3.11 Fixed. Thanks for the error log. Okay I figured this one out too... It's a really insignificant bug on my end, but it basically meant you couldn't have tier 3 or greater generic units. The code would enter an infinite loop on trying to process any tier 3 or greater generic units. This has been fixed in v0.9.3.11. Thanks for the bug report. This has been fixed. There may be a couple of additional bugs like this lurking about. I made the Tile Objects check their position at instantiation because I want to catch all weird bugs where a tile object does not have a position. This is what caught a different unrelated replace tile bug. This is likely an issue with your death_quote_info.txt script. There's an "if statement" you wrote somewhere in the script that the Engine is incapable of parsing. You can give me the debug.log.1 that has the issue + the death quote info script and I can take a closer look if that's not enough information for you to solve the issue.

I've not been able to find this bug -- I tried multiple merges of one item, and multiple merges of different items, both in the same session, and nothing broke on my end. If you can find a specific way to recreate the bug, please forward it to me -- or the error message, so I at least have an idea of where to start. These are now fixed in the latest update to the Engine (v0.9.3.10). The activated versions of Sol and Luna are the default, but the proc version are also still around in the status.xml if you wanted to use them instead as a basis. As far as I can tell, this should only happen when "cheat=1" is set in the config.ini file. If so, this is a feature, not a bug -- so it's easier to test with. Switch it to "cheat=0" in the main "Data/config.ini" when you ship the game. I have no idea where to start on this one either -- if there is no error message, then this will be very hard to debug. If you can send me the minimum data necessary to repeat the bug, I can take a look. It only happens with the one class type? If so, I would check the images associated with the class type -- maybe one of them is missing or buggy? But I really don't know... I'm glad you figured it out. The call item script is very elite tech for the Engine, and most of the things you could do with it would cause the game to crash unceremoniously, so I don't recommend using it if possible. However, the exp potion idea is a good case for using it. Try setting up an item like so: <item name="Exp Drink"> <id>Exp Drink</id> <spritetype>Consumable</spritetype> <spriteid>8</spriteid> <components>usable,uses,map_hit_color,call_item_script,booster</components> <uses>2</uses> <RNG>0</RNG> <value>300</value> <desc>A draught that gives 50 exp.</desc> <map_hit_color>96,144,232</map_hit_color> </item> The item must have the call_item_component component, booster component, and usable component to work. Then, create a file called "Data/callItemScript.txt" in your Data directory. # A sample call item script if;self.unit2.id == "Exp Drink" give_exp;{unit};50 end The first unit is the unit you are using the item on, and the unit2 is the item itself. This script is shared by all items that have the call_item_script component, so if you have more than one you must check the item id to determine what to do -- just like I did. Edit: Also, this will only work in the newest update to the Engine since I fixed a bug associated with the call item script component. There's a new build (v0.9.3.10) out new that fixes these bugs described above, along with a terrain_layer bug that someone else reported to me directly. Happy new year!

Thanks for the bug report! I never would have found this without the report! Saving the turnwheel's action log is very complicated, and it was trying to save the convoy as a unit when this occurred. There's a new upload of the Engine (v0.9.3.9) at the usual place which has this fixed, along with a couple of other small trade menu related issues. I also added a title screen particle flag to the constants.ini file. You can add the line title_particles=None to turn off the particles on the title screen, or set it to one of ["Smoke", "Fire", "Dark"] (the three weather systems that actually work on the title screen). For instance: title_particles=Fire to get Fire. "Smoke" is the default. "Dark" is kind of boring. "Fire" looks pretty neat though.

Try using the "gold" command instead. Because I added support for different parties in the Engine, there is no longer one single money constant. Now you use the "gold" command, which can be done like this: gold;1000 to give 1000 gold to the current party, or like this: gold;2000;Greil_Mercenaries to give 2000 gold to a specific party. I will have to update the wiki with this change. I'll also see about adding a no banner version, since there currently isn't one.

I'm assuming that you are running the base Python version of the Engine, not the Windows executable. It's not mentioned in the tutorial (which is my oversight -- sorry about that), but you will need to have PyQt5 (a GUI framework) installed to run the LevelEditor.py as a Python script. I don't know your method of installation of Python, so I can't necessarily recommend any specific way of installing PyQt5. I use Anaconda, so for me PyQt5 comes pre-installed, which is why it is my oversight.

Yes. The game can determine the number of levels at runtime now automatically. Lines 80 - 150 of the Code/configuration.py file contains a list of every constant currently accepted in the constants.ini by the Engine. Not yet. It's on the to do list. I'll probably add the flag as an option in the constants.ini file but its not high priority since there is a solution, even if the solution is kind of jank. I also forgot to mention that the trading menu had a usability upgrade thanks to djnemec of Gitlab. He upgraded the code so now the trading menu should behave more like the GBA games.

A new version of the Engine has been posted that fixes some bugs I've received reports about. The current version of the Engine is now v0.9.3.8. Thanks for your patience! These bugs should now be fixed. Thanks for the bug report! No temporary fix, just a weird corner case that popped up from the Python 2 -> 3 transition that I didn't nail down. It's the "Resist Status" status that is causing the problem. The next version of the Engine should have it fixed, along with the weird Howl/Gleipnir animation effect. Also these.

So there's an easy but somewhat hacky way right now. In the future I'll add a flag to turn off the particles, but for now: Navigate to Sprites/General/Weather/SmokeParticles.png and open it in GIMP or Photoshop. You can't use Paint for this because Paint won't preserve the transparency of the image. Then, just make the whole image completely transparent. Save and overwrite the image. Now, even though the particle effect is still on, you won't see any particles in the title screen.

Sure is! Here's an example: <item name="Phase Scroll"> <id>Phase_Scroll</id> <spritetype>Consumable</spritetype> <spriteid>0</spriteid> <components>usable,uses,beneficial,status</components> <uses>1</uses> <RNG>0</RNG> <value>2000</value> <desc>Grants Shimmer skill permanently.</desc> <status>Shimmer</status> </item> You could make the Shimmer skill have a time limit to only give Shimmer temporarily to the unit that uses the item. Thanks for the bug report! No temporary fix, just a weird corner case that popped up from the Python 2 -> 3 transition that I didn't nail down. It's the "Resist Status" status that is causing the problem. The next version of the Engine should have it fixed, along with the weird Howl/Gleipnir animation effect.