creatures caves welcome, guest
downloads   gallery   dev   community   creatchi   forum   mycaves
bookmarks | search | post new topic
Development Forum
old
C2 - Wraparound fix attempt.   1 | 2
GimmeCat

GimmeCat
United Kingdom  


  4/22/2018  1

I actually acquired a release version of C2 yesterday to test exactly that. The wraparound points seems to be in the same place (norn desert/volcano island), however, when I then tried injecting your wraparound fix, nothing appeared to change. They still ended up walking the wrong way when looking at objects. It was very odd!

Having been inspired by your work, Elegnaim, I've decided to try my own version of a wrap fix. Originally I was going to simply modify your scripts (this was for personal use) but I've ended up taking a different approach entirely.

Haven't tested my method yet - it takes a while to edit so many scripts, doesn't it?! - but I'll let you know how it goes when I do. :)

 
GimmeCat

GimmeCat
United Kingdom  


  4/24/2018  1

BA 1.5 is going to include my version of the wrap fix. I ended up writing the scripts from scratch.

Get ready for a massive infodump. :)

So here's what I found out. The world x0|x8352 point is at the coconut island and is the 'true' wrapping point of the world. This makes a lot more sense than what we were thinking with it beginning at the desert. I'm pretty sure now the wrapping problem comes from an engine math error to do with calculating polar coordinates.

Think of the world as a circle divided into two halves, with coordinates going clockwise and both x0 and x8352 at the top:



The game calculates an object's position from 0 between -180 and +180 degrees as part of its magic in getting a 2D plane to wrap back on itself.

Let's say we have a NORN at x4000 and an _IT_ at x4200.

The NORN falls into the +180 range (right half of the circle). The _IT_ falls into the -180 range (left half of the circle). Now the engine is supposed to add 180 degrees (or x4176) to the _IT_'s calculated angle to convert its position to a positive value, because even though it's in the -180 half of the circle, the world doesn't use negative coordinates.

Problem is, this correction is missed.



Internally, this means that when the engine tries to calculate 'appr' based on NORN and _IT_'s relative positions to each other, it thinks _IT_ is half a world away, rather than just 200 pixels away. You end up with the game telling the NORN that it must face the direction of -x4152 instead of x4200.

So, how do we fix this?

Uh... well, we can't. But we can work around it. Elegnaim's solution works well enough, but I think what I've come up with might be slightly more reliable.

Here's an example script:

scrp 4 0 0 29
doif touc targ _it_ lt 1
loop
gsub appw
wait 60
untl touc targ _it_ gt 0
endi
impt 3
aim: 2
touc
wait 4
anim [111112113114111]
mesg writ _it_ 3
stm# writ targ 15
wait 4
pose 12
wait 20
done
subr appw
doif posx gt 7000
impt 3
aim: 2
appr
else
doif posx ge 4176
targ _it_
doif posx ge 4176
targ ownr
impt 3
aim: 2
appr
else
targ ownr
impt 3
aim: 2
pose 60
anim [013014015016R]
endi
else
doif posx lt 1000
impt 3
aim: 2
appr
else
targ _it_
doif posx lt 4176
targ ownr
impt 3
aim: 2
appr
else
targ ownr
impt 3
aim: 2
pose 59
anim [013014015016R]
endi
endi
endi
endi
retn
endm

