Chokboyz

Originally Posted By: Celtic Minstrel Home, End, PageUp, and PageDown would work... except that laptops don't typically have those, either. Unbelievable ... Provided that laptops usually don't have proper mouse (read a mouse pad), i assumed those keys were always implemented so that you can move around quickly ... My bad then Originally Posted By: Celtic Minstrel What about moving diagonally if two non-opposing arrow keys are pressed simultaneously? For example, hold left and up together to move NW. That would makes sense (the most actually), but the problem of overlapping with the four default cardinal direction arise (i.e the program may register the keys as "go left then up" instead of "go North-West" (and would, in general, be quite clumsy) ...). It is a possible global (i assume all computers have, at least, arrow keys ...) solution, though Chokboyz

Originally Posted By: Fett0001 Us laptop users typically don't have a numkeypad, and this makes it difficult to move diagonally. It would be nice if there were a way to press up and left and go northwest, etc. Nowadays laptop have integrated numkeypad or virtual numkeypad (usually accessed via the Fn key). Plus the mouse/pad can be used to be move the party ... Don't shout yet, i'm just joking More seriously, we can assign the Home, End, Page Up/Down key to diagonal movement (these are usually used, since they match the numkey ones) ... Originally Posted By: Ishad Nha Ctrl + Arrow key would be possible Ctrl is already used to multilook, so that's probably a bad idea ... Chokboyz

Originally Posted By: Thuryl The original behaviour was that life-saving items would in fact save the party from Kill Party nodes. So i've not forgotten to put the check back : it wasn't here in the first place ... Which is a bit strange since there is a check that prevents luck from interfering if the party is killed via the Kill Party node Originally Posted By: Thuryl This has been a pain for designers for a very long time. Originally Posted By: Cryolemon It makes sense to have an option in the node (as an extra value say) to force kill, or allow life saving items to work. What would the default be for compatibility? I would propose keeping 0 (dead), 1 (dust) and 2 (stone) for backwards compatibility and use extra1b value 2 to force kill (0 is ressurect and 1 is kill). As always, it's open to discussion Originally Posted By: Thuryl Keep in mind that a chain of more than 50 special nodes is treated as an infinite loop and automatically terminated. The old 50 max node limit is gone, if i'm not mistaken ... Thanks, Chokboyz

Originally Posted By: Mistb0rn Is there any way to use a node to kill the party without them being able to block it with a life-saving item? Sorry for being late here ... In fact, the node "kill party" is supposed to ignore life saving items, but it seems i've forgot to put the check back when fixing the kill function. I've, of course, reverted it to the original behavior, but we can implement a kill node that allows choosing to force kill or not, if it seems revelant Chokboyz

Originally Posted By: Ishad Nha 133 was my work presumably, committed by W Dueck on my behalf. Yet my original code seems to have had none of these errors, file corruption in transit? More likely an old/different version of the code was comitted. All the features advertised on the commit page are in though. (note that no crashes with Mac scenarios or last outdoor strings was experienced though) Originally Posted By: Ishad Nha Anyway there is a revision 134 which hopefully fixed the errors. Yes, it does. Chokboyz

Originally Posted By: Ishad Nha That is the Mac version surely, none of those problems have been seen on my Windows version of the Editor. No, it's indeed the Windows version, especially this commit : http://code.google.com/p/openexile/source/detail?r=133 . (get it and try it, those bugs are real) It may have been commited not up-to-date though. Chokboyz

Originally Posted By: Ahbleza Is there a list of all the 'Hot-Keys', 'ctrl + char', and 'alt + char' keys; I don't know of any, apart from the in the menus (open file, etc). Originally Posted By: Ahbleza including what you can do in the 'debug' mode? Enter Debug mode (Shift-D) and press the '/' key (on the keypad). Originally Posted By: Ahbleza The idea of 'mult-look' has to be a lot easier than moving around a room to 'look' at every object individually, eh? The right mouse button already provides an alternative for that (don't worry, the Ctrl key multilook behavior has been implemented nonetheless) Hope it helps, Chokboyz

