Discussion in 'Released Mods' started by wondible, April 5, 2014.
yeah just let it fail in case nothing is ready.
1. Play 2v2, have some nukes
4. Main menu
5. join another 2v2
6. Missle command stays with old nukes
And just as I fixed the old bugs ;^)
I have lovely theoretical code to prevent that, but it clearly needs more testing. I'm wondering if Ubernet still has you in the previous game?
Maybe you can copy from PA Stats how it captures the lobby id.
Why do you use localStorage instead of sessionStorage?
Because I want to handle crashes and the like.
If the program closes, the player will have to reconnect, and you hook model.joinGame.
Yeah but I still want to keep some data in memory even over reload or crash or whatever. I am not quite sure anymore where you can grab what data, but at least back when I wrote this code I had to grab some data during the lobby/join phase of the game and use it during the game.
Generally I don't see any downside in the local storage for my data, so I can't see why I should use the session storage, that only adds potential error sources.
Ah... new_game does store it in session... and then overwrites the definition with a transient one.
Ah yeah I remember I saw that bug. Basically it seems they don't use it at all, so they never noticed I guess and I just rolled my own logic.
- Ready launchers are selected first, but then unready launchers are queued up.
- Abililty to remove problem launchers from the list.
- Layout changes; vestigial attack buttons removed.
- Hide during game-over/review.
- Bugfix: selecting attack wouldn't set attack command mode first time (no selection)
- Bugfix: losing keyboard commands after using hover-pips.
- Bugfix: tracks current game id differently, since UberNet doesn't always know which game you are in.
The remove button threw off what layout there was, I'm still not quite happy it.
- Clear groups on disconnect api (Reconnect Button mod compatibitilty)
- Add icon
- Release to PAMM
This is nice, very good for large games. Roll on the carpet bombing
edit: A short video showing the attack function.
Quick question, surely naive (ain't no dev and have no modding knowledge):
Since there is no alert saying a nuke is ready, wouldn't it possible to rely on other data, such as a specific launcher build power (since it's a factory)? Do you have access to such data ?
I was thinking that a launcher (alive) with zero metal / energy expense would most likely mean a nuke is ready (or that launcher's energy toggle was used to switch it off).
you can't get that info currently
I've thought about trying do some dead reckoning based on build power, and perhaps letting the player assign assisting fabbers. A more likely first step would be let the player select a progress status, and use that to update a simple time-based dead reckoning.
would it be possible to implement a completion bar into the UI to show how far along a nuke is in a specific launcher?
I've thought about it. Most of the options will be both complicated to implement and not very good. Plus it looks I have some paying work and won't necessarily be able to take on major projects for a while.
Manual: provide a bar the player can click to record how far each launcher is beyond ready/not. Might be combined with one of the following.
Dead Reckoning: record the time between start and marked-ready, possibly with manual progress updates. Use this as a stand-in for the build rate that fuzzes together economic health, assistance, etc.
Estimation: Hook into blueprint framework to get missile cost and launcher fab rate. Provide a method to manually link a group of assisters to the launcher. Track economic efficiency to figure out estimated build rate. So yeah, really complicated.
Bonus method: hook into hover events to pick up actual progress when the cursor is over the launcher. Doesn't work well with the current hover-pip workflow.
so there is no way to pick up the health of the nuke directly?
If it was easy, I would have done it already ;^)
Separate names with a comma.