51 réponses à ce sujet

[E.C.Patterson]

I tried the demo mod and this is pure awesomeness. The fog of war works great and I love the different shades and shapes of the tiles as you uncover the area. Fantastic work. However, to make this perfect IMO :

-Fog of war should be on the minimap too as there isn't much point in my mind in being unable to see the whole area on the pop-up map while seeing it all on the usually permanent one.
-The mini-map is now huge! Is it possible to fix?
-The radius of the uncovered area could be bigger, or at least the space cleared directly in front of the character as he sees ahead: presently it practically only clears the squares directly "above" him in front.

Also one question: How does it work when you switch control to other characters? Is the map status the same for all party members?

Modifié par E.C.Patterson, 05 février 2011 - 02:58 .

[kevL]

hi E.C.
going to bounce off some of your questions here (not implying anyone thinks the same way)

E.C.Patterson wrote...

I tried the demo mod and this is pure awesomeness. The fog of war works great and I love the different shades and shapes of the tiles as you uncover the area. Fantastic work.

agreed. really like the shaping of the overlay

-Fog of war should be on the minimap too as there isn't much point in my mind in being unable to see the whole area on the pop-up map while seeing it all on the usually permanent one.

I don't mind it not on the mini-map; in fact I'll probably look into disabling the zoomed-out view(s) to restrict its vision. *shrug

-The mini-map is now huge! Is it possible to fix?

same here, but i have to jog things around 'cause I'm using a pseudo-custom background.tga, anyway. *shrug

-The radius of the uncovered area could be bigger, or at least the space cleared directly in front of the character as he sees ahead: presently it practically only clears the squares directly "above" him in front.

@Lance,
that's my question too. Is there a single variable, or two, that determines how much area gets uncovered each tick? As E.C., I'd like to increase it ever so slightly. More clearage in front of the character would be nice, but I'm imagining is too difficult ..

was looking through 'gui_examine' and understand where you got your appellation (referenced earlier) from; felt like I was reading the Iliad: didn't understand 80% but it sounds cool

So, is it possible to easily adjust how much space gets cleared, by say adding +1 to a variable or constant? (If it requires adjusting values in 'areamap.xml' - *pfft* it's just fine as it is!) my first guess is "float fPixels"

Also one question: How does it work when you switch control to other characters? Is the map status the same for all party members?

I just tested with a Companion: works the same as PC on my system.

[Lance Botelle]

E.C.Patterson wrote...

I tried the demo mod and this is pure awesomeness. The fog of war works great and I love the different shades and shapes of the tiles as you uncover the area. Fantastic work. However, to make this perfect IMO :

-Fog of war should be on the minimap too as there isn't much point in my mind in being unable to see the whole area on the pop-up map while seeing it all on the usually permanent one.
-The mini-map is now huge! Is it possible to fix?
-The radius of the uncovered area could be bigger, or at least the space cleared directly in front of the character as he sees ahead: presently it practically only clears the squares directly "above" him in front.

Also one question: How does it work when you switch control to other characters? Is the map status the same for all party members?

Hi E.C.Patterson & KevL,

Just a quick response as I am having dinner at a friends and not at my own computer just now.

1) I did not need the FOW for the mini-map as I would probably choose to disable the minimap if this was the case. It was not something I even considered, but should be possible.

2) The mini map can very easily be reverted to the original size, simply remove the minimap.xml from the hak. To ensure the "MAP UNAVAILABLE" facility still works with the minimap, you have to add scriptloadable=true to the UIScene section of a copy of the original minimap.xml file. I will upload an edited version to the Vault for people who want this.

3) The radius *could* be increased , but would require a little more care with the code to ensure that the blocks clear correctly in relation to the whole radius. It is a little more complicated than you may think simply because of the way the blocks clear. Furthermore, I felt that the amount cleared as it stands was a good average for interior areas as well. KevL: The areamap.xml does not need to be edited. Thankfully.

4) Switching to a companion should make no difference bcause the GUI works according to the player and not the PC as such.

Cheers!

Lance.

Modifié par Lance Botelle, 05 février 2011 - 07:36 .

