Arcen Games
General Category => Starward Rogue => Starward Rogue Mods & Modding => Topic started by: ptarth on January 30, 2016, 07:26:31 am
-
Rather than clutter up the other highly serious modding threads, I thought I'd open up a more general question thread.
I've been looking at the shots included in the game for inspiration and ideas.
We have red, yellow, green, blue, and purple.
We have white, golden, burningred and emblazonedyellow (close to orange).
Why are there no orange shots (seriously)?
-
So after much ado I wanted to give Visual Studio a shot for editing. Previously, I have been using notepad++ to edit the xml files, however after Misery commenting on it enough, I wanted to give VS a shot. Any suggestions on how to set this up? At some point in time I might try to get SVN access, but not until I've contributed enough to make it worth the effort on the part of others.
-
Hm, I'm not sure what you mean by "set it up". You just install it. If there's something else to it than the usual, I never encountered it.
-
Right. It wants me to create a new Project. Do I just ignore that and just use it as a fancy text editor?
-
I just go to "open file" and load the XML files. That's about all you need to do.
-
I just go to "open file" and load the XML files. That's about all you need to do.
So effectively just treat it as a fancy xml editor?
-
Yep.
-
K. We'll see how it goes I guess. Although, I'm finding it a tough sell because I'm using a potato to run all of this and VS is really top heavy on it.
Back to the original question then: Why no orange shots? Is it a palette issue? A color-blind issue? Does Chris or Blue just hate orange? I mean, I'm not a big fan of orange, but I'm having troubles making rainbows without the O in ROYGBIV.
-
K. We'll see how it goes I guess. Although, I'm finding it a tough sell because I'm using a potato to run all of this and VS is really top heavy on it.
Back to the original question then: Why no orange shots? Is it a palette issue? A color-blind issue? Does Chris or Blue just hate orange? I mean, I'm not a big fan of orange, but I'm having troubles making rainbows without the O in ROYGBIV.
Confimed: Nyan Cat being worked on by ptarth.
-
K. We'll see how it goes I guess. Although, I'm finding it a tough sell because I'm using a potato to run all of this and VS is really top heavy on it.
Back to the original question then: Why no orange shots? Is it a palette issue? A color-blind issue? Does Chris or Blue just hate orange? I mean, I'm not a big fan of orange, but I'm having troubles making rainbows without the O in ROYGBIV.
Confimed: Nyan Cat being worked on by ptarth.
Complete with the relevant .ogg played on looping attack.
-
Next Question: Why is there one and only one EmblazonedPurple shot? QuadEmblazonedPurple?
-
- How large is a room? I mean sure, the room designer uses 1 character per tile, that's not what I mean, I mean, in pixels. For example right now I have estimates of 66 pixels per tile and 68 pixels per tile.
- In pathfinding (specifically CardinalMover right now), how much does the hitbox effect the turning radius?
- In pathfinding (specifically CardinalMover right now), how much does the time_to_visually_rotate_180_degrees effect the turning radius?
- I spawn 10 CardinalMover enemies on top of one another, under certain situations, some of their paths are offset by roughly half the wide of their hitbox. What's going on?
- When using a random spread salvo weapon (example: shot_per_salvo="45" inaccuracy_spread="135" inaccuracy_is_by_salvo="true" with all of the performance logic on) I get the initial shot being fired off at a completely different angle than the rest of the salvo. I'm guessing the original shot is going off at the correct angle and doesn't have the inaccuracy applied. I guess this is also a preliminary bug report and not a question.
-
Are you using an initial_firing_delay? I had some issues with my ships' first shop being in the wrong direction until I set initial_firing_delay="0.1" to give it time to change its facing properly.
-
No. I tried it. Cue time still mucks up salvos as well.
See attached image.
-
I had issues with my Aegis shield pattern getting messed up like that (sometimes much worse) that involved how the player moved. Does that problem go away when the player stays perfectly still?
-
No. I tried it. Cue time still mucks up salvos as well.
See attached image.
There's always the make it fire stationary non rendering bullets solution.
Then have that bullet spawn the pattern itself.
yeah this bit of the game is full of not fun buggy things.
trying to synch up cardinal movers (spawned together) onto a fixed grid seems not so easy.
tiles have a radius of 32 it seems, so in theory dead on 64... in theory...
-
No. But that's because I'm also using a massive random component in the shot direction.
How I think it works is: the first shot (central) aims exactly at the player (target="direct"), then all successive shots in the salvo are space around it, according to the logic you define. Then the misdirection angle is added to each of the shots, except the first shot which is somehow skipped.
There are ways to get around it like specifying a special pattern or to use dumbfire on a fixed angle rotation system.
-
No. But that's because I'm also using a massive random component in the shot direction.
How I think it works is: the first shot (central) aims exactly at the player (target="direct"), then all successive shots in the salvo are space around it, according to the logic you define. Then the misdirection angle is added to each of the shots, except the first shot which is somehow skipped.
There are ways to get around it like specifying a special pattern or to use dumbfire on a fixed angle rotation system.
ah ha!
The loop bug!
It looks just right! Iterating over all generated shots EXCEPT the first one.
-
There's always the make it fire stationary non rendering bullets solution.
Then have that bullet spawn the pattern itself.
Yep. I'm hoping Keith sees my mantis entry and has time to fix it. I'm guessing it is probably 1-5 lines of code that weren't quite right, depending on how it was implemented. If he does, great, I don't have to change anything. If not, then I'll use another solution when the Invader is ready to go.
- yeah this bit of the game is full of not fun buggy things.
That's a bit harsh. I mean, sure, there are some bugs, but mostly minor stuff. I'd say 90%+ of the things work right, 8% work mostly, and 2% don't work at all. If I can't make awesome things with that sort of system, then I deserve to be hit by invisible 10km IJN Torpedoes.
trying to synch up cardinal movers (spawned together) onto a fixed grid seems not so easy.
You and me both. However, I'm reasonably happy with how the current draft of the Invader v2.0 came out. The files are up on the Mantis if anyone wants to take a look.
tiles have a radius of 32 it seems, so in theory dead on 64... in theory...
Ah. Hmm. I was calculating them based on 66. Using your numbers... I have new numbers... that don't line up with the old numbers.. Hmm...
With a 31x31 room, it seems I can place an enemy at 1050 from the center (but I can't place the player there, strangely. Perhaps the placement point of the player and enemies differ?) This gives me an estimate of 68 pixels per tile for enemy placement. Using 64 it gives me 1984, which is definitely too narrow. Except that for the player that might be right. I stuck the player spawn at 800 because 1000 wasn't working correctly. So if the spawn points anchorpoint differs based on game entity... Or maybe based on hitbox size?
My take home lesson is, don't require pixel perfect movement, especially since the player isn't able to keep track of everything. Also, pray that Misery or Pepisolo doesn't decide to shift the movement speed, hitbox, direction shift time, or breathe too hard.
-
The loop bug!
It looks just right! Iterating over all generated shots EXCEPT the first one.
Actually, that makes a ton of sense. Now we wait for someone to bring it up in casual conversation with Keith and see if he does a face palm.
-
Would that be the pants on head thing?
-
Would that be the pants on head thing?
Yes.
-
Anyone know where/how the unlock of the Warden works?
In a related question I can see how floors are generated, but where does it specify how many levels are to be generated for your run and what happens after the final boss. I fear that this is all hard coded in the engine and not accessible.
-
Just look at the status display that appears when you're starting a new run. It lists how many more times you need to defeat the Warden in order to unlock floors 6 and 7. The starting number is 3.
And I dont think there's a way to alter that, it sounds like something that's hardcoded. Why would it need to be changed though?
-
Because I want to do something horrible and evil that would potentially involve restructuring the length and unlocking sequence of things in the game.
-
That sounds like alot of effort.
I always prefer to just make things shoot at the player more.
-
That sounds like alot of effort.
I always prefer to just make things shoot at the player more.
Hmm, which tagline do you think is better?
- It's part of my brawler revolution plan.
- You wouldn't understand. It's a Team Flame Tank thing.
-
They sound like they just go together. One after another.
Sounds like something a certain family member of mine would say, resulting in much groaning and facepalming all around. Therefore, I approve of these lines.
-
It doesn't actually fit the thread exactly, but it was better than creating a new thread. This is sort of a public notice or modders be aware notice.
I've been working on shield protected entities. The Guardian Blaster is a default weapon and it causes problems. Specifically, it fires 13! shot removing shots per attack. That means it will penetrate and destroy 13 shield shots regardless if they reflect, kill, or intercept and hold.
My first solution was to make a shield shot that produced another shield shot on death (I'm guessing you can see where this was going). It worked, however, it only doubled the number of shields between me and the target.
The second solution was to have the second shot spawn itself on death. This causes infinite shots. I suppose if your shield system only fires once, that works. In my case I have a teleporter nearby that is causing problems.
The third solution was to have the refresh rate of the shield shot be very low (.05). This worked.
My fourth solution is to return the shield system shot rate to 1, but to have the shield pattern refresh itself with mostly invisible shots within a spawned loop. This limits the stacking of shield shot animation. It destroys system performance. Trying more optimizations to see if I can fix this one.
My fifth solution is to see if I can do something the do_not_do_rest_of_logic_on_early_death attribute. Perhaps an infinite self-spawning shot that will die properly only when left to die?
-
does immune_to_interception_and_aoe not work, or do they still need to be able to be killed by the player.
-
Oh thank you! for reminding me/giving me a lead.
So, I hadn't tried does immune_to_interception_and_aoe (I had not remember/found it). I also hadn't tried a shield shot that does AOE damage on death (to clear out the shots). What I did next though was to use shots_can_withstand_x_shot_interceptions="100". Which works without having to change much of anything.