Chokboyz

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


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

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


Ctrl is already used to multilook, so that's probably a bad idea ...

Chokboyz

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



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


The old 50 max node limit is gone, if i'm not mistaken ...

Thanks,
Chokboyz

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

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)


Yes, it does.

Chokboyz

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

I don't know of any, apart from the in the menus (open file, etc).


Enter Debug mode (Shift-D) and press the '/' key (on the keypad).


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

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


Agreed
If it gains the community approval, this wouldn't take long to implement ...

Thanks,
Chokboyz

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

Yes, probably a mac to windows leftover ...


I guess we can bring back the "holding Ctrl allows multiple looks" behavior ...
Edit : Done.


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


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.


No, it's not

Chokboyz

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


Done.


As Ishad Nha said, nope, they're not (in fact, only the 10 first events are even used).

Chokboyz

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

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

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

Yup, another unnecessary large array


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

Yes i did ...

Chokboyz

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


I confirm this (swap also doesn't work). I'll try to take a look into it this week.


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

 

Thanks, that was a good way to start the investigation.

 

Chokboyz

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


By the way, when you say the PSD[0][0] "resets", i assume it takes the value 0 ?


Did you find anything useful ?

Chokboyz

At what moment/after what action exactly does it seems to reset ?
I don't think i've fixed this (0,0) oddity ...

Chokboyz

Ok, i've replaced it with play_sound().


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

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

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.

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