10 replies to this topic

[Himself]

Heya people ^^


Having read this http://www.pocketpla.../simscript.html

I could understand the whole guide, except for the 3 things that I'm going to ask..



Question number 1:

If my ONLY trigger is a StateCheck, will using a LastSeen automatically target the object of this StateCheck ?? (whether I wish it or not right??)



Question number 2:

In the guide mentioned above, open search field and paste sentence:
NearestEnemyOf and NearestEnemyOfType.


A very BIG block right under this part.. with lots of RandomNumGT (for 20, and later for 10), is 20 and 10 rolled for every instance of OR(3) along the block, or are these rolled 'only once' and the result used for the entire sequence of OR(3) in the block ???




And finally 3rd question: (which is a result of questions 1 and 2)

The same block I mentioned above starts with:


IF
OR(3)
StateCheck(NearestEnemyOfType([GOODCUTOFF.0.0.SORCERER]),STATE_HELPLESS)
!See(NearestEnemyOfType([GOODCUTOFF.0.0.SORCERER]))
RandomNumGT(20,5)
OR(3)
blablabla...


So, provided he can see the nearest sorcerer in party, this sorcerer is not helpless, and the number rolled is inferior to 5 (25% chance), this failure will invalidate the whole block thus making the script jump to the next block ??¿¿

Isn't that actually contrary to what this example was meant to demonstrate (priority targeting?)?

If not please explain why make an elaborate block that gets skipped 25% of the time.. so long as there is a sorcerer - and further in the block a mage - in the party. This logic gets me very confused..




Maybe (probably) I completely misunderstood... also if I wasn't clear on some points, let me know and will try to elaborate again.

Any and all help is immensely appreciated

(edit: better explained.. hopefully ^^)

Edited by Himself, 19 January 2010 - 09:50 AM.

[Himself]

Jarno Mikkola, on 18 January 2010 - 10:26 PM, said:

I'll see if I can come with some sort of solution when I get home... this week end. But before that, you are free to take a shot at it, but make sure that you can restore your game before you even attempt anything.

There are currently 239 bifs.. too much to do by hand. But does the above mean you'll actually see if its 'do-able' ? I get nothing about weidu so if its too much work please don't spend your time with. I was never intended that you could/should help me in any of my crazy attempts ^^


But just in case you think its worth a shot
What would ne needed.. I think:


1- Check data folder for all *.bif ( *** can weidu check when a file was created? )
2- Start extracting, and create/update list of files already extracted so as not to repeat those
3- Skip (to not overwrite) files already in override folder

*** I ask since newer bifs may have an updated version of the same file that is inside an older bif.. so weidu would need to extract from the newest created *.bifs first. If weidu can not make this check, it could extract based on a "created by hand" listfile where you inserted the name of each bif (from newest to oldest).


Anyway.. that would leave all game files in override, and we could delete or make 0 byte files of all previous biffs including BG1+TotSC+SoA+ToB right? So general biffing could biff from this point based on dunno, file extension? whatever makes it faster to find later. Probably would need more than 1 biffing session if these get slow after some time due to memory issues.

Also, if chitin.key only indexes files from the data folder, it could be cleaned when all files are in override folder, but dunno if that would make the file any more accurate or faster after general biffing.

Edited by Himself, 19 January 2010 - 06:18 AM.

[Miloch]

Regarding your first post:
#1: No - LastSeenBy will respond to the last matched See trigger.
#2-3: The d20 is rolled once for the whole script (every time it cycles). It doesn't make much sense to me. It should probably have been written in reverse, and included a RandomNumGT(20,0) block as well, unless as you suggest, it should be skipped 25% of the time. On top of it, the first example uses negative (false) conditions. Personally, I wouldn't use a block that complex in script targetting. Scripts can go wrong enough as it is, so keep it simple. As if anyone would make such a complex calculation in real combat anyway...

I'm not sure if there's a question in your second post, or if there is, what the original context was.

[Jarno Mikkola]

Himself, on 19 January 2010 - 06:02 AM, said:

1- Check data folder for all *.bif ( *** can weidu check when a file was created? )
2- Start extracting, and create/update list of files already extracted so as not to repeat those
3- Skip (to not overwrite) files already in override folder

1-2-3. WeiDU doesn't need to check what's where as long as it's within the Chitin.key file, it's golden, as there is only 1 reference to each file... so when or if you are able to unbiff all the files that are referenced there, you can go and overwrite CD folders .bif files... at least in theory.

Himself, on 19 January 2010 - 06:02 AM, said:

Anyway.. that would leave all game files in override, and we could delete or make 0 byte files of all previous biffs including BG1+TotSC+SoA+ToB right? So general biffing could biff from this point based on dunno, file extension? whatever makes it faster to find later. Probably would need more than 1 biffing session if these get slow after some time due to memory issues.

Well, it's probably best to actually extract the .bif files to somewhere... then overwrite the .bif files with 1 bit .bifs... and install any other mods... and then use the generalized biffing to 'reorganize' the game files so the computer reads them faster. The advantage of making the game this way would be that the data base is less cluttered with unneeded files in the end, and so you'll save some space... how much it's? Hard to say. Is the game faster to load and play? It's, in theory.

That's at least... the theory.

[Himself]

Thanks for clearing it up Miloch, I was getting afraid nobody would answer ^^

Miloch, on 19 January 2010 - 04:54 PM, said:

I'm not sure if there's a question in your second post, or if there is, what the original context was.

Oh its because I PM Jarno a lot, and he asked if we could let these conversations in a topic, so thats why I changed the name of this topic too.. ^^

Anyway its about re-biffing most of the game files, since you guys started the topic about change biffing in the megamods sections, I thought "what the heck why no re-biff everything", since most of the original game files (except for the areas) get edited by X or Y mod and this generates a lot of double copies as well. But I simple lack Weidu knowledge to know if its doable and if it can improve performance of the chitin.key, so basically was just elaborating and theorizing with Jarno (since hes much more of a coder than me).

Edited by Himself, 21 January 2010 - 10:30 AM.

[Himself]

During the install of a mod I had some errors of the like:

[NMR-V1.5/baf\Original\m_shout.baf] PARSE ERROR at line 72 column 1-26
Near Text: )
[Heard] argument [HELP57] not found in [SHOUTIDS.IDS]


If I do go in the shoutids and create the HELP57 under a new value, would that actually fix the error ?¿

[Miloch]

Himself, on 26 January 2010 - 05:33 PM, said:

If I do go in the shoutids and create the HELP57 under a new value, would that actually fix the error ?¿

Yes. It's very easy to do this in mod code too:

APPEND shoutids.ids ~57 HELP57~ UNLESS ~^57 HELP57~

Which means add it to the IDS file unless there's already a similar entry.

[Himself]

Thanks a lot Miloch!!

btw, this can be done even after the mod was already installed, right? since the absence in IDS didnt stop the mod from writing the script, I assume.

[Miloch]

It should be done before compiling the script, because if it didn't find the IDS value then it didn't compile correctly. You can fix both the IDS and the script manually with NI or DLTCEP though, if you have to.

[Himself]

Any way to solve this or have NI use more memory ? Or is this an OS issue ?.. Running Win7 here :X

[Miloch]

I have never seen that... could be a memory issue or a Java version issue (make sure you have the latest). You can try upping the memory by launching it with a batch file. Just make a new text file, call it NearInfinity.bat (or whatever) and in it put:

java -Xmx128M -jar NearInfinity.jar

That will launch it with 128M instead of the default (I think 64M). You can up it from there if that doesn't work (256, 512) but if you get that far and it still doesn't work, it must be something else.