Ultimate Amiga
Games Corner => The Crypt of Bloodwych => Bloodwych Editors and Modifications => Topic started by: MadMunky on January 13, 2016, 07:27:20 AM
-
Sorry about all the new threads but I want to try keep each thing separate.
Horace, did you ever make an app to output the datablocks to files, I need these for the HTML version i.e. for the original we have
Mod0.Monster
Mod0.Ob
Mod0.Map
Mod0.Switches
Mod0.Triggers
Also if you have these files for your new version i'll start to check if they work also
-
Yes, some of them at least. This is done by my editor, providing the data locations are "mapped" (known) ... I did quite a few locations for BEXT and everything known I have done for the original 439 version.
(I would love to try and include Atari data file support also)
There's a zip on one of the other threads (where I asked BruceUncle about BEXT disassembly) .... I will try to find it later and attach it here as well :)
I will also pump out a BOS data set for you, although the final tower isn't complete.
-
Thanks Horace,
Least I can make a start and see what breaks :)
-
Hi MM,
BEXT files attached for you.... probably more to come when I look into it in more depth.
Pretty sure one of the character colour files has an extra bit of data each (maybe characters.colours ?) ... I'm guessing this is used for the colour of each avatar once recruited.
-
Thanks Horace!
Added these in and they loaded up without issues! There is a few graphic errors i need to look into but they are working and im able to walk around the towers and triggers and monster are working. Of course we did not add any code to recruit the monsters or anything extra that was in the Extended levels but the base seems to work!
Now I dont remember the Extended levels much was this a correct monster?
(http://s7.postimg.org/72tre1igb/bloodwychetx.png)
Now the strange thing this is the "ChaosEx" data you uploaded but comparing it with Alan's map (I really need to make a map viewer :))
(http://s11.postimg.org/drmiiyvcz/bloodwychetxmap.png)
I'm standing where the Red block is and Alan called this the Moon Tower (I cant remember if they officially had names) so someone if wrong...
Anyways this is excellent news and figures crossed makes things a lot easier!
-
i'd assume so, but i cant remember off the top of my head! Maybe i can pull the info out of my maps / viewer.
You are welcome to use my amiga editor as a map viewer if it helps?
It's WIP but always is!
really glad the data set help :)
-
Thanks Horace I should be able to knock up a viewer pretty quickly but what would help is if you where able to go to the same location on the Amiga or if your viewer shows you the monster check that and let me know if that monster was right?
-
Thanks Horace I should be able to knock up a viewer pretty quickly but what would help is if you where able to go to the same location on the Amiga or if your viewer shows you the monster check that and let me know if that monster was right?
now i'm done with my other posts, i'll do it right away :)
-
Right.... looks like we are all good!
There is an issue with Alan's maps, in that he has labelled them wrong. He starts with a tower called "main" and this is wrong... for one thing they are more like Dungeons than towers! Secondly, each one should be labelled acording to the crystal and coloured Entropy monsters.
So the correct order is Serpent, Chaos, Moon, Dragon .... what you are looking at is really the Dragon Dungeon :)
I've loaded this up and you can see on my map a monster in position X0 Y0 F0 .... further checking revels that (s)he is a Red Blodwyn as expected :) see the monster stats data on the bottom right of picture number 2
-
Now the strange thing this is the "ChaosEx" data you uploaded but comparing it with Alan's map (I really need to make a map viewer :))
just to add confusion, it sounds like i may have exported files with the wrong labels then.... (possibly swapping dragon/chaos round?)
-
Hey MadMunky, a few things re: BEXT that i'd be grateful if you could keep me informed on in your experiements!
1) Have i labelled the files wrong (they are ok in my viewer, so it might just be an export fail)
2) certain monsters hold/drop items .... i think they are marked as 'invalid type' in my map editor. (see the pic i posted before) .... any info on how they are set (probably a bit-set tbh) and how the object dropped is determined would be really useful.
3) Any info on new pads/switch triggers etc, such as the Summon pads would also help!
-
Hi Horace,
Will do, this will prob take some time as I will have to develop a way to read the in game memory and try detect whats changing and as I write this i'm thinking this is where Bits version may come in handy!
Bit,
Can your version load up the data disk and have it playable? Is there any way I can hook into the memory once its loaded so I could read say the map data block to draw it out so I can see as things change. I used to do this with Steem and WinUAE but Steem stores the memory backwards and WinUAE is slow and a pain so your version would be perfect for this!
We would need to work out a way to expose the memory (ideally for me a WebService as I already have the map viewer being done for the HTML version which would be easy to adapt to read your memory block) but if you have a working version in Visual Studio I could look at add in that support if I can work out how in C :) the other options are to hack into the applications memory using node.js and ReadProcessMemory I believe would do this I would need to investigate more into that though...
-
Hm, I cannot confirm this 'backwards' of Steem. I made my memory images with it. WinUAE really needs a longer time until it runs and I needed some time to made the right setups to run it at all, but once this is all done, it works fine. Still - would be a pain to work with those both.
My versions do use an original memory image (with initialized values, shot at the main menu directly after the came the first time here, so just loses the title image) and operates on it.
Even that the real memory location of this image changes from run to run, it is declared as a global array with 1 MB-size and got the name M. To match the labels of the disassembly the datas are loaded to M[0x14000], so there you could find the first original opcode of the game.
Both screens can be found in consequence at M[0x70000] and M[0x78000] (differs a bit from amiga version). That means: you can ever hit the F12 key for a break, go to the debug window (option memory), enter &M[0xyouchoice] and it will list the contents (never tried to save from there, but there should be an option). Then you continue to debug. Except for a very few needed variables, the current version still has no own data-fields. It operates completely on this M[] - and that correct in endianess (keeps amiga/atari style, which differs to PC-version).
You already know how to compile normal and extended version (#define NORMAL in types.h, set // before for the extended levels). So - if the current problem is really just the missing redistributables, you should make it...
-
Will do, this will prob take some time as I will have to develop a way to read the in game memory and try detect whats changing and as I write this i'm thinking this is where Bits version may come in handy!.
Reminds me of this upcoming WinUAE feature, heat maps (http://eab.abime.net/showthread.php?t=80750).
-
Horace,
Can you check the object files you posted on here, the Serpent tower file looks fine but the rest do not seem valid (looks like your grabbing the wrong address's?)
Check out the chaosex.ob
(http://s24.postimg.org/qsvfh1cqt/2016_01_20_12_27_51_Settings.png)
-
I'd recognise that data block anywhere! That's a 00000 starting point so I probably loaded a variable incorrectly.
Will take a look when I'm home!
-
the offsets i have in the 'datamap' seem right, for where they are in the BEXT main file.
$1071A serpent
$11B1C chaos
$12F1E moon
$14320 dragon
each one should start 2 bytes 'earlier' to include the number of objects in the data-set. e.g. 10718 for the serpent dungon. The blocks are then $402 bytes long
What is really wierd is that:
a) the chaos one did not save using the specified offset. (code looks fine)
b) i was looking at the objects displayed by the editor, and they didnt seem to match the exported data-blocks (??) yet both referred to the same variables to find the above offsets!!
c) my editor has randomly started crashing when i switch to the 'objects' page, and have BEXT loaded. (edit... just worked out why - i am auto-loading into a 'sixth' tower that does not exist)
EDIT 2:
problem found and fixed :) new files attached!
this just makes me realise how much some of my editor code needs tidying up (the import/export procedure is very messy)
-
Nice one Horace this works.
So we have the levels loaded, all the items load and placed correctly (I need to add in the different items for the extended levels), the monsters are all loaded but I need to fix the palettes on them.
I think rather than trying to decode the original source for the amount of effort it takes (and Horace you and bit will do this a lot faster than I can) for the little bits we are missing like monsters that drop items which i expect will be code we will not use like the Zendik code i'll just play through the game and find the monsters that drop items.
After that its just a case of adding in the new switches and some code to allow you to recruit the monsters and we should have a fully playable data disk.
-
Found the block of data that makes up the characters names in the extended levels there must be pointer to which are used but you can change them and change the characters names.
(http://s19.postimg.org/5afp9hx1f/2016_01_21_15_06_59_Hex_Workshop_D_Dropbox_Blood.png)
-
Horace,
Can you remember if there where any scrolls in the DD? I can only find REFORGE THY BONES and a potions scroll, I guess they trimmed it out to make room :)
-
Either that or they couldn't be bothered?! There's lots of room left in the data at the end of the 512k, but maybe the ST version isn't quite as efficient....
I don't think there are any, but I will be patching. My next (BEXT) update to have more!!
Great work on the names btw. So please document the monster item drops carefully though , as I may be able to reverse engineer from your findings :)
-
Will do,
The way we do it in Bloodwych it was based on the monsters form id as to who dropped what, at the moment formid 18 in extended levels drops a chromatic key, I expect there will be more.
-
GRRR!! just wrote a massive reply on this only for my internet to blot out and lose it!!
I have found the item dropped data for you MadMunky, so you can use the code correctly. (although you'll have to do something specific for Books of Skulls as i end up hacking the Zendick drop code!! ... which means my method there matches the one you are already using... using the form ID)
In the BEXT file it's at $161EC and is $62 bytes long (it is immediately before "mary had a little lamb" etc)
You can now code it 'correctly' and the data looks like this:
56565251535017171A186019345351505656181A182020523518531A19171861515022502E5256253153552255512E52515650533B5652295550513654181A1819171A37635251545553565450525051535550525451181850561A181A181A186200
As an example, the first few bytes: $56 $56 $52 , relate to two chromatic keys, then a serpent key, dropped by an elf, a ninja and a dragon.
If you remember fro reading the monster data, each one had a 'type':
Type 0 - normal
Type 1 - normal with spells
Type 2 - Drone
Type 3 - Drone with spells (i.e. set bit 0 = spells)
Type 4 - Shooter (Arc Bolt Machine)
... The monsters who drop things are all appearing in my editor as Type 8 (it calls them 'invalid') ... perhaps really its a case of (i.e. set bit 3 = drop object?) - I've checked and these match up with the object codes above.
I haven't extracted this data yet, because i need to test the preceding bytes, but from experience i suspect they are 'offsets' to how far into the object list each Dungeon begins:
00 00 - 00 0E - 00 20 - 00 45
These would mean the Chase dungeon started at an offset of $0E, which would be object: $51 .... i will have to check this!
-
As an example, the first few bytes: $56 $56 $52 , relate to two chromatic keys, then a serpent key, dropped by an elf, a ninja and a dragon.
How are you working out what monster dropped the item?
Nice work on this, if we can identify this it will save me a lot of time :)
-
The first type 8 monster drops item 1, the second 08 monster drops item 2 etc
I guess they are "loaded up" into the expanded monster block when you enter each tower (don't ask me what havens when you leave a tower though) .... In the same way the ace of swords is automatically "given" to zendick when the monster block is expanded.
-
Ah nice one, I get you now! This makes things a lot easier I'll make a function for type 8 monsters to drop these items that way when get get on to a editor your just have to assign it as a type 8 and you can then assign an item to drop.
-
i might see if it's possible to use the same method as a 'hack' on the original bloodwych to create more consistency in the data / editing....
-
all confirmed...
the "drops object" requirement is a bit set (bit 3 of the half-byte for 'type') ... i know this as i have added it to my editor and just produced a drone (type '2') with spells (bit 0 set) and who drops and object.
i also changed the 00 00 that i suspected was the tower-offset, and it did indeed change the dropped object accordingly.
i will include the 'data block' on my BEXT outputs in future, and look to implement this into my editor :)
-
Horace can you explain which bit is used
Here is the first monster in the DD that drops an item
85 FF 16 08 12 01
AB CD EF GH IJ KL
The bits for the monster are
1000 0101 1111 1111 0001 0110 0000 1000 0001 0010 0000 0001
-
Horace can you explain which bit is used
Here is the first monster in the DD that drops an item
85 FF 16 08 12 01
AB CD EF GH IJ KL
The bits for the monster are
1000 0101 1111 1111 0001 0110 0000 1000 0001 0010 0000 0001
in that list, the one on the far left. >1<000
It's the bit '3' (remember there is a bit '0' for spells, and bit '1' declares a drone) of the first half-byte ... ( which here is a value $8)
IIRC the second half-byte is the floor on which the monster starts?
So for example, if the first half byte was 1010 , it would be:
- dropping an object
- not an arc bolt machine
- a drone
- not spell casting.
-
OK then im not sure how this works out
The array of items posted has 96 items listed but there is only 54 monsters which have items being dropped...
-
perhaps the offset values mean certain objects don't get used / dropped?
I would have to do more verification.
Are you sure there are not 54 items held by type $8 and the remainder held by type $9 (i.e. bits 0 and 3 set)
-
Thanks Horace, I've matched the first 54 monsters to the items so i will play though and see if they match as they should. The first one I can confirm is correct.
-
I tested the first three and they were ok, and I was able to modify them!
On my editor, I will try and remove all monsters that *don't* hold an object and then created a fast-route through to do some checking.
-
Thanks Horace, I've done the same.
So far they have all been correct, but I'm still not sure why there is only 54 Monsters with the 'Bit' set (for monster type 8+) but more items in the data block.
-
MadMunky, i am sure you are doing your bit check wrong.
I have take my extracted .monsters files, and I am deleteing any monester (6 bytes) that doesnt start with $8 or $9 ..... so far i have;
block length !97 ($61)
serpent = !14
chaos = !18
moon = !37
dragon =!28
total = 97
i've saved the blocks so i have copies with *only* monsters who drop items.... attached for reference, although un-tested!
-
So I have 97 Monster with type >= 7 but only 54 with the 'bit' set for holding items.
-
So I have 97 Monster with type >= 7 but only 54 with the 'bit' set for holding items.
Any number >7 *has* to have the bit set. So if you have toe 8 or 9 (or anything above) then the number 3 bit is set, not clear.
Think about it using the full binary notation.... When you convert binary to a number the "easy" way, you add 1,2,4 ,8 for whenever bits 0,1,2,3 are set.
So 0001 has only bit 0 set... That is 1 in decimal.
0101 has bits 0 and 2 set.... That's 1+4 = 5 in decimal.
1000 has bit 3 set..... 8 in decimal
Any more than that *has* to have bit 3 set, and therefor gives a decimal value >=8
1111 for example is 1+2+4+8 = 15
-
OK Sorry my bad I had previously hard coded it to type 8 so type 9 where missed, I've fixed it and now matching 97 monsters :D
-
glad to hear you will be getting the right numbers now :)
-
OK Sorry my bad I had previously hard coded it to type 8 so type 9 where missed, I've fixed it and now matching 97 monsters :D
Did you correct this for actual bit checking in the end?
-
I did :)