Thanks for the support ! Concerning the recent Scenario Editor commit, i've tweaked/fixed several things : Fixed the Ctrl-P report reprint command was blackening the text screen. Tweaked some menu hiding (Town concise report and Town Dialogue should be accessible now) Fixed the delete button wasn't working for the town rectangles (and the Bottom Right part is correctly changed to "Not placed yet" now). Get rid of the "black void" bar that may appears in the left of the screen in higher resolution (did something similar with the game some times ago, but forget the Editor ) I've not been able to experience those crash you mentioned when doing a Scenario Object report on a Mac scenario or fiddling with the 40 last outdoor strings ... That doesn't means they aren't there, though Chokboyz

Originally Posted By: Celtic Minstrel On second thoughts, I have been neglecting the fact that Mac has one more modifier key than Windows. And it's quite natural to map the command key on Mac to the control key on Windows. So, if you want to keep Ctrl-click as multi-look, then on the Mac we'll make command-click be multi-look. Maybe it already is, I dunno. Seems like a good idea to me Note that Windows also has a command key (probably stol... err inspired by the Mac one) but is quite a pain to fiddle with , so i'd would suggest doing as you said : holding Ctrl for multilook on Windows, holding Command for multilook on Mac (given the code, #ifdef would do the trick). Originally Posted By: Celtic Minstrel And then alt-click could be something else, such as "use space"... hey, that's a good idea! Agreed If it gains the community approval, this wouldn't take long to implement ... Thanks, Chokboyz

Originally Posted By: Celtic Minstrel ...wait, what? We should not have Ctrl-click and right-click have a different effect. Either change right-click to trigger multi-look, or change ctrl-click to trigger either normal look or nothing, and then perhaps alt-click can trigger multi-look. Hmm ? Right-click has always been "look the space the cursor is on" and Ctrl-Click was "keep on looking until i release the Ctrl key, while in looking mode" before it was broken somewhere between Exile 2, Exile 3 and BoE. If any of these should be changed, then i'll make Ctrl-Click does nothing (which it already did, except when in looking mode). Chokboyz

Originally Posted By: Fett0001 Most people who do multilook could use the right click. It might be legacy from the old macs without two mouse buttons. Yes, probably a mac to windows leftover ... Originally Posted By: Celtic Minstrel This behaviour should be brought back if it doesn't already occur. I guess we can bring back the "holding Ctrl allows multiple looks" behavior ... Edit : Done. Originally Posted By: Celtic Minstrel Note that on the Mac, Ctrl+click is identical to right-click, so it's probably best to do the same on Windows. Are you suggesting we double the right-click with Ctrl+click ? If so, I understand that some Mac don't have a second mouse button, but that seems a bit redundant for other platforms ... Originally Posted By: Ishad Nha Using the find in all files function, searching for Ctrl: it seems only to occur for multiple looking. In practice it does allow multiple looking, this function is working properly in Windows. I've found the same as you, Ctrl is only used for multiple looking in the Windows code. I disagree, though, it is not working properly : for example pressing the Key Down button counts as if the Ctrl key was pressed. Edit: Nevermind, it's fixed. Originally Posted By: Ishad Nha it is not a really big bug No, it's not Chokboyz

