Almost 3 years ago, I added international keyboard support into ProQuake with a cvar (with a keypad bug I keep forgetting to fix) on Windows, but it is dependent on Windows messaging stuffs so it is totally non-portable.

I was just looking to understand the FitzQuake 0.80 implementation of the SDL build and the Key_Map thing threw me off. I thought some non-obvious keymapping was going on using libsdl somehow. 

It just maps SDL key codes to Quake key codes IIRC. 

I don't know if other people have this problem, but I find that the more immersed I am in playing a Quake map, the less likely I am to remember to quicksave. When I die, having to replay several minutes really breaks the immersion :-(

To fix this problem, I'm working on a patch which adds autosave/load to QuakeSpasm. Here's a snapshot:

http://github.com/downloads/ericwa/Quakespasm-Autosave/quakespasm.zip

Here's how it works: at regular intervals (no more frequently than every 30 seconds), it automatically creates a save called auto_{mapname}. When you die, the most recent save is loaded - regardless of whether it's an autosave, quicksave or normal save.

If you want to start a map from the beginning, you can use the "restart" command, or "map mapname".

It needs more testing - there are heuristics for deciding when to autosave which need to be tweaked - but check it out!

the code is here:
http://github.com/ericwa/Quakespasm-Autosave 

Great feature ericw! 

 

While working on a convertion of the qtest1 I have a lot of issues in the coding part.
A lot of the script has changed in the original version so I'm tinkering to get a right one that includes all original entities, and has some add-ons like earthquake, serpent, earlier shallrath and so on.

Now one thing breaks me up, and I don't know if it is the code or Fitzquake. Halfway the level the map just hangs, and there is no oppertunty to finish the level or make a quit outcome.

I think it has to do something with my broken code attempts, but fortunately Quakespasm or BengtGl, Afterquake don't have this error. 

sounds a bit like a remove/setmodel/setorigin/setsize/walkmove/movetogoal/droptofloor call inside a touch function.
certain ordering can result in infinite loops if you violate the rule that you don't do the above (all of those functions can change the entity links in the physics cache states which is a problem if the engine is walking them at the time). 

Possible, most of the time I have not the slightest idea what I'm doing. As long as the code produces a progs.dat it's allright with me.
I just wondered why the different engines have such a strange impact on behaviour.

Aftershock seems to handle the earthquake code with much more disaster then other ones.
When I added the dragon code from Patrick Martin lots of other changes were made I have no controll of.

Mixing several codes can make it a bit blurry as much statements depend on each other.
I have a great code for the Serpent, but it uses fbx that is not easy to integrate. 

only to confuse madfox ;-) 

a "sv_touchlinks: next != L->next" error.

My blame_code, it somehow has something to do with a touch code. 

madfox, see the rule above. :)
touchlinks is specific to a trigger's touch function. hence all the self.think=SUB_Remove; lines in the vanilla qc. 

void trig_touch () = {
//Do stuff
setmodel(self,"madfox.mdl"); //Just NO!
setorigin(self,nowhere); //how do I physic now??
droptofloor(); // what?
SUB_Remove(); //EGAD are you crazy???
};

Is BAD...

Instead do:

void trig_touch () = {
// Do stuff
self.think = SUB_Remove; //veddy nawce
self.nextthink = time + 0.1; //let's do the touch links dance
}; 

Spike, Qmaster.

Point is that I have not enough knowhow to trace a console error parm back to a trigger_touch. I admire your insight, but a sv_touchlinks: next != L->next error doesn't give me any link to the qc.

It also isn't something I did, but a logic result from adding code to an excisting, while both are a mirakle to me.

While testing the mod I experienced this flaw in fitzquake, while it doesn't in other engines. So my concern became this next etc. could be the cause.

After the exit this message appear, so it can be something I did with the qtest1 code, as in this first code there is no info_camera or exit.
Maybe better to use the coding thread as this error is more code-related then fitzquake-sdl, and I could use some advice as the dragon code won't accept the new serpent code.

Here is how I have come sofar: MF_Qtest03 

There was a behavior change introduced in Fitzquake 0.85 related to touchlinks. It was attempt to fix the general case, but actually didn't work properly and causes new crashes sometimes. For example, it crashes the level WhiteRoom.

Madfox, if you see a crash in fitz 0.85 and no other engine, it might be the same problem. Quakespasm has fixed it I believe. 

I just wondered why it happened only in fitzquake. As qtest1 is the oldest quake code I started on a win98/dos, which has fitzquake075.

Fine to know I don't have to search it in the qtest1 code.
I'm only modding my qc attention. 

"keep posting and fortify the data"!!! That is so becoming the tagline for a forum superhero team!