Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MadMunky]

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

[Hungry Horace]

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.

[MadMunky]

Thanks Horace,

Least I can make a start and see what breaks

[Hungry Horace]

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.

[MadMunky]

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?



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 )



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!

[Hungry Horace]

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

[MadMunky]

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?

[Hungry Horace]

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

[Hungry Horace]

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

[Hungry Horace]

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

[Hungry Horace]

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!

[MadMunky]

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

[Bit]

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

[copse]

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.

[MadMunky]

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