[E.C.Patterson]

Lance Botelle wrote...
1) I did not need the FOW for the mini-map as I would probably choose to disable the minimap if this was the case. It was not something I even considered, but should be possible.

Let me know if there's anything I can do.

Modifié par E.C.Patterson, 05 février 2011 - 03:09 .

[Lance Botelle]

Hi All,

I have uploaded a version of the minimap.xml for those people who want to keep the minimap to the original size. Simply download and place this version of the minimap.xml in the hak instead of the one it currently uses. (Use a hak editor to open the hak and replace the file.)

Lance.

E.C.Patterson wrote...

Lance Botelle wrote...
1) I did not need the FOW for the mini-map as I would probably choose to disable the minimap if this was the case. It was not something I even considered, but should be possible.

Let me know if there's anything I can do.

Hi E.C. Patterson,

If you intend to use the original size mini-map for which I have now provided a new XML file, it begs the question of whether you really need to use FOW with the comparitively small view of the world with this map? I would have thought it would be a case of allowing the small mini-map or making the "Map Unavailable" ... period. Personally, when the mini-map is at its original size, it always feels too small to be of much good to me anyway.

It would take a lot more coding for very little in return as far as I can see. (It may be a case of me not even knowing how to do it, although I suspect I would get there in the end if it is possible.) However, to support my own argument, I suppose I should alter the function that currently disables the map and mini-map to allow just the mini-map to be disabled, which it does not do at the moment. Maybe I could update this function if you think it would help?

Lance.

Modifié par Lance Botelle, 05 février 2011 - 08:26 .

[E.C.Patterson]

Lance Botelle wrote...

It would take a lot more coding for very little in return as far as I can see. (It may be a case of me not even knowing how to do it, although I suspect I would get there in the end if it is possible.)

I had thought perhaps it would have been just a case of giving the same treatment to minimap.xml as you did to areamap.xml. In which case I would have been happy to transfer and adapt the lines of code. But if you don't even know how to adress this, then I can understand you not wanting to spend time figuring it out.

However, to support my own argument, I suppose I should alter the function that currently disables the map and mini-map to allow just the mini-map to be disabled, which it does not do at the moment. Maybe I could update this function if you think it would help?

Good idea.

By the way, you can call me E.C. We've known each other long enough.

Modifié par E.C.Patterson, 05 février 2011 - 08:38 .

[kevL]

E.C.Patterson wrote...

Lance Botelle wrote...

However, to support my own argument, I suppose I should alter the function that currently disables the map and mini-map to allow just the mini-map to be disabled, which it does not do at the moment. Maybe I could update this function if you think it would help?

Good idea.

2nd!

I was surprised you didn't put in the fourth condition for 'nState' (enable / disable) .. just for Completeness! i'm good with it as is

*tinker tinker*

[Lance Botelle]

E.C.Patterson wrote...

I had thought perhaps it would have been just a case of giving the same treatment to minimap.xml as you did to areamap.xml. In which case I would have been happy to transfer and adapt the lines of code. But if you don't even know how to adress this, then I can understand you not wanting to spend time figuring it out.

Lance Botelle wrote ...
However, to support my own argument, I suppose I should alter the function that currently disables the map and mini-map to allow just the mini-map to be disabled, which it does not do at the moment. Maybe I could update this function if you think it would help?

Good idea.

By the way, you can call me E.C. We've known each other long enough.  

Hi E.C.

Well known and well met. Thanks.

I have not looked into this side ... and it may be as simple as you suggest .... but as the grid I use is based upon a 40 x 40 blocks of 6 x 6 pixels, creating a 240 x 240 "image", it may be too big for the equivilent minimap screen (unless it is able to auto-resize somehow depending on where it is placed, bt I suspect it is not as easy as this). Therefore, one would probably have to recalculate the area covered and resize the blocks and add new lines according to the calculations reached. As you are probably aware,as well as the new code, it would require editing of 1600 lines of code to ensure the blocks "sat" correctly.

I will look at reworking the other function for now then.

EDIT: Did you see I added an altered minimap.xml to "fix" the size for people who wanted it smaller like yourself?

