61
Projects, demos, and games Information / Re: STICKY: 2020 King's Field II port progress report
« on: April 06, 2022, 01:40:21 PM »
black hole of despair
Today I set out to switch between this blue sky and the dark sky. Somehow it spiraled into a recurring nightmare so that I couldn't seem to tear myself away from it all day.
The tricky thing is loading the sky without hitting a hiccup. I couldn't get it to work so I ended up tearing through and double checking all of my code around this sort of thing. I found a lot of problem areas in the process. Some may be bugs in the current patch. I kept going through moments where it seemed to be working, only to later have it regress back to not working.
Even the map transitions I set up were stalling. But I think I've got a handle on all of it now.
On the sky changes front, I started out by looking at the event trip zones as a possibility, however they're really pretty badly designed. I thought about how they could be improved. But for this leg of my project I decided it would do to add a formula to my INI file that looks like sky[1] = if(neg(70-2_,12-3_,40-1_,1_-56,0),4,1) and just cuts out the relevant section of map.
I've made the 2 old "alphafog" Detail extensions that serve to blend the sky into the ground plane of fog communicate the sky model number to specialize accordingly, but I'm not certain if this is best for the other ones that control the fog effects mainly. These 2 are very much tailored to the model itself and isolated, so it seems fine to work like this.
Next I have to work on the UV animation. In order to make this blue sky I had to disable it. I could write a long paragraph about what the options are how to do this. I'm not sure yet what I intend to do. I'll have to figure out something.
trip zone thoughts
Trip zones definitely need to be improved. The main problem is there's no way to pick up on leaving the zone, so it makes event setup really tedious and unreliable. Unfortunately there isn't a very obvious way to incorporate this into SOM_MAP's existing framework. I would start by adding a system number to the INI file for testing the trip zones, which can help some, but can't inform events, so they would need there own way to do this, that I think could be done with the Counter loading module, but isn't very straightforward. It would be better if the trip zone events had a direct way. I thought about letting the "always on" events define an optional trip zone. The only real problem there is how to choose if the zone is square or circular. Being "always on" could process coming or going or staying in or out. But how? The Counter way seems most practical. Its only drawback is obtuseness and requiring dummy trip zones. But the master event could consolidate all trip zones. The approach I took probably isn't practical for a real project, and isn't user-friendly at all, so I'm certain this trip-zone approach will be realized down the road.
Today I set out to switch between this blue sky and the dark sky. Somehow it spiraled into a recurring nightmare so that I couldn't seem to tear myself away from it all day.
The tricky thing is loading the sky without hitting a hiccup. I couldn't get it to work so I ended up tearing through and double checking all of my code around this sort of thing. I found a lot of problem areas in the process. Some may be bugs in the current patch. I kept going through moments where it seemed to be working, only to later have it regress back to not working.
Even the map transitions I set up were stalling. But I think I've got a handle on all of it now.
On the sky changes front, I started out by looking at the event trip zones as a possibility, however they're really pretty badly designed. I thought about how they could be improved. But for this leg of my project I decided it would do to add a formula to my INI file that looks like sky[1] = if(neg(70-2_,12-3_,40-1_,1_-56,0),4,1) and just cuts out the relevant section of map.
I've made the 2 old "alphafog" Detail extensions that serve to blend the sky into the ground plane of fog communicate the sky model number to specialize accordingly, but I'm not certain if this is best for the other ones that control the fog effects mainly. These 2 are very much tailored to the model itself and isolated, so it seems fine to work like this.
Next I have to work on the UV animation. In order to make this blue sky I had to disable it. I could write a long paragraph about what the options are how to do this. I'm not sure yet what I intend to do. I'll have to figure out something.
trip zone thoughts
Trip zones definitely need to be improved. The main problem is there's no way to pick up on leaving the zone, so it makes event setup really tedious and unreliable. Unfortunately there isn't a very obvious way to incorporate this into SOM_MAP's existing framework. I would start by adding a system number to the INI file for testing the trip zones, which can help some, but can't inform events, so they would need there own way to do this, that I think could be done with the Counter loading module, but isn't very straightforward. It would be better if the trip zone events had a direct way. I thought about letting the "always on" events define an optional trip zone. The only real problem there is how to choose if the zone is square or circular. Being "always on" could process coming or going or staying in or out. But how? The Counter way seems most practical. Its only drawback is obtuseness and requiring dummy trip zones. But the master event could consolidate all trip zones. The approach I took probably isn't practical for a real project, and isn't user-friendly at all, so I'm certain this trip-zone approach will be realized down the road.