|
| Thread: ERA scripts debugging and fixing |  This thread is pages long: 1 2 3 4 5 · «PREV / NEXT» |
|
Bersy
Honorable
Supreme Hero
|
posted May 06, 2012 02:43 PM |
|
|
|
Is that only Era problem or WoG 3.58f either?
|
|
solitaire345
Promising
Famous Hero
|
|
posted May 06, 2012 02:54 PM |
|
|
The same happens on WoG 3.58f too.
____________
|
|
majaczek
Supreme Hero
Work at Magic Dimmension
|
|
posted May 06, 2012 03:39 PM |
|
|
about HE:A3
I think the script should be fixed but old command stay. The current version of command if used wisely allow adding hardcoded artifact bonus to hero without that artifact. It may be glitch or hack but is useful. Or if you believe the command is mostly used by mistake in scripts you may "fix" it - but then ther need to be another command which would do purporsed behaviour of the hack with more official way. For example Advanced Level's "Irresistible Magic" works like Orb of Vulnerability (I don't remember name properly but I mean that black orb), and it does it with some hack of artifact. Old versions of AL just put the art on Ammo Cart slot at beggining of each battle, moreover it can be dropped to backpack. The new versions at least don't allow clonning this artifact, perhaps even are compatible with war machines script - but with current syntax it's enough to place orb and remove it with HE:A3 once - once it would be fixed - it need add the art every battle and every batttle remove it (I guess now it just places the orb at same slot but after War Machines script execute and remove after battle restoring Ammo Cart - or another way if H3 engine handles only arts at beggining of battle - adds the art before battle and fixes war machines just before the war machine were spawned).
So having ability to add artifact bonuses without the artifact itself would be valuable, even more if there's no script method to simulate the behaviour of the artifact (and juggling artifacts around battle start is a hack too) So if you really want to fix HE:A3 please add two new commands - to add or remove artifact bonuses without really changing the artifact (and which would also trigger Equip Artifact ERM Event properly perhaps - or make it separate command).
About hacks - when I haven't the memory codes from Bersy I resorted to a hack which disables UN for commanders just before they would spawn and enables back just after they would spawn which allowed me to start battle without commander spawned but keep all commander data and behaviour before and after the battle including commander getting experience (yeah it behaved if commander weren't killed no matter what). I learned a bit then but just having memory code for disable the incompability between EA and COmmanders were much better than having to workaround this (thanks Bersy!).
|
|
JimV
Responsible
Supreme Hero
|
|
posted May 06, 2012 06:32 PM |
|
Edited by JimV at 18:33, 06 May 2012.
|
I personally disagree that HE:A3 should remove artifacts without removing bonuses. There are already ERM commands to add bonuses (HE:F - Primary Skill; morale, luck, Secondary Skills, etc.). These commands are in fact used to create new artifacts in many maps. HE:A3 has a useful function to remove a specified number of artifacts and should not be combined with another function which may or may not be wanted, and if wanted, can easily be accomplished by other means. In my opinion.
Meanwhile, I am bogged down a bit on the Garrison's problem, and have only more negative information. I removed all 275 Garrisons from the saved game (1_Red_Quick), and still got the immediate crash during loading - as expected, since if bad Garrison placement or numbers of Garrisons caused the crash, the crash should occur on day one or two. Also, I created a Large random map with the Garrisons script enabled, asked for "tons of Garrisons" at start-up, and have so far run the map until Month 13, Week 1, Day 1, without getting a crash on re-loading. So it seems to me that the Garrisons must be combined with some other feature (I don't use a lot of WoG features usually - there are several which I have never used) or behavior. Or perhaps I don't have enough Garrisons in the test map. I may try again with an XL map without water.
I noticed in passing that there are a lot of resource objects in the list of DEF's of the saved game, and that unlike other objects including the Garrisons, the same DEF occurs several times. I hypothesize that this means resources are being "spawned" during the game, which makes me suspicious that these resources have something to do with the problem. Probably just another bad guess which I have to work my way past. It seems that the only right guess I make is the very last one.
I make take a break from Garrisons to write the "Forge in the Forest" script for "The King in Yellow", if nobody objects strongly.
P.S. Thanks to Solitaire345 for the interesting script-initialization information and test case.
|
|
majaczek
Supreme Hero
Work at Magic Dimmension
|
|
posted May 06, 2012 07:16 PM |
|
|
|
Okay, I see HE:A3 weren't intended to have such effect, and probably should be fixed. But it has given intresting results used the way I described. So if it really has to be fixed (and perhaps it is) there should be another (new) command in ERM which is intended to produce same effects (add/remove harcoded abilities from hero without changing real artifacts). Changing primary skills is indeed trivial, so is morale/luck. But there's already a quite much artifact with hardcoded effect which couldn't be reached by script or is really hard to do it fairly - for example Orb of Vulnerability, Angel's Wings - and almost all H3 artifacts which weren't just Primary skills artifacts or Morale/Luck ones.
|
|
Bersy
Honorable
Supreme Hero
|
|
posted May 06, 2012 07:21 PM |
|
|
Thanks for info Jim, sounds promising.
I fixed artifact counter for HE:A3, not the behavior. In Phoenix we use it just to delete artifacts from backpack.
|
|
JimV
Responsible
Supreme Hero
|
|
posted May 06, 2012 08:20 PM |
|
|
That is fair enough. If people object to bugs in scripts caused by mis-use of HE:A3, that can be addressed in the scripts themselves.
I haven't tested recently, but I have a vague recollection that the bonuses mentioned in the Help for the HE:A3 command are Primary Skills only.
At six months game-time in an XL random map with "tons" of Garrisons, no problems so far. Multi-variable problems are the worst kind.
|
|
Bersy
Honorable
Supreme Hero
|
|
posted May 06, 2012 09:32 PM |
|
|
|
Perhaps y1..y100 variables corruption could also break the logics, but you play without problems, so it needs deeper revision.
|
|
majaczek
Supreme Hero
Work at Magic Dimmension
|
|
posted May 07, 2012 04:05 PM |
|
|
I have an idea how to provide unlimited number of standard variables, without having to assign memory for each one. It involves adress tree (a tree with 256 childs, with data only on bottom of roots) data structure. the problem is the idea to work need hooks on current variable usage code. If we want to have decent backward compability we can make the structure only handling "new" variables, that mean ones above TE limit (so code involving old variable numbers work as much like old as it can). The support for so much variables over the standard interface would involve each old ERM command much less limits on usage, in example some ERM command needs continous block of v-variables. It would also help making scripts compatible wit elder scripts - all unclaimed global variables from 3.58f can rest unclaimed, and we can make claimed a range of variables over the 3.58f limit. (any ERA script which is wanted to work with every old map etc. could use the variables from new range so it won't conflict the old pre-ERA scripts - this would also help for example making merged_SU compatible with all pre-SU scripts/maps without to have to resort SN:M and SN:W variables). Once we would have hooks it's trivial using this algorithm to provide 2^32 v-variables, and same for each global variable type, hovewer using the machinery for local variables would involve copying the tree many times which at least would make calling functions much slower, so for locals we can stay with old limit or make new limit standard way (by using contignous table).
The structure is simple and enough efficient. The main entry have optional 256 entries which have optional 256 subentries which have 256 optional subentries which have 256 optional variable entries. Variables zeroed would be treated same as unallocated. The tree entry with no active subentries would be treated as unallocated (meaning all variables under it are zero/unallocated). Using one variable anywhere on range would at worst need to allocate one varaible entry and two tree entries. The contignous block of 256 variables would need to allocate at worst 256 variable entries and three tree entries (two if numbers are aligned). I can provide C++ code for the data structure and handling of it, but any ERM interpreter/compiler hooks are left to you Bersy or a person which you choose and who agree to help.
Hope it fits here better than to official ERA thread.
|
|
Bersy
Honorable
Supreme Hero
|
|
posted May 07, 2012 04:38 PM |
|
|
majaczek, of course I thought about such a simple solution. But there are a few reasons why it's senseless:
1) We need often dynamics, not statics.
2) WoG accesses variables directly. You cannot hook 100500 places, including indirect addresses and addresses with pre-calculated offsets.
|
|
Bersy
Honorable
Supreme Hero
|
|
posted May 07, 2012 07:50 PM |
|
|
|
This is the map which is always killed by garrisons script: Link
|
|
majaczek
Supreme Hero
Work at Magic Dimmension
|
|
posted May 07, 2012 08:46 PM |
|
|
1) Dynamics are welcomed too, but statics are needed also..
2) ouch it hurts.... thousands of places to patch - seems it's impossible with retaining binary compability with TE. So until somebody wants to waste time to analyse WoG sources for finding every code signature which affects the veriables, it seems my concept fail.
Have you thought of adding new global set of variables with such "unlimited" feature? we already have a and b letters uncovered, and perhaps some more. We could then make two global sets of variables (integer and floats) with perhaps strings too, which could be threated differensive in ERM so it couldn't be used for example in VR:C which require v-variables, but most of cases of normal variable use would be covered... or just use older letters with some mark as WoG team invented negative indexes. Also we can do a bit security from offsetting by making the tree bottom of contignous blocks of 256 variables (it would lead to bugs if number%256 is too big but offsetism would work on most low ones from the bank). The indirect pre-calculated offsets are happy since I already stated the old range would use same old contignous block. So if we made our new variables different rather than just hooking everything it may work like there are different types of z-variables (the ert-variables are purporsely managed difrently than dynamic z-variables)... I hope then we could be done in less than 300 hooks. Am I still too optimistic? If yes we can always make new category of SN variable (the concept is dynamically allocated but it's hidden detail inside - the scripters would see it as huge static variable). If there no chances of something similair and useable let me know and we would be back on the main topic.
|
|
Bersy
Honorable
Supreme Hero
|
|
posted May 07, 2012 09:03 PM |
|
Edited by Bersy at 21:04, 07 May 2012.
|
I won't do it definitely. To my mind, the reward does not cover the price and I see no feature in ERM and indexed variables. Something of a higher level should appear. Sorry.
P.S. Let's skip the offtopic here.
|
|
JimV
Responsible
Supreme Hero
|
|
posted May 08, 2012 03:02 AM |
|
|
Bersy, thanks for the map. Preliminary results:
Test 1: Era 2.1, Garrisons script activated. End-turn until Month 2, Week 1, Day 2, then re-load from Autosave (M 2, W 1, D1). Result: crash during load.
Test 2: Era 2.1, Garrisons script not activated. End-turn for a month the same as before, then re-load Autosave. Result: crash during load.
Test 3: Same as 2, except Autosave re-loaded on second day. Crash during load.
Tools/Validate Map says "there is no problem with the map". (Easy for it to say.)
Test 4: WoG 3.58f. End-turn for a month, re-load Autosave. No crash.
Observation: this is the biggest random map which I have run under Era so far. It has approximately no water, and no block of the underground bigger than about 8x8 without terrain. My other two random test maps had less than 1/4 of the underground developed.
|
|
JimV
Responsible
Supreme Hero
|
|
posted May 08, 2012 07:33 AM |
|
|
Quote:
Bug report #3
Press "M" and choose "normal battle". Random Hero script produces ERM errors message.
Analysis: The Random Hero script tries to pick a random Hero to defend a group of neutral monsters who have been attacked by a player's Hero, 25% of the time. It selects a Hero number from 0 to 154 randomly (155 is reserved for Asmodeus), then does a series of checks to see if that Hero is suitable. If not, it tries another number, until it has exhausted all possibilities. One of the checks it makes is whether the random Hero is in any of the Prisons which are on the map.
The subject map has a Prison at 85/76/1 which does not have a Hero in it. (When you visit that Prison, it says, "The King has released the Hero, yada, yada, yada.") Therefore when the script checks that Prison, it gives an error message (no Hero at HE$/$/$, where $/$/$ is the Prison location). My guess is that the Hero scheduled to be in that Prison somehow got assigned to a player or a Tavern slot at the start of the game.
I can see these alternatives (there may be others):
1) Live with the error messages. The script continues and finds a suitable Hero with no further problem. The error messages are annoying, but will only occur when there is an empty Prison on the map. Unfortunately, there is no special ERM receiver for Prisons.
2) Eliminate the Prison check. Then in some small percentage of cases the random Hero will be one from a Prison. If the random Hero wins the battle, it will go back into its Prison after the battle (courtesy of the HE:O$/1 syntax), but if it is killed in the battle, then when its Prison is visited, the message "The King has released the Hero ..." will appear and the Prison will disappear without releasing the Hero. (Tested.)
3) Designate Boragus (#154) to always be the random Hero and disable him from being hireable by any player. (Give him properties equal to those of a randomly-selected Hero before the battle starts.)
4) Use a Hero that is in a Tavern - I just thought of this and haven't tested it, so I am not sure what will happen if that Hero is killed in the battle. If it leaves a blank Tavern slot, that would not be acceptable.
I prefer 2) as it is very easy to do and eliminates glitchy error messages. Removing lines 156-157 or converting them to comments as shown below eliminates the Prison check:
*!UN&-786:U62/-1/?y18; //get the number of prisons on the map
*!DO7797/1/y18/1&-786:Py18/62/y19; //iterate through prison's and see if this hero is in any of them
|
|
Bersy
Honorable
Supreme Hero
|
|
posted May 08, 2012 09:08 AM |
|
Edited by Bersy at 14:43, 08 May 2012.
|
!!UN:P904/1 P905/0; errors displaying off
dangerous code, !!HEx/y/z:N?...
!!UN:P904/0 P905/?y1; errors displaying on, get result
!!if&y1=1:; there was an error...
Random Map, Test 5: without garrisons it's ok even with Phoenix. Used the updated era.dll: http://wikisend.com/download/736030/era.dll
|
|
JimV
Responsible
Supreme Hero
|
|
posted May 08, 2012 03:39 PM |
|
|
That's a beautiful idea! (No wonder you make the big bucks.) My implementation in the Random Heroes script:
!!UN:P904/1 P905/0; disable error messages <--added
!!HEv1/v2/v3:N?y2; //get hero number at prison's position
!!UN:P905/?y3; <--added
!!UN:P904/0; re-enable error messages <--added
!!FU&y3>0:E; leave if error <--added
!!IF&y2=x3:V786/1; //set flag if the hero is in prison
Garrisons Test 6: select "some" Garrisons at the start of the game (choices are "none", "few", "some", and "tons"; previous tests were done with "tons") - result (with new Era.dll, thanks): no crash on re-load.
So my current wild guess is that some limit on the number of objects is being exceeded.
|
|
Bersy
Honorable
Supreme Hero
|
|
posted May 08, 2012 04:09 PM |
|
Edited by Bersy at 16:11, 08 May 2012.
|
Right, SyDr also says about only "tons" crash.
BTW, it's safe to write !!UN:P904/0 P905/?y1, because options are a simply array of 1000 integers.
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
|
posted May 08, 2012 05:32 PM |
|
|
Has anyone tried it with:
!#UN:C4892718/1/183; 65000 objects allowed
This code seems to be safe. Or is about max garrisons number?
|
|
Bersy
Honorable
Supreme Hero
|
|
posted May 08, 2012 06:14 PM |
|
|
|
Hmm, I don't know if it can help, but still worths trying.
|
|
|
|