Lance.

kevL wrote...

I was surprised you didn't put in the fourth condition for 'nState' (enable / disable) .. just for Completeness! i'm good with it as is

*tinker tinker*

Hi KevL,

I am a little annoyed with the ommision myself, but must have thought I would never use that combination at the time. That is unlike me in this kind of thing though, as if there is another "state", I normally account for it for "completeness" as well.

So, I will take a look at that later (probably tomorrow now) and update accordingly.

Cheers!

Lance.

Modifié par Lance Botelle, 05 février 2011 - 09:28 .

[Lance Botelle]

Hi All,

I am looking at rewriting some of the code to make one program that can be switched between "Active" and "Passive" mapping via a global variable and/or to a local variable which builders can associate with a feat on the player if so inclined. e.g. "Expert Mapper" feat that allows a PC to map passively.

I will also take a look to see if the FOW can easily be added to the mini-map, and again, hopefully, make this switchable for those who do or do not want the FOW for the mini-map. (I do not know if it is easy to add the FOW or not yet, so we will have to wait and see.)

I will also be updating the Map Unavailable function to allow just the mini-map to be unavailable, which is the last state not counted for at the moment.

After some consideration, I have decided *not* to increase the radius, simply because it involves a new algorithm to determine the blocks that are cleared and is not, regretably, as simple as increasing a variable. (This could be done by someone wishing to spend the time to do so, but is not something I wish to spend time doing at the moment. Maybe, it is something I can look at at a later date if there is a real burning desire for it. Alternatively, if someone wants to look at the code for themselves and write the part to increase the radius, I would be happy to examine it and add the new code to my existing code and release as an update if confirmed as OK.)

I wil post my results here later and obviously make the new updates as soon as possible.

Lance.

Modifié par Lance Botelle, 06 février 2011 - 02:03 .

[dunniteowl]

You, sir, have achieved at least Minor Hero Status in my point of view. FoW is not my favorite term, but the concept of not allowing the entire map to be viewable based on whether or not you have an accurate map -- or have explored the area -- is one of my peeves with the way the game was designed. Thank you for proving the devs right once again when they opined that they expected members of the Community to improve upon their efforts and "blow them away."

dunniteowl

[E.C.Patterson]

Don't know if you had verified this Lance, but I did, and map notes, as I hoped, show ABOVE the FoW (so you see the map pin even if that part of the area has not been explored.). A1! Thank you.



Thanks for taking a look at FoW on the minimap.

[Lance Botelle]

dunniteowl wrote...

You, sir, have achieved at least Minor Hero Status in my point of view. FoW is not my favorite term, but the concept of not allowing the entire map to be viewable based on whether or not you have an accurate map -- or have explored the area -- is one of my peeves with the way the game was designed. Thank you for proving the devs right once again when they opined that they expected members of the Community to improve upon their efforts and "blow them away."
dunniteowl

Thanks dunniteowl,

That's quite an accolade.  Is there a banner for it?   "Minor Hero"

I must admit, I only use the term FoW because it seems to be the term people understand when it comes to this sort of thing.

Lance.

E.C.Patterson wrote...

Don't know if you had verified this Lance, but I did, and map notes, as I hoped, show ABOVE the FoW (so you see the map pin even if that part of the area has not been explored.). A1! Thank you.

Thanks for taking a look at FoW on the minimap.

Hi E.C.

Yes. I was pleasantly surprised when the map notes remained visible. I thought it was going to be another issue to work around. It means builders can choose to either leave map notes as active in the fog to give approximations for the player ("the tavern is over yonder" kind of thing) or enable/disable the map notes as required by the builder. i.e. When the PC has actually found the location.

I will be looking at the mini-map code shortly.

Lance.

[Lance Botelle]

Hi All,

I have now uploaded the new combined "Active" and "Passive" system that is controlled by a global variable in a new module OnEnter script. (NB: Be sure to add the global line to your own module if you want to change it.)

There is also a variable to allow or disallow "Mapping During Combat".

I also added template code for builders to tie in with an "Expert Mapping" feat concept.