(Gotta love a <code> tag that doesn't let you indent..)

There are two main differences between my solution and Elegnaim's.

The first is that I've stuck with a single gsub emulating the 'appr' command and calling it from a loop that repeats until NORN and _IT_ are touching. Only after the two are in range does the rest of the script fire. This has resulted in shorter scripts overall, but whether that translates to better performance, I couldn't say. Maybe?

The other difference is that I've used a raw anim/pose cycle to get the creature walking in the appropriate direction. I think that the 'push' of Elegnaim's solution might exacerbate the pain issue encountered along the world midpoint, so I wanted to come up with something that would avoid essentially shoving them into a wall and causing more pain.

One drawback to this solution which I will probably end up fixing before I push BA 1.5 is that if a norn is trying to approach something it can't actually reach, such as a cloud, then they will never end up 'touching'. This is more realistic, technically, but does mean that they won't do that cute little 'reaching up' animation when they try to touch it. They'll just wander around underneath it for a bit.

Also, I still catch them initially looking in the wrong direction when they spot an object across the midpoint. If you have any input on why that might be, Elegnaim (or anyone else) I'd be very happy to hear it! I couldn't find where the initial 'face direction' is set before any action is taken.

One final issue: The 'Flee' behaviour uses poses that specify "away from _IT_" and there's no way to trick the game to reverse this direction. So retreating norns are still going to retreat in the wrong direction near the wrap point.

As for why they experience pain here and nowhere else?



Well, I still have no idea. The only difference I could spot between those and other rooms along the midpoint is that they didn't have floors. But I added floors in, and it still happens.

 
Yme

Yme



  4/24/2018

GimmeCat wrote:
BA 1.5 is going to include my So here's what I found out. The world x0|x8352 point is at the coconut island and is the 'true' wrapping point of the world. This makes a lot more sense than what we were thinking with it beginning at the desert. I'm pretty sure now the wrapping problem comes from an engine math error to do with calculating polar coordinates.



Yeah, that's where the real wraparound point is, and it used to have the same problems as the desert area, until it was fixed in a patch, soon after the game was first released.

That's why I thought that they might have just switched it around, when Elegnaim thought about swapping rooms around, to put the problem back where it originally used to be.

What is the reason why it's not possible to fix the calculations the engine does, though?

 
GimmeCat

GimmeCat
United Kingdom  


  4/24/2018

It's hardcoded. You can't change the behind-the-scenes behaviours of commands like "appr" or "targ" or "stm#", they just do what they've been programmed to do.
 
Yme

Yme



  4/24/2018

So it's a bug in the language itself, sort of?
 
skerit

skerit
Belgium  

 visit skerit's website: Skerit
  4/24/2018

What would have been the reason to move the *real* wraparound point from love island to where it is now? It must have involved some changes to the coordinate calculation & testing (hehe, testing & C2... That's an oxymoron for you)

Even that they changed it in a patch AFTER the game's release indicates there was a serious issue with it being where it was, more important than all the other issues we still have, right?

So did it actually fix *something* or was it a failed attempt at a fix, which they eventually just left in?

Also: the original wraparound point went straight through walls, mostly. That seems like such a logical place.

 
Elegnaim

Elegnaim



  4/28/2018

So my logic for shifting the rooms back to align with the old blue ocean/volcano wraparound point was a hunch -- and a not terribly well grounded one at that -- that the engine was trying to figure out neighboring rooms based on both the ocean and desert wrap points at the same time, and getting confused.

Like maybe trying to get collision data for the room to the right of the left incubator elevator shaft from one of the rooms to the right of the volcano -- all of which have walls on their left side.

GimmeCat wrote:
It's hardcoded. You can't change the behind-the-scenes behaviours of commands like "appr" or "targ" or "stm#", they just do what they've been programmed to do.



Welllllllllllllllllllllllllll

42C6EB is doing a comparison against some register to see if it's set to 'appr' followed by a jump. You could maybe have CheatEngine break whenever the application jumps into wherever that jump is leading to (42c746?) and start stepping through things until relevant math starts happening (assuming it does, hopefully).

Should be another reference to appr at 42A0C5.

If you can find the assembly code for processing appr, you should be able to change how the executable handles it.

 
GimmeCat

GimmeCat
United Kingdom  


  4/28/2018

Well, I mean of course. Dig into the assembly and anything can be fixed, theoretically. :) I just meant within the realms of CAOS scripting.
 

prev | 1 | 2 | next

downloads
cobs
adoptions
creaturelink
metarooms
breeds
 
gallery
art
wallpaper
screenshots
graphics
promos
sprites
dev
hack shack
script reservations
dev resources
active projects
dev forum
 
community
links
advice
chat
polls
resources
creatchi
 
forum
bookmarks
general
news
help
development
strangeo
survivor
mycaves
log in
register
lost pw
0 online
creatures caves is your #1 resource for the creatures artificial life game series: creatures, creatures 2, creatures 3, docking station, and the upcoming creatures family.

contact    help    privacy policy    terms & conditions    rules    donate    wiki