Originally Posted By: Celtic Minstrel So, you could change that to check < 100. Then, it must be changed in the editor (i'd suggest to replace the 11 events button (0-10 + none) by a text-field), the code already supporting up to 100 events (minus some check adjustment in one function). Originally Posted By: Celtic Minstrel And this could be changed to initialize all 100 of them. Done. Originally Posted By: Celtic Minstrel ...unless of course the others are used anywhere else in the game. As Ishad Nha said, nope, they're not (in fact, only the 10 first events are even used). Chokboyz

Originally Posted By: Fett0001 Back in Exile 2, it was used for extra looks. Thanks ... Is there a point in keeping this ? (it is actually non-working (and never worked in BoE) and causing the down-arrow bug) If there's no objections, i'll clean it up Chokboyz

Originally Posted By: Fett0001 Thanks for the quick responses. ^__^ You're welcome. By the way, does anybody knows if the Ctrl key is used at all in Windows BoE (apart from the Ctrl+X shortcuts) ? It seems there's a check for it but the only part it is actually used is a (faulty) check in the look mode ... (my guess is that it was supposed to allow multiple looks in a row ...) Chokboyz

Originally Posted By: Fett0001 Relating to searching containers: If I use the "l" shortcut to look and the down arrow key to pick the direction to search a container, the look mode doesn't end. Confirmed. The bug is already present in the legacy version of Blades of Exile. The funny part is that the only key that does so is the down arrow, not even the down keypad arrow. I'm looking into this. Chokboyz

Originally Posted By: Celtic Minstrel So, there's actually space for 100 events? Yup, another unnecessary large array Originally Posted By: Celtic Minstre The next step is to check the event-handling nodes and the area of the code where NPC key events and town key events are checked, and verify that there is no check for < 20. The event-handling nodes checks the key_times[monster_start.time_code] index (monster_start.time_code is between 0 and 9), so no problem here. During the initialization of the game, the 20 first values of key_times are initialized (to 30000) though. Hope it helps, Chokboyz

Originally Posted By: Celtic Minstrel So, you were able to access an item that had been placed on the non-container space and marked as contained, once the space was transformed to a container? Yes i did ... Chokboyz

Originally Posted By: Ishad Nha In the meantime don't use (0,0) for anything important. You still have that potential problem with the dialog nodes for good measure. What problem ? The fact that A,B,C and D are 0 by default ? Don't worry, the only way to change SDF using A,B, C or D while talking is to either use the Set Flag to 1 or Buy response, Change flag nodes (and forgetting to assign A, B or C for those is hardly a bug ! ). Originally Posted By: Mistb0rn I set the 'transform to' of the terrain I wanted to change to the proper number for the box, and it still changed to cave. I confirm this (swap also doesn't work). I'll try to take a look into it this week. Originally Posted By: Mistb0rn I tried putting a 'contained in something' item in the non-container terrain, but then even after I change the terrain to the box it still isn't accessible. I just tried Celtic Minstrel's method and it worked fine (changed/swapped/tranformed a terrain to the chest on grey blocks, terrain number 194). What terrain did you changed to ? (tested "transform terrain" while talking too) Chokboyz

Ok, i've found what was causing the SDF[0][0] problem (or one of the cause but i've not encountered any "reset" since) ... The problem was that the "null monster" start structure template was giving the monster a default (0,0) life flag (even when it is correctly set to (-1,-1) in the editor ). This "null" template is used when creating some monsters : wandering (outdoor or in town) and summoning ones. So, their life flag being (0,0), everytime you killed such a monster, the SDF[0][0] was reset to 1 (i.e monster's dead). The fix will be included in the next commit (here is the fixed null_start_type = {0,0,location(80,80),1,0,0,0,-1,-1,0,0, 0,-1,-1,-1} if anyone ever needs it). Originally Posted By: Mistb0rn As far as I can tell, it occurs at some point during an outdoor wandering monster encounter. Thanks, that was a good way to start the investigation. Chokboyz

Originally Posted By: Ishad Nha I just checked "stuff_done" in Find in Files, most of the SDFs are straight absolute numbers. But there a few with algebraic values, I will look at these, especially if their value is being set. Edit: Checking Find in Files for "PSD" I found quite a few flags where X was less than 299. There were a few algebraic ones too. Edit: Does the SDF (0,0) problem affect all scenarios or only some of them? Default value of Extra Values A,B,C,D for all dialog node types happens to be 0. So it is possible to affect flag (0,0) inadvertently, if the designer forgets to enter the intended values of A,B,C,D. Yup, that's one possibility ... I've already investigates the PSD/party.stuff_done accesses and apart from talking or node setting, the PSD[0][0] can also be changed by a monster life flag. So far, i've not been able to "reset" the PSD[0][0]. I'll give the debugger a try, but last time i used DevCPP's it was really funky (breakpoints ignored, watched variables not updated or locking the editor when manually asked to update, etc ) ... Originally Posted By: Mistb0rn Is there any problem with using flag 0,0? It seems to inexplicably reset for no apparent reason. By the way, when you say the PSD[0][0] "resets", i assume it takes the value 0 ? Originally Posted By: Mistb0rn I can try some additional tests and see if I can find out more. Did you find anything useful ? Chokboyz

Originally Posted By: Mistb0rn Is there any problem with using flag 0,0? It seems to inexplicably reset for no apparent reason. At what moment/after what action exactly does it seems to reset ? I don't think i've fixed this (0,0) oddity ... Chokboyz

Originally Posted By: Celtic Minstrel I don't believe force_play_sound is needed - didn't it just forward to play_sound? Possibly after doing one extra thing. Ok, i've replaced it with play_sound(). Originally Posted By: Celtic Minstrel It's possible that these errors are a result of my messing around with the Windows code, attempting to merge the two codes, but I can't actually remember if I committed that, so... *shrugs* Are you speaking of that commit : http://code.google.com/p/openexile/source/detail?r=121 ? If so, don't worry, i've finished the cleaning of the code which now compiles (and uses the tools/classes folders and the files/changes you introduced). Chokboyz

Originally Posted By: The Almighty Doer of Stuff Something still just doesn't seem right about someone with no stats and crappy lockpicks being able to pick any non-magical lock with ease. Is this going to be addressed? Town difficulty setting has been implemented (in Windows version, see above) for new format scenarios (e.g now lockpick level 10 on a town with difficulty 10 don't give any bonus ... You'd better invest in Lockpicking and Dexterity if you plan on lockpicking a door in a town with high difficulty and a crappy lockpick) and the "reversed difficulty scale" has been fixed. Chokboyz

Originally Posted By: Ishad Nha [...] The tools and classes folder have their files listed in the Dev file as occurring in the main Blades of Exile folder, by contrast the Header files list these same files as occurring in their actual locations. As far as i can tell it's a consequence of the code "alignement" to the Mac standard (for example CONSTS.h doesn't exists anymore and has been replaced by a consts.h file that use only enumerators). Another consequence is that, even after correcting the paths to consts.h and such, the game won't compile because some constants in the code must be "updated" to use the new enumerator structure. That and the fact that others constants (NUM_OF_PC for example) has just been deleted. I'll try to find some time to sort all of that out, but i don't have much time to spend on it ... Chokboyz Edit : is there any reason why all the different modes (COMBAT, TOWN, etc) have been deleted ? (i'm putting it back using enumerator) Idem for traps types. Also what happened to force_play_sound ? (using plain play_sound instead) Edit 2 : Okay, things are a bit cleaned up (includes are in such a mess though ...) but the linker throws multiples definitions errors (snds and sound_handle) ... Edit 3: Finally, it compiles and run fine. After further testing (read probably this week-end), i'll commit the changes. Technically, I had to externalize several variables, correct double definitions (now using those soundtool, mathutil, etc files), write two more enumerations (eTrapType and eMode) and correct the code (e.g STATUS_BLESS => STATUS_BLESS_CURSE) in many places.

Originally Posted By: Ishad Nha Has anyone ever actually seen a 1x1 Area Rectangle situated only on square 0,0? Yup, in every legacy scenario's outdoor section that is large enough (Redemption's first area comes to my mind right now ...). The loaded outdoor shifting procedure makes it possible to have such a rectangle. Chokboyz