I also added the missing state of having only the mini-map disabled.

I was *unable* to work out how to make the mini-map have the FOW, and so advise simply making it "unavailable" with the new state available with the altered function above.

NOTE: I have tested this as far as I can, but would appreciate feedback to ensure that it is still working for everybody. Let me know of any problems and I will fix them when I can. It should, however, be fine. I would rather warn you to be on the safe side though.

Many Thanks.

Lance.

EDIT: It has been pointed out that being allowed to "zoom out" on the mini-map gives the player an advantage over the FOW on the area map, in that objects can be seen on the mini-map that cannot be seen on the area map. (See this screenshot: https://picasaweb.go...626503486292338) However, for my own design purposes, this was not an issue, because if I felt the mini-map was giving too greater an advantage in a situation where I wanted to restrict player knowledge, I could make the mini-map unavailable with the current code. For my own purposes, I wanted to avoid hiding the zoom buttons for the mini-map if possible, thereby leaving at least one zoomable GUI to the player at some times.

However, if there is a strong feeling that having the zoom buttons on the mini-map "hidden" (made permanently unavailable throughout the game), then I can update the code again to allow this option. Note, however, I suspect the buttons would be unswitchable (i.e. either permanently on or off from the start of the module) due to the fact that the zoom state of the mini-map is remembered between shows, which means if the zoom buttons were hidden when the mini-map zoom state was zoomed out, then disabling the buttons would serve little purpose at this point. They need to be disabled *before* the player has had the chance to zoom out in the first place.

Modifié par Lance Botelle, 06 février 2011 - 07:12 .

[Shaughn78]

Very nice, I like the combination. Currently working on incorporating this into Risen Hero.

Lance below I listed the variables that I found that can be modified to adapt the system to our different games. Are there any that I missed? Also for the feat, I just found a variable check. I just wanted to verify that it is all your system checks before I add a check for the feat to my levelup script that adds will update that variable.

edit ****Disregard the feat question, just read the comments about it and I'm all set with that one.****

Global:
FOWPASSIVE Change between passive and active system, set on module load 0 = passive 1 = active
FOWMAPINCOMBAT Close map during combat and prevent mapping 0 = no mapping in combat 1 = combat mapping

Local Area
MAPSTATE 0 = Map & minimap enabled, 1 = Map disabled Minimap enabled, 2 = Map and minimap disabled, 3 map enabled minimap disabled

Local Character
FEAT_ALTHEA_EXPERTMAPPER a character has expert mapping feat 0 = no feat 1 = has feat

Modifié par Shaughn78, 06 février 2011 - 07:34 .

[Lance Botelle]

Hi Shaughn,

I should have explained these more in the manual ... sorry about that.

All correct apart from ...

1) I think the FOWPASSIVE is the opposite to what you said. i.e. FOWPASSIVE = 1 for PASSIVE mode. The default of 0 is for ACTIVE mode. Feedback on entry to the module should tell you which system is active ... if I have the logic correct.

EDIT: Furthermore, these are "global" as opposed to "local" module variables ... if there is a difference?

2) FEAT_ALTHEA_EXPERTMAPPER is set to 1 if *any* PC that the player controls has the Expert Mapper feat. i.e. Only one party member needs to have the feat was my suggestion. Defining between the PCs for the map feat seemed a little too strict to me. I know there could be situations where the PC with the feat is disabled in some way, but that is why I left the variable check a little more "basic" to allow the builder to determine if and when the feat was present or not.

Lance.

Modifié par Lance Botelle, 06 février 2011 - 08:07 .

[Lance Botelle]

Hi All,

A bug was reported where "Passive" mapping mode was not clearing the variables correctly and causing FoW errors. This latest version (v1.01) should fix that. Be sure to replace all current scripts and haks with this version and apply/add the correct variables within the modules Onload. (v1.01b was the same fix with an updated PDF manual.)

Please keep me updated of any other errors that I may have missed.

Many Thanks.

Lance.

Modifié par Lance Botelle, 06 février 2011 - 11:12 .

[Shaughn78]

Lance,

