Minor Tweaks

[Keldorn]

1. Swap the damage packets around on Greater Holy Arrows and UGA/GA's 2nd charge so that the rebuke hits first like it does on the Holy Lance.

2. Replace multiple gold pouches in individual chests with a single package of gold.

3. Make the Steam Crossbow not fire when clicking to swap bolt type or weapon/spell.

4. Make summoned monsters that don't self adjust not count towards calculated levels/monsters slain for treasure.

 

[Thothie]

1. Swap the damage packets around on Greater Holy Arrows and UGA/GA's 2nd charge so that the rebuke hits first like it does on the Holy Lance.

Not sure if it can be done, I'll have to look into what's causing it. Projectiles deal damage differently than weapons, and the polearms sometimes leave the registration system to do damage. Will look into it though.

2. Replace multiple gold pouches in individual chests with a single package of gold.

Can't be done. Gold packages in individualized chests have to come in fixed amounts, due to each fixed amount package requiring a separate script. You can create a global gold package of any amount, but not individualized ones. Best I can do is offer larger packages, unless MiB can code up a function for adding gold to specific stores.

3. Make the Steam Crossbow not fire when clicking to swap bolt type or weapon/spell.

There's no function to let the script know that the arrow selection menu is active, so there's no easy way to do this.

4. Make summoned monsters that don't self adjust not count towards calculated levels/monsters slain for treasure.

They don't. Only creatures specifically flagged for self-adjustment do.

 

[Orochi]

Based on what I've seen of the source code, it might be possible to alert the script system that the menus are active.

 

[The Man In Black]

so there's no easy way to do this.

 

[Orochi]

Oh come on, it can't be THAT difficult.

 

[The Man In Black]

So you do it. Thothie doesn't code and I don't care anymore.

 

[Thothie]

So you do it. Thothie doesn't code and I don't care anymore.

I *kinda* code... I could *maybe* work it out, make a script call when the menu is activated, and store the time (since the menu has a time out). Just, yeah, effort + trial & error.

1. Swap the damage packets around on Greater Holy Arrows and UGA/GA's 2nd charge so that the rebuke hits first like it does on the Holy Lance.

Looked into this further, and, sadly, it canna be worked out. The reason it works for the Holy Lance is the polearm projectiles do their damage differently, and leave the registration system (to allow damage to vary based on time held, distance, etc.) Even with that, I notice, however, you can still do so much damage with one Holy Lance throw that a target skeleton can die from the raw damage before it realizes it's been struck by Rebuke Undead, despite the fact that it should indeed get the Rebuke spell first, and thus the weaker ones tend to get up again, when they should not. Therefore, it likely wouldn't be worth the extra overhead it would take for Gholy Arrows to work the same way (manual damage formulation), and it's straight out for the UGA/GA (completely dependent on standard registration). Since the damage doesn't really vary, it isn't really worth it for the Holy Lance either, but it just happens to already be using the polearm projectile's manual damage system.

 

[Orochi]

Thothie, you do rely heavily on scripts for pretty much everything, even in situations where scripts are not the best solution to the problem. I think that's what he's getting at.

That being said, I can leave myself on hand for coding matters. I do remember looking over the code that deals with quickslot stuff, you might be able to insert something codeside so it knows when it opens and closes, or dispatches a script event when it does happen. But please don't store anything in a script var if you can avoid it. I actively avoid using scripting systems in this manner, especially MS:C's, because it's slow as hell.

 

[Thothie]

Thothie, you do rely heavily on scripts for pretty much everything, even in situations where scripts are not the best solution to the problem. I think that's what he's getting at.

I don't think that's what he was getting at, sadly. There's no easy solution for it, regardless of whether the solution is code side or script side (and, currently, there is no script side solution). Adding a script side solution would actually be easier than adding a code side one, as you'd have to block access to the attack button for every other function that uses it while the menu was open. Tricky to do when it's on a hook.

I don't see a way to setup a script side solution that wouldn't involve a var though, unless you create a new global player condition, which would be just about as rough as an entirely code side solution. Granted, I don't think speed would be a major issue in this case - it's not something you'd be checking often enough to be a factor. (Unlike, for instance, the player animation system, which I really think should be moved off the scripts and to the codes.)

 

