Eliwan

Check terrain costs. Don't iterate through each spot that is normally available to move through, but instead check per tile what terrain is beneath and calculate the cost of movement through that tile.This code snippet is from KK20's AWXP Engine and I think it's helpful to have something to directly reference: #----------------------------------------------------------------------------- # * Calc_Pos - Find what tiles to highlight to determine range #----------------------------------------------------------------------------- # unit = Class Unit # range_max = maximum range that can be achieved # range_min = minimum " " # type = what tiles are we going to work on? # >> "move" - Move range # >> "attack" - Attack range # >> "direct" - 4 tiles around the unit # >> "vision" - Unit's vision range # x , y = If wanting to get tiles from a specific spot and not a unit's x/y #----------------------------------------------------------------------------- def calc_pos(unit, type = "all", x = nil, y = nil) # Stores all the x-y coordinates of possible spots positions = [] if type == "move" or (type == "attack" and unit.max_range == 1) # Sets maximum move range based on remaining fuel range_max = (unit.fuel < unit.move ? unit.fuel : unit.move ) #In Advance Wars units have a Fuel amount that dictates their maximum move #For your case you'd want to just have the Move of the unit (which would be probably mostly dependant on their class) case range_max when 0 # Adds current actor position since it can only move 0 spaces # Actor = unit positions.push([unit.x, unit.y]) # If unit can actually move some spaces... else # setup the values of the following arrays positions = [[unit.x, unit.y]] #-> Stores [x,y] of every space that unit can move onto route = [[]] #-> Defines the directions to get to position. Elements work in conjunction with position's. cost = [0] #-> Movement cost to get to position. Work in conjunction with positions and route more_step = [0] #-> Stores index values so that it can check which positions to process possible additional spaces. for i in more_step x = positions[i][0] # X-coord of space y = positions[i][1] # Y-coord of space c = cost[i] # Space's cost (e.g. it takes 3 move points to get here) #Begin finding all possible paths. Starts with DOWN if unit.passable?(x, y+1) #Can the tile below be walked through #For other directions, instead of adding 1 to Y, #you'd subtract 1 from Y for up; (x, y-1) #subtract 1 from X to get left; (x-1,y) #add one to X to get right. (x+1, y) tt = (unit.army.officer.perfect_movement ? 1 : ($game_map.get_tile(x,y+1).move_cost(unit))) #get move cost of tile that is below tt += unit.army.mcosts #Powers that increase move costs across all terrains use this to increase it if c+tt <= range_max #if current route cost <= move_range if positions.include?([x, y + 1]) #is this spot already found? index = positions.index([x, y + 1]) #find element of this spot if cost[index] > c+tt #is current route found less costly than original? route[index].clear #reset existing route route[index] = route[i] + [2] #set new route cost[index] = c+tt #replace cost table for pos if c+tt < range_max #is there another spot we can reach because of this reduced cost? more_step.push(route.index(route[i] + [2])) end elsif cost[index] == c+tt #is new route just as costly? if clean_route(route[i]+[2], route[index]) #does the new-found route have less turns than current route? route[index].clear #reset existing route route[index] = route[i] + [2] #set new route end end else #this spot is newly founded...let's add it positions.push([x, y + 1]) #add position to positions array route.push(route[i] + [2]) #add route for position cost.push(c+tt) #add cost required for position if c+tt < range_max #enough move spaces left to find more spots? more_step.push(route.index(route[i] + [2])) #push more step for position end end end end #The process is much the same as above for the other 3 directions

Lying does not become a good person holy jeebus stop this madness

Making a single thread is probably for the best :v The hair colors are messed up as what should be the lightest shade is the darkest. It works for the bangs, but not for the top nor back of the head (nor, even, for the left side of the canvas / their right). The near shoulder looks still too much like the skin that it used to be (unless it's supposed to be some skin tight cloth or his skin is gray, though his face doesn't show this trait very well at all), I would recommend copying some cloth folds onto it from elsewhere or freehanding some of your own. The mark over the eye I can't tell what it is supposed to be-- if it is a scar then it is too absent in certain places, if it is a henna it doesn't read well as one due to its faintness (which may have been the point, though, so this could be ignored). Regading the actual color choice, the inside color of the hair is actually darker than the outline, as is the darkest color on the exposed arm and the reds on that same spot. This creates a conflict with the outline itself, as the outline is supposed to be the "black" color for the character design-- everything should be brighter than it, unless to portray some extraordinary darkness (e.g. a black hole maybe). (It also looks really heavily like Raven because of how little facial change there was, but the components do work together)

Yes via Circles' NMM2CSV and a CSV editor of your choice e.g. libreoffice + if you want new graphics with image editor of your choice + finally EA to insert it all or you could use Nightmare and GBAGE instead of CSV / EA

No. Whoever said that is blatantly lying; as FEXP and FEXNA are separate engines from actual GBA FE. While they "work the same" in that they'd have the end thing be the same / similar, you'd have different UI designs and options available with each as well as having zero code compatibility (GBA FE is assembled C, FEXP is Ruby, I don't know what FEXNA is). As for a real "how"; it depends on what the skill(s) affects. If it just changes the damage/hit/crit values for an entire battle, then it's not too bad. But something like Luna, which affects only one hit in a battle, require making the battle system recalculate damage on each hit; something like Sol requires figuring out how to increment the attacker's HP (and afaik nobody knows how to do this? not sure off the top of my head however).

Yes. "Archived" refers to any form of compression (zip, rar, 7zip, etc. see here for more if you care).

The unheadered, unpatched ROM should be 4 MB, headered unpatched 4.0004 or more MB- or As far as checking the size goes, just clicking the file or right-clicking it and selecting properties (or "more information" or something of such nature) should tell you immediately specifics of how much space the file is. The last time I spoke with somebody with this kind of issue, they hadn't unpacked the archived ROM :V Checking my own files, a zipped vanilla unheadered (4,194,816 bytes) FE4 is 2.8 MB, so I'd assume that this is the issue... for the moment at the very least.

Not easy and very hacky with Nightmare, however- Nightmare is a Hex Editor at its core, just labelled nicely according to the modules. What you need is a proper Hex Editor (google, there're plenty of great free ones such as HxD) and some way to hold your manipulations as well (e.g. notepad). If you want to change the class of all your units to monsters, then repointing every single one of the promotion items to promote the same list of lasses would be fine. Promotion Items point to a 00 terminated list of bytes in the rom. Each of the bytes corresponds to a class that that item is able to promote. For example, the Hero Crest's "promotion pointer" is 088ADF57. This means that it points to 008ADF57 in the actual hex dump of the ROM, which (in HxD) is: (The highlighted portion shows us the classes the item promotes) Non-image replication: Offset(h) [00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F] 008ADF40 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 3B 7C 008ADF40 7D 51 00 3D 3E 47 00 0F 10 13 14 3F 7E 00 05 06 008ADF40 09 0A 37 00 19 1A 00 48 1F 20 00 45 4A 25 26 44 008ADF40 2D 2E 4B 7F 00 00 0F 10 13 14 3F 42 41 05 06 09 We care about 008ADF57 ~ 008ADF66 in this instance, which contains "0F 10 13 14 3F 7E 00 05 06 09 0A 37 00 19 1A 00", as the list of classes this item promotes.As I've actually done this exact thing many times I happen to have the list already prepared, but what it is is the list of unpromoted monster class IDs, which was compiled using Nightmare to check. 52 54 56 58 5B 5D 5F 63 00I believe that the monster classes are already pointed to promote to their elite-r variants, but just in case, check in the Class editors to make sure that the Tarvos promotes to the Maelduin, the Bonewalker (Sword/Lance) promotes to the Wight (Sword/Lance), etc. because otherwise this doesn't work.If you want less intensive edited thing, you can repoint every single promotion item's promotion pointer to point to the same space in ROM; so that you don't have to edit the drops. (Or I suppose you could customize each promotion item to promote a given monster class group) Regardless, the method is the same. You open the ROM in HxD and navigate to some free space or the end of the rom. I personally recommend starting at 00B2A610 if you don't want to expand the rom size-- this means pointing every promotion item to this space. Pointers need to point to (ROM address + 0800000), so 08B2A610 is the pointer you'll want in this instance. Then, after making all of those edits in nightmare, save the ROM, quit Nightmare, and open the ROM in HxD. Goto offset (CTRL+G in windwos) 00B2A610, and paste-ovewrite (CTRL+B in windows) in the class list above, reproduced here: 52 54 56 58 5B 5D 5F 63 00 DO NOT PASTE INSERT (ctrl + v). IT WILL BREAK THE ROM.Then Save the ROM, close HxD, and play it. Note that this only edits the promotions; so you'd need to do something else if you wanted to edit the classes of the characters (codebreaker codes being the easiest), though I believe that Nightmare can handle that component.

29 color, 5 legendary weapon wielding, Honoka Einae Tai'Sari says hi

alusq is amazing they don't needa link their spritans (it's here for the record)

Yes, it is. Circles has been doing other things primarily from what I can tell, but always with clear support for going back to this. (And they continually talk about this and I'm pretty sure they're not bringing it up in self-shame at having to quit :V)

I feel like I've made a mistake somewhere....

C30 is the shockwave used by both brigand and pirate: (the first one is confirmation that it is in fact C30) Close to that are... mmm.. C31 (which I know the pirate also uses) C32 (huh, seems like it's a copy..?) The only other command seems to be C4E...

The large kickback-behind-the-user command is used by both the Pirate and the Brigand in their animations. The Fighter on the other hand does not use any graphical codes :V I'm actually unaware of a small gray cloud? Though I do know that some of the command codes actually change color of their clouds based on the tile that the user is on (for example the pirate/brigand cloud is blue when they're on ocean/sea tiles but brown when on grass/mountain/peak tiles).

Try the spriting subforum :V The hero's critical and return shockwaves are part of the battle animation and are not command codes. :C As far as specific crit, The blur to jump is far too large for how snappy and existent it is. The majority of the large-distance quick blurs actually tend to also have the character become much less noticible, particularly observable in the swordmaster's animations (and by extension, bwdyeti's astra animation which for the most part follows the same principles). The arm that doesn't hold the axe probably could stand to move some with the throw, and the legs look funny in the throwing process as well (not just because of animation speed).

I. Are you adorable? L. Are you awesome? O. Are you amazing? V. Are you wonderful? E. Are you precious? Y. Can you eat three meals each day? O. Are you beloved? U. Are you going to dare say no to LOVE?

yes we are us

No$GBA 2.8d, THIS devkitpro.

Only if we can also make a list of: Coders/Writers/Scenario Designers/etc that are available to take requests*. *processes that take hours and hours and hours and hours of life to finish. That are also things that would get edited, the minds of people changing for one reason or another; and therefore needing MORE return work b the original builder (or somebody else, which could cause other issues). So artists should devote hours and hours and hours of time when the other party didn't necessarily? Like, this is a two way street here. People want to have their art assets be good. But the people who make those good art assets also want their things to bud into existence, or to be able to live off of their asset creation. The only real "solution" is to become a master of all trades; which is obviously unfeasible... but it's the only one that makes a lot of sense here. It's a problem that's been discussed over and over and the answer is always the same and the thread follows the same pattern every single time. "Requests where" >"art is hard and artists have other things that they actively want to work on" Absolutely! Most people would be overworked if they took requests at a whim; most people don't want to divert from their main workflow which consumes all their time for such a craft to work on somebody else's project that they aren't also interested in. So in the act of taking a single request, they're overworked. Problem solved; nobody has time for requests because nobody allots time for requests, which they don't do because they're effectively doing auto-requests (as in self-requests).

0, on subject. Linux is an Operating System alone by definitions of, uh, common sense and also wikipedia. 1, on subject. I know from personal experience with IT/CS/engineers that nobody cares about the difference between the two. 2, on subject. You admit that Colorz's statement is accurate, because in the user still is harnessing Linux whether or not that's their actual OS (which it in fact is). 3, off subject. Why does your post not conform to width restraints of the page ("word wrap")? It trails off of the displayed area for seemingly no reason. so WHYYYYYYYY

Try anyway! The only way to get better is to make your most earnest attempt. ~'w'~ (and then more people will probably be relatively willing to help you out, too.)

Because Lenh is human and copy pasted / typo'd.

Given the angle, the lips should be actually going off the edge of the face that we can see; and the back of the head should have more volume to make room for the skull's shape.

Can confirm Eirika's map sprite crashes the game when patched to a vanilla FE8 ROM