When creating an area that disables the map gui Mapstate 1 or 2 should a NoFogofWar waypoint also be placed?

[Lance Botelle]

Shaughn78 wrote...

Lance,
When creating an area that disables the map gui Mapstate 1 or 2 should a NoFogofWar waypoint also be placed?

Hi Shaughn,

It's up to you really. I suppose that as the map cannot be seen, using the prevention waypoint may appear superfluous. However, using the waypoint will also prevent the code from firing when the player is in it as well, which may mean less CPU overhead.

It really depends if you intend to allow the map to become "available" again at some time with a code change. If you do not have the NO FoW waypoint in place, then the PC will have to map away the FoW as usual. If, on the other hand, you have a NO FoW prevention waypoint in place, then they will receive the whole map.

Personally, I *would* use a "NO FoW Waypoint" in areas where I was making the "Map Unavailable" for the area map ... but there may be other mitigating circumstances where I might change my mind.

EDIT: Did you pick up the latest bug free version that I uploaded yesterday evening?

Lance.

Modifié par Lance Botelle, 07 février 2011 - 09:23 .

[Lance Botelle]

Hi All,

Version 1.02 is now available, with the following alterations: ...

1) Debug code tied or made less intrusive.

2) Added extra checks for invalid areas.

3) Typo corrections in the PDF manual.

Also be aware that if the FOWMAPINCOMBAT is left in its default of 0, then mapping must be reinitiated by opening the map whether the player is in an "Active" or "Passive" mode environment. To avoid this for a Passive Mode environment, ensure this variable is set to 1, but be aware that it may affect performance if the combat is CPU intensive.

Many thanks for all the support, feedback, appreciation and Vault votes.

Lance.

Modifié par Lance Botelle, 11 février 2011 - 03:39 .

[kevL]

the Bard wrote...

3) The radius *could* be increased , but would require a little more care with the code to ensure that the blocks clear correctly in relation to the whole radius. It is a little more complicated than you may think simply because of the way the blocks clear. Furthermore, I felt that the amount cleared as it stands was a good average for interior areas as well. KevL: The areamap.xml does not need to be edited. Thankfully.

After some consideration, I have decided *not* to increase the radius, simply because it involves a new algorithm to determine the blocks that are cleared and is not, regretably, as simple as increasing a variable. (This could be done by someone wishing to spend the time to do so, but is not something I wish to spend time doing at the moment. Maybe, it is something I can look at at a later date if there is a real burning desire for it. Alternatively, if someone wants to look at the code for themselves and write the part to increase the radius, I would be happy to examine it and add the new code to my existing code and release as an update if confirmed as OK.)

what I did, after spending three days with coming to grips with how brilliantly simple the FoW is -- minus the ostensible frustrations including FLAMING TRUNCATIONS OF INTEGERS!!! Lol -- is this. It isn't perfect as it leaves "axe blades" sticking into the cleared area, but it's the least muck-muck of several permutations I tried.

iLoop of the core function basically increases the radius away from the player's current position. So i increased max-iLoop from 3 to 4. Next there are several possibilities, and I settled on leaving the first iteration as iLoop==1, doubling iLoop==2 to iLoop==2||3, and incrementing iLoop==3 to iLoop==4. Playing around with this is not for the faint-of-heart ..


It's not perfect, Lance, and i Can tell you're going for crisper edges : there are some skewed diagonals on Loop3 that get missed, it looks like. Personally i like it and ascribe to it, "hey, can't quite see there" ; some other permutations of the Loop increased this effect, such as iterating iLoop==2 to iLoop==2||3 plus iLoop==3 to iLoop==3||4

Also be aware that if the FOWMAPINCOMBAT is left in its default of 0, then mapping must be reinitiated by opening the map whether the player is in an "Active" or "Passive" mode environment. To avoid this for a Passive Mode environment, ensure this variable is set to 1, but be aware that it may affect performance if the combat is CPU intensive.