[Orochi]

Agreed. My idea, though, was to have the code INFORM the script system via dispatching an event somehow. I've seen those scattered through the code, and I'm wondering if it could be rigged up to do that. That way, you wouldn't need a variable to track it, and it would happen right as the code was being processed. The idea here being that we're informing the script system so that weapons that might use it that are within that system can make use of it. Given that the Steam XBow is outside the registration system, I take that to mean it's code-side, which is why I suggested a code-side solution initially.

 

[Thothie]

Eh, well there's script events, which is what I was thinking of using. Script events actually use a bit of processing time, but again, this isn't something that happens every frame or anything, but it wouldn't avoid a var. Eg.

{ game_arrowmenu //<time_opened|0=closed>
	setvard PLR_ARROW_MENU PARAM1
}

The other way to inform scripts is via $get() params. eg. $get(ent_owner,arrowmenuopen) - that'd be the only way you wouldn't need a var, but then you still need a new flag on the player.

For that particular check, it would be less resource intensive, but it'd also mean adding a new conditional to ALL $get checks (which often happen every frame - kinda wish we had our $get's better categorized to avoid that. ><) So, in this instance, the script event is likely the less resource intensive approach, as this isn't something that happens all that often.

A completely code side solution maybe to add a new flag to the player and then check that before attacking, but it might bring up unforeseen issues (resulting in inability to attack), and would add the additional conditional for all attacks, rather than one particular weapon. (edit: Scratch that, that wouldn't work, because the Steam bow doesn't use the standard attack system - you'd have to suspend the hook entirely, or catch it under game_+attack.)

 

[Orochi]

I can't make a judgment here because I'm not familiar with all the specifics of the scripting system. If you think it'll be less resource-intensive, then go for it. The MS:C source is spaghetti code anyway; macros and such abound. It's worth noting that the code-side of the menu system, that is what actually makes it display, is client AND server. The scripts have to have something to make use of, so I figured we could have the source code do what it needs to do really fast and inform the scripting system along with it. I'm not sure but I think the code has a way to tell when the menu is open or closed.

 

[Thothie]

Yeah, that's why we call it MSC++ - tis like once in a blue moon you actually use a standard C++ command.

If there's already a flag for telling if the menu is open, that's half the work done, but yes, if you trapped it before calling "game_+attack", you'd be checking an extra conditional every frame mouse1 was down, even with a purely code side check. Adding a $get() to grab the flag would be calling an extra conditional nearly every frame. So, scriptevent it is, I guess... $get and scriptevents are the only two ways I know of.

I'd have to look it up, but I suspect it's just sending a message to tell the client to activate the menu, and the client sending back to the server which arrow it selected (if any). You'd have to call the script event once on menu activation, and again on selection (in client.cpp, no doubt). The menu automatically times out after a few seconds, thus storing the time when the menu was activated would be required, and you'd have include the auto-close time script side, or add it to the param you sent.

You can see why we've not bothered with this though.

 

[Orochi]

The thing is, conditionals code-side are much faster than script-side conditionals. Scripts have to be parsed and run through a bunch of hoops besides. Checking a single conditional every frame does next to nothing speed-wise when it's running directly on the processor and not abstracted through 5 other function calls.

 

[TheOysterHippopotami]

While I agree that all of Keldorns suggestions are good ones, I think that if there is going to be a shortage of coding potential then your coding resources might be better spent in a different place.

 

[Thothie]

The thing is, conditionals code-side are much faster than script-side conditionals. Scripts have to be parsed and run through a bunch of hoops besides. Checking a single conditional every frame does next to nothing speed-wise when it's running directly on the processor and not abstracted through 5 other function calls.

A 0.5ms pulse every once in while is still better than adding a 0.1ms pulse every frame. (Not accurate, but the general comparison stands).

This is something you should take into account when coding for MSS.

I don't care anymore.

But... But... MSC Care Bear says you must care!

Please, do something simple, like getting us those extra quick slots, or something! Maybe it'll help you come out of your fugue and help our poor lost MSC child! :...(

 

[Thothie]

Hrmmm... I cannot figure where/what the delay is for the menu to time out on its own. ...and I really dun wanna "eye" it.