Jump to content

Tokei

Members
  • Posts

    661
  • Joined

  • Last visited

  • Days Won

    90

Tokei last won the day on April 20

Tokei had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Canada

Recent Profile Visitors

33485 profile views

Tokei's Achievements

  1. Unfortunately, that's not an str effect. You cannot edit the Evil Land because it's a 3D ground effect. It also happens to be hard coded in the client. You can change the texture (data\texture\effect\evilland\demonground.tga), but that won't do much. I presume bRO is the official server, correct? Then it's a bit weird that you're lagging. Evil Land isn't a fancy effect at all, it's a single texture shown on the floor: I looked at rAthena's db/source and it's using Layout 1 instead of 0, which makes the effect being sent 9 times instead of 1, which is wrong of course. That would normally be the reason for your lag, but since it's bRO... then it doesn't make sense. I made a basic gray looking evil land if you want to give it a shot nonetheless. demonground.tga demonground_alpha_translucent.tga Well, unless bRO still uses a very old client, then there's really nothing you can do...
  2. Fixed in 1.8.7.1. There was an issue with UV texture coordinates being all set to 0 on new tiles.
  3. Hmm, there is an approximation that can be done which will probably be good enough. The point 2 is misleading; what is seen in the UI is a blend of the background + layers. You can't separate them as it's already a final image, if that makes sense. But you could in theory extract a transparency value by using a black and white background version of the composite image. Then do some math magic and approximate the bgra values. I've added the option in 1.1.0, though it's a bit awkward to use (found in File > Export as PNG...).
  4. The purpose of encrypting the file table is to not be able to see the files anymore. While possible, retrieving the file listing would be... quite counter productive? Perhaps this feature is something you don't want to use as it doesn't seem to fit what your needs.
  5. There are two methods for doing that: Once you have the current frame, click on: Then add the name of the file, like "test.wav". The file should be in data\wav\test.wav You can add a bunch of sound names by editing the list instead: Then select the sound for the frame from the list. If the sound doesn't play when testing the sprite, then it's just because it wasn't found in the resources. That's not really important, but you can add more resources from File > Settings > Sound:
  6. Hmm, you'd definitely want to add more checks on this, but here: - script Mob Helper -1,{ OnNPCKillEvent: // Fixed improper usage of rand for "chance" if (500 < rand(10000)) end; if (mkTimed && gettimetick(2) <= mkTimed) end; // Don't use "set" anymore, that's way outdated. // Using getmonsterinfo isn't a bad idea, but it's somewhat useless/broken now. You'd have to expand on it in the source to make it useful. getunitdata(killedgid, .@mobdata); // There's no reason to use player variables in this case, the variable has no purpose outside of the NPC block code. Therefore it should be a NPC variable. .@MobMode = .@mobdata[UMOB_MODE]; .@MobClass = .@mobdata[UMOB_CLASS]; if (!(.@MobMode & MD_CANMOVE)) end; if (!(.@MobMode & MD_CANATTACK)) end; // MD_BOSS/32 isn't a thing anymore either, so that code won't work. if (.@MobClass == CLASS_BOSS) end; // Too much wrong with these lines. //set @WoE[0],1288|1285|1830|1949|1950|1286|1287|1899|1829; //WoE IDs //for(set @n,0; @n < getarraysize(@WoE); set @n,@n+1){ if(@WoE[@n] == killedrid){ end; } } //WoE // You probably meant to use "setarray", and you also probably to use commas instead of separators: setarray @woe, 1288, 1285, ..; // Either way, that's inefficient considering this code runs on all killed monsters. Honestly I'd do the whole thing via the source instead since running a script everytime you kill a monster is overkill. Anyhow, use a dictionary seach: if (.badMob[killedrid]) end; .@nTime = (300 + rand(0, 120)) - getmonsterinfo(killedrid, MOB_LV); // The main reason why your script didn't work: "summon" uses miliseconds, not seconds. .@nTime *= 1000; // s to ms summon "Ajudante " + getmonsterinfo(killedrid, MOB_NAME), killedrid, .@nTime; mkTimed = gettimetick(2) + .@nTime + rand(0, 60); message strcharinfo(0), "[" + getmonsterinfo(killedrid, MOB_NAME) + "] Hello " + strcharinfo(0) + " I will help you for a few minutes!"; end; OnInit: // Define bad mobs here .badMob[1288] = 1; .badMob[1285] = 1; .badMob[1830] = 1; .badMob[1949] = 1; .badMob[1950] = 1; .badMob[1286] = 1; .badMob[1287] = 1; .badMob[1899] = 1; .badMob[1829] = 1; end; }
  7. Heya, The HP/SP bars are data\texture\À¯ÀúÀÎÅÍÆäÀ̽º\basic_interface\gzeblue_left.bmp gzeblue_mid gzeblue_right And the AP bar is gzered_left / gzered_mid / gzered_right.
  8. I fixed the hyperlink color, along with the brush selection and the search brush (same download link as before). As for the 4 GB limit, that's a structural limit with GRF files and there's nothing that can be done about it unless Gravity updates their file format. For more context, the file table offset is defined as an unsigned integer and the entries within the file table are also defined as unsigned integers. Four bytes of data cannot go beyond 4294967295; if they do, they'll wrap back to 0 and starts corrupting data in your GRF. I'm afraid this is technically impossible. If your GRF reached 5+ GB in size, then it means you've lost data within your GRF without you knowing about it. As I mentioned above, if you go past 4 GB with your file offsets, the data wraps back to 0. The fact that your GRF loads means that the file table offset was indeed beyond the limit and is probably written right in the middle of your GRF instead of at the end of it. The file table has overwritten some of your files within your GRF and some indexes are linking to invalid data (and not by a small amount, about 1/5th of your GRF is unreadable). When that happens, the client won't be able to decompress the data as it won't be a valid zlib entry, and it will attempt to read from the next GRF listed.
  9. Updated to 1.8.6.6, this update mostly targets the map rendering: Added/fixed the RSM2 to RSM1 option when right-clicking a RSM2 file. The "anim" option will keep the rotation key frames, but it is not a perfect conversion; the scale/texture/offset key frames cannot be converted. The "flat" option will remove any kind of animation but will always be a perfect match with the original. I know this feature isn't that useful anymore since most clients support RSM2 files just fine, but I still hear people wanting to downgrade RSM2 files. You'll need to set the scale to (-1,1,1) in BrowEdit if you want to keep original model direction. Added the "Downgrade" option when right-clicking a RSW file. This will set the version of the RSW to 0x201 and GND to 0x107. All RSM2 files inside the RSW file will be converted to RSM1 and added to your GRF. The RSM2 models are also placed in their correct positions after conversion. Fixed the FPS counter. Added a "minimap" option to create minimaps: Added a face culling option to reflect the client's behavior more accurately. Added a copy/paste feature meant for BrowEdit 3 by using shift-left-click: Please keep your drama/trolling out of this thread, thank you. This forum is primarily dedicated towards developers, not players. I'd refer you to RMS, reddit or your own server forum instead.
  10. They shouldn't be encrypted, no. Unless Gravity revamped the rrf format, this tool should still work. You don't have to handle newer packets unless you want some information from them. For example, if there is a newer packet for displaying NPC messages, then they would simply not show up in the tool anymore until you added a parsing method for it. Anyway, you'd have to share your replay with me in private to look into what's happening. It's too vague as it is.
  11. You forgot the semi-colon after the first line: ALTER TABLE `char` ADD `achievement_points` INT to ALTER TABLE `char` ADD `achievement_points` INT; Other than that, it ran fine for me. (Also you may want to use a proper SQL editor like HeidiSQL instead of phpmyadmin...)
  12. Well that's a bit of a vague error, but usually that means either one of these two: You do not have the .net 3.5 and .net 4.0 properly installed. Or you have conflicting dlls in your folder where GRF Editor is running from (doesn't seem likely though?). So for starter, I'd recommend reinstalling .net 4.0, then .net 3.5, and go from there I suppose.
  13. That's a different issue though; rand(0, 0) doesn't make sense. You could edit the BUILDIN function to ignore such a case, since one could argue that rand(0, 0) should return 0. In the original script posted by InfectedX, it was impossible to have such a scenario so the error didn't make sense. That's why I suggested him to use an entirely different method instead.
  14. Hmm, I'm not entirely sure. My first guess would be the lack of a 1-pixel border around the image. But perhaps there's something else going on with the image itself (maybe it's a transparency image?), but I'd need to have a look at the act/spr files first.
  15. Ah no, the script I posted isn't meant to just copy paste and run. It's just if you have doubts with a mechanic or something; it's way too custom to be used and I'm too lazy to convert it to rAthena's standards.
×
×
  • Create New...