Among many, many other tweaks ( including the ability to turn FoW on and off ... and On Again!!! <- ended up deleting all string values for each area in the specific module, effectively resetting all those GuiTextures via a OnceOnly variable ) and some pseudo-reshuffling of code ( GetIsAreaInterior() only needs to be called once, sir ), plus changed most string_vars to constant literals ( why not ... ), simply add an extra note to the in-combat warning : <b>note Mapping is not allowed during combat.</b> You must reopen the areaMap after combat to resume mapping this area.


Astounding effort, Lance. You, sir, are a GENIUS ....

- any suspected release date for Althea ?


edit, Pic of axe blades
area {Width=16, Height=12}

Modifié par kevL, 05 mai 2012 - 11:34 .

[Lance Botelle]

kevL wrote...

Astounding effort, Lance. You, sir, are a GENIUS ....

- any suspected release date for Althea ?


edit, Pic of axe blades
area {Width=16, Height=12}

Hi KevL,

Thanks for all the high praise. You may be interested to know that I have tweaked and improved the code over the last year and it works much better now (in my opinion), but I dId not release any more versions as I wanted to leave that until Althéa is released.

That said, if you stick close to reading the blog (see link), I will release the module for beta testers as soon as it is close to ready and you can be onbe of the first to get your hands on it and all the improved code of the mapping facility.

Basically, I have made the functions more independant and made a couple of changes that were not obvious when first released (especially for MP).

Thanks again for lookin at the code and having fun with it. It's always a great feeling when others take a look.

Stay in touch!

EDIT: By the way, those "diagonal half cuts" are deliberate to give a half revealed map on the border of the PC's vision.

Lance.

Modifié par Lance Botelle, 06 mai 2012 - 07:15 .

[Alupinu]

Lance Botelle wrote...

...but I dId not release any more versions as I wanted to leave that until Althéa is released.
Lance.

So in other words there is no chance of the new FofW being released anytime soon?

Modifié par Alupinu, 06 mai 2012 - 08:15 .

[kevL]

Lance Botelle wrote...

EDIT: By the way, those "diagonal half cuts" are deliberate to give a half revealed map on the border of the PC's vision.

yes yes, they also make ... Axe Blades!!

Stay in touch!

will do.

[Lance Botelle]

Hi KevL,

I don't get those "axe blades", so maybe that was one of the "fixes" I made. Although, I seem to recall there was another reason for the result you are getting. I'm almost sure that there was a fix I made (even in the latest version), which resolved that image effect you are getting. I thought it was a result of the algorithm ... hmm ... I cannot quite recall ... except I am 99% certain that the result you are experiencing does not happen on my own version.

If you contact me by email, maybe we can look at what is happeneing ... and maybe you can have access to some of my new code so you can compare and find anything you want to do yourself.

ALUPINU: Contact me by email and maybe we can do something, especially if you are a person who can extract what you need from my own scripts ... yes?

Cheers,

Lance.


EDIT: Actually, I may have changed one of the images slightly (or altogether) to remove some of the jaggedness effect. I still get some, but not like you have.

Anyway, if anybody is interested, I wil upload my "alb_functions_map" include file, which contains much of the new and/or changed code that I have been using. Please note, there have been quite a few changes, and it is only really to be looked at and compared to what I have released for help. Note also, that there are a number of other scripts that I have changed that relate to this, which I have not  yet uploaded for viewing, but it can be seen that I was also working on my own "map" rather than a system generated one, which worked OK, but I decided to abandon as it involved more time than I felt it was worth including at this stage.

ALB_FUNCTIONS_MAP.NSS SCRIPT

Thanks,
Lance.

Modifié par Lance Botelle, 06 mai 2012 - 10:28 .

[kevL]

Lance, relax you're not going crazy.

the reason those 'axe blades' are there, sticking into the clearing, is because my adaptation of your code increases Loop from 3 to 4 !

To compensate, I let the conditions for Loop==2 go through on new Loops 2 or 3, and then Loop==3 becomes new Loop 4. This increases the radius that gets cleared nicely (imo) but leaves those blades sticking in, on skewed diagonals ( not exactly at 45deg but slightly +/- ). (I'm not sure if this is happening on myLoop==3 or myLoop==4 ...)


but the first time i saw it I smiled, so it